From peter.musgrave@magorcorp.com Sat May 1 03:51:02 2010 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 61DCF28C113 for ; Sat, 1 May 2010 03:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.228 X-Spam-Level: X-Spam-Status: No, score=0.228 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_50=0.001, 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 CQn4VIPF0Isg for ; Sat, 1 May 2010 03:51:01 -0700 (PDT) Received: from mail-gx0-f221.google.com (mail-gx0-f221.google.com [209.85.217.221]) by core3.amsl.com (Postfix) with ESMTP id D068128C0FE for ; Sat, 1 May 2010 03:51:00 -0700 (PDT) Received: by gxk21 with SMTP id 21so571218gxk.14 for ; Sat, 01 May 2010 03:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.165.7 with SMTP id n7mr4898558ybe.38.1272711043683; Sat, 01 May 2010 03:50:43 -0700 (PDT) Received: by 10.150.92.9 with HTTP; Sat, 1 May 2010 03:50:43 -0700 (PDT) In-Reply-To: <4BDB52AB.9000507@estacado.net> References: <4BDB52AB.9000507@estacado.net> Date: Sat, 1 May 2010 06:50:43 -0400 Message-ID: From: Peter Musgrave To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 10:51:02 -0000 Works for me (and happens to be what my application does). Peter Musgrave On Fri, Apr 30, 2010 at 5:59 PM, Adam Roach wrote: > [as chair] > > During IESG review of the INFO specification, several members expressed > concerns about the congestion properties of INFO. The draft authors and I= ESG > worked together to craft text that satisfies these concerns. > > Since the resulting text contains normative language, we are bringing the > proposal to the SIPCORE working group for a 2-week consensus call. Please > comment on the following proposed text before Friday, May 14th. If you ag= ree > with the proposal, please send a short response indicating that fact. > > "10.9. =A0Rate and size of INFO Requests > > =A0 =A0"INFO messages differ from many other sorts of SIP messages in tha= t > =A0 =A0 they carry application information, and the size and rate of the > =A0 =A0 INFO message is directly determined by the application. This can > =A0 =A0 cause application information traffic to interfere with other tra= ffic > =A0 =A0 on that infrastructure, or to self-interfere when data rates beco= me > =A0 =A0 too high. > > =A0 =A0"A designer of an INFO package, and the application that uses it, > =A0 =A0 need to consider the impact that the size and the rate of the INF= O > =A0 =A0 messages have on the network and on other traffic, since it norma= lly > =A0 =A0 cannot be ensured that INFO messages will be carried over a > =A0 =A0 congestion-controlled transport protocol end-to-end. Even if an > =A0 =A0 INFO message is sent over a such a transport protocol, a downstre= am > =A0 =A0 SIP entity might forward the message over a transport protocol th= at > =A0 =A0 does not provide congestion control. > > =A0 =A0"Therefore, an application SHOULD generally have at most one outst= anding > INFO message. > =A0 =A0 The guidelines in RFC3261 Section 18 MUST be followed for sending= and > receiving INFO > =A0 =A0 requests and responses, such as the guideline to not exceed messa= ges > =A0 =A0 sizes of 1300 bytes when the path MTU is unknown. RFC5405 provide= s > =A0 =A0 additional guidelines for applications using the User Datagram > =A0 =A0 Protocol (UDP) that may be useful background reading." > > Thanks. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Sat May 1 05:46:09 2010 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 803BA28CB28 for ; Sat, 1 May 2010 05:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_40=-0.185, 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 L8RVgl8H6l+Z for ; Sat, 1 May 2010 05:46:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6A25928CBCD for ; Sat, 1 May 2010 05:34:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-ef-4bdc1fab2c80 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A9.DB.08537.BAF1CDB4; Sat, 1 May 2010 14:33:47 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sat, 1 May 2010 14:33:46 +0200 From: Christer Holmberg To: Adam Roach , SIPCORE Date: Sat, 1 May 2010 14:32:59 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: AcrosF91AgyaHh/9SVeVA39RRQ4U5AAehBFW Message-ID: References: <4BDB52AB.9000507@estacado.net> In-Reply-To: <4BDB52AB.9000507@estacado.net> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 12:46:09 -0000 "INFO package" will of course be changed to "Info Package", in order to be = alligned with the terminology in the rest of the document. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Adam= Roach [adam@estacado.net] Sent: Saturday, May 01, 2010 12:59 AM To: SIPCORE Subject: [sipcore] Call for Consensus: INFO Specification and Congestion [as chair] During IESG review of the INFO specification, several members expressed concerns about the congestion properties of INFO. The draft authors and IESG worked together to craft text that satisfies these concerns. Since the resulting text contains normative language, we are bringing the proposal to the SIPCORE working group for a 2-week consensus call. Please comment on the following proposed text before Friday, May 14th. If you agree with the proposal, please send a short response indicating that fact. "10.9. Rate and size of INFO Requests "INFO messages differ from many other sorts of SIP messages in that they carry application information, and the size and rate of the INFO message is directly determined by the application. This can cause application information traffic to interfere with other traffic on that infrastructure, or to self-interfere when data rates become too high. "A designer of an INFO package, and the application that uses it, need to consider the impact that the size and the rate of the INFO messages have on the network and on other traffic, since it normally cannot be ensured that INFO messages will be carried over a congestion-controlled transport protocol end-to-end. Even if an INFO message is sent over a such a transport protocol, a downstream SIP entity might forward the message over a transport protocol that does not provide congestion control. "Therefore, an application SHOULD generally have at most one outstanding INFO message. The guidelines in RFC3261 Section 18 MUST be followed for sending and receiving INFO requests and responses, such as the guideline to not exceed messages sizes of 1300 bytes when the path MTU is unknown. RFC5405 provides additional guidelines for applications using the User Datagram Protocol (UDP) that may be useful background reading." Thanks. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From brett@broadsoft.com Sat May 1 13:00:00 2010 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 8BDBD3A6A2E for ; Sat, 1 May 2010 13:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=-1.021, 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 3Bqbwf-r3ulv for ; Sat, 1 May 2010 12:59:59 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 7E7D13A6A8D for ; Sat, 1 May 2010 12:59:59 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sat, 1 May 2010 12:59:41 -0700 From: Brett Tate To: Adam Roach , SIPCORE Date: Sat, 1 May 2010 12:58:46 -0700 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: AcrosF7OodFb4OdXQnizT6SUMCEHVAAsffaw Message-ID: <747A6506A991724FB09B129B79D5FEB6148116A280@EXMBXCLUS01.citservers.local> References: <4BDB52AB.9000507@estacado.net> In-Reply-To: <4BDB52AB.9000507@estacado.net> 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 Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 20:00:00 -0000 Within proposed section 10.9 paragraph 2, "over a such a transport" should = be "over such a transport". The following sentence from paragraph 2 potentially could be improved. How= ever it is likely good enough since I'm not currently motivated enough to p= ropose alternative wording. "The guidelines in RFC3261 Section 18 MUST be followed for sending and rece= iving INFO requests and responses, such as the guideline to not exceed mess= ages sizes of 1300 bytes when the path MTU is unknown." Concerning the above sentence... since the INFO draft is built upon RFC3261= , there is little reason to indicate that the guidelines in RFC3261 Section= 18 MUST be followed; the draft is not upgrading/adjusting any of the norma= tive and non normative text from section 18. Concerning the referenced gui= deline, section 18 also has an additional guideline conflicting with the re= ference guideline (i.e. upon failure to successfully switch away from UDP, = the large request SHOULD still be sent over UDP). Thanks, Brett From keith.drage@alcatel-lucent.com Sat May 1 17:38:33 2010 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 C02B23A6829 for ; Sat, 1 May 2010 17:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.04 X-Spam-Level: X-Spam-Status: No, score=-4.04 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_50=0.001, 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 eXYJeBIYJ-hg for ; Sat, 1 May 2010 17:38:32 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 6A9D23A68B0 for ; Sat, 1 May 2010 17:38:05 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o420arrJ021383 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 2 May 2010 02:36:54 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 2 May 2010 02:36:53 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , SIPCORE Date: Sun, 2 May 2010 02:36:51 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: AcrosGDDwXiUbSVIR82oeEZV8srIsQA3lwhQ Message-ID: References: <4BDB52AB.9000507@estacado.net> In-Reply-To: <4BDB52AB.9000507@estacado.net> 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.64 on 155.132.188.13 Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 00:38:33 -0000 I have significant issues with the third proposed paragraph. > "Therefore, an application SHOULD generally have at most=20 > one outstanding INFO message. This sentence does not solve the problem of congestion, which is the ethos = for adding the text. All it does is impose limitations on implementations t= hat are unnecessary. I would claim that I can impose congestion on the netw= ork by poor design of INFO packages even without this limitation, whereas c= areful use of INFO with multiple overlapping sends does not cause congestio= n. Therefore I do not accept this sentence. > The guidelines in RFC3261 Section 18 MUST be followed=20 > for sending and receiving INFO > requests and responses, such as the guideline to not=20 > exceed messages > sizes of 1300 bytes when the path MTU is unknown.=20 > RFC5405 provides > additional guidelines for applications using the User Datagram > Protocol (UDP) that may be useful background reading." The MUST here is superfluous. By all means draw our attention to the text i= n RFC 3261, which already contains a MUST. But if people are really going t= o ignore RFC 3261, then they will also ignore the MUST here. There are lots= of other MUSTs in RFC 3261 it is equally important for an INFO implementat= ion to follow, and we get nowhere by repeating them all. I would suggest th= at rather than the text here, you merely informatively introduce a quote fr= om RFC 3261 of the relevant text. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, April 30, 2010 10:59 PM > To: SIPCORE > Subject: [sipcore] Call for Consensus: INFO Specification and=20 > Congestion >=20 > [as chair] >=20 > During IESG review of the INFO specification, several members=20 > expressed concerns about the congestion properties of INFO.=20 > The draft authors and IESG worked together to craft text that=20 > satisfies these concerns. >=20 > Since the resulting text contains normative language, we are=20 > bringing the proposal to the SIPCORE working group for a=20 > 2-week consensus call.=20 > Please comment on the following proposed text before Friday,=20 > May 14th.=20 > If you agree with the proposal, please send a short response=20 > indicating that fact. >=20 > "10.9. Rate and size of INFO Requests >=20 > "INFO messages differ from many other sorts of SIP=20 > messages in that > they carry application information, and the size and rate of the > INFO message is directly determined by the application. This can > cause application information traffic to interfere with=20 > other traffic > on that infrastructure, or to self-interfere when data=20 > rates become > too high. >=20 > "A designer of an INFO package, and the application that uses it, > need to consider the impact that the size and the rate=20 > of the INFO > messages have on the network and on other traffic,=20 > since it normally > cannot be ensured that INFO messages will be carried over a > congestion-controlled transport protocol end-to-end. Even if an > INFO message is sent over a such a transport protocol,=20 > a downstream > SIP entity might forward the message over a transport=20 > protocol that > does not provide congestion control. >=20 > "Therefore, an application SHOULD generally have at most=20 > one outstanding INFO message. > The guidelines in RFC3261 Section 18 MUST be followed=20 > for sending and receiving INFO > requests and responses, such as the guideline to not=20 > exceed messages > sizes of 1300 bytes when the path MTU is unknown.=20 > RFC5405 provides > additional guidelines for applications using the User Datagram > Protocol (UDP) that may be useful background reading." >=20 > Thanks. >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Sun May 2 01:00:24 2010 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 CD8493A6974 for ; Sun, 2 May 2010 01:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_40=-0.185, 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 5VvoguAmVn8k for ; Sun, 2 May 2010 01:00:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B94DA3A67FD for ; Sun, 2 May 2010 01:00:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-7c-4bdd3106a796 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 47.6B.08537.6013DDB4; Sun, 2 May 2010 10:00:07 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sun, 2 May 2010 10:00:06 +0200 From: Christer Holmberg To: Brett Tate , Adam Roach , SIPCORE Date: Sun, 2 May 2010 09:57:50 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: AcrosF7OodFb4OdXQnizT6SUMCEHVAAsffawABq0urU= Message-ID: References: <4BDB52AB.9000507@estacado.net>, <747A6506A991724FB09B129B79D5FEB6148116A280@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB6148116A280@EXMBXCLUS01.citservers.local> 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-Brightmail-Tracker: AAAAAA== Cc: "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 08:00:24 -0000 Hi, I am adding Lars Eggert to the discussion, since he had most issues with th= is in IESG. >Within proposed section 10.9 paragraph 2, "over a such a transport" should= be "over such a transport". Correct. >The following sentence from paragraph 2 potentially could be improved. Ho= wever it is likely good enough since I'm not currently motivated enough to = propose alternative wording. > >"The guidelines in RFC3261 Section 18 MUST be followed for sending and rec= eiving INFO requests and responses, such as the guideline to not exceed mes= sages sizes of 1300 bytes when the path MTU is unknown." > >Concerning the above sentence... since the INFO draft is built upon RFC326= 1, there is little reason to indicate that the guidelines in RFC3261 Sectio= n 18 MUST be followed; the draft is not upgrading/adjusting any of the norm= ative and non normative text from section 18. =20 >Concerning the referenced guideline, section 18 also has an additional gui= deline conflicting with the reference guideline (i.e. upon failure to succe= ssfully switch away from UDP, the large request SHOULD still be sent over U= DP). Keith had similar comments, so I suggest we discuss it in that thread. Thanks! Regards, Christer= From christer.holmberg@ericsson.com Sun May 2 01:03:39 2010 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 B5C5B3A6946 for ; Sun, 2 May 2010 01:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=-1.623, BAYES_20=-0.74] 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 vkJjTptmm2tM for ; Sun, 2 May 2010 01:03:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 742373A69B6 for ; Sun, 2 May 2010 01:03:37 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-95-4bdd31c8c57a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5A.0E.21861.8C13DDB4; Sun, 2 May 2010 10:03:20 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 2 May 2010 10:03:20 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Adam Roach , SIPCORE Date: Sun, 2 May 2010 10:00:14 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: AcrosGDDwXiUbSVIR82oeEZV8srIsQA3lwhQAA+wo/k= Message-ID: References: <4BDB52AB.9000507@estacado.net>, 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-Brightmail-Tracker: AAAAAA== Cc: "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 08:03:39 -0000 Hi Keith, I am adding Lars Eggert to the discussion, since he had most issues with th= is in IESG. >I have significant issues with the third proposed paragraph. > >"Therefore, an application SHOULD generally have at most one outstanding I= NFO message. > >This sentence does not solve the problem of congestion, which is the ethos= for adding the text. All it does is >impose limitations on implementations= that are unnecessary. I would claim that I can impose congestion on the >n= etwork by poor design of INFO packages even without this limitation, wherea= s careful use of INFO with >multiple overlapping sends does not cause conge= stion. Therefore I do not accept this sentence. I'll let Lars comment on this. >>The guidelines in RFC3261 Section 18 MUST be followed >>for sending and receiving INFO requests and responses, such as the guidel= ine to not >>exceed messages sizes of 1300 bytes when the path MTU is unknown. >>RFC5405 provides additional guidelines for applications using the User Da= tagram >>Protocol (UDP) that may be useful background reading." > >The MUST here is superfluous. By all means draw our attention to the text = in RFC 3261, which already=20 >contains a MUST. But if people are really going to ignore RFC 3261, then t= hey will also ignore the MUST=20 >here. There are lots of other MUSTs in RFC 3261 it is equally important fo= r an INFO implementation to=20 >follow, and we get nowhere by repeating them all. I would suggest that rat= her than the text here, you merely=20 >informatively introduce a quote from RFC 3261 of the relevant text. Would you be ok if we change "Section 18 MUST be followed" to "Section 18 a= re to be followed"? Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, April 30, 2010 10:59 PM > To: SIPCORE > Subject: [sipcore] Call for Consensus: INFO Specification and > Congestion > > [as chair] > > During IESG review of the INFO specification, several members > expressed concerns about the congestion properties of INFO. > The draft authors and IESG worked together to craft text that > satisfies these concerns. > > Since the resulting text contains normative language, we are > bringing the proposal to the SIPCORE working group for a > 2-week consensus call. > Please comment on the following proposed text before Friday, > May 14th. > If you agree with the proposal, please send a short response > indicating that fact. > > "10.9. Rate and size of INFO Requests > > "INFO messages differ from many other sorts of SIP > messages in that > they carry application information, and the size and rate of the > INFO message is directly determined by the application. This can > cause application information traffic to interfere with > other traffic > on that infrastructure, or to self-interfere when data > rates become > too high. > > "A designer of an INFO package, and the application that uses it, > need to consider the impact that the size and the rate > of the INFO > messages have on the network and on other traffic, > since it normally > cannot be ensured that INFO messages will be carried over a > congestion-controlled transport protocol end-to-end. Even if an > INFO message is sent over a such a transport protocol, > a downstream > SIP entity might forward the message over a transport > protocol that > does not provide congestion control. > > "Therefore, an application SHOULD generally have at most > one outstanding INFO message. > The guidelines in RFC3261 Section 18 MUST be followed > for sending and receiving INFO > requests and responses, such as the guideline to not > exceed messages > sizes of 1300 bytes when the path MTU is unknown. > RFC5405 provides > additional guidelines for applications using the User Datagram > Protocol (UDP) that may be useful background reading." > > Thanks. > > /a > _______________________________________________ > 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 keith.drage@alcatel-lucent.com Sun May 2 04:58:36 2010 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 153AD3A68CF for ; Sun, 2 May 2010 04:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_20=-0.74, 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 Ce82P6VaTwXJ for ; Sun, 2 May 2010 04:58:34 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 98A4C3A67A7 for ; Sun, 2 May 2010 04:58:33 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o42BvkpG009569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 2 May 2010 13:57:46 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 2 May 2010 13:57:46 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Adam Roach , SIPCORE Date: Sun, 2 May 2010 13:57:42 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: AcrosGDDwXiUbSVIR82oeEZV8srIsQA3lwhQAA+wo/kAB/vzwA== Message-ID: References: <4BDB52AB.9000507@estacado.net>, 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.64 on 155.132.188.13 Cc: "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 11:58:36 -0000 > >>The guidelines in RFC3261 Section 18 MUST be followed for=20 > sending and=20 > >>receiving INFO requests and responses, such as the guideline to not=20 > >>exceed messages sizes of 1300 bytes when the path MTU is unknown. > >>RFC5405 provides additional guidelines for applications=20 > using the User=20 > >>Datagram Protocol (UDP) that may be useful background reading." > > > >The MUST here is superfluous. By all means draw our attention to the=20 > >text in RFC 3261, which already contains a MUST. But if people are=20 > >really going to ignore RFC 3261, then they will also ignore the MUST=20 > >here. There are lots of other MUSTs in RFC 3261 it is=20 > equally important=20 > >for an INFO implementation to follow, and we get nowhere by=20 > repeating them all. I would suggest that rather than the text=20 > here, you merely informatively introduce a quote from RFC=20 > 3261 of the relevant text. >=20 > Would you be ok if we change "Section 18 MUST be followed" to=20 > "Section 18 are to be followed"? That at least removes the double specification of the same MUST in two docu= ments one of which is already dependent on the other. However I would still= point out that there are lots of RFC 3261 MUSTs that I could break in an I= NFO implementation that would cause equal impact on the network. Therefore = I still consider it unnecessary. Can I further point out however that none of this text does not belong in s= ection 10, as section 10 is about what needs to be documented to define an = INFO package, not about what the implementor actually needs to do. It actua= lly relates to whether it was appropriate to select INFO in the first place= to do the job, as if the information transfer requirements are inappropria= te to the underlying transport capabilities of SIP, then INFO should not ha= ve been selected in the first place. regards Keith=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Sunday, May 02, 2010 9:00 AM > To: DRAGE, Keith (Keith); Adam Roach; SIPCORE > Cc: lars.eggert@nokia.com > Subject: RE: [sipcore] Call for Consensus: INFO Specification=20 > and Congestion >=20 > Hi Keith, >=20 > I am adding Lars Eggert to the discussion, since he had most=20 > issues with this in IESG. >=20 > >I have significant issues with the third proposed paragraph. > > > >"Therefore, an application SHOULD generally have at most one=20 > outstanding INFO message. > > > >This sentence does not solve the problem of congestion,=20 > which is the ethos for adding the text. All it does is=20 > >impose limitations on implementations that are unnecessary.=20 > I would claim that I can impose congestion on the >network by=20 > poor design of INFO packages even without this limitation,=20 > whereas careful use of INFO with >multiple overlapping sends=20 > does not cause congestion. Therefore I do not accept this sentence. >=20 > I'll let Lars comment on this. >=20 > >>The guidelines in RFC3261 Section 18 MUST be followed for=20 > sending and=20 > >>receiving INFO requests and responses, such as the guideline to not=20 > >>exceed messages sizes of 1300 bytes when the path MTU is unknown. > >>RFC5405 provides additional guidelines for applications=20 > using the User=20 > >>Datagram Protocol (UDP) that may be useful background reading." > > > >The MUST here is superfluous. By all means draw our attention to the=20 > >text in RFC 3261, which already contains a MUST. But if people are=20 > >really going to ignore RFC 3261, then they will also ignore the MUST=20 > >here. There are lots of other MUSTs in RFC 3261 it is=20 > equally important=20 > >for an INFO implementation to follow, and we get nowhere by=20 > repeating them all. I would suggest that rather than the text=20 > here, you merely informatively introduce a quote from RFC=20 > 3261 of the relevant text. >=20 > Would you be ok if we change "Section 18 MUST be followed" to=20 > "Section 18 are to be followed"? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: Friday, April 30, 2010 10:59 PM > > To: SIPCORE > > Subject: [sipcore] Call for Consensus: INFO Specification and=20 > > Congestion > > > > [as chair] > > > > During IESG review of the INFO specification, several members=20 > > expressed concerns about the congestion properties of INFO. > > The draft authors and IESG worked together to craft text that=20 > > satisfies these concerns. > > > > Since the resulting text contains normative language, we=20 > are bringing=20 > > the proposal to the SIPCORE working group for a 2-week=20 > consensus call. > > Please comment on the following proposed text before=20 > Friday, May 14th. > > If you agree with the proposal, please send a short response=20 > > indicating that fact. > > > > "10.9. Rate and size of INFO Requests > > > > "INFO messages differ from many other sorts of SIP messages in=20 > > that > > they carry application information, and the size and=20 > rate of the > > INFO message is directly determined by the=20 > application. This can > > cause application information traffic to interfere with other=20 > > traffic > > on that infrastructure, or to self-interfere when data rates=20 > > become > > too high. > > > > "A designer of an INFO package, and the application=20 > that uses it, > > need to consider the impact that the size and the rate of the=20 > > INFO > > messages have on the network and on other traffic, since it=20 > > normally > > cannot be ensured that INFO messages will be carried over a > > congestion-controlled transport protocol end-to-end.=20 > Even if an > > INFO message is sent over a such a transport protocol, a=20 > > downstream > > SIP entity might forward the message over a transport=20 > protocol=20 > > that > > does not provide congestion control. > > > > "Therefore, an application SHOULD generally have at most one=20 > > outstanding INFO message. > > The guidelines in RFC3261 Section 18 MUST be followed for=20 > > sending and receiving INFO > > requests and responses, such as the guideline to not exceed=20 > > messages > > sizes of 1300 bytes when the path MTU is unknown. > > RFC5405 provides > > additional guidelines for applications using the User Datagram > > Protocol (UDP) that may be useful background reading." > > > > Thanks. > > > > /a > > _______________________________________________ > > 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 Peter.Zehler@xerox.com Mon May 3 08:20:42 2010 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 482CA3A67F6 for ; Mon, 3 May 2010 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[AWL=1.227, BAYES_50=0.001, 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 JfYRntoJzL6m for ; Mon, 3 May 2010 08:20:37 -0700 (PDT) Received: from wbmler4.mail.xerox.com (wbmler4.mail.xerox.com [13.13.138.219]) by core3.amsl.com (Postfix) with ESMTP id 24D113A6D12 for ; Mon, 3 May 2010 08:20:35 -0700 (PDT) Received: from wbmlir1.mail.xerox.com (wbmlir1.mail.xerox.com [13.131.8.221]) by wbmler4.mail.xerox.com (8.14.2/8.13.8) with ESMTP id o43FKKZO002942 for ; Mon, 3 May 2010 11:20:20 -0400 Received: from wbmlir1.mail.xerox.com (localhost [127.0.0.1]) by wbmlir1.mail.xerox.com (8.14.2/8.13.6) with ESMTP id o43FKGjj020879 for ; Mon, 3 May 2010 11:20:16 -0400 Received: from USA7061GW002.na.xerox.net (usa7061gw002.na.xerox.net [13.151.210.15]) by wbmlir1.mail.xerox.com (8.14.2/8.13.6) with ESMTP id o43FKCMM020815 for ; Mon, 3 May 2010 11:20:16 -0400 X-XeroxINT-Source-Ip: 13.151.210.15 X-XeroxINT-Source-Name: usa7061gw002.na.xerox.net X-XeroxINT-Reported-Name: USA7061GW002.na.xerox.net Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA7061GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 May 2010 08:20:15 -0700 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_01CAEAD4.216A97A6" Date: Mon, 3 May 2010 08:20:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review request: Dial String syntax for the "tel" URI Scheme Thread-Index: Acrq1CdVxefzcLQKQaexqrq5pEjBtQ== From: "Zehler, Peter" To: X-OriginalArrivalTime: 03 May 2010 15:20:15.0016 (UTC) FILETIME=[218A5280:01CAEAD4] Subject: [sipcore] Review request: Dial String syntax for the "tel" URI Scheme 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 May 2010 15:20:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEAD4.216A97A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 This is a request for the list to review an Internet Draft that codifies the parameters for Dial Strings to be used in an rfc3966 compliant URL. The requirements for this draft originated in the IEEE/ISTO Printer Working Group (PWG) . The PWG is a consortium printer and multi-function device manufacturers, print server developers, operating system providers and print management application developers. Previous works of the PWG include the Printer MIB (rfc3805) and the Internet Printing Protocol (rfc2911, rfc2910 and others) The Working Group in the PWG that I chair is addressing the modeling of Multifunction Devices. In that effort an outbound facsimile (i.e. FaxOut) requires a way to encode Dial Strings in the URL for a destination facsimile device. =20 The draft title is "Dial String syntax for the "tel" URI Scheme" and it can be retrieved from . It proposes three "tel" URI schemes parameters that cover pre-dialing, post-dialing and T.33 subaddressing. The post-dialing and T.33 subaddressing are adopted from the now obsolete rfc2806 but updated for tfc3966 syntax. Pre-dial was created to avoid obfuscation of the resource identified by the URI. Rfc2806 allowed the pre-dial string to be included in the tel: URI. =20 In a comment on this Internet Draft on the URI Review list it was suggested that the RAI-area working groups that deals with SIP should be the place where the Dial String parameter semantics should be discussed. =20 I look forward to your comments, =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 =20 >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, April 26, 2010 4:06 PM > To: Zehler, Peter > Subject: New Version Notification for draft-zehler-teldial-info-00 >=20 >=20 > A new version of I-D, draft-zehler-teldial-info-00.txt has been successfully submitted by Peter Zehler and posted to the IETF repository. >=20 > Filename: draft-zehler-teldial-info > Revision: 00 > Title: Dial String syntax for the "tel" URI Scheme > Creation_date: 2010-04-24 > WG ID: Independent Submission > Number_of_pages: 7 >=20 > Abstract: > The "tel" URI (Uniform Resource Identifier) for Telephone Numbers=20 > [RFC3966] describes resources identified by telephone numbers. These=20 > resources specify termination points within a public or private=20 > telephone network. The termination points are a globally or locally=20 > unique endpoint. RFC3966 does not address the means by which the=20 > telephone URI can be used to reach termination point from a specific=20 > node in the telephone network. >=20 > This document specifies the means by which the termination point is=20 > reached from a specific node in the telephone network. This document=20 > specifies how to encode the numbers, symbols and pauses required to=20 > traverse the phone network to reach the termination point in an RFC > 3966 compliant "tel" URI. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 =20 =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com =20 Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 ------_=_NextPart_001_01CAEAD4.216A97A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

This is a request for the list to review an = Internet Draft that codifies the parameters for Dial Strings to be used in an rfc3966 compliant URL.  The requirements for this draft originated in the IEEE/ISTO Printer Working Group (PWG) <http://www.pwg.org>.  The PWG is a consortium printer and = multi-function device manufacturers, print server developers, operating system = providers and print management application developers.  Previous works of = the PWG include the Printer MIB (rfc3805) and the Internet Printing Protocol = (rfc2911, rfc2910 and others)  The Working Group in the PWG that I chair is addressing the modeling of Multifunction Devices.  In that effort = an outbound facsimile (i.e. FaxOut) requires a way to encode Dial Strings = in the URL for a destination facsimile device.

 

The draft title is "Dial String syntax for the "tel" URI Scheme" and it can be retrieved from <http://t= ools.ietf.org/html/draft-zehler-teldial-info-00>.   It proposes three “tel” URI schemes parameters that = cover pre-dialing, post-dialing  and T.33 subaddressing.  The = post-dialing and T.33 subaddressing are adopted from the now obsolete rfc2806 but = updated for tfc3966 syntax.  Pre-dial was created to avoid obfuscation of = the resource identified by the URI.  Rfc2806 allowed the pre-dial = string to be included in the tel: URI.

 

In a comment on this Internet Draft on the URI = Review list it was suggested that the RAI-area working groups that deals with SIP = should be the place where the Dial String parameter semantics should be = discussed. 

 

I look forward to your comments,

 

Peter Zehler


Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com<= span style=3D'color:#1F497D'>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 =

 

 

> 

> -----Original Message-----

> From: IETF I-D Submission Tool = [mailto:idsubmission@ietf.org]

> Sent: Monday, April 26, 2010 4:06 = PM

> To: Zehler, Peter

> Subject: New Version Notification for draft-zehler-teldial-info-00

> 

> 

> A new version of I-D, draft-zehler-teldial-info-00.txt has been successfully submitted by = Peter Zehler and posted to the IETF repository.

> 

> Filename:        draft-zehler-teldial-info

> Revision:       =  00

> Title:           = Dial String syntax for the "tel" URI Scheme

> Creation_date:   = 2010-04-24

> WG ID:           Independent Submission

> Number_of_pages: 7

> 

> Abstract:

> The "tel" URI (Uniform Resource Identifier) for Telephone Numbers

> [RFC3966] describes resources identified by telephone numbers.  These

> resources specify termination points within = a public or private

> telephone network. The termination points = are a globally or locally

> unique endpoint.  RFC3966 does not = address the means by which the

> telephone URI can be used to reach = termination point from a specific

> node in the telephone = network.

> 

> This document specifies the means by which = the termination point is

> reached from a specific node in the = telephone network. This document

> specifies how to encode the numbers, = symbols and pauses required to

> traverse the phone network to reach the = termination point in an RFC

> 3966 compliant "tel" = URI.

> 

> 

> 

> The IETF Secretariat.

> 

> 

 

 

 

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 =

 

------_=_NextPart_001_01CAEAD4.216A97A6-- From pkyzivat@cisco.com Mon May 3 09:29:59 2010 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 9D64C3A6910 for ; Mon, 3 May 2010 09:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.301 X-Spam-Level: X-Spam-Status: No, score=-10.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 VaurM6K-3NWB for ; Mon, 3 May 2010 09:29:58 -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 0CC6A3A68F3 for ; Mon, 3 May 2010 09:29:57 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADOW3ktAZnwM/2dsb2JhbACdInGjepkNgnSCHgQ X-IronPort-AV: E=Sophos;i="4.52,320,1270425600"; d="scan'208";a="107453077" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 May 2010 16:29:43 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o43GThWj014600; Mon, 3 May 2010 16:29:43 GMT Message-ID: <4BDEF9F6.9030908@cisco.com> Date: Mon, 03 May 2010 12:29:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Zehler, Peter" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Review request: Dial String syntax for the "tel" URI Scheme 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 May 2010 16:29:59 -0000 [with my individual hat on] Peter, I find this to be a *terrible* idea!!! This conflates the notion of a Uniform Resource *Identifier*, with that of a Uniform Resource *Locator*. Were such changes made, it would complicate the use of tel: URIs in SIP, and even of sip: URIs, since sip incorporates the telephone-subscriber syntax into its own syntax. For instance, this would confuse URI comparison. Do two URIs that differ only with regards to these new parameters compare as equal? For some purposes they should, but for others not. Also, if you have a URI containing these parameters in your address book, and share it with me, are those parameters valid for me as well? (Most likely I should strip them out, and then perhaps add others in their place.) In sip we eventually defined RFC 4967 to define a way to specify a dial string that is distinct from a tel: uri. If such things are important, I suggest that they belong in a new URI scheme. (Or some existing one different from tel:) Thanks, Paul P.S. I know there have been other parameters defined for tel: that have some of the same issues. IMO that was a mistake. Lets not do it again. Zehler, Peter wrote: > All, > > > > This is a request for the list to review an Internet Draft that codifies > the parameters for Dial Strings to be used in an rfc3966 compliant URL. > The requirements for this draft originated in the IEEE/ISTO Printer > Working Group (PWG) . The PWG is a consortium > printer and multi-function device manufacturers, print server > developers, operating system providers and print management application > developers. Previous works of the PWG include the Printer MIB (rfc3805) > and the Internet Printing Protocol (rfc2911, rfc2910 and others) The > Working Group in the PWG that I chair is addressing the modeling of > Multifunction Devices. In that effort an outbound facsimile (i.e. > FaxOut) requires a way to encode Dial Strings in the URL for a > destination facsimile device. > > > > The draft title is "Dial String syntax for the "tel" URI Scheme" and it > can be retrieved from > . It proposes > three “tel” URI schemes parameters that cover pre-dialing, post-dialing > and T.33 subaddressing. The post-dialing and T.33 subaddressing are > adopted from the now obsolete rfc2806 but updated for tfc3966 syntax. > Pre-dial was created to avoid obfuscation of the resource identified by > the URI. Rfc2806 allowed the pre-dial string to be included in the tel: > URI. > > > > In a comment on this Internet Draft on the URI Review list it was > suggested that the RAI-area working groups that deals with SIP should be > the place where the Dial String parameter semantics should be discussed. > > > > I look forward to your comments, > > > > Peter Zehler > > > Xerox Research Center Webster > Email: Peter.Zehler@Xerox.com > Voice: (585) 265-8755 > FAX: (585) 265-7441 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > > > > > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: Monday, April 26, 2010 4:06 PM > > > To: Zehler, Peter > > > Subject: New Version Notification for draft-zehler-teldial-info-00 > > > > > > > > > A new version of I-D, draft-zehler-teldial-info-00.txt has been > successfully submitted by Peter Zehler and posted to the IETF repository. > > > > > > Filename: draft-zehler-teldial-info > > > Revision: 00 > > > Title: Dial String syntax for the "tel" URI Scheme > > > Creation_date: 2010-04-24 > > > WG ID: Independent Submission > > > Number_of_pages: 7 > > > > > > Abstract: > > > The "tel" URI (Uniform Resource Identifier) for Telephone Numbers > > > [RFC3966] describes resources identified by telephone numbers. These > > > resources specify termination points within a public or private > > > telephone network. The termination points are a globally or locally > > > unique endpoint. RFC3966 does not address the means by which the > > > telephone URI can be used to reach termination point from a specific > > > node in the telephone network. > > > > > > This document specifies the means by which the termination point is > > > reached from a specific node in the telephone network. This document > > > specifies how to encode the numbers, symbols and pauses required to > > > traverse the phone network to reach the termination point in an RFC > > > 3966 compliant "tel" URI. > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > > > Peter Zehler > > Xerox Research Center Webster > Email: Peter.Zehler@Xerox.com > Voice: (585) 265-8755 > FAX: (585) 265-7441 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dworley@avaya.com Mon May 3 10:58:25 2010 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 EC6F53A6976 for ; Mon, 3 May 2010 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, 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 Ju-k2ZQwZbL3 for ; Mon, 3 May 2010 10:58:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 542993A68BD for ; Mon, 3 May 2010 10:58:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,320,1270440000"; d="scan'208";a="186971446" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 May 2010 13:58:08 -0400 X-IronPort-AV: E=Sophos;i="4.52,320,1270440000"; d="scan'208";a="457243538" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 May 2010 13:58:07 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 3 May 2010 13:58:07 -0400 From: "Worley, Dale R (Dale)" To: "Zehler, Peter" , "sipcore@ietf.org" Date: Mon, 3 May 2010 13:58:05 -0400 Thread-Topic: [sipcore] Review request: Dial String syntax for the "tel" URI Scheme Thread-Index: AQHK6uouVVrRdAqLME6xY4fOBuhfDQ== 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Review request: Dial String syntax for the "tel" URI Scheme 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 May 2010 17:58:26 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Zehl= er, Peter [Peter.Zehler@xerox.com] The draft title is "Dial String syntax for the "tel" URI Scheme" and it can= be retrieved from . It proposes three =93tel=94 URI schemes parameters that cover pre-dial= ing, post-dialing and T.33 subaddressing. The post-dialing and T.33 subad= dressing are adopted from the now obsolete rfc2806 but updated for tfc3966 = syntax. Pre-dial was created to avoid obfuscation of the resource identifi= ed by the URI. Rfc2806 allowed the pre-dial string to be included in the t= el: URI. ________________________________________ In regard to subaddressing, this is a good idea, since the subaddressed des= tination is a descrete entity with a name that is unique within the context= of the E.164 number. In regard to "dial strings", I think this is not a good idea. A "dial stri= ng" is the specific routing from one location to one destination. It isn't= a name for the destination, and it really isn't a URL, as there is the imp= lication that a URL is globally valid. What you are attempting to do is cr= eate a URL-like string which is the dialing instructions to reach a particu= lar destination from a particular origin and which also makes explicit the = E.164 address of the destination. It has no portability at all. Also, the commonest transformation that is applied to convert E.164 numbers= to dial strings is the removal of the country and city codes from the begi= nning of the E.164 number, and the draft has no mechanism for specifying th= at. I think a better approach would be to see if the context concept of RFC 396= 6 solves the problem, that is, the device which is acting on the tel URI sh= ould be provisioned with an appropriate converstion table from telephone nu= mbers to dialing actions. If you really need to transport a string of dialing instructions from one e= lement to another, it would be much safer to define a new namespace. E.g.,= "dial:w9w01118005551212". Dale From fluffy@cisco.com Tue May 4 11:54:51 2010 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 BB22928C31E for ; Tue, 4 May 2010 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.965 X-Spam-Level: X-Spam-Status: No, score=-109.965 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, 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 5OMjE+-CcYGt for ; Tue, 4 May 2010 11:54:51 -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 BF49C3A6ABB for ; Tue, 4 May 2010 11:45:40 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4FAM4H4EurRN+K/2dsb2JhbAAtkGCMI3GkWJlvhRMEgz4 X-IronPort-AV: E=Sophos;i="4.52,328,1270425600"; d="scan'208";a="524893431" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 04 May 2010 18:45:27 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o44IjJOC026448 for ; Tue, 4 May 2010 18:45:27 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 4 May 2010 09:01:32 -0600 Message-Id: To: sipcore@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [sipcore] Option tag problem ... 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 May 2010 18:54:51 -0000 There's been lots of discussion around changing the option tag = registration process but I'm unclear on what the problem is we are = trying to solve. Are there some concrete examples folks can bring up = form the past where we would have a better interoperability situations = today if we changed this? I'm not saying there is not a problem, I just = think we need to get clear about what we are trying to fix before we are = going to be able to figure out how to fix it.=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From paulej@packetizer.com Tue May 4 16:46:16 2010 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 C3D173A6B24 for ; Tue, 4 May 2010 16:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=-0.849, 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 tbdfSY5xVLbp for ; Tue, 4 May 2010 16:46:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id C769428C16F for ; Tue, 4 May 2010 16:37:44 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o44NbKv8029124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 May 2010 19:37:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273016246; bh=MXhxUsHtzT29ZBFGVRKSXItEio45CSCzjiHn+I3JbuY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=F31AcPfBlC4mQKQO83VvUmSL71+Fe+nWREaqiyDw4yR52j/epOm324xPWWKwQGZfY 6J9bqF+1DRIjFqoHUwRzef/zuj6PD7L/BAq4mEP5WpXu5UTfj1TP8rmZeJzQRlYGkq JdldmeHczdY6pux7lZWMznb5ro6Rkk1Agt9o8EE4= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o44NbJvN023848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 May 2010 19:37:19 -0400 From: "Paul E. Jones" To: "'Cullen Jennings'" References: <020801cae802$07b56ef0$17204cd0$@com> In-Reply-To: Date: Tue, 4 May 2010 19:37:04 -0400 Message-ID: <013b01caebe2$b43c08d0$1cb41a70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcromniiBo1q2JVvQy61uuGdcfOzygDOsMxw Content-Language: en-us Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] SIP OPTIONS "ping" 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 May 2010 23:46:16 -0000 Cullen, Problem Statement: Recognizing that if a SIP entity does not know the basic operational state of a peer device, there is a risk of delays in delivering service and weakened ability for administrators to correct service issues. Further recognizing that SIP specifies the use of OPTIONS as a means of determining the basic state of a UAS, but RFC 3261's description of the usage is shallow and does not lend itself to interoperability, resulting in a wide variety of implementations of OPTIONS for this purpose. Proposed Solution: Define procedures for using the current OPTIONS method defined in RFC 3261 in a way that improves interoperability and lends to consistent implementation when used to determine the operational status of peer SIP entities so as to reduce delays, improve overall operational efficiency, and provide reliable/useful operational status information to administrators. Paul > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Friday, April 30, 2010 3:21 PM > To: Paul E. Jones > Cc: 'Michael Miller'; sipcore@ietf.org; 'Hadriel Kaplan' > Subject: Re: [sipcore] SIP OPTIONS "ping" > > > Thanks for the reset. > > I think the reasons this thread has been so unproductive is we are > unclear on what the problem is we are trying to solve. "We need a way > to do PING" is not a problem. It is a solution to some problem. If the > problem is figure out which of multiple next hops to use based on load > balancing and if the hop is dead or alive, well the PING approach here > will fail miserably (see the overload discussion and simulations) and > we have WG going to the IESG to try and solve that problem. > > Let me make it very clear I am against the working group working on > this draft until someone can describe what the problem is. The current > draft hand waves at a few problems - does not say what it is trying to > do. Then proposes some syntax with no backing semantics that would help > solve any of the problems it mentions. > > Cullen > > On Apr 29, 2010, at 7:11 PM, Paul E. Jones wrote: > > > Guys, > > > > I decided to start this new thread, because the previous one is > proving to > > be a bit challenging to respond to. > > > > Let's back up and review where we are and what we're trying to > accomplish. > > > > Many devices today use OPTIONS as a "ping" method. The reason is > that there > > was nothing better or more appropriate for an out-of-dialog means of > > determining status of a peer SIP device. These devices include > PBXes, SBCs, > > etc. > > > > The problems are: > > 1) Response codes vary from one device to another (e.g., 600 vs. 503 > vs. > > 486) > > 2) Nowhere is it documented that an OPTIONS can be used as an > > application-level "ping" > > > > Taking note of the current state of affairs and desiring to improve > it > > without changing SIP in any significant way, we prepared the OPTIONS > "ping" > > draft. > > > > Is it a ping message or not? The thread has focused heavily on the > contents > > of the message, but we're not proposing changes to the contents of a > > message. We only wish to focus on response codes: the contents of > headers > > and body were not subject to change. > > > > We proposed sending OPTIONS "ping" messages to the IP address of the > peer > > device with a request URI of "sip:hostport" since that seemed most > logical > > to us. Christer pointed out that that's the address used when > addressing a > > SIP proxy server. I think that's OK, since we're not suggesting that > the > > proxy server actually alter its behavior. That said, we would like > to > > propose use of 503 to indicate that the device is overloaded, rather > than > > 600: that's what RFC 3261 says. But, note that we're not saying a 600 > is > > illegal if that were the appropriate code -- it just isn't in this > case. > > > > We also expect this to be used only between two devices that agree to > do so. > > The interval for messages I also wanted to keep locally configured. > > > > It might be useful to indicate that the message was a "ping" -- I > have no > > objection. But, I would not implement a different code path, > personally. > > That's why I felt it wasn't terribly important to include. > > > > If we do nothing, the world will continue to use OPTIONS as they do > today. > > Introducing PING will take time to standardize and we still have to > support > > OPTIONS for a decade. So, why bother? > > > > My recommendation is that we not boil the ocean and try to create the > most > > architecturally pure solution. Let's recognize the use of OPTIONS in > this > > way as legitimate, keep it peer-to-peer (maxforward=1), recommend > response > > codes, and expect a locally provisioned usage policy (e.g., message > > frequency). > > > > I've captured the groups' comments in this draft, though I'd like to > > reinstate the paragraph relating to the SIP Request URI > (sip:hostport): > > http://hive.packetizer.com/users/paulej/internet-drafts/pre-draft- > jones-sip- > > options-ping-01.pdf > > > > In any case, I'll go along with whatever the group wishes to do. > > > > Paul > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From Madhubabu@veraznet.com Tue May 4 17:49:28 2010 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 EFF093A693F for ; Tue, 4 May 2010 17:49:28 -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 ViV+mpHYiSK5 for ; Tue, 4 May 2010 17:49:28 -0700 (PDT) Received: from edge.us.veraznetworks.com (edge.veraznet.com [198.87.49.151]) by core3.amsl.com (Postfix) with ESMTP id 53F793A6922 for ; Tue, 4 May 2010 17:49:28 -0700 (PDT) Received: from vrzus-hub01.us.veraznetworks.com (198.87.49.3) by edge.us.veraznetworks.com (198.87.49.151) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 4 May 2010 17:34:55 -0700 Received: from SJ-EXCH2K7.us.veraznetworks.com ([10.6.0.14]) by vrzus-hub01.us.veraznetworks.com ([10.6.0.45]) with mapi; Tue, 4 May 2010 17:49:13 -0700 From: Madhubabu Brahmanapally To: "sipcore@ietf.org" Date: Tue, 4 May 2010 17:49:13 -0700 Thread-Topic: Update to RFC5407 Thread-Index: Acrr7Mf+TEiMvwQcRpKYeg0jbMJtpw== Message-ID: <7A999C3D057A7A438B6880174FC3778B2139C535BB@SJ-EXCH2K7.us.veraznetworks.com> 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_7A999C3D057A7A438B6880174FC3778B2139C535BBSJEXCH2K7usve_" MIME-Version: 1.0 Subject: [sipcore] Update to RFC5407 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 May 2010 00:53:19 -0000 --_000_7A999C3D057A7A438B6880174FC3778B2139C535BBSJEXCH2K7usve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Are there any work/draft available for updates of RFC5407 for Race conditio= ns or best practices? Regards Madhubabu --_000_7A999C3D057A7A438B6880174FC3778B2139C535BBSJEXCH2K7usve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Are there any work/draft available for updates of RFC540= 7 for Race conditions or best practices?

 

Regards

Madhubabu

--_000_7A999C3D057A7A438B6880174FC3778B2139C535BBSJEXCH2K7usve_-- From paulej@packetizer.com Tue May 4 21:49:39 2010 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 58A3E3A686E for ; Tue, 4 May 2010 21:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, J_CHICKENPOX_38=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 OF+yaLOGuX7s for ; Tue, 4 May 2010 21:49:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 28F773A68A8 for ; Tue, 4 May 2010 21:49:38 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o454nJQg016743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 May 2010 00:49:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273034964; bh=SfZzT7OGSXNVFSgJCq+wKA3cL3TeT2ZCOZOdr4DU95w=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=pYtHX1duJZgg/6FPKOZ2DmDCIaEoLFCaOE/j1yh8BaTyWwjPtyC+ya+D9VaTV0gHD qYX5APq3UpnGDIsM69vIEQ2O14QsthmTe9IAqNDRLp78qqHRh0//O7pgxO/FnBknlz EpvqLigC6bNSNVx29HujO4zGl2C7KtfB3oKqshTE= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o454nIdI024388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 May 2010 00:49:18 -0400 From: "Paul E. Jones" To: Date: Wed, 5 May 2010 00:49:02 -0400 Message-ID: <01c501caec0e$48e624e0$dab26ea0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrsDkjOK5ef9FFUTOq6bfZWNHVcxg== Content-Language: en-us Subject: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 04:49:39 -0000 Folks, I posted a revised version of the OPTIONS "ping" draft with changes as per our discussions. One change I made was that I re-instated the paragraph related to addressing, saying OPTIONS "should" be addressed to sip:hostport. I'm still willing to consider removing that entirely if that's preferred, but I recall that Hadriel preferred to have something that one could generally assume to be the proper address. As a means of querying UAS status, I think that's a reasonable choice. Anyway, I welcome comments on the draft. Paul From christer.holmberg@ericsson.com Tue May 4 22:29:01 2010 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 A48E128C199 for ; Tue, 4 May 2010 22:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.972 X-Spam-Level: X-Spam-Status: No, score=-2.972 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, J_CHICKENPOX_38=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 2IlEcYakksHa for ; Tue, 4 May 2010 22:29:00 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B40E828C173 for ; Tue, 4 May 2010 22:20:37 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-a2-4be10016e239 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EB.99.21861.61001EB4; Wed, 5 May 2010 07:20:22 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 5 May 2010 07:20:22 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.40]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 5 May 2010 07:20:21 +0200 From: Christer Holmberg To: "Paul E. Jones" , "sipcore@ietf.org" Date: Wed, 5 May 2010 07:20:19 +0200 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrsDkjOK5ef9FFUTOq6bfZWNHVcxgABA26w Message-ID: References: <01c501caec0e$48e624e0$dab26ea0$@com> In-Reply-To: <01c501caec0e$48e624e0$dab26ea0$@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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 05:29:01 -0000 Hi, As said earlier, 3261 already says that OPTIONS addressed to proxies are to= use sip:hostport, so I don't think we need to say anything about that. Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones > Sent: 5. toukokuuta 2010 7:49 > To: sipcore@ietf.org > Subject: [sipcore] draft-jones-sip-options-ping-01 >=20 > Folks, >=20 > I posted a revised version of the OPTIONS "ping" draft with=20 > changes as per our discussions. One change I made was that I=20 > re-instated the paragraph related to addressing, saying=20 > OPTIONS "should" be addressed to sip:hostport. > I'm still willing to consider removing that entirely if=20 > that's preferred, but I recall that Hadriel preferred to have=20 > something that one could generally assume to be the proper=20 > address. As a means of querying UAS status, I think that's a=20 > reasonable choice. >=20 > Anyway, I welcome comments on the draft. >=20 > Paul >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From john.elwell@siemens-enterprise.com Wed May 5 05:55:02 2010 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 09FF028C0DD for ; Wed, 5 May 2010 05:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_20=-0.74] 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 CSwPjijvfSD7 for ; Wed, 5 May 2010 05:55:00 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 610643A6B7C for ; Wed, 5 May 2010 05:54:58 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-66988; Wed, 5 May 2010 14:54:43 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B88351EB82AE; Wed, 5 May 2010 14:54:43 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 5 May 2010 14:54:43 +0200 From: "Elwell, John" To: "Paul E. Jones" , 'Cullen Jennings' Date: Wed, 5 May 2010 14:54:41 +0200 Thread-Topic: [sipcore] SIP OPTIONS "ping" Thread-Index: AcromniiBo1q2JVvQy61uuGdcfOzygDOsMxwAB8bIaA= Message-ID: References: <020801cae802$07b56ef0$17204cd0$@com> <013b01caebe2$b43c08d0$1cb41a70$@com> In-Reply-To: <013b01caebe2$b43c08d0$1cb41a70$@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 Cc: 'Michael Miller' , "sipcore@ietf.org" , 'Hadriel Kaplan' Subject: Re: [sipcore] SIP OPTIONS "ping" 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 May 2010 12:55:02 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones > Sent: 05 May 2010 00:37 > To: 'Cullen Jennings' > Cc: 'Michael Miller'; sipcore@ietf.org; 'Hadriel Kaplan' > Subject: Re: [sipcore] SIP OPTIONS "ping" >=20 > Cullen, >=20 > Problem Statement: >=20 > Recognizing that if a SIP entity does not know the basic=20 > operational state > of a peer device, there is a risk of delays in delivering service and > weakened ability for administrators to correct service issues. [JRE] To a first approximation, a 2xx versus a 4xx/5xx/6xx should tell you = the basic operational state of the responder. So we need more precise infor= mation on what is broken. John >=20 > Further recognizing that SIP specifies the use of OPTIONS as=20 > a means of > determining the basic state of a UAS, but RFC 3261's=20 > description of the > usage is shallow and does not lend itself to=20 > interoperability, resulting in > a wide variety of implementations of OPTIONS for this purpose.=20 >=20 > Proposed Solution: >=20 > Define procedures for using the current OPTIONS method=20 > defined in RFC 3261 > in a way that improves interoperability and lends to consistent > implementation when used to determine the operational status=20 > of peer SIP > entities so as to reduce delays, improve overall operational=20 > efficiency, and > provide reliable/useful operational status information to=20 > administrators. >=20 > Paul >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of Cullen Jennings > > Sent: Friday, April 30, 2010 3:21 PM > > To: Paul E. Jones > > Cc: 'Michael Miller'; sipcore@ietf.org; 'Hadriel Kaplan' > > Subject: Re: [sipcore] SIP OPTIONS "ping" > >=20 > >=20 > > Thanks for the reset. > >=20 > > I think the reasons this thread has been so unproductive is we are > > unclear on what the problem is we are trying to solve. "We=20 > need a way > > to do PING" is not a problem. It is a solution to some=20 > problem. If the > > problem is figure out which of multiple next hops to use=20 > based on load > > balancing and if the hop is dead or alive, well the PING=20 > approach here > > will fail miserably (see the overload discussion and=20 > simulations) and > > we have WG going to the IESG to try and solve that problem. > >=20 > > Let me make it very clear I am against the working group working on > > this draft until someone can describe what the problem is.=20 > The current > > draft hand waves at a few problems - does not say what it=20 > is trying to > > do. Then proposes some syntax with no backing semantics=20 > that would help > > solve any of the problems it mentions. > >=20 > > Cullen > >=20 > > On Apr 29, 2010, at 7:11 PM, Paul E. Jones wrote: > >=20 > > > Guys, > > > > > > I decided to start this new thread, because the previous one is > > proving to > > > be a bit challenging to respond to. > > > > > > Let's back up and review where we are and what we're trying to > > accomplish. > > > > > > Many devices today use OPTIONS as a "ping" method. The reason is > > that there > > > was nothing better or more appropriate for an=20 > out-of-dialog means of > > > determining status of a peer SIP device. These devices include > > PBXes, SBCs, > > > etc. > > > > > > The problems are: > > > 1) Response codes vary from one device to another (e.g.,=20 > 600 vs. 503 > > vs. > > > 486) > > > 2) Nowhere is it documented that an OPTIONS can be used as an > > > application-level "ping" > > > > > > Taking note of the current state of affairs and desiring=20 > to improve > > it > > > without changing SIP in any significant way, we prepared=20 > the OPTIONS > > "ping" > > > draft. > > > > > > Is it a ping message or not? The thread has focused=20 > heavily on the > > contents > > > of the message, but we're not proposing changes to the=20 > contents of a > > > message. We only wish to focus on response codes: the contents of > > headers > > > and body were not subject to change. > > > > > > We proposed sending OPTIONS "ping" messages to the IP=20 > address of the > > peer > > > device with a request URI of "sip:hostport" since that seemed most > > logical > > > to us. Christer pointed out that that's the address used when > > addressing a > > > SIP proxy server. I think that's OK, since we're not=20 > suggesting that > > the > > > proxy server actually alter its behavior. That said, we=20 > would like > > to > > > propose use of 503 to indicate that the device is=20 > overloaded, rather > > than > > > 600: that's what RFC 3261 says. But, note that we're not=20 > saying a 600 > > is > > > illegal if that were the appropriate code -- it just isn't in this > > case. > > > > > > We also expect this to be used only between two devices=20 > that agree to > > do so. > > > The interval for messages I also wanted to keep locally=20 > configured. > > > > > > It might be useful to indicate that the message was a "ping" -- I > > have no > > > objection. But, I would not implement a different code path, > > personally. > > > That's why I felt it wasn't terribly important to include. > > > > > > If we do nothing, the world will continue to use OPTIONS=20 > as they do > > today. > > > Introducing PING will take time to standardize and we=20 > still have to > > support > > > OPTIONS for a decade. So, why bother? > > > > > > My recommendation is that we not boil the ocean and try=20 > to create the > > most > > > architecturally pure solution. Let's recognize the use=20 > of OPTIONS in > > this > > > way as legitimate, keep it peer-to-peer (maxforward=3D1), recommend > > response > > > codes, and expect a locally provisioned usage policy=20 > (e.g., message > > > frequency). > > > > > > I've captured the groups' comments in this draft, though=20 > I'd like to > > > reinstate the paragraph relating to the SIP Request URI > > (sip:hostport): > > > http://hive.packetizer.com/users/paulej/internet-drafts/pre-draft- > > jones-sip- > > > options-ping-01.pdf > > > > > > In any case, I'll go along with whatever the group wishes to do. > > > > > > Paul > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > >=20 > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >=20 > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Wed May 5 06:28:58 2010 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 197E228C0E3 for ; Wed, 5 May 2010 06:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-1.967, 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 1YU9WrH0hBah for ; Wed, 5 May 2010 06:28:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 32C9E3A6BF7 for ; Wed, 5 May 2010 06:28:55 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-7e-4be172897e89 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F5.8E.21861.98271EB4; Wed, 5 May 2010 15:28:41 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 5 May 2010 15:28:40 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.40]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 5 May 2010 15:28:40 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Adam Roach , SIPCORE Date: Wed, 5 May 2010 15:28:39 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: AcrosGDDwXiUbSVIR82oeEZV8srIsQA3lwhQAA+wo/kAB/vzwACaE3Lw Message-ID: References: <4BDB52AB.9000507@estacado.net>, 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-Brightmail-Tracker: AAAAAA== Cc: "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 13:28:58 -0000 Hi,=20 >>>>The guidelines in RFC3261 Section 18 MUST be followed for sending and >>>>receiving INFO requests and responses, such as the guideline to not=20 >>>>exceed messages sizes of 1300 bytes when the path MTU is unknown. >>>>RFC5405 provides additional guidelines for applications using the User >>>>Datagram Protocol (UDP) that may be useful background reading." >>> >>>The MUST here is superfluous. By all means draw our attention to the=20 >>>text in RFC 3261, which already contains a MUST. But if people are=20 >>>really going to ignore RFC 3261, then they will also ignore the MUST=20 >>>here. There are lots of other MUSTs in RFC 3261 it is equally important >>>for an INFO implementation to follow, and we get nowhere by repeating th= em all.=20 >>>I would suggest that rather than the text here, you merely informatively= =20 >>>introduce a quote from RFC 3261 of the relevant text. >>=20 >>Would you be ok if we change "Section 18 MUST be followed" to "Section=20 >>18 are to be followed"? >=20 >That at least removes the double specification of the same=20 >MUST in two documents one of which is already dependent on=20 >the other. However I would still point out that there are=20 >lots of RFC 3261 MUSTs that I could break in an INFO=20 >implementation that would cause equal impact on the network.=20 >Therefore I still consider it unnecessary. >=20 >Can I further point out however that none of this text does=20 >not belong in section 10, as section 10 is about what needs=20 >to be documented to define an INFO package, not about what=20 >the implementor actually needs to do. It actually relates to=20 >whether it was appropriate to select INFO in the first place=20 >to do the job, as if the information transfer requirements=20 >are inappropriate to the underlying transport capabilities of=20 >SIP, then INFO should not have been selected in the first place. So, I guess it should be somewhere in section 7.4. Regards, Christer =20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Sunday, May 02, 2010 9:00 AM > > To: DRAGE, Keith (Keith); Adam Roach; SIPCORE > > Cc: lars.eggert@nokia.com > > Subject: RE: [sipcore] Call for Consensus: INFO Specification and=20 > > Congestion > >=20 > > Hi Keith, > >=20 > > I am adding Lars Eggert to the discussion, since he had most issues=20 > > with this in IESG. > >=20 > > >I have significant issues with the third proposed paragraph. > > > > > >"Therefore, an application SHOULD generally have at most one > > outstanding INFO message. > > > > > >This sentence does not solve the problem of congestion, > > which is the ethos for adding the text. All it does is > > >impose limitations on implementations that are unnecessary.=20 > > I would claim that I can impose congestion on the >network by poor=20 > > design of INFO packages even without this limitation,=20 > whereas careful=20 > > use of INFO with >multiple overlapping sends does not cause=20 > > congestion. Therefore I do not accept this sentence. > >=20 > > I'll let Lars comment on this. > >=20 > > >>The guidelines in RFC3261 Section 18 MUST be followed for > > sending and > > >>receiving INFO requests and responses, such as the=20 > guideline to not=20 > > >>exceed messages sizes of 1300 bytes when the path MTU is unknown. > > >>RFC5405 provides additional guidelines for applications > > using the User > > >>Datagram Protocol (UDP) that may be useful background reading." > > > > > >The MUST here is superfluous. By all means draw our=20 > attention to the=20 > > >text in RFC 3261, which already contains a MUST. But if people are=20 > > >really going to ignore RFC 3261, then they will also=20 > ignore the MUST=20 > > >here. There are lots of other MUSTs in RFC 3261 it is > > equally important > > >for an INFO implementation to follow, and we get nowhere by > > repeating them all. I would suggest that rather than the text here,=20 > > you merely informatively introduce a quote from RFC > > 3261 of the relevant text. > >=20 > > Would you be ok if we change "Section 18 MUST be followed"=20 > to "Section=20 > > 18 are to be followed"? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > > > Sent: Friday, April 30, 2010 10:59 PM > > > To: SIPCORE > > > Subject: [sipcore] Call for Consensus: INFO Specification and=20 > > > Congestion > > > > > > [as chair] > > > > > > During IESG review of the INFO specification, several members=20 > > > expressed concerns about the congestion properties of INFO. > > > The draft authors and IESG worked together to craft text that=20 > > > satisfies these concerns. > > > > > > Since the resulting text contains normative language, we > > are bringing > > > the proposal to the SIPCORE working group for a 2-week > > consensus call. > > > Please comment on the following proposed text before > > Friday, May 14th. > > > If you agree with the proposal, please send a short response=20 > > > indicating that fact. > > > > > > "10.9. Rate and size of INFO Requests > > > > > > "INFO messages differ from many other sorts of SIP=20 > messages in=20 > > > that > > > they carry application information, and the size and > > rate of the > > > INFO message is directly determined by the > > application. This can > > > cause application information traffic to interfere=20 > with other=20 > > > traffic > > > on that infrastructure, or to self-interfere when=20 > data rates=20 > > > become > > > too high. > > > > > > "A designer of an INFO package, and the application > > that uses it, > > > need to consider the impact that the size and the=20 > rate of the=20 > > > INFO > > > messages have on the network and on other traffic, since it=20 > > > normally > > > cannot be ensured that INFO messages will be carried over a > > > congestion-controlled transport protocol end-to-end.=20 > > Even if an > > > INFO message is sent over a such a transport protocol, a=20 > > > downstream > > > SIP entity might forward the message over a transport > > protocol > > > that > > > does not provide congestion control. > > > > > > "Therefore, an application SHOULD generally have at most one=20 > > > outstanding INFO message. > > > The guidelines in RFC3261 Section 18 MUST be followed for=20 > > > sending and receiving INFO > > > requests and responses, such as the guideline to not exceed=20 > > > messages > > > sizes of 1300 bytes when the path MTU is unknown. > > > RFC5405 provides > > > additional guidelines for applications using the=20 > User Datagram > > > Protocol (UDP) that may be useful background reading." > > > > > > Thanks. > > > > > > /a > > > _______________________________________________ > > > 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 keith.drage@alcatel-lucent.com Wed May 5 06:46:11 2010 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 5BBC628C0D8 for ; Wed, 5 May 2010 06:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=-1.814, BAYES_05=-1.11, 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 Vd3EiPsxG5Ia for ; Wed, 5 May 2010 06:46:10 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 57EF33A6949 for ; Wed, 5 May 2010 06:46:07 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o45DjMdo027475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 May 2010 15:45:22 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 5 May 2010 15:45:22 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Adam Roach , SIPCORE Date: Wed, 5 May 2010 15:45:21 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: AcrosGDDwXiUbSVIR82oeEZV8srIsQA3lwhQAA+wo/kAB/vzwACaE3LwAADdYTA= Message-ID: References: <4BDB52AB.9000507@estacado.net>, 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.64 on 155.132.188.84 Cc: "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 13:46:11 -0000 Yes, but obviously not in the same words. It needs to be tailored as do not= choose an INFO solution if you need to do this. Keith =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Wednesday, May 05, 2010 2:29 PM > To: DRAGE, Keith (Keith); Adam Roach; SIPCORE > Cc: lars.eggert@nokia.com > Subject: RE: [sipcore] Call for Consensus: INFO Specification=20 > and Congestion >=20 >=20 > Hi,=20 >=20 > >>>>The guidelines in RFC3261 Section 18 MUST be followed for sending=20 > >>>>and receiving INFO requests and responses, such as the=20 > guideline to=20 > >>>>not exceed messages sizes of 1300 bytes when the path MTU=20 > is unknown. > >>>>RFC5405 provides additional guidelines for applications using the=20 > >>>>User Datagram Protocol (UDP) that may be useful=20 > background reading." > >>> > >>>The MUST here is superfluous. By all means draw our=20 > attention to the=20 > >>>text in RFC 3261, which already contains a MUST. But if people are=20 > >>>really going to ignore RFC 3261, then they will also=20 > ignore the MUST=20 > >>>here. There are lots of other MUSTs in RFC 3261 it is equally=20 > >>>important for an INFO implementation to follow, and we get=20 > nowhere by repeating them all. > >>>I would suggest that rather than the text here, you merely=20 > >>>informatively introduce a quote from RFC 3261 of the relevant text. > >>=20 > >>Would you be ok if we change "Section 18 MUST be followed"=20 > to "Section > >>18 are to be followed"? > >=20 > >That at least removes the double specification of the same=20 > MUST in two=20 > >documents one of which is already dependent on the other. However I=20 > >would still point out that there are lots of RFC 3261 MUSTs that I=20 > >could break in an INFO implementation that would cause equal=20 > impact on=20 > >the network. > >Therefore I still consider it unnecessary. > >=20 > >Can I further point out however that none of this text does=20 > not belong=20 > >in section 10, as section 10 is about what needs to be documented to=20 > >define an INFO package, not about what the implementor=20 > actually needs=20 > >to do. It actually relates to whether it was appropriate to=20 > select INFO=20 > >in the first place to do the job, as if the information transfer=20 > >requirements are inappropriate to the underlying transport=20 > capabilities=20 > >of SIP, then INFO should not have been selected in the first place. >=20 > So, I guess it should be somewhere in section 7.4. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > =20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Sunday, May 02, 2010 9:00 AM > > > To: DRAGE, Keith (Keith); Adam Roach; SIPCORE > > > Cc: lars.eggert@nokia.com > > > Subject: RE: [sipcore] Call for Consensus: INFO Specification and=20 > > > Congestion > > >=20 > > > Hi Keith, > > >=20 > > > I am adding Lars Eggert to the discussion, since he had=20 > most issues=20 > > > with this in IESG. > > >=20 > > > >I have significant issues with the third proposed paragraph. > > > > > > > >"Therefore, an application SHOULD generally have at most one > > > outstanding INFO message. > > > > > > > >This sentence does not solve the problem of congestion, > > > which is the ethos for adding the text. All it does is > > > >impose limitations on implementations that are unnecessary.=20 > > > I would claim that I can impose congestion on the=20 > >network by poor=20 > > > design of INFO packages even without this limitation, > > whereas careful > > > use of INFO with >multiple overlapping sends does not cause=20 > > > congestion. Therefore I do not accept this sentence. > > >=20 > > > I'll let Lars comment on this. > > >=20 > > > >>The guidelines in RFC3261 Section 18 MUST be followed for > > > sending and > > > >>receiving INFO requests and responses, such as the > > guideline to not > > > >>exceed messages sizes of 1300 bytes when the path MTU=20 > is unknown. > > > >>RFC5405 provides additional guidelines for applications > > > using the User > > > >>Datagram Protocol (UDP) that may be useful background reading." > > > > > > > >The MUST here is superfluous. By all means draw our > > attention to the > > > >text in RFC 3261, which already contains a MUST. But if=20 > people are=20 > > > >really going to ignore RFC 3261, then they will also > > ignore the MUST > > > >here. There are lots of other MUSTs in RFC 3261 it is > > > equally important > > > >for an INFO implementation to follow, and we get nowhere by > > > repeating them all. I would suggest that rather than the=20 > text here,=20 > > > you merely informatively introduce a quote from RFC > > > 3261 of the relevant text. > > >=20 > > > Would you be ok if we change "Section 18 MUST be followed"=20 > > to "Section > > > 18 are to be followed"? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > > > > Sent: Friday, April 30, 2010 10:59 PM > > > > To: SIPCORE > > > > Subject: [sipcore] Call for Consensus: INFO Specification and=20 > > > > Congestion > > > > > > > > [as chair] > > > > > > > > During IESG review of the INFO specification, several members=20 > > > > expressed concerns about the congestion properties of INFO. > > > > The draft authors and IESG worked together to craft text that=20 > > > > satisfies these concerns. > > > > > > > > Since the resulting text contains normative language, we > > > are bringing > > > > the proposal to the SIPCORE working group for a 2-week > > > consensus call. > > > > Please comment on the following proposed text before > > > Friday, May 14th. > > > > If you agree with the proposal, please send a short response=20 > > > > indicating that fact. > > > > > > > > "10.9. Rate and size of INFO Requests > > > > > > > > "INFO messages differ from many other sorts of SIP > > messages in > > > > that > > > > they carry application information, and the size and > > > rate of the > > > > INFO message is directly determined by the > > > application. This can > > > > cause application information traffic to interfere > > with other > > > > traffic > > > > on that infrastructure, or to self-interfere when > > data rates > > > > become > > > > too high. > > > > > > > > "A designer of an INFO package, and the application > > > that uses it, > > > > need to consider the impact that the size and the > > rate of the > > > > INFO > > > > messages have on the network and on other=20 > traffic, since it=20 > > > > normally > > > > cannot be ensured that INFO messages will be=20 > carried over a > > > > congestion-controlled transport protocol end-to-end.=20 > > > Even if an > > > > INFO message is sent over a such a transport protocol, a=20 > > > > downstream > > > > SIP entity might forward the message over a transport > > > protocol > > > > that > > > > does not provide congestion control. > > > > > > > > "Therefore, an application SHOULD generally have=20 > at most one=20 > > > > outstanding INFO message. > > > > The guidelines in RFC3261 Section 18 MUST be followed for=20 > > > > sending and receiving INFO > > > > requests and responses, such as the guideline to=20 > not exceed=20 > > > > messages > > > > sizes of 1300 bytes when the path MTU is unknown. > > > > RFC5405 provides > > > > additional guidelines for applications using the > > User Datagram > > > > Protocol (UDP) that may be useful background reading." > > > > > > > > Thanks. > > > > > > > > /a > > > > _______________________________________________ > > > > 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 fluffy@cisco.com Wed May 5 08:01:49 2010 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 BE5AA28C295 for ; Wed, 5 May 2010 08:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.834 X-Spam-Level: X-Spam-Status: No, score=-108.834 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8, 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 9-GLuURD2Z0b for ; Wed, 5 May 2010 08:01:48 -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 0A1D128C2AB for ; Wed, 5 May 2010 07:56:25 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABsk4UurRN+J/2dsb2JhbACdRnGkR5lZhRMEgz4 X-IronPort-AV: E=Sophos;i="4.52,333,1270425600"; d="scan'208";a="254196147" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 05 May 2010 14:56:12 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o45EuAV1002973; Wed, 5 May 2010 14:56:11 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <013b01caebe2$b43c08d0$1cb41a70$@com> Date: Wed, 5 May 2010 08:56:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <020801cae802$07b56ef0$17204cd0$@com> <013b01caebe2$b43c08d0$1cb41a70$@com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1078) Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] SIP OPTIONS "ping" 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 May 2010 15:01:49 -0000 On May 4, 2010, at 5:37 PM, Paul E. Jones wrote: > Cullen, >=20 > Problem Statement: >=20 > Recognizing that if a SIP entity does not know the basic operational = state > of a peer device, there is a risk of delays in delivering service and > weakened ability for administrators to correct service issues. So for many devices, there is one one logical next hop and the existing = DNS and ICMP approaches seem to be adequate but for other situations, = there has always been a desire to do something better than that. So for = the type of servers that had many possible next hops to choose from, I = think people do want to have a better way to choose which next hop to = use that minimizes delays due to servers being down or overloaded. Right = now a new working group has been proposed to work on that problem. Is = there anything you see we need to do to expand the scope of the SIP = Overload Control Charter to make sure the problem you are envision is in = scope for that WG? As far as I can tell, this is the simple case of what = they hope to solve.=20 >=20 > Further recognizing that SIP specifies the use of OPTIONS as a means = of > determining the basic state of a UAS, but RFC 3261's description of = the > usage is shallow and does not lend itself to interoperability, = resulting in > a wide variety of implementations of OPTIONS for this purpose.=20 >=20 Actually, I don't think this was the purpose of OPTIONS in 3261 so I'm = not surprised there are some difficulties in using it this way. However, = I don't see that as a problem.=20 Cullen Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From wwwrun@rfc-editor.org Wed May 5 17:53:54 2010 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 396A828C19C; Wed, 5 May 2010 17:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=-1.131, BAYES_40=-0.185, J_CHICKENPOX_93=0.6, NO_RELAYS=-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 FXPw1qwGbCjm; Wed, 5 May 2010 17:53:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 7A09B28C161; Wed, 5 May 2010 17:53:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D4E92E067F; Wed, 5 May 2010 17:53:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100506005340.D4E92E067F@rfc-editor.org> Date: Wed, 5 May 2010 17:53:40 -0700 (PDT) Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 5839 on An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification 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 May 2010 00:53:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5839 Title: An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author: A. Niemi, D. Willis, Ed. Status: Standards Track Stream: IETF Date: May 2010 Mailbox: aki.niemi@nokia.com, dean.willis@softarmor.com Pages: 25 Characters: 52999 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-subnot-etags-04.txt URL: http://www.rfc-editor.org/rfc/rfc5839.txt The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gsalguei@cisco.com Wed May 5 19:08:53 2010 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 0B0953A68EE for ; Wed, 5 May 2010 19:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, 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 6pTynWVBbGdT for ; Wed, 5 May 2010 19:08:50 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 63B233A6949 for ; Wed, 5 May 2010 19:08:46 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o4628TDU029467; Wed, 5 May 2010 22:08:30 -0400 (EDT) Received: from rtp-gsalguei-8711.cisco.com (rtp-gsalguei-8711.cisco.com [10.116.61.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o4628Tnx006145; Wed, 5 May 2010 22:08:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: Date: Wed, 5 May 2010 22:08:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5794D411-079D-4FC0-A53F-C68AF4F275B0@cisco.com> References: <01c501caec0e$48e624e0$dab26ea0$@com> To: Christer Holmberg X-Mailer: Apple Mail (2.1078) Cc: "Paul E. Jones" , sipcore@ietf.org Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 02:08:53 -0000 Christer -=20 I think we are in agreement here. Do you think the language should be = revised to something stronger (i.e. MUST) in regards to using that = address form when sending an OPTIONS to a proxy? Or do you think it = should stay as is? Gonzalo =20 On May 5, 2010, at 1:20 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > As said earlier, 3261 already says that OPTIONS addressed to proxies = are to use sip:hostport, so I don't think we need to say anything about = that. >=20 > Regards, >=20 > Christer=20 >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org=20 >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones >> Sent: 5. toukokuuta 2010 7:49 >> To: sipcore@ietf.org >> Subject: [sipcore] draft-jones-sip-options-ping-01 >>=20 >> Folks, >>=20 >> I posted a revised version of the OPTIONS "ping" draft with=20 >> changes as per our discussions. One change I made was that I=20 >> re-instated the paragraph related to addressing, saying=20 >> OPTIONS "should" be addressed to sip:hostport. >> I'm still willing to consider removing that entirely if=20 >> that's preferred, but I recall that Hadriel preferred to have=20 >> something that one could generally assume to be the proper=20 >> address. As a means of querying UAS status, I think that's a=20 >> reasonable choice. >>=20 >> Anyway, I welcome comments on the draft. >>=20 >> Paul >>=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 christer.holmberg@ericsson.com Wed May 5 22:33:57 2010 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 065603A681B for ; Wed, 5 May 2010 22:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=-0.956, BAYES_00=-2.599, J_CHICKENPOX_38=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 AU1DjUtZHz12 for ; Wed, 5 May 2010 22:33:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DB7F53A680D for ; Wed, 5 May 2010 22:33:53 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-30-4be254b2f5a9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.B6.21861.2B452EB4; Thu, 6 May 2010 07:33:38 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 6 May 2010 07:33:38 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.40]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 6 May 2010 07:33:38 +0200 From: Christer Holmberg To: Gonzalo Salgueiro Date: Thu, 6 May 2010 07:33:37 +0200 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: Acrswq3JxHwPY+gDSgCpn7JjBlhtygAGp7HQ Message-ID: References: <01c501caec0e$48e624e0$dab26ea0$@com> <5794D411-079D-4FC0-A53F-C68AF4F275B0@cisco.com> In-Reply-To: <5794D411-079D-4FC0-A53F-C68AF4F275B0@cisco.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-Brightmail-Tracker: AAAAAA== Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 05:33:57 -0000 Hi,=20 >I think we are in agreement here. Do you think the language=20 >should be revised to something stronger (i.e. MUST) in=20 >regards to using that address form when sending an OPTIONS to=20 >a proxy? Or do you think it should stay as is? Similar to comments that have been given for INFO, we should not "duplicate= " MUST/SHALL/SHOULD/etc that are already in RFC3261. We can say something: "The addressing of OPTIONS requests to a proxy is des= cribed in section X in RFC 3261" ...or something like that. Regards, Christer > On May 5, 2010, at 1:20 AM, Christer Holmberg wrote: >=20 > >=20 > > Hi, > >=20 > > As said earlier, 3261 already says that OPTIONS addressed=20 > to proxies are to use sip:hostport, so I don't think we need=20 > to say anything about that. > >=20 > > Regards, > >=20 > > Christer > >=20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones > >> Sent: 5. toukokuuta 2010 7:49 > >> To: sipcore@ietf.org > >> Subject: [sipcore] draft-jones-sip-options-ping-01 > >>=20 > >> Folks, > >>=20 > >> I posted a revised version of the OPTIONS "ping" draft=20 > with changes=20 > >> as per our discussions. One change I made was that I=20 > re-instated the=20 > >> paragraph related to addressing, saying OPTIONS "should"=20 > be addressed=20 > >> to sip:hostport. > >> I'm still willing to consider removing that entirely if that's=20 > >> preferred, but I recall that Hadriel preferred to have=20 > something that=20 > >> one could generally assume to be the proper address. As a=20 > means of=20 > >> querying UAS status, I think that's a reasonable choice. > >>=20 > >> Anyway, I welcome comments on the draft. > >>=20 > >> Paul > >>=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 HKaplan@acmepacket.com Wed May 5 22:41:40 2010 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 1C9E83A691A for ; Wed, 5 May 2010 22:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_38=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 PgbbzGYuxo4Q for ; Wed, 5 May 2010 22:41:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AAF483A686E for ; Wed, 5 May 2010 22:41:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 6 May 2010 01:41:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 6 May 2010 01:41:16 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Paul E. Jones" , "sipcore@ietf.org" Date: Thu, 6 May 2010 01:40:46 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrsDkjOK5ef9FFUTOq6bfZWNHVcxgABA26wADMIhbA= Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> References: <01c501caec0e$48e624e0$dab26ea0$@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 Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 05:41:40 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Christer Holmberg > Sent: Wednesday, May 05, 2010 1:20 AM >=20 > As said earlier, 3261 already says that OPTIONS addressed to proxies are > to use sip:hostport, so I don't think we need to say anything about that. But this is *not* to a proxy, or at least not always to a proxy. The draft= is for it between UA's as well (B2BUA's to be precise, but UA's nonetheles= s). -hadriel From HKaplan@acmepacket.com Wed May 5 22:55:26 2010 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 5EBC53A6A62 for ; Wed, 5 May 2010 22:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_20=-0.74] 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 xbtSx6VfOlHx for ; Wed, 5 May 2010 22:55:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9DB5B3A6781 for ; Wed, 5 May 2010 22:55:24 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 6 May 2010 01:55:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 6 May 2010 01:55:10 -0400 From: Hadriel Kaplan To: "Elwell, John" , "Paul E. Jones" , 'Cullen Jennings' Date: Thu, 6 May 2010 01:55:05 -0400 Thread-Topic: [sipcore] SIP OPTIONS "ping" Thread-Index: AcromniiBo1q2JVvQy61uuGdcfOzygDOsMxwAB8bIaAAI0gt4A== Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7197@mail> References: <020801cae802$07b56ef0$17204cd0$@com> <013b01caebe2$b43c08d0$1cb41a70$@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 Cc: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS "ping" 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 May 2010 05:55:26 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 05, 2010 8:55 AM > To: Paul E. Jones; 'Cullen Jennings' >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones > > Sent: 05 May 2010 00:37 > > > > Problem Statement: > > Recognizing that if a SIP entity does not know the basic > > operational state > > of a peer device, there is a risk of delays in delivering service and > > weakened ability for administrators to correct service issues. > > [JRE] To a first approximation, a 2xx versus a 4xx/5xx/6xx should tell yo= u > the basic operational state of the responder. So we need more precise > information on what is broken. But it doesn't in practice. Both because it's not a binary on/off operatio= nal state, and because of targeting/addressing issues. =20 Some devices send a 503 when they're too busy, and don't want new requests = for retry-after time, but still expect in-dialog requests. Some devices se= nd a 486 instead. Some devices send a 503 when they're admin-down. Some devices send a 500 i= nstead. In either case, some expect in-dialog messages, others don't. Some send a 483 Too Many Hops, because the requestor had to set a max-forwa= rds of 0 or 1 to prevent it going past the next-hop. (because the addressin= g for the OPTIONS is ambiguous) And that prevents either a 2xx or 5xx. -hadriel From HKaplan@acmepacket.com Wed May 5 23:03:41 2010 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 7521B3A6A34 for ; Wed, 5 May 2010 23:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-1.043, 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 QWHWhaJRCZmR for ; Wed, 5 May 2010 23:03:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 57EB33A6827 for ; Wed, 5 May 2010 23:03:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 6 May 2010 02:03:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 6 May 2010 02:03:24 -0400 From: Hadriel Kaplan To: Cullen Jennings , "Paul E. Jones" Date: Thu, 6 May 2010 02:03:24 -0400 Thread-Topic: [sipcore] SIP OPTIONS "ping" Thread-Index: AcrsY0J1qaJGRG5sQZerG6B6RtMBvwAfYHeQ Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D719A@mail> References: <020801cae802$07b56ef0$17204cd0$@com> <013b01caebe2$b43c08d0$1cb41a70$@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 Cc: 'Michael Miller' , "sipcore@ietf.org" Subject: Re: [sipcore] SIP OPTIONS "ping" 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 May 2010 06:03:41 -0000 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, May 05, 2010 10:56 AM > To: Paul E. Jones >=20 > So for many devices, there is one one logical next hop and the existing > DNS and ICMP approaches seem to be adequate but for other situations, > there has always been a desire to do something better than that. So for > the type of servers that had many possible next hops to choose from, I > think people do want to have a better way to choose which next hop to use > that minimizes delays due to servers being down or overloaded. Right now = a > new working group has been proposed to work on that problem. Is there > anything you see we need to do to expand the scope of the SIP Overload > Control Charter to make sure the problem you are envision is in scope for > that WG? As far as I can tell, this is the simple case of what they hope > to solve. Yes, I also noted that when Paul first submitted the draft. But his point = was that (1) it's not just load state, it's also admin state, and (2) it's = a ping as well. I suppose one could argue that if the overload WG covers r= eal state information and not just load, then OPTIONS could be the carrier = for that info. > > Further recognizing that SIP specifies the use of OPTIONS as a means of > > determining the basic state of a UAS, but RFC 3261's description of the > > usage is shallow and does not lend itself to interoperability, resultin= g > in > > a wide variety of implementations of OPTIONS for this purpose. >=20 > Actually, I don't think this was the purpose of OPTIONS in 3261 so I'm no= t > surprised there are some difficulties in using it this way. However, I > don't see that as a problem. >From rfc3261 page 68: 11.2 Processing of OPTIONS Request The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. -hadriel From christer.holmberg@ericsson.com Wed May 5 23:22:24 2010 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 9C8993A689B for ; Wed, 5 May 2010 23:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, 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 Ioao54MX9-Jz for ; Wed, 5 May 2010 23:22:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B510B3A6A2D for ; Wed, 5 May 2010 23:22:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-17-4be2600ea99d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7D.1B.08537.E0062EB4; Thu, 6 May 2010 08:22:07 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.40]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 6 May 2010 08:22:06 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Paul E. Jones" , "sipcore@ietf.org" Date: Thu, 6 May 2010 08:22:05 +0200 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrsDkjOK5ef9FFUTOq6bfZWNHVcxgABA26wADMIhbAAAXNUcA== Message-ID: References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 06:22:24 -0000 Hi,=20 >>As said earlier, 3261 already says that OPTIONS addressed to proxies=20 >>are to use sip:hostport, so I don't think we need to say anything about t= hat. >=20 >But this is *not* to a proxy, or at least not always to a=20 >proxy. The draft is for it between UA's as well (B2BUA's to=20 >be precise, but UA's nonetheless). True, I was also talking about proxies. But, I believe 3261 also says that OPTIONS addresses to UAs are using the h= ostpart. Would need to double check, though. Regards, Christer From HKaplan@acmepacket.com Wed May 5 23:47:07 2010 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 707253A69FE for ; Wed, 5 May 2010 23:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_38=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 Rosn24+iBLgr for ; Wed, 5 May 2010 23:47:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7FF043A6AD3 for ; Wed, 5 May 2010 23:47:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 6 May 2010 02:46:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 6 May 2010 02:46:49 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Paul E. Jones" , "sipcore@ietf.org" Date: Thu, 6 May 2010 02:46:48 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrsDkjOK5ef9FFUTOq6bfZWNHVcxgABA26wADMIhbAAAXNUcAAAN+Pg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> 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 Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 06:47:07 -0000 I don't think so - it was ambiguous for that. It only said this in section= 11: The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to the way a Request-URI is set for a REGISTER request. It didn't explicitly say how to address a UA instance, only a proxy. (of co= urse how one knows a priori that the next-hop is a proxy vs. a b2bua is bey= ond me) =20 But it doesn't really matter. In practice, historically even using sip:hos= tport has had problems, especially if the next-hop is an SBC. Because an S= BC doesn't know if the OPTIONS request is really for itself, vs. for an aut= horitative proxy for the domain, behind it - if it knew the OPTIONS was for= a ping, it would know it's for itself; but if it's for capabilities then i= t was always a guess as to whom it's for; and of course the OPTIONS doesn't= say which it is so it's always a guess. So people set max-forwards to eit= her 0 or 1 to avoid it going further, and that caused other issues (like ge= tting a 483 instead of a 200, and incrementing loop-detection counters). So today you have a bunch of configuration you may need to set, and to set = it you need to know what the next-hop or previous-hop expects. So it's err= or-prone, tedious, and not fun. -hadriel > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, May 06, 2010 2:22 AM > > > >But this is *not* to a proxy, or at least not always to a > >proxy. The draft is for it between UA's as well (B2BUA's to > >be precise, but UA's nonetheless). >=20 > True, I was also talking about proxies. >=20 > But, I believe 3261 also says that OPTIONS addresses to UAs are using the > hostpart. Would need to double check, though. >=20 > Regards, >=20 > Christer From pkyzivat@cisco.com Thu May 6 05:59:21 2010 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 012393A6BBA for ; Thu, 6 May 2010 05:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.986 X-Spam-Level: X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, 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 J-CPFRUvRtSH for ; Thu, 6 May 2010 05:59:20 -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 88DAB28C160 for ; Thu, 6 May 2010 05:57:33 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANBY4ktAZnwM/2dsb2JhbACdaHGifZoBglmCOgQ X-IronPort-AV: E=Sophos;i="4.52,341,1270425600"; d="scan'208";a="108679959" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 May 2010 12:57:20 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o46CvKDt019670; Thu, 6 May 2010 12:57:20 GMT Message-ID: <4BE2BCB0.10909@cisco.com> Date: Thu, 06 May 2010 08:57:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 12:59:21 -0000 If you dig into it, the notion of "addressing OPTIONS to a proxy" is not a meaningful concept, so defining rules for how to do it is meaningless. This is because "proxy" is a *role* a server takes on, not a particular type of server. The same box may sometimes act like a proxy, and sometimes ack like something else. And by definition, when a box generates its own response to an incoming OPTIONS request, it is acting as a UAS. The situation that is most proxy-like in this regard is when a request arrives, isn't addressed to the receiving server, and max-forwards is zero. If it returns 200 response in such a case, then I suppose we can conclude that it was at least a middle-box, though it might still normally act as a B2BUA rather than a proxy. In any case, in this situation, the request is by definition not addressed to this box, so imposing requirements on the form of the R-URI would be silly. So fundamentally we need to just be talking about what it means to address a specific server, without regard to what sort of server it might be. And IMO that simply means using a URI with a domain that server "is responsible for". All URIs with that domain are in some sense addressed to that box, regardless of user part. At that point it is up to that box to interpret the user part as it sees fit. Some user parts may be treated by it as identifiers of certain resources within the box. Others might be treated as requiring retargeting. Note that even a URI with *no* user part could be treated as requiring retargeting. (E.g. the box might be a load balancer.) Thanks, Paul Thanks, Paul Hadriel Kaplan wrote: > I don't think so - it was ambiguous for that. It only said this in section 11: > The target of the OPTIONS request is identified by the Request-URI, > which could identify another UA or a SIP server. If the OPTIONS is > addressed to a proxy server, the Request-URI is set without a user > part, similar to the way a Request-URI is set for a REGISTER request. > > It didn't explicitly say how to address a UA instance, only a proxy. (of course how one knows a priori that the next-hop is a proxy vs. a b2bua is beyond me) > > But it doesn't really matter. In practice, historically even using sip:hostport has had problems, especially if the next-hop is an SBC. Because an SBC doesn't know if the OPTIONS request is really for itself, vs. for an authoritative proxy for the domain, behind it - if it knew the OPTIONS was for a ping, it would know it's for itself; but if it's for capabilities then it was always a guess as to whom it's for; and of course the OPTIONS doesn't say which it is so it's always a guess. So people set max-forwards to either 0 or 1 to avoid it going further, and that caused other issues (like getting a 483 instead of a 200, and incrementing loop-detection counters). > > So today you have a bunch of configuration you may need to set, and to set it you need to know what the next-hop or previous-hop expects. So it's error-prone, tedious, and not fun. > > -hadriel > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Thursday, May 06, 2010 2:22 AM >>> But this is *not* to a proxy, or at least not always to a >>> proxy. The draft is for it between UA's as well (B2BUA's to >>> be precise, but UA's nonetheless). >> True, I was also talking about proxies. >> >> But, I believe 3261 also says that OPTIONS addresses to UAs are using the >> hostpart. Would need to double check, though. >> >> Regards, >> >> Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From paulej@packetizer.com Thu May 6 09:10:44 2010 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 A584A3A6BC6 for ; Thu, 6 May 2010 09:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, J_CHICKENPOX_38=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 bzOVhUt9mxIJ for ; Thu, 6 May 2010 09:10:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id E63E03A6B46 for ; Thu, 6 May 2010 09:07:44 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o46G7LXh031888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 May 2010 12:07:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273162047; bh=6Dcm28fL6jVumtCi2Mw4/YvA7gITiqbGB2RfEtF7OXU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cgl/UWQANNU2sluZGDDC6PylzopjIkcbutLipyWBAsXy9S6y/darY3XGn8xC7BNRd rCswa7e3h9oNH65rdFyIO+FUmMiJEFvyYE01zaZAvz3G6w9YY8QFn7rB5EOpaI7mFJ cYhETdE/I4t4Yblea0+3AYIZTF3+dkud+kMc+EU4= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o46G7KpT030281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 May 2010 12:07:20 -0400 From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Gonzalo Salgueiro'" References: <01c501caec0e$48e624e0$dab26ea0$@com> <5794D411-079D-4FC0-A53F-C68AF4F275B0@cisco.com> In-Reply-To: Date: Thu, 6 May 2010 12:07:03 -0400 Message-ID: <030b01caed36$2aa53f10$7fefbd30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrswq3JxHwPY+gDSgCpn7JjBlhtygAGp7HQABYvxvA= Content-Language: en-us Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 16:10:44 -0000 Christer, Sounds good. How is this? The OPTIONS message SHOULD be addressed to a peer SIP entity using a SIP URI of the form "sip:hostport" (see Section 25.1 of RFC 3261 for definitions). For example, "sip:192.168.1.5" is preferred, whereas "sip:bob@example.com" is not preferred for the purpose of this memo. The request URI required when addressing a proxy is described in Section 11 of RFC 3261. Paul > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, May 06, 2010 1:34 AM > To: Gonzalo Salgueiro > Cc: Paul E. Jones; sipcore@ietf.org > Subject: RE: [sipcore] draft-jones-sip-options-ping-01 > > > Hi, > > >I think we are in agreement here. Do you think the language > >should be revised to something stronger (i.e. MUST) in > >regards to using that address form when sending an OPTIONS to > >a proxy? Or do you think it should stay as is? > > Similar to comments that have been given for INFO, we should not > "duplicate" MUST/SHALL/SHOULD/etc that are already in RFC3261. > > We can say something: "The addressing of OPTIONS requests to a proxy is > described in section X in RFC 3261" > > ...or something like that. > > Regards, > > Christer > > > > > > On May 5, 2010, at 1:20 AM, Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > As said earlier, 3261 already says that OPTIONS addressed > > to proxies are to use sip:hostport, so I don't think we need > > to say anything about that. > > > > > > Regards, > > > > > > Christer > > > > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul E. Jones > > >> Sent: 5. toukokuuta 2010 7:49 > > >> To: sipcore@ietf.org > > >> Subject: [sipcore] draft-jones-sip-options-ping-01 > > >> > > >> Folks, > > >> > > >> I posted a revised version of the OPTIONS "ping" draft > > with changes > > >> as per our discussions. One change I made was that I > > re-instated the > > >> paragraph related to addressing, saying OPTIONS "should" > > be addressed > > >> to sip:hostport. > > >> I'm still willing to consider removing that entirely if that's > > >> preferred, but I recall that Hadriel preferred to have > > something that > > >> one could generally assume to be the proper address. As a > > means of > > >> querying UAS status, I think that's a reasonable choice. > > >> > > >> Anyway, I welcome comments on the draft. > > >> > > >> Paul > > >> > > >> > > >> _______________________________________________ > > >> 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 Thu May 6 12:52:33 2010 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 88BD23A6A57 for ; Thu, 6 May 2010 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=-0.656, 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 eYm7lqu6M-TM for ; Thu, 6 May 2010 12:52:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 47D603A6A40 for ; Thu, 6 May 2010 12:52:31 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-a7-4be31df08cf0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 88.80.21861.0FD13EB4; Thu, 6 May 2010 21:52:16 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.40]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 6 May 2010 21:52:16 +0200 From: Christer Holmberg To: SIPCORE Date: Thu, 6 May 2010 21:51:24 +0200 Thread-Topic: SigComp and Service-Route Thread-Index: AQHK58K2VbA2czSRtUC38BERDQCunJJE239f 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SigComp and 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: Thu, 06 May 2010 19:52:33 -0000 Hi, Any comments on this? It is going to be discussed at the 3GPP meeting next = week, so some guidance from the WG would be useful, I think. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] Sent: Thursday, April 29, 2010 8:37 PM To: SIPCORE Subject: [sipcore] SigComp and Service-Route Hi, I appologize if the following issue have been discussed and solved before. When reading RFC 5049 (Sigcomp), the UA figures out whether the outbound proxy supports sigcomp by looking at outbound proxie's entry in the Service-Route in the REGISTER response. My questions are: 1. How can the UA ensure that the outbound proxy will be listed in the Service-Route in the first place? RFC 3608 (Service-Route) does not mandate the registrar to insert any intermediaries in the Service-Route, e.g based on Path. It's all based on local policy. 2. Even if the registrar would build the Service-Route based on Path, how does it know that the Path address/port values will be usable/routable in the UA-towards-registrar direction (Path is supposed to be used in the registrar-towards-UA direction)? This is similar to the Record-Route problem, and intermediaries with different network addresses/ports per direction would have to insert "double Path". I guess the outbound proxy could insert itself in the Service-Route, but that is not described anywhere in RFC 5049, and it is also a SHOULD NOT in RFC 3608. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From HKaplan@acmepacket.com Fri May 7 08:31:01 2010 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 4DA383A6977 for ; Fri, 7 May 2010 08:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_20=-0.74] 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 z3aTOfsRySWy for ; Fri, 7 May 2010 08:30:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BE0643A6957 for ; Fri, 7 May 2010 08:30:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 7 May 2010 11:30:45 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 7 May 2010 11:30:44 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 7 May 2010 11:30:33 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrtG9LAYnWZEPSrSTixWz+wxNOhWAAOKg3g Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> In-Reply-To: <4BE2BCB0.10909@cisco.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 Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 15:31:01 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, May 06, 2010 8:57 AM > To: Hadriel Kaplan >=20 > If you dig into it, the notion of "addressing OPTIONS to a proxy" is not > a meaningful concept, so defining rules for how to do it is meaningless. Agreed. =20 > So fundamentally we need to just be talking about what it means to > address a specific server, without regard to what sort of server it > might be. And IMO that simply means using a URI with a domain that > server "is responsible for". All URIs with that domain are in some sense > addressed to that box, regardless of user part. At that point it is up > to that box to interpret the user part as it sees fit. Some user parts > may be treated by it as identifiers of certain resources within the box. > Others might be treated as requiring retargeting. Note that even a URI > with *no* user part could be treated as requiring retargeting. (E.g. the > box might be a load balancer.) I'm not exactly clear on what you're proposing. =20 If you're proposing the request be set to "sip:domain.com" or "sip:192.1.2.= 3", that hasn't worked in practice and probably can't without an indicator = the OPTIONS is for status/ping. =20 If you're proposing to use "sip:special-user@domain.com" or "sip:special-us= er@192.1.2.3", that's what I was originally proposing, except I was proposi= ng "special-user" be a well-known reserved name. But on thinking about it more I concurred with your original proposal sever= al emails ago, to just have a new SIP Header to indicate the OPTIONS is for= the status/ping. (or we could make it a more generic header which says som= ething like "this is for the system's administrative process", so we could = use it in SUBSCRIBEs, for example) -hadriel From pkyzivat@cisco.com Fri May 7 09:57:52 2010 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 5B9463A67D6 for ; Fri, 7 May 2010 09:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 QjJmsqEe+CJ0 for ; Fri, 7 May 2010 09:57:51 -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 349153A67B7 for ; Fri, 7 May 2010 09:57:51 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHfj40tAZnwM/2dsb2JhbACeGXGmEplNgncMghIE X-IronPort-AV: E=Sophos;i="4.52,349,1270425600"; d="scan'208";a="108993879" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 May 2010 16:57:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o47GvcXc014960; Fri, 7 May 2010 16:57:38 GMT Message-ID: <4BE44683.9040405@cisco.com> Date: Fri, 07 May 2010 12:57:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 16:57:52 -0000 At end... Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, May 06, 2010 8:57 AM >> To: Hadriel Kaplan >> >> If you dig into it, the notion of "addressing OPTIONS to a proxy" is not >> a meaningful concept, so defining rules for how to do it is meaningless. > > Agreed. > > >> So fundamentally we need to just be talking about what it means to >> address a specific server, without regard to what sort of server it >> might be. And IMO that simply means using a URI with a domain that >> server "is responsible for". All URIs with that domain are in some sense >> addressed to that box, regardless of user part. At that point it is up >> to that box to interpret the user part as it sees fit. Some user parts >> may be treated by it as identifiers of certain resources within the box. >> Others might be treated as requiring retargeting. Note that even a URI >> with *no* user part could be treated as requiring retargeting. (E.g. the >> box might be a load balancer.) > > I'm not exactly clear on what you're proposing. > > If you're proposing the request be set to "sip:domain.com" or "sip:192.1.2.3", that hasn't worked in practice and probably can't without an indicator the OPTIONS is for status/ping. > > If you're proposing to use "sip:special-user@domain.com" or "sip:special-user@192.1.2.3", that's what I was originally proposing, except I was proposing "special-user" be a well-known reserved name. > > But on thinking about it more I concurred with your original proposal several emails ago, to just have a new SIP Header to indicate the OPTIONS is for the status/ping. (or we could make it a more generic header which says something like "this is for the system's administrative process", so we could use it in SUBSCRIBEs, for example) Sorry, I guess my comment left things dangling. My point was that there currently is no consistent and well known way of identifying "the box". There isn't even a *notion* of addressing "the box", as distinct from any of the resources it manages. One answer is that if you want to ping something, you need to find something to ping that has the properties you want, and that will be identified by *some* URI, but not the same one for every box, and maybe none for some boxes. So you need to find out by provisioning what it is that you should address your pings to. I don't find that answer very satisfying. Alternately, we have to come up with a unique way of addressing the ping to something with the appropriate properties, without appropriating a username value that some might object to. I *guess* we could pick some obscure value for the user name for this purpose. But I hate appropriating special values out of someone else's namespace. Rather I think we should use some namespace that we control. I see several possibilities: - a new header indicating that this (OPTIONS) request has a special meaning - a special URI parameter indicating that this request is addressed to a special function rather than to the normal resource associated with the URI - a new request type (e.g. PING) in which case we get to specify all the semantics I can find no particular benefit to the URI parameter over the header parameter, and it raises various other questions I'd just as soon avoid going into. I have some fondness for a new method, but find the new header on OPTIONS to be roughly as good, and more people seem to like it, so I'm ok with that. I do however appreciate the points that Cullen has raised, and would like to see them addressed before we go much further with this. Thanks, Paul From mary.ietf.barnes@gmail.com Fri May 7 13:22:22 2010 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 A9C863A684A for ; Fri, 7 May 2010 13:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.539, 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 savw-oDHzqg1 for ; Fri, 7 May 2010 13:22:18 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id 9CA283A69A0 for ; Fri, 7 May 2010 13:22:14 -0700 (PDT) Received: by yxe9 with SMTP id 9so1160030yxe.29 for ; Fri, 07 May 2010 13:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=ERaKcH99zZeZGyqFJbiz/dTeYmDv1l3f8ik0spcDnns=; b=N2/GVY6f/+g8uiztlCFjvBuJ2zpg9CkzJQwizi0exvNGzfJ3BF4HvxcsoZwWArvO7/ Vz4sdWffdIomc9wsZh6Iovt+fKO8oNdw60T/Iptre32u5jHAtk9r2HUWR5hBHUuee0fz WiBUlw9QtwpMgKojL63FccjmenJ4GYGFJrWp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=kj7YYczUtng9s07BRRj4Ey8wjciQm0ycbtzy1OBCE/fA5ibK4qQA9TV8tr8wJELiBb I17iAdKj2ZM2FBPK434PMFS0jQUH353xhWpNeY9G+wOQum31Ja/J6N5mus+uysqzO0hx yd4FCu8zrx7V89Jfu0BFUeefGT5rFKltmXN/A= MIME-Version: 1.0 Received: by 10.231.182.140 with SMTP id cc12mr346852ibb.18.1273263718344; Fri, 07 May 2010 13:21:58 -0700 (PDT) Received: by 10.231.147.148 with HTTP; Fri, 7 May 2010 13:21:58 -0700 (PDT) Date: Fri, 7 May 2010 15:21:58 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Cc: Francois AUDET , Shida Schubert Subject: [sipcore] 4244bis issue summary/proposed changes 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 May 2010 20:22:22 -0000 Hi all, This is a follow-up to the discussion we had on 4244bis in Anaheim and some subsequent discussion on the mailing list. The primary point of contention was around the support for voicemail. The example we have in the WG -00 describes the handling as based on policy and provides two examples of such. However, that's really not the best approach and indeed voicemail really has two basic use cases that are specific to configuration and thus a UAS for a specific configuration does have determinant behavior and we can specify the exact mechanism by which the appropriate information is derived from the History-Info header. Our proposal is actually to move the majority of the use cases out of this document into a separate informational (or BCP) document and add more illustrative text and precise descriptions as to how the necessary information is derived from the History-Info header. We will add general text to 4244bis describing basic rules for using the information in the UAS and application considerations sections. We will keep the basic examples from RFC 4244. In one sense, we are reverting to what we had in earlier versions, except that the call flows will be kept in sync with 4244bis. We can decide where the call flows should live once we get the updated documents submitted. For background, here's a link to the earlier thread: http://www.ietf.org/mail-archive/web/sipcore/current/msg02180.html and meeting minutes: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html We'll try to get the updates done within the next couple weeks. Thanks, Mary. From pkyzivat@cisco.com Fri May 7 14:32:00 2010 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 BD6F23A67EA for ; Fri, 7 May 2010 14:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.27 X-Spam-Level: X-Spam-Status: No, score=-10.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 L2dSUvY7iXrt for ; Fri, 7 May 2010 14:32: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 2D1053A6924 for ; Fri, 7 May 2010 14:31:50 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOsj5EtAZnwN/2dsb2JhbACeHHGmDJk+hRUE X-IronPort-AV: E=Sophos;i="4.52,350,1270425600"; d="scan'208";a="109068776" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 May 2010 21:17:44 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o47LHiol022483; Fri, 7 May 2010 21:17:44 GMT Message-ID: <4BE48378.5020602@cisco.com> Date: Fri, 07 May 2010 17:17:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Francois AUDET , Shida Schubert Subject: Re: [sipcore] 4244bis issue summary/proposed changes 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 May 2010 21:32:00 -0000 Mary Barnes wrote: > Hi all, > > This is a follow-up to the discussion we had on 4244bis in Anaheim and > some subsequent discussion on the mailing list. The primary point of > contention was around the support for voicemail. The example we have > in the WG -00 describes the handling as based on policy and provides > two examples of such. However, that's really not the best approach > and indeed voicemail really has two basic use cases that are specific > to configuration and thus a UAS for a specific configuration does have > determinant behavior and we can specify the exact mechanism by which > the appropriate information is derived from the History-Info header. I look forward to hearing about that. Thanks, Paul From root@core3.amsl.com Sat May 8 00:30:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1CBBE3A68A8; Sat, 8 May 2010 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100508073002.1CBBE3A68A8@core3.amsl.com> Date: Sat, 8 May 2010 00:30:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Sat, 08 May 2010 07:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-04.txt Pages : 24 Date : 2010-05-08 In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-reinvite-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-08002159.I-D@ietf.org> --NextPart-- From HKaplan@acmepacket.com Sat May 8 08:53:23 2010 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 5D8313A6895 for ; Sat, 8 May 2010 08:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-1.005, 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 xtKiyT9F7xLi for ; Sat, 8 May 2010 08:53:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3F75D3A6851 for ; Sat, 8 May 2010 08:53:21 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 8 May 2010 11:53:08 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 8 May 2010 11:53:08 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Cullen Jennings Date: Sat, 8 May 2010 11:53:06 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcruBolScHHzRspCRyGP8ArcOq2ohwAvcP6Q Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> In-Reply-To: <4BE44683.9040405@cisco.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 Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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, 08 May 2010 15:53:23 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, May 07, 2010 12:58 PM >=20 > My point was that there currently is no consistent and well known way of > identifying "the box". There isn't even a *notion* of addressing "the > box", as distinct from any of the resources it manages. > One answer is that if you want to ping something, you need to find > something to ping that has the properties you want, and that will be > identified by *some* URI, but not the same one for every box, and maybe > none for some boxes. So you need to find out by provisioning what it is > that you should address your pings to. >=20 > I don't find that answer very satisfying. Me neither. =20 > I do however appreciate the points that Cullen has raised, and would > like to see them addressed before we go much further with this. Although I agree that the overload-chartered work is meant to improve thing= s from the on/off flapping model we have today, I don't see how that invali= dates the need or value of clearing up OPTIONS. In some ways it's orthogon= al, because the addressing problem still exists for OPTIONS regardless. For sake of argument, ignore the "ping" aspect of OPTIONS. Let's just say = you wanted to send an OPTIONS to a SIP device (proxy, B2BUA, or UA) to lear= n its capabilities - the *system's* capabilities, not a particular user ins= tance in it. How would you do that? In practice today: through manual con= figuration. So let's say we went and created a draft to fix that, by using= a new header. In that same draft, we re-iterated or clarified what the re= sponses to such a query would mean. In effect, that's Paul's draft. Furthermore, if we cleared up how OPTIONS can be addressed, one could use a= n OPTIONS to exchange the new overload info. And likewise, a SUBSCRIBE for= overload info has the same issues OPTIONS does in terms of addressing. -hadriel From pkyzivat@cisco.com Mon May 10 07:17:35 2010 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 96F453A6951 for ; Mon, 10 May 2010 07:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.966 X-Spam-Level: X-Spam-Status: No, score=-8.966 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_50=0.001, 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 B3bBxn96SWkF for ; Mon, 10 May 2010 07:17:34 -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 87A0A3A69A1 for ; Mon, 10 May 2010 07:17:33 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,362,1270425600"; d="scan'208";a="109677761" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 May 2010 14:17:22 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4AEHL1K006126; Mon, 10 May 2010 14:17:22 GMT Message-ID: <4BE81570.5080803@cisco.com> Date: Mon, 10 May 2010 10:17:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 14:17:35 -0000 Inline... Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, May 07, 2010 12:58 PM >> >> My point was that there currently is no consistent and well known way of >> identifying "the box". There isn't even a *notion* of addressing "the >> box", as distinct from any of the resources it manages. >> One answer is that if you want to ping something, you need to find >> something to ping that has the properties you want, and that will be >> identified by *some* URI, but not the same one for every box, and maybe >> none for some boxes. So you need to find out by provisioning what it is >> that you should address your pings to. >> >> I don't find that answer very satisfying. > > Me neither. > > >> I do however appreciate the points that Cullen has raised, and would >> like to see them addressed before we go much further with this. > > Although I agree that the overload-chartered work is meant to improve things from the on/off flapping model we have today, I don't see how that invalidates the need or value of clearing up OPTIONS. In some ways it's orthogonal, because the addressing problem still exists for OPTIONS regardless. > > For sake of argument, ignore the "ping" aspect of OPTIONS. Let's just say you wanted to send an OPTIONS to a SIP device (proxy, B2BUA, or UA) to learn its capabilities - the *system's* capabilities, not a particular user instance in it. How would you do that? In practice today: through manual configuration. So let's say we went and created a draft to fix that, by using a new header. In that same draft, we re-iterated or clarified what the responses to such a query would mean. In effect, that's Paul's draft. My counter-argument here is that the "system capabilities of a box" isn't necessarily a well defined concept. There may just be a multiplexer, based on the user part of the uri, to a variety of software agents. So no matter what you address the request to you are actually getting the status of one software agent or another, not of the box as a whole. I interpret 3261 as saying the those elements "responsible for a domain" are the masters of the URIs that are valid in that domain. Others, that are not responsible for the domain, have no business "fabricating" a URI by pasting together a user part of their choice with the domain name. Instead they should be using addresses that are "given to them" directly or indirectly by an "agent" of the domain. There is one case I know of where that is formally not the case. It is when using REGISTER, where a sip URI without user part is the R-URI. That is a restriction for domains that support REGISTER, and potentially may apply only to REGISTER. Of course, this philosophy is violated all over the place. It can be justified in some cases as a matter that in some cases knowledge of the policy of a particular domain may extend to elements beyond those "responsible for the domain". But that still doesn't justify making such assumptions about a domain you have no special information about. (And of course you an violate this is you are prepared for the consequences. If I didn't know Hadriel's sip URI, I might just try a variety of user parts in sip:*@acmepacket.com it hopes of guessing it.) I think it is a big philosophical step to say that there is a reserved sip uri that will be serviced by *something* that can speak for the box as a whole. > Furthermore, if we cleared up how OPTIONS can be addressed, one could use an OPTIONS to exchange the new overload info. And likewise, a SUBSCRIBE for overload info has the same issues OPTIONS does in terms of addressing. I wonder if that doesn't have some of the same issues - that a box may server as a multiplexer for a number of software agents. Much or all of the "overload" attributes may be attributable to those software agents, not to the box in general. I can certainly imagine architectures where requests to sip:X@example.com is overloaded, while requests to sip:Y@example.com is not overloaded. But I haven't been party to the overload work, so I don't know what the thinking is like in that regard. To me this seems like a reason to include the ping clarification (at least with respect "addressing the box") into the overload work. And to a certain extent that may also be true for the question of inconsistent responses to conditions, since the inconsistent responses of concern are all (I think) related to overload and up/down type conditions. Thanks, Paul From radhika.r.roy@us.army.mil Mon May 10 07:37:58 2010 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 906EE3A6985 for ; Mon, 10 May 2010 07:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 jY+prwowzGWg for ; Mon, 10 May 2010 07:37:56 -0700 (PDT) Received: from mxoutdr1.us.army.mil (mxoutdr1.us.army.mil [143.69.242.38]) by core3.amsl.com (Postfix) with ESMTP id 8965C3A6359 for ; Mon, 10 May 2010 07:37:55 -0700 (PDT) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=EEC9wloQsFf7SPZWfHAw0o27cKNikVpcvmZFA6GuplDLSkk+6cjhmC+V FsZ+iPSqPlZ1NAiSJF4zLoPnmKsc5A==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us.army.mil; i=radhika.r.roy@us.army.mil; q=dns/txt; s=akodkim; t=1273502266; x=1305038266; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy,=20Radhika=20R=20Dr=20CIV=20USA=20USAMC"=20 |Subject:=20Re:=20[sipcore]=20 draft-jones-sip-options-ping-01|Date:=20Mon,=2010=20May =202010=2010:37:31=20-0400|Message-ID:=20|To:=20Paul=20Kyzivat=20|Cc:=20Hadriel=20Kaplan=20, "Paul=20E.=20Jones"=0D=0A=20,"sipc ore@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4BE815 70.5080803@cisco.com>|References:=20<01c501caec0e$48e624e 0$dab26ea0$@com>=0D=0A=20=20<430FC6BDED 356B4C8498F634416644A91A8A7D7192@mail>=0D=0A=20=20<430FC6BDED356B4C8498F634416644A91A8A7D71A2@ma il>=0D=0A=20<4BE2BCB0.10909@cisco.com>=0D=0A=20<430FC6BDE D356B4C8498F634416644A91A8A7D760B@mail>=0D=0A=20<4BE44683 .9040405@cisco.com>=0D=0A=20<430FC6BDED356B4C8498F6344166 44A91A8A7D7771@mail>=0D=0A=20<4BE81570.5080803@cisco.com>; bh=oLddV9M7ta327g8w3cPJQOlrCb5+wnaXHJwU4DRtIWU=; b=bvo6ghRbaAtK8anszu50MSPnTMNPV5zyI6IWhAXgQFezfV6ryDrmJ8CW Sg4EOeiAajw01qmbQPEhzId2BC/fHwSNOeL+Fr1QyPs0ziddP/ldjG9P4 mUxVaU7mKl3mLvmYGpXeCjW+bctNW+AoQ+vsKuYZwVNaOFzngQRY8GvzD o=; From: "Roy, Radhika R Dr CIV USA USAMC" X-AKO: 159255037:10.240.36.115:10 May 2010 14:37:38 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.52,362,1270425600"; d="scan'208";a="159255037" Received: from mailstore13.int.dr1.us.army.mil (HELO us.army.mil) ([10.240.36.115]) by mxoutdr1.us.army.mil with ESMTP; 10 May 2010 14:37:31 +0000 Received: from [10.224.32.173] (Forwarded-For: 199.226.82.164, [10.224.32.173]) by mail13.int.dr1.us.army.mil (mshttpd); Mon, 10 May 2010 10:37:31 -0400 To: Paul Kyzivat Message-ID: Date: Mon, 10 May 2010 10:37:31 -0400 X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.01 (built Dec 5 2007; 32bit) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <4BE81570.5080803@cisco.com> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 14:37:58 -0000 Hi, Paul K. Does it not mean that the very concept of Box is misleading? In summary, does it not mean that we should rather keep our focus on "Agent" as a point of basic reference that controls Domain? Best regards, Radhika ----- Original Message ----- From: Paul Kyzivat Date: Monday, May 10, 2010 10:17 Subject: Re: [sipcore] draft-jones-sip-options-ping-01 To: Hadriel Kaplan Cc: "Paul E. Jones" , "sipcore@ietf.org" > Inline... > > Hadriel Kaplan wrote: > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, May 07, 2010 12:58 PM > >> > >> My point was that there currently is no consistent and well > known way of > >> identifying "the box". There isn't even a *notion* of > addressing "the > >> box", as distinct from any of the resources it manages. > >> One answer is that if you want to ping something, you need to find > >> something to ping that has the properties you want, and that > will be > >> identified by *some* URI, but not the same one for every box, > and maybe > >> none for some boxes. So you need to find out by provisioning > what it is > >> that you should address your pings to. > >> > >> I don't find that answer very satisfying. > > > > Me neither. > > > > > >> I do however appreciate the points that Cullen has raised, and > would>> like to see them addressed before we go much further with > this.> > > Although I agree that the overload-chartered work is meant to > improve things from the on/off flapping model we have today, I > don't see how that invalidates the need or value of clearing up > OPTIONS. In some ways it's orthogonal, because the addressing > problem still exists for OPTIONS regardless. > > > > For sake of argument, ignore the "ping" aspect of OPTIONS. > Let's just say you wanted to send an OPTIONS to a SIP device > (proxy, B2BUA, or UA) to learn its capabilities - the *system's* > capabilities, not a particular user instance in it. How would you > do that? In practice today: through manual configuration. So > let's say we went and created a draft to fix that, by using a new > header. In that same draft, we re-iterated or clarified what the > responses to such a query would mean. In effect, that's Paul's draft. > > My counter-argument here is that the "system capabilities of a > box" > isn't necessarily a well defined concept. There may just be a > multiplexer, based on the user part of the uri, to a variety of > software > agents. So no matter what you address the request to you are > actually > getting the status of one software agent or another, not of the > box as a > whole. > > I interpret 3261 as saying the those elements "responsible for a > domain" > are the masters of the URIs that are valid in that domain. Others, > that > are not responsible for the domain, have no business "fabricating" > a URI > by pasting together a user part of their choice with the domain > name. > Instead they should be using addresses that are "given to them" > directly > or indirectly by an "agent" of the domain. > > There is one case I know of where that is formally not the case. > It is > when using REGISTER, where a sip URI without user part is the R- > URI. > That is a restriction for domains that support REGISTER, and > potentially > may apply only to REGISTER. > > Of course, this philosophy is violated all over the place. It can > be > justified in some cases as a matter that in some cases knowledge > of the > policy of a particular domain may extend to elements beyond those > "responsible for the domain". But that still doesn't justify > making such > assumptions about a domain you have no special information about. > > (And of course you an violate this is you are prepared for the > consequences. If I didn't know Hadriel's sip URI, I might just try > a > variety of user parts in sip:*@acmepacket.com it hopes of guessing > it.) > I think it is a big philosophical step to say that there is a > reserved > sip uri that will be serviced by *something* that can speak for > the box > as a whole. > > > Furthermore, if we cleared up how OPTIONS can be addressed, one > could use an OPTIONS to exchange the new overload info. And > likewise, a SUBSCRIBE for overload info has the same issues > OPTIONS does in terms of addressing. > > I wonder if that doesn't have some of the same issues - that a box > may > server as a multiplexer for a number of software agents. Much or > all of > the "overload" attributes may be attributable to those software > agents, > not to the box in general. I can certainly imagine architectures > where > requests to sip:X@example.com is overloaded, while requests to > sip:Y@example.com is not overloaded. > > But I haven't been party to the overload work, so I don't know > what the > thinking is like in that regard. > > To me this seems like a reason to include the ping clarification > (at > least with respect "addressing the box") into the overload work. > And to > a certain extent that may also be true for the question of > inconsistent > responses to conditions, since the inconsistent responses of > concern are > all (I think) related to overload and up/down type conditions. > > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From paulej@packetizer.com Mon May 10 12:40:04 2010 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 F130F3A6BE7 for ; Mon, 10 May 2010 12:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=-0.719, 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 TjHlGjS-Qm38 for ; Mon, 10 May 2010 12:40:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 868F93A6BED for ; Mon, 10 May 2010 12:27:14 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o4AJQtIF028800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 15:27:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273519621; bh=Uuo4NMA+B3+Mg5lxllwOAIfmdZdslSNbWKaVlOgv4/A=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=AQp615AaokyaM0jxph8z5CHE6Q1vY8lQLH+g6kbXblkMymiBF0O23vpuUF1dQ80Al tssii46h0g+8wUUFHwqeaaqpVl1UTueO1IwJh0/Qa+UmOtspOzT/DN5sFDAZCnLrVU QdFL0yBJ2VuOUMaYVRGgy0KdoyoiccQObQpr4fbg= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o4AJQrHY022915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 May 2010 15:26:53 -0400 From: "Paul E. Jones" To: "'Roy, Radhika R Dr CIV USA USAMC'" , "'Paul Kyzivat'" References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> In-Reply-To: Date: Mon, 10 May 2010 15:26:50 -0400 Message-ID: <00d901caf076$bdd21770$39764650$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcrwTmGogFNPl9ZIQdagvDYsz7f3jgAJSBFA Content-Language: en-us Cc: sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 19:40:04 -0000 Radhika, Paul, I agree that the concept of a "box" is vague. There is, though, an addressable user agent to which we can send an OPTIONS message to query for its operational status. Within the subject draft, that's what we propose to do. Perhaps even using the word "propose" is not accurate, as this draft was written in response to what clearly appears to be behavior already widely implemented. Unfortunately, it's not consistently implemented. For example, some devices return a 486, 503, or even 600 when they wish to report that they're in an state where they cannot accept new dialogs. I believe work on overload is important, but the purpose of overload is rather different than sending an OPTIONS to a user agent to determine its operational state. The work on "keep" is also important, but the focus of this draft is not to maintain open pinholes through a firewall. The scope of the subject draft is purposely narrow. Arguably, it's not needed since RFC 3261 already defines these procedures. Our assertion, though, is that RFC 3261 does not go far enough in providing clarity so as to ensure that the response to an OPTIONS "ping" is meaningful. Perhaps this draft doesn't, either, but recognize that this is just a draft and we're prepared to make changes to improve clarity. Paul > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Roy, Radhika R Dr CIV USA USAMC > Sent: Monday, May 10, 2010 10:38 AM > To: Paul Kyzivat > Cc: Paul E. Jones; sipcore@ietf.org; Hadriel Kaplan > Subject: Re: [sipcore] draft-jones-sip-options-ping-01 > > Hi, Paul K. > > Does it not mean that the very concept of Box is misleading? > > In summary, does it not mean that we should rather keep our focus on > "Agent" as a point of basic reference that controls Domain? > > Best regards, > Radhika > > ----- Original Message ----- > From: Paul Kyzivat > Date: Monday, May 10, 2010 10:17 > Subject: Re: [sipcore] draft-jones-sip-options-ping-01 > To: Hadriel Kaplan > Cc: "Paul E. Jones" , "sipcore@ietf.org" > > > > > Inline... > > > > Hadriel Kaplan wrote: > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Friday, May 07, 2010 12:58 PM > > >> > > >> My point was that there currently is no consistent and well > > known way of > > >> identifying "the box". There isn't even a *notion* of > > addressing "the > > >> box", as distinct from any of the resources it manages. > > >> One answer is that if you want to ping something, you need to find > > >> something to ping that has the properties you want, and that > > will be > > >> identified by *some* URI, but not the same one for every box, > > and maybe > > >> none for some boxes. So you need to find out by provisioning > > what it is > > >> that you should address your pings to. > > >> > > >> I don't find that answer very satisfying. > > > > > > Me neither. > > > > > > > > >> I do however appreciate the points that Cullen has raised, and > > would>> like to see them addressed before we go much further with > > this.> > > > Although I agree that the overload-chartered work is meant to > > improve things from the on/off flapping model we have today, I > > don't see how that invalidates the need or value of clearing up > > OPTIONS. In some ways it's orthogonal, because the addressing > > problem still exists for OPTIONS regardless. > > > > > > For sake of argument, ignore the "ping" aspect of OPTIONS. > > Let's just say you wanted to send an OPTIONS to a SIP device > > (proxy, B2BUA, or UA) to learn its capabilities - the *system's* > > capabilities, not a particular user instance in it. How would you > > do that? In practice today: through manual configuration. So > > let's say we went and created a draft to fix that, by using a new > > header. In that same draft, we re-iterated or clarified what the > > responses to such a query would mean. In effect, that's Paul's draft. > > > > My counter-argument here is that the "system capabilities of a > > box" > > isn't necessarily a well defined concept. There may just be a > > multiplexer, based on the user part of the uri, to a variety of > > software > > agents. So no matter what you address the request to you are > > actually > > getting the status of one software agent or another, not of the > > box as a > > whole. > > > > I interpret 3261 as saying the those elements "responsible for a > > domain" > > are the masters of the URIs that are valid in that domain. Others, > > that > > are not responsible for the domain, have no business "fabricating" > > a URI > > by pasting together a user part of their choice with the domain > > name. > > Instead they should be using addresses that are "given to them" > > directly > > or indirectly by an "agent" of the domain. > > > > There is one case I know of where that is formally not the case. > > It is > > when using REGISTER, where a sip URI without user part is the R- > > URI. > > That is a restriction for domains that support REGISTER, and > > potentially > > may apply only to REGISTER. > > > > Of course, this philosophy is violated all over the place. It can > > be > > justified in some cases as a matter that in some cases knowledge > > of the > > policy of a particular domain may extend to elements beyond those > > "responsible for the domain". But that still doesn't justify > > making such > > assumptions about a domain you have no special information about. > > > > (And of course you an violate this is you are prepared for the > > consequences. If I didn't know Hadriel's sip URI, I might just try > > a > > variety of user parts in sip:*@acmepacket.com it hopes of guessing > > it.) > > I think it is a big philosophical step to say that there is a > > reserved > > sip uri that will be serviced by *something* that can speak for > > the box > > as a whole. > > > > > Furthermore, if we cleared up how OPTIONS can be addressed, one > > could use an OPTIONS to exchange the new overload info. And > > likewise, a SUBSCRIBE for overload info has the same issues > > OPTIONS does in terms of addressing. > > > > I wonder if that doesn't have some of the same issues - that a box > > may > > server as a multiplexer for a number of software agents. Much or > > all of > > the "overload" attributes may be attributable to those software > > agents, > > not to the box in general. I can certainly imagine architectures > > where > > requests to sip:X@example.com is overloaded, while requests to > > sip:Y@example.com is not overloaded. > > > > But I haven't been party to the overload work, so I don't know > > what the > > thinking is like in that regard. > > > > To me this seems like a reason to include the ping clarification > > (at > > least with respect "addressing the box") into the overload work. > > And to > > a certain extent that may also be true for the question of > > inconsistent > > responses to conditions, since the inconsistent responses of > > concern are > > all (I think) related to overload and up/down type conditions. > > > > Thanks, > > Paul > > _______________________________________________ > > 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 May 10 13:01:02 2010 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 5DD2F3A6CD2 for ; Mon, 10 May 2010 13:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.262 X-Spam-Level: X-Spam-Status: No, score=-10.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 ZjZeFV-Cds7i for ; Mon, 10 May 2010 13:01:01 -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 BD9DD28C267 for ; Mon, 10 May 2010 12:49:32 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM//50tAZnwM/2dsb2JhbACeInGjNplJhRQE X-IronPort-AV: E=Sophos;i="4.52,364,1270425600"; d="scan'208";a="109778668" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 May 2010 19:49:21 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4AJnLdo016083; Mon, 10 May 2010 19:49:21 GMT Message-ID: <4BE86339.6020709@cisco.com> Date: Mon, 10 May 2010 15:49:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> In-Reply-To: <00d901caf076$bdd21770$39764650$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, "'Roy, Radhika R Dr CIV USA USAMC'" , 'Hadriel Kaplan' Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 20:01:02 -0000 Paul E. Jones wrote: > Radhika, Paul, > > I agree that the concept of a "box" is vague. There is, though, an > addressable user agent to which we can send an OPTIONS message to query for > its operational status. Within the subject draft, that's what we propose to > do. > > Perhaps even using the word "propose" is not accurate, as this draft was > written in response to what clearly appears to be behavior already widely > implemented. Unfortunately, it's not consistently implemented. For > example, some devices return a 486, 503, or even 600 when they wish to > report that they're in an state where they cannot accept new dialogs. > > I believe work on overload is important, but the purpose of overload is > rather different than sending an OPTIONS to a user agent to determine its > operational state. I'm still struggling to understand the difference. With overload control the sender is trying to avoid sending to a box that is "overloaded". In the extreme, and overloaded box is pretty similar to a "down" box. We also want to avoid sending messages to a "down" box. And overload status may come in degrees. So when given a choice, the sender may choose to send to the "least loaded" box. So using OPTIONS to determine this sort of thing is pretty closely aligned with overload control. What are the other uses of OPTIONS ping that are *not* in this category? > The work on "keep" is also important, but the focus of > this draft is not to maintain open pinholes through a firewall. > > The scope of the subject draft is purposely narrow. Arguably, it's not > needed since RFC 3261 already defines these procedures. Our assertion, > though, is that RFC 3261 does not go far enough in providing clarity so as > to ensure that the response to an OPTIONS "ping" is meaningful. Perhaps > this draft doesn't, either, but recognize that this is just a draft and > we're prepared to make changes to improve clarity. At this point I think several people seem to have somewhat different conceptions of what is missing and what is needed. There may indeed be a need here. It just seems like so far we have a solution proposed while we as yet don't have clarity on what it is the solution *to*. Thanks, Paul > Paul > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Roy, Radhika R Dr CIV USA USAMC >> Sent: Monday, May 10, 2010 10:38 AM >> To: Paul Kyzivat >> Cc: Paul E. Jones; sipcore@ietf.org; Hadriel Kaplan >> Subject: Re: [sipcore] draft-jones-sip-options-ping-01 >> >> Hi, Paul K. >> >> Does it not mean that the very concept of Box is misleading? >> >> In summary, does it not mean that we should rather keep our focus on >> "Agent" as a point of basic reference that controls Domain? >> >> Best regards, >> Radhika >> >> ----- Original Message ----- >> From: Paul Kyzivat >> Date: Monday, May 10, 2010 10:17 >> Subject: Re: [sipcore] draft-jones-sip-options-ping-01 >> To: Hadriel Kaplan >> Cc: "Paul E. Jones" , "sipcore@ietf.org" >> >> >> >>> Inline... >>> >>> Hadriel Kaplan wrote: >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Friday, May 07, 2010 12:58 PM >>>>> >>>>> My point was that there currently is no consistent and well >>> known way of >>>>> identifying "the box". There isn't even a *notion* of >>> addressing "the >>>>> box", as distinct from any of the resources it manages. >>>>> One answer is that if you want to ping something, you need to find >>>>> something to ping that has the properties you want, and that >>> will be >>>>> identified by *some* URI, but not the same one for every box, >>> and maybe >>>>> none for some boxes. So you need to find out by provisioning >>> what it is >>>>> that you should address your pings to. >>>>> >>>>> I don't find that answer very satisfying. >>>> Me neither. >>>> >>>> >>>>> I do however appreciate the points that Cullen has raised, and >>> would>> like to see them addressed before we go much further with >>> this.> >>>> Although I agree that the overload-chartered work is meant to >>> improve things from the on/off flapping model we have today, I >>> don't see how that invalidates the need or value of clearing up >>> OPTIONS. In some ways it's orthogonal, because the addressing >>> problem still exists for OPTIONS regardless. >>>> For sake of argument, ignore the "ping" aspect of OPTIONS. >>> Let's just say you wanted to send an OPTIONS to a SIP device >>> (proxy, B2BUA, or UA) to learn its capabilities - the *system's* >>> capabilities, not a particular user instance in it. How would you >>> do that? In practice today: through manual configuration. So >>> let's say we went and created a draft to fix that, by using a new >>> header. In that same draft, we re-iterated or clarified what the >>> responses to such a query would mean. In effect, that's Paul's draft. >>> >>> My counter-argument here is that the "system capabilities of a >>> box" >>> isn't necessarily a well defined concept. There may just be a >>> multiplexer, based on the user part of the uri, to a variety of >>> software >>> agents. So no matter what you address the request to you are >>> actually >>> getting the status of one software agent or another, not of the >>> box as a >>> whole. >>> >>> I interpret 3261 as saying the those elements "responsible for a >>> domain" >>> are the masters of the URIs that are valid in that domain. Others, >>> that >>> are not responsible for the domain, have no business "fabricating" >>> a URI >>> by pasting together a user part of their choice with the domain >>> name. >>> Instead they should be using addresses that are "given to them" >>> directly >>> or indirectly by an "agent" of the domain. >>> >>> There is one case I know of where that is formally not the case. >>> It is >>> when using REGISTER, where a sip URI without user part is the R- >>> URI. >>> That is a restriction for domains that support REGISTER, and >>> potentially >>> may apply only to REGISTER. >>> >>> Of course, this philosophy is violated all over the place. It can >>> be >>> justified in some cases as a matter that in some cases knowledge >>> of the >>> policy of a particular domain may extend to elements beyond those >>> "responsible for the domain". But that still doesn't justify >>> making such >>> assumptions about a domain you have no special information about. >>> >>> (And of course you an violate this is you are prepared for the >>> consequences. If I didn't know Hadriel's sip URI, I might just try >>> a >>> variety of user parts in sip:*@acmepacket.com it hopes of guessing >>> it.) >>> I think it is a big philosophical step to say that there is a >>> reserved >>> sip uri that will be serviced by *something* that can speak for >>> the box >>> as a whole. >>> >>>> Furthermore, if we cleared up how OPTIONS can be addressed, one >>> could use an OPTIONS to exchange the new overload info. And >>> likewise, a SUBSCRIBE for overload info has the same issues >>> OPTIONS does in terms of addressing. >>> >>> I wonder if that doesn't have some of the same issues - that a box >>> may >>> server as a multiplexer for a number of software agents. Much or >>> all of >>> the "overload" attributes may be attributable to those software >>> agents, >>> not to the box in general. I can certainly imagine architectures >>> where >>> requests to sip:X@example.com is overloaded, while requests to >>> sip:Y@example.com is not overloaded. >>> >>> But I haven't been party to the overload work, so I don't know >>> what the >>> thinking is like in that regard. >>> >>> To me this seems like a reason to include the ping clarification >>> (at >>> least with respect "addressing the box") into the overload work. >>> And to >>> a certain extent that may also be true for the question of >>> inconsistent >>> responses to conditions, since the inconsistent responses of >>> concern are >>> all (I think) related to overload and up/down type conditions. >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> 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 May 10 14:10:42 2010 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 0C6973A6A55 for ; Mon, 10 May 2010 14:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 JrDDynm+3OaU for ; Mon, 10 May 2010 14:10:40 -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 36D443A68B5 for ; Mon, 10 May 2010 14:10:03 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJkS6EtAZnwN/2dsb2JhbACeI3GifplOhRQE X-IronPort-AV: E=Sophos;i="4.53,202,1272844800"; d="scan'208";a="109802692" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 May 2010 21:09:51 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4AL9pLe002602; Mon, 10 May 2010 21:09:51 GMT Message-ID: <4BE87625.30903@cisco.com> Date: Mon, 10 May 2010 17:09:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Roy, Radhika R Dr CIV USA USAMC" References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 21:10:42 -0000 Roy, Radhika R Dr CIV USA USAMC wrote: > Hi, Paul K. > > Does it not mean that the very concept of Box is misleading? There is nothing wrong with the "concept" of a box. Its just that we have no sip artifacts that correlate to a box in a consistent way across implementations. > In summary, does it not mean that we should rather keep our focus on "Agent" as a point of basic reference that controls Domain? My use of "agent" was informal. We probably have similar problems defining it. IIUC, the goal in all of this is to provide information via one request to some sip URI that is useful for predicting future behavior for some set of sip methods sent to some set of sip URIs. The trick is identifying the mapping between the set of things you are interested in predicting the behavior of and the address you send the query to. To get very far with this I think it will be necessary to restrict the architectures it applies to. Maybe there is some set of assumptions that are valid across a broad range of interesting implementations, or not. That may become apparent by trying to get agreement on what those assumptions are. Thanks, Paul > Best regards, > Radhika > > ----- Original Message ----- > From: Paul Kyzivat > Date: Monday, May 10, 2010 10:17 > Subject: Re: [sipcore] draft-jones-sip-options-ping-01 > To: Hadriel Kaplan > Cc: "Paul E. Jones" , "sipcore@ietf.org" > > >> Inline... >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Friday, May 07, 2010 12:58 PM >>>> >>>> My point was that there currently is no consistent and well >> known way of >>>> identifying "the box". There isn't even a *notion* of >> addressing "the >>>> box", as distinct from any of the resources it manages. >>>> One answer is that if you want to ping something, you need to find >>>> something to ping that has the properties you want, and that >> will be >>>> identified by *some* URI, but not the same one for every box, >> and maybe >>>> none for some boxes. So you need to find out by provisioning >> what it is >>>> that you should address your pings to. >>>> >>>> I don't find that answer very satisfying. >>> Me neither. >>> >>> >>>> I do however appreciate the points that Cullen has raised, and >> would>> like to see them addressed before we go much further with >> this.> >>> Although I agree that the overload-chartered work is meant to >> improve things from the on/off flapping model we have today, I >> don't see how that invalidates the need or value of clearing up >> OPTIONS. In some ways it's orthogonal, because the addressing >> problem still exists for OPTIONS regardless. >>> For sake of argument, ignore the "ping" aspect of OPTIONS. >> Let's just say you wanted to send an OPTIONS to a SIP device >> (proxy, B2BUA, or UA) to learn its capabilities - the *system's* >> capabilities, not a particular user instance in it. How would you >> do that? In practice today: through manual configuration. So >> let's say we went and created a draft to fix that, by using a new >> header. In that same draft, we re-iterated or clarified what the >> responses to such a query would mean. In effect, that's Paul's draft. >> >> My counter-argument here is that the "system capabilities of a >> box" >> isn't necessarily a well defined concept. There may just be a >> multiplexer, based on the user part of the uri, to a variety of >> software >> agents. So no matter what you address the request to you are >> actually >> getting the status of one software agent or another, not of the >> box as a >> whole. >> >> I interpret 3261 as saying the those elements "responsible for a >> domain" >> are the masters of the URIs that are valid in that domain. Others, >> that >> are not responsible for the domain, have no business "fabricating" >> a URI >> by pasting together a user part of their choice with the domain >> name. >> Instead they should be using addresses that are "given to them" >> directly >> or indirectly by an "agent" of the domain. >> >> There is one case I know of where that is formally not the case. >> It is >> when using REGISTER, where a sip URI without user part is the R- >> URI. >> That is a restriction for domains that support REGISTER, and >> potentially >> may apply only to REGISTER. >> >> Of course, this philosophy is violated all over the place. It can >> be >> justified in some cases as a matter that in some cases knowledge >> of the >> policy of a particular domain may extend to elements beyond those >> "responsible for the domain". But that still doesn't justify >> making such >> assumptions about a domain you have no special information about. >> >> (And of course you an violate this is you are prepared for the >> consequences. If I didn't know Hadriel's sip URI, I might just try >> a >> variety of user parts in sip:*@acmepacket.com it hopes of guessing >> it.) >> I think it is a big philosophical step to say that there is a >> reserved >> sip uri that will be serviced by *something* that can speak for >> the box >> as a whole. >> >>> Furthermore, if we cleared up how OPTIONS can be addressed, one >> could use an OPTIONS to exchange the new overload info. And >> likewise, a SUBSCRIBE for overload info has the same issues >> OPTIONS does in terms of addressing. >> >> I wonder if that doesn't have some of the same issues - that a box >> may >> server as a multiplexer for a number of software agents. Much or >> all of >> the "overload" attributes may be attributable to those software >> agents, >> not to the box in general. I can certainly imagine architectures >> where >> requests to sip:X@example.com is overloaded, while requests to >> sip:Y@example.com is not overloaded. >> >> But I haven't been party to the overload work, so I don't know >> what the >> thinking is like in that regard. >> >> To me this seems like a reason to include the ping clarification >> (at >> least with respect "addressing the box") into the overload work. >> And to >> a certain extent that may also be true for the question of >> inconsistent >> responses to conditions, since the inconsistent responses of >> concern are >> all (I think) related to overload and up/down type conditions. >> >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From paulej@packetizer.com Mon May 10 14:28:07 2010 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 2D7973A6BF0 for ; Mon, 10 May 2010 14:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-0.799, 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 RTSZes06tw9u for ; Mon, 10 May 2010 14:28:05 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 1472E28C1E3 for ; Mon, 10 May 2010 14:25:58 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o4ALPdM0004203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 17:25:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273526745; bh=RaWm26oAu/s6hN8e+k1yWS1Jlx4hBmz1VZGKy+M5RGM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jqdsrYygEpjxyN4P0yNiMbNbxZLjioQVP4PwyAifhLhb0bk3eBO1emKwhr+VkrqJu p8fcaT/qHGMvJhbTJ86I32u2Zim/y2DSTXD0xH7rQKbh8ftupcK9S02j/td57yNSjY FOENOriO1V02qQdxBgFXQLHPexoYsqWX61jJR2Lw= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o4ALPbVk023343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 May 2010 17:25:37 -0400 From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> In-Reply-To: <4BE86339.6020709@cisco.com> Date: Mon, 10 May 2010 17:25:34 -0400 Message-ID: <010501caf087$53ff6c60$fbfe4520$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcrweeZcOnUADXkqRO+hQVeFIQLGOwABvqwQ Content-Language: en-us Cc: sipcore@ietf.org, "'Roy, Radhika R Dr CIV USA USAMC'" , 'Hadriel Kaplan' Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 21:28:07 -0000 Paul, > > I believe work on overload is important, but the purpose of overload > is > > rather different than sending an OPTIONS to a user agent to determine > its > > operational state. > > I'm still struggling to understand the difference. > With overload control the sender is trying to avoid sending to a box > that is "overloaded". In the extreme, and overloaded box is pretty > similar to a "down" box. We also want to avoid sending messages to a > "down" box. The OPTIONS method is not used only to determine is a user agent is overloaded. This is just one example we've discussed. We're not proposing to make fine-grained routing decisions based over the results of an OPTIONS response, though it certainly has some utility for helping to facilitate traffic. Not all devices need the same level of granularity and responsiveness as what might be provided via overload. Even so, a service provider would likely appreciate knowing a box is currently in a maintenance state so as to not waste time directing traffic to a known-down device. A 503 could tell the administrator that there is an issue and that code would also be used when an administrator takes a box down for maintenance (as per 3261). Most certainly, a 500 likely would mean there is a problem that needs immediate attention. So, it has management value. The OPTIONS "ping" could be used to check the status of an IP phone or ATA device, neither of which are likely to implement the overload spec. A service provider may not be very interested to know whether a small business SBC is overloaded or not, but it might want to know whether it's responsive in the least and what status it is reporting presently. Even in cases where two peer SBCs might want to know overload information, that does not eliminate the desire for an administrative device to also want to collect status information. Managed service providers would likely want to keep close tabs on the current state of a PBX or SBC, but that information may or may not be collected by an SBC. > And overload status may come in degrees. So when given a choice, the > sender may choose to send to the "least loaded" box. Yeah, and that's not what we're trying to address. > So using OPTIONS to determine this sort of thing is pretty closely > aligned with overload control. What are the other uses of OPTIONS ping > that are *not* in this category? See above. > > The work on "keep" is also important, but the focus of > > this draft is not to maintain open pinholes through a firewall. > > > > The scope of the subject draft is purposely narrow. Arguably, it's > not > > needed since RFC 3261 already defines these procedures. Our > assertion, > > though, is that RFC 3261 does not go far enough in providing clarity > so as > > to ensure that the response to an OPTIONS "ping" is meaningful. > Perhaps > > this draft doesn't, either, but recognize that this is just a draft > and > > we're prepared to make changes to improve clarity. > > At this point I think several people seem to have somewhat different > conceptions of what is missing and what is needed. There may indeed be > a > need here. It just seems like so far we have a solution proposed while > we as yet don't have clarity on what it is the solution *to*. For a variety of reasons (as mentioned above), there is a desire to learn the operational status of a given user agent. The method through which one accomplishes this task is by sending an OPTIONS message as per RFC 3261. This will report whether the device is operational (200) or overloaded or down for maintenance (503). In practice, though, we see lots of response codes returned, just for these two basic states. Since there are so many varied implementations all over the map, a desire was expressed to be able to differentiate an OPTIONS "ping" from an OPTIONS intended to query device capabilities. Personally, I would make no distinction in my code, but the fact is that we're dealing with an aging protocol with a lot of legacy implementations we need to consider. Therefore, I conceded on the request to make a distinction by including a header (of some sort) to indicate that the message is a "ping". For those who do wish to implement two code paths in order to support different behavior, they could use that header to do that. On that point, I don't really care so much: I'd encourage a single behavior, but I'm not going to argue with folks who clearly see value in having something to use as a differentiator: if they see a need, then one likely exists. The bottom line is that we're not trying to define anything not already defined in RFC 3261. What we are trying to do is improve upon that text by recommending response codes and clarifying the fact that OPTIONS may be used for this purpose. If we do not move forward with this draft, then we just live with the varied implementations. I do not think the work on overload will likely eliminate use of the OPTIONS "ping" for the aforementioned use cases, so we'll continue to see varying behavior. Paul From dean.willis@softarmor.com Mon May 10 14:59:09 2010 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 A91E33A6C0E for ; Mon, 10 May 2010 14:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-0.723, 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 doeQoOcUE7U6 for ; Mon, 10 May 2010 14:59:09 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AD0D528C0D7 for ; Mon, 10 May 2010 14:59:03 -0700 (PDT) Received: from [192.168.2.2] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4ALwlIq012684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 May 2010 16:58:48 -0500 Message-ID: <4BE88192.8030800@softarmor.com> Date: Mon, 10 May 2010 16:58:42 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: "Paul E. Jones" References: <4BD58D45.3000709@cisco.com> <004f01cae641$4e690a90$eb3b1fb0$@com> <4BD73FE1.7050105@cisco.com> <005b01cae646$9892b0d0$c9b81270$@com> <4BD76496.50905@cisco.com> <005301cae68b$8f7d8110$ae788330$@com> <1BDEDBAC-7959-4767-85EA-BCF3E9D6C746@softarmor.com> <00da01cae72e$4f5590c0$ee00b240$@com> <8748ED98-3A25-4E30-B9D7-FE0C08ECA33B@softarmor.com> <010901cae73a$766dfec0$6349fc40$@com> In-Reply-To: <010901cae73a$766dfec0$6349fc40$@com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Michael Miller' , sipcore@ietf.org, 'Hadriel Kaplan' Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.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, 10 May 2010 21:59:09 -0000 Paul E. Jones wrote: > Dean, > >> So for example, a new header field "Options-mode" with a value of >> "ping" means "If you support this extension, do not proxy this >> request, just send an immediate 200 OK response and do not bother >> populating the Supported header field of the 200 OK response." >> Somebody who didn't recognize the header field would just send a >> conventional 200 OK response. > > Not objecting to the header, but I think we would have failed in our effort > if the message might possibly be proxied. The intent was for this to be > peer-to-peer. Then a header, combined with an options-tag used in a Prcy-Require" would do the job. > >> And perhaps an option tag of "optionsmodeping". That way we can add >> further options-modes, and option tags for them in the future as (and >> if) needed. > > So, you want a head like this: > > Options-Mode: ping > > Or this: > > Require: optionsmodeping Both. And a Proxy-Require: optionmsmodeping to make sure that proxies that understand Options-Mode: ping don't forward. -- Dean From dean.willis@softarmor.com Mon May 10 15:19:46 2010 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 F05913A69CE for ; Mon, 10 May 2010 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.588, 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 6qt1eOynwQzG for ; Mon, 10 May 2010 15:19:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 187273A68AE for ; Mon, 10 May 2010 15:19:44 -0700 (PDT) Received: from [192.168.2.2] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4AMJTnM012892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 May 2010 17:19:30 -0500 Message-ID: <4BE8866B.2020205@softarmor.com> Date: Mon, 10 May 2010 17:19:23 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: "Paul E. Jones" References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> In-Reply-To: <00d901caf076$bdd21770$39764650$@com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, "'Roy, Radhika R Dr CIV USA USAMC'" , 'Hadriel Kaplan' Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 22:19:46 -0000 Paul E. Jones wrote: > Radhika, Paul, > > I agree that the concept of a "box" is vague. There is, though, an > addressable user agent to which we can send an OPTIONS message to query for > its operational status. Within the subject draft, that's what we propose to > do. > The problem is that sip"alice@192.168.3.1", "sip:bob@192.168.3.1", "sip:charlie@192.168.3.1", and "sip:ping@192.168.3.1" might actually be four different SIP user agent instances, using four different software stacks, all being demuxed by an independent proxy module running on port 5060 of "192.168.3.1", which might also be a UA for "sip:admin@192.168.3.1" (or something entirely different), meaning that it too isn't "just a proxy". Which piece of software did you want to have answer the "ping" and how is this not somehow different real behavior from what RFC 3261 says? We can certainly alter the behavior of OPTIONS using option-tags and headers. But this doesn't make it "automatically work" when the recipient doesn't understand the extension. Rather, it makes the request automatically (and detectably) fail, so that the UAC sending the OPTIONS request can fall back to sending an old-fashioned OPTIONS if it wants to. -- Dean From pkyzivat@cisco.com Mon May 10 15:33:49 2010 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 6C6393A6A92 for ; Mon, 10 May 2010 15:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.962 X-Spam-Level: X-Spam-Status: No, score=-8.962 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_50=0.001, 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 7lq4aKvkfPoj for ; Mon, 10 May 2010 15:33: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 DE1FA3A6A1A for ; Mon, 10 May 2010 15:33:47 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHwm6EtAZnwN/2dsb2JhbACeJHGiMJljhRQE X-IronPort-AV: E=Sophos;i="4.53,203,1272844800"; d="scan'208";a="109826124" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 May 2010 22:33:36 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4AMXaE5025691; Mon, 10 May 2010 22:33:36 GMT Message-ID: <4BE889BD.2030901@cisco.com> Date: Mon, 10 May 2010 18:33:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> In-Reply-To: <010501caf087$53ff6c60$fbfe4520$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, "'Roy, Radhika R Dr CIV USA USAMC'" , 'Hadriel Kaplan' Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 22:33:49 -0000 Paul E. Jones wrote: > Paul, > >>> I believe work on overload is important, but the purpose of overload >> is >>> rather different than sending an OPTIONS to a user agent to determine >> its >>> operational state. >> I'm still struggling to understand the difference. >> With overload control the sender is trying to avoid sending to a box >> that is "overloaded". In the extreme, and overloaded box is pretty >> similar to a "down" box. We also want to avoid sending messages to a >> "down" box. > > The OPTIONS method is not used only to determine is a user agent is > overloaded. This is just one example we've discussed. I think you are viewing "overload" more narrowly than I am. > We're not proposing to make fine-grained routing decisions based over the > results of an OPTIONS response, though it certainly has some utility for > helping to facilitate traffic. Not all devices need the same level of > granularity and responsiveness as what might be provided via overload. Even > so, a service provider would likely appreciate knowing a box is currently in > a maintenance state so as to not waste time directing traffic to a > known-down device. A box in maintenance state is effectively "down" if it won't accept additional calls. Though this may be subtle if it will still accept some class of requests, such as those that are in-dialog, while rejecting others. But "wasting time" directing traffic to known-down devices is, AFAIK, a valid subject for overload control, since it loads the network and the sending device. Maybe it is not part of the currently planned work on overload control. But if not, then I would argue that we should consider broadening the charter of that WG, rather than inventing an entirely separate solution to another aspect of the same problem space. > A 503 could tell the administrator that there is an issue and that code > would also be used when an administrator takes a box down for maintenance > (as per 3261). Most certainly, a 500 likely would mean there is a problem > that needs immediate attention. So, it has management value. A 500 has essentially no predictive value about how other requests will be processed in the future. > The OPTIONS "ping" could be used to check the status of an IP phone or ATA > device, neither of which are likely to implement the overload spec. What would be the purpose of obtaining this information? This is one of the primary uses for OPTIONS as it is defined in 3261. Its is expected to return the same result as an INVITE would. There are many reasons why that doesn't mean as much as it might seem, but I don't think we need a lot of clarification for that usage. It might be more complicated if you don't send the OPTIONS to the same address as you would send an INVITE. That is because there is probably no particularly good answer in that case - at least without being much more precise about the intended use of the result. Even dumb devices probably should implement some limited form of overload control, once that is defined. At least enough to protect the network. > A service provider may not be very interested to know whether a small > business SBC is overloaded or not, It *ought* to be, of it isn't providing very good service. And ignoring this and as a result reaching congestion collapse isn't good for it even if it doesn't care about the PBX. > but it might want to know whether it's > responsive in the least and what status it is reporting presently. Why would it want to know one and not the other? If it doesn't care about overload control, wouldn't most likely not care whether the device is up either? If its not doing overload control, then the most interesting statistic is likely to be the number of calls delivered successfully, vs. the number that failed due to lack of response by the pbx. Sure, it might want this information just because it is "curious". But we are going to have a hard time refining the definitions of these various "states" without some notion of how they are to be used. > Even in > cases where two peer SBCs might want to know overload information, that does > not eliminate the desire for an administrative device to also want to > collect status information. Managed service providers would likely want to > keep close tabs on the current state of a PBX or SBC, but that information > may or may not be collected by an SBC. All of the above cases you are mentioning are of interest *before* nailing down the mechanism to address them. >> And overload status may come in degrees. So when given a choice, the >> sender may choose to send to the "least loaded" box. > > Yeah, and that's not what we're trying to address. > >> So using OPTIONS to determine this sort of thing is pretty closely >> aligned with overload control. What are the other uses of OPTIONS ping >> that are *not* in this category? > > See above. > >>> The work on "keep" is also important, but the focus of >>> this draft is not to maintain open pinholes through a firewall. >>> >>> The scope of the subject draft is purposely narrow. Arguably, it's >> not >>> needed since RFC 3261 already defines these procedures. Our >> assertion, >>> though, is that RFC 3261 does not go far enough in providing clarity >> so as >>> to ensure that the response to an OPTIONS "ping" is meaningful. >> Perhaps >>> this draft doesn't, either, but recognize that this is just a draft >> and >>> we're prepared to make changes to improve clarity. >> At this point I think several people seem to have somewhat different >> conceptions of what is missing and what is needed. There may indeed be >> a >> need here. It just seems like so far we have a solution proposed while >> we as yet don't have clarity on what it is the solution *to*. > > For a variety of reasons (as mentioned above), there is a desire to learn > the operational status of a given user agent. I do believe there are a number of good reasons to want to know "operational status". I think most of them have to do with wanting to predict certain aspects of future behavior. But the devil is in the details: what aspects of future behavior do you wish to predict? What information would be useful for making that prediction? And who has that information? The response code to an OPTIONS request will have some limited predictive value. Will refining the way options responses are made improve that predictive value? Will it provide predictive value that is needed and not already available? Maybe, but I don't really know. Only if we know what kinds of predictions are to be made will we be able to determine that. And that is exactly the info that I am not seeing so far. Thanks, Paul K > The method through which one > accomplishes this task is by sending an OPTIONS message as per RFC 3261. > This will report whether the device is operational (200) or overloaded or > down for maintenance (503). In practice, though, we see lots of response > codes returned, just for these two basic states. > > Since there are so many varied implementations all over the map, a desire > was expressed to be able to differentiate an OPTIONS "ping" from an OPTIONS > intended to query device capabilities. Personally, I would make no > distinction in my code, but the fact is that we're dealing with an aging > protocol with a lot of legacy implementations we need to consider. > Therefore, I conceded on the request to make a distinction by including a > header (of some sort) to indicate that the message is a "ping". For those > who do wish to implement two code paths in order to support different > behavior, they could use that header to do that. On that point, I don't > really care so much: I'd encourage a single behavior, but I'm not going to > argue with folks who clearly see value in having something to use as a > differentiator: if they see a need, then one likely exists. > > The bottom line is that we're not trying to define anything not already > defined in RFC 3261. What we are trying to do is improve upon that text by > recommending response codes and clarifying the fact that OPTIONS may be used > for this purpose. If we do not move forward with this draft, then we just > live with the varied implementations. I do not think the work on overload > will likely eliminate use of the OPTIONS "ping" for the aforementioned use > cases, so we'll continue to see varying behavior. > > Paul > > > From paulej@packetizer.com Mon May 10 17:28:32 2010 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 C3D873A6852 for ; Mon, 10 May 2010 17:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, J_CHICKENPOX_38=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 frMvcmP4CZwU for ; Mon, 10 May 2010 17:28:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id B2DAC3A67AD for ; Mon, 10 May 2010 17:28:31 -0700 (PDT) Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o4B0SBkj014401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 20:28:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1273537698; bh=y1JS9c3MZTc6Wp3szaYidlq04LUs+ICYZdwoIJMDMBI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Kb/hhr/jAokR+35mLFny6CqeWrFKRkfv+usd8g4HriTkbj8tYKIVzp1hNbU2LXTys u/8QDpHbKq5KeUrTzNg+0aZOreCgHiFFMTf18noSfO4gpCp81HwClsa76bIozlUzCk ZjAS8gYzBBe5l3KLT61G1v8BSWTQHX0CuxV9zeHY= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o4B0SAQi023893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 May 2010 20:28:10 -0400 From: "Paul E. Jones" To: "'Dean Willis'" References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE8866B.2020205@softarmor.com> In-Reply-To: <4BE8866B.2020205@softarmor.com> Date: Mon, 10 May 2010 20:28:07 -0400 Message-ID: <019e01caf0a0$d4a076c0$7de16440$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcrwjuKGaUr7HEgqTPC4Yh5ieNgKlAAENW1g Content-Language: en-us Cc: sipcore@ietf.org, "'Roy, Radhika R Dr CIV USA USAMC'" , 'Hadriel Kaplan' Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 00:28:32 -0000 Dean, > > I agree that the concept of a "box" is vague. There is, though, an > > addressable user agent to which we can send an OPTIONS message to > query for > > its operational status. Within the subject draft, that's what we > propose to > > do. > > > > The problem is that sip"alice@192.168.3.1", "sip:bob@192.168.3.1", > "sip:charlie@192.168.3.1", and "sip:ping@192.168.3.1" might actually be > four different SIP user agent instances, using four different software > stacks, all being demuxed by an independent proxy module running on > port > 5060 of "192.168.3.1", which might also be a UA for > "sip:admin@192.168.3.1" (or something entirely different), meaning that > it too isn't "just a proxy". What I proposed was sip:hostport. I understand that there may be a wide variation of things done in practice, but one ought to be able to expect some predictable behavior when sending an OPTIONS to 192.168.1.10 addressed to sip:192.168.1.10. > Which piece of software did you want to have answer the "ping" and how > is this not somehow different real behavior from what RFC 3261 says? Whatever software should respond to sip:192.168.1.10. I'm not proposing any behavior that is different than RFC 3261, though I am recommending the preferred form of addressing and response value. > We can certainly alter the behavior of OPTIONS using option-tags and > headers. But this doesn't make it "automatically work" when the > recipient doesn't understand the extension. Rather, it makes the > request > automatically (and detectably) fail, so that the UAC sending the > OPTIONS > request can fall back to sending an old-fashioned OPTIONS if it wants > to. I never proposed a different behavior, though some did. In that case, we could insert headers as you proposed, perhaps a header in the request and response. There were valid reasons for doing that with which I'll not argue. I recognize that it would take time be implemented widely, but I also don't see that as an issue. Remember, I'm proposing the use of this "ping" between two devices that have some general knowledge of each other. I would not expect this to be sent out over the Internet. Rather, it would be used between a management system and devices it manages or between two SBCs, etc. So, the scope is relatively narrow as compared to the interoperability requirements of sending an INVITE out over the Internet. Paul From HKaplan@acmepacket.com Mon May 10 21:14:33 2010 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 3049F28C1F9 for ; Mon, 10 May 2010 21:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 oUx+DGxCmJ4e for ; Mon, 10 May 2010 21:14:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B81F828C118 for ; Mon, 10 May 2010 21:14:26 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 00:14:15 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 00:14:15 -0400 From: Hadriel Kaplan To: Dean Willis , "Paul E. Jones" Date: Tue, 11 May 2010 00:14:13 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrwjvLQQg2/PVqrSqCsJwelW04eEQAMCFkg Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7AB3@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE8866B.2020205@softarmor.com> In-Reply-To: <4BE8866B.2020205@softarmor.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 Cc: "sipcore@ietf.org" , "'Roy, Radhika R Dr CIV USA USAMC'" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 04:14:33 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, May 10, 2010 6:19 PM > To: Paul E. Jones > Cc: 'Roy, Radhika R Dr CIV USA USAMC'; 'Paul Kyzivat'; sipcore@ietf.org; >=20 > Which piece of software did you want to have answer the "ping" and how > is this not somehow different real behavior from what RFC 3261 says? Right now, Paul is only stipulating what 3261 says, because he's proposing = using "sip:hostport" and wants to query the logical "proxy" role of the nex= t-hop. RFC 3261 section 11 says: The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to the way a Request-URI is set for a REGISTER request. =20 > We can certainly alter the behavior of OPTIONS using option-tags and > headers. But this doesn't make it "automatically work" when the > recipient doesn't understand the extension. Rather, it makes the request > automatically (and detectably) fail, so that the UAC sending the OPTIONS > request can fall back to sending an old-fashioned OPTIONS if it wants to. Paul's current draft proposes that we formulate the OPTIONS as per RFC 3261= , such that it would be interpreted as "an old-fashioned" OPTIONS. Some of us (maybe only me) feel there should be something different about t= his particular OPTIONS, because we'd like to know the OPTIONS we received, = or the response to one we sent, is actually following the draft's clarifica= tions for response codes. It doesn't *have* to do that - the whole thing c= ould be based purely on configuration; but it would be *nice* to make this = thing automatic by the existence of a header field. -hadriel From HKaplan@acmepacket.com Mon May 10 21:55:21 2010 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 1FCC13A6CA2 for ; Mon, 10 May 2010 21:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-0.950, 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 CnK39Muc1HFr for ; Mon, 10 May 2010 21:55:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 39A6D3A6AD9 for ; Mon, 10 May 2010 21:55:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 00:55:07 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 00:55:07 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Cullen Jennings Date: Tue, 11 May 2010 00:55:06 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrwkOogHcvFaGKYTfmpwrIpi0I2jQAL4bgw Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> In-Reply-To: <4BE889BD.2030901@cisco.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 Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 04:55:21 -0000 OPTIONS already exists. It is widely deployed. It is widely deployed as a= way to query system status. (Arguably more so for that than for query of a= ctual extensions/sdp/etc.) RFC 3261 specifically described this use-case f= or OPTIONS. In practice, though, it has interop issues. The interop issue= s mostly revolve around response codes and target addressing. Today, those= interop issues are resolved by manual configuration. Paul is trying to al= leviate those interop issues by recommending a particular configuration, wh= ich follows rfc3261's language. One could almost call it a BCP. (except th= e term "BCP" means something different in IETF than normal nomenclature) So he submitted a draft to do that. The response he gets is "we're working= on an overload control mechanism and this thing has a bit of that... so no= , we can't clean this up". It's like you guys are saying "Oh your arm hurts when you lift stuff? Well= we could fix that, but we're working on giving you a new hand, and that ho= lds the things you lift, so stop using your arm while we go design this new= hand for it... oh and make sure you tell the hand designers about this arm= problem...". No? -hadriel From dean.willis@softarmor.com Mon May 10 22:08:44 2010 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 1BAA43A6ADA for ; Mon, 10 May 2010 22:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 Ajiq3-05x64p for ; Mon, 10 May 2010 22:08:43 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2D47B3A69F9 for ; Mon, 10 May 2010 22:08:43 -0700 (PDT) Received: from [192.168.2.2] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4B58OJ8015666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 May 2010 00:08:28 -0500 Message-ID: <4BE8E643.3040003@softarmor.com> Date: Tue, 11 May 2010 00:08:19 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: Hadriel Kaplan References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE8866B.2020205@softarmor.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB3@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7AB3@mail> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , "'Roy, Radhika R Dr CIV USA USAMC'" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 05:08:44 -0000 Hadriel Kaplan wrote: >> We can certainly alter the behavior of OPTIONS using option-tags >> and headers. But this doesn't make it "automatically work" when the >> recipient doesn't understand the extension. Rather, it makes the >> request automatically (and detectably) fail, so that the UAC >> sending the OPTIONS request can fall back to sending an >> old-fashioned OPTIONS if it wants to. > > Paul's current draft proposes that we formulate the OPTIONS as per > RFC 3261, such that it would be interpreted as "an old-fashioned" > OPTIONS. If it's also being responded too as an old-fashioned OPTIONS and is consistent with the content-rules of an old-fashioned OPTIONS and is subject to the proxy-rules of an old-fashioned OPTIONS and is in fact, in no way distinguishable from an old-fashioned OPTIONS, then you're right and no extension is needed. > Some of us (maybe only me) feel there should be something different > about this particular OPTIONS, because we'd like to know the OPTIONS > we received, or the response to one we sent, is actually following > the draft's clarifications for response codes. It doesn't *have* to > do that - the whole thing could be based purely on configuration; but > it would be *nice* to make this thing automatic by the existence of a > header field. Perhaps something that clarified the use cases for OPTIONS in general, including targeting the request to a given node, preventing proxying of the request using max-forwards, and clarifying the response codes for different situations would be useful. Why just document the ping case? And I'm still fuzzy on why you need to be able to differentiate a "ping OPTIONS" from a "regular" OPTIONS. The use cases for doing this that I've heard so far seem to require an extension. -- Dean From pkyzivat@cisco.com Tue May 11 06:42:29 2010 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 2BB7028C14D for ; Tue, 11 May 2010 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.049 X-Spam-Level: X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_40=-0.185, 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 1BhM5YEU8PY6 for ; Tue, 11 May 2010 06:42:28 -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 BA23B28C178 for ; Tue, 11 May 2010 06:41:23 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,207,1272844800"; d="scan'208";a="110027313" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 May 2010 13:41:07 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4BDf6Xt027395; Tue, 11 May 2010 13:41:07 GMT Message-ID: <4BE95E6E.3000601@cisco.com> Date: Tue, 11 May 2010 09:41:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 13:42:29 -0000 Hadriel Kaplan wrote: > OPTIONS already exists. It is widely deployed. It is widely deployed as a way to query system status. (Arguably more so for that than for query of actual extensions/sdp/etc.) RFC 3261 specifically described this use-case for OPTIONS. In practice, though, it has interop issues. The interop issues mostly revolve around response codes and target addressing. Today, those interop issues are resolved by manual configuration. Paul is trying to alleviate those interop issues by recommending a particular configuration, which follows rfc3261's language. One could almost call it a BCP. (except the term "BCP" means something different in IETF than normal nomenclature) > > So he submitted a draft to do that. The response he gets is "we're working on an overload control mechanism and this thing has a bit of that... so no, we can't clean this up". > > It's like you guys are saying "Oh your arm hurts when you lift stuff? Well we could fix that, but we're working on giving you a new hand, and that holds the things you lift, so stop using your arm while we go design this new hand for it... oh and make sure you tell the hand designers about this arm problem...". No? Well, I guess the problem is that I am not getting answers to questions about *why* the options is being used - what one intends to accomplish with the answer. All I'm getting is "the answers that I get are inconsistent for my purposes". And so I am making my own assumptions about why, that are conflated with the overload work. The fact is, there are many possible reasons to use OPTIONS. I suspect that the reason there are different responses to similar situations is at least in part because the person deciding what response to give made the decision based on his/her notion of what the response would be used for. As I said yesterday, ISTM that one of the primary reasons for sending OPTIONS is so that the response to it can be used to make predictions about how future requests sent to related addresses will fare. I could say more, but in the interest of reaching some level of common understanding, I won't. Instead, I'll just ask: is that the primary goal here? Thanks, Paul From brett@broadsoft.com Tue May 11 07:31:22 2010 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 46DC03A6949 for ; Tue, 11 May 2010 07:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[AWL=-0.953, 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 Hssbi1AXUwf8 for ; Tue, 11 May 2010 07:31:21 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 8DBEC3A6968 for ; Tue, 11 May 2010 07:30:14 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 11 May 2010 07:30:03 -0700 From: Brett Tate To: "sipcore@ietf.org" Date: Tue, 11 May 2010 07:29:05 -0700 Thread-Topic: rfc3428 section 10: request-uri does not reflect binding Thread-Index: AcrxFk8nUOLO3ltoROq0Hfc7otNdTw== Message-ID: <747A6506A991724FB09B129B79D5FEB61481384179@EXMBXCLUS01.citservers.local> 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 Subject: [sipcore] rfc3428 section 10: request-uri does not reflect binding 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 May 2010 14:31:22 -0000 Howdy, Within RFC3428 section 10 example, the proxy "finds a binding from sip:user= 2@domain.com to sip:user2@user2pc.domain.com"; however it indicates sip:use= r2@domain.com instead of sip:user2@user2pc.domain.com within proxied MESSAG= E's request-uri. I assume that this a bug within the example (similar to tag and extraneous = ';' issues); however I thought that I'd ask before opening errata... is suc= h proxy behavior intentional? If intentional, what is the corresponding no= rmative text within RFC3428? Thanks, Brett From HKaplan@acmepacket.com Tue May 11 08:34:32 2010 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 6BF833A6BE6 for ; Tue, 11 May 2010 08:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, 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 T2ndHb1z5IRe for ; Tue, 11 May 2010 08:34:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 169F63A67F0 for ; Tue, 11 May 2010 08:34:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 11:34:09 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 11:34:08 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 11 May 2010 11:34:08 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrxD7VjsCVJOF9jQAKhMjr8ynuSlwADQBJA Message-ID: <430FC6BDED356B4C8498F634416644A91C139909C2@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> In-Reply-To: <4BE95E6E.3000601@cisco.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 Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 15:34:32 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, May 11, 2010 9:41 AM > To: Hadriel Kaplan >=20 > As I said yesterday, ISTM that one of the primary reasons for sending > OPTIONS is so that the response to it can be used to make predictions > about how future requests sent to related addresses will fare. > I could say more, but in the interest of reaching some level of common > understanding, I won't. Instead, I'll just ask: is that the primary goal > here? For me it is. I do also have a need to actually learn what the next-hop's = supported extensions are (and I do mean "box-level" ones), but that's not t= he main driver use-case for me at this instant in time. =20 So for me, the main use-case for sending OPTIONS right now is to learn the = capability of the next-hop to process messages. Load-related state, admin = state, and actual transport layer reachability as well. That's what many/m= ost people have been doing with OPTIONS for the past many years, after all.= Paul J's not proposing to change that - just to clarify what 3261 says ab= out it, so we don't have to do as much configuration to continue doing it. -hadriel From HKaplan@acmepacket.com Tue May 11 08:53:38 2010 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 951BD3A69EE for ; Tue, 11 May 2010 08:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 031bc8NaqCuX for ; Tue, 11 May 2010 08:53:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B5E663A67AE for ; Tue, 11 May 2010 08:53:37 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 11:53:26 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 11:53:26 -0400 From: Hadriel Kaplan To: Dean Willis Date: Tue, 11 May 2010 11:53:26 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrwyADaEcEJAq3pS8u1cZlTXMMa9QAV20EA Message-ID: <430FC6BDED356B4C8498F634416644A91C139909DA@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE8866B.2020205@softarmor.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB3@mail> <4BE8E643.3040003@softarmor.com> In-Reply-To: <4BE8E643.3040003@softarmor.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 Cc: "Paul E. Jones" , "sipcore@ietf.org" , "'Roy, Radhika R Dr CIV USA USAMC'" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 15:53:38 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, May 11, 2010 1:08 AM > To: Hadriel Kaplan =20 > And I'm still fuzzy on why you need to be able to differentiate a "ping > OPTIONS" from a "regular" OPTIONS. The use cases for doing this that > I've heard so far seem to require an extension. Basically because different vendors use different response codes and proces= s the request slightly differently, but all are legal per 3261. For exampl= e, let's say vendor X sends this OPTIONS per 3261, and expects a 503 to mea= n admin-down. But some vendor Y responds to it with a 500 to mean admin-do= wn. Vendor Y is not going to change its default behavior, because they're deplo= yed doing it that way and it's working. So they need something in the requ= est to tell them "this request is per draft foo, so use the specific respon= se codes per draft foo". Likewise, vendor X needs to know the responder di= d draft foo, so it doesn't apply its legacy default behavior (whatever that= is) but follows draft foo instead. So we could put some new param in the request's Via (like ";foo"), and have= the responder set it to something (like ";foo=3Dyes"). Or we could do it = with a Header. Either way, if the responder does not do foo both sides wil= l just do their legacy default logic. -hadriel From pkyzivat@cisco.com Tue May 11 10:51:20 2010 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 85EF03A6A51 for ; Tue, 11 May 2010 10:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 Cl2Y3QyTri1O for ; Tue, 11 May 2010 10:51:19 -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 7E22C3A69E3 for ; Tue, 11 May 2010 10:51:18 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,209,1272844800"; d="scan'208";a="110242546" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 May 2010 17:51:07 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4BHp7OD004230; Tue, 11 May 2010 17:51:07 GMT Message-ID: <4BE998FE.5040703@cisco.com> Date: Tue, 11 May 2010 13:50:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C139909C2@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: [sipcore] The predictive value of OPTIONS 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 May 2010 17:51:20 -0000 [Changing the subject line] Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, May 11, 2010 9:41 AM >> To: Hadriel Kaplan >> >> As I said yesterday, ISTM that one of the primary reasons for sending >> OPTIONS is so that the response to it can be used to make predictions >> about how future requests sent to related addresses will fare. >> I could say more, but in the interest of reaching some level of common >> understanding, I won't. Instead, I'll just ask: is that the primary goal >> here? > > For me it is. > I do also have a need to actually learn what the next-hop's > supported extensions are (and I do mean "box-level" ones), > but that's not the main driver use-case for me at this instant in time. Well, I would put that into somewhat the same bucket: You are looking to predict which options will be supported for requests you might send in the future. You seem to be making an assumption that extension support is uniquely defined at the "box-level". I don't think its proper to assume that in general, for a variety of reasons. For instance, a B2BUA may choose not to admit to support for an extension in the context of a dialog unless the "other leg" supports that extension. This goes double for other "attributes" that may be reported by OPTIONS, such as: event packages, mime types, media formats, even methods. (For the latter, what is a B2BUA supposed to do if it understands some method, but the other "side" doesn't?) > So for me, the main use-case for sending OPTIONS right now is to > learn the capability of the next-hop to process messages. You mean the dynamic, current "capacity" to process messages, not the theoretical "ability" to do so when resources are available? Or do you mean both? Do you mean: - the theoretical "ability" to do so when resources are available, - the "capacity" to do so given current load and resource availability, - the "willingness" to do so, at this time, for this requestor? > Load-related state, admin state, and actual transport layer > reachability as well. > That's what many/most people have been doing with OPTIONS for > the past many years, after all. I expect that people have had one, or more, of the meanings I list above in mind, perhaps without realizing that they are different. I'm willing to bet not everyone will agree its the same one of the above. OPTIONS, as currently defined, cannot provide all three answers. Nor will tightening up the specs change that, though doing so might make it do a better job of *one* of those. So one thing we might do is narrow down which (possibly more than one) of those we want answers to. (I expect there will be desire for all three.) Then, lets talk about what range of things a given response applies to: Suppose I send OPTIONS to - sip:198.51.100.101:5060 Does the response I get apply also to - sip:198.51.100.101:5061, - sip:alice@198.51.100.101:5060, - sip:alice@198.51.100.101:5060, - sips:carol@198.51.100.101:5061 - sip:example.com (maps to 198.51.100.101) - sip:pbx1.example.com (also maps to 198.51.100.101) It *might*, or it might not. Paul J assumes that sip: is "special", in that it applies to the "box", whereas sip:@ might return something else. And that might make sense for a proxy, or a proxy/registrar. But for a "phone" sip:198.51.100.101:5060 might just denote the "primary line", while sip:2@198.51.100.101:5060 may denote the "secondary line". And then the answer for one might have little predictive value over requests to the other. E.g. an OPTIONS to one might return 486 because the phone is busy, while an OPTIONS to the other might return 200. For a gateway, there may well be DSP resources required to establish a call, and how much, or what type may depend on the codecs used in the call. So an answer to OPTIONS won't be valuable in predicting if a particular call can succeed. So, I think we need to get specific about what we want to predict before deciding how to request the info to base those predictions on. Thanks, Paul From HKaplan@acmepacket.com Tue May 11 11:41:34 2010 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 6AD043A6A2D for ; Tue, 11 May 2010 11:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, 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 1uC4p+WEaHgQ for ; Tue, 11 May 2010 11:41:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 96F2D3A6A5E for ; Tue, 11 May 2010 11:41:13 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 14:41:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 14:41:01 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 11 May 2010 14:40:57 -0400 Thread-Topic: [sipcore] The predictive value of OPTIONS Thread-Index: AcrxMqWM1HUOcdQDS2yJlnpCVCnCvwAAXDrQ Message-ID: <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> <4BE998FE.5040703@cisco.com> In-Reply-To: <4BE998FE.5040703@cisco.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 Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] The predictive value of OPTIONS 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 May 2010 18:41:34 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: Tuesday, May 11, 2010 1:51 PM >=20 > > > > For me it is. > > I do also have a need to actually learn what the next-hop's > > supported extensions are (and I do mean "box-level" ones), > > but that's not the main driver use-case for me at this instant in time. >=20 > Well, I would put that into somewhat the same bucket: > You are looking to predict which options will be supported for requests > you might send in the future. >=20 > You seem to be making an assumption that extension support is uniquely > defined at the "box-level". I don't think its proper to assume that in > general, for a variety of reasons. For instance, a B2BUA may choose not > to admit to support for an extension in the context of a dialog unless > the "other leg" supports that extension. > This goes double for other "attributes" that may be reported by OPTIONS, > such as: event packages, mime types, media formats, even methods. Yup, I know that quite well, and have made that argument before in IETF. :) When I said "box-level", I meant capabilities *of* the B2BUA, at least with= respect to me. Not of any other "side", but of "my side". In practice, t= here is a set of capabilities that could be indicated, and are. Some of th= em would be quite useful, and really only apply on a per-hop basis anyway. = It's not everything, which makes it dangerous (and why I'm not suggesting = doing it right now), but that's for a later time. =20 > (For the latter, what is a B2BUA supposed to do if it understands some > method, but the other "side" doesn't?) If it accepts the method on my "side", it accepts the method. If the other= side doesn't, then it will reject it when I send it. Those two cases are = not mutually inconsistent. The B2BUA can make a routing decision which of = many "sides" to send the request to, but it really does accept it and I rea= lly should send it to find out - as opposed to when it does not accept it o= n my side and there's no point ever sending it such a method. =20 =20 > > So for me, the main use-case for sending OPTIONS right now is to > > learn the capability of the next-hop to process messages. >=20 > You mean the dynamic, current "capacity" to process messages, not the > theoretical "ability" to do so when resources are available? Or do you > mean both? Current. > Do you mean: > - the theoretical "ability" to do so when resources are available, > - the "capacity" to do so given current load and resource availability, > - the "willingness" to do so, at this time, for this requestor? If you mean "for this requestor" to mean for the same hop (as opposed to fo= r the same source Contact URI), then I'd argue the second and third are eff= ectively the same thing, in practice. I believe that has even come up in t= he overload discussions a long time ago, and I think there was agreement th= ey are effectively the same thing, logically. Just because a next-hop tell= s me it can't do any more, but tells someone else something different, does= n't matter to my local processing of future requests to it. > I expect that people have had one, or more, of the meanings I list above > in mind, perhaps without realizing that they are different. I'm willing > to bet not everyone will agree its the same one of the above. OPTIONS, > as currently defined, cannot provide all three answers. Nor will > tightening up the specs change that, though doing so might make it do a > better job of *one* of those. In every case I have seen this used for in deployment, as far as I can tell= they have actually meant the same thing. =20 > Then, lets talk about what range of things a given response applies to: >=20 > Suppose I send OPTIONS to > - sip:198.51.100.101:5060 > Does the response I get apply also to > - sip:198.51.100.101:5061, > - sip:alice@198.51.100.101:5060, > - sip:alice@198.51.100.101:5060, > - sips:carol@198.51.100.101:5061 > - sip:example.com (maps to 198.51.100.101) > - sip:pbx1.example.com (also maps to 198.51.100.101) YES. If the responder understands the Header, then it's reporting a system= -level capability. (luckily you forgot about anycasting ;) > But for a "phone" sip:198.51.100.101:5060 might just denote the "primary > line", while sip:2@198.51.100.101:5060 may denote the "secondary line". > And then the answer for one might have little predictive value over > requests to the other. E.g. an OPTIONS to one might return 486 because > the phone is busy, while an OPTIONS to the other might return 200. Hence the need/desire for a Header. =20 > For a gateway, there may well be DSP resources required to establish a > call, and how much, or what type may depend on the codecs used in the > call. So an answer to OPTIONS won't be valuable in predicting if a > particular call can succeed. That's OK. A "box-wide" semantic is a superset. If you can handle ANY mor= e calls (from that previous hop), then "box-wide" you can handle more calls= . That doesn't mean you can't reject future calls due to unavailable resou= rces such as DSPs. If you can NOT handle any more "box-wide", for example = due to CPU, then the number of DSP resources you have really doesn't matter= . -hadriel From adam@nostrum.com Tue May 11 12:13:09 2010 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 B1B1228C202 for ; Tue, 11 May 2010 12:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.320, 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 HAZo5kMM3Omd for ; Tue, 11 May 2010 12:13:08 -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 839E728C207 for ; Tue, 11 May 2010 12:12:43 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4BJCUE8099902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 14:12:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BE9AC1E.9020902@nostrum.com> Date: Tue, 11 May 2010 14:12:30 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 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: 70.249.147.216 is authenticated by a trusted mechanism) Subject: [sipcore] Draft Publication Requests 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 May 2010 19:13:09 -0000 [as chair] The SIPCORE chairs have requested publication for the following three documents: draft-ietf-sipcore-reinvite-04 draft-ietf-sipcore-event-rate-control-03 draft-ietf-sipcore-invfix-01 You can track their progress using the datatracker tool: https://datatracker.ietf.org/doc/draft-ietf-sipcore-reinvite/ https://datatracker.ietf.org/doc/draft-ietf-sipcore-event-rate-control/ https://datatracker.ietf.org/doc/draft-ietf-sipcore-invfix/ /a From HKaplan@acmepacket.com Tue May 11 13:36:20 2010 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 2B0733A68E3 for ; Tue, 11 May 2010 13:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 t8-mFYN22bKF for ; Tue, 11 May 2010 13:36:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7C8543A6A09 for ; Tue, 11 May 2010 13:35:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 16:35:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 16:35:46 -0400 From: Hadriel Kaplan To: Brett Tate , "sipcore@ietf.org" Date: Tue, 11 May 2010 16:35:45 -0400 Thread-Topic: rfc3428 section 10: request-uri does not reflect binding Thread-Index: AcrxFk8nUOLO3ltoROq0Hfc7otNdTwAMp9iQ Message-ID: <430FC6BDED356B4C8498F634416644A91C13990B60@mail> References: <747A6506A991724FB09B129B79D5FEB61481384179@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61481384179@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] rfc3428 section 10: request-uri does not reflect binding 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 May 2010 20:36:20 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Brett Tate > Sent: Tuesday, May 11, 2010 10:29 AM >=20 > Within RFC3428 section 10 example, the proxy "finds a binding from > sip:user2@domain.com to sip:user2@user2pc.domain.com"; however it > indicates sip:user2@domain.com instead of sip:user2@user2pc.domain.com > within proxied MESSAGE's request-uri. >=20 > I assume that this a bug within the example (similar to tag and extraneou= s > ';' issues); however I thought that I'd ask before opening errata... is > such proxy behavior intentional? If intentional, what is the > corresponding normative text within RFC3428? It's pretty clearly a bug. :) The text in section 6 says: Proxies route MESSAGE requests according to the rules of SIP [1]. And the example says: User1 forwards this message to the server for domain.com. The proxy receives this request, and recognizes that it is the server for domain.com. It looks up user2 in its database (built up through registrations), and finds a binding from sip:user2@domain.com to sip:user2@user2pc.domain.com. It forwards the request to user2. So F2 should have been: MESSAGE sip:user2@user2pc.domain.com SIP/2.0 Via: SIP/2.0/TCP proxy.domain.com;branch=3Dz9hG4bK123dsghds Via: SIP/2.0/TCP user1pc.domain.com;branch=3Dz9hG4bK776sgdkse; received=3D1.2.3.4 Max-Forwards: 69 From: sip:user1@domain.com;tag=3D49394 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: ... ... -hadriel From fluffy@cisco.com Tue May 11 14:16:14 2010 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 A00063A6A83 for ; Tue, 11 May 2010 14:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.962 X-Spam-Level: X-Spam-Status: No, score=-109.962 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 E2lWXbS1MHCT for ; Tue, 11 May 2010 14:16:07 -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 809153A6A91 for ; Tue, 11 May 2010 14:15:14 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,210,1272844800"; d="scan'208";a="325039289" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 11 May 2010 21:15:00 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4BLEx7Q002052; Tue, 11 May 2010 21:15:00 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> Date: Tue, 11 May 2010 15:14:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8D8EC101-F319-4E90-98AF-0A1CAF0C065F@cisco.com> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1078) Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 21:16:14 -0000 On May 10, 2010, at 10:55 PM, Hadriel Kaplan wrote: > Paul is trying to alleviate those interop issues by recommending a = particular configuration, which follows rfc3261's language. One could = almost call it a BCP. (except the term "BCP" means something different = in IETF than normal nomenclature) >=20 > So he submitted a draft to do that. The response he gets is "we're = working on an overload control mechanism and this thing has a bit of = that... so no, we can't clean this up". Really? I did not get that out of the draft. If you mean that the drafts = thinks it is OK to a SIP URI that has a host portion with no user name, = well I took that as fairly obvious that was OK in 3261. Section 11 = explicitly discusses it.=20 From HKaplan@acmepacket.com Tue May 11 14:30:30 2010 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 CCE893A682E for ; Tue, 11 May 2010 14:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_05=-1.11] 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 kVI1cseQ6fM3 for ; Tue, 11 May 2010 14:30:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id ACDE33A6942 for ; Tue, 11 May 2010 14:30:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 17:30:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 17:30:16 -0400 From: Hadriel Kaplan To: Cullen Jennings Date: Tue, 11 May 2010 17:30:13 -0400 Thread-Topic: [sipcore] draft-jones-sip-options-ping-01 Thread-Index: AcrxTwfB5As2qFhuQ8us4b/OtQPt2AAAOpyA Message-ID: <430FC6BDED356B4C8498F634416644A91C13990B98@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <8D8EC101-F319-4E90-98AF-0A1CAF0C065F@cisco.com> In-Reply-To: <8D8EC101-F319-4E90-98AF-0A1CAF0C065F@cisco.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 Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 21:30:30 -0000 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, May 11, 2010 5:15 PM > To: Hadriel Kaplan >=20 > On May 10, 2010, at 10:55 PM, Hadriel Kaplan wrote: >=20 > > Paul is trying to alleviate those interop issues by recommending a > particular configuration, which follows rfc3261's language. One could > almost call it a BCP. (except the term "BCP" means something different in > IETF than normal nomenclature) > > So he submitted a draft to do that. The response he gets is "we're > working on an overload control mechanism and this thing has a bit of > that... so no, we can't clean this up". >=20 > Really? I did not get that out of the draft. If you mean that the drafts > thinks it is OK to a SIP URI that has a host portion with no user name, > well I took that as fairly obvious that was OK in 3261. Section 11 > explicitly discusses it. Right, but it wasn't clear enough to make it usable without configuration i= n many cases. First, because if you send it to a proxy or b2bua between yo= u and the Registrar, it's not distinguishable from an OPTIONS targeted to t= he Registrar, so some proxies/b2buas will forward it to the registrar. If = you set a max-forwards of 0 to stop that, you'll get a 483 from some proxie= s/b2buas instead of a OPTIONS-based response. That's legit too, since 3261= only said: Alternatively, a server receiving an OPTIONS request with a Max- Forwards header field value of 0 MAY respond to the request regardless of the Request-URI. Then there's the response status code itself and clarifying section 11.2. So afaict Paul's draft is trying to clear up 3261's language to be explicit= and avoid the manual configuration for these types of issues. (though I m= ay be reading more into it than is there, or than Paul intends) -hadriel From pkyzivat@cisco.com Tue May 11 17:39:55 2010 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 9BA603A6C1C for ; Tue, 11 May 2010 17:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.258 X-Spam-Level: X-Spam-Status: No, score=-10.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 vnQmSXEqit1Q for ; Tue, 11 May 2010 17:39:54 -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 8FA0E3A693A for ; Tue, 11 May 2010 17:39:53 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEeV6UtAZnwN/2dsb2JhbACeK3GhGplGgnaCGwQ X-IronPort-AV: E=Sophos;i="4.53,211,1272844800"; d="scan'208";a="110212279" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 May 2010 00:39:42 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4C0dgS1016627; Wed, 12 May 2010 00:39:42 GMT Message-ID: <4BE9F8CE.2050207@cisco.com> Date: Tue, 11 May 2010 20:39:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> <4BE998FE.5040703@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] The predictive value of OPTIONS 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 May 2010 00:39:55 -0000 This is fragmenting into multiple issues that ought to be discussed separately. But I want to go home so I'm not splitting it up. inline... Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Tuesday, May 11, 2010 1:51 PM >> >>> For me it is. >>> I do also have a need to actually learn what the next-hop's >>> supported extensions are (and I do mean "box-level" ones), >>> but that's not the main driver use-case for me at this instant in time. >> Well, I would put that into somewhat the same bucket: >> You are looking to predict which options will be supported for requests >> you might send in the future. >> >> You seem to be making an assumption that extension support is uniquely >> defined at the "box-level". I don't think its proper to assume that in >> general, for a variety of reasons. For instance, a B2BUA may choose not >> to admit to support for an extension in the context of a dialog unless >> the "other leg" supports that extension. >> This goes double for other "attributes" that may be reported by OPTIONS, >> such as: event packages, mime types, media formats, even methods. > > Yup, I know that quite well, and have made that argument before in IETF. :) > > When I said "box-level", I meant capabilities *of* the B2BUA, at least with respect to me. Not of any other "side", but of "my side". In practice, there is a set of capabilities that could be indicated, and are. Some of them would be quite useful, and really only apply on a per-hop basis anyway. It's not everything, which makes it dangerous (and why I'm not suggesting doing it right now), but that's for a later time. > > >> (For the latter, what is a B2BUA supposed to do if it understands some >> method, but the other "side" doesn't?) > > If it accepts the method on my "side", it accepts the method. If the other side doesn't, then it will reject it when I send it. Those two cases are not mutually inconsistent. The B2BUA can make a routing decision which of many "sides" to send the request to, but it really does accept it and I really should send it to find out - as opposed to when it does not accept it on my side and there's no point ever sending it such a method. Lets use MESSAGE for discussion. You would report MESSAGE in an Accept header. Then later you receive MESSAGE, forward it to the "other side", and get back a 405, including a list of methods that are supported, not including MESSAGE. Do you pass that Accept on? Or alter it to indicate that you *do* support MESSAGE even though you are rejecting it with a 405? There is no way to win here. You must be inconsistent at some point. So the result of the OPTIONS wrt Accept cannot be trusted to predict future behavior. The same is true for most of the other things reported in OPTIONS - its really hard to say much about how relevant they are for predicting future behavior. To do better, I think it is necessary to either: - specify in the query the context of the question, or - return a complex document that describes what is supported under a variety of circumstances. I doubt we want the latter (at least I don't). Specifying the context for which you want an answer is also pretty difficult to do, given the number of different contexts that are possible. Maybe its possible to do a few interesting ones. One is to send an OPTIONS to a URL and get an answer that pertains to *that* URL, while not necessarily pertaining to any other URL. AFAIK that is, more or less, what the current definition of OPTIONS does. You might choose to extrapolate the results for that URL to other URLs, but that may or may not produce correct results. Of course this is also limited, in that it only reports the results for OPTIONS. It has no way to customize the results for other methods. (For instance, some MIME types are likely to be acceptable only in the context of certain methods. Application/SDP may not be acceptable for MESSAGE.) To get beyond the answer for one URL, we need a way to indicate we want an answer for a class of URLs, maybe all of them. Some seem to think that a URL with no user part is an indicator for this. I think that is probably a sensible meaning for some servers, but not all of them. IMO there is no good value you can pick to put in the user part of the R-URI to indicate this. But perhaps it could be indicated via some new header. If this is the desire, and single answers are desired, then some accuracy must be given up. Presumably the answer must be the union of the answers for all the URIs it applies to. So for any particular URI the answer might be less. Also, there is the distinction between what might be available on a good day, vs. what the server is currently capable of, vs. what it is *willing* to do. Again, I don't see how any one answer is the right one for this. (E.g. the server is heavily loaded. It is capable of accepting *some* requests, but is only willing to accept requests from privileged callers. Or, it is in shutting-down mode. It has plenty of resources, but is only willing to accept in-dialog requests.) Again, I think to get at this will require an indicator in the request of which sort of answer you want. Unless we can agree the answer is always and only about *capability*, and never about policy. Bottom line here: I think there needs to be a selector, or selectors, for which kind of answer is desired. >>> So for me, the main use-case for sending OPTIONS right now is to >>> learn the capability of the next-hop to process messages. >> You mean the dynamic, current "capacity" to process messages, not the >> theoretical "ability" to do so when resources are available? Or do you >> mean both? > > Current. Sorry - I botched my message that you are replying to. I wrote the above, then the list immediately below to replace that. >> Do you mean: >> - the theoretical "ability" to do so when resources are available, >> - the "capacity" to do so given current load and resource availability, >> - the "willingness" to do so, at this time, for this requestor? > > If you mean "for this requestor" to mean for the same hop (as opposed to for the same source Contact URI), then I'd argue the second and third are effectively the same thing, in practice. I believe that has even come up in the overload discussions a long time ago, and I think there was agreement they are effectively the same thing, logically. Just because a next-hop tells me it can't do any more, but tells someone else something different, doesn't matter to my local processing of future requests to it. I meant whatever the server would use as input to any policy decisions it might make. That might mean the sender of the message (top Via value), the originator of the request, whatever. For instance, administrative shutdown would be a policy that determines willingness to handle requests. (At least until the listeners are stopped.) It might apply to certain links, which is what you are getting at. It might also apply to certain request originators, or to in-dialog vs. out-of-dialog requests, etc. It might also apply to certain R-URIs. Policies to throttle load before overload occurs could also fall into this category of "willingness". The specified expectation that an OPTIONS should return 486 if the device (a phone presumably) is on a call also falls into this "policy" category, since it could alternatively hang up the existing call or put it on hold to accept the new call. I can see utility in getting theoretical capability as well: it would be nice to be able to determine which if any of your devices could support video, even if currently busy. I might then choose to wait till the video phone is free rather than calling now on the audio phone. (But of course this is better done with presence.) But, if the majority of people can agree on a single context in which they want an answer, then perhaps we can simply have a single indicator that says we want that, rather than whatever it is that OPTIONS otherwise returns. >> I expect that people have had one, or more, of the meanings I list above >> in mind, perhaps without realizing that they are different. I'm willing >> to bet not everyone will agree its the same one of the above. OPTIONS, >> as currently defined, cannot provide all three answers. Nor will >> tightening up the specs change that, though doing so might make it do a >> better job of *one* of those. > > In every case I have seen this used for in deployment, as far as I can tell they have actually meant the same thing. To be fair, ACME has a particular perspective. SBCs talk to a certain class of equipment. I doubt you have need to interface directly to phones. But others do use OPTIONS to phones. >> Then, lets talk about what range of things a given response applies to: >> >> Suppose I send OPTIONS to >> - sip:198.51.100.101:5060 >> Does the response I get apply also to >> - sip:198.51.100.101:5061, >> - sip:alice@198.51.100.101:5060, >> - sip:alice@198.51.100.101:5060, >> - sips:carol@198.51.100.101:5061 >> - sip:example.com (maps to 198.51.100.101) >> - sip:pbx1.example.com (also maps to 198.51.100.101) > > YES. If the responder understands the Header, then it's reporting a system-level capability. (luckily you forgot about anycasting ;) I slipped some ringers in there for you. :-) There is no guarantee that two ports for the same ip address are served by the same "server". They may be served by separate processes with independent resources. Statistically there is probably a good chance that 5060 and 5061 are served by the same server. But once you get past that, then what? I didn't put in multi-homing situations, or IPv6/IPv6 cases, but they apply too. For all of these I can't see a good alternative to assuming they are distinct and asking on each, or *configuring* the cases when you *know* they are the same. And I still disagree with assuming they are the same when the user part varies, unless we add something to the message to indicate that is what is desired. But even an indicator won't deal with the port issue, or with multihoming, since you can't know if the device speaks for the others. OR, the response could be altered to indicate all the different addresses is applies to. >> But for a "phone" sip:198.51.100.101:5060 might just denote the "primary >> line", while sip:2@198.51.100.101:5060 may denote the "secondary line". >> And then the answer for one might have little predictive value over >> requests to the other. E.g. an OPTIONS to one might return 486 because >> the phone is busy, while an OPTIONS to the other might return 200. > > Hence the need/desire for a Header. > > >> For a gateway, there may well be DSP resources required to establish a >> call, and how much, or what type may depend on the codecs used in the >> call. So an answer to OPTIONS won't be valuable in predicting if a >> particular call can succeed. > > That's OK. A "box-wide" semantic is a superset. If you can handle ANY more calls (from that previous hop), then "box-wide" you can handle more calls. That doesn't mean you can't reject future calls due to unavailable resources such as DSPs. If you can NOT handle any more "box-wide", for example due to CPU, then the number of DSP resources you have really doesn't matter. That is a possible interpretation. If some (expensive) codecs are disabled during peak load, should that be reflected in the response? What if some destinations are currently unreachable? Should OPTIONS for a particular address reflect that? (E.g. only +1... calls are currently operational because the international trunk is down. Should OPTIONS to sip:+44... return 480 or 200?) Thanks, Paul From HKaplan@acmepacket.com Tue May 11 19:39:20 2010 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 8BF6F3A6C64 for ; Tue, 11 May 2010 19:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 ZFl0fiJk3kfr for ; Tue, 11 May 2010 19:39:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6B1E628C0FE for ; Tue, 11 May 2010 19:39:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 11 May 2010 22:39:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 11 May 2010 22:39:01 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 11 May 2010 22:39:00 -0400 Thread-Topic: [sipcore] The predictive value of OPTIONS Thread-Index: Acrxa6zJXrYYhTLHS++mxQFL0xMJqQACVU3g Message-ID: <430FC6BDED356B4C8498F634416644A91C13990BE6@mail> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> <4BE998FE.5040703@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> <4BE9F8CE.2050207@cisco.com> In-Reply-To: <4BE9F8CE.2050207@cisco.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 Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] The predictive value of OPTIONS 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 May 2010 02:39:20 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, May 11, 2010 8:40 PM > To: Hadriel Kaplan >=20 > Hadriel Kaplan wrote: > > > >> (For the latter, what is a B2BUA supposed to do if it understands some > >> method, but the other "side" doesn't?) > > > > If it accepts the method on my "side", it accepts the method. If the > other side doesn't, then it will reject it when I send it. Those two > cases are not mutually inconsistent. The B2BUA can make a routing > decision which of many "sides" to send the request to, but it really does > accept it and I really should send it to find out - as opposed to when it > does not accept it on my side and there's no point ever sending it such a > method. >=20 > Lets use MESSAGE for discussion. You would report MESSAGE in an Accept > header. Then later you receive MESSAGE, forward it to the "other side", > and get back a 405, including a list of methods that are supported, not > including MESSAGE. Do you pass that Accept on? Or alter it to indicate > that you *do* support MESSAGE even though you are rejecting it with a 405= ? >=20 > There is no way to win here. You must be inconsistent at some point. So > the result of the OPTIONS wrt Accept cannot be trusted to predict future > behavior. The same is true for most of the other things reported in > OPTIONS - its really hard to say much about how relevant they are for > predicting future behavior. I think you're missing my point - when you send a request to user1@foo what= you get back is about user1@foo. So if you get back an Accept without MES= SAGE, you may be able to know something about user1@foo, but NOTHING about = user2@foo. There is no inconsistency there. But as I said in the previous email with regards to what could reasonably b= e learned from the response: "It's not everything, which makes it dangerous= (and why I'm not suggesting doing it right now), but that's for a later ti= me." Allowed methods, for example, is probably a borderline one. But most= of the capabilities which I would want such a thing for would really be pr= oxy type of capabilities: things like keepalives, sigcomp, secagree, and so= me transport/connection things which should arguably be in DNS SRV's but ar= e basically always manually provisioned today. =20 > One is to send an OPTIONS to a URL and get an answer that pertains to > *that* URL, while not necessarily pertaining to any other URL. AFAIK > that is, more or less, what the current definition of OPTIONS does. You > might choose to extrapolate the results for that URL to other URLs, but > that may or may not produce correct results. Of course this is also > limited, in that it only reports the results for OPTIONS. It has no way > to customize the results for other methods. (For instance, some MIME > types are likely to be acceptable only in the context of certain > methods. Application/SDP may not be acceptable for MESSAGE.) >=20 > To get beyond the answer for one URL, we need a way to indicate we want > an answer for a class of URLs, maybe all of them. Some seem to think > that a URL with no user part is an indicator for this. I think that is > probably a sensible meaning for some servers, but not all of them. IMO > there is no good value you can pick to put in the user part of the R-URI > to indicate this. But perhaps it could be indicated via some new header. > If this is the desire, and single answers are desired, then some > accuracy must be given up. Presumably the answer must be the union of > the answers for all the URIs it applies to. So for any particular URI > the answer might be less. Exactly - when you send it to a URL, the result is about the URL; and curre= ntly lots of devices do assume no user part is effectively all of them (of = that particular URL), and I have been agreeing that a Header is a fine way = to make it unambiguous for that case. I don't think anyone has objected to= that, including Paul J. =20 > Also, there is the distinction between what might be available on a good > day, vs. what the server is currently capable of, vs. what it is > *willing* to do. Again, I don't see how any one answer is the right one > for this. (E.g. the server is heavily loaded. It is capable of accepting > *some* requests, but is only willing to accept requests from privileged > callers. Or, it is in shutting-down mode. It has plenty of resources, > but is only willing to accept in-dialog requests.) >=20 > Again, I think to get at this will require an indicator in the request > of which sort of answer you want. Unless we can agree the answer is > always and only about *capability*, and never about policy. >=20 > Bottom line here: I think there needs to be a selector, or selectors, > for which kind of answer is desired. I don't think so. Not in practice. There is no real difference to the req= uestor whether the responder won't accept new requests because it's overloa= ded, shutting down, or just doesn't like you. The resulting effect on the = requestor is the same. And at the end of the day, that's the important pie= ce for interoperability: what the requestor should do given a response, not= why the responder sent the response. For the "privileged callers" case, if by "privileged callers" you mean spec= ific calls from the same hop, then the responder really does accept request= s, just not all requests, and should say it does accept requests - but that= 's *OK*, it's not _broken_ to not be able to signal every possible policy r= ule to previous hops. It may not be optimal in some folks' minds, but it's= not broken. Same goes for the other "policy" cases you had in your email = (I've removed them to reduce the size of this email). =20 > > In every case I have seen this used for in deployment, as far as I can > tell they have actually meant the same thing. >=20 > To be fair, ACME has a particular perspective. SBCs talk to a certain > class of equipment. I doubt you have need to interface directly to > phones. But others do use OPTIONS to phones. Actually over half of our SBC's talk to phones direct. (I count an MTA/IAD/= Terminal as a phone - basically anything that Registers and represents a si= ngle user I consider a "phone") But you're right SBCs don't generally send= OPTIONS to phones unless something else sends it through the SBC to reach = them, and I don't see that happening very much. I usually see OPTIONS comi= ng from phones to the SBC, or between an SBC and its next/previous-hop serv= ers. =20 > >> Then, lets talk about what range of things a given response applies to= : > >> > >> Suppose I send OPTIONS to > >> - sip:198.51.100.101:5060 > >> Does the response I get apply also to > >> - sip:198.51.100.101:5061, > >> - sip:alice@198.51.100.101:5060, > >> - sip:alice@198.51.100.101:5060, > >> - sips:carol@198.51.100.101:5061 > >> - sip:example.com (maps to 198.51.100.101) > >> - sip:pbx1.example.com (also maps to 198.51.100.101) > > > > YES. If the responder understands the Header, then it's reporting a > system-level capability. (luckily you forgot about anycasting ;) >=20 > I slipped some ringers in there for you. :-) Oops, missed the port numbers being different. Right, those are different,= because they're a different URL hostport. -hadriel From fluffy@cisco.com Tue May 11 21:42:12 2010 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 2598628B56A for ; Tue, 11 May 2010 21:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.961 X-Spam-Level: X-Spam-Status: No, score=-109.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 eOuxnKqg7YmL for ; Tue, 11 May 2010 21:42:09 -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 B40F33A6C41 for ; Tue, 11 May 2010 21:42:09 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,211,1272844800"; d="scan'208";a="196260417" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 12 May 2010 04:41:59 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4C4fwOp009290; Wed, 12 May 2010 04:41:58 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13990B98@mail> Date: Tue, 11 May 2010 22:41:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2E0FBC9C-D265-4637-A1F1-41C531B7B196@cisco.com> References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <8D8EC101-F319-4E90-98AF-0A1CAF0C065F@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990B98@mail> To: "Hadriel Kaplan" X-Mailer: Apple Mail (2.1078) Cc: "Paul E. Jones" , sipcore@ietf.org Subject: Re: [sipcore] draft-jones-sip-options-ping-01 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 May 2010 04:42:12 -0000 Hmm, I'm still confused what the problem is that causes me to want to = send an options to say my outbound proxy but if my outbound = proxy/sbc/b2bua is configured to be outbound.example.com and my AOR it = alice@example.com, it seems pretty clear that I send it to = sip:outbound.example.com if that's where I want it to go.=20 On May 11, 2010, at 3:30 PM, Hadriel Kaplan wrote: >=20 >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Tuesday, May 11, 2010 5:15 PM > > To: Hadriel Kaplan > > > > On May 10, 2010, at 10:55 PM, Hadriel Kaplan wrote: > > > > > Paul is trying to alleviate those interop issues by recommending = a > > particular configuration, which follows rfc3261's language. One = could > > almost call it a BCP. (except the term "BCP" means something = different in > > IETF than normal nomenclature) > > > So he submitted a draft to do that. The response he gets is = "we're > > working on an overload control mechanism and this thing has a bit of > > that... so no, we can't clean this up". > > > > Really? I did not get that out of the draft. If you mean that the = drafts > > thinks it is OK to a SIP URI that has a host portion with no user = name, > > well I took that as fairly obvious that was OK in 3261. Section 11 > > explicitly discusses it. >=20 > Right, but it wasn't clear enough to make it usable without = configuration in many cases. First, because if you send it to a proxy = or b2bua between you and the Registrar, it's not distinguishable from an = OPTIONS targeted to the Registrar, so some proxies/b2buas will forward = it to the registrar. If you set a max-forwards of 0 to stop that, = you'll get a 483 from some proxies/b2buas instead of a OPTIONS-based = response. That's legit too, since 3261 only said: > Alternatively, a server receiving an OPTIONS request with a Max- > Forwards header field value of 0 MAY respond to the request > regardless of the Request-URI. >=20 > Then there's the response status code itself and clarifying section = 11.2. >=20 > So afaict Paul's draft is trying to clear up 3261's language to be = explicit and avoid the manual configuration for these types of issues. = (though I may be reading more into it than is there, or than Paul = intends) >=20 > -hadriel >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From shinji.okumura@softfront.jp Wed May 12 04:13:25 2010 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 A7B753A6A96 for ; Wed, 12 May 2010 04:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.534 X-Spam-Level: ** X-Spam-Status: No, score=2.534 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222] 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 yq-CzhsBfqt2 for ; Wed, 12 May 2010 04:13:24 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 8A3993A69D1 for ; Wed, 12 May 2010 04:13:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id DEC0C46B297 for ; Wed, 12 May 2010 20:13:12 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7lodntkgUm5 for ; Wed, 12 May 2010 20:13:08 +0900 (JST) Received: from softfront.jp (p6068-ipad403sapodori.hokkaido.ocn.ne.jp [60.43.99.68]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 4480146B1A0 for ; Wed, 12 May 2010 20:13:07 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Wed, 12 May 2010 20:13:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <20100508073002.1CBBE3A68A8@core3.amsl.com> References: <20100508073002.1CBBE3A68A8@core3.amsl.com> Message-Id: <18CAF1C419F9A7shinji.okumura@softfront.jp> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Wed, 12 May 2010 11:13:25 -0000 Hi, I have one question and one comment about UAC behavior. question: At first, oa status is only audio, and during a next reINVITE transaction oa status is changed to audio and video. And then UAS sends a 4xx response to the reINVITE. In this case which is a new offer UAC should send, only audio or both of audio and video with zero port? comment: If already-executed changes is made by only PRACK transaction, IMO UAC need not generate a new offer to synchronize both UAs. Regards, Shinji Internet-Drafts@ietf.org Sat, 8 May 2010 00:30:02 -0700 (PDT) >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > > Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-sipcore-reinvite-04.txt > Pages : 24 > Date : 2010-05-08 > >In this document, we clarify the handling of re-INVITEs in SIP. We >clarify in which situations a UAS (User Agent Server) should generate >a success response and in which situations a UAS should generate an >error response to a re-INVITE. Additionally, we clarify issues >related to target-refresh requests. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. From gao.yang2@zte.com.cn Wed May 12 06:18:51 2010 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 997F13A68B9 for ; Wed, 12 May 2010 06:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.081 X-Spam-Level: X-Spam-Status: No, score=-98.081 tagged_above=-999 required=5 tests=[AWL=1.343, BAYES_40=-0.185, 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 B1LoKRPXPPOh for ; Wed, 12 May 2010 06:18:50 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id A32D73A6BA2 for ; Wed, 12 May 2010 06:13:11 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Wed, 12 May 2010 21:08:32 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3015714703; Wed, 12 May 2010 21:12:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4CDCwKl018105; Wed, 12 May 2010 21:12:58 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <18CAF1C419F9A7shinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 12 May 2010 21:10:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-12 21:12:43, Serialize complete at 2010-05-12 21:12:43 Content-Type: multipart/alternative; boundary="=_alternative 00488B3E48257721_=" X-MAIL: mse2.zte.com.cn o4CDCwKl018105 Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Wed, 12 May 2010 13:18:51 -0000 This is a multipart message in MIME format. --=_alternative 00488B3E48257721_= Content-Type: text/plain; charset="US-ASCII" > Hi, > > I have one question and one comment about UAC behavior. > > question: > At first, oa status is only audio, and during a next reINVITE > transaction oa status is changed to audio and video. And then > UAS sends a 4xx response to the reINVITE. If the O/A in Re-INVITE without precondition, the media modification is defined as *in use* after the O/A by RFC3264. So, the UAS need to send 2xx, while not 4xx. > In this case which is a new offer UAC should send, only audio > or both of audio and video with zero port? Here, if you are talking the *legacy* UAS, then the *legacy* UAS may send 4xx. This case is talked in "3.4. UAC Behavior" of the text. Current normative text is that UAC SHOULD send a new Offer to synchronize the session state. As the session state would be synchronize by the new O/A, so there's no rigorous rule about the content of the Offer. But the text show tendency by the description of: the UAC uses the criteria in Section 3.3 in order to decide whether or not changes have been executed for the stream I guess this is the deliberate arrangement by Gonzalo. Gonzalo? > > comment: > If already-executed changes is made by only PRACK transaction, > IMO UAC need not generate a new offer to synchronize both UAs. New Offer is used by UAC in the conditions: "modification is *in use*, AND UAS send 4xx" or other race condition. I think it is not relating to the request type. Thanks, Gao -------------------------------------------------------- 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 00488B3E48257721_= Content-Type: text/html; charset="US-ASCII"

> Hi,
>
> I have one question and one comment about UAC behavior.
>
> question:
> At first, oa status is only audio, and during a next reINVITE
> transaction oa status is changed to audio and video. And then
> UAS sends a 4xx response to the reINVITE.

If the O/A in Re-INVITE without precondition, the media modification is defined as *in use* after the O/A by RFC3264.
So, the UAS need to send 2xx, while not 4xx.
 
> In this case which is a new offer UAC should send, only audio
> or both of audio and video with zero port?

Here, if you are talking the *legacy* UAS, then the *legacy* UAS may send 4xx.
This case is talked in "3.4.  UAC Behavior" of the text.

Current normative text is that UAC SHOULD send a new Offer to synchronize the session state. As the session state would be synchronize by the new O/A, so there's no rigorous rule about the content of the Offer. But the text show tendency by the description of:
the UAC uses the criteria in Section 3.3 in order to decide whether or not changes have been executed for the stream

I guess this is the deliberate arrangement by Gonzalo. Gonzalo?

>
> comment:
> If already-executed changes is made by only PRACK transaction,
> IMO UAC need not generate a new offer to synchronize both UAs.

New Offer is used by UAC in the conditions:
"modification is *in use*, AND UAS send 4xx" or other race condition.

I think it is not relating to the request type.

Thanks,

Gao 

--------------------------------------------------------
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 00488B3E48257721_=-- From dworley@avaya.com Wed May 12 13:13:58 2010 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 F02C63A67E3 for ; Wed, 12 May 2010 13:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_20=-0.74] 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 jCQwi6+HZfLE for ; Wed, 12 May 2010 13:13:58 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id EA2B03A6452 for ; Wed, 12 May 2010 13:13:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,217,1272859200"; d="scan'208";a="15641484" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 12 May 2010 16:13:42 -0400 X-IronPort-AV: E=Sophos;i="4.53,217,1272859200"; d="scan'208";a="474427286" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 May 2010 16:13:40 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Wed, 12 May 2010 16:13:40 -0400 From: "WORLEY, Dale R (Dale)" To: Hadriel Kaplan , Paul Kyzivat Date: Wed, 12 May 2010 16:13:40 -0400 Thread-Topic: [sipcore] The predictive value of OPTIONS Thread-Index: Acrxa6zJXrYYhTLHS++mxQFL0xMJqQACVU3gACZyHr4= Message-ID: References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> <4BE998FE.5040703@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> <4BE9F8CE.2050207@cisco.com>, <430FC6BDED356B4C8498F634416644A91C13990BE6@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13990BE6@mail> 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 Cc: "Paul E. Jones" , "sipcore@ietf.org" Subject: Re: [sipcore] The predictive value of OPTIONS 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 May 2010 20:13:59 -0000 There is some predictive value of a blanket OPTIONS test, probably more tha= n people realize. In SIP, there can be multiple ways to accomplish a task. Especially when p= ropprietary extensions may be present, the theoretically correct way to han= dle the situation is to try the methods in order of decreasing preference u= ntil you discover a method that is supported: Try A, if that fails, try B,= if that fails, try C. In practice, you'd like to know if the next-hop ele= ment doesn't support method A, so you can avoid the overhead of trying it o= n future calls. In the case of proprietary extensions (which method A is likely to be), a s= ingle OPTIONs request can tell you if the element has never heard of the ex= tension. Because of downstream elements, you may still have to fall back t= o methods B and C at times, but there is a significant savings if you can d= etect the cases where the next-hop element cannot process method A *at all*= . Dale From pkyzivat@cisco.com Wed May 12 13:49:45 2010 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 796A73A693E for ; Wed, 12 May 2010 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 8KVMCF7gQWKj for ; Wed, 12 May 2010 13:49:44 -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 3EE363A6937 for ; Wed, 12 May 2010 13:49:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJKx6ktAZnwN/2dsb2JhbACeJ3GjU5lahRIE X-IronPort-AV: E=Sophos;i="4.53,217,1272844800"; d="scan'208";a="110657058" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 May 2010 20:49:32 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4CKnWB5000148; Wed, 12 May 2010 20:49:32 GMT Message-ID: <4BEB145B.50702@cisco.com> Date: Wed, 12 May 2010 16:49:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: OKUMURA Shinji References: <20100508073002.1CBBE3A68A8@core3.amsl.com> <18CAF1C419F9A7shinji.okumura@softfront.jp> In-Reply-To: <18CAF1C419F9A7shinji.okumura@softfront.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Wed, 12 May 2010 20:49:45 -0000 OKUMURA Shinji wrote: > Hi, > > I have one question and one comment about UAC behavior. > > question: > At first, oa status is only audio, and during a next reINVITE > transaction oa status is changed to audio and video. And then > UAS sends a 4xx response to the reINVITE. > In this case which is a new offer UAC should send, only audio > or both of audio and video with zero port? Well, the new o/a is to restate the status quo. Since the new o/a never succeeded, the status quo includes only one m-line. So I think it would be acceptable to send an offer with that. OTOH, its possible that the other party is confused and thinks there are two m-lines in effect. It might be further confused to receive another offer with only one m-line. So it might be prudent to send the new offer as you suggest. Its legal to do so, and it ought not hurt anything. (But it might cause trouble if the other UA simply can't handle the additional m-line. If so it is quite broken.) > comment: > If already-executed changes is made by only PRACK transaction, > IMO UAC need not generate a new offer to synchronize both UAs. I don't understand what point you are making, or why. Thanks, Paul > Regards, > Shinji > > Internet-Drafts@ietf.org > Sat, 8 May 2010 00:30:02 -0700 (PDT) >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >> >> >> Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) >> Author(s) : G. Camarillo, et al. >> Filename : draft-ietf-sipcore-reinvite-04.txt >> Pages : 24 >> Date : 2010-05-08 >> >> In this document, we clarify the handling of re-INVITEs in SIP. We >> clarify in which situations a UAS (User Agent Server) should generate >> a success response and in which situations a UAS should generate an >> error response to a re-INVITE. Additionally, we clarify issues >> related to target-refresh requests. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From shinji.okumura@softfront.jp Wed May 12 18:17:26 2010 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 BBDD73A6983 for ; Wed, 12 May 2010 18:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.734 X-Spam-Level: *** X-Spam-Status: No, score=3.734 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222] 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 a7rZpKOL7WQw for ; Wed, 12 May 2010 18:17:24 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 61DC33A693A for ; Wed, 12 May 2010 18:17:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 9B25B46B322; Thu, 13 May 2010 10:17:08 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq+9vzudsRMB; Thu, 13 May 2010 10:17:03 +0900 (JST) Received: from softfront.jp (p6068-ipad403sapodori.hokkaido.ocn.ne.jp [60.43.99.68]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 81A3846B1A0; Thu, 13 May 2010 10:17:02 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Thu, 13 May 2010 10:17:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: <23CAF239FD3DB8shinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 01:17:26 -0000 Gao, gao.yang2@zte.com.cn Wed, 12 May 2010 21:10:02 +0800 >> Hi, >> >> I have one question and one comment about UAC behavior. >> >> question: >> At first, oa status is only audio, and during a next reINVITE >> transaction oa status is changed to audio and video. And then >> UAS sends a 4xx response to the reINVITE. > >If the O/A in Re-INVITE without precondition, the media modification is >defined as *in use* after the O/A by RFC3264. >So, the UAS need to send 2xx, while not 4xx. > >> In this case which is a new offer UAC should send, only audio >> or both of audio and video with zero port? > >Here, if you are talking the *legacy* UAS, then the *legacy* UAS may send >4xx. >This case is talked in "3.4. UAC Behavior" of the text. > >Current normative text is that UAC SHOULD send a new Offer to synchronize >the session state. As the session state would be synchronize by the new >O/A, so there's no rigorous rule about the content of the Offer. But the >text show tendency by the description of: >the UAC uses the criteria in Section 3.3 in order to decide whether or not >changes have been executed for the stream > >I guess this is the deliberate arrangement by Gonzalo. Gonzalo? My question is not so complicated. If a UAS recognize that current oa state is audio and video. It means SDP include two m= lines. In this condition, may UAC send offer SDP that include only one m= line? Regards, Shinji >> comment: >> If already-executed changes is made by only PRACK transaction, >> IMO UAC need not generate a new offer to synchronize both UAs. > >New Offer is used by UAC in the conditions: >"modification is *in use*, AND UAS send 4xx" or other race condition. > >I think it is not relating to the request type. > >Thanks, > >Gao From shinji.okumura@softfront.jp Wed May 12 18:30:19 2010 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 572CD3A6A14 for ; Wed, 12 May 2010 18:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.633 X-Spam-Level: ** X-Spam-Status: No, score=2.633 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222] 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 fyZM9UaB+9JG for ; Wed, 12 May 2010 18:30:18 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 129DA3A6A0F for ; Wed, 12 May 2010 18:30:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 1081246B327; Thu, 13 May 2010 10:30:08 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsBAf7bkuKsl; Thu, 13 May 2010 10:30:03 +0900 (JST) Received: from softfront.jp (p6068-ipad403sapodori.hokkaido.ocn.ne.jp [60.43.99.68]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 90F4346B1A0; Thu, 13 May 2010 10:30:02 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Thu, 13 May 2010 10:30:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4BEB145B.50702@cisco.com> References: <20100508073002.1CBBE3A68A8@core3.amsl.com> <18CAF1C419F9A7shinji.okumura@softfront.jp> <4BEB145B.50702@cisco.com> Message-Id: <30CAF23BCE2F6Dshinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 01:30:19 -0000 Hi Paul and Gao, Paul Kyzivat Wed, 12 May 2010 16:49:31 -0400 >OKUMURA Shinji wrote: >> Hi, >> >> I have one question and one comment about UAC behavior. >> >> question: >> At first, oa status is only audio, and during a next reINVITE >> transaction oa status is changed to audio and video. And then >> UAS sends a 4xx response to the reINVITE. >> In this case which is a new offer UAC should send, only audio >> or both of audio and video with zero port? > >Well, the new o/a is to restate the status quo. >Since the new o/a never succeeded, the status quo includes only one >m-line. So I think it would be acceptable to send an offer with that. > >OTOH, its possible that the other party is confused and thinks there are >two m-lines in effect. It might be further confused to receive another >offer with only one m-line. So it might be prudent to send the new offer >as you suggest. Its legal to do so, and it ought not hurt anything. >(But it might cause trouble if the other UA simply can't handle the >additional m-line. If so it is quite broken.) > >> comment: >> If already-executed changes is made by only PRACK transaction, >> IMO UAC need not generate a new offer to synchronize both UAs. > >I don't understand what point you are making, or why. As Reconfirmation of fundamental premise: If reINVITE is rejected, then both UAs must cancel all of changes within the reINVITE transaction. Originally this rollback is an automatic process, so sending new offer is not necessary. Why should UAC send new offer? The reason is that: "There are also certain race condition situations that get both user agents out of synchronization" as shown in Figure 5. In Figure 5, if UPDATE transaction does not exist, the common view of oa state is already synchronized(i.e., sendrecv audio and inactive video). I think in this case UAC need not generate a new offer. Regards, Shinji > Thanks, > Paul > >> Regards, >> Shinji >> >> Internet-Drafts@ietf.org >> Sat, 8 May 2010 00:30:02 -0700 (PDT) >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >>> >>> >>> Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) >>> Author(s) : G. Camarillo, et al. >>> Filename : draft-ietf-sipcore-reinvite-04.txt >>> Pages : 24 >>> Date : 2010-05-08 >>> >>> In this document, we clarify the handling of re-INVITEs in SIP. We >>> clarify in which situations a UAS (User Agent Server) should generate >>> a success response and in which situations a UAS should generate an >>> error response to a re-INVITE. Additionally, we clarify issues >>> related to target-refresh requests. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. From gao.yang2@zte.com.cn Wed May 12 18:33:21 2010 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 30BB93A6A01 for ; Wed, 12 May 2010 18:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.333 X-Spam-Level: X-Spam-Status: No, score=-99.333 tagged_above=-999 required=5 tests=[AWL=2.505, 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 ZAaWNbm+yb3B for ; Wed, 12 May 2010 18:33:20 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B5B0C3A693A for ; Wed, 12 May 2010 18:33:19 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Thu, 13 May 2010 09:28:39 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 57857.3015714703; Thu, 13 May 2010 09:28:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4D1WtWw009694; Thu, 13 May 2010 09:32:55 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <23CAF239FD3DB8shinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 13 May 2010 09:30:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-13 09:32:53, Serialize complete at 2010-05-13 09:32:53 Content-Type: multipart/alternative; boundary="=_alternative 0008789548257722_=" X-MAIL: mse2.zte.com.cn o4D1WtWw009694 Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 01:33:21 -0000 This is a multipart message in MIME format. --=_alternative 0008789548257722_= Content-Type: text/plain; charset="US-ASCII" Hi Shinji, > My question is not so complicated. > If a UAS recognize that current oa state is audio and video. > It means SDP include two m= lines. > In this condition, may UAC send offer SDP that include only one > m= line? Sure. But I'd like to point out that this UAS is *legacy* one. As it is *legacy* one, the UAC need to send a new O/A to synchronize the session state. And the UAC can not know the UAS's *understanding* of the state(*legacy* one is ambiguous). Thanks, Gao -------------------------------------------------------- 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 0008789548257722_= Content-Type: text/html; charset="US-ASCII"

Hi Shinji,

> My question is not so complicated.
> If a UAS recognize that current oa state is audio and video.
> It means SDP include two m= lines.
> In this condition, may UAC send offer SDP that include only one
> m= line?
Sure.

But I'd like to point out that this UAS is *legacy* one. As it is *legacy* one, the UAC need to send a new O/A to synchronize the session state. And the UAC can not know the UAS's *understanding* of the state(*legacy* one is ambiguous).

Thanks,

Gao 

--------------------------------------------------------
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 0008789548257722_=-- From gao.yang2@zte.com.cn Wed May 12 18:40:39 2010 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 58FE33A67EB for ; Wed, 12 May 2010 18:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.339 X-Spam-Level: X-Spam-Status: No, score=-97.339 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 SpRok9XjFtPl for ; Wed, 12 May 2010 18:40:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 417863A6907 for ; Wed, 12 May 2010 18:40:31 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Thu, 13 May 2010 09:34:35 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 57857.4821350471; Thu, 13 May 2010 09:35:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4D1e6Wm021769; Thu, 13 May 2010 09:40:06 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <30CAF23BCE2F6Dshinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 13 May 2010 09:37:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-13 09:40:04, Serialize complete at 2010-05-13 09:40:04 Content-Type: multipart/alternative; boundary="=_alternative 0009211C48257722_=" X-MAIL: mse2.zte.com.cn o4D1e6Wm021769 Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 01:40:39 -0000 This is a multipart message in MIME format. --=_alternative 0009211C48257722_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2hpbmppLA0KDQpBcyBJIHNhaWQgaW4gbXkgZmlyc3QgbWFpbCBpbiB0aGlzIHRocmVhZCwg dGhlIFVBUyBzaG91bGQgbm90IHNlbmQgNHh4IGJ5IA0KdGhlIG5ldyBydWxlIGluIHRoaXMgZHJh ZnQuDQoNClRoZSBiYXNpYyBwcmluY2lwbGUgaW4gdGhpcyBkcmFmdCBpcywgDQoNCjEuIElmIHRo ZSBtb2RpZmljYXRpb24gdHJpZ2dlcmVkIGJ5IHRoZSBSZS1JTlZJVEUgaXMgKmluIHVzZSosIHRo ZW4gdGhlIA0KVUFTIHNob3VsZCBub3Qgc2VuZCA0eHguDQoNCjIuIElmIHRoZSBVQVMgd2FudCB0 byByb2xsYmFjayBtb2RpZmljYXRpb24gd2hpY2ggaGFzIGJlZW4gKmluIHVzZSosIGFuIA0KVVBE QVRFIGJlZm9yZSBmaW5hbCAyeHggb2YgUmUtSU5WSVRFIGlzIHN1Z2dlc3RlZC4NCg0KVGhhbmtz LA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAg OiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQog ZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQoNCg0KDQpPS1VNVVJBIFNoaW5qaSA8c2hpbmppLm9rdW11cmFAc29mdGZyb250 LmpwPiANCjIwMTAtMDUtMTMgMDk6MzANCg0KytW8/sjLDQpzaXBjb3JlQGlldGYub3JnDQqzrcvN DQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4sIGdhby55YW5nMkB6dGUuY29tLmNu DQrW98ziDQpSZTogW3NpcGNvcmVdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52 aXRlLTA0LnR4dA0KDQoNCg0KDQoNCg0KSGkgUGF1bCBhbmQgR2FvLA0KDQpQYXVsIEt5eml2YXQg PHBreXppdmF0QGNpc2NvLmNvbT4NCldlZCwgMTIgTWF5IDIwMTAgMTY6NDk6MzEgLTA0MDANCj5P S1VNVVJBIFNoaW5qaSB3cm90ZToNCj4+IEhpLA0KPj4gDQo+PiBJIGhhdmUgb25lIHF1ZXN0aW9u IGFuZCBvbmUgY29tbWVudCBhYm91dCBVQUMgYmVoYXZpb3IuDQo+PiANCj4+IHF1ZXN0aW9uOg0K Pj4gQXQgZmlyc3QsIG9hIHN0YXR1cyBpcyBvbmx5IGF1ZGlvLCBhbmQgZHVyaW5nIGEgbmV4dCBy ZUlOVklURQ0KPj4gdHJhbnNhY3Rpb24gb2Egc3RhdHVzIGlzIGNoYW5nZWQgdG8gYXVkaW8gYW5k IHZpZGVvLiBBbmQgdGhlbg0KPj4gVUFTIHNlbmRzIGEgNHh4IHJlc3BvbnNlIHRvIHRoZSByZUlO VklURS4NCj4+IEluIHRoaXMgY2FzZSB3aGljaCBpcyBhIG5ldyBvZmZlciBVQUMgc2hvdWxkIHNl bmQsIG9ubHkgYXVkaW8NCj4+IG9yIGJvdGggb2YgYXVkaW8gYW5kIHZpZGVvIHdpdGggemVybyBw b3J0Pw0KPg0KPldlbGwsIHRoZSBuZXcgby9hIGlzIHRvIHJlc3RhdGUgdGhlIHN0YXR1cyBxdW8u DQo+U2luY2UgdGhlIG5ldyBvL2EgbmV2ZXIgc3VjY2VlZGVkLCB0aGUgc3RhdHVzIHF1byBpbmNs dWRlcyBvbmx5IG9uZSANCj5tLWxpbmUuIFNvIEkgdGhpbmsgaXQgd291bGQgYmUgYWNjZXB0YWJs ZSB0byBzZW5kIGFuIG9mZmVyIHdpdGggdGhhdC4NCj4NCj5PVE9ILCBpdHMgcG9zc2libGUgdGhh dCB0aGUgb3RoZXIgcGFydHkgaXMgY29uZnVzZWQgYW5kIHRoaW5rcyB0aGVyZSBhcmUgDQo+dHdv IG0tbGluZXMgaW4gZWZmZWN0LiBJdCBtaWdodCBiZSBmdXJ0aGVyIGNvbmZ1c2VkIHRvIHJlY2Vp dmUgYW5vdGhlciANCj5vZmZlciB3aXRoIG9ubHkgb25lIG0tbGluZS4gU28gaXQgbWlnaHQgYmUg cHJ1ZGVudCB0byBzZW5kIHRoZSBuZXcgb2ZmZXIgDQo+YXMgeW91IHN1Z2dlc3QuIEl0cyBsZWdh bCB0byBkbyBzbywgYW5kIGl0IG91Z2h0IG5vdCBodXJ0IGFueXRoaW5nLg0KPihCdXQgaXQgbWln aHQgY2F1c2UgdHJvdWJsZSBpZiB0aGUgb3RoZXIgVUEgc2ltcGx5IGNhbid0IGhhbmRsZSB0aGUg DQo+YWRkaXRpb25hbCBtLWxpbmUuIElmIHNvIGl0IGlzIHF1aXRlIGJyb2tlbi4pDQo+DQo+PiBj b21tZW50Og0KPj4gSWYgYWxyZWFkeS1leGVjdXRlZCBjaGFuZ2VzIGlzIG1hZGUgYnkgb25seSBQ UkFDSyB0cmFuc2FjdGlvbiwNCj4+IElNTyBVQUMgbmVlZCBub3QgZ2VuZXJhdGUgYSBuZXcgb2Zm ZXIgdG8gc3luY2hyb25pemUgYm90aCBVQXMuDQo+DQo+SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQg cG9pbnQgeW91IGFyZSBtYWtpbmcsIG9yIHdoeS4NCg0KQXMgUmVjb25maXJtYXRpb24gb2YgZnVu ZGFtZW50YWwgcHJlbWlzZToNCg0KSWYgcmVJTlZJVEUgaXMgcmVqZWN0ZWQsIHRoZW4gYm90aCBV QXMgbXVzdCBjYW5jZWwgYWxsIG9mDQpjaGFuZ2VzIHdpdGhpbiB0aGUgcmVJTlZJVEUgdHJhbnNh Y3Rpb24uDQpPcmlnaW5hbGx5IHRoaXMgcm9sbGJhY2sgaXMgYW4gYXV0b21hdGljIHByb2Nlc3Ms IHNvIHNlbmRpbmcNCm5ldyBvZmZlciBpcyBub3QgbmVjZXNzYXJ5Lg0KDQpXaHkgc2hvdWxkIFVB QyBzZW5kIG5ldyBvZmZlcj8NClRoZSByZWFzb24gaXMgdGhhdDoNCiAgICJUaGVyZSBhcmUgYWxz byBjZXJ0YWluDQogICByYWNlIGNvbmRpdGlvbiBzaXR1YXRpb25zIHRoYXQgZ2V0IGJvdGggdXNl ciBhZ2VudHMgb3V0IG9mDQogICBzeW5jaHJvbml6YXRpb24iIGFzIHNob3duIGluIEZpZ3VyZSA1 Lg0KDQpJbiBGaWd1cmUgNSwgaWYgVVBEQVRFIHRyYW5zYWN0aW9uIGRvZXMgbm90IGV4aXN0LCB0 aGUgY29tbW9uDQp2aWV3IG9mIG9hIHN0YXRlIGlzIGFscmVhZHkgc3luY2hyb25pemVkKGkuZS4s IHNlbmRyZWN2IGF1ZGlvDQphbmQgaW5hY3RpdmUgdmlkZW8pLg0KDQpJIHRoaW5rIGluIHRoaXMg Y2FzZSBVQUMgbmVlZCBub3QgZ2VuZXJhdGUgYSBuZXcgb2ZmZXIuDQoNClJlZ2FyZHMsDQpTaGlu amkNCg0KPiAgICAgICAgICAgICAgICBUaGFua3MsDQo+ICAgICAgICAgICAgICAgIFBhdWwNCj4N Cj4+IFJlZ2FyZHMsDQo+PiBTaGluamkNCj4+IA0KPj4gSW50ZXJuZXQtRHJhZnRzQGlldGYub3Jn DQo+PiBTYXQsICA4IE1heSAyMDEwIDAwOjMwOjAyIC0wNzAwIChQRFQpDQo+Pj4gQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IA0KZGlyZWN0b3JpZXMuDQo+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2Vz c2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUgDQpXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRG Lg0KPj4+DQo+Pj4NCj4+PiAgICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUmUtSU5WSVRF IGFuZCBUYXJnZXQtcmVmcmVzaCBSZXF1ZXN0IA0KSGFuZGxpbmcgaW4gdGhlIFNlc3Npb24gSW5p dGlhdGlvbiBQcm90b2NvbCAoU0lQKQ0KPj4+ICAgICAgICAgICAgICBBdXRob3IocykgICAgICAg OiBHLiBDYW1hcmlsbG8sIGV0IGFsLg0KPj4+ICAgICAgICAgICAgICBGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQudHh0DQo+Pj4gICAgICAgICAgICAgIFBh Z2VzICAgICAgICAgICA6IDI0DQo+Pj4gICAgICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIw MTAtMDUtMDgNCj4+Pg0KPj4+IEluIHRoaXMgZG9jdW1lbnQsIHdlIGNsYXJpZnkgdGhlIGhhbmRs aW5nIG9mIHJlLUlOVklURXMgaW4gU0lQLiAgV2UNCj4+PiBjbGFyaWZ5IGluIHdoaWNoIHNpdHVh dGlvbnMgYSBVQVMgKFVzZXIgQWdlbnQgU2VydmVyKSBzaG91bGQgZ2VuZXJhdGUNCj4+PiBhIHN1 Y2Nlc3MgcmVzcG9uc2UgYW5kIGluIHdoaWNoIHNpdHVhdGlvbnMgYSBVQVMgc2hvdWxkIGdlbmVy YXRlIGFuDQo+Pj4gZXJyb3IgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUuICBBZGRpdGlvbmFsbHks IHdlIGNsYXJpZnkgaXNzdWVzDQo+Pj4gcmVsYXRlZCB0byB0YXJnZXQtcmVmcmVzaCByZXF1ZXN0 cy4NCj4+Pg0KPj4+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPj4+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwY29yZS1yZWludml0 ZS0wNC50eHQNCj4+Pg0KPj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KPj4+DQo+Pj4gQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNv bXBsaWFudCBtYWlsIHJlYWRlcg0KPj4+IGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkg cmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlDQo+Pj4gSW50ZXJuZXQtRHJhZnQuDQoN Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLg0K --=_alternative 0009211C48257722_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNoaW5qaSw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIEkgc2FpZCBpbiBteSBm aXJzdCBtYWlsIGluIHRoaXMgdGhyZWFkLA0KdGhlIFVBUyBzaG91bGQgbm90IHNlbmQgNHh4IGJ5 IHRoZSBuZXcgcnVsZSBpbiB0aGlzIGRyYWZ0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGJhc2ljIHByaW5jaXBsZSBpbiB0aGlzIGRyYWZ0IGlz LA0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBJ ZiB0aGUgbW9kaWZpY2F0aW9uIHRyaWdnZXJlZCBieQ0KdGhlIFJlLUlOVklURSBpcyAqaW4gdXNl KiwgdGhlbiB0aGUgVUFTIHNob3VsZCBub3Qgc2VuZCA0eHguPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLiBJZiB0aGUgVUFTIHdhbnQgdG8gcm9sbGJh Y2sgbW9kaWZpY2F0aW9uDQp3aGljaCBoYXMgYmVlbiAqaW4gdXNlKiwgYW4gVVBEQVRFIGJlZm9y ZSBmaW5hbCAyeHggb2YgUmUtSU5WSVRFIGlzIHN1Z2dlc3RlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZu YnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBl X21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPk9LVU1VUkEgU2hpbmppICZsdDtzaGluamkub2t1bXVyYUBzb2Z0ZnJvbnQuanAm Z3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAt MDUtMTMgMDk6MzA8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+c2lwY29yZUBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UGF1bCBLeXpp dmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7LA0KZ2FvLnlhbmcyQHp0ZS5jb20uY248L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLXNpcGNv cmUtcmVpbnZpdGUtMDQudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBQYXVsIGFuZCBHYW8sPGJyPg0KPGJyPg0KUGF1bCBLeXpp dmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7PGJyPg0KV2VkLCAxMiBNYXkgMjAxMCAxNjo0 OTozMSAtMDQwMDxicj4NCiZndDtPS1VNVVJBIFNoaW5qaSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBI aSw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIGhhdmUgb25lIHF1ZXN0aW9uIGFuZCBv bmUgY29tbWVudCBhYm91dCBVQUMgYmVoYXZpb3IuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgcXVlc3Rpb246PGJyPg0KJmd0OyZndDsgQXQgZmlyc3QsIG9hIHN0YXR1cyBpcyBvbmx5IGF1 ZGlvLCBhbmQgZHVyaW5nIGEgbmV4dCByZUlOVklURTxicj4NCiZndDsmZ3Q7IHRyYW5zYWN0aW9u IG9hIHN0YXR1cyBpcyBjaGFuZ2VkIHRvIGF1ZGlvIGFuZCB2aWRlby4gQW5kIHRoZW48YnI+DQom Z3Q7Jmd0OyBVQVMgc2VuZHMgYSA0eHggcmVzcG9uc2UgdG8gdGhlIHJlSU5WSVRFLjxicj4NCiZn dDsmZ3Q7IEluIHRoaXMgY2FzZSB3aGljaCBpcyBhIG5ldyBvZmZlciBVQUMgc2hvdWxkIHNlbmQs IG9ubHkgYXVkaW88YnI+DQomZ3Q7Jmd0OyBvciBib3RoIG9mIGF1ZGlvIGFuZCB2aWRlbyB3aXRo IHplcm8gcG9ydD88YnI+DQomZ3Q7PGJyPg0KJmd0O1dlbGwsIHRoZSBuZXcgby9hIGlzIHRvIHJl c3RhdGUgdGhlIHN0YXR1cyBxdW8uPGJyPg0KJmd0O1NpbmNlIHRoZSBuZXcgby9hIG5ldmVyIHN1 Y2NlZWRlZCwgdGhlIHN0YXR1cyBxdW8gaW5jbHVkZXMgb25seSBvbmUNCjxicj4NCiZndDttLWxp bmUuIFNvIEkgdGhpbmsgaXQgd291bGQgYmUgYWNjZXB0YWJsZSB0byBzZW5kIGFuIG9mZmVyIHdp dGggdGhhdC48YnI+DQomZ3Q7PGJyPg0KJmd0O09UT0gsIGl0cyBwb3NzaWJsZSB0aGF0IHRoZSBv dGhlciBwYXJ0eSBpcyBjb25mdXNlZCBhbmQgdGhpbmtzIHRoZXJlDQphcmUgPGJyPg0KJmd0O3R3 byBtLWxpbmVzIGluIGVmZmVjdC4gSXQgbWlnaHQgYmUgZnVydGhlciBjb25mdXNlZCB0byByZWNl aXZlIGFub3RoZXINCjxicj4NCiZndDtvZmZlciB3aXRoIG9ubHkgb25lIG0tbGluZS4gU28gaXQg bWlnaHQgYmUgcHJ1ZGVudCB0byBzZW5kIHRoZSBuZXcNCm9mZmVyIDxicj4NCiZndDthcyB5b3Ug c3VnZ2VzdC4gSXRzIGxlZ2FsIHRvIGRvIHNvLCBhbmQgaXQgb3VnaHQgbm90IGh1cnQgYW55dGhp bmcuPGJyPg0KJmd0OyhCdXQgaXQgbWlnaHQgY2F1c2UgdHJvdWJsZSBpZiB0aGUgb3RoZXIgVUEg c2ltcGx5IGNhbid0IGhhbmRsZSB0aGUNCjxicj4NCiZndDthZGRpdGlvbmFsIG0tbGluZS4gSWYg c28gaXQgaXMgcXVpdGUgYnJva2VuLik8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgY29tbWVudDo8 YnI+DQomZ3Q7Jmd0OyBJZiBhbHJlYWR5LWV4ZWN1dGVkIGNoYW5nZXMgaXMgbWFkZSBieSBvbmx5 IFBSQUNLIHRyYW5zYWN0aW9uLDxicj4NCiZndDsmZ3Q7IElNTyBVQUMgbmVlZCBub3QgZ2VuZXJh dGUgYSBuZXcgb2ZmZXIgdG8gc3luY2hyb25pemUgYm90aCBVQXMuPGJyPg0KJmd0Ozxicj4NCiZn dDtJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCBwb2ludCB5b3UgYXJlIG1ha2luZywgb3Igd2h5Ljxi cj4NCjxicj4NCkFzIFJlY29uZmlybWF0aW9uIG9mIGZ1bmRhbWVudGFsIHByZW1pc2U6PGJyPg0K PGJyPg0KSWYgcmVJTlZJVEUgaXMgcmVqZWN0ZWQsIHRoZW4gYm90aCBVQXMgbXVzdCBjYW5jZWwg YWxsIG9mPGJyPg0KY2hhbmdlcyB3aXRoaW4gdGhlIHJlSU5WSVRFIHRyYW5zYWN0aW9uLjxicj4N Ck9yaWdpbmFsbHkgdGhpcyByb2xsYmFjayBpcyBhbiBhdXRvbWF0aWMgcHJvY2Vzcywgc28gc2Vu ZGluZzxicj4NCm5ldyBvZmZlciBpcyBub3QgbmVjZXNzYXJ5Ljxicj4NCjxicj4NCldoeSBzaG91 bGQgVUFDIHNlbmQgbmV3IG9mZmVyPzxicj4NClRoZSByZWFzb24gaXMgdGhhdDo8YnI+DQogJm5i c3A7ICZxdW90O1RoZXJlIGFyZSBhbHNvIGNlcnRhaW48YnI+DQogJm5ic3A7IHJhY2UgY29uZGl0 aW9uIHNpdHVhdGlvbnMgdGhhdCBnZXQgYm90aCB1c2VyIGFnZW50cyBvdXQgb2Y8YnI+DQogJm5i c3A7IHN5bmNocm9uaXphdGlvbiZxdW90OyBhcyBzaG93biBpbiBGaWd1cmUgNS48YnI+DQo8YnI+ DQpJbiBGaWd1cmUgNSwgaWYgVVBEQVRFIHRyYW5zYWN0aW9uIGRvZXMgbm90IGV4aXN0LCB0aGUg Y29tbW9uPGJyPg0KdmlldyBvZiBvYSBzdGF0ZSBpcyBhbHJlYWR5IHN5bmNocm9uaXplZChpLmUu LCBzZW5kcmVjdiBhdWRpbzxicj4NCmFuZCBpbmFjdGl2ZSB2aWRlbykuPGJyPg0KPGJyPg0KSSB0 aGluayBpbiB0aGlzIGNhc2UgVUFDIG5lZWQgbm90IGdlbmVyYXRlIGEgbmV3IG9mZmVyLjxicj4N Cjxicj4NClJlZ2FyZHMsPGJyPg0KU2hpbmppPGJyPg0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGFua3MsPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQpQYXVsPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsg U2hpbmppPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSW50ZXJuZXQtRHJhZnRzQGlldGYu b3JnPGJyPg0KJmd0OyZndDsgU2F0LCAmbmJzcDs4IE1heSAyMDEwIDAwOjMwOjAyIC0wNzAwIChQ RFQpPGJyPg0KJmd0OyZndDsmZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyZn dDsmZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbA0KQ29yZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtUaXRsZSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogUmUtSU5WSVRFIGFuZA0KVGFyZ2V0LXJl ZnJlc2ggUmVxdWVzdCBIYW5kbGluZyBpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29s IChTSVApPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0F1dGhvcihzKSAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IEcuIENhbWFyaWxsbywgZXQgYWwuPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0ZpbGVu YW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52 aXRlLTA0LnR4dDxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtQYWdlcyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDogMjQ8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7RGF0ZSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxMC0wNS0wODxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJbiB0aGlzIGRvY3VtZW50LCB3ZSBjbGFyaWZ5 IHRoZSBoYW5kbGluZyBvZiByZS1JTlZJVEVzIGluDQpTSVAuICZuYnNwO1dlPGJyPg0KJmd0OyZn dDsmZ3Q7IGNsYXJpZnkgaW4gd2hpY2ggc2l0dWF0aW9ucyBhIFVBUyAoVXNlciBBZ2VudCBTZXJ2 ZXIpIHNob3VsZA0KZ2VuZXJhdGU8YnI+DQomZ3Q7Jmd0OyZndDsgYSBzdWNjZXNzIHJlc3BvbnNl IGFuZCBpbiB3aGljaCBzaXR1YXRpb25zIGEgVUFTIHNob3VsZCBnZW5lcmF0ZQ0KYW48YnI+DQom Z3Q7Jmd0OyZndDsgZXJyb3IgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUuICZuYnNwO0FkZGl0aW9u YWxseSwgd2UgY2xhcmlmeQ0KaXNzdWVzPGJyPg0KJmd0OyZndDsmZ3Q7IHJlbGF0ZWQgdG8gdGFy Z2V0LXJlZnJlc2ggcmVxdWVzdHMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxicj4NCiZndDsmZ3Q7Jmd0OyBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZp dGUtMDQudHh0PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7Jmd0 OyZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+DQomZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsgQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUg YSBNSU1FIGNvbXBsaWFudCBtYWlsDQpyZWFkZXI8YnI+DQomZ3Q7Jmd0OyZndDsgaW1wbGVtZW50 YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbg0Kb2YgdGhl PGJyPg0KJmd0OyZndDsmZ3Q7IEludGVybmV0LURyYWZ0Ljxicj4NCjxicj4NCjwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZu YnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5 Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtU aGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlh bC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29i bGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7 YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3Ro ZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7 ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2Nv bmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5i c3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3Im bmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRk cmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhp cyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZu YnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5i c3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJz cDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDti eSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0009211C48257722_=-- From shinji.okumura@softfront.jp Wed May 12 19:08:19 2010 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 A31B73A69FF for ; Wed, 12 May 2010 19:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.55 X-Spam-Level: ** X-Spam-Status: No, score=2.55 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222] 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 P4utGGwss0ch for ; Wed, 12 May 2010 19:08:18 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 6C78C3A67AF for ; Wed, 12 May 2010 19:08:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id B817146B32D; Thu, 13 May 2010 11:08:07 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCJ9vMoDl-d3; Thu, 13 May 2010 11:08:03 +0900 (JST) Received: from softfront.jp (p6068-ipad403sapodori.hokkaido.ocn.ne.jp [60.43.99.68]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 3527A46B327; Thu, 13 May 2010 11:08:02 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Thu, 13 May 2010 11:08:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: <48CAF2411CE44Bshinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 02:08:19 -0000 Gao, I am talking about "UAC Behavior". What you say is "UAS Behavior". The basic principle in my opinion is, If an UPDATE has been not used, then the original rollback process may works well. Regards, Shinji gao.yang2@zte.com.cn Thu, 13 May 2010 09:37:19 +0800 >Hi Shinji, > >As I said in my first mail in this thread, the UAS should not send 4xx by >the new rule in this draft. > >The basic principle in this draft is, > >1. If the modification triggered by the Re-INVITE is *in use*, then the >UAS should not send 4xx. > >2. If the UAS want to rollback modification which has been *in use*, an >UPDATE before final 2xx of Re-INVITE is suggested. > >Thanks, > >Gao > >=================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn >=================================== > >OKUMURA Shinji >2010-05-13 09:30 > >Hi Paul and Gao, > >Paul Kyzivat >Wed, 12 May 2010 16:49:31 -0400 >>OKUMURA Shinji wrote: >>> Hi, >>> >>> I have one question and one comment about UAC behavior. >>> >>> question: >>> At first, oa status is only audio, and during a next reINVITE >>> transaction oa status is changed to audio and video. And then >>> UAS sends a 4xx response to the reINVITE. >>> In this case which is a new offer UAC should send, only audio >>> or both of audio and video with zero port? >> >>Well, the new o/a is to restate the status quo. >>Since the new o/a never succeeded, the status quo includes only one >>m-line. So I think it would be acceptable to send an offer with that. >> >>OTOH, its possible that the other party is confused and thinks there are >>two m-lines in effect. It might be further confused to receive another >>offer with only one m-line. So it might be prudent to send the new offer >>as you suggest. Its legal to do so, and it ought not hurt anything. >>(But it might cause trouble if the other UA simply can't handle the >>additional m-line. If so it is quite broken.) >> >>> comment: >>> If already-executed changes is made by only PRACK transaction, >>> IMO UAC need not generate a new offer to synchronize both UAs. >> >>I don't understand what point you are making, or why. > >As Reconfirmation of fundamental premise: > >If reINVITE is rejected, then both UAs must cancel all of >changes within the reINVITE transaction. >Originally this rollback is an automatic process, so sending >new offer is not necessary. > >Why should UAC send new offer? >The reason is that: > "There are also certain > race condition situations that get both user agents out of > synchronization" as shown in Figure 5. > >In Figure 5, if UPDATE transaction does not exist, the common >view of oa state is already synchronized(i.e., sendrecv audio >and inactive video). > >I think in this case UAC need not generate a new offer. > >Regards, >Shinji > >> Thanks, >> Paul >> >>> Regards, >>> Shinji >>> >>> Internet-Drafts@ietf.org >>> Sat, 8 May 2010 00:30:02 -0700 (PDT) >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >>>> >>>> >>>> Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) >>>> Author(s) : G. Camarillo, et al. >>>> Filename : draft-ietf-sipcore-reinvite-04.txt >>>> Pages : 24 >>>> Date : 2010-05-08 >>>> >>>> In this document, we clarify the handling of re-INVITEs in SIP. We >>>> clarify in which situations a UAS (User Agent Server) should generate >>>> a success response and in which situations a UAS should generate an >>>> error response to a re-INVITE. Additionally, we clarify issues >>>> related to target-refresh requests. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From gao.yang2@zte.com.cn Wed May 12 19:14:45 2010 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 996A83A6908 for ; Wed, 12 May 2010 19:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.312 X-Spam-Level: X-Spam-Status: No, score=-97.312 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 1zbAEmxuFa0R for ; Wed, 12 May 2010 19:14:44 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 864823A6907 for ; Wed, 12 May 2010 19:14:42 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Thu, 13 May 2010 10:10:05 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 57857.3015714703; Thu, 13 May 2010 10:09:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4D2Dxq3070069; Thu, 13 May 2010 10:14:07 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <48CAF2411CE44Bshinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 13 May 2010 10:11:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-13 10:14:04, Serialize complete at 2010-05-13 10:14:04 Content-Type: multipart/alternative; boundary="=_alternative 000C3D6548257722_=" X-MAIL: mse2.zte.com.cn o4D2Dxq3070069 Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 02:14:45 -0000 This is a multipart message in MIME format. --=_alternative 000C3D6548257722_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U2hpbmppLA0KDQpJZiB0aGUgVUFTIGlzIHVuZGVyIHRoaXMgZHJhZnQncyBydWxlcywgdGhlIFVB UyB3b3VsZCBub3Qgc2VuZCA0eHguDQpUaGVuLCB5b3VyIHByb2JsZW0gaXMgbm90IGV4aXN0Lg0K DQpUaGF0J3Mgd2h5IEkgdGFsayBVQVMncyBydWxlIGZpcnN0Lg0KDQpUaGFua3MsDQoNCkdhbw0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0K IFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBn YW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cg0KDQoNCk9LVU1VUkEgU2hpbmppIDxzaGluamkub2t1bXVyYUBzb2Z0ZnJvbnQuanA+IA0KMjAx MC0wNS0xMyAxMDowOA0KDQrK1bz+yMsNCnNpcGNvcmVAaWV0Zi5vcmcNCrOty80NCmdhby55YW5n MkB6dGUuY29tLmNuDQrW98ziDQpSZTogW3NpcGNvcmVdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1z aXBjb3JlLXJlaW52aXRlLTA0LnR4dA0KDQoNCg0KDQoNCg0KR2FvLA0KDQpJIGFtIHRhbGtpbmcg YWJvdXQgIlVBQyBCZWhhdmlvciIuDQpXaGF0IHlvdSBzYXkgaXMgIlVBUyBCZWhhdmlvciIuDQoN ClRoZSBiYXNpYyBwcmluY2lwbGUgaW4gbXkgb3BpbmlvbiBpcywgDQoNCklmIGFuIFVQREFURSBo YXMgYmVlbiBub3QgdXNlZCwgdGhlbiB0aGUgb3JpZ2luYWwgcm9sbGJhY2sNCnByb2Nlc3MgbWF5 IHdvcmtzIHdlbGwuDQoNClJlZ2FyZHMsDQpTaGluamkNCg0KZ2FvLnlhbmcyQHp0ZS5jb20uY24N ClRodSwgMTMgTWF5IDIwMTAgMDk6Mzc6MTkgKzA4MDANCj5IaSBTaGluamksDQo+DQo+QXMgSSBz YWlkIGluIG15IGZpcnN0IG1haWwgaW4gdGhpcyB0aHJlYWQsIHRoZSBVQVMgc2hvdWxkIG5vdCBz ZW5kIDR4eCBieSANCg0KPnRoZSBuZXcgcnVsZSBpbiB0aGlzIGRyYWZ0Lg0KPg0KPlRoZSBiYXNp YyBwcmluY2lwbGUgaW4gdGhpcyBkcmFmdCBpcywgDQo+DQo+MS4gSWYgdGhlIG1vZGlmaWNhdGlv biB0cmlnZ2VyZWQgYnkgdGhlIFJlLUlOVklURSBpcyAqaW4gdXNlKiwgdGhlbiB0aGUgDQo+VUFT IHNob3VsZCBub3Qgc2VuZCA0eHguDQo+DQo+Mi4gSWYgdGhlIFVBUyB3YW50IHRvIHJvbGxiYWNr IG1vZGlmaWNhdGlvbiB3aGljaCBoYXMgYmVlbiAqaW4gdXNlKiwgYW4gDQo+VVBEQVRFIGJlZm9y ZSBmaW5hbCAyeHggb2YgUmUtSU5WSVRFIGlzIHN1Z2dlc3RlZC4NCj4NCj5UaGFua3MsDQo+DQo+ R2FvDQo+DQo+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gWmlwICAgIDog MjEwMDEyDQo+IFRlbCAgICA6IDg3MjExDQo+IFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQo+ IGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo+PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCj4NCj5PS1VNVVJBIFNoaW5qaSA8c2hpbmppLm9rdW11cmFAc29mdGZyb250 LmpwPiANCj4yMDEwLTA1LTEzIDA5OjMwDQo+DQo+SGkgUGF1bCBhbmQgR2FvLA0KPg0KPlBhdWwg S3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPg0KPldlZCwgMTIgTWF5IDIwMTAgMTY6NDk6MzEg LTA0MDANCj4+T0tVTVVSQSBTaGluamkgd3JvdGU6DQo+Pj4gSGksDQo+Pj4gDQo+Pj4gSSBoYXZl IG9uZSBxdWVzdGlvbiBhbmQgb25lIGNvbW1lbnQgYWJvdXQgVUFDIGJlaGF2aW9yLg0KPj4+IA0K Pj4+IHF1ZXN0aW9uOg0KPj4+IEF0IGZpcnN0LCBvYSBzdGF0dXMgaXMgb25seSBhdWRpbywgYW5k IGR1cmluZyBhIG5leHQgcmVJTlZJVEUNCj4+PiB0cmFuc2FjdGlvbiBvYSBzdGF0dXMgaXMgY2hh bmdlZCB0byBhdWRpbyBhbmQgdmlkZW8uIEFuZCB0aGVuDQo+Pj4gVUFTIHNlbmRzIGEgNHh4IHJl c3BvbnNlIHRvIHRoZSByZUlOVklURS4NCj4+PiBJbiB0aGlzIGNhc2Ugd2hpY2ggaXMgYSBuZXcg b2ZmZXIgVUFDIHNob3VsZCBzZW5kLCBvbmx5IGF1ZGlvDQo+Pj4gb3IgYm90aCBvZiBhdWRpbyBh bmQgdmlkZW8gd2l0aCB6ZXJvIHBvcnQ/DQo+Pg0KPj5XZWxsLCB0aGUgbmV3IG8vYSBpcyB0byBy ZXN0YXRlIHRoZSBzdGF0dXMgcXVvLg0KPj5TaW5jZSB0aGUgbmV3IG8vYSBuZXZlciBzdWNjZWVk ZWQsIHRoZSBzdGF0dXMgcXVvIGluY2x1ZGVzIG9ubHkgb25lIA0KPj5tLWxpbmUuIFNvIEkgdGhp bmsgaXQgd291bGQgYmUgYWNjZXB0YWJsZSB0byBzZW5kIGFuIG9mZmVyIHdpdGggdGhhdC4NCj4+ DQo+Pk9UT0gsIGl0cyBwb3NzaWJsZSB0aGF0IHRoZSBvdGhlciBwYXJ0eSBpcyBjb25mdXNlZCBh bmQgdGhpbmtzIHRoZXJlIGFyZSANCg0KPj50d28gbS1saW5lcyBpbiBlZmZlY3QuIEl0IG1pZ2h0 IGJlIGZ1cnRoZXIgY29uZnVzZWQgdG8gcmVjZWl2ZSBhbm90aGVyIA0KPj5vZmZlciB3aXRoIG9u bHkgb25lIG0tbGluZS4gU28gaXQgbWlnaHQgYmUgcHJ1ZGVudCB0byBzZW5kIHRoZSBuZXcgb2Zm ZXIgDQoNCj4+YXMgeW91IHN1Z2dlc3QuIEl0cyBsZWdhbCB0byBkbyBzbywgYW5kIGl0IG91Z2h0 IG5vdCBodXJ0IGFueXRoaW5nLg0KPj4oQnV0IGl0IG1pZ2h0IGNhdXNlIHRyb3VibGUgaWYgdGhl IG90aGVyIFVBIHNpbXBseSBjYW4ndCBoYW5kbGUgdGhlIA0KPj5hZGRpdGlvbmFsIG0tbGluZS4g SWYgc28gaXQgaXMgcXVpdGUgYnJva2VuLikNCj4+DQo+Pj4gY29tbWVudDoNCj4+PiBJZiBhbHJl YWR5LWV4ZWN1dGVkIGNoYW5nZXMgaXMgbWFkZSBieSBvbmx5IFBSQUNLIHRyYW5zYWN0aW9uLA0K Pj4+IElNTyBVQUMgbmVlZCBub3QgZ2VuZXJhdGUgYSBuZXcgb2ZmZXIgdG8gc3luY2hyb25pemUg Ym90aCBVQXMuDQo+Pg0KPj5JIGRvbid0IHVuZGVyc3RhbmQgd2hhdCBwb2ludCB5b3UgYXJlIG1h a2luZywgb3Igd2h5Lg0KPg0KPkFzIFJlY29uZmlybWF0aW9uIG9mIGZ1bmRhbWVudGFsIHByZW1p c2U6DQo+DQo+SWYgcmVJTlZJVEUgaXMgcmVqZWN0ZWQsIHRoZW4gYm90aCBVQXMgbXVzdCBjYW5j ZWwgYWxsIG9mDQo+Y2hhbmdlcyB3aXRoaW4gdGhlIHJlSU5WSVRFIHRyYW5zYWN0aW9uLg0KPk9y aWdpbmFsbHkgdGhpcyByb2xsYmFjayBpcyBhbiBhdXRvbWF0aWMgcHJvY2Vzcywgc28gc2VuZGlu Zw0KPm5ldyBvZmZlciBpcyBub3QgbmVjZXNzYXJ5Lg0KPg0KPldoeSBzaG91bGQgVUFDIHNlbmQg bmV3IG9mZmVyPw0KPlRoZSByZWFzb24gaXMgdGhhdDoNCj4gICAiVGhlcmUgYXJlIGFsc28gY2Vy dGFpbg0KPiAgIHJhY2UgY29uZGl0aW9uIHNpdHVhdGlvbnMgdGhhdCBnZXQgYm90aCB1c2VyIGFn ZW50cyBvdXQgb2YNCj4gICBzeW5jaHJvbml6YXRpb24iIGFzIHNob3duIGluIEZpZ3VyZSA1Lg0K Pg0KPkluIEZpZ3VyZSA1LCBpZiBVUERBVEUgdHJhbnNhY3Rpb24gZG9lcyBub3QgZXhpc3QsIHRo ZSBjb21tb24NCj52aWV3IG9mIG9hIHN0YXRlIGlzIGFscmVhZHkgc3luY2hyb25pemVkKGkuZS4s IHNlbmRyZWN2IGF1ZGlvDQo+YW5kIGluYWN0aXZlIHZpZGVvKS4NCj4NCj5JIHRoaW5rIGluIHRo aXMgY2FzZSBVQUMgbmVlZCBub3QgZ2VuZXJhdGUgYSBuZXcgb2ZmZXIuDQo+DQo+UmVnYXJkcywN Cj5TaGluamkNCj4NCj4+ICAgICAgICAgICAgICAgIFRoYW5rcywNCj4+ICAgICAgICAgICAgICAg IFBhdWwNCj4+DQo+Pj4gUmVnYXJkcywNCj4+PiBTaGluamkNCj4+PiANCj4+PiBJbnRlcm5ldC1E cmFmdHNAaWV0Zi5vcmcNCj4+PiBTYXQsICA4IE1heSAyMDEwIDAwOjMwOjAyIC0wNzAwIChQRFQp DQo+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cyANCmRpcmVjdG9yaWVzLg0KPj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSANCldvcmtpbmcg R3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+DQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBSZS1JTlZJVEUgYW5kIFRhcmdldC1yZWZyZXNoIFJlcXVlc3QgDQpIYW5kbGlu ZyBpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApDQo+Pj4+ICAgICAgICAg ICAgICBBdXRob3IocykgICAgICAgOiBHLiBDYW1hcmlsbG8sIGV0IGFsLg0KPj4+PiAgICAgICAg ICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0LnR4 dA0KPj4+PiAgICAgICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMjQNCj4+Pj4gICAgICAgICAg ICAgIERhdGUgICAgICAgICAgICA6IDIwMTAtMDUtMDgNCj4+Pj4NCj4+Pj4gSW4gdGhpcyBkb2N1 bWVudCwgd2UgY2xhcmlmeSB0aGUgaGFuZGxpbmcgb2YgcmUtSU5WSVRFcyBpbiBTSVAuICBXZQ0K Pj4+PiBjbGFyaWZ5IGluIHdoaWNoIHNpdHVhdGlvbnMgYSBVQVMgKFVzZXIgQWdlbnQgU2VydmVy KSBzaG91bGQgZ2VuZXJhdGUNCj4+Pj4gYSBzdWNjZXNzIHJlc3BvbnNlIGFuZCBpbiB3aGljaCBz aXR1YXRpb25zIGEgVUFTIHNob3VsZCBnZW5lcmF0ZSBhbg0KPj4+PiBlcnJvciByZXNwb25zZSB0 byBhIHJlLUlOVklURS4gIEFkZGl0aW9uYWxseSwgd2UgY2xhcmlmeSBpc3N1ZXMNCj4+Pj4gcmVs YXRlZCB0byB0YXJnZXQtcmVmcmVzaCByZXF1ZXN0cy4NCj4+Pj4NCj4+Pj4gQSBVUkwgZm9yIHRo aXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+Pj4+IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0LnR4dA0KPj4+Pg0KPj4+PiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+DQo+Pj4+IEJlbG93 IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFk ZXINCj4+Pj4gaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVND SUkgdmVyc2lvbiBvZiB0aGUNCj4+Pj4gSW50ZXJuZXQtRHJhZnQuDQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaXBjb3JlIG1haWxpbmcgbGlz dA0KPnNpcGNvcmVAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlz IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo ZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu ZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000C3D6548257722_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNoaW5qaSw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIHRoZSBVQVMgaXMgdW5kZXIg dGhpcyBkcmFmdCdzIHJ1bGVzLA0KdGhlIFVBUyB3b3VsZCBub3Qgc2VuZCA0eHguPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVuLCB5b3VyIHByb2JsZW0gaXMg bm90IGV4aXN0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+VGhhdCdzIHdoeSBJIHRhbGsgVUFTJ3MgcnVsZSBmaXJzdC48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZu YnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBl X21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPk9LVU1VUkEgU2hpbmppICZsdDtzaGluamkub2t1bXVyYUBzb2Z0ZnJvbnQuanAm Z3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAt MDUtMTMgMTA6MDg8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+c2lwY29yZUBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Z2FvLnlhbmcy QHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gSS1EIEFjdGlvbjpk cmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8 dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+ DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5HYW8sPGJyPg0KPGJyPg0KSSBhbSB0 YWxraW5nIGFib3V0ICZxdW90O1VBQyBCZWhhdmlvciZxdW90Oy48YnI+DQpXaGF0IHlvdSBzYXkg aXMgJnF1b3Q7VUFTIEJlaGF2aW9yJnF1b3Q7Ljxicj4NCjxicj4NClRoZSBiYXNpYyBwcmluY2lw bGUgaW4gbXkgb3BpbmlvbiBpcywgPGJyPg0KPGJyPg0KSWYgYW4gVVBEQVRFIGhhcyBiZWVuIG5v dCB1c2VkLCB0aGVuIHRoZSBvcmlnaW5hbCByb2xsYmFjazxicj4NCnByb2Nlc3MgbWF5IHdvcmtz IHdlbGwuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpTaGluamk8YnI+DQo8YnI+DQpnYW8ueWFu ZzJAenRlLmNvbS5jbjxicj4NClRodSwgMTMgTWF5IDIwMTAgMDk6Mzc6MTkgKzA4MDA8YnI+DQom Z3Q7SGkgU2hpbmppLDxicj4NCiZndDs8YnI+DQomZ3Q7QXMgSSBzYWlkIGluIG15IGZpcnN0IG1h aWwgaW4gdGhpcyB0aHJlYWQsIHRoZSBVQVMgc2hvdWxkIG5vdCBzZW5kDQo0eHggYnkgPGJyPg0K Jmd0O3RoZSBuZXcgcnVsZSBpbiB0aGlzIGRyYWZ0Ljxicj4NCiZndDs8YnI+DQomZ3Q7VGhlIGJh c2ljIHByaW5jaXBsZSBpbiB0aGlzIGRyYWZ0IGlzLCA8YnI+DQomZ3Q7PGJyPg0KJmd0OzEuIElm IHRoZSBtb2RpZmljYXRpb24gdHJpZ2dlcmVkIGJ5IHRoZSBSZS1JTlZJVEUgaXMgKmluIHVzZSos IHRoZW4NCnRoZSA8YnI+DQomZ3Q7VUFTIHNob3VsZCBub3Qgc2VuZCA0eHguPGJyPg0KJmd0Ozxi cj4NCiZndDsyLiBJZiB0aGUgVUFTIHdhbnQgdG8gcm9sbGJhY2sgbW9kaWZpY2F0aW9uIHdoaWNo IGhhcyBiZWVuICppbiB1c2UqLA0KYW4gPGJyPg0KJmd0O1VQREFURSBiZWZvcmUgZmluYWwgMnh4 IG9mIFJlLUlOVklURSBpcyBzdWdnZXN0ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDtUaGFua3MsPGJy Pg0KJmd0Ozxicj4NCiZndDtHYW88YnI+DQomZ3Q7PGJyPg0KJmd0Oz09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJy Pg0KJmd0OyBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQomZ3Q7IFRlbDIgJm5ic3A7IDoo Kzg2KS0wMjUtNTI4NzcyMTE8YnI+DQomZ3Q7IGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNu PGJyPg0KJmd0Oz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0Ozxi cj4NCiZndDtPS1VNVVJBIFNoaW5qaSAmbHQ7c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwJmd0 OyA8YnI+DQomZ3Q7MjAxMC0wNS0xMyAwOTozMDxicj4NCiZndDs8YnI+DQomZ3Q7SGkgUGF1bCBh bmQgR2FvLDxicj4NCiZndDs8YnI+DQomZ3Q7UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNj by5jb20mZ3Q7PGJyPg0KJmd0O1dlZCwgMTIgTWF5IDIwMTAgMTY6NDk6MzEgLTA0MDA8YnI+DQom Z3Q7Jmd0O09LVU1VUkEgU2hpbmppIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyBIaSw8YnI+DQom Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEkgaGF2ZSBvbmUgcXVlc3Rpb24gYW5kIG9u ZSBjb21tZW50IGFib3V0IFVBQyBiZWhhdmlvci48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7IHF1ZXN0aW9uOjxicj4NCiZndDsmZ3Q7Jmd0OyBBdCBmaXJzdCwgb2Egc3RhdHVz IGlzIG9ubHkgYXVkaW8sIGFuZCBkdXJpbmcgYSBuZXh0IHJlSU5WSVRFPGJyPg0KJmd0OyZndDsm Z3Q7IHRyYW5zYWN0aW9uIG9hIHN0YXR1cyBpcyBjaGFuZ2VkIHRvIGF1ZGlvIGFuZCB2aWRlby4g QW5kIHRoZW48YnI+DQomZ3Q7Jmd0OyZndDsgVUFTIHNlbmRzIGEgNHh4IHJlc3BvbnNlIHRvIHRo ZSByZUlOVklURS48YnI+DQomZ3Q7Jmd0OyZndDsgSW4gdGhpcyBjYXNlIHdoaWNoIGlzIGEgbmV3 IG9mZmVyIFVBQyBzaG91bGQgc2VuZCwgb25seSBhdWRpbzxicj4NCiZndDsmZ3Q7Jmd0OyBvciBi b3RoIG9mIGF1ZGlvIGFuZCB2aWRlbyB3aXRoIHplcm8gcG9ydD88YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7V2VsbCwgdGhlIG5ldyBvL2EgaXMgdG8gcmVzdGF0ZSB0aGUgc3RhdHVzIHF1by48 YnI+DQomZ3Q7Jmd0O1NpbmNlIHRoZSBuZXcgby9hIG5ldmVyIHN1Y2NlZWRlZCwgdGhlIHN0YXR1 cyBxdW8gaW5jbHVkZXMgb25seQ0Kb25lIDxicj4NCiZndDsmZ3Q7bS1saW5lLiBTbyBJIHRoaW5r IGl0IHdvdWxkIGJlIGFjY2VwdGFibGUgdG8gc2VuZCBhbiBvZmZlciB3aXRoDQp0aGF0Ljxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtPVE9ILCBpdHMgcG9zc2libGUgdGhhdCB0aGUgb3RoZXIg cGFydHkgaXMgY29uZnVzZWQgYW5kIHRoaW5rcw0KdGhlcmUgYXJlIDxicj4NCiZndDsmZ3Q7dHdv IG0tbGluZXMgaW4gZWZmZWN0LiBJdCBtaWdodCBiZSBmdXJ0aGVyIGNvbmZ1c2VkIHRvIHJlY2Vp dmUNCmFub3RoZXIgPGJyPg0KJmd0OyZndDtvZmZlciB3aXRoIG9ubHkgb25lIG0tbGluZS4gU28g aXQgbWlnaHQgYmUgcHJ1ZGVudCB0byBzZW5kIHRoZQ0KbmV3IG9mZmVyIDxicj4NCiZndDsmZ3Q7 YXMgeW91IHN1Z2dlc3QuIEl0cyBsZWdhbCB0byBkbyBzbywgYW5kIGl0IG91Z2h0IG5vdCBodXJ0 IGFueXRoaW5nLjxicj4NCiZndDsmZ3Q7KEJ1dCBpdCBtaWdodCBjYXVzZSB0cm91YmxlIGlmIHRo ZSBvdGhlciBVQSBzaW1wbHkgY2FuJ3QgaGFuZGxlDQp0aGUgPGJyPg0KJmd0OyZndDthZGRpdGlv bmFsIG0tbGluZS4gSWYgc28gaXQgaXMgcXVpdGUgYnJva2VuLik8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBjb21tZW50Ojxicj4NCiZndDsmZ3Q7Jmd0OyBJZiBhbHJlYWR5LWV4ZWN1 dGVkIGNoYW5nZXMgaXMgbWFkZSBieSBvbmx5IFBSQUNLIHRyYW5zYWN0aW9uLDxicj4NCiZndDsm Z3Q7Jmd0OyBJTU8gVUFDIG5lZWQgbm90IGdlbmVyYXRlIGEgbmV3IG9mZmVyIHRvIHN5bmNocm9u aXplIGJvdGgNClVBcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7SSBkb24ndCB1bmRlcnN0 YW5kIHdoYXQgcG9pbnQgeW91IGFyZSBtYWtpbmcsIG9yIHdoeS48YnI+DQomZ3Q7PGJyPg0KJmd0 O0FzIFJlY29uZmlybWF0aW9uIG9mIGZ1bmRhbWVudGFsIHByZW1pc2U6PGJyPg0KJmd0Ozxicj4N CiZndDtJZiByZUlOVklURSBpcyByZWplY3RlZCwgdGhlbiBib3RoIFVBcyBtdXN0IGNhbmNlbCBh bGwgb2Y8YnI+DQomZ3Q7Y2hhbmdlcyB3aXRoaW4gdGhlIHJlSU5WSVRFIHRyYW5zYWN0aW9uLjxi cj4NCiZndDtPcmlnaW5hbGx5IHRoaXMgcm9sbGJhY2sgaXMgYW4gYXV0b21hdGljIHByb2Nlc3Ms IHNvIHNlbmRpbmc8YnI+DQomZ3Q7bmV3IG9mZmVyIGlzIG5vdCBuZWNlc3NhcnkuPGJyPg0KJmd0 Ozxicj4NCiZndDtXaHkgc2hvdWxkIFVBQyBzZW5kIG5ldyBvZmZlcj88YnI+DQomZ3Q7VGhlIHJl YXNvbiBpcyB0aGF0Ojxicj4NCiZndDsgJm5ic3A7ICZxdW90O1RoZXJlIGFyZSBhbHNvIGNlcnRh aW48YnI+DQomZ3Q7ICZuYnNwOyByYWNlIGNvbmRpdGlvbiBzaXR1YXRpb25zIHRoYXQgZ2V0IGJv dGggdXNlciBhZ2VudHMgb3V0IG9mPGJyPg0KJmd0OyAmbmJzcDsgc3luY2hyb25pemF0aW9uJnF1 b3Q7IGFzIHNob3duIGluIEZpZ3VyZSA1Ljxicj4NCiZndDs8YnI+DQomZ3Q7SW4gRmlndXJlIDUs IGlmIFVQREFURSB0cmFuc2FjdGlvbiBkb2VzIG5vdCBleGlzdCwgdGhlIGNvbW1vbjxicj4NCiZn dDt2aWV3IG9mIG9hIHN0YXRlIGlzIGFscmVhZHkgc3luY2hyb25pemVkKGkuZS4sIHNlbmRyZWN2 IGF1ZGlvPGJyPg0KJmd0O2FuZCBpbmFjdGl2ZSB2aWRlbykuPGJyPg0KJmd0Ozxicj4NCiZndDtJ IHRoaW5rIGluIHRoaXMgY2FzZSBVQUMgbmVlZCBub3QgZ2VuZXJhdGUgYSBuZXcgb2ZmZXIuPGJy Pg0KJmd0Ozxicj4NCiZndDtSZWdhcmRzLDxicj4NCiZndDtTaGluamk8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1RoYW5rcyw8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGF1bDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsmZ3Q7IFNoaW5qaTxicj4NCiZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPGJyPg0KJmd0OyZn dDsmZ3Q7IFNhdCwgJm5ic3A7OCBNYXkgMjAxMCAwMDozMDowMiAtMDcwMCAoUERUKTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQpkaXJlY3Rvcmllcy48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQ cm90b2NvbA0KQ29yZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZQ0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFJlLUlOVklURSBhbmQgVGFyZ2V0LXJlZnJlc2gg UmVxdWVzdA0KSGFuZGxpbmcgaW4gdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQ KTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7QXV0aG9yKHMpDQombmJzcDsgJm5ic3A7ICZuYnNwOyA6IEcuIENhbWFy aWxsbywgZXQgYWwuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7OiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQudHh0PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQ YWdlcw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDI0PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtEYXRlICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxMC0w NS0wODxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEluIHRoaXMg ZG9jdW1lbnQsIHdlIGNsYXJpZnkgdGhlIGhhbmRsaW5nIG9mIHJlLUlOVklURXMNCmluIFNJUC4g Jm5ic3A7V2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNsYXJpZnkgaW4gd2hpY2ggc2l0dWF0aW9u cyBhIFVBUyAoVXNlciBBZ2VudCBTZXJ2ZXIpDQpzaG91bGQgZ2VuZXJhdGU8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IGEgc3VjY2VzcyByZXNwb25zZSBhbmQgaW4gd2hpY2ggc2l0dWF0aW9ucyBhIFVB UyBzaG91bGQNCmdlbmVyYXRlIGFuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBlcnJvciByZXNwb25z ZSB0byBhIHJlLUlOVklURS4gJm5ic3A7QWRkaXRpb25hbGx5LCB3ZQ0KY2xhcmlmeSBpc3N1ZXM8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJlbGF0ZWQgdG8gdGFyZ2V0LXJlZnJlc2ggcmVxdWVzdHMu PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQSBVUkwgZm9yIHRo aXMgSW50ZXJuZXQtRHJhZnQgaXM6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQudHh0 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3 aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwNCnJlYWRlcjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkg dmVyc2lvbg0Kb2YgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdC48YnI+ DQomZ3Q7PGJyPg0KJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0O3NpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0O3NpcGNvcmVAaWV0 Zi5vcmc8YnI+DQomZ3Q7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 000C3D6548257722_=-- From shinji.okumura@softfront.jp Wed May 12 22:13:30 2010 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 657073A69BB for ; Wed, 12 May 2010 22:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.49 X-Spam-Level: ** X-Spam-Status: No, score=2.49 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222] 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 Wmxe+UpmfrHJ for ; Wed, 12 May 2010 22:13:28 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 20FF83A6A36 for ; Wed, 12 May 2010 22:13:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id BEB4946B347 for ; Thu, 13 May 2010 14:13:04 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSCidBVx8fnx for ; Thu, 13 May 2010 14:13:02 +0900 (JST) Received: from softfront.jp (p6068-ipad403sapodori.hokkaido.ocn.ne.jp [60.43.99.68]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id B573646AFD8 for ; Thu, 13 May 2010 14:13:01 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Thu, 13 May 2010 14:12:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <20100508073002.1CBBE3A68A8@core3.amsl.com> References: <20100508073002.1CBBE3A68A8@core3.amsl.com> Message-Id: <8CCAF25AF47C5Dshinji.okumura@softfront.jp> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 05:13:30 -0000 Hi, In this text, 3.5. Glare Situations These rules imply that if the UAS of a re-INVITE transaction receives and UPDATE request with an offer after having sent a non-2xx final response to the re-INVITE but before having received the corresponding ACK request, the UA SHOULD return a 491 (Request Pending) response to the UPDATE request. that is shown in a Figure below. A B | | |re-INV (offer1) | |------------------------------>| | 18x(answer1)| |<------------------------------| | non-2xx| | /---------------|<-+ |UPD / | | reject UPDATE |=============/================>|* | | / 491(UPD)| | |<==========/===================| | | / | | |<--------/ | | |ACK | | |------------------------------>|<-+ | | Regarding 491 and 500 response, there are some descriptions in RFC3261 and RFC3311. But in these text, an interworking of INVITE and UPDATE is not clear. IMO when the directions of the both request are corresponding, the response code seems to be 500. And if the directions are not corresponding, the response code seems to be 491. Therefore in this case, I think a UAS should return a 500 response to an UPDATE request. Regards, Shinji Internet-Drafts@ietf.org Sat, 8 May 2010 00:30:02 -0700 (PDT) >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > > Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-sipcore-reinvite-04.txt > Pages : 24 > Date : 2010-05-08 > >In this document, we clarify the handling of re-INVITEs in SIP. We >clarify in which situations a UAS (User Agent Server) should generate >a success response and in which situations a UAS should generate an >error response to a re-INVITE. Additionally, we clarify issues >related to target-refresh requests. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. From gao.yang2@zte.com.cn Wed May 12 23:07:13 2010 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 AB7F93A6A36; Wed, 12 May 2010 23:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.022 X-Spam-Level: X-Spam-Status: No, score=-97.022 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 L4C0NZpXknlM; Wed, 12 May 2010 23:07:12 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 95A5B3A6A50; Wed, 12 May 2010 23:07:09 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580712001811080; Thu, 13 May 2010 14:02:22 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3289705602; Thu, 13 May 2010 14:06:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4D638YE068632; Thu, 13 May 2010 14:03:08 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <8CCAF25AF47C5Dshinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 13 May 2010 14:00:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-13 14:03:01, Serialize complete at 2010-05-13 14:03:01 Content-Type: multipart/alternative; boundary="=_alternative 002133F948257722_=" X-MAIL: mse2.zte.com.cn o4D638YE068632 Cc: sipcore@ietf.org, sipcore-bounces@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 06:07:13 -0000 This is a multipart message in MIME format. --=_alternative 002133F948257722_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2hpbmppLA0KDQpUaGVyZSdzIHByZWNvbmRpdGlvbiBmb3IgdGhlIHRleHQgeW91IG1lbnRp b25lZDogDQoNCldoZW4gY2hlY2tpbmcgZm9yIGdsYXJlIHNpdHVhdGlvbnMsIFVBcyBNVVNUIHRy ZWF0IHRoZSBleGNoYW5nZSBvZiBhDQogICBub24tMnh4IGZpbmFsIHJlc3BvbnNlIHRvIGEgcmUt SU5WSVRFIGFuZCBpdHMgY29ycmVzcG9uZGluZyBBQ0sNCiAgIHJlcXVlc3QgYXMgYW4gb2ZmZXIv YW5zd2VyIGV4Y2hhbmdlLiAgQ29uc2VxdWVudGx5LCB0aGUgcnVsZXMNCiAgIHJlZ2FyZGluZyBn bGFyZSBzaXR1YXRpb25zIGFwcGxpY2FibGUgdG8gb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlcyBhcmUN CiAgIGFsc28gYXBwbGljYWJsZSB0byB0aG9zZSBleGNoYW5nZXMuICBUaGVzZSBydWxlcyBpbXBs eSB0aGF0IGlmIHRoZQ0KICAgVUFTIG9mIGEgcmUtSU5WSVRFIHRyYW5zYWN0aW9uIHJlY2VpdmVz IGFuZCBVUERBVEUgcmVxdWVzdCB3aXRoIGFuDQogICBvZmZlciBhZnRlciBoYXZpbmcgc2VudCBh IG5vbi0yeHggZmluYWwgcmVzcG9uc2UgdG8gdGhlIHJlLUlOVklURSBidXQNCiAgIGJlZm9yZSBo YXZpbmcgcmVjZWl2ZWQgdGhlIGNvcnJlc3BvbmRpbmcgQUNLIHJlcXVlc3QsIHRoZSBVQSBTSE9V TEQNCiAgIHJldHVybiBhIDQ5MSAoUmVxdWVzdCBQZW5kaW5nKSByZXNwb25zZSB0byB0aGUgVVBE QVRFIHJlcXVlc3QuIA0KDQpXaXRoIHRoZSBwcmVjb25kaXRpb24gZGVmaW5lZCBoZXJlLCB0aGUg VUFTKG9mIFJlLUlOVklURSkgTVVTVCB0aGluayBpdCANCmhhcyBzZW5kZWQgYSBPZmZlciBhZnRl ciBpdCBzZW5kIHRoZSBub24tMnh4Lg0KDQpCZWZvcmUgdGhlIFVBUyBnZXQgdGhlIEFDSywgaXQg Z2V0IGEgbmV3IE9mZmVyIGluIFVQREFURSwgaXQgU0hPVUxEIHNlbmQgDQo0eHguDQoNClRoZXJl J3Mgbm9ybWF0aXZlIGRlZmluaXRpb24gaGVyZS4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAg OiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcy QHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpP S1VNVVJBIFNoaW5qaSA8c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwPiANCreivP7IyzogIHNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNS0xMyAxMzoxMg0KDQrK1bz+yMsNCnNpcGNv cmVAaWV0Zi5vcmcNCrOty80NCg0K1vfM4g0KUmU6IFtzaXBjb3JlXSBJLUQgQWN0aW9uOmRyYWZ0 LWlldGYtc2lwY29yZS1yZWludml0ZS0wNC50eHQNCg0KDQoNCg0KDQoNCkhpLA0KDQpJbiB0aGlz IHRleHQsDQoNCjMuNS4gIEdsYXJlIFNpdHVhdGlvbnMNCiAgIFRoZXNlIHJ1bGVzIGltcGx5IHRo YXQgaWYgdGhlDQogICBVQVMgb2YgYSByZS1JTlZJVEUgdHJhbnNhY3Rpb24gcmVjZWl2ZXMgYW5k IFVQREFURSByZXF1ZXN0IHdpdGggYW4NCiAgIG9mZmVyIGFmdGVyIGhhdmluZyBzZW50IGEgbm9u LTJ4eCBmaW5hbCByZXNwb25zZSB0byB0aGUgcmUtSU5WSVRFIGJ1dA0KICAgYmVmb3JlIGhhdmlu ZyByZWNlaXZlZCB0aGUgY29ycmVzcG9uZGluZyBBQ0sgcmVxdWVzdCwgdGhlIFVBIFNIT1VMRA0K ICAgcmV0dXJuIGEgNDkxIChSZXF1ZXN0IFBlbmRpbmcpIHJlc3BvbnNlIHRvIHRoZSBVUERBVEUg cmVxdWVzdC4NCg0KdGhhdCBpcyBzaG93biBpbiBhIEZpZ3VyZSBiZWxvdy4NCg0KICAgIEEgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQg0KICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgIHxyZS1JTlYgKG9mZmVyMSkgICAgICAgICAgICAgICAgfA0KICAgIHwt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgIHwgICAgICAgICAgICAgICAgICAg MTh4KGFuc3dlcjEpfA0KICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KICAg IHwgICAgICAgICAgICAgICAgICAgICAgICBub24tMnh4fA0KICAgIHwgICAgICAgICAgICAgICAv LS0tLS0tLS0tLS0tLS0tfDwtKw0KICAgIHxVUEQgICAgICAgICAgIC8gICAgICAgICAgICAgICAg fCAgfCByZWplY3QgVVBEQVRFDQogICAgfD09PT09PT09PT09PT0vPT09PT09PT09PT09PT09PT58 KiB8DQogICAgfCAgICAgICAgICAgIC8gICAgICAgICAgNDkxKFVQRCl8ICB8DQogICAgfDw9PT09 PT09PT09Lz09PT09PT09PT09PT09PT09PT18ICB8DQogICAgfCAgICAgICAgICAvICAgICAgICAg ICAgICAgICAgICB8ICB8DQogICAgfDwtLS0tLS0tLS8gICAgICAgICAgICAgICAgICAgICB8ICB8 DQogICAgfEFDSyAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICB8DQogICAgfC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58PC0rDQogICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQoNClJlZ2FyZGluZyA0OTEgYW5kIDUwMCByZXNwb25zZSwgdGhlcmUgYXJlIHNv bWUgZGVzY3JpcHRpb25zIGluIFJGQzMyNjENCmFuZCBSRkMzMzExLiBCdXQgaW4gdGhlc2UgdGV4 dCwgYW4gaW50ZXJ3b3JraW5nIG9mIElOVklURSBhbmQgVVBEQVRFDQppcyBub3QgY2xlYXIuDQoN CklNTyB3aGVuIHRoZSBkaXJlY3Rpb25zIG9mIHRoZSBib3RoIHJlcXVlc3QgYXJlIGNvcnJlc3Bv bmRpbmcsDQp0aGUgcmVzcG9uc2UgY29kZSBzZWVtcyB0byBiZSA1MDAuIEFuZCBpZiB0aGUgZGly ZWN0aW9ucyBhcmUgbm90DQpjb3JyZXNwb25kaW5nLCB0aGUgcmVzcG9uc2UgY29kZSBzZWVtcyB0 byBiZSA0OTEuDQoNClRoZXJlZm9yZSBpbiB0aGlzIGNhc2UsIEkgdGhpbmsgYSBVQVMgc2hvdWxk IHJldHVybiBhIDUwMCByZXNwb25zZSB0bw0KYW4gVVBEQVRFIHJlcXVlc3QuDQoNClJlZ2FyZHMs DQpTaGluamkNCg0KSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnDQpTYXQsICA4IE1heSAyMDEwIDAw OjMwOjAyIC0wNzAwIChQRFQpDQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KZGlyZWN0b3JpZXMuDQo+VGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUg V29ya2luZyANCkdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPg0KPiAgICAgICAgICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBSZS1JTlZJVEUgYW5kIFRhcmdldC1yZWZyZXNoIFJlcXVlc3QgDQpIYW5k bGluZyBpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApDQo+ICAgICAgICAg ICAgICAgIEF1dGhvcihzKSAgICAgICA6IEcuIENhbWFyaWxsbywgZXQgYWwuDQo+ICAgICAgICAg ICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNC50 eHQNCj4gICAgICAgICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMjQNCj4gICAgICAgICAgICAg ICAgRGF0ZSAgICAgICAgICAgIDogMjAxMC0wNS0wOA0KPg0KPkluIHRoaXMgZG9jdW1lbnQsIHdl IGNsYXJpZnkgdGhlIGhhbmRsaW5nIG9mIHJlLUlOVklURXMgaW4gU0lQLiAgV2UNCj5jbGFyaWZ5 IGluIHdoaWNoIHNpdHVhdGlvbnMgYSBVQVMgKFVzZXIgQWdlbnQgU2VydmVyKSBzaG91bGQgZ2Vu ZXJhdGUNCj5hIHN1Y2Nlc3MgcmVzcG9uc2UgYW5kIGluIHdoaWNoIHNpdHVhdGlvbnMgYSBVQVMg c2hvdWxkIGdlbmVyYXRlIGFuDQo+ZXJyb3IgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUuICBBZGRp dGlvbmFsbHksIHdlIGNsYXJpZnkgaXNzdWVzDQo+cmVsYXRlZCB0byB0YXJnZXQtcmVmcmVzaCBy ZXF1ZXN0cy4NCj4NCj5BIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUt MDQudHh0DQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+QmVs b3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJl YWRlcg0KPmltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJ IHZlcnNpb24gb2YgdGhlDQo+SW50ZXJuZXQtRHJhZnQuDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K DQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFs LiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVj eSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNt aXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVz c2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3Rp ZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1l c3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1T cGFtIHN5c3RlbS4NCg== --=_alternative 002133F948257722_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNoaW5qaSw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZXJlJ3MgcHJlY29uZGl0 aW9uIGZvciB0aGUgdGV4dCB5b3UNCm1lbnRpb25lZDogPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XaGVuIGNoZWNraW5nIGZvciBnbGFyZSBzaXR1YXRp b25zLA0KVUFzIE1VU1QgdHJlYXQgdGhlIGV4Y2hhbmdlIG9mIGE8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtub24tMnh4IGZpbmFsIHJlc3Bv bnNlDQp0byBhIHJlLUlOVklURSBhbmQgaXRzIGNvcnJlc3BvbmRpbmcgQUNLPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7cmVxdWVzdCA8Yj5h cyBhbiBvZmZlci9hbnN3ZXINCmV4Y2hhbmdlPC9iPi4gJm5ic3A7Q29uc2VxdWVudGx5LCA8Yj50 aGUgcnVsZXM8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 Yj4mbmJzcDsgJm5ic3A7cmVnYXJkaW5nIGdsYXJlIHNpdHVhdGlvbnMNCmFwcGxpY2FibGUgdG8g b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlcyBhcmU8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48Yj4mbmJzcDsgJm5ic3A7YWxzbyBhcHBsaWNhYmxlIHRvIHRob3Nl DQpleGNoYW5nZXM8L2I+LiAmbmJzcDtUaGVzZSBydWxlcyBpbXBseSB0aGF0IGlmIHRoZTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1VBUyBv ZiBhIHJlLUlOVklURSB0cmFuc2FjdGlvbg0KcmVjZWl2ZXMgYW5kIFVQREFURSByZXF1ZXN0IHdp dGggYW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDtvZmZlciBhZnRlciBoYXZpbmcgc2VudA0KYSBub24tMnh4IGZpbmFsIHJlc3BvbnNlIHRv IHRoZSByZS1JTlZJVEUgYnV0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7YmVmb3JlIGhhdmluZyByZWNlaXZlZA0KdGhlIGNvcnJlc3BvbmRp bmcgQUNLIHJlcXVlc3QsIHRoZSBVQSBTSE9VTEQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtyZXR1cm4gYSA0OTEgKFJlcXVlc3QgUGVuZGlu ZykNCnJlc3BvbnNlIHRvIHRoZSBVUERBVEUgcmVxdWVzdC4gJm5ic3A7PC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XaXRoIHRoZSBwcmVjb25kaXRpb24g ZGVmaW5lZCBoZXJlLA0KdGhlIFVBUyhvZiBSZS1JTlZJVEUpIE1VU1QgdGhpbmsgaXQgaGFzIHNl bmRlZCBhIE9mZmVyIGFmdGVyIGl0IHNlbmQgdGhlDQpub24tMnh4LjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVmb3JlIHRoZSBVQVMgZ2V0IHRoZSBB Q0ssIGl0IGdldCBhDQpuZXcgT2ZmZXIgaW4gVVBEQVRFLCBpdCBTSE9VTEQgc2VuZCA0eHguPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVyZSdzIG5v cm1hdGl2ZSBkZWZpbml0aW9uIGhlcmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFpp cCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJy Pg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlh bmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwv Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5PS1VN VVJBIFNoaW5qaSAmbHQ7c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwJmd0OzwvYj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAxMC0wNS0xMyAxMzoxMjwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5zaXBjb3JlQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIEkt RCBBY3Rpb246ZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0LnR4dDwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGksPGJyPg0KPGJy Pg0KSW4gdGhpcyB0ZXh0LDxicj4NCjxicj4NCjMuNS4gJm5ic3A7R2xhcmUgU2l0dWF0aW9uczxi cj4NCiAmbmJzcDsgVGhlc2UgcnVsZXMgaW1wbHkgdGhhdCBpZiB0aGU8YnI+DQogJm5ic3A7IFVB UyBvZiBhIHJlLUlOVklURSB0cmFuc2FjdGlvbiByZWNlaXZlcyBhbmQgVVBEQVRFIHJlcXVlc3Qg d2l0aA0KYW48YnI+DQogJm5ic3A7IG9mZmVyIGFmdGVyIGhhdmluZyBzZW50IGEgbm9uLTJ4eCBm aW5hbCByZXNwb25zZSB0byB0aGUgcmUtSU5WSVRFDQpidXQ8YnI+DQogJm5ic3A7IGJlZm9yZSBo YXZpbmcgcmVjZWl2ZWQgdGhlIGNvcnJlc3BvbmRpbmcgQUNLIHJlcXVlc3QsIHRoZSBVQSBTSE9V TEQ8YnI+DQogJm5ic3A7IHJldHVybiBhIDQ5MSAoUmVxdWVzdCBQZW5kaW5nKSByZXNwb25zZSB0 byB0aGUgVVBEQVRFIHJlcXVlc3QuPGJyPg0KPGJyPg0KdGhhdCBpcyBzaG93biBpbiBhIEZpZ3Vy ZSBiZWxvdy48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwO0EgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEI8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQogJm5ic3A7 ICZuYnNwO3xyZS1JTlYgKG9mZmVyMSkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDt8PGJyPg0KICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDE4eChh bnN3ZXIxKXw8YnI+DQogJm5ic3A7ICZuYnNwO3wmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tfDxicj4NCiAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtu b24tMnh4fDxicj4NCiAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLy0tLS0tLS0tLS0tLS0tLXwmbHQ7LSs8YnI+DQogJm5ic3A7 ICZuYnNwO3xVUEQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDt8 IHJlamVjdCBVUERBVEU8YnI+DQogJm5ic3A7ICZuYnNwO3w9PT09PT09PT09PT09Lz09PT09PT09 PT09PT09PT0mZ3Q7fCogfDxicj4NCiAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDs0OTEoVVBEKXwgJm5ic3A7fDxicj4NCiAmbmJzcDsgJm5ic3A7fCZsdDs9PT09PT09PT09Lz09 PT09PT09PT09PT09PT09PT18ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7fDxicj4NCiAm bmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3w8YnI+DQog Jm5ic3A7ICZuYnNwO3xBQ0sgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3wtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0mZ3Q7fCZsdDstKzxicj4NCiAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCjxicj4NClJlZ2FyZGluZyA0OTEg YW5kIDUwMCByZXNwb25zZSwgdGhlcmUgYXJlIHNvbWUgZGVzY3JpcHRpb25zIGluIFJGQzMyNjE8 YnI+DQphbmQgUkZDMzMxMS4gQnV0IGluIHRoZXNlIHRleHQsIGFuIGludGVyd29ya2luZyBvZiBJ TlZJVEUgYW5kIFVQREFURTxicj4NCmlzIG5vdCBjbGVhci48YnI+DQo8YnI+DQpJTU8gd2hlbiB0 aGUgZGlyZWN0aW9ucyBvZiB0aGUgYm90aCByZXF1ZXN0IGFyZSBjb3JyZXNwb25kaW5nLDxicj4N CnRoZSByZXNwb25zZSBjb2RlIHNlZW1zIHRvIGJlIDUwMC4gQW5kIGlmIHRoZSBkaXJlY3Rpb25z IGFyZSBub3Q8YnI+DQpjb3JyZXNwb25kaW5nLCB0aGUgcmVzcG9uc2UgY29kZSBzZWVtcyB0byBi ZSA0OTEuPGJyPg0KPGJyPg0KVGhlcmVmb3JlIGluIHRoaXMgY2FzZSwgSSB0aGluayBhIFVBUyBz aG91bGQgcmV0dXJuIGEgNTAwIHJlc3BvbnNlIHRvPGJyPg0KYW4gVVBEQVRFIHJlcXVlc3QuPGJy Pg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpTaGluamk8YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHNA aWV0Zi5vcmc8YnI+DQpTYXQsICZuYnNwOzggTWF5IDIwMTAgMDA6MzA6MDIgLTA3MDAgKFBEVCk8 YnI+DQomZ3Q7QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzDQpkaXJlY3Rvcmllcy48YnI+DQomZ3Q7VGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUgV29ya2lu Zw0KR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClRpdGxl ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBSZS1JTlZJVEUgYW5kIFRhcmdl dC1yZWZyZXNoDQpSZXF1ZXN0IEhhbmRsaW5nIGluIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wgKFNJUCk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCkF1dGhvcihzKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IEcu IENhbWFyaWxsbywgZXQgYWwuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNC50eHQ8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBh Z2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyNDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KRGF0 ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxMC0wNS0wODxi cj4NCiZndDs8YnI+DQomZ3Q7SW4gdGhpcyBkb2N1bWVudCwgd2UgY2xhcmlmeSB0aGUgaGFuZGxp bmcgb2YgcmUtSU5WSVRFcyBpbiBTSVAuICZuYnNwO1dlPGJyPg0KJmd0O2NsYXJpZnkgaW4gd2hp Y2ggc2l0dWF0aW9ucyBhIFVBUyAoVXNlciBBZ2VudCBTZXJ2ZXIpIHNob3VsZCBnZW5lcmF0ZTxi cj4NCiZndDthIHN1Y2Nlc3MgcmVzcG9uc2UgYW5kIGluIHdoaWNoIHNpdHVhdGlvbnMgYSBVQVMg c2hvdWxkIGdlbmVyYXRlIGFuPGJyPg0KJmd0O2Vycm9yIHJlc3BvbnNlIHRvIGEgcmUtSU5WSVRF LiAmbmJzcDtBZGRpdGlvbmFsbHksIHdlIGNsYXJpZnkgaXNzdWVzPGJyPg0KJmd0O3JlbGF0ZWQg dG8gdGFyZ2V0LXJlZnJlc2ggcmVxdWVzdHMuPGJyPg0KJmd0Ozxicj4NCiZndDtBIFVSTCBmb3Ig dGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8YnI+DQomZ3Q7aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0LnR4dDxicj4NCiZndDs8 YnI+DQomZ3Q7SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Ojxicj4NCiZndDtmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxicj4N CiZndDs8YnI+DQomZ3Q7QmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1F IGNvbXBsaWFudCBtYWlsIHJlYWRlcjxicj4NCiZndDtpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0 aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZTxicj4NCiZndDtJbnRlcm5l dC1EcmFmdC48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjxicj4N CjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJz cDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Nv bnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZu YnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXph dGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNw O2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNw O2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5i c3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNj bG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5i c3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNw O2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5 Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7 YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2Vp dmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNw O21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNw O1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJl Pg== --=_alternative 002133F948257722_=-- From shinji.okumura@softfront.jp Thu May 13 02:35:43 2010 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 B6E293A68AE for ; Thu, 13 May 2010 02:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.745 X-Spam-Level: ** X-Spam-Status: No, score=2.745 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_32=0.6, RELAY_IS_221=2.222] 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 zUHxMw668-Id for ; Thu, 13 May 2010 02:35:42 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 4B4B23A6A44 for ; Thu, 13 May 2010 02:35:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 28CE046B363; Thu, 13 May 2010 18:35:06 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGT82rvfuwR1; Thu, 13 May 2010 18:35:02 +0900 (JST) Received: from softfront.jp (p6068-ipad403sapodori.hokkaido.ocn.ne.jp [60.43.99.68]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id AECC246B33F; Thu, 13 May 2010 18:35:01 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Thu, 13 May 2010 18:35:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 09:35:43 -0000 Gao, IIUC you means that UAS treats a 4xx to INVITE as an offer and an ACK as an answer. Well, A B | | |re-INV (offer1) | |------------------------------>| | 18x(answer1)| |<------------------------------| | non-2xx| |<------------------------------| | | | /---------->|* |ACK / | |-----------------/------------>| | / | |re-INV (offer2)/ | |--------------/ | | | In an above Figure, what is a response code to the 2nd re-INVITE? Or if UA B received the 2nd re-INIVTE before non-2xx, what is a response code to it? gao.yang2@zte.com.cn Thu, 13 May 2010 14:00:16 +0800 >Hi Shinji, > >There's precondition for the text you mentioned: > >When checking for glare situations, UAs MUST treat the exchange of a > non-2xx final response to a re-INVITE and its corresponding ACK > request as an offer/answer exchange. Consequently, the rules > regarding glare situations applicable to offer/answer exchanges are > also applicable to those exchanges. These rules imply that if the > UAS of a re-INVITE transaction receives and UPDATE request with an > offer after having sent a non-2xx final response to the re-INVITE but > before having received the corresponding ACK request, the UA SHOULD > return a 491 (Request Pending) response to the UPDATE request. > >With the precondition defined here, the UAS(of Re-INVITE) MUST think it >has sended a Offer after it send the non-2xx. > >Before the UAS get the ACK, it get a new Offer in UPDATE, it SHOULD send >4xx. > >There's normative definition here. Is that "normative definition" defined in this draft? Regards, Shinji >Thanks, > >Gao > >=================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn >=================================== > >OKUMURA Shinji > >Hi, > >In this text, > >3.5. Glare Situations > These rules imply that if the > UAS of a re-INVITE transaction receives and UPDATE request with an > offer after having sent a non-2xx final response to the re-INVITE but > before having received the corresponding ACK request, the UA SHOULD > return a 491 (Request Pending) response to the UPDATE request. > >that is shown in a Figure below. > > A B > | | > |re-INV (offer1) | > |------------------------------>| > | 18x(answer1)| > |<------------------------------| > | non-2xx| > | /---------------|<-+ > |UPD / | | reject UPDATE > |=============/================>|* | > | / 491(UPD)| | > |<==========/===================| | > | / | | > |<--------/ | | > |ACK | | > |------------------------------>|<-+ > | | > >Regarding 491 and 500 response, there are some descriptions in RFC3261 >and RFC3311. But in these text, an interworking of INVITE and UPDATE >is not clear. > >IMO when the directions of the both request are corresponding, >the response code seems to be 500. And if the directions are not >corresponding, the response code seems to be 491. > >Therefore in this case, I think a UAS should return a 500 response to >an UPDATE request. > >Regards, >Shinji > >Internet-Drafts@ietf.org >Sat, 8 May 2010 00:30:02 -0700 (PDT) >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >> >> >> Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) >> Author(s) : G. Camarillo, et al. >> Filename : draft-ietf-sipcore-reinvite-04.txt >> Pages : 24 >> Date : 2010-05-08 >> >>In this document, we clarify the handling of re-INVITEs in SIP. We >>clarify in which situations a UAS (User Agent Server) should generate >>a success response and in which situations a UAS should generate an >>error response to a re-INVITE. Additionally, we clarify issues >>related to target-refresh requests. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. From gao.yang2@zte.com.cn Thu May 13 03:12:27 2010 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 2FEE13A6B1F for ; Thu, 13 May 2010 03:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.046 X-Spam-Level: X-Spam-Status: No, score=-97.046 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 7dhRpYhKKF90 for ; Thu, 13 May 2010 03:12:25 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 89AEE3A6B1A for ; Thu, 13 May 2010 03:11:53 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Thu, 13 May 2010 18:06:20 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3015714703; Thu, 13 May 2010 18:11:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4DAB8qZ069146; Thu, 13 May 2010 18:11:17 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 13 May 2010 18:08:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-13 18:11:04, Serialize complete at 2010-05-13 18:11:04 Content-Type: multipart/alternative; boundary="=_alternative 0037E83648257722_=" X-MAIL: mse2.zte.com.cn o4DAB8qZ069146 Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Thu, 13 May 2010 10:12:27 -0000 This is a multipart message in MIME format. --=_alternative 0037E83648257722_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2hpbmppLA0KDQpVQSBBIE1VU1QgZmluaXNoIHRoZSBmaXJzdCBSZS1JTlZJVEUgYmVmb3Jl IHRoZSBzZWNvbmQgUmUtSU5WSVRFLiBTbywgDQp0aGVyZSdzIG5vIGFtYmlndWl0eSBoZXJlLiBU aGUgVUEgQiBjYW4gaGFuZGxlIHRoZSBSZS1JTlZJVEUgT0suDQoNCkluIG15IHVuZGVyc3RhbmRp bmcsIGl0IGlzIGNyb3NzaW5nIGNhc2UsIHdoaWxlIG5vdCBnbGFyZSBvbmUuDQoNClRob3VnaCBp dCBpcyBub3Qgbm9ybWF0aXZlLCBidXQgSSdkIGxpa2UgdG8gZGlzdGluZ3Vpc2ggdGhlIHR3bzoN Cg0KR2xhcmUgY2FzZTogdGhlcmUncyBhbWJpZ3VpdHkuDQpDcm9zc2luZyBjYXNlOiB0aGVyZSdz IG5vIGFtYmlndWl0eSwgYnV0IG1lc3NhZ2UgaXMgaW50ZXJsYWNlZCBmcm9tIHRoZSANCm5vcm1h bCBzZXF1ZW5jZS4gDQoNClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAg OigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KT0tVTVVSQSBTaGluamkgPHNo aW5qaS5va3VtdXJhQHNvZnRmcm9udC5qcD4gDQoyMDEwLTA1LTEzIDE3OjM1DQoNCsrVvP7Iyw0K c2lwY29yZUBpZXRmLm9yZw0Ks63LzQ0KZ2FvLnlhbmcyQHp0ZS5jb20uY24NCtb3zOINClJlOiBb c2lwY29yZV0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQudHh0DQoN Cg0KDQoNCg0KDQpHYW8sDQoNCklJVUMgeW91IG1lYW5zIHRoYXQgVUFTIHRyZWF0cyBhIDR4eCB0 byBJTlZJVEUgYXMgYW4gb2ZmZXIgYW5kDQphbiBBQ0sgYXMgYW4gYW5zd2VyLg0KDQpXZWxsLCAN Cg0KICAgIEEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQg0KICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgIHxyZS1JTlYgKG9mZmVyMSkgICAgICAgICAgICAg ICAgfA0KICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgIHwgICAgICAg ICAgICAgICAgICAgMTh4KGFuc3dlcjEpfA0KICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBub24tMnh4fA0KICAgIHw8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgLy0tLS0tLS0tLS0+fCoNCiAgICB8 QUNLICAgICAgICAgICAgICAgLyAgICAgICAgICAgIHwNCiAgICB8LS0tLS0tLS0tLS0tLS0tLS0v LS0tLS0tLS0tLS0tPnwNCiAgICB8ICAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgIHwNCiAg ICB8cmUtSU5WIChvZmZlcjIpLyAgICAgICAgICAgICAgIHwNCiAgICB8LS0tLS0tLS0tLS0tLS0v ICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN Cg0KSW4gYW4gYWJvdmUgRmlndXJlLCB3aGF0IGlzIGEgcmVzcG9uc2UgY29kZSB0byB0aGUgMm5k DQpyZS1JTlZJVEU/DQpPciBpZiBVQSBCIHJlY2VpdmVkIHRoZSAybmQgcmUtSU5JVlRFIGJlZm9y ZSBub24tMnh4LA0Kd2hhdCBpcyBhIHJlc3BvbnNlIGNvZGUgdG8gaXQ/DQoNCmdhby55YW5nMkB6 dGUuY29tLmNuDQpUaHUsIDEzIE1heSAyMDEwIDE0OjAwOjE2ICswODAwDQo+SGkgU2hpbmppLA0K Pg0KPlRoZXJlJ3MgcHJlY29uZGl0aW9uIGZvciB0aGUgdGV4dCB5b3UgbWVudGlvbmVkOiANCj4N Cj5XaGVuIGNoZWNraW5nIGZvciBnbGFyZSBzaXR1YXRpb25zLCBVQXMgTVVTVCB0cmVhdCB0aGUg ZXhjaGFuZ2Ugb2YgYQ0KPiAgIG5vbi0yeHggZmluYWwgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUg YW5kIGl0cyBjb3JyZXNwb25kaW5nIEFDSw0KPiAgIHJlcXVlc3QgYXMgYW4gb2ZmZXIvYW5zd2Vy IGV4Y2hhbmdlLiAgQ29uc2VxdWVudGx5LCB0aGUgcnVsZXMNCj4gICByZWdhcmRpbmcgZ2xhcmUg c2l0dWF0aW9ucyBhcHBsaWNhYmxlIHRvIG9mZmVyL2Fuc3dlciBleGNoYW5nZXMgYXJlDQo+ICAg YWxzbyBhcHBsaWNhYmxlIHRvIHRob3NlIGV4Y2hhbmdlcy4gIFRoZXNlIHJ1bGVzIGltcGx5IHRo YXQgaWYgdGhlDQo+ICAgVUFTIG9mIGEgcmUtSU5WSVRFIHRyYW5zYWN0aW9uIHJlY2VpdmVzIGFu ZCBVUERBVEUgcmVxdWVzdCB3aXRoIGFuDQo+ICAgb2ZmZXIgYWZ0ZXIgaGF2aW5nIHNlbnQgYSBu b24tMnh4IGZpbmFsIHJlc3BvbnNlIHRvIHRoZSByZS1JTlZJVEUgYnV0DQo+ICAgYmVmb3JlIGhh dmluZyByZWNlaXZlZCB0aGUgY29ycmVzcG9uZGluZyBBQ0sgcmVxdWVzdCwgdGhlIFVBIFNIT1VM RA0KPiAgIHJldHVybiBhIDQ5MSAoUmVxdWVzdCBQZW5kaW5nKSByZXNwb25zZSB0byB0aGUgVVBE QVRFIHJlcXVlc3QuIA0KPg0KPldpdGggdGhlIHByZWNvbmRpdGlvbiBkZWZpbmVkIGhlcmUsIHRo ZSBVQVMob2YgUmUtSU5WSVRFKSBNVVNUIHRoaW5rIGl0IA0KPmhhcyBzZW5kZWQgYSBPZmZlciBh ZnRlciBpdCBzZW5kIHRoZSBub24tMnh4Lg0KPg0KPkJlZm9yZSB0aGUgVUFTIGdldCB0aGUgQUNL LCBpdCBnZXQgYSBuZXcgT2ZmZXIgaW4gVVBEQVRFLCBpdCBTSE9VTEQgc2VuZCANCj40eHguDQo+ DQo+VGhlcmUncyBub3JtYXRpdmUgZGVmaW5pdGlvbiBoZXJlLg0KDQpJcyB0aGF0ICJub3JtYXRp dmUgZGVmaW5pdGlvbiIgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0Pw0KDQpSZWdhcmRzLA0KU2hpbmpp DQoNCg0KPlRoYW5rcywNCj4NCj5HYW8NCj4NCj49PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPiBaaXAgICAgOiAyMTAwMTINCj4gVGVsICAgIDogODcyMTENCj4gVGVsMiAgIDoo Kzg2KS0wMjUtNTI4NzcyMTENCj4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj49PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPk9LVU1VUkEgU2hpbmppIDxzaGlu amkub2t1bXVyYUBzb2Z0ZnJvbnQuanA+IA0KPg0KPkhpLA0KPg0KPkluIHRoaXMgdGV4dCwNCj4N Cj4zLjUuICBHbGFyZSBTaXR1YXRpb25zDQo+ICAgVGhlc2UgcnVsZXMgaW1wbHkgdGhhdCBpZiB0 aGUNCj4gICBVQVMgb2YgYSByZS1JTlZJVEUgdHJhbnNhY3Rpb24gcmVjZWl2ZXMgYW5kIFVQREFU RSByZXF1ZXN0IHdpdGggYW4NCj4gICBvZmZlciBhZnRlciBoYXZpbmcgc2VudCBhIG5vbi0yeHgg ZmluYWwgcmVzcG9uc2UgdG8gdGhlIHJlLUlOVklURSBidXQNCj4gICBiZWZvcmUgaGF2aW5nIHJl Y2VpdmVkIHRoZSBjb3JyZXNwb25kaW5nIEFDSyByZXF1ZXN0LCB0aGUgVUEgU0hPVUxEDQo+ICAg cmV0dXJuIGEgNDkxIChSZXF1ZXN0IFBlbmRpbmcpIHJlc3BvbnNlIHRvIHRoZSBVUERBVEUgcmVx dWVzdC4NCj4NCj50aGF0IGlzIHNob3duIGluIGEgRmlndXJlIGJlbG93Lg0KPg0KPiAgICBBICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEINCj4gICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQo+ICAgIHxyZS1JTlYgKG9mZmVyMSkgICAgICAgICAgICAgICAgfA0KPiAg ICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgfCAgICAgICAgICAgICAg ICAgICAxOHgoYW5zd2VyMSl8DQo+ICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t fA0KPiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgbm9uLTJ4eHwNCj4gICAgfCAgICAgICAg ICAgICAgIC8tLS0tLS0tLS0tLS0tLS18PC0rDQo+ICAgIHxVUEQgICAgICAgICAgIC8gICAgICAg ICAgICAgICAgfCAgfCByZWplY3QgVVBEQVRFDQo+ICAgIHw9PT09PT09PT09PT09Lz09PT09PT09 PT09PT09PT0+fCogfA0KPiAgICB8ICAgICAgICAgICAgLyAgICAgICAgICA0OTEoVVBEKXwgIHwN Cj4gICAgfDw9PT09PT09PT09Lz09PT09PT09PT09PT09PT09PT18ICB8DQo+ICAgIHwgICAgICAg ICAgLyAgICAgICAgICAgICAgICAgICAgfCAgfA0KPiAgICB8PC0tLS0tLS0tLyAgICAgICAgICAg ICAgICAgICAgIHwgIHwNCj4gICAgfEFDSyAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICB8 DQo+ICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fDwtKw0KPiAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4NCj5SZWdhcmRpbmcgNDkxIGFuZCA1MDAgcmVz cG9uc2UsIHRoZXJlIGFyZSBzb21lIGRlc2NyaXB0aW9ucyBpbiBSRkMzMjYxDQo+YW5kIFJGQzMz MTEuIEJ1dCBpbiB0aGVzZSB0ZXh0LCBhbiBpbnRlcndvcmtpbmcgb2YgSU5WSVRFIGFuZCBVUERB VEUNCj5pcyBub3QgY2xlYXIuDQo+DQo+SU1PIHdoZW4gdGhlIGRpcmVjdGlvbnMgb2YgdGhlIGJv dGggcmVxdWVzdCBhcmUgY29ycmVzcG9uZGluZywNCj50aGUgcmVzcG9uc2UgY29kZSBzZWVtcyB0 byBiZSA1MDAuIEFuZCBpZiB0aGUgZGlyZWN0aW9ucyBhcmUgbm90DQo+Y29ycmVzcG9uZGluZywg dGhlIHJlc3BvbnNlIGNvZGUgc2VlbXMgdG8gYmUgNDkxLg0KPg0KPlRoZXJlZm9yZSBpbiB0aGlz IGNhc2UsIEkgdGhpbmsgYSBVQVMgc2hvdWxkIHJldHVybiBhIDUwMCByZXNwb25zZSB0bw0KPmFu IFVQREFURSByZXF1ZXN0Lg0KPg0KPlJlZ2FyZHMsDQo+U2hpbmppDQo+DQo+SW50ZXJuZXQtRHJh ZnRzQGlldGYub3JnDQo+U2F0LCAgOCBNYXkgMjAxMCAwMDozMDowMiAtMDcwMCAoUERUKQ0KPj5B IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgDQpkaXJlY3Rvcmllcy4NCj4+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUgDQpXb3JraW5nIEdyb3VwIG9mIHRo ZSBJRVRGLg0KPj4NCj4+DQo+PiAgICAgICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBSZS1J TlZJVEUgYW5kIFRhcmdldC1yZWZyZXNoIFJlcXVlc3QgDQpIYW5kbGluZyBpbiB0aGUgU2Vzc2lv biBJbml0aWF0aW9uIFByb3RvY29sIChTSVApDQo+PiAgICAgICAgICAgICAgICBBdXRob3Iocykg ICAgICAgOiBHLiBDYW1hcmlsbG8sIGV0IGFsLg0KPj4gICAgICAgICAgICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0LnR4dA0KPj4gICAgICAgICAg ICAgICAgUGFnZXMgICAgICAgICAgIDogMjQNCj4+ICAgICAgICAgICAgICAgIERhdGUgICAgICAg ICAgICA6IDIwMTAtMDUtMDgNCj4+DQo+PkluIHRoaXMgZG9jdW1lbnQsIHdlIGNsYXJpZnkgdGhl IGhhbmRsaW5nIG9mIHJlLUlOVklURXMgaW4gU0lQLiAgV2UNCj4+Y2xhcmlmeSBpbiB3aGljaCBz aXR1YXRpb25zIGEgVUFTIChVc2VyIEFnZW50IFNlcnZlcikgc2hvdWxkIGdlbmVyYXRlDQo+PmEg c3VjY2VzcyByZXNwb25zZSBhbmQgaW4gd2hpY2ggc2l0dWF0aW9ucyBhIFVBUyBzaG91bGQgZ2Vu ZXJhdGUgYW4NCj4+ZXJyb3IgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUuICBBZGRpdGlvbmFsbHks IHdlIGNsYXJpZnkgaXNzdWVzDQo+PnJlbGF0ZWQgdG8gdGFyZ2V0LXJlZnJlc2ggcmVxdWVzdHMu DQo+Pg0KPj5BIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4+aHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0LnR4 dA0KPj4NCj4+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KPj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+QmVs b3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJl YWRlcg0KPj5pbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJ SSB2ZXJzaW9uIG9mIHRoZQ0KPj5JbnRlcm5ldC1EcmFmdC4NCg0KDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0 dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3Ro ZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0037E83648257722_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNoaW5qaSw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlVBIEEgTVVTVCBmaW5pc2gg dGhlIGZpcnN0IFJlLUlOVklURQ0KYmVmb3JlIHRoZSBzZWNvbmQgUmUtSU5WSVRFLiBTbywgdGhl cmUncyBubyBhbWJpZ3VpdHkgaGVyZS4gVGhlIFVBIEIgY2FuDQpoYW5kbGUgdGhlIFJlLUlOVklU RSBPSy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklu IG15IHVuZGVyc3RhbmRpbmcsIGl0IGlzIGNyb3NzaW5nDQpjYXNlLCB3aGlsZSBub3QgZ2xhcmUg b25lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhv dWdoIGl0IGlzIG5vdCBub3JtYXRpdmUsIGJ1dCBJJ2QNCmxpa2UgdG8gZGlzdGluZ3Vpc2ggdGhl IHR3bzo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkds YXJlIGNhc2U6IHRoZXJlJ3MgYW1iaWd1aXR5LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Q3Jvc3NpbmcgY2FzZTogdGhlcmUncyBubyBhbWJpZ3VpdHksDQpidXQg bWVzc2FnZSBpcyBpbnRlcmxhY2VkIGZyb20gdGhlIG5vcm1hbCBzZXF1ZW5jZS4gPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVs ICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4Nzcy MTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5PS1VNVVJBIFNoaW5qaSAmbHQ7c2hpbmppLm9rdW11cmFAc29m dGZyb250LmpwJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDEwLTA1LTEzIDE3OjM1PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnNpcGNvcmVAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Pmdhby55YW5nMkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIEkt RCBBY3Rpb246ZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0LnR4dDwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+R2FvLDxicj4NCjxi cj4NCklJVUMgeW91IG1lYW5zIHRoYXQgVUFTIHRyZWF0cyBhIDR4eCB0byBJTlZJVEUgYXMgYW4g b2ZmZXIgYW5kPGJyPg0KYW4gQUNLIGFzIGFuIGFuc3dlci48YnI+DQo8YnI+DQpXZWxsLCA8YnI+ DQo8YnI+DQogJm5ic3A7ICZuYnNwO0EgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IEI8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQogJm5ic3A7ICZuYnNwO3xyZS1J TlYgKG9mZmVyMSkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDt8PGJyPg0KICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJmd0O3w8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDE4eChhbnN3ZXIxKXw8YnI+ DQogJm5ic3A7ICZuYnNwO3wmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4N CiAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtub24tMnh4fDxicj4N CiAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPg0K ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8PGJyPg0KICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAvLS0tLS0tLS0tLSZndDt8Kjxi cj4NCiAmbmJzcDsgJm5ic3A7fEFDSyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8PGJyPg0KICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0tLS0tLS0tLS0vLS0tLS0tLS0tLS0tJmd0 O3w8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3xyZS1JTlYgKG9mZmVyMikvICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgfDxicj4NCiAm bmJzcDsgJm5ic3A7fC0tLS0tLS0tLS0tLS0tLyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQo8YnI+DQpJ biBhbiBhYm92ZSBGaWd1cmUsIHdoYXQgaXMgYSByZXNwb25zZSBjb2RlIHRvIHRoZSAybmQ8YnI+ DQpyZS1JTlZJVEU/PGJyPg0KT3IgaWYgVUEgQiByZWNlaXZlZCB0aGUgMm5kIHJlLUlOSVZURSBi ZWZvcmUgbm9uLTJ4eCw8YnI+DQp3aGF0IGlzIGEgcmVzcG9uc2UgY29kZSB0byBpdD88YnI+DQo8 YnI+DQpnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NClRodSwgMTMgTWF5IDIwMTAgMTQ6MDA6MTYg KzA4MDA8YnI+DQomZ3Q7SGkgU2hpbmppLDxicj4NCiZndDs8YnI+DQomZ3Q7VGhlcmUncyBwcmVj b25kaXRpb24gZm9yIHRoZSB0ZXh0IHlvdSBtZW50aW9uZWQ6IDxicj4NCiZndDs8YnI+DQomZ3Q7 V2hlbiBjaGVja2luZyBmb3IgZ2xhcmUgc2l0dWF0aW9ucywgVUFzIE1VU1QgdHJlYXQgdGhlIGV4 Y2hhbmdlIG9mDQphPGJyPg0KJmd0OyAmbmJzcDsgbm9uLTJ4eCBmaW5hbCByZXNwb25zZSB0byBh IHJlLUlOVklURSBhbmQgaXRzIGNvcnJlc3BvbmRpbmcNCkFDSzxicj4NCiZndDsgJm5ic3A7IHJl cXVlc3QgYXMgYW4gb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLiAmbmJzcDtDb25zZXF1ZW50bHksIHRo ZQ0KcnVsZXM8YnI+DQomZ3Q7ICZuYnNwOyByZWdhcmRpbmcgZ2xhcmUgc2l0dWF0aW9ucyBhcHBs aWNhYmxlIHRvIG9mZmVyL2Fuc3dlciBleGNoYW5nZXMNCmFyZTxicj4NCiZndDsgJm5ic3A7IGFs c28gYXBwbGljYWJsZSB0byB0aG9zZSBleGNoYW5nZXMuICZuYnNwO1RoZXNlIHJ1bGVzIGltcGx5 DQp0aGF0IGlmIHRoZTxicj4NCiZndDsgJm5ic3A7IFVBUyBvZiBhIHJlLUlOVklURSB0cmFuc2Fj dGlvbiByZWNlaXZlcyBhbmQgVVBEQVRFIHJlcXVlc3QNCndpdGggYW48YnI+DQomZ3Q7ICZuYnNw OyBvZmZlciBhZnRlciBoYXZpbmcgc2VudCBhIG5vbi0yeHggZmluYWwgcmVzcG9uc2UgdG8gdGhl IHJlLUlOVklURQ0KYnV0PGJyPg0KJmd0OyAmbmJzcDsgYmVmb3JlIGhhdmluZyByZWNlaXZlZCB0 aGUgY29ycmVzcG9uZGluZyBBQ0sgcmVxdWVzdCwgdGhlIFVBDQpTSE9VTEQ8YnI+DQomZ3Q7ICZu YnNwOyByZXR1cm4gYSA0OTEgKFJlcXVlc3QgUGVuZGluZykgcmVzcG9uc2UgdG8gdGhlIFVQREFU RSByZXF1ZXN0Lg0KPGJyPg0KJmd0Ozxicj4NCiZndDtXaXRoIHRoZSBwcmVjb25kaXRpb24gZGVm aW5lZCBoZXJlLCB0aGUgVUFTKG9mIFJlLUlOVklURSkgTVVTVCB0aGluaw0KaXQgPGJyPg0KJmd0 O2hhcyBzZW5kZWQgYSBPZmZlciBhZnRlciBpdCBzZW5kIHRoZSBub24tMnh4Ljxicj4NCiZndDs8 YnI+DQomZ3Q7QmVmb3JlIHRoZSBVQVMgZ2V0IHRoZSBBQ0ssIGl0IGdldCBhIG5ldyBPZmZlciBp biBVUERBVEUsIGl0IFNIT1VMRA0Kc2VuZCA8YnI+DQomZ3Q7NHh4Ljxicj4NCiZndDs8YnI+DQom Z3Q7VGhlcmUncyBub3JtYXRpdmUgZGVmaW5pdGlvbiBoZXJlLjxicj4NCjxicj4NCklzIHRoYXQg JnF1b3Q7bm9ybWF0aXZlIGRlZmluaXRpb24mcXVvdDsgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0Pzxi cj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KU2hpbmppPGJyPg0KPGJyPg0KPGJyPg0KJmd0O1RoYW5r cyw8YnI+DQomZ3Q7PGJyPg0KJmd0O0dhbzxicj4NCiZndDs8YnI+DQomZ3Q7PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAw MTI8YnI+DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgVGVsMiAmbmJz cDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5j b20uY248YnI+DQomZ3Q7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQom Z3Q7PGJyPg0KJmd0O09LVU1VUkEgU2hpbmppICZsdDtzaGluamkub2t1bXVyYUBzb2Z0ZnJvbnQu anAmZ3Q7IDxicj4NCiZndDs8YnI+DQomZ3Q7SGksPGJyPg0KJmd0Ozxicj4NCiZndDtJbiB0aGlz IHRleHQsPGJyPg0KJmd0Ozxicj4NCiZndDszLjUuICZuYnNwO0dsYXJlIFNpdHVhdGlvbnM8YnI+ DQomZ3Q7ICZuYnNwOyBUaGVzZSBydWxlcyBpbXBseSB0aGF0IGlmIHRoZTxicj4NCiZndDsgJm5i c3A7IFVBUyBvZiBhIHJlLUlOVklURSB0cmFuc2FjdGlvbiByZWNlaXZlcyBhbmQgVVBEQVRFIHJl cXVlc3QNCndpdGggYW48YnI+DQomZ3Q7ICZuYnNwOyBvZmZlciBhZnRlciBoYXZpbmcgc2VudCBh IG5vbi0yeHggZmluYWwgcmVzcG9uc2UgdG8gdGhlIHJlLUlOVklURQ0KYnV0PGJyPg0KJmd0OyAm bmJzcDsgYmVmb3JlIGhhdmluZyByZWNlaXZlZCB0aGUgY29ycmVzcG9uZGluZyBBQ0sgcmVxdWVz dCwgdGhlIFVBDQpTSE9VTEQ8YnI+DQomZ3Q7ICZuYnNwOyByZXR1cm4gYSA0OTEgKFJlcXVlc3Qg UGVuZGluZykgcmVzcG9uc2UgdG8gdGhlIFVQREFURSByZXF1ZXN0Ljxicj4NCiZndDs8YnI+DQom Z3Q7dGhhdCBpcyBzaG93biBpbiBhIEZpZ3VyZSBiZWxvdy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7QSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgQjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8cmUtSU5W IChvZmZlcjEpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3wtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0mZ3Q7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDE4eChhbnN3ZXIx KXw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLXw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O25vbi0yeHh8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy0tLS0tLS0tLS0tLS0tLXwmbHQ7LSs8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDt8VVBEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg LyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3wgJm5ic3A7fCByZWplY3QgVVBEQVRFPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fD09PT09PT09 PT09PT0vPT09PT09PT09PT09PT09PSZndDt8KiB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDs0OTEoVVBEKXwgJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7ICZu YnNwO3wmbHQ7PT09PT09PT09PS89PT09PT09PT09PT09PT09PT09fCAmbmJzcDt8PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS8g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8ICZuYnNwO3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8QUNLICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDt8PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8Jmx0Oy0rPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDs8YnI+DQomZ3Q7UmVnYXJkaW5nIDQ5MSBhbmQgNTAw IHJlc3BvbnNlLCB0aGVyZSBhcmUgc29tZSBkZXNjcmlwdGlvbnMgaW4gUkZDMzI2MTxicj4NCiZn dDthbmQgUkZDMzMxMS4gQnV0IGluIHRoZXNlIHRleHQsIGFuIGludGVyd29ya2luZyBvZiBJTlZJ VEUgYW5kIFVQREFURTxicj4NCiZndDtpcyBub3QgY2xlYXIuPGJyPg0KJmd0Ozxicj4NCiZndDtJ TU8gd2hlbiB0aGUgZGlyZWN0aW9ucyBvZiB0aGUgYm90aCByZXF1ZXN0IGFyZSBjb3JyZXNwb25k aW5nLDxicj4NCiZndDt0aGUgcmVzcG9uc2UgY29kZSBzZWVtcyB0byBiZSA1MDAuIEFuZCBpZiB0 aGUgZGlyZWN0aW9ucyBhcmUgbm90PGJyPg0KJmd0O2NvcnJlc3BvbmRpbmcsIHRoZSByZXNwb25z ZSBjb2RlIHNlZW1zIHRvIGJlIDQ5MS48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZXJlZm9yZSBpbiB0 aGlzIGNhc2UsIEkgdGhpbmsgYSBVQVMgc2hvdWxkIHJldHVybiBhIDUwMCByZXNwb25zZQ0KdG88 YnI+DQomZ3Q7YW4gVVBEQVRFIHJlcXVlc3QuPGJyPg0KJmd0Ozxicj4NCiZndDtSZWdhcmRzLDxi cj4NCiZndDtTaGluamk8YnI+DQomZ3Q7PGJyPg0KJmd0O0ludGVybmV0LURyYWZ0c0BpZXRmLm9y Zzxicj4NCiZndDtTYXQsICZuYnNwOzggTWF5IDIwMTAgMDA6MzA6MDIgLTA3MDAgKFBEVCk8YnI+ DQomZ3Q7Jmd0O0EgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cw0KZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyZndDtUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZQ0K V29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1RpdGxlICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogUmUt SU5WSVRFIGFuZCBUYXJnZXQtcmVmcmVzaCBSZXF1ZXN0IEhhbmRsaW5nDQppbiB0aGUgU2Vzc2lv biBJbml0aWF0aW9uIFByb3RvY29sIChTSVApPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0F1dGhvcihzKQ0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOiBHLiBDYW1hcmlsbG8sIGV0IGFsLjxicj4NCiZndDsmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFt ZQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZp dGUtMDQudHh0PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDogMjQ8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF0ZSAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs6IDIwMTAtMDUtMDg8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7SW4g dGhpcyBkb2N1bWVudCwgd2UgY2xhcmlmeSB0aGUgaGFuZGxpbmcgb2YgcmUtSU5WSVRFcyBpbiBT SVAuDQombmJzcDtXZTxicj4NCiZndDsmZ3Q7Y2xhcmlmeSBpbiB3aGljaCBzaXR1YXRpb25zIGEg VUFTIChVc2VyIEFnZW50IFNlcnZlcikgc2hvdWxkIGdlbmVyYXRlPGJyPg0KJmd0OyZndDthIHN1 Y2Nlc3MgcmVzcG9uc2UgYW5kIGluIHdoaWNoIHNpdHVhdGlvbnMgYSBVQVMgc2hvdWxkIGdlbmVy YXRlDQphbjxicj4NCiZndDsmZ3Q7ZXJyb3IgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUuICZuYnNw O0FkZGl0aW9uYWxseSwgd2UgY2xhcmlmeSBpc3N1ZXM8YnI+DQomZ3Q7Jmd0O3JlbGF0ZWQgdG8g dGFyZ2V0LXJlZnJlc2ggcmVxdWVzdHMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0EgVVJM IGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxicj4NCiZndDsmZ3Q7aHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0LnR4dDxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KJmd0OyZndDtmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtCZWxvdyBpcyB0aGUg ZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyPGJyPg0K Jmd0OyZndDtpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJ SSB2ZXJzaW9uIG9mIHRoZTxicj4NCiZndDsmZ3Q7SW50ZXJuZXQtRHJhZnQuPGJyPg0KPGJyPg0K PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNw O1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29u dGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5i c3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0 aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7 Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7 YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJz cDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Ns b3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJz cDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7 YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkm bmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDth cmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2 ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5i c3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5i c3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7 U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0037E83648257722_=-- From adam@nostrum.com Thu May 13 08:33:32 2010 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 92C0B3A67B6 for ; Thu, 13 May 2010 08:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_50=0.001, 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 IaTpumlfM2NB for ; Thu, 13 May 2010 08:33: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 CAC453A6919 for ; Thu, 13 May 2010 08:33:29 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4DFXFjQ022460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 10:33:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BEC1BBB.4050706@nostrum.com> Date: Thu, 13 May 2010 10:33:15 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 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 Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] SigComp and 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: Thu, 13 May 2010 15:33:32 -0000 Christer: Sorry for the slow response. Some responses inline. On 5/6/10 2:51 PM, Christer Holmberg wrote: > 1. How can the UA ensure that the outbound proxy will be listed in the > Service-Route in the first place? RFC 3608 (Service-Route) does not > mandate the registrar to insert any intermediaries in the Service-Route, > e.g based on Path. It's all based on local policy. > Service-Route is the means by which the network conveys the proxies that the UA needs to use when accessing the network. I think there's an assumption in certain networks -- like IMS -- that the registrar will, as a matter of policy, copy the Path into the Service-Route. Strictly speaking, though, even that's not necessary for the UA to ensure traversal of a specific first-hop proxy. Service-Route specifies a minimal set of proxies to be traversed, not an exhaustive and restrictive set of proxies. There is nothing in the Service-Route mechanism that prevents the UA from inserting a specific outbound proxy in all of its requests. So, trivially, if the UA discovers that a SigComp-supporting proxy isn't the first hop in the Service-Route returned by the network, it makes a local decision to send all requests through one that does. (Recall that support of SigComp by the first proxy in the Service-Route set can be determined by casual inspection: if the URL has a ";comp=sigcomp" parameter, it supports SigComp; otherwise, it does not.) > 2. Even if the registrar would build the Service-Route based on Path, > how does it know that the Path address/port values will be > usable/routable in the UA-towards-registrar direction (Path is supposed > to be used in the registrar-towards-UA direction)? This is similar to > the Record-Route problem, and intermediaries with different network > addresses/ports per direction would have to insert "double Path". > If this mechanism is used, and if the outbound proxy presents different address spaces towards the UA than it does towards the registrar, then the outbound proxy will need to take some extraordinary measures to ensure that everything works smoothly. Inserting a "Double-Path" would be one approach. > I guess the outbound proxy could insert itself in the Service-Route, but > that is not described anywhere in RFC 5049, and it is also a SHOULD NOT > in RFC 3608. > That approach is congruent to the "change the Record-Route" mechanism that 3261 originally described for multihomed proxies. If you'll recall, we determined this approach to be problematic enough that we issued a correction -- RFC5658 -- that basically says "don't do that." If you're operating in a network that, as a matter of policy, reflects the Path back in a Service-Route, then I think the "Double-Path" approach is really what you want to do for multi-homed outbound proxies. And, even if you're not, doing a "Double-Path" doesn't cause any issues. /a From dean.willis@softarmor.com Thu May 13 10:55:28 2010 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 664223A6C22 for ; Thu, 13 May 2010 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-0.626, 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 gZ1L8shBQHLK for ; Thu, 13 May 2010 10:55:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 783123A68D6 for ; Thu, 13 May 2010 10:55:27 -0700 (PDT) Received: from [192.168.2.2] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4DHsr6L017200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 May 2010 12:54:54 -0500 Message-ID: <4BEC3CE7.5000302@softarmor.com> Date: Thu, 13 May 2010 12:54:47 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: Paul Kyzivat References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> <4BE998FE.5040703@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> <4BE9F8CE.2050207@cisco.com> In-Reply-To: <4BE9F8CE.2050207@cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] The predictive value of OPTIONS 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 May 2010 17:55:28 -0000 Paul Kyzivat wrote: > There is no way to win here. You must be inconsistent at some point. So > the result of the OPTIONS wrt Accept cannot be trusted to predict future > behavior. The same is true for most of the other things reported in > OPTIONS - its really hard to say much about how relevant they are for > predicting future behavior. This gets right at the aspect of option-tags that people seem to keep getting confused on. OPTIONS responses and option-tags DO NOT assert (or require) anything about "willingness" or "authorization". They assert only capability. You can be capable of understanding a MESSAGE request without being willing to accept one from a given party (or, in the case of a B2BUA, TO a given party). We keep falling back into trying to use optionality to predict or mandate outcome. We MUST NOT do this -- the mechanism just doesn't work this way. At best, optionality in SIP is a way of predicting understanding, not behavior. Consider the difference between Bob approaching Alice and saying "Would you understand what I was asking if I asked you to go home with me?" vs. Bob asking Alice "Will you go home with me?" The first is an optionality discussion; the second is a request for a specific extension. -- Dean -- Dean From adam@nostrum.com Thu May 13 11:23:09 2010 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 4C7FE3A6C8F for ; Thu, 13 May 2010 11:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.216, 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 D9YbakV4m-hI for ; Thu, 13 May 2010 11:23:05 -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 9B7423A6C6E for ; Thu, 13 May 2010 11:20:19 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4DIK25O035226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 13:20:02 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BEC42D2.6090604@nostrum.com> Date: Thu, 13 May 2010 13:20:02 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dean Willis References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> <4BE998FE.5040703@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> <4BE9F8CE.2050207@cisco.com> <4BEC3CE7.5000302@softarmor.com> In-Reply-To: <4BEC3CE7.5000302@softarmor.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: "Paul E. Jones" , "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] The predictive value of OPTIONS 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 May 2010 18:23:09 -0000 [as a participant] On 5/13/10 12:54 PM, Dean Willis wrote: > Consider the difference between Bob approaching Alice and saying "Would > you understand what I was asking if I asked you to go home with me?" vs. > Bob asking Alice "Will you go home with me?" > I nominate this for the award of "most illustrative analogy ever applied to SIP." :-) /a From kpfleming@digium.com Thu May 13 11:32:25 2010 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 9278B3A684F for ; Thu, 13 May 2010 11:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.414 X-Spam-Level: X-Spam-Status: No, score=-104.414 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_40=-0.185, 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 XXJW3FMpMqLR for ; Thu, 13 May 2010 11:32:24 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 8BD233A6C93 for ; Thu, 13 May 2010 11:32:10 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OCdCS-0000g2-NG for sipcore@ietf.org; Thu, 13 May 2010 13:32:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id A0824D8025 for ; Thu, 13 May 2010 13:32:00 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csq-ZpRGX7sj for ; Thu, 13 May 2010 13:32:00 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 5A314D8023 for ; Thu, 13 May 2010 13:32:00 -0500 (CDT) Message-ID: <4BEC45A0.5000802@digium.com> Date: Thu, 13 May 2010 13:32:00 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: sipcore@ietf.org References: <01c501caec0e$48e624e0$dab26ea0$@com> <430FC6BDED356B4C8498F634416644A91A8A7D7192@mail> <430FC6BDED356B4C8498F634416644A91A8A7D71A2@mail> <4BE2BCB0.10909@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D760B@mail> <4BE44683.9040405@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7771@mail> <4BE81570.5080803@cisco.com> <00d901caf076$bdd21770$39764650$@com> <4BE86339.6020709@cisco.com> <010501caf087$53ff6c60$fbfe4520$@com> <4BE889BD.2030901@cisco.com> <430FC6BDED356B4C8498F634416644A91A8A7D7AB9@mail> <4BE95E6E.3000601@cisco.com> <430FC6BDED356B4C8498F634416644A91C139909C2@mail> <4BE998FE.5040703@cisco.com> <430FC6BDED356B4C8498F634416644A91C13990ABF@mail> <4BE9F8CE.2050207@cisco.com> <4BEC3CE7.5000302@softarmor.com> <4BEC42D2.6090604@nostrum.com> In-Reply-To: <4BEC42D2.6090604@nostrum.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] The predictive value of OPTIONS 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 May 2010 18:32:25 -0000 On 05/13/2010 01:20 PM, Adam Roach wrote: > [as a participant] > > On 5/13/10 12:54 PM, Dean Willis wrote: >> Consider the difference between Bob approaching Alice and saying "Would >> you understand what I was asking if I asked you to go home with me?" vs. >> Bob asking Alice "Will you go home with me?" >> > > I nominate this for the award of "most illustrative analogy ever applied > to SIP." Oddly enough, about 30 seconds ago I sent a message to DISPATCH about Bob chatting up Alice. Precognition, I guess. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From adam@nostrum.com Thu May 13 12:12:26 2010 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 D98EC3A6BC2 for ; Thu, 13 May 2010 12:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_50=0.001, 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 8kHPppGeNKJ4 for ; Thu, 13 May 2010 12:12: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 BBB2A3A68F9 for ; Thu, 13 May 2010 12:12:14 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4DJBg14039220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 14:11:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BEC4EEE.70008@nostrum.com> Date: Thu, 13 May 2010 14:11:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BDB52AB.9000507@estacado.net>, 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: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 19:12:27 -0000 [as a participant] Regarding the proposed text that I sent to the mailing list last week, there was an exchange regarding where in the document this behavior goes; On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: > ...[T]his text does not belong in section 10, as section 10 is about what needs to be documented to define an INFO package, not about what the implementor actually needs to do. It actually relates to whether it was appropriate to select INFO in the first place to do the job, as if the information transfer requirements are inappropriate to the underlying transport capabilities of SIP, then INFO should not have been selected in the first place. > On 5/5/10 8:28 AM, Christer Holmberg responded: > So, I guess it should be somewhere in section 7.4. > On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: > Yes, but obviously not in the same words. It needs to be tailored as do not choose an INFO solution if you need to do this. > I would argue that section 7.3 already goes over this ground in terms of whether INFO is appropriate for a particular use case. And, in fact, *most* of the proposed text isn't talking about what event package designers should do. Some of it does, but for the most part, the text talks about what implementors are required to do. The document *does* have a section that covers this ground: section 3. To that end, I would think we could split this into two sections. The part dealing with implementation issues would be a new section 3.5; the other would form an introduction to the existing section 10.9. Incorporating the other suggestions made so far, then, I would propose the following sections for the INFO document: > 3.5. Rate and Size of INFO Requests > > INFO messages differ from many other sorts of SIP messages in > that they carry application information, and the size and rate > of the INFO message is directly determined by the application. > This can cause application information traffic to interfere > with other traffic on that infrastructure, or to self-interfere > when data rates become too high. > > Implementors need to consider the impact that the size and the > rate of the INFO messages have on the network and on other > traffic, since it normally cannot be ensured that INFO messages > will be carried over a congestion-controlled transport protocol > end-to-end. Even if an INFO message is sent over such a > transport protocol, a downstream SIP entity might forward the > message over a transport protocol that does not provide > congestion control. > > Therefore, an application SHOULD generally have at most one > outstanding INFO message. Implementors are reminded to observe > the guidelines in RFC3261 Section 18 regarding the size of SIP > messages, such as the guideline to not exceed message sizes > of 1300 bytes when the path MTU is unknown. RFC5405 provides > additional guidelines for applications using the User Datagram > Protocol (UDP) that may be useful background reading. > > > > 10.9 Rate of INFO Requests > > A designer of an Info package needs to be mindful of the > potential congestion impact their application can have on both > the SIP network and the Internet at large. See section 3.5 > for a discussion of congestion-related issues. > > If there is a maximum or minimum rate at which UAs can send > INFO requests associated with the Info Package within a dialog, > the Info Package specification MUST document the rate values. > > If the rates can vary, the Info Package specification MAY > define Info Package parameters that UAs can use to indicate > or negotiate the rates. Alternatively the rate information > can be part of the application data information associated > with the Info Package. Does that sound reasonable? /a From keith.drage@alcatel-lucent.com Sun May 16 15:03:53 2010 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 6CEE33A6B17 for ; Sun, 16 May 2010 15:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_50=0.001, 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 eUPPfgstMV5t for ; Sun, 16 May 2010 15:03:52 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id A91BF3A6B11 for ; Sun, 16 May 2010 15:03:50 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4GM2a4U022955 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 May 2010 00:02:37 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 17 May 2010 00:02:36 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Mon, 17 May 2010 00:02:35 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: Acry0CTXmjhnJTziT1Wmpqip64ed5AANS/aw Message-ID: References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> In-Reply-To: <4BEC4EEE.70008@nostrum.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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, 16 May 2010 22:03:53 -0000 This proposed paragraph still causes me issues: > Therefore, an application SHOULD generally have at most one > outstanding INFO message. Implementors are reminded to observe > the guidelines in RFC3261 Section 18 regarding the size of SIP > messages, such as the guideline to not exceed message sizes > of 1300 bytes when the path MTU is unknown. RFC5405 provides > additional guidelines for applications using the User Datagram > Protocol (UDP) that may be useful background reading. I already objected to the first sentence above as I do not believe it solve= s the issue, and removes useful capabilities that may be desired by some ap= plications. I CANNOT accept this sentence. The second sentence above is an inexact extraction, and as such misleads co= mpletely. The correct quote is below: If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers. Nothing about not exceeding message sizes. Only restriction is to send usin= g a congestion controlled transport protocol if it exceeds MTU size. Theref= ore second sentence as currently drafted is unacceptable. regards Keith =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Thursday, May 13, 2010 8:12 PM > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > Subject: Re: [sipcore] Call for Consensus: INFO Specification=20 > and Congestion >=20 > [as a participant] >=20 > Regarding the proposed text that I sent to the mailing list=20 > last week, there was an exchange regarding where in the=20 > document this behavior goes; >=20 > On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: > > ...[T]his text does not belong in section 10, as section 10=20 > is about what needs to be documented to define an INFO=20 > package, not about what the implementor actually needs to do.=20 > It actually relates to whether it was appropriate to select=20 > INFO in the first place to do the job, as if the information=20 > transfer requirements are inappropriate to the underlying=20 > transport capabilities of SIP, then INFO should not have been=20 > selected in the first place. > > =20 >=20 > On 5/5/10 8:28 AM, Christer Holmberg responded: > > So, I guess it should be somewhere in section 7.4. > > =20 >=20 > On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: > > Yes, but obviously not in the same words. It needs to be=20 > tailored as do not choose an INFO solution if you need to do this. > > =20 >=20 > I would argue that section 7.3 already goes over this ground=20 > in terms of whether INFO is appropriate for a particular use=20 > case. And, in fact, > *most* of the proposed text isn't talking about what event=20 > package designers should do. Some of it does, but for the=20 > most part, the text talks about what implementors are=20 > required to do. The document *does* have a section that=20 > covers this ground: section 3. >=20 > To that end, I would think we could split this into two=20 > sections. The part dealing with implementation issues would=20 > be a new section 3.5; the other would form an introduction to=20 > the existing section 10.9. >=20 > Incorporating the other suggestions made so far, then, I=20 > would propose the following sections for the INFO document: >=20 > > 3.5. Rate and Size of INFO Requests > > > > INFO messages differ from many other sorts of SIP messages in > > that they carry application information, and the size and rate > > of the INFO message is directly determined by the application. > > This can cause application information traffic to interfere > > with other traffic on that infrastructure, or to self-interfere > > when data rates become too high. > > > > Implementors need to consider the impact that the size and the > > rate of the INFO messages have on the network and on other > > traffic, since it normally cannot be ensured that INFO messages > > will be carried over a congestion-controlled transport protocol > > end-to-end. Even if an INFO message is sent over such a > > transport protocol, a downstream SIP entity might forward the > > message over a transport protocol that does not provide > > congestion control. > > > > Therefore, an application SHOULD generally have at most one > > outstanding INFO message. Implementors are reminded to observe > > the guidelines in RFC3261 Section 18 regarding the size of SIP > > messages, such as the guideline to not exceed message sizes > > of 1300 bytes when the path MTU is unknown. RFC5405 provides > > additional guidelines for applications using the User Datagram > > Protocol (UDP) that may be useful background reading. > > > > > > > > 10.9 Rate of INFO Requests > > > > A designer of an Info package needs to be mindful of the > > potential congestion impact their application can have on both > > the SIP network and the Internet at large. See section 3.5 > > for a discussion of congestion-related issues. > > > > If there is a maximum or minimum rate at which UAs can send > > INFO requests associated with the Info Package within a dialog, > > the Info Package specification MUST document the rate values. > > > > If the rates can vary, the Info Package specification MAY > > define Info Package parameters that UAs can use to indicate > > or negotiate the rates. Alternatively the rate information > > can be part of the application data information associated > > with the Info Package. >=20 >=20 > Does that sound reasonable? >=20 > /a > = From christer.holmberg@ericsson.com Sun May 16 22:35:21 2010 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 84DDA3A6D13 for ; Sun, 16 May 2010 22:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=-1.953, 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 b3MiZyhhGQLg for ; Sun, 16 May 2010 22:35:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 204063A6D57 for ; Sun, 16 May 2010 22:31:59 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-4d-4bf0d4c6b5f9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C5.B5.21861.6C4D0FB4; Mon, 17 May 2010 07:31:50 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 17 May 2010 07:31:50 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Adam Roach Date: Mon, 17 May 2010 07:31:48 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: Acry0CTXmjhnJTziT1Wmpqip64ed5AANS/awAJ6FVPA= Message-ID: References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@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-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 05:35:21 -0000 Hi, I appologize that it has taken me a while to reply on this issue. I've been= busy with 3GPP the last few weeks. Note that the draft already contains section 7.3, which talks about rate an= d volume. Nobody has commented on that, so I assume it is ok. My suggestion would be to: - Remove section 7.3 - Add new section 7.4.1.2, that talks about rate and volume - New section 7.4.1.2 consists of text from old section 7.3 and the suggest= ed new text for section 10.9. - Keep section 10.9 unchanged (draft version -07) So, new section 7.4.1.2 could look like: "7.4.1.2. INFO Request Rate and Volume INFO messages differ from many other sorts of SIP messages in that they carry application information, and the size and rate of the INFO message is directly determined by the application. This can cause application information traffic to interfere with other traffic on that infrastructure, or to self-interfere when data rates become too high. There is no default throttling mechanism for INFO requests. Apart from the SIP session establishment, the number of SIP messages exchanged during the lifetime a normal SIP session is rather small. Some applications, like sending of DTMF tones, can generate a burst of up to 20 messages per second. Other applications, like constant GPS location updates, could generate a high rate of INFO requests during the lifetime of the invite dialog usage. A designer of an INFO package, and the application that uses it, need to consider the impact that the size and the rate of the INFO messages have on the network and on other traffic, since it normally cannot be ensured that INFO messages will be carried over a congestion-controlled transport protocol end-to-end. Even if an INFO message is sent over a such a transport protocol, a downstream SIP entity might forward the message over a transport protocol that does not provide congestion control. Furthermore, SIP messages tend to be relatively small, on the order of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct exchange of bulk data beyond these limits, especially if the headers plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media plane data transport mechanisms. RFC5405 provides additional guidelines for applications using the=20 User Datagram Protocol (UDP) that may be useful background reading." And, section 10.9 would look like: "10.9. Rate of INFO Requests If there is a maximum or minimum rate at which UAs can send INFO requests associated with the Info Package within a dialog, the Info Package specification MUST document the rate values. If the rates can vary, the Info Package specification MAY define Info Package parameters that UAs can use to indicate or negotiate the rates. Alternatively the rate information can be part of the application data information associated with the Info Package." Would people be ok with that? Regards, Christer =20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 > Sent: 17. toukokuuta 2010 1:03 > To: Adam Roach > Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > Subject: RE: [sipcore] Call for Consensus: INFO Specification=20 > and Congestion >=20 > This proposed paragraph still causes me issues: >=20 > > Therefore, an application SHOULD generally have at most one > > outstanding INFO message. Implementors are reminded to observe > > the guidelines in RFC3261 Section 18 regarding the size of SIP > > messages, such as the guideline to not exceed message sizes > > of 1300 bytes when the path MTU is unknown. RFC5405 provides > > additional guidelines for applications using the User Datagram > > Protocol (UDP) that may be useful background reading. >=20 > I already objected to the first sentence above as I do not=20 > believe it solves the issue, and removes useful capabilities=20 > that may be desired by some applications. I CANNOT accept=20 > this sentence. >=20 > The second sentence above is an inexact extraction, and as=20 > such misleads completely. The correct quote is below: >=20 > If a request is within 200 bytes of the path MTU, or if it=20 > is larger > than 1300 bytes and the path MTU is unknown, the request=20 > MUST be sent > using an RFC 2914 [43] congestion controlled transport=20 > protocol, such > as TCP. If this causes a change in the transport protocol from the > one indicated in the top Via, the value in the top Via MUST be > changed. This prevents fragmentation of messages over UDP and > provides congestion control for larger messages. However, > implementations MUST be able to handle messages up to the maximum > datagram packet size. For UDP, this size is 65,535 bytes,=20 > including > IP and UDP headers. >=20 > Nothing about not exceeding message sizes. Only restriction=20 > is to send using a congestion controlled transport protocol=20 > if it exceeds MTU size. Therefore second sentence as=20 > currently drafted is unacceptable. >=20 >=20 > regards >=20 > Keith > =20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: Thursday, May 13, 2010 8:12 PM > > To: DRAGE, Keith (Keith) > > Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > > Subject: Re: [sipcore] Call for Consensus: INFO Specification and=20 > > Congestion > >=20 > > [as a participant] > >=20 > > Regarding the proposed text that I sent to the mailing list=20 > last week,=20 > > there was an exchange regarding where in the document this behavior=20 > > goes; > >=20 > > On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: > > > ...[T]his text does not belong in section 10, as section 10 > > is about what needs to be documented to define an INFO package, not=20 > > about what the implementor actually needs to do. > > It actually relates to whether it was appropriate to select INFO in=20 > > the first place to do the job, as if the information transfer=20 > > requirements are inappropriate to the underlying transport=20 > > capabilities of SIP, then INFO should not have been selected in the=20 > > first place. > > > =20 > >=20 > > On 5/5/10 8:28 AM, Christer Holmberg responded: > > > So, I guess it should be somewhere in section 7.4. > > > =20 > >=20 > > On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: > > > Yes, but obviously not in the same words. It needs to be > > tailored as do not choose an INFO solution if you need to do this. > > > =20 > >=20 > > I would argue that section 7.3 already goes over this=20 > ground in terms=20 > > of whether INFO is appropriate for a particular use case. And, in=20 > > fact, > > *most* of the proposed text isn't talking about what event package=20 > > designers should do. Some of it does, but for the most=20 > part, the text=20 > > talks about what implementors are required to do. The=20 > document *does*=20 > > have a section that covers this ground: section 3. > >=20 > > To that end, I would think we could split this into two=20 > sections. The=20 > > part dealing with implementation issues would be a new section 3.5;=20 > > the other would form an introduction to the existing section 10.9. > >=20 > > Incorporating the other suggestions made so far, then, I=20 > would propose=20 > > the following sections for the INFO document: > >=20 > > > 3.5. Rate and Size of INFO Requests > > > > > > INFO messages differ from many other sorts of SIP messages in > > > that they carry application information, and the=20 > size and rate > > > of the INFO message is directly determined by the=20 > application. > > > This can cause application information traffic to interfere > > > with other traffic on that infrastructure, or to=20 > self-interfere > > > when data rates become too high. > > > > > > Implementors need to consider the impact that the=20 > size and the > > > rate of the INFO messages have on the network and on other > > > traffic, since it normally cannot be ensured that=20 > INFO messages > > > will be carried over a congestion-controlled=20 > transport protocol > > > end-to-end. Even if an INFO message is sent over such a > > > transport protocol, a downstream SIP entity might forward the > > > message over a transport protocol that does not provide > > > congestion control. > > > > > > Therefore, an application SHOULD generally have at most one > > > outstanding INFO message. Implementors are reminded=20 > to observe > > > the guidelines in RFC3261 Section 18 regarding the=20 > size of SIP > > > messages, such as the guideline to not exceed message sizes > > > of 1300 bytes when the path MTU is unknown. RFC5405 provides > > > additional guidelines for applications using the=20 > User Datagram > > > Protocol (UDP) that may be useful background reading. > > > > > > > > > > > > 10.9 Rate of INFO Requests > > > > > > A designer of an Info package needs to be mindful of the > > > potential congestion impact their application can=20 > have on both > > > the SIP network and the Internet at large. See section 3.5 > > > for a discussion of congestion-related issues. > > > > > > If there is a maximum or minimum rate at which UAs can send > > > INFO requests associated with the Info Package=20 > within a dialog, > > > the Info Package specification MUST document the rate values. > > > > > > If the rates can vary, the Info Package specification MAY > > > define Info Package parameters that UAs can use to indicate > > > or negotiate the rates. Alternatively the rate information > > > can be part of the application data information associated > > > with the Info Package. > >=20 > >=20 > > Does that sound reasonable? > >=20 > > /a > > = From keith.drage@alcatel-lucent.com Mon May 17 02:30:58 2010 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 08A793A67FD for ; Mon, 17 May 2010 02:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-2.184, BAYES_40=-0.185, 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 nWZ6CQbCZv8w for ; Mon, 17 May 2010 02:30:56 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E9CF43A6893 for ; Mon, 17 May 2010 02:28:59 -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.14.3/8.14.3/ICT) with ESMTP id o4H9QDfN007130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 May 2010 11:28:06 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 17 May 2010 11:27:54 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Adam Roach Date: Mon, 17 May 2010 11:27:53 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: Acry0CTXmjhnJTziT1Wmpqip64ed5AANS/awAJ6FVPAACPCgsA== Message-ID: References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@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.64 on 155.132.188.80 Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 09:30:58 -0000 I'm OK with this proposal. Keith=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Monday, May 17, 2010 6:32 AM > To: DRAGE, Keith (Keith); Adam Roach > Cc: Adam Roach; SIPCORE; lars.eggert@nokia.com > Subject: RE: [sipcore] Call for Consensus: INFO Specification=20 > and Congestion >=20 >=20 > Hi, >=20 > I appologize that it has taken me a while to reply on this=20 > issue. I've been busy with 3GPP the last few weeks. >=20 >=20 > Note that the draft already contains section 7.3, which talks=20 > about rate and volume. Nobody has commented on that, so I=20 > assume it is ok. >=20 > My suggestion would be to: >=20 > - Remove section 7.3 > - Add new section 7.4.1.2, that talks about rate and volume > - New section 7.4.1.2 consists of text from old section=20 > 7.3 and the suggested new text for section 10.9. > - Keep section 10.9 unchanged (draft version -07) >=20 > So, new section 7.4.1.2 could look like: >=20 >=20 > "7.4.1.2. INFO Request Rate and Volume >=20 > INFO messages differ from many other sorts of SIP messages in that > they carry application information, and the size and rate of the > INFO message is directly determined by the application. This can > cause application information traffic to interfere with=20 > other traffic > on that infrastructure, or to self-interfere when data rates become > too high. >=20 > There is no default throttling mechanism for INFO requests. Apart > from the SIP session establishment, the number of SIP messages > exchanged during the lifetime a normal SIP session is rather small. >=20 > Some applications, like sending of DTMF tones, can generate a burst > of up to 20 messages per second. Other applications, like constant > GPS location updates, could generate a high rate of INFO requests > during the lifetime of the invite dialog usage. >=20 > A designer of an INFO package, and the application that uses it, > need to consider the impact that the size and the rate of the INFO > messages have on the network and on other traffic, since=20 > it normally > cannot be ensured that INFO messages will be carried over a > congestion-controlled transport protocol end-to-end. Even if an > INFO message is sent over a such a transport protocol, a downstream > SIP entity might forward the message over a transport protocol that > does not provide congestion control. >=20 > Furthermore, SIP messages tend to be relatively small, on the order > of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct > exchange of bulk data beyond these limits, especially if=20 > the headers > plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for > such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media > plane data transport mechanisms. >=20 > RFC5405 provides additional guidelines for applications using the=20 > User Datagram Protocol (UDP) that may be useful background=20 > reading." >=20 > And, section 10.9 would look like: >=20 > "10.9. Rate of INFO Requests >=20 > If there is a maximum or minimum rate at which UAs can send INFO > requests associated with the Info Package within a dialog, the Info > Package specification MUST document the rate values. >=20 > If the rates can vary, the Info Package specification MAY=20 > define Info > Package parameters that UAs can use to indicate or negotiate the > rates. Alternatively the rate information can be part of the > application data information associated with the Info Package." >=20 >=20 > Would people be ok with that? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: 17. toukokuuta 2010 1:03 > > To: Adam Roach > > Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > > Subject: RE: [sipcore] Call for Consensus: INFO Specification and=20 > > Congestion > >=20 > > This proposed paragraph still causes me issues: > >=20 > > > Therefore, an application SHOULD generally have at most one > > > outstanding INFO message. Implementors are reminded=20 > to observe > > > the guidelines in RFC3261 Section 18 regarding the=20 > size of SIP > > > messages, such as the guideline to not exceed message sizes > > > of 1300 bytes when the path MTU is unknown. RFC5405 provides > > > additional guidelines for applications using the=20 > User Datagram > > > Protocol (UDP) that may be useful background reading. > >=20 > > I already objected to the first sentence above as I do not=20 > believe it=20 > > solves the issue, and removes useful capabilities that may=20 > be desired=20 > > by some applications. I CANNOT accept this sentence. > >=20 > > The second sentence above is an inexact extraction, and as such=20 > > misleads completely. The correct quote is below: > >=20 > > If a request is within 200 bytes of the path MTU, or if it is=20 > > larger > > than 1300 bytes and the path MTU is unknown, the request MUST be=20 > > sent > > using an RFC 2914 [43] congestion controlled transport protocol,=20 > > such > > as TCP. If this causes a change in the transport=20 > protocol from the > > one indicated in the top Via, the value in the top Via MUST be > > changed. This prevents fragmentation of messages over UDP and > > provides congestion control for larger messages. However, > > implementations MUST be able to handle messages up to the maximum > > datagram packet size. For UDP, this size is 65,535 bytes,=20 > > including > > IP and UDP headers. > >=20 > > Nothing about not exceeding message sizes. Only restriction=20 > is to send=20 > > using a congestion controlled transport protocol if it exceeds MTU=20 > > size. Therefore second sentence as currently drafted is=20 > unacceptable. > >=20 > >=20 > > regards > >=20 > > Keith > > =20 > >=20 > > > -----Original Message----- > > > From: Adam Roach [mailto:adam@nostrum.com] > > > Sent: Thursday, May 13, 2010 8:12 PM > > > To: DRAGE, Keith (Keith) > > > Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > > > Subject: Re: [sipcore] Call for Consensus: INFO Specification and=20 > > > Congestion > > >=20 > > > [as a participant] > > >=20 > > > Regarding the proposed text that I sent to the mailing list=20 > > last week,=20 > > > there was an exchange regarding where in the document=20 > this behavior=20 > > > goes; > > >=20 > > > On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: > > > > ...[T]his text does not belong in section 10, as section 10 > > > is about what needs to be documented to define an INFO=20 > package, not=20 > > > about what the implementor actually needs to do. > > > It actually relates to whether it was appropriate to=20 > select INFO in=20 > > > the first place to do the job, as if the information transfer=20 > > > requirements are inappropriate to the underlying transport=20 > > > capabilities of SIP, then INFO should not have been=20 > selected in the=20 > > > first place. > > > > =20 > > >=20 > > > On 5/5/10 8:28 AM, Christer Holmberg responded: > > > > So, I guess it should be somewhere in section 7.4. > > > > =20 > > >=20 > > > On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: > > > > Yes, but obviously not in the same words. It needs to be > > > tailored as do not choose an INFO solution if you need to do this. > > > > =20 > > >=20 > > > I would argue that section 7.3 already goes over this=20 > > ground in terms=20 > > > of whether INFO is appropriate for a particular use case. And, in=20 > > > fact, > > > *most* of the proposed text isn't talking about what=20 > event package=20 > > > designers should do. Some of it does, but for the most=20 > > part, the text=20 > > > talks about what implementors are required to do. The=20 > > document *does*=20 > > > have a section that covers this ground: section 3. > > >=20 > > > To that end, I would think we could split this into two=20 > > sections. The=20 > > > part dealing with implementation issues would be a new=20 > section 3.5;=20 > > > the other would form an introduction to the existing section 10.9. > > >=20 > > > Incorporating the other suggestions made so far, then, I=20 > > would propose=20 > > > the following sections for the INFO document: > > >=20 > > > > 3.5. Rate and Size of INFO Requests > > > > > > > > INFO messages differ from many other sorts of SIP=20 > messages in > > > > that they carry application information, and the=20 > > size and rate > > > > of the INFO message is directly determined by the=20 > > application. > > > > This can cause application information traffic to interfere > > > > with other traffic on that infrastructure, or to=20 > > self-interfere > > > > when data rates become too high. > > > > > > > > Implementors need to consider the impact that the=20 > > size and the > > > > rate of the INFO messages have on the network and on other > > > > traffic, since it normally cannot be ensured that=20 > > INFO messages > > > > will be carried over a congestion-controlled=20 > > transport protocol > > > > end-to-end. Even if an INFO message is sent over such a > > > > transport protocol, a downstream SIP entity might=20 > forward the > > > > message over a transport protocol that does not provide > > > > congestion control. > > > > > > > > Therefore, an application SHOULD generally have at most one > > > > outstanding INFO message. Implementors are reminded=20 > > to observe > > > > the guidelines in RFC3261 Section 18 regarding the=20 > > size of SIP > > > > messages, such as the guideline to not exceed message sizes > > > > of 1300 bytes when the path MTU is unknown.=20 > RFC5405 provides > > > > additional guidelines for applications using the=20 > > User Datagram > > > > Protocol (UDP) that may be useful background reading. > > > > > > > > > > > > > > > > 10.9 Rate of INFO Requests > > > > > > > > A designer of an Info package needs to be mindful of the > > > > potential congestion impact their application can=20 > > have on both > > > > the SIP network and the Internet at large. See section 3.5 > > > > for a discussion of congestion-related issues. > > > > > > > > If there is a maximum or minimum rate at which UAs can send > > > > INFO requests associated with the Info Package=20 > > within a dialog, > > > > the Info Package specification MUST document the=20 > rate values. > > > > > > > > If the rates can vary, the Info Package specification MAY > > > > define Info Package parameters that UAs can use to indicate > > > > or negotiate the rates. Alternatively the rate information > > > > can be part of the application data information associated > > > > with the Info Package. > > >=20 > > >=20 > > > Does that sound reasonable? > > >=20 > > > /a > > > = From christer.holmberg@ericsson.com Mon May 17 05:50:03 2010 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 049653A6A2E for ; Mon, 17 May 2010 05:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.94 X-Spam-Level: X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_50=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 AXBlWjrafW8s for ; Mon, 17 May 2010 05:50:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 179F93A6B19 for ; Mon, 17 May 2010 05:47:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-0b-4bf13ac005a4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id ED.CA.08537.0CA31FB4; Mon, 17 May 2010 14:46:56 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 17 May 2010 14:46:56 +0200 From: Christer Holmberg To: Adam Roach Date: Mon, 17 May 2010 14:46:54 +0200 Thread-Topic: [sipcore] SigComp and Service-Route Thread-Index: AcrysaE2ee8BIJ4oSVSBneWIDNTWxQC06WUA Message-ID: References: <4BEC1BBB.4050706@nostrum.com> In-Reply-To: <4BEC1BBB.4050706@nostrum.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SigComp and 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, 17 May 2010 12:50:03 -0000 Hi Adam,=20 >Sorry for the slow response. Some responses inline. >=20 >On 5/6/10 2:51 PM, Christer Holmberg wrote: >>1. How can the UA ensure that the outbound proxy will be=20 >>listed in the Service-Route in the first place? RFC 3608 (Service-Route) = does not=20 >>mandate the registrar to insert any intermediaries in the=20 >>Service-Route, e.g based on Path. It's all based on local policy. =20 >=20 >Service-Route is the means by which the network conveys the=20 >proxies that the UA needs to use when accessing the network.=20 >I think there's an assumption in certain networks -- like IMS=20 >-- that the registrar will, as a matter of policy, copy the=20 >Path into the Service-Route. That is not correct - at least not for IMS. Especially in roaming scenarios, where the P-CSCF (outbound proxy) and S-CS= CF (registrar) are in different networks, no such assumption can be made. =20 >Strictly speaking, though, even that's not necessary for the=20 >UA to ensure traversal of a specific first-hop proxy.=20 >Service-Route specifies a minimal set of proxies to be=20 >traversed, not an exhaustive and restrictive set of proxies.=20 >There is nothing in the Service-Route mechanism that prevents=20 >the UA from inserting a specific outbound proxy in all of its=20 >requests. Correct. An IMS UE for example inserts a P-CSCF (the network may also inser= t IBCFs) in its requests no matter what the Service-Route contains. But, the problem is that the UE would need to get a Service-Route including= the P-CSCF, in order to get the "comp" parameter. >So, trivially, if the UA discovers that a SigComp-supporting=20 >proxy isn't the first hop in the Service-Route returned by=20 >the network, it makes a local decision to send all requests=20 >through one that does. (Recall that support of SigComp by the=20 >first proxy in the Service-Route set can be determined by=20 >casual inspection: if the URL has a ";comp=3Dsigcomp"=20 >parameter, it supports SigComp; otherwise, it does not.) Correct. The problem is that so far the P-CSCF is unable to get ";comp=3Dsi= gcomp" inserted into the Service-Route, since the P-CSCF cannot be sure tha= t the S-CSCF will insert it. >>2. Even if the registrar would build the Service-Route based on Path,=20 >>how does it know that the Path address/port values will be=20 >>usable/routable in the UA-towards-registrar direction (Path is=20 >>supposed to be used in the registrar-towards-UA direction)? This is=20 >>similar to the Record-Route problem, and intermediaries=20 >>with different network addresses/ports per direction would have to insert= =20 >>"double Path". >> =20 >=20 >If this mechanism is used, and if the outbound proxy presents=20 >different address spaces towards the UA than it does towards=20 >the registrar, then the outbound proxy will need to take some=20 >extraordinary measures to ensure that everything works=20 >smoothly. Inserting a "Double-Path" would be one approach. > >>I guess the outbound proxy could insert itself in the Service-Route,=20 >>but that is not described anywhere in RFC 5049, and it is also a=20 >>SHOULD NOT in RFC 3608. >> =20 >=20 >That approach is congruent to the "change the Record-Route"=20 >mechanism that 3261 originally described for multihomed=20 >proxies. If you'll recall, we determined this approach to be=20 >problematic enough that we issued a correction -- RFC5658 --=20 >that basically says "don't do that." >=20 >If you're operating in a network that, as a matter of policy,=20 >reflects the Path back in a Service-Route, then I think the=20 >"Double-Path" approach is really what you want to do for multi-homed=20 >outbound proxies.=20 >And, even if you're not, doing a "Double-Path" doesn't cause=20 >any issues. Yes. The problem is that the registrar would need to know that the P-CSCF (= and and any other intermediate inserting Path) has used "Double-Path", in o= rder to "safely" building the Service-Route based on the path. It may be po= ssible to configure within a single network, but more difficult in roaming = scenarios. Some years ago, Jonathan worked on a draft which was related to this: http://tools.ietf.org/id/draft-rosenberg-sip-route-construct-02.txt He did not have time to continue, and said I could take it over if I want t= o, but I never did it either. Regards, Christer From pkyzivat@cisco.com Mon May 17 07:54:36 2010 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 3C9563A6844 for ; Mon, 17 May 2010 07:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.981 X-Spam-Level: X-Spam-Status: No, score=-9.981 tagged_above=-999 required=5 tests=[AWL=0.618, 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 UyAxr3TrwWNa for ; Mon, 17 May 2010 07:54:34 -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 59B213A6A26 for ; Mon, 17 May 2010 07:54:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGf18EtAZnwM/2dsb2JhbACeAXGhTJk4hRAE X-IronPort-AV: E=Sophos;i="4.53,247,1272844800"; d="scan'208";a="111773765" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 May 2010 14:54:01 +0000 Received: from [10.86.254.114] ([10.86.254.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4HEs0l3008291; Mon, 17 May 2010 14:54:01 GMT Message-ID: <4BF15888.1040905@cisco.com> Date: Mon, 17 May 2010 10:54:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 14:54:36 -0000 Maybe this is moot because Keith has agreed to the latest proposal... I was wondering about your objection to recommending at most one outstanding INFO message - because there are useful things to do with this. In general, having multiple outstanding requests in a dialog is problematic. With retransmission of lost messages this can result in some messages being rejected due to CSeq errors. While this isn't necessarily fatal, and there can be a few cases where this can still have utility, those cases are rare. Thanks, Paul DRAGE, Keith (Keith) wrote: > I'm OK with this proposal. > > Keith > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, May 17, 2010 6:32 AM >> To: DRAGE, Keith (Keith); Adam Roach >> Cc: Adam Roach; SIPCORE; lars.eggert@nokia.com >> Subject: RE: [sipcore] Call for Consensus: INFO Specification >> and Congestion >> >> >> Hi, >> >> I appologize that it has taken me a while to reply on this >> issue. I've been busy with 3GPP the last few weeks. >> >> >> Note that the draft already contains section 7.3, which talks >> about rate and volume. Nobody has commented on that, so I >> assume it is ok. >> >> My suggestion would be to: >> >> - Remove section 7.3 >> - Add new section 7.4.1.2, that talks about rate and volume >> - New section 7.4.1.2 consists of text from old section >> 7.3 and the suggested new text for section 10.9. >> - Keep section 10.9 unchanged (draft version -07) >> >> So, new section 7.4.1.2 could look like: >> >> >> "7.4.1.2. INFO Request Rate and Volume >> >> INFO messages differ from many other sorts of SIP messages in that >> they carry application information, and the size and rate of the >> INFO message is directly determined by the application. This can >> cause application information traffic to interfere with >> other traffic >> on that infrastructure, or to self-interfere when data rates become >> too high. >> >> There is no default throttling mechanism for INFO requests. Apart >> from the SIP session establishment, the number of SIP messages >> exchanged during the lifetime a normal SIP session is rather small. >> >> Some applications, like sending of DTMF tones, can generate a burst >> of up to 20 messages per second. Other applications, like constant >> GPS location updates, could generate a high rate of INFO requests >> during the lifetime of the invite dialog usage. >> >> A designer of an INFO package, and the application that uses it, >> need to consider the impact that the size and the rate of the INFO >> messages have on the network and on other traffic, since >> it normally >> cannot be ensured that INFO messages will be carried over a >> congestion-controlled transport protocol end-to-end. Even if an >> INFO message is sent over a such a transport protocol, a downstream >> SIP entity might forward the message over a transport protocol that >> does not provide congestion control. >> >> Furthermore, SIP messages tend to be relatively small, on the order >> of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct >> exchange of bulk data beyond these limits, especially if >> the headers >> plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for >> such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media >> plane data transport mechanisms. >> >> RFC5405 provides additional guidelines for applications using the >> User Datagram Protocol (UDP) that may be useful background >> reading." >> >> And, section 10.9 would look like: >> >> "10.9. Rate of INFO Requests >> >> If there is a maximum or minimum rate at which UAs can send INFO >> requests associated with the Info Package within a dialog, the Info >> Package specification MUST document the rate values. >> >> If the rates can vary, the Info Package specification MAY >> define Info >> Package parameters that UAs can use to indicate or negotiate the >> rates. Alternatively the rate information can be part of the >> application data information associated with the Info Package." >> >> >> Would people be ok with that? >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> -----Original Message----- >>> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] >>> Sent: 17. toukokuuta 2010 1:03 >>> To: Adam Roach >>> Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com >>> Subject: RE: [sipcore] Call for Consensus: INFO Specification and >>> Congestion >>> >>> This proposed paragraph still causes me issues: >>> >>>> Therefore, an application SHOULD generally have at most one >>>> outstanding INFO message. Implementors are reminded >> to observe >>>> the guidelines in RFC3261 Section 18 regarding the >> size of SIP >>>> messages, such as the guideline to not exceed message sizes >>>> of 1300 bytes when the path MTU is unknown. RFC5405 provides >>>> additional guidelines for applications using the >> User Datagram >>>> Protocol (UDP) that may be useful background reading. >>> I already objected to the first sentence above as I do not >> believe it >>> solves the issue, and removes useful capabilities that may >> be desired >>> by some applications. I CANNOT accept this sentence. >>> >>> The second sentence above is an inexact extraction, and as such >>> misleads completely. The correct quote is below: >>> >>> If a request is within 200 bytes of the path MTU, or if it is >>> larger >>> than 1300 bytes and the path MTU is unknown, the request MUST be >>> sent >>> using an RFC 2914 [43] congestion controlled transport protocol, >>> such >>> as TCP. If this causes a change in the transport >> protocol from the >>> one indicated in the top Via, the value in the top Via MUST be >>> changed. This prevents fragmentation of messages over UDP and >>> provides congestion control for larger messages. However, >>> implementations MUST be able to handle messages up to the maximum >>> datagram packet size. For UDP, this size is 65,535 bytes, >>> including >>> IP and UDP headers. >>> >>> Nothing about not exceeding message sizes. Only restriction >> is to send >>> using a congestion controlled transport protocol if it exceeds MTU >>> size. Therefore second sentence as currently drafted is >> unacceptable. >>> >>> regards >>> >>> Keith >>> >>> >>>> -----Original Message----- >>>> From: Adam Roach [mailto:adam@nostrum.com] >>>> Sent: Thursday, May 13, 2010 8:12 PM >>>> To: DRAGE, Keith (Keith) >>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com >>>> Subject: Re: [sipcore] Call for Consensus: INFO Specification and >>>> Congestion >>>> >>>> [as a participant] >>>> >>>> Regarding the proposed text that I sent to the mailing list >>> last week, >>>> there was an exchange regarding where in the document >> this behavior >>>> goes; >>>> >>>> On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: >>>>> ...[T]his text does not belong in section 10, as section 10 >>>> is about what needs to be documented to define an INFO >> package, not >>>> about what the implementor actually needs to do. >>>> It actually relates to whether it was appropriate to >> select INFO in >>>> the first place to do the job, as if the information transfer >>>> requirements are inappropriate to the underlying transport >>>> capabilities of SIP, then INFO should not have been >> selected in the >>>> first place. >>>>> >>>> On 5/5/10 8:28 AM, Christer Holmberg responded: >>>>> So, I guess it should be somewhere in section 7.4. >>>>> >>>> On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: >>>>> Yes, but obviously not in the same words. It needs to be >>>> tailored as do not choose an INFO solution if you need to do this. >>>>> >>>> I would argue that section 7.3 already goes over this >>> ground in terms >>>> of whether INFO is appropriate for a particular use case. And, in >>>> fact, >>>> *most* of the proposed text isn't talking about what >> event package >>>> designers should do. Some of it does, but for the most >>> part, the text >>>> talks about what implementors are required to do. The >>> document *does* >>>> have a section that covers this ground: section 3. >>>> >>>> To that end, I would think we could split this into two >>> sections. The >>>> part dealing with implementation issues would be a new >> section 3.5; >>>> the other would form an introduction to the existing section 10.9. >>>> >>>> Incorporating the other suggestions made so far, then, I >>> would propose >>>> the following sections for the INFO document: >>>> >>>>> 3.5. Rate and Size of INFO Requests >>>>> >>>>> INFO messages differ from many other sorts of SIP >> messages in >>>>> that they carry application information, and the >>> size and rate >>>>> of the INFO message is directly determined by the >>> application. >>>>> This can cause application information traffic to interfere >>>>> with other traffic on that infrastructure, or to >>> self-interfere >>>>> when data rates become too high. >>>>> >>>>> Implementors need to consider the impact that the >>> size and the >>>>> rate of the INFO messages have on the network and on other >>>>> traffic, since it normally cannot be ensured that >>> INFO messages >>>>> will be carried over a congestion-controlled >>> transport protocol >>>>> end-to-end. Even if an INFO message is sent over such a >>>>> transport protocol, a downstream SIP entity might >> forward the >>>>> message over a transport protocol that does not provide >>>>> congestion control. >>>>> >>>>> Therefore, an application SHOULD generally have at most one >>>>> outstanding INFO message. Implementors are reminded >>> to observe >>>>> the guidelines in RFC3261 Section 18 regarding the >>> size of SIP >>>>> messages, such as the guideline to not exceed message sizes >>>>> of 1300 bytes when the path MTU is unknown. >> RFC5405 provides >>>>> additional guidelines for applications using the >>> User Datagram >>>>> Protocol (UDP) that may be useful background reading. >>>>> >>>>> >>>>> >>>>> 10.9 Rate of INFO Requests >>>>> >>>>> A designer of an Info package needs to be mindful of the >>>>> potential congestion impact their application can >>> have on both >>>>> the SIP network and the Internet at large. See section 3.5 >>>>> for a discussion of congestion-related issues. >>>>> >>>>> If there is a maximum or minimum rate at which UAs can send >>>>> INFO requests associated with the Info Package >>> within a dialog, >>>>> the Info Package specification MUST document the >> rate values. >>>>> If the rates can vary, the Info Package specification MAY >>>>> define Info Package parameters that UAs can use to indicate >>>>> or negotiate the rates. Alternatively the rate information >>>>> can be part of the application data information associated >>>>> with the Info Package. >>>> >>>> Does that sound reasonable? >>>> >>>> /a >>>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From keith.drage@alcatel-lucent.com Mon May 17 13:00:38 2010 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 9E0C23A6AEC for ; Mon, 17 May 2010 13:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.431 X-Spam-Level: X-Spam-Status: No, score=-4.431 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_05=-1.11, 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 1i6tsJ360mUR for ; Mon, 17 May 2010 13:00:37 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id A48E83A6AD4 for ; Mon, 17 May 2010 13:00:35 -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.14.3/8.14.3/ICT) with ESMTP id o4HJxV17017900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 May 2010 21:59:31 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 17 May 2010 21:59:31 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Mon, 17 May 2010 21:59:30 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: Acr10OYwVBkAnaioRwybwLqM56MdqwAKd5PA Message-ID: References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> <4BF15888.1040905@cisco.com> In-Reply-To: <4BF15888.1040905@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 20:00:38 -0000 If the transport protocol is used by the application protocol in a manner t= hat can get messages out of sequence, then the application protocol needs t= o provide its own capabilities to resolve the issue. So yes, when using INFO as a compelled signalling mechanism, it is reliable= . If you do not use it that way, then the application has to put in its own s= equence numbers, or whatever mechanism it so desires, to achieve the same p= urpose. That is of course assuming that the application protocol vulnerable= to dropped or out of sequence messages in the first place.=20 I believe I suggested some time ago on a very early draft that we might wan= t to put something about this in the document, but no one ever took it up. = Too late now. regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, May 17, 2010 3:54 PM > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; Adam Roach; Adam Roach; SIPCORE;=20 > lars.eggert@nokia.com > Subject: Re: [sipcore] Call for Consensus: INFO Specification=20 > and Congestion >=20 > Maybe this is moot because Keith has agreed to the latest proposal... >=20 > I was wondering about your objection to recommending at most=20 > one outstanding INFO message - because there are useful=20 > things to do with this. >=20 > In general, having multiple outstanding requests in a dialog=20 > is problematic. With retransmission of lost messages this can=20 > result in some messages being rejected due to CSeq errors.=20 > While this isn't necessarily fatal, and there can be a few=20 > cases where this can still have utility, those cases are rare. >=20 > Thanks, > Paul >=20 > DRAGE, Keith (Keith) wrote: > > I'm OK with this proposal. > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Monday, May 17, 2010 6:32 AM > >> To: DRAGE, Keith (Keith); Adam Roach > >> Cc: Adam Roach; SIPCORE; lars.eggert@nokia.com > >> Subject: RE: [sipcore] Call for Consensus: INFO Specification and=20 > >> Congestion > >> > >> > >> Hi, > >> > >> I appologize that it has taken me a while to reply on this issue.=20 > >> I've been busy with 3GPP the last few weeks. > >> > >> > >> Note that the draft already contains section 7.3, which=20 > talks about=20 > >> rate and volume. Nobody has commented on that, so I assume=20 > it is ok. > >> > >> My suggestion would be to: > >> > >> - Remove section 7.3 > >> - Add new section 7.4.1.2, that talks about rate and volume > >> - New section 7.4.1.2 consists of text from old section=20 > >> 7.3 and the suggested new text for section 10.9. > >> - Keep section 10.9 unchanged (draft version -07) > >> > >> So, new section 7.4.1.2 could look like: > >> > >> > >> "7.4.1.2. INFO Request Rate and Volume > >> > >> INFO messages differ from many other sorts of SIP=20 > messages in that > >> they carry application information, and the size and rate of the > >> INFO message is directly determined by the application. This can > >> cause application information traffic to interfere with other=20 > >> traffic > >> on that infrastructure, or to self-interfere when data=20 > rates become > >> too high. > >> > >> There is no default throttling mechanism for INFO=20 > requests. Apart > >> from the SIP session establishment, the number of SIP messages > >> exchanged during the lifetime a normal SIP session is=20 > rather small. > >> > >> Some applications, like sending of DTMF tones, can=20 > generate a burst > >> of up to 20 messages per second. Other applications,=20 > like constant > >> GPS location updates, could generate a high rate of=20 > INFO requests > >> during the lifetime of the invite dialog usage. > >> > >> A designer of an INFO package, and the application that uses it, > >> need to consider the impact that the size and the rate=20 > of the INFO > >> messages have on the network and on other traffic, since it=20 > >> normally > >> cannot be ensured that INFO messages will be carried over a > >> congestion-controlled transport protocol end-to-end. Even if an > >> INFO message is sent over a such a transport protocol,=20 > a downstream > >> SIP entity might forward the message over a transport=20 > protocol that > >> does not provide congestion control. > >> > >> Furthermore, SIP messages tend to be relatively small,=20 > on the order > >> of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct > >> exchange of bulk data beyond these limits, especially if the=20 > >> headers > >> plus body exceed the UDP MTU [RFC0768]. Appropriate=20 > mechanisms for > >> such traffic include HTTP [RFC2616], MSRP [RFC4975], or=20 > other media > >> plane data transport mechanisms. > >> > >> RFC5405 provides additional guidelines for applications=20 > using the=20 > >> User Datagram Protocol (UDP) that may be useful background=20 > >> reading." > >> > >> And, section 10.9 would look like: > >> > >> "10.9. Rate of INFO Requests > >> > >> If there is a maximum or minimum rate at which UAs can send INFO > >> requests associated with the Info Package within a=20 > dialog, the Info > >> Package specification MUST document the rate values. > >> > >> If the rates can vary, the Info Package specification=20 > MAY define=20 > >> Info > >> Package parameters that UAs can use to indicate or negotiate the > >> rates. Alternatively the rate information can be part of the > >> application data information associated with the Info Package." > >> > >> > >> Would people be ok with that? > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> =20 > >> > >>> -----Original Message----- > >>> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > >>> Sent: 17. toukokuuta 2010 1:03 > >>> To: Adam Roach > >>> Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > >>> Subject: RE: [sipcore] Call for Consensus: INFO Specification and=20 > >>> Congestion > >>> > >>> This proposed paragraph still causes me issues: > >>> > >>>> Therefore, an application SHOULD generally have at most one > >>>> outstanding INFO message. Implementors are reminded > >> to observe > >>>> the guidelines in RFC3261 Section 18 regarding the > >> size of SIP > >>>> messages, such as the guideline to not exceed message sizes > >>>> of 1300 bytes when the path MTU is unknown. RFC5405 provides > >>>> additional guidelines for applications using the > >> User Datagram > >>>> Protocol (UDP) that may be useful background reading. > >>> I already objected to the first sentence above as I do not > >> believe it > >>> solves the issue, and removes useful capabilities that may > >> be desired > >>> by some applications. I CANNOT accept this sentence. > >>> > >>> The second sentence above is an inexact extraction, and as such=20 > >>> misleads completely. The correct quote is below: > >>> > >>> If a request is within 200 bytes of the path MTU, or if it is=20 > >>> larger > >>> than 1300 bytes and the path MTU is unknown, the=20 > request MUST be=20 > >>> sent > >>> using an RFC 2914 [43] congestion controlled transport=20 > protocol,=20 > >>> such > >>> as TCP. If this causes a change in the transport > >> protocol from the > >>> one indicated in the top Via, the value in the top Via MUST be > >>> changed. This prevents fragmentation of messages over UDP and > >>> provides congestion control for larger messages. However, > >>> implementations MUST be able to handle messages up to=20 > the maximum > >>> datagram packet size. For UDP, this size is 65,535 bytes,=20 > >>> including > >>> IP and UDP headers. > >>> > >>> Nothing about not exceeding message sizes. Only restriction > >> is to send > >>> using a congestion controlled transport protocol if it=20 > exceeds MTU=20 > >>> size. Therefore second sentence as currently drafted is > >> unacceptable. > >>> > >>> regards > >>> > >>> Keith > >>> =20 > >>> > >>>> -----Original Message----- > >>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>> Sent: Thursday, May 13, 2010 8:12 PM > >>>> To: DRAGE, Keith (Keith) > >>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > >>>> Subject: Re: [sipcore] Call for Consensus: INFO=20 > Specification and=20 > >>>> Congestion > >>>> > >>>> [as a participant] > >>>> > >>>> Regarding the proposed text that I sent to the mailing list > >>> last week, > >>>> there was an exchange regarding where in the document > >> this behavior > >>>> goes; > >>>> > >>>> On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: > >>>>> ...[T]his text does not belong in section 10, as section 10 > >>>> is about what needs to be documented to define an INFO > >> package, not > >>>> about what the implementor actually needs to do. > >>>> It actually relates to whether it was appropriate to > >> select INFO in > >>>> the first place to do the job, as if the information transfer=20 > >>>> requirements are inappropriate to the underlying transport=20 > >>>> capabilities of SIP, then INFO should not have been > >> selected in the > >>>> first place. > >>>>> =20 > >>>> On 5/5/10 8:28 AM, Christer Holmberg responded: > >>>>> So, I guess it should be somewhere in section 7.4. > >>>>> =20 > >>>> On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: > >>>>> Yes, but obviously not in the same words. It needs to be > >>>> tailored as do not choose an INFO solution if you need=20 > to do this. > >>>>> =20 > >>>> I would argue that section 7.3 already goes over this > >>> ground in terms > >>>> of whether INFO is appropriate for a particular use=20 > case. And, in=20 > >>>> fact, > >>>> *most* of the proposed text isn't talking about what > >> event package > >>>> designers should do. Some of it does, but for the most > >>> part, the text > >>>> talks about what implementors are required to do. The > >>> document *does* > >>>> have a section that covers this ground: section 3. > >>>> > >>>> To that end, I would think we could split this into two > >>> sections. The > >>>> part dealing with implementation issues would be a new > >> section 3.5; > >>>> the other would form an introduction to the existing=20 > section 10.9. > >>>> > >>>> Incorporating the other suggestions made so far, then, I > >>> would propose > >>>> the following sections for the INFO document: > >>>> > >>>>> 3.5. Rate and Size of INFO Requests > >>>>> > >>>>> INFO messages differ from many other sorts of SIP > >> messages in > >>>>> that they carry application information, and the > >>> size and rate > >>>>> of the INFO message is directly determined by the > >>> application. > >>>>> This can cause application information traffic to interfere > >>>>> with other traffic on that infrastructure, or to > >>> self-interfere > >>>>> when data rates become too high. > >>>>> > >>>>> Implementors need to consider the impact that the > >>> size and the > >>>>> rate of the INFO messages have on the network and on other > >>>>> traffic, since it normally cannot be ensured that > >>> INFO messages > >>>>> will be carried over a congestion-controlled > >>> transport protocol > >>>>> end-to-end. Even if an INFO message is sent over such a > >>>>> transport protocol, a downstream SIP entity might > >> forward the > >>>>> message over a transport protocol that does not provide > >>>>> congestion control. > >>>>> > >>>>> Therefore, an application SHOULD generally have at most one > >>>>> outstanding INFO message. Implementors are reminded > >>> to observe > >>>>> the guidelines in RFC3261 Section 18 regarding the > >>> size of SIP > >>>>> messages, such as the guideline to not exceed message sizes > >>>>> of 1300 bytes when the path MTU is unknown.=20 > >> RFC5405 provides > >>>>> additional guidelines for applications using the > >>> User Datagram > >>>>> Protocol (UDP) that may be useful background reading. > >>>>> > >>>>> > >>>>> > >>>>> 10.9 Rate of INFO Requests > >>>>> > >>>>> A designer of an Info package needs to be mindful of the > >>>>> potential congestion impact their application can > >>> have on both > >>>>> the SIP network and the Internet at large. See section 3.5 > >>>>> for a discussion of congestion-related issues. > >>>>> > >>>>> If there is a maximum or minimum rate at which UAs can send > >>>>> INFO requests associated with the Info Package > >>> within a dialog, > >>>>> the Info Package specification MUST document the > >> rate values. > >>>>> If the rates can vary, the Info Package specification MAY > >>>>> define Info Package parameters that UAs can use to indicate > >>>>> or negotiate the rates. Alternatively the rate information > >>>>> can be part of the application data information associated > >>>>> with the Info Package. > >>>> > >>>> Does that sound reasonable? > >>>> > >>>> /a > >>>> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > = From christer.holmberg@ericsson.com Mon May 17 21:25:16 2010 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 0E0173A6BDE for ; Mon, 17 May 2010 21:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.642, 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 hJYncmbYlgcr for ; Mon, 17 May 2010 21:25:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0E5EC3A6BF4 for ; Mon, 17 May 2010 21:25:09 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-72-4bf2169c66ed Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5F.60.21861.C9612FB4; Tue, 18 May 2010 06:25:00 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 18 May 2010 06:24:59 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 18 May 2010 06:24:59 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Paul Kyzivat Date: Tue, 18 May 2010 06:22:53 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: Acr10OYwVBkAnaioRwybwLqM56MdqwAKd5PAABHBHD4= Message-ID: References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> <4BF15888.1040905@cisco.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-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 04:25:16 -0000 Hi, >If the transport protocol is used by the application protocol in a manner = that can get messages out of sequence, then the application protocol needs = to provide its own capabilities to resolve the issue. > >So yes, when using INFO as a compelled signalling mechanism, it is reliabl= e. > >If you do not use it that way, then the application has to put in its own = sequence numbers, or whatever mechanism it so desires, to achieve the same = purpose. That is of course assuming that the application protocol vulnerabl= e to dropped or out of sequence messages in the=20 >first place. > >I believe I suggested some time ago on a very early draft that we might wa= nt to put something about this in the document, but no one ever took it up.= Too late now. Some text does exist in Section 3.4. Also, I don't believe we had the restriction in the old RFC, so in the even= t that thera are existing implementations sending multiple outstanding INFO= s, I don't want to suddenly make them non-standard compliant. So, Lars, can you live with the text I suggested? :) Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, May 17, 2010 3:54 PM > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; Adam Roach; Adam Roach; SIPCORE; > lars.eggert@nokia.com > Subject: Re: [sipcore] Call for Consensus: INFO Specification > and Congestion > > Maybe this is moot because Keith has agreed to the latest proposal... > > I was wondering about your objection to recommending at most > one outstanding INFO message - because there are useful > things to do with this. > > In general, having multiple outstanding requests in a dialog > is problematic. With retransmission of lost messages this can > result in some messages being rejected due to CSeq errors. > While this isn't necessarily fatal, and there can be a few > cases where this can still have utility, those cases are rare. > > Thanks, > Paul > > DRAGE, Keith (Keith) wrote: > > I'm OK with this proposal. > > > > Keith > > > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Monday, May 17, 2010 6:32 AM > >> To: DRAGE, Keith (Keith); Adam Roach > >> Cc: Adam Roach; SIPCORE; lars.eggert@nokia.com > >> Subject: RE: [sipcore] Call for Consensus: INFO Specification and > >> Congestion > >> > >> > >> Hi, > >> > >> I appologize that it has taken me a while to reply on this issue. > >> I've been busy with 3GPP the last few weeks. > >> > >> > >> Note that the draft already contains section 7.3, which > talks about > >> rate and volume. Nobody has commented on that, so I assume > it is ok. > >> > >> My suggestion would be to: > >> > >> - Remove section 7.3 > >> - Add new section 7.4.1.2, that talks about rate and volume > >> - New section 7.4.1.2 consists of text from old section > >> 7.3 and the suggested new text for section 10.9. > >> - Keep section 10.9 unchanged (draft version -07) > >> > >> So, new section 7.4.1.2 could look like: > >> > >> > >> "7.4.1.2. INFO Request Rate and Volume > >> > >> INFO messages differ from many other sorts of SIP > messages in that > >> they carry application information, and the size and rate of the > >> INFO message is directly determined by the application. This can > >> cause application information traffic to interfere with other > >> traffic > >> on that infrastructure, or to self-interfere when data > rates become > >> too high. > >> > >> There is no default throttling mechanism for INFO > requests. Apart > >> from the SIP session establishment, the number of SIP messages > >> exchanged during the lifetime a normal SIP session is > rather small. > >> > >> Some applications, like sending of DTMF tones, can > generate a burst > >> of up to 20 messages per second. Other applications, > like constant > >> GPS location updates, could generate a high rate of > INFO requests > >> during the lifetime of the invite dialog usage. > >> > >> A designer of an INFO package, and the application that uses it, > >> need to consider the impact that the size and the rate > of the INFO > >> messages have on the network and on other traffic, since it > >> normally > >> cannot be ensured that INFO messages will be carried over a > >> congestion-controlled transport protocol end-to-end. Even if an > >> INFO message is sent over a such a transport protocol, > a downstream > >> SIP entity might forward the message over a transport > protocol that > >> does not provide congestion control. > >> > >> Furthermore, SIP messages tend to be relatively small, > on the order > >> of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct > >> exchange of bulk data beyond these limits, especially if the > >> headers > >> plus body exceed the UDP MTU [RFC0768]. Appropriate > mechanisms for > >> such traffic include HTTP [RFC2616], MSRP [RFC4975], or > other media > >> plane data transport mechanisms. > >> > >> RFC5405 provides additional guidelines for applications > using the > >> User Datagram Protocol (UDP) that may be useful background > >> reading." > >> > >> And, section 10.9 would look like: > >> > >> "10.9. Rate of INFO Requests > >> > >> If there is a maximum or minimum rate at which UAs can send INFO > >> requests associated with the Info Package within a > dialog, the Info > >> Package specification MUST document the rate values. > >> > >> If the rates can vary, the Info Package specification > MAY define > >> Info > >> Package parameters that UAs can use to indicate or negotiate the > >> rates. Alternatively the rate information can be part of the > >> application data information associated with the Info Package." > >> > >> > >> Would people be ok with that? > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > >>> Sent: 17. toukokuuta 2010 1:03 > >>> To: Adam Roach > >>> Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > >>> Subject: RE: [sipcore] Call for Consensus: INFO Specification and > >>> Congestion > >>> > >>> This proposed paragraph still causes me issues: > >>> > >>>> Therefore, an application SHOULD generally have at most one > >>>> outstanding INFO message. Implementors are reminded > >> to observe > >>>> the guidelines in RFC3261 Section 18 regarding the > >> size of SIP > >>>> messages, such as the guideline to not exceed message sizes > >>>> of 1300 bytes when the path MTU is unknown. RFC5405 provides > >>>> additional guidelines for applications using the > >> User Datagram > >>>> Protocol (UDP) that may be useful background reading. > >>> I already objected to the first sentence above as I do not > >> believe it > >>> solves the issue, and removes useful capabilities that may > >> be desired > >>> by some applications. I CANNOT accept this sentence. > >>> > >>> The second sentence above is an inexact extraction, and as such > >>> misleads completely. The correct quote is below: > >>> > >>> If a request is within 200 bytes of the path MTU, or if it is > >>> larger > >>> than 1300 bytes and the path MTU is unknown, the > request MUST be > >>> sent > >>> using an RFC 2914 [43] congestion controlled transport > protocol, > >>> such > >>> as TCP. If this causes a change in the transport > >> protocol from the > >>> one indicated in the top Via, the value in the top Via MUST be > >>> changed. This prevents fragmentation of messages over UDP and > >>> provides congestion control for larger messages. However, > >>> implementations MUST be able to handle messages up to > the maximum > >>> datagram packet size. For UDP, this size is 65,535 bytes, > >>> including > >>> IP and UDP headers. > >>> > >>> Nothing about not exceeding message sizes. Only restriction > >> is to send > >>> using a congestion controlled transport protocol if it > exceeds MTU > >>> size. Therefore second sentence as currently drafted is > >> unacceptable. > >>> > >>> regards > >>> > >>> Keith > >>> > >>> > >>>> -----Original Message----- > >>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>> Sent: Thursday, May 13, 2010 8:12 PM > >>>> To: DRAGE, Keith (Keith) > >>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com > >>>> Subject: Re: [sipcore] Call for Consensus: INFO > Specification and > >>>> Congestion > >>>> > >>>> [as a participant] > >>>> > >>>> Regarding the proposed text that I sent to the mailing list > >>> last week, > >>>> there was an exchange regarding where in the document > >> this behavior > >>>> goes; > >>>> > >>>> On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: > >>>>> ...[T]his text does not belong in section 10, as section 10 > >>>> is about what needs to be documented to define an INFO > >> package, not > >>>> about what the implementor actually needs to do. > >>>> It actually relates to whether it was appropriate to > >> select INFO in > >>>> the first place to do the job, as if the information transfer > >>>> requirements are inappropriate to the underlying transport > >>>> capabilities of SIP, then INFO should not have been > >> selected in the > >>>> first place. > >>>>> > >>>> On 5/5/10 8:28 AM, Christer Holmberg responded: > >>>>> So, I guess it should be somewhere in section 7.4. > >>>>> > >>>> On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: > >>>>> Yes, but obviously not in the same words. It needs to be > >>>> tailored as do not choose an INFO solution if you need > to do this. > >>>>> > >>>> I would argue that section 7.3 already goes over this > >>> ground in terms > >>>> of whether INFO is appropriate for a particular use > case. And, in > >>>> fact, > >>>> *most* of the proposed text isn't talking about what > >> event package > >>>> designers should do. Some of it does, but for the most > >>> part, the text > >>>> talks about what implementors are required to do. The > >>> document *does* > >>>> have a section that covers this ground: section 3. > >>>> > >>>> To that end, I would think we could split this into two > >>> sections. The > >>>> part dealing with implementation issues would be a new > >> section 3.5; > >>>> the other would form an introduction to the existing > section 10.9. > >>>> > >>>> Incorporating the other suggestions made so far, then, I > >>> would propose > >>>> the following sections for the INFO document: > >>>> > >>>>> 3.5. Rate and Size of INFO Requests > >>>>> > >>>>> INFO messages differ from many other sorts of SIP > >> messages in > >>>>> that they carry application information, and the > >>> size and rate > >>>>> of the INFO message is directly determined by the > >>> application. > >>>>> This can cause application information traffic to interfere > >>>>> with other traffic on that infrastructure, or to > >>> self-interfere > >>>>> when data rates become too high. > >>>>> > >>>>> Implementors need to consider the impact that the > >>> size and the > >>>>> rate of the INFO messages have on the network and on other > >>>>> traffic, since it normally cannot be ensured that > >>> INFO messages > >>>>> will be carried over a congestion-controlled > >>> transport protocol > >>>>> end-to-end. Even if an INFO message is sent over such a > >>>>> transport protocol, a downstream SIP entity might > >> forward the > >>>>> message over a transport protocol that does not provide > >>>>> congestion control. > >>>>> > >>>>> Therefore, an application SHOULD generally have at most one > >>>>> outstanding INFO message. Implementors are reminded > >>> to observe > >>>>> the guidelines in RFC3261 Section 18 regarding the > >>> size of SIP > >>>>> messages, such as the guideline to not exceed message sizes > >>>>> of 1300 bytes when the path MTU is unknown. > >> RFC5405 provides > >>>>> additional guidelines for applications using the > >>> User Datagram > >>>>> Protocol (UDP) that may be useful background reading. > >>>>> > >>>>> > >>>>> > >>>>> 10.9 Rate of INFO Requests > >>>>> > >>>>> A designer of an Info package needs to be mindful of the > >>>>> potential congestion impact their application can > >>> have on both > >>>>> the SIP network and the Internet at large. See section 3.5 > >>>>> for a discussion of congestion-related issues. > >>>>> > >>>>> If there is a maximum or minimum rate at which UAs can send > >>>>> INFO requests associated with the Info Package > >>> within a dialog, > >>>>> the Info Package specification MUST document the > >> rate values. > >>>>> If the rates can vary, the Info Package specification MAY > >>>>> define Info Package parameters that UAs can use to indicate > >>>>> or negotiate the rates. Alternatively the rate information > >>>>> can be part of the application data information associated > >>>>> with the Info Package. > >>>> > >>>> Does that sound reasonable? > >>>> > >>>> /a > >>>> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >= From gao.yang2@zte.com.cn Tue May 18 01:27:34 2010 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 9E6783A67E6 for ; Tue, 18 May 2010 01:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.147 X-Spam-Level: X-Spam-Status: No, score=-98.147 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_50=0.001, 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 8PAQCpYxg0Nr for ; Tue, 18 May 2010 01:27:33 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id F1C423A6C58 for ; Tue, 18 May 2010 01:23:21 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Tue, 18 May 2010 16:17:26 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 17030.1727820181; Tue, 18 May 2010 16:18:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4I8KsuW023457 for ; Tue, 18 May 2010 16:20:54 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 18 May 2010 16:17:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-18 16:20:44, Serialize complete at 2010-05-18 16:20:44 Content-Type: multipart/alternative; boundary="=_alternative 002DCE6F48257727_=" X-MAIL: mse2.zte.com.cn o4I8KsuW023457 Subject: [sipcore] Question about P-Associated-URI header's syntax defined in RFC3455 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 May 2010 08:27:34 -0000 This is a multipart message in MIME format. --=_alternative 002DCE6F48257727_= Content-Type: text/plain; charset="US-ASCII" Hi, If people has/have discussed this issue in sip relating WG, sorry for it. Yongping(Yongping Huang) and Jingning(Jingning He) find a inconsistent problem about P-Associated-URI header's syntax defined in RFC3455. By text description in 4.1.2.1 and 4.1.2.2(the highlight part), P-Associated-URI may have zero URI. But refer to the syntax description part in 5.1, it seams the header would have at least one URI. Is this an inconsistent problem? Thanks, Gao //Jingning's correction proposal as: P-Associated-URI = "P-Associated-URI" HCOLON [p-aso-uri-spec *(COMMA p-aso-uri-spec)] or, P-Associated-URI = "P-Associated-URI" HCOLON [p-aso-uri-spec ]*(COMMA p-aso-uri-spec) //Parts of text from RFC3455: 4.1.2.1 Procedures at the UA The header value contains a list of zero or more associated URIs to the address-of-record URI. The UAC MAY use any of the associated URIs to populate the From header value, or any other SIP header value that provides information of the identity of the calling party, in a subsequent request. 4.1.2.2 Procedures at the registrar In case the address-of-record under registration does not have any other SIP or SIPS URIs associated, the registrar MUST include an empty P-Associated-URI header value. 5.1 P-Associated-URI header syntax The syntax of the P-Associated-URI header is described as follows: P-Associated-URI = "P-Associated-URI" HCOLON (p-aso-uri-spec) *(COMMA p-aso-uri-spec) =================================== 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 002DCE6F48257727_= Content-Type: text/html; charset="US-ASCII"
Hi,

If people has/have discussed this issue in sip relating WG, sorry for it.

Yongping(Yongping Huang) and Jingning(Jingning He) find a inconsistent problem about P-Associated-URI header's syntax defined in RFC3455. By text description in 4.1.2.1 and 4.1.2.2(the highlight part), P-Associated-URI may have zero URI. But refer to the syntax description part in 5.1, it seams the header would have at least one URI.

Is this an inconsistent problem?

Thanks,

Gao


//Jingning's correction proposal as:

P-Associated-URI       = "P-Associated-URI" HCOLON
                               [p-aso-uri-spec *(COMMA p-aso-uri-spec)]
or,
                               
P-Associated-URI       = "P-Associated-URI" HCOLON
                               [p-aso-uri-spec ]*(COMMA p-aso-uri-spec)  
   

//Parts of text from RFC3455:

4.1.2.1 Procedures at the UA

   The header value contains a list of zero or more associated URIs to
   the address-of-record URI.  The UAC MAY use any of the associated
   URIs to populate the From header value, or any other SIP header value
   that provides information of the identity of the calling party, in a
   subsequent request.


4.1.2.2 Procedures at the registrar

   In case the address-of-record under registration does not have any
   other SIP or SIPS URIs associated, the registrar MUST include an
   empty P-Associated-URI header value.


5.1 P-Associated-URI header syntax

   The syntax of the P-Associated-URI header is described as follows:

      P-Associated-URI       = "P-Associated-URI" HCOLON
                               (p-aso-uri-spec)
                               *(COMMA p-aso-uri-spec)





===================================
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 002DCE6F48257727_=-- From adam@nostrum.com Tue May 18 06:47:05 2010 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 88DA13A69E2 for ; Tue, 18 May 2010 06:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.311, 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 c62UQOAeVTOq for ; Tue, 18 May 2010 06:47:04 -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 C59973A68A0 for ; Tue, 18 May 2010 06:46:35 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o4IDhugc074833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 08:43:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BF2999C.4030301@nostrum.com> Date: Tue, 18 May 2010 08:43:56 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christer Holmberg References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> <4BF15888.1040905@cisco.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.147.216 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 13:47:05 -0000 [as participant] On 5/17/10 23:22, May 17, Christer Holmberg wrote: > Also, I don't believe we had the restriction in the old RFC, so in the event that thera are existing implementations sending multiple outstanding INFOs, I don't want to suddenly make them non-standard compliant. > They also don't include an Info-Package header field. No matter what you do, RFC 2976 implementations aren't going to be compliant to the new specification. Any arguments about "making RFC 2976 implementations non-compliant" are red herrings. /a From christer.holmberg@ericsson.com Tue May 18 11:41:09 2010 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 2C3763A6A24 for ; Tue, 18 May 2010 11:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=-0.638, 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 J9rvEfsy7IIg for ; Tue, 18 May 2010 11:41:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id EE2663A6C6B for ; Tue, 18 May 2010 11:39:59 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-1d-4bf2def7547a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 17.D9.21861.7FED2FB4; Tue, 18 May 2010 20:39:51 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 18 May 2010 16:00:39 +0200 From: Christer Holmberg To: Adam Roach Date: Tue, 18 May 2010 15:58:25 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: Acr2kaGHv1lnmLZyQTy5lLq/twO7ZQAAI2mX Message-ID: References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> <4BF15888.1040905@cisco.com>, , <4BF2999C.4030301@nostrum.com> In-Reply-To: <4BF2999C.4030301@nostrum.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-Brightmail-Tracker: AAAAAA== Cc: "DRAGE, Keith \(Keith\)" , Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 18:41:09 -0000 Hi, >>Also, I don't believe we had the restriction in the old RFC, so in the ev= ent that thera are existing >>implementations sending multiple outstanding = INFOs, I don't want to suddenly make them non-standard >>compliant. > >They also don't include an Info-Package header field. No matter what you >do, RFC 2976 implementations aren't going to be compliant to the new >specification. Any arguments about "making RFC 2976 implementations >non-compliant" are red herrings. The draft also defines the "legacy INFO usage", which means RFC 2976 implem= entations will continue to be compliant. Anyway, Lars has indicated that he can live with my suggested text, so my i= ntention is to update the draft based on that. Regards, Christer= From gao.yang2@zte.com.cn Tue May 18 19:36:07 2010 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 4CEBC3A6ACE for ; Tue, 18 May 2010 19:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.873 X-Spam-Level: X-Spam-Status: No, score=-97.873 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 TPzsWEcj5Qoz for ; Tue, 18 May 2010 19:36:04 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 525AA3A6ABD for ; Tue, 18 May 2010 19:36:03 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Wed, 19 May 2010 10:30:00 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3015714703; Wed, 19 May 2010 10:35:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4J2ZTbB036884; Wed, 19 May 2010 10:35:29 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 19 May 2010 10:32:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-19 10:35:27, Serialize complete at 2010-05-19 10:35:27 Content-Type: multipart/alternative; boundary="=_alternative 000E30E548257728_=" X-MAIL: mse2.zte.com.cn o4J2ZTbB036884 Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Wed, 19 May 2010 02:36:07 -0000 This is a multipart message in MIME format. --=_alternative 000E30E548257728_= Content-Type: text/plain; charset="US-ASCII" Hi, In the address line of your mail, there's the mail list's address. But your mail is not in the archive. I suggest you chech your internal mail server and request Oscar to check the mail list's server for your e-mail address. Contents inlines. Thanks, Gao > In 4.5. Race Conditions and Target Refreshes, > Additionally, UAs MUST treat > the exchange of a 2xx response to an INVITE request and its > corresponding ACK request as an offer/answer exchange. > > What do above descriptions require to UAS? This requires UAC and UAS (UAs). And the specific demand is to treate such messages as if with O/A. > > >In my understanding, it is crossing case, while not glare one. > > The figure in the previous mail is a glare case of UPDATE. > And the crossing case of UPDATE is shown as below. > > A B > | | > |re-INV (offer1) | > |------------------------------>| > | 18x(answer1)| > |<------------------------------| > | non-2xx| > |<------------------------------| > | | > | /---------->|* > |ACK / | > |-----------------/------------>| > | / | > |UPDATE (offer2)/ | > |--------------/ | > | | > > UAS will not be able to recognize the difference between > the glare case and the crossing case. > Yes, UAS can not recognize the difference. So, this use case has ambiguity, and in UAS's view, this is a glare case. And the UAS would send 491, the session state would be the same in UAC and UAS's view. I'd like to put your glare case further: UAC send UPDATE in scope of Re-INVITE in it's view(before non-2xx of this Re-INVITE). But UAS get the UPDATE after the non-2xx(Re-INVITE)'s ACK. UAC's view: UPDATE is in scope of the Re-INVITE; UAS's view: UPDATE is out scope of the Re-INVITE. For this case, the text suggest UAC send a new Re-INVITE/UPDATE after the 2xx of UPDATE. This is defined in 3.5: If the UAC of a re-INVITE transaction sends an UPDATE request with an offer, receives a non-2xx response to the re-INVITE, and then a 2xx response to the UPDATE request, the UA SHOULD generate a new re- INVITE or UPDATE request in order to make sure that both UAs have a common view of the state of the session, as described in Section 3.4. -------------------------------------------------------- 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 000E30E548257728_= Content-Type: text/html; charset="US-ASCII"
Hi,

In the address line of your mail, there's the mail list's address. But your mail is not in the archive. I suggest you chech your internal mail server and request Oscar to check the mail list's server for your e-mail address.

Contents inlines.

Thanks,

Gao  

> In 4.5.  Race Conditions and Target Refreshes,
>    Additionally, UAs MUST treat
>    the exchange of a 2xx response to an INVITE request and its
>    corresponding ACK request as an offer/answer exchange.
>
> What do above descriptions require to UAS?

This requires UAC and UAS (UAs). And the specific demand is to treate such messages as if with O/A.

>
> >In my understanding, it is crossing case, while not glare one.
>
> The figure in the previous mail is a glare case of UPDATE.
> And the crossing case of UPDATE is shown as below.
>
>     A                               B
>     |                               |
>     |re-INV (offer1)                |
>     |------------------------------>|
>     |                   18x(answer1)|
>     |<------------------------------|
>     |                        non-2xx|
>     |<------------------------------|
>     |                               |
>     |                   /---------->|*
>     |ACK               /            |
>     |-----------------/------------>|
>     |                /              |
>     |UPDATE (offer2)/               |
>     |--------------/                |
>     |                               |
>
> UAS will not be able to recognize the difference between
> the glare case and the crossing case.
>

Yes, UAS can not recognize the difference. So, this use case has ambiguity, and in UAS's view, this is a glare case.
And the UAS would send 491, the session state would be the same in UAC and UAS's view.

I'd like to put your glare case further:

UAC send UPDATE in scope of Re-INVITE in it's view(before non-2xx of this Re-INVITE). But UAS get the UPDATE after the non-2xx(Re-INVITE)'s ACK.
UAC's view: UPDATE is in scope of the Re-INVITE;
UAS's view: UPDATE is out scope of the Re-INVITE.
For this case, the text suggest UAC send a new Re-INVITE/UPDATE after the 2xx of UPDATE. This is defined in 3.5:

If
   the UAC of a re-INVITE transaction sends an UPDATE request with an
   offer, receives a non-2xx response to the re-INVITE, and then a 2xx
   response to the UPDATE request, the UA SHOULD generate a new re-
   INVITE or UPDATE request in order to make sure that both UAs have a
   common view of the state of the session, as described in Section 3.4.
 
--------------------------------------------------------
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 000E30E548257728_=-- From root@core3.amsl.com Wed May 19 01:00:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 151363A6B66; Wed, 19 May 2010 01:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100519080002.151363A6B66@core3.amsl.com> Date: Wed, 19 May 2010 01:00:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-08.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: Wed, 19 May 2010 08:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : C. Holmberg, et al. Filename : draft-ietf-sipcore-info-events-08.txt Pages : 38 Date : 2010-05-19 This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. The document obsoletes RFC 2976. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-info-events-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-19005846.I-D@ietf.org> --NextPart-- From pkyzivat@cisco.com Wed May 19 06:57:51 2010 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 ACD0F3A6B4B for ; Wed, 19 May 2010 06:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.963 X-Spam-Level: X-Spam-Status: No, score=-8.963 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_50=0.001, 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 O8QeuBPW-vAV for ; Wed, 19 May 2010 06:57:49 -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 F0CD13A6994 for ; Wed, 19 May 2010 06:57:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAqL80tAZnwN/2dsb2JhbACeFXGjYZl5hRAE X-IronPort-AV: E=Sophos;i="4.53,263,1272844800"; d="scan'208";a="112669555" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 May 2010 13:57:18 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4JDvDVn016282; Wed, 19 May 2010 13:57:13 GMT Message-ID: <4BF3EE38.30307@cisco.com> Date: Wed, 19 May 2010 09:57:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> <4BF15888.1040905@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 13:57:51 -0000 DRAGE, Keith (Keith) wrote: > If the transport protocol is used by the application protocol in a manner that can get messages out of sequence, then the application protocol needs to provide its own capabilities to resolve the issue. In general there is little/nothing the application can do to ensure that multiple in-flight INFO messages stay in order. Even if TCP is used on every hop, messages may be reordered as they transit a proxy. Hence 500 responses due to the out of order messages may be received. And yes, the application protocol can be designed to function in the face of that. I'm not suggesting that having multiple INFOs outstanding be forbidden - just reminding that there are more problems with using them than simply congestion. > So yes, when using INFO as a compelled signalling mechanism, it is reliable. I don't understand the above. What is a "compelled signalling mechanism"? > If you do not use it that way, then the application has to put in its own sequence numbers, or whatever mechanism it so desires, to achieve the same purpose. That is of course assuming that the application protocol vulnerable to dropped or out of sequence messages in the first place. > > I believe I suggested some time ago on a very early draft that we might want to put something about this in the document, but no one ever took it up. Too late now. As long as we are all on the same page about this I'm satisfied. Thanks, Paul > regards > > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, May 17, 2010 3:54 PM >> To: DRAGE, Keith (Keith) >> Cc: Christer Holmberg; Adam Roach; Adam Roach; SIPCORE; >> lars.eggert@nokia.com >> Subject: Re: [sipcore] Call for Consensus: INFO Specification >> and Congestion >> >> Maybe this is moot because Keith has agreed to the latest proposal... >> >> I was wondering about your objection to recommending at most >> one outstanding INFO message - because there are useful >> things to do with this. >> >> In general, having multiple outstanding requests in a dialog >> is problematic. With retransmission of lost messages this can >> result in some messages being rejected due to CSeq errors. >> While this isn't necessarily fatal, and there can be a few >> cases where this can still have utility, those cases are rare. >> >> Thanks, >> Paul >> >> DRAGE, Keith (Keith) wrote: >>> I'm OK with this proposal. >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Monday, May 17, 2010 6:32 AM >>>> To: DRAGE, Keith (Keith); Adam Roach >>>> Cc: Adam Roach; SIPCORE; lars.eggert@nokia.com >>>> Subject: RE: [sipcore] Call for Consensus: INFO Specification and >>>> Congestion >>>> >>>> >>>> Hi, >>>> >>>> I appologize that it has taken me a while to reply on this issue. >>>> I've been busy with 3GPP the last few weeks. >>>> >>>> >>>> Note that the draft already contains section 7.3, which >> talks about >>>> rate and volume. Nobody has commented on that, so I assume >> it is ok. >>>> My suggestion would be to: >>>> >>>> - Remove section 7.3 >>>> - Add new section 7.4.1.2, that talks about rate and volume >>>> - New section 7.4.1.2 consists of text from old section >>>> 7.3 and the suggested new text for section 10.9. >>>> - Keep section 10.9 unchanged (draft version -07) >>>> >>>> So, new section 7.4.1.2 could look like: >>>> >>>> >>>> "7.4.1.2. INFO Request Rate and Volume >>>> >>>> INFO messages differ from many other sorts of SIP >> messages in that >>>> they carry application information, and the size and rate of the >>>> INFO message is directly determined by the application. This can >>>> cause application information traffic to interfere with other >>>> traffic >>>> on that infrastructure, or to self-interfere when data >> rates become >>>> too high. >>>> >>>> There is no default throttling mechanism for INFO >> requests. Apart >>>> from the SIP session establishment, the number of SIP messages >>>> exchanged during the lifetime a normal SIP session is >> rather small. >>>> Some applications, like sending of DTMF tones, can >> generate a burst >>>> of up to 20 messages per second. Other applications, >> like constant >>>> GPS location updates, could generate a high rate of >> INFO requests >>>> during the lifetime of the invite dialog usage. >>>> >>>> A designer of an INFO package, and the application that uses it, >>>> need to consider the impact that the size and the rate >> of the INFO >>>> messages have on the network and on other traffic, since it >>>> normally >>>> cannot be ensured that INFO messages will be carried over a >>>> congestion-controlled transport protocol end-to-end. Even if an >>>> INFO message is sent over a such a transport protocol, >> a downstream >>>> SIP entity might forward the message over a transport >> protocol that >>>> does not provide congestion control. >>>> >>>> Furthermore, SIP messages tend to be relatively small, >> on the order >>>> of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct >>>> exchange of bulk data beyond these limits, especially if the >>>> headers >>>> plus body exceed the UDP MTU [RFC0768]. Appropriate >> mechanisms for >>>> such traffic include HTTP [RFC2616], MSRP [RFC4975], or >> other media >>>> plane data transport mechanisms. >>>> >>>> RFC5405 provides additional guidelines for applications >> using the >>>> User Datagram Protocol (UDP) that may be useful background >>>> reading." >>>> >>>> And, section 10.9 would look like: >>>> >>>> "10.9. Rate of INFO Requests >>>> >>>> If there is a maximum or minimum rate at which UAs can send INFO >>>> requests associated with the Info Package within a >> dialog, the Info >>>> Package specification MUST document the rate values. >>>> >>>> If the rates can vary, the Info Package specification >> MAY define >>>> Info >>>> Package parameters that UAs can use to indicate or negotiate the >>>> rates. Alternatively the rate information can be part of the >>>> application data information associated with the Info Package." >>>> >>>> >>>> Would people be ok with that? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] >>>>> Sent: 17. toukokuuta 2010 1:03 >>>>> To: Adam Roach >>>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com >>>>> Subject: RE: [sipcore] Call for Consensus: INFO Specification and >>>>> Congestion >>>>> >>>>> This proposed paragraph still causes me issues: >>>>> >>>>>> Therefore, an application SHOULD generally have at most one >>>>>> outstanding INFO message. Implementors are reminded >>>> to observe >>>>>> the guidelines in RFC3261 Section 18 regarding the >>>> size of SIP >>>>>> messages, such as the guideline to not exceed message sizes >>>>>> of 1300 bytes when the path MTU is unknown. RFC5405 provides >>>>>> additional guidelines for applications using the >>>> User Datagram >>>>>> Protocol (UDP) that may be useful background reading. >>>>> I already objected to the first sentence above as I do not >>>> believe it >>>>> solves the issue, and removes useful capabilities that may >>>> be desired >>>>> by some applications. I CANNOT accept this sentence. >>>>> >>>>> The second sentence above is an inexact extraction, and as such >>>>> misleads completely. The correct quote is below: >>>>> >>>>> If a request is within 200 bytes of the path MTU, or if it is >>>>> larger >>>>> than 1300 bytes and the path MTU is unknown, the >> request MUST be >>>>> sent >>>>> using an RFC 2914 [43] congestion controlled transport >> protocol, >>>>> such >>>>> as TCP. If this causes a change in the transport >>>> protocol from the >>>>> one indicated in the top Via, the value in the top Via MUST be >>>>> changed. This prevents fragmentation of messages over UDP and >>>>> provides congestion control for larger messages. However, >>>>> implementations MUST be able to handle messages up to >> the maximum >>>>> datagram packet size. For UDP, this size is 65,535 bytes, >>>>> including >>>>> IP and UDP headers. >>>>> >>>>> Nothing about not exceeding message sizes. Only restriction >>>> is to send >>>>> using a congestion controlled transport protocol if it >> exceeds MTU >>>>> size. Therefore second sentence as currently drafted is >>>> unacceptable. >>>>> regards >>>>> >>>>> Keith >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>> Sent: Thursday, May 13, 2010 8:12 PM >>>>>> To: DRAGE, Keith (Keith) >>>>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; lars.eggert@nokia.com >>>>>> Subject: Re: [sipcore] Call for Consensus: INFO >> Specification and >>>>>> Congestion >>>>>> >>>>>> [as a participant] >>>>>> >>>>>> Regarding the proposed text that I sent to the mailing list >>>>> last week, >>>>>> there was an exchange regarding where in the document >>>> this behavior >>>>>> goes; >>>>>> >>>>>> On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: >>>>>>> ...[T]his text does not belong in section 10, as section 10 >>>>>> is about what needs to be documented to define an INFO >>>> package, not >>>>>> about what the implementor actually needs to do. >>>>>> It actually relates to whether it was appropriate to >>>> select INFO in >>>>>> the first place to do the job, as if the information transfer >>>>>> requirements are inappropriate to the underlying transport >>>>>> capabilities of SIP, then INFO should not have been >>>> selected in the >>>>>> first place. >>>>>>> >>>>>> On 5/5/10 8:28 AM, Christer Holmberg responded: >>>>>>> So, I guess it should be somewhere in section 7.4. >>>>>>> >>>>>> On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: >>>>>>> Yes, but obviously not in the same words. It needs to be >>>>>> tailored as do not choose an INFO solution if you need >> to do this. >>>>>>> >>>>>> I would argue that section 7.3 already goes over this >>>>> ground in terms >>>>>> of whether INFO is appropriate for a particular use >> case. And, in >>>>>> fact, >>>>>> *most* of the proposed text isn't talking about what >>>> event package >>>>>> designers should do. Some of it does, but for the most >>>>> part, the text >>>>>> talks about what implementors are required to do. The >>>>> document *does* >>>>>> have a section that covers this ground: section 3. >>>>>> >>>>>> To that end, I would think we could split this into two >>>>> sections. The >>>>>> part dealing with implementation issues would be a new >>>> section 3.5; >>>>>> the other would form an introduction to the existing >> section 10.9. >>>>>> Incorporating the other suggestions made so far, then, I >>>>> would propose >>>>>> the following sections for the INFO document: >>>>>> >>>>>>> 3.5. Rate and Size of INFO Requests >>>>>>> >>>>>>> INFO messages differ from many other sorts of SIP >>>> messages in >>>>>>> that they carry application information, and the >>>>> size and rate >>>>>>> of the INFO message is directly determined by the >>>>> application. >>>>>>> This can cause application information traffic to interfere >>>>>>> with other traffic on that infrastructure, or to >>>>> self-interfere >>>>>>> when data rates become too high. >>>>>>> >>>>>>> Implementors need to consider the impact that the >>>>> size and the >>>>>>> rate of the INFO messages have on the network and on other >>>>>>> traffic, since it normally cannot be ensured that >>>>> INFO messages >>>>>>> will be carried over a congestion-controlled >>>>> transport protocol >>>>>>> end-to-end. Even if an INFO message is sent over such a >>>>>>> transport protocol, a downstream SIP entity might >>>> forward the >>>>>>> message over a transport protocol that does not provide >>>>>>> congestion control. >>>>>>> >>>>>>> Therefore, an application SHOULD generally have at most one >>>>>>> outstanding INFO message. Implementors are reminded >>>>> to observe >>>>>>> the guidelines in RFC3261 Section 18 regarding the >>>>> size of SIP >>>>>>> messages, such as the guideline to not exceed message sizes >>>>>>> of 1300 bytes when the path MTU is unknown. >>>> RFC5405 provides >>>>>>> additional guidelines for applications using the >>>>> User Datagram >>>>>>> Protocol (UDP) that may be useful background reading. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 10.9 Rate of INFO Requests >>>>>>> >>>>>>> A designer of an Info package needs to be mindful of the >>>>>>> potential congestion impact their application can >>>>> have on both >>>>>>> the SIP network and the Internet at large. See section 3.5 >>>>>>> for a discussion of congestion-related issues. >>>>>>> >>>>>>> If there is a maximum or minimum rate at which UAs can send >>>>>>> INFO requests associated with the Info Package >>>>> within a dialog, >>>>>>> the Info Package specification MUST document the >>>> rate values. >>>>>>> If the rates can vary, the Info Package specification MAY >>>>>>> define Info Package parameters that UAs can use to indicate >>>>>>> or negotiate the rates. Alternatively the rate information >>>>>>> can be part of the application data information associated >>>>>>> with the Info Package. >>>>>> Does that sound reasonable? >>>>>> >>>>>> /a >>>>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> From christer.holmberg@ericsson.com Wed May 19 09:38:32 2010 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 D78D23A6BAE for ; Wed, 19 May 2010 09:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-1.849, 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 LJtEZ8B5j2De for ; Wed, 19 May 2010 09:38:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A0F493A6AD4 for ; Wed, 19 May 2010 09:38:21 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-5e-4bf413f50314 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 87.26.21861.5F314FB4; Wed, 19 May 2010 18:38:13 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 19 May 2010 18:38:12 +0200 From: Christer Holmberg To: SIPCORE Date: Wed, 19 May 2010 18:38:12 +0200 Thread-Topic: Keep forward strategy Thread-Index: AQHK93GrndgmxaDiREC+pnR0pdIA+w== 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Keep forward strategy 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 May 2010 16:38:33 -0000 Hi, I intend to submit a new version of the keep draft soon. My intention is to move back to the Via parameter based solution, based on = comments I've received. That means that the negotiation will be between adjacent nodes (either duri= ng initial dialog request, or when the route set has been established). My intention is also to remove the non-dialog/registration related "ping" u= se-case, as it seems like OPTIONS would be a better candidate for that. Tha= t means that keep-alives negotiated during the registration phase will be s= ent during the lifetime of the registration, and keep-alives negotiated dur= ing a dialog establishement will be sent during the lifetime of the dialog. Some other mechanism will then be used for "pings", which lifetime are not = related to any registration or dialog. Regards, Christer From keith.drage@alcatel-lucent.com Wed May 19 09:54:13 2010 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 4779F3A6B53 for ; Wed, 19 May 2010 09:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.439 X-Spam-Level: X-Spam-Status: No, score=-4.439 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_05=-1.11, 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 bke7d3iWwjiU for ; Wed, 19 May 2010 09:54:11 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 875823A6A4A for ; Wed, 19 May 2010 09:53:59 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4JGqpbS006430 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 May 2010 18:52:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 19 May 2010 18:52:50 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Wed, 19 May 2010 18:52:48 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: Acr3W0ghhuc1MWXrQbOgcYIDvJdMMwAF/8tw Message-ID: References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> <4BF15888.1040905@cisco.com> <4BF3EE38.30307@cisco.com> In-Reply-To: <4BF3EE38.30307@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 16:54:13 -0000 A compelled signalling mechanism is one where you cannot send the next pack= et until you have received the ack to the previous packet, i.e. a window si= ze of one. As such the compelling guarantees the order, and the protocol do= es not need sequence numbers. I believe the term was in use in telecommunic= ation signalling systems that behaved this way. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 19, 2010 2:57 PM > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; Adam Roach; Adam Roach; SIPCORE; > lars.eggert@nokia.com > Subject: Re: [sipcore] Call for Consensus: INFO Specification > and Congestion > > > > DRAGE, Keith (Keith) wrote: > > If the transport protocol is used by the application > protocol in a manner that can get messages out of sequence, > then the application protocol needs to provide its own > capabilities to resolve the issue. > > In general there is little/nothing the application can do to > ensure that > multiple in-flight INFO messages stay in order. Even if TCP > is used on every hop, messages may be reordered as they > transit a proxy. Hence 500 responses due to the out of order > messages may be received. > > And yes, the application protocol can be designed to function > in the face of that. I'm not suggesting that having multiple > INFOs outstanding be forbidden - just reminding that there > are more problems with using them than simply congestion. > > > So yes, when using INFO as a compelled signalling > mechanism, it is reliable. > > I don't understand the above. What is a "compelled signalling > mechanism"? > > > If you do not use it that way, then the application has to > put in its own sequence numbers, or whatever mechanism it so > desires, to achieve the same purpose. That is of course > assuming that the application protocol vulnerable to dropped > or out of sequence messages in the first place. > > > > I believe I suggested some time ago on a very early draft > that we might want to put something about this in the > document, but no one ever took it up. Too late now. > > As long as we are all on the same page about this I'm satisfied. > > Thanks, > Paul > > > regards > > > > Keith > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, May 17, 2010 3:54 PM > >> To: DRAGE, Keith (Keith) > >> Cc: Christer Holmberg; Adam Roach; Adam Roach; SIPCORE; > >> lars.eggert@nokia.com > >> Subject: Re: [sipcore] Call for Consensus: INFO Specification and > >> Congestion > >> > >> Maybe this is moot because Keith has agreed to the latest > proposal... > >> > >> I was wondering about your objection to recommending at most one > >> outstanding INFO message - because there are useful things > to do with > >> this. > >> > >> In general, having multiple outstanding requests in a dialog is > >> problematic. With retransmission of lost messages this can > result in > >> some messages being rejected due to CSeq errors. > >> While this isn't necessarily fatal, and there can be a few cases > >> where this can still have utility, those cases are rare. > >> > >> Thanks, > >> Paul > >> > >> DRAGE, Keith (Keith) wrote: > >>> I'm OK with this proposal. > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>> Sent: Monday, May 17, 2010 6:32 AM > >>>> To: DRAGE, Keith (Keith); Adam Roach > >>>> Cc: Adam Roach; SIPCORE; lars.eggert@nokia.com > >>>> Subject: RE: [sipcore] Call for Consensus: INFO > Specification and > >>>> Congestion > >>>> > >>>> > >>>> Hi, > >>>> > >>>> I appologize that it has taken me a while to reply on > this issue. > >>>> I've been busy with 3GPP the last few weeks. > >>>> > >>>> > >>>> Note that the draft already contains section 7.3, which > >> talks about > >>>> rate and volume. Nobody has commented on that, so I assume > >> it is ok. > >>>> My suggestion would be to: > >>>> > >>>> - Remove section 7.3 > >>>> - Add new section 7.4.1.2, that talks about rate > and volume > >>>> - New section 7.4.1.2 consists of text from old section > >>>> 7.3 and the suggested new text for section 10.9. > >>>> - Keep section 10.9 unchanged (draft version -07) > >>>> > >>>> So, new section 7.4.1.2 could look like: > >>>> > >>>> > >>>> "7.4.1.2. INFO Request Rate and Volume > >>>> > >>>> INFO messages differ from many other sorts of SIP > >> messages in that > >>>> they carry application information, and the size and > rate of the > >>>> INFO message is directly determined by the > application. This can > >>>> cause application information traffic to interfere with other > >>>> traffic > >>>> on that infrastructure, or to self-interfere when data > >> rates become > >>>> too high. > >>>> > >>>> There is no default throttling mechanism for INFO > >> requests. Apart > >>>> from the SIP session establishment, the number of SIP messages > >>>> exchanged during the lifetime a normal SIP session is > >> rather small. > >>>> Some applications, like sending of DTMF tones, can > >> generate a burst > >>>> of up to 20 messages per second. Other applications, > >> like constant > >>>> GPS location updates, could generate a high rate of > >> INFO requests > >>>> during the lifetime of the invite dialog usage. > >>>> > >>>> A designer of an INFO package, and the application > that uses it, > >>>> need to consider the impact that the size and the rate > >> of the INFO > >>>> messages have on the network and on other traffic, since it > >>>> normally > >>>> cannot be ensured that INFO messages will be carried over a > >>>> congestion-controlled transport protocol end-to-end. > Even if an > >>>> INFO message is sent over a such a transport protocol, > >> a downstream > >>>> SIP entity might forward the message over a transport > >> protocol that > >>>> does not provide congestion control. > >>>> > >>>> Furthermore, SIP messages tend to be relatively small, > >> on the order > >>>> of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct > >>>> exchange of bulk data beyond these limits, especially if the > >>>> headers > >>>> plus body exceed the UDP MTU [RFC0768]. Appropriate > >> mechanisms for > >>>> such traffic include HTTP [RFC2616], MSRP [RFC4975], or > >> other media > >>>> plane data transport mechanisms. > >>>> > >>>> RFC5405 provides additional guidelines for applications > >> using the > >>>> User Datagram Protocol (UDP) that may be useful background > >>>> reading." > >>>> > >>>> And, section 10.9 would look like: > >>>> > >>>> "10.9. Rate of INFO Requests > >>>> > >>>> If there is a maximum or minimum rate at which UAs > can send INFO > >>>> requests associated with the Info Package within a > >> dialog, the Info > >>>> Package specification MUST document the rate values. > >>>> > >>>> If the rates can vary, the Info Package specification > >> MAY define > >>>> Info > >>>> Package parameters that UAs can use to indicate or > negotiate the > >>>> rates. Alternatively the rate information can be part of the > >>>> application data information associated with the Info > Package." > >>>> > >>>> > >>>> Would people be ok with that? > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: DRAGE, Keith (Keith) > [mailto:keith.drage@alcatel-lucent.com] > >>>>> Sent: 17. toukokuuta 2010 1:03 > >>>>> To: Adam Roach > >>>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; > lars.eggert@nokia.com > >>>>> Subject: RE: [sipcore] Call for Consensus: INFO > Specification and > >>>>> Congestion > >>>>> > >>>>> This proposed paragraph still causes me issues: > >>>>> > >>>>>> Therefore, an application SHOULD generally have > at most one > >>>>>> outstanding INFO message. Implementors are reminded > >>>> to observe > >>>>>> the guidelines in RFC3261 Section 18 regarding the > >>>> size of SIP > >>>>>> messages, such as the guideline to not exceed > message sizes > >>>>>> of 1300 bytes when the path MTU is unknown. > RFC5405 provides > >>>>>> additional guidelines for applications using the > >>>> User Datagram > >>>>>> Protocol (UDP) that may be useful background reading. > >>>>> I already objected to the first sentence above as I do not > >>>> believe it > >>>>> solves the issue, and removes useful capabilities that may > >>>> be desired > >>>>> by some applications. I CANNOT accept this sentence. > >>>>> > >>>>> The second sentence above is an inexact extraction, and as such > >>>>> misleads completely. The correct quote is below: > >>>>> > >>>>> If a request is within 200 bytes of the path MTU, or > if it is > >>>>> larger > >>>>> than 1300 bytes and the path MTU is unknown, the > >> request MUST be > >>>>> sent > >>>>> using an RFC 2914 [43] congestion controlled transport > >> protocol, > >>>>> such > >>>>> as TCP. If this causes a change in the transport > >>>> protocol from the > >>>>> one indicated in the top Via, the value in the top > Via MUST be > >>>>> changed. This prevents fragmentation of messages > over UDP and > >>>>> provides congestion control for larger messages. However, > >>>>> implementations MUST be able to handle messages up to > >> the maximum > >>>>> datagram packet size. For UDP, this size is 65,535 bytes, > >>>>> including > >>>>> IP and UDP headers. > >>>>> > >>>>> Nothing about not exceeding message sizes. Only restriction > >>>> is to send > >>>>> using a congestion controlled transport protocol if it > >> exceeds MTU > >>>>> size. Therefore second sentence as currently drafted is > >>>> unacceptable. > >>>>> regards > >>>>> > >>>>> Keith > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>>>> Sent: Thursday, May 13, 2010 8:12 PM > >>>>>> To: DRAGE, Keith (Keith) > >>>>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; > lars.eggert@nokia.com > >>>>>> Subject: Re: [sipcore] Call for Consensus: INFO > >> Specification and > >>>>>> Congestion > >>>>>> > >>>>>> [as a participant] > >>>>>> > >>>>>> Regarding the proposed text that I sent to the mailing list > >>>>> last week, > >>>>>> there was an exchange regarding where in the document > >>>> this behavior > >>>>>> goes; > >>>>>> > >>>>>> On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: > >>>>>>> ...[T]his text does not belong in section 10, as section 10 > >>>>>> is about what needs to be documented to define an INFO > >>>> package, not > >>>>>> about what the implementor actually needs to do. > >>>>>> It actually relates to whether it was appropriate to > >>>> select INFO in > >>>>>> the first place to do the job, as if the information transfer > >>>>>> requirements are inappropriate to the underlying transport > >>>>>> capabilities of SIP, then INFO should not have been > >>>> selected in the > >>>>>> first place. > >>>>>>> > >>>>>> On 5/5/10 8:28 AM, Christer Holmberg responded: > >>>>>>> So, I guess it should be somewhere in section 7.4. > >>>>>>> > >>>>>> On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: > >>>>>>> Yes, but obviously not in the same words. It needs to be > >>>>>> tailored as do not choose an INFO solution if you need > >> to do this. > >>>>>>> > >>>>>> I would argue that section 7.3 already goes over this > >>>>> ground in terms > >>>>>> of whether INFO is appropriate for a particular use > >> case. And, in > >>>>>> fact, > >>>>>> *most* of the proposed text isn't talking about what > >>>> event package > >>>>>> designers should do. Some of it does, but for the most > >>>>> part, the text > >>>>>> talks about what implementors are required to do. The > >>>>> document *does* > >>>>>> have a section that covers this ground: section 3. > >>>>>> > >>>>>> To that end, I would think we could split this into two > >>>>> sections. The > >>>>>> part dealing with implementation issues would be a new > >>>> section 3.5; > >>>>>> the other would form an introduction to the existing > >> section 10.9. > >>>>>> Incorporating the other suggestions made so far, then, I > >>>>> would propose > >>>>>> the following sections for the INFO document: > >>>>>> > >>>>>>> 3.5. Rate and Size of INFO Requests > >>>>>>> > >>>>>>> INFO messages differ from many other sorts of SIP > >>>> messages in > >>>>>>> that they carry application information, and the > >>>>> size and rate > >>>>>>> of the INFO message is directly determined by the > >>>>> application. > >>>>>>> This can cause application information traffic > to interfere > >>>>>>> with other traffic on that infrastructure, or to > >>>>> self-interfere > >>>>>>> when data rates become too high. > >>>>>>> > >>>>>>> Implementors need to consider the impact that the > >>>>> size and the > >>>>>>> rate of the INFO messages have on the network > and on other > >>>>>>> traffic, since it normally cannot be ensured that > >>>>> INFO messages > >>>>>>> will be carried over a congestion-controlled > >>>>> transport protocol > >>>>>>> end-to-end. Even if an INFO message is sent over such a > >>>>>>> transport protocol, a downstream SIP entity might > >>>> forward the > >>>>>>> message over a transport protocol that does not provide > >>>>>>> congestion control. > >>>>>>> > >>>>>>> Therefore, an application SHOULD generally have > at most one > >>>>>>> outstanding INFO message. Implementors are reminded > >>>>> to observe > >>>>>>> the guidelines in RFC3261 Section 18 regarding the > >>>>> size of SIP > >>>>>>> messages, such as the guideline to not exceed > message sizes > >>>>>>> of 1300 bytes when the path MTU is unknown. > >>>> RFC5405 provides > >>>>>>> additional guidelines for applications using the > >>>>> User Datagram > >>>>>>> Protocol (UDP) that may be useful background reading. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 10.9 Rate of INFO Requests > >>>>>>> > >>>>>>> A designer of an Info package needs to be mindful of the > >>>>>>> potential congestion impact their application can > >>>>> have on both > >>>>>>> the SIP network and the Internet at large. See > section 3.5 > >>>>>>> for a discussion of congestion-related issues. > >>>>>>> > >>>>>>> If there is a maximum or minimum rate at which > UAs can send > >>>>>>> INFO requests associated with the Info Package > >>>>> within a dialog, > >>>>>>> the Info Package specification MUST document the > >>>> rate values. > >>>>>>> If the rates can vary, the Info Package specification MAY > >>>>>>> define Info Package parameters that UAs can use > to indicate > >>>>>>> or negotiate the rates. Alternatively the rate > information > >>>>>>> can be part of the application data information > associated > >>>>>>> with the Info Package. > >>>>>> Does that sound reasonable? > >>>>>> > >>>>>> /a > >>>>>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > From keith.drage@alcatel-lucent.com Wed May 19 10:22:01 2010 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 A1B833A67CF for ; Wed, 19 May 2010 10:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.19 X-Spam-Level: X-Spam-Status: No, score=-5.19 tagged_above=-999 required=5 tests=[AWL=1.059, 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 X2E4-TUODxwk for ; Wed, 19 May 2010 10:21:59 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 34FD53A67D1 for ; Wed, 19 May 2010 10:21:49 -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.14.3/8.14.3/ICT) with ESMTP id o4JHLAD9015768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 May 2010 19:21:10 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 19 May 2010 19:21:09 +0200 From: "DRAGE, Keith (Keith)" To: "DRAGE, Keith (Keith)" , Paul Kyzivat Date: Wed, 19 May 2010 19:21:07 +0200 Thread-Topic: [sipcore] Call for Consensus: INFO Specification and Congestion Thread-Index: Acr3W0ghhuc1MWXrQbOgcYIDvJdMMwAF/8twAAEHZCA= Message-ID: References: <4BDB52AB.9000507@estacado.net>, <4BEC4EEE.70008@nostrum.com> <4BF15888.1040905@cisco.com> <4BF3EE38.30307@cisco.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.64 on 155.132.188.80 Cc: Adam Roach , SIPCORE , "lars.eggert@nokia.com" Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion 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 May 2010 17:22:01 -0000 Thinking about it a bit more, maybe the term "compelled" was not the best w= ord, as it may imply an element of continued or repeated transmission until= an ack is received, which is certainly not what I meant to occur at the ap= plication level. So I'll stick to the window size of one. In any case I was just explaining what I meant, and none of this needs a re= vision of the text. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Wednesday, May 19, 2010 5:53 PM > To: Paul Kyzivat > Cc: Adam Roach; SIPCORE; lars.eggert@nokia.com > Subject: Re: [sipcore] Call for Consensus: INFO Specification > and Congestion > > A compelled signalling mechanism is one where you cannot send > the next packet until you have received the ack to the > previous packet, i.e. a window size of one. As such the > compelling guarantees the order, and the protocol does not > need sequence numbers. I believe the term was in use in > telecommunication signalling systems that behaved this way. > > Keith > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, May 19, 2010 2:57 PM > > To: DRAGE, Keith (Keith) > > Cc: Christer Holmberg; Adam Roach; Adam Roach; SIPCORE; > > lars.eggert@nokia.com > > Subject: Re: [sipcore] Call for Consensus: INFO Specification and > > Congestion > > > > > > > > DRAGE, Keith (Keith) wrote: > > > If the transport protocol is used by the application > > protocol in a manner that can get messages out of sequence, > then the > > application protocol needs to provide its own capabilities > to resolve > > the issue. > > > > In general there is little/nothing the application can do to ensure > > that > > multiple in-flight INFO messages stay in order. Even if > TCP is used > > on every hop, messages may be reordered as they transit a > proxy. Hence > > 500 responses due to the out of order messages may be received. > > > > And yes, the application protocol can be designed to > function in the > > face of that. I'm not suggesting that having multiple INFOs > > outstanding be forbidden - just reminding that there are > more problems > > with using them than simply congestion. > > > > > So yes, when using INFO as a compelled signalling > > mechanism, it is reliable. > > > > I don't understand the above. What is a "compelled signalling > > mechanism"? > > > > > If you do not use it that way, then the application has to > > put in its own sequence numbers, or whatever mechanism it > so desires, > > to achieve the same purpose. That is of course assuming that the > > application protocol vulnerable to dropped or out of > sequence messages > > in the first place. > > > > > > I believe I suggested some time ago on a very early draft > > that we might want to put something about this in the > document, but no > > one ever took it up. Too late now. > > > > As long as we are all on the same page about this I'm satisfied. > > > > Thanks, > > Paul > > > > > regards > > > > > > Keith > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Monday, May 17, 2010 3:54 PM > > >> To: DRAGE, Keith (Keith) > > >> Cc: Christer Holmberg; Adam Roach; Adam Roach; SIPCORE; > > >> lars.eggert@nokia.com > > >> Subject: Re: [sipcore] Call for Consensus: INFO > Specification and > > >> Congestion > > >> > > >> Maybe this is moot because Keith has agreed to the latest > > proposal... > > >> > > >> I was wondering about your objection to recommending at most one > > >> outstanding INFO message - because there are useful things > > to do with > > >> this. > > >> > > >> In general, having multiple outstanding requests in a dialog is > > >> problematic. With retransmission of lost messages this can > > result in > > >> some messages being rejected due to CSeq errors. > > >> While this isn't necessarily fatal, and there can be a few cases > > >> where this can still have utility, those cases are rare. > > >> > > >> Thanks, > > >> Paul > > >> > > >> DRAGE, Keith (Keith) wrote: > > >>> I'm OK with this proposal. > > >>> > > >>> Keith > > >>> > > >>>> -----Original Message----- > > >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > >>>> Sent: Monday, May 17, 2010 6:32 AM > > >>>> To: DRAGE, Keith (Keith); Adam Roach > > >>>> Cc: Adam Roach; SIPCORE; lars.eggert@nokia.com > > >>>> Subject: RE: [sipcore] Call for Consensus: INFO > > Specification and > > >>>> Congestion > > >>>> > > >>>> > > >>>> Hi, > > >>>> > > >>>> I appologize that it has taken me a while to reply on > > this issue. > > >>>> I've been busy with 3GPP the last few weeks. > > >>>> > > >>>> > > >>>> Note that the draft already contains section 7.3, which > > >> talks about > > >>>> rate and volume. Nobody has commented on that, so I assume > > >> it is ok. > > >>>> My suggestion would be to: > > >>>> > > >>>> - Remove section 7.3 > > >>>> - Add new section 7.4.1.2, that talks about rate > > and volume > > >>>> - New section 7.4.1.2 consists of text from old section > > >>>> 7.3 and the suggested new text for section 10.9. > > >>>> - Keep section 10.9 unchanged (draft version -07) > > >>>> > > >>>> So, new section 7.4.1.2 could look like: > > >>>> > > >>>> > > >>>> "7.4.1.2. INFO Request Rate and Volume > > >>>> > > >>>> INFO messages differ from many other sorts of SIP > > >> messages in that > > >>>> they carry application information, and the size and > > rate of the > > >>>> INFO message is directly determined by the > > application. This can > > >>>> cause application information traffic to interfere > with other > > >>>> traffic > > >>>> on that infrastructure, or to self-interfere when data > > >> rates become > > >>>> too high. > > >>>> > > >>>> There is no default throttling mechanism for INFO > > >> requests. Apart > > >>>> from the SIP session establishment, the number of > SIP messages > > >>>> exchanged during the lifetime a normal SIP session is > > >> rather small. > > >>>> Some applications, like sending of DTMF tones, can > > >> generate a burst > > >>>> of up to 20 messages per second. Other applications, > > >> like constant > > >>>> GPS location updates, could generate a high rate of > > >> INFO requests > > >>>> during the lifetime of the invite dialog usage. > > >>>> > > >>>> A designer of an INFO package, and the application > > that uses it, > > >>>> need to consider the impact that the size and the rate > > >> of the INFO > > >>>> messages have on the network and on other traffic, since it > > >>>> normally > > >>>> cannot be ensured that INFO messages will be carried over a > > >>>> congestion-controlled transport protocol end-to-end. > > Even if an > > >>>> INFO message is sent over a such a transport protocol, > > >> a downstream > > >>>> SIP entity might forward the message over a transport > > >> protocol that > > >>>> does not provide congestion control. > > >>>> > > >>>> Furthermore, SIP messages tend to be relatively small, > > >> on the order > > >>>> of 500 Bytes to 32K Bytes. SIP is a poor mechanism > for direct > > >>>> exchange of bulk data beyond these limits, > especially if the > > >>>> headers > > >>>> plus body exceed the UDP MTU [RFC0768]. Appropriate > > >> mechanisms for > > >>>> such traffic include HTTP [RFC2616], MSRP [RFC4975], or > > >> other media > > >>>> plane data transport mechanisms. > > >>>> > > >>>> RFC5405 provides additional guidelines for applications > > >> using the > > >>>> User Datagram Protocol (UDP) that may be useful background > > >>>> reading." > > >>>> > > >>>> And, section 10.9 would look like: > > >>>> > > >>>> "10.9. Rate of INFO Requests > > >>>> > > >>>> If there is a maximum or minimum rate at which UAs > > can send INFO > > >>>> requests associated with the Info Package within a > > >> dialog, the Info > > >>>> Package specification MUST document the rate values. > > >>>> > > >>>> If the rates can vary, the Info Package specification > > >> MAY define > > >>>> Info > > >>>> Package parameters that UAs can use to indicate or > > negotiate the > > >>>> rates. Alternatively the rate information can be > part of the > > >>>> application data information associated with the Info > > Package." > > >>>> > > >>>> > > >>>> Would people be ok with that? > > >>>> > > >>>> Regards, > > >>>> > > >>>> Christer > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: DRAGE, Keith (Keith) > > [mailto:keith.drage@alcatel-lucent.com] > > >>>>> Sent: 17. toukokuuta 2010 1:03 > > >>>>> To: Adam Roach > > >>>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; > > lars.eggert@nokia.com > > >>>>> Subject: RE: [sipcore] Call for Consensus: INFO > > Specification and > > >>>>> Congestion > > >>>>> > > >>>>> This proposed paragraph still causes me issues: > > >>>>> > > >>>>>> Therefore, an application SHOULD generally have > > at most one > > >>>>>> outstanding INFO message. Implementors are reminded > > >>>> to observe > > >>>>>> the guidelines in RFC3261 Section 18 regarding the > > >>>> size of SIP > > >>>>>> messages, such as the guideline to not exceed > > message sizes > > >>>>>> of 1300 bytes when the path MTU is unknown. > > RFC5405 provides > > >>>>>> additional guidelines for applications using the > > >>>> User Datagram > > >>>>>> Protocol (UDP) that may be useful background reading. > > >>>>> I already objected to the first sentence above as I do not > > >>>> believe it > > >>>>> solves the issue, and removes useful capabilities that may > > >>>> be desired > > >>>>> by some applications. I CANNOT accept this sentence. > > >>>>> > > >>>>> The second sentence above is an inexact extraction, > and as such > > >>>>> misleads completely. The correct quote is below: > > >>>>> > > >>>>> If a request is within 200 bytes of the path MTU, or > > if it is > > >>>>> larger > > >>>>> than 1300 bytes and the path MTU is unknown, the > > >> request MUST be > > >>>>> sent > > >>>>> using an RFC 2914 [43] congestion controlled transport > > >> protocol, > > >>>>> such > > >>>>> as TCP. If this causes a change in the transport > > >>>> protocol from the > > >>>>> one indicated in the top Via, the value in the top > > Via MUST be > > >>>>> changed. This prevents fragmentation of messages > > over UDP and > > >>>>> provides congestion control for larger messages. However, > > >>>>> implementations MUST be able to handle messages up to > > >> the maximum > > >>>>> datagram packet size. For UDP, this size is 65,535 bytes, > > >>>>> including > > >>>>> IP and UDP headers. > > >>>>> > > >>>>> Nothing about not exceeding message sizes. Only restriction > > >>>> is to send > > >>>>> using a congestion controlled transport protocol if it > > >> exceeds MTU > > >>>>> size. Therefore second sentence as currently drafted is > > >>>> unacceptable. > > >>>>> regards > > >>>>> > > >>>>> Keith > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Adam Roach [mailto:adam@nostrum.com] > > >>>>>> Sent: Thursday, May 13, 2010 8:12 PM > > >>>>>> To: DRAGE, Keith (Keith) > > >>>>>> Cc: Christer Holmberg; Adam Roach; SIPCORE; > > lars.eggert@nokia.com > > >>>>>> Subject: Re: [sipcore] Call for Consensus: INFO > > >> Specification and > > >>>>>> Congestion > > >>>>>> > > >>>>>> [as a participant] > > >>>>>> > > >>>>>> Regarding the proposed text that I sent to the mailing list > > >>>>> last week, > > >>>>>> there was an exchange regarding where in the document > > >>>> this behavior > > >>>>>> goes; > > >>>>>> > > >>>>>> On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote: > > >>>>>>> ...[T]his text does not belong in section 10, as section 10 > > >>>>>> is about what needs to be documented to define an INFO > > >>>> package, not > > >>>>>> about what the implementor actually needs to do. > > >>>>>> It actually relates to whether it was appropriate to > > >>>> select INFO in > > >>>>>> the first place to do the job, as if the information > transfer > > >>>>>> requirements are inappropriate to the underlying transport > > >>>>>> capabilities of SIP, then INFO should not have been > > >>>> selected in the > > >>>>>> first place. > > >>>>>>> > > >>>>>> On 5/5/10 8:28 AM, Christer Holmberg responded: > > >>>>>>> So, I guess it should be somewhere in section 7.4. > > >>>>>>> > > >>>>>> On 5/5/10 8:45 AM, DRAGE, Keith (Keith) replied: > > >>>>>>> Yes, but obviously not in the same words. It needs to be > > >>>>>> tailored as do not choose an INFO solution if you need > > >> to do this. > > >>>>>>> > > >>>>>> I would argue that section 7.3 already goes over this > > >>>>> ground in terms > > >>>>>> of whether INFO is appropriate for a particular use > > >> case. And, in > > >>>>>> fact, > > >>>>>> *most* of the proposed text isn't talking about what > > >>>> event package > > >>>>>> designers should do. Some of it does, but for the most > > >>>>> part, the text > > >>>>>> talks about what implementors are required to do. The > > >>>>> document *does* > > >>>>>> have a section that covers this ground: section 3. > > >>>>>> > > >>>>>> To that end, I would think we could split this into two > > >>>>> sections. The > > >>>>>> part dealing with implementation issues would be a new > > >>>> section 3.5; > > >>>>>> the other would form an introduction to the existing > > >> section 10.9. > > >>>>>> Incorporating the other suggestions made so far, then, I > > >>>>> would propose > > >>>>>> the following sections for the INFO document: > > >>>>>> > > >>>>>>> 3.5. Rate and Size of INFO Requests > > >>>>>>> > > >>>>>>> INFO messages differ from many other sorts of SIP > > >>>> messages in > > >>>>>>> that they carry application information, and the > > >>>>> size and rate > > >>>>>>> of the INFO message is directly determined by the > > >>>>> application. > > >>>>>>> This can cause application information traffic > > to interfere > > >>>>>>> with other traffic on that infrastructure, or to > > >>>>> self-interfere > > >>>>>>> when data rates become too high. > > >>>>>>> > > >>>>>>> Implementors need to consider the impact that the > > >>>>> size and the > > >>>>>>> rate of the INFO messages have on the network > > and on other > > >>>>>>> traffic, since it normally cannot be ensured that > > >>>>> INFO messages > > >>>>>>> will be carried over a congestion-controlled > > >>>>> transport protocol > > >>>>>>> end-to-end. Even if an INFO message is sent > over such a > > >>>>>>> transport protocol, a downstream SIP entity might > > >>>> forward the > > >>>>>>> message over a transport protocol that does not provide > > >>>>>>> congestion control. > > >>>>>>> > > >>>>>>> Therefore, an application SHOULD generally have > > at most one > > >>>>>>> outstanding INFO message. Implementors are reminded > > >>>>> to observe > > >>>>>>> the guidelines in RFC3261 Section 18 regarding the > > >>>>> size of SIP > > >>>>>>> messages, such as the guideline to not exceed > > message sizes > > >>>>>>> of 1300 bytes when the path MTU is unknown. > > >>>> RFC5405 provides > > >>>>>>> additional guidelines for applications using the > > >>>>> User Datagram > > >>>>>>> Protocol (UDP) that may be useful background reading. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> 10.9 Rate of INFO Requests > > >>>>>>> > > >>>>>>> A designer of an Info package needs to be > mindful of the > > >>>>>>> potential congestion impact their application can > > >>>>> have on both > > >>>>>>> the SIP network and the Internet at large. See > > section 3.5 > > >>>>>>> for a discussion of congestion-related issues. > > >>>>>>> > > >>>>>>> If there is a maximum or minimum rate at which > > UAs can send > > >>>>>>> INFO requests associated with the Info Package > > >>>>> within a dialog, > > >>>>>>> the Info Package specification MUST document the > > >>>> rate values. > > >>>>>>> If the rates can vary, the Info Package > specification MAY > > >>>>>>> define Info Package parameters that UAs can use > > to indicate > > >>>>>>> or negotiate the rates. Alternatively the rate > > information > > >>>>>>> can be part of the application data information > > associated > > >>>>>>> with the Info Package. > > >>>>>> Does that sound reasonable? > > >>>>>> > > >>>>>> /a > > >>>>>> > > >>> _______________________________________________ > > >>> 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 shinji.okumura@softfront.jp Fri May 21 05:26:35 2010 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 7585C3A6D3F for ; Fri, 21 May 2010 05:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.136 X-Spam-Level: X-Spam-Status: No, score=-95.136 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 sbaYKWFAEvDH for ; Fri, 21 May 2010 05:26:34 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id C28253A6FFE for ; Fri, 21 May 2010 01:02:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 91B98428010; Fri, 21 May 2010 17:02:18 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8-aO3k+wKpS; Fri, 21 May 2010 17:02:13 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id C272B42800F; Fri, 21 May 2010 17:02:12 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 21 May 2010 17:02:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4BEB145B.50702@cisco.com> References: <20100508073002.1CBBE3A68A8@core3.amsl.com> <18CAF1C419F9A7shinji.okumura@softfront.jp> <4BEB145B.50702@cisco.com> Message-Id: <37CAF8BBEA5EA7shinji.okumura@softfront.jp> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Fri, 21 May 2010 12:26:35 -0000 Paul, Paul Kyzivat Wed, 12 May 2010 16:49:31 -0400 >OKUMURA Shinji wrote: >> Hi, >> >> I have one question and one comment about UAC behavior. >> >> question: >> At first, oa status is only audio, and during a next reINVITE >> transaction oa status is changed to audio and video. And then >> UAS sends a 4xx response to the reINVITE. >> In this case which is a new offer UAC should send, only audio >> or both of audio and video with zero port? > >Well, the new o/a is to restate the status quo. >Since the new o/a never succeeded, the status quo includes only one >m-line. So I think it would be acceptable to send an offer with that. > >OTOH, its possible that the other party is confused and thinks there are >two m-lines in effect. It might be further confused to receive another >offer with only one m-line. So it might be prudent to send the new offer >as you suggest. Its legal to do so, and it ought not hurt anything. >(But it might cause trouble if the other UA simply can't handle the >additional m-line. If so it is quite broken.) Since both UAs agreed with two m-lines once, probably it does not cause trouble. Additionally, IMO a sess-version of SDP should be increased too. Regards, Shinji >> comment: >> If already-executed changes is made by only PRACK transaction, >> IMO UAC need not to generate a new offer to synchronize both UAs. > >I don't understand what point you are making, or why. > > Thanks, > Paul > >> Regards, >> Shinji >> >> Internet-Drafts@ietf.org >> Sat, 8 May 2010 00:30:02 -0700 (PDT) >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >>> >>> >>> Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) >>> Author(s) : G. Camarillo, et al. >>> Filename : draft-ietf-sipcore-reinvite-04.txt >>> Pages : 24 >>> Date : 2010-05-08 >>> >>> In this document, we clarify the handling of re-INVITEs in SIP. We >>> clarify in which situations a UAS (User Agent Server) should generate >>> a success response and in which situations a UAS should generate an >>> error response to a re-INVITE. Additionally, we clarify issues >>> related to target-refresh requests. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. From brett@broadsoft.com Fri May 21 12:02:07 2010 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 C8E6F3A6876 for ; Fri, 21 May 2010 12:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.949, 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 zfvuC4uTwrzJ for ; Fri, 21 May 2010 12:02:07 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 7CCEC3A6F2A for ; Fri, 21 May 2010 10:35:35 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 21 May 2010 10:35:29 -0700 From: Brett Tate To: "sipcore@ietf.org" Date: Fri, 21 May 2010 10:34:25 -0700 Thread-Topic: draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQ== Message-ID: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AbzF Al6b B2NW CgvX Dl9w ES87 EsMW GcW8 HZKd H23f IJ7p IviJ JfTv JuFo KXeI KZbL; 1; cwBpAHAAYwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {DCCE5AD3-403A-4081-9BD1-D456D7E29D8D}; YgByAGUAdAB0AEAAYgByAG8AYQBkAHMAbwBmAHQALgBjAG8AbQA=; Fri, 21 May 2010 17:34:25 GMT; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAHMAaQBwAGMAbwByAGUALQByAGUAaQBuAHYAaQB0AGUALQAwADQAOgAgAGcAbABhAHIAZQAgAGEAbgBkACAAVQBQAEQAQQBUAEUAIAB3AGkAdABoAG8AdQB0ACAAUwBEAFAA x-cr-puzzleid: {DCCE5AD3-403A-4081-9BD1-D456D7E29D8D} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 19:02:07 -0000 Howdy, Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate that an UPDATE= without SDP should be treated (from a glare perspective) as though it cont= ained an offer SDP. However I currently find the definition of "glare" and= the expected behavior to be ambiguous. What is the precise meaning of glare? I ask mainly because some vendors se= nd a 491 when an RFC indicates to send a 500. If INVITE contains offer SDP and 18x was not reliable, how SHOULD the calle= d party respond if UPDATE without SDP is received from caller: 491, 500, or= process as though no glare? If INVITE contains offer SDP and 18x was not reliable, how SHOULD the calle= r respond if UPDATE without SDP is received from called party: 491, 500, or= process as though no glare? If caller receives INVITE 2xx without offer/answer, how SHOULD or MUST the = caller respond if UPDATE without SDP is received from called party prior to= sending ACK (if not willing to queue or drop UPDATE): 491 or 500? Is it a= SHOULD or MUST? Thanks, Brett From pkyzivat@cisco.com Fri May 21 12:53:33 2010 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 AFEE63A684B for ; Fri, 21 May 2010 12:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.022 X-Spam-Level: X-Spam-Status: No, score=-9.022 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_40=-0.185, 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 D8Q0GbDnee5T for ; Fri, 21 May 2010 12:53:32 -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 A747528C390 for ; Fri, 21 May 2010 06:26:43 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIsm9ktAZnwN/2dsb2JhbACeIXGkB5lfhRIE X-IronPort-AV: E=Sophos;i="4.53,278,1272844800"; d="scan'208";a="113291308" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 May 2010 13:26:37 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4LDQaZu008343; Fri, 21 May 2010 13:26:37 GMT Message-ID: <4BF68A0C.20204@cisco.com> Date: Fri, 21 May 2010 09:26:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: OKUMURA Shinji References: <20100508073002.1CBBE3A68A8@core3.amsl.com> <18CAF1C419F9A7shinji.okumura@softfront.jp> <4BEB145B.50702@cisco.com> <37CAF8BBEA5EA7shinji.okumura@softfront.jp> In-Reply-To: <37CAF8BBEA5EA7shinji.okumura@softfront.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Fri, 21 May 2010 19:53:33 -0000 Shinji, OKUMURA Shinji wrote: > Paul, > > Paul Kyzivat > Wed, 12 May 2010 16:49:31 -0400 >> OKUMURA Shinji wrote: >>> Hi, >>> >>> I have one question and one comment about UAC behavior. >>> >>> question: >>> At first, oa status is only audio, and during a next reINVITE >>> transaction oa status is changed to audio and video. And then >>> UAS sends a 4xx response to the reINVITE. >>> In this case which is a new offer UAC should send, only audio >>> or both of audio and video with zero port? >> Well, the new o/a is to restate the status quo. >> Since the new o/a never succeeded, the status quo includes only one >> m-line. So I think it would be acceptable to send an offer with that. >> >> OTOH, its possible that the other party is confused and thinks there are >> two m-lines in effect. It might be further confused to receive another >> offer with only one m-line. So it might be prudent to send the new offer >> as you suggest. Its legal to do so, and it ought not hurt anything. >> (But it might cause trouble if the other UA simply can't handle the >> additional m-line. If so it is quite broken.) > > Since both UAs agreed with two m-lines once, probably it does > not cause trouble. It would be good to explain the reasoning. > Additionally, IMO a sess-version of SDP should be increased too. Some problem cases would be the following: A B M1 | reINVITE SDP1,V=a | |---------------------->| M2 | 180rel SDP2,V=b | |<----------------------| M3 | PRACK SDP3,V=a+1 | |---------------------->| M4 | 200PRA SDP4,V=b+1 | |<----------------------| M5 | 4xx INVITE | |<----------------------| M6.1 | UPDATE SDP1,V=x | Either this |---------------------->| M6.2 | UPDATE SDP4,V=x | or this |---------------------->| The question above is: should x be 'a', or 'a+2' in M6.*, and does the answer to that matter depending on whether the SDP is SDP1 or SDP5? I think this is moot in most cases because there will be no rejection of the invite after two o/a exchanges. But it can happen, say in case of preconditions that aren't met. In M6.1 I think x should be 'a+2'. Does that seem right to you? I think M6.2 is not recommended. If it occurs, then again I think x should be a+2. A B M1 | reINVITE SDP1,V=a | |---------------------->| M2 | 180rel SDP2,V=b | |<----------------------| M5 | 4xx INVITE | |<----------------------| M6.1 | UPDATE SDP1,V=x | Either this |---------------------->| M6.2 | UPDATE SDP4,V=x | or this |---------------------->| In this simpler case, for M6.1 x='a' should be fine and prudent, because somebody *might* complain if the get two successive SDPs that are identical except for the version. IMO the SDP version is untrustworthy and probably ought to be ignored, but it seems that some do check it, depend upon it, and get upset if it doesn't behave as they expect.) Thanks, Paul > Regards, > Shinji > >>> comment: >>> If already-executed changes is made by only PRACK transaction, >>> IMO UAC need not to generate a new offer to synchronize both UAs. >> I don't understand what point you are making, or why. >> >> Thanks, >> Paul >> >>> Regards, >>> Shinji >>> >>> Internet-Drafts@ietf.org >>> Sat, 8 May 2010 00:30:02 -0700 (PDT) >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >>>> >>>> >>>> Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) >>>> Author(s) : G. Camarillo, et al. >>>> Filename : draft-ietf-sipcore-reinvite-04.txt >>>> Pages : 24 >>>> Date : 2010-05-08 >>>> >>>> In this document, we clarify the handling of re-INVITEs in SIP. We >>>> clarify in which situations a UAS (User Agent Server) should generate >>>> a success response and in which situations a UAS should generate an >>>> error response to a re-INVITE. Additionally, we clarify issues >>>> related to target-refresh requests. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. > From shinji.okumura@softfront.jp Fri May 21 13:38:16 2010 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 8A0003A7093 for ; Fri, 21 May 2010 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.668 X-Spam-Level: X-Spam-Status: No, score=-94.668 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_32=0.6, RELAY_IS_221=2.222, 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 VeUL7A3gjI4f for ; Fri, 21 May 2010 13:37:34 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id BA98A3A7EAA for ; Fri, 21 May 2010 05:52:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id A164842800F for ; Fri, 21 May 2010 21:51:58 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR9Wl5y6spC9 for ; Fri, 21 May 2010 21:51:53 +0900 (JST) Received: from softfront.jp (112.136.13.156.er.eaccess.ne.jp [112.136.13.156]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 36785428010 for ; Fri, 21 May 2010 21:51:53 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 21 May 2010 21:52:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: References: Message-Id: Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Fri, 21 May 2010 20:38:37 -0000 Gao, gao.yang2@zte.com.cn Thu, 13 May 2010 18:08:15 +0800 >Hi Shinji, > >UA A MUST finish the first Re-INVITE before the second Re-INVITE. So, >there's no ambiguity here. The UA B can handle the Re-INVITE OK. In 4.5. Race Conditions and Target Refreshes, Additionally, UAs MUST treat the exchange of a 2xx response to an INVITE request and its corresponding ACK request as an offer/answer exchange. What do above descriptions require to UAS? Should UAS reject a UPDATE received between 2xx response to an INVITE request and its corresponding ACK or not??? >In my understanding, it is crossing case, while not glare one. The figure in the previous mail is a glare case of UPDATE. A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x(answer1)| |<------------------------------| s1| non-2xx|s1 | /---------------|<-+ |UPD / |s0| reject UPDATE |=============/================>|* | | / 491(UPD)| | |<==========/===================| | | / | | |<--------/ | | s0|ACK ACK | | |------------> ---------->|<-+ | | And the crossing case of UPDATE is shown as below. A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x(answer1)| |<------------------------------| s1| non-2xx|s1 |<------------------------------| s0| |s0 | /---------->|* |ACK / ACK | |----------> / --------->| | / | |UPDATE (offer2)/ | |--------------/ | | | UAS will not be able to recognize the difference between the glare case and the crossing case. Regards, Shinji >Though it is not normative, but I'd like to distinguish the two: > >Glare case: there's ambiguity. >Crossing case: there's no ambiguity, but message is interlaced from the >normal sequence. > >Thanks, > >Gao > >=================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn >=================================== > >OKUMURA Shinji >2010-05-13 17:35 > >Gao, > >IIUC you means that UAS treats a 4xx to INVITE as an offer and >an ACK as an answer. > >Well, > > A B > | | > |re-INV (offer1) | > |------------------------------>| > | 18x(answer1)| > |<------------------------------| > | non-2xx| > |<------------------------------| > | | > | /---------->|* > |ACK / | > |-----------------/------------>| > | / | > |re-INV (offer2)/ | > |--------------/ | > | | > >In an above Figure, what is a response code to the 2nd >re-INVITE? >Or if UA B received the 2nd re-INIVTE before non-2xx, >what is a response code to it? > >gao.yang2@zte.com.cn >Thu, 13 May 2010 14:00:16 +0800 >>Hi Shinji, >> >>There's precondition for the text you mentioned: >> >>When checking for glare situations, UAs MUST treat the exchange of a >> non-2xx final response to a re-INVITE and its corresponding ACK >> request as an offer/answer exchange. Consequently, the rules >> regarding glare situations applicable to offer/answer exchanges are >> also applicable to those exchanges. These rules imply that if the >> UAS of a re-INVITE transaction receives and UPDATE request with an >> offer after having sent a non-2xx final response to the re-INVITE but >> before having received the corresponding ACK request, the UA SHOULD >> return a 491 (Request Pending) response to the UPDATE request. >> >>With the precondition defined here, the UAS(of Re-INVITE) MUST think it >>has sended a Offer after it send the non-2xx. >> >>Before the UAS get the ACK, it get a new Offer in UPDATE, it SHOULD send >>4xx. >> >>There's normative definition here. > >Is that "normative definition" defined in this draft? > >Regards, >Shinji > > >>Thanks, >> >>Gao >> >>=================================== >> Zip : 210012 >> Tel : 87211 >> Tel2 :(+86)-025-52877211 >> e_mail : gao.yang2@zte.com.cn >>=================================== >> >>OKUMURA Shinji >> >>Hi, >> >>In this text, >> >>3.5. Glare Situations >> These rules imply that if the >> UAS of a re-INVITE transaction receives and UPDATE request with an >> offer after having sent a non-2xx final response to the re-INVITE but >> before having received the corresponding ACK request, the UA SHOULD >> return a 491 (Request Pending) response to the UPDATE request. >> >>that is shown in a Figure below. >> >> A B >> | | >> |re-INV (offer1) | >> |------------------------------>| >> | 18x(answer1)| >> |<------------------------------| >> | non-2xx| >> | /---------------|<-+ >> |UPD / | | reject UPDATE >> |=============/================>|* | >> | / 491(UPD)| | >> |<==========/===================| | >> | / | | >> |<--------/ | | >> |ACK | | >> |------------------------------>|<-+ >> | | >> >>Regarding 491 and 500 response, there are some descriptions in RFC3261 >>and RFC3311. But in these text, an interworking of INVITE and UPDATE >>is not clear. >> >>IMO when the directions of the both request are corresponding, >>the response code seems to be 500. And if the directions are not >>corresponding, the response code seems to be 491. >> >>Therefore in this case, I think a UAS should return a 500 response to >>an UPDATE request. >> >>Regards, >>Shinji >> >>Internet-Drafts@ietf.org >>Sat, 8 May 2010 00:30:02 -0700 (PDT) >>>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >>> >>> >>> Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) >>> Author(s) : G. Camarillo, et al. >>> Filename : draft-ietf-sipcore-reinvite-04.txt >>> Pages : 24 >>> Date : 2010-05-08 >>> >>>In this document, we clarify the handling of re-INVITEs in SIP. We >>>clarify in which situations a UAS (User Agent Server) should generate >>>a success response and in which situations a UAS should generate an >>>error response to a re-INVITE. Additionally, we clarify issues >>>related to target-refresh requests. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. From shinji.okumura@softfront.jp Fri May 21 20:35:08 2010 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 695843A6B11 for ; Fri, 21 May 2010 20:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.038 X-Spam-Level: X-Spam-Status: No, score=-95.038 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_57=0.6, RELAY_IS_221=2.222, 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 wpf1Es6gkmZO for ; Fri, 21 May 2010 20:35:07 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 1FFF63A6B1E for ; Fri, 21 May 2010 20:35:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 85A92428012 for ; Sat, 22 May 2010 12:34:56 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj2ReDYm-nx3 for ; Sat, 22 May 2010 12:34:51 +0900 (JST) Received: from softfront.jp (112.136.13.156.er.eaccess.ne.jp [112.136.13.156]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 19BBF42800F for ; Sat, 22 May 2010 12:34:51 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Sat, 22 May 2010 12:34:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: <20100508073002.1CBBE3A68A8@core3.amsl.com> References: <20100508073002.1CBBE3A68A8@core3.amsl.com> Message-Id: Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Sat, 22 May 2010 03:35:08 -0000 Hi all, In 3.5. Glare Situations, | These rules imply that if the | UAS of a re-INVITE transaction receives and UPDATE request with an | offer after having sent a non-2xx final response to the re-INVITE but | before having received the corresponding ACK request, the UA SHOULD | return a 491 (Request Pending) response to the UPDATE request. There are two variants, shown in Figure 1 and 2 below. A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x(answer1)| |<------------------------------| s1| non-2xx|s1 | /---------------|<-+ |UPD(offer2) / |s0| reject UPDATE |=============/================>|* | | / 491(UPD)| | |<==========/===================| | | / ACK | | |<--------/ ---------->|<-+ s0|ACK | |-----------> | | | Figure 1 A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x(answer1)| |<------------------------------| s1| non-2xx|s1 |<------------------------------|<-+ s0|ACK |s0| |-----------> | | |UPD(offer0) | | |==============================>|* | reject UPDATE | 491(UPD)| | |<==============================| | | ACK | | | ---------->|<-+ | | Figure 2 And there is another variant of Figure 1, shown in Figure 3 below. A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x(answer1)| |<------------------------------| s1| non-2xx|s1 | /-------------|<-+ | / ACK |s0| reject UPDATE | / ---------->|<-+ |UPD(offer2) / | |=============/================>| | / 200(UPD)| |<==========/===================| s2| / |s2 |<--------/ | s0|ACK | |-----------> | | | Figure 3 In Figure 1, even if UAS reject the UPDATE, UAC send new UPDATE to synchronize a common view in the current rules(Section 3.4). In Figure 2, if UAS reject the UPDATE, it fails to synchronize a common view. In Figure 3, this rule is useless. After all I think "UAS SHOULD return a 491 between non-2xx and ACK" is unnecessary. That is, UAS may return 2xx to this UPDATE. And, in Figure 1 and 2, the common view of both UAs has already been synchronized. UAC need not to send an UPDATE request to synchronize. IMO, If O/A exchange succeeds by the use of UPDATE before 4xx to INVITE, or UAC has sent UPDATE before 4xx and received 2xx to the UPDATE after 4xx, then UAC should sent new offer to synchronize. Regards, Shinji Internet-Drafts@ietf.org Sat, 8 May 2010 00:30:02 -0700 (PDT) >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > > Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-sipcore-reinvite-04.txt > Pages : 24 > Date : 2010-05-08 > >In this document, we clarify the handling of re-INVITEs in SIP. We >clarify in which situations a UAS (User Agent Server) should generate >a success response and in which situations a UAS should generate an >error response to a re-INVITE. Additionally, we clarify issues >related to target-refresh requests. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. From shinji.okumura@softfront.jp Fri May 21 22:49:54 2010 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 DBBC43A6B8F for ; Fri, 21 May 2010 22:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.453 X-Spam-Level: X-Spam-Status: No, score=-96.453 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 XhANAAXJVi0l for ; Fri, 21 May 2010 22:49:52 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 8B1703A6B95 for ; Fri, 21 May 2010 22:49:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id D279A428011; Sat, 22 May 2010 14:49:39 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiTxVmZAkW3D; Sat, 22 May 2010 14:49:36 +0900 (JST) Received: from softfront.jp (112.136.13.156.er.eaccess.ne.jp [112.136.13.156]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 6801742800F; Sat, 22 May 2010 14:49:35 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Sat, 22 May 2010 14:49:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: <4BF68A0C.20204@cisco.com> References: <18CAF1C419F9A7shinji.okumura@softfront.jp> <4BEB145B.50702@cisco.com> <37CAF8BBEA5EA7shinji.okumura@softfront.jp> <4BF68A0C.20204@cisco.com> Message-Id: <17CAF9728F1F1Fshinji.okumura@softfront.jp> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Sat, 22 May 2010 05:49:54 -0000 Paul, >Shinji, > >OKUMURA Shinji wrote: >> Paul, >> >> Paul Kyzivat >> Wed, 12 May 2010 16:49:31 -0400 >>> OKUMURA Shinji wrote: >>>> Hi, >>>> >>>> I have one question and one comment about UAC behavior. >>>> >>>> question: >>>> At first, oa status is only audio, and during a next reINVITE >>>> transaction oa status is changed to audio and video. And then >>>> UAS sends a 4xx response to the reINVITE. >>>> In this case which is a new offer UAC should send, only audio >>>> or both of audio and video with zero port? >>> Well, the new o/a is to restate the status quo. >>> Since the new o/a never succeeded, the status quo includes only one >>> m-line. So I think it would be acceptable to send an offer with that. >>> >>> OTOH, its possible that the other party is confused and thinks there are >>> two m-lines in effect. It might be further confused to receive another >>> offer with only one m-line. So it might be prudent to send the new offer >>> as you suggest. Its legal to do so, and it ought not hurt anything. >>> (But it might cause trouble if the other UA simply can't handle the >>> additional m-line. If so it is quite broken.) >> >> Since both UAs agreed with two m-lines once, probably it does >> not cause trouble. > >It would be good to explain the reasoning. > >> Additionally, IMO a sess-version of SDP should be increased too. > >Some problem cases would be the following: > > A B > M1 | reINVITE SDP1,V=a | > |---------------------->| > M2 | 180rel SDP2,V=b | > |<----------------------| > M3 | PRACK SDP3,V=a+1 | > |---------------------->| > M4 | 200PRA SDP4,V=b+1 | > |<----------------------| > M5 | 4xx INVITE | > |<----------------------| > M6.1 | UPDATE SDP1,V=x | Either this > |---------------------->| > M6.2 | UPDATE SDP4,V=x | or this > |---------------------->| Perhaps does you mean M6.2 is "UPDATE SDP5"? >The question above is: should x be 'a', or 'a+2' in M6.*, and does the >answer to that matter depending on whether the SDP is SDP1 or SDP5? I think x should be a+2, and SDP5 should be based on SDP4. >I think this is moot in most cases because there will be no rejection of >the invite after two o/a exchanges. But it can happen, say in case of >preconditions that aren't met. I agree. this is unclear, but UAC should prepare for it as described in this draft. In the following case, A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x(answer1)| |<------------------------------| s1| non-2xx|s1 | /-------------|<-+ | / ACK |s0| reject UPDATE | / ---------->|<-+ |UPD(offer2) / | |=============/================>| | / 200(UPD)| |<==========/===================| s2| / |s2 |<--------/ | s0|ACK | |-----------> | | | s0: only audio s1: audio and video s2: audio and video and fax UA-B recognizes that the current status is s2. UA-A should send a SDP that is considered reasonable and proper by UA-B. That is, x is a+2 and m-lines is 3. Certainly video and fax are "zero port". IMO universal rules should be able to support the most complex cases. >In M6.1 I think x should be 'a+2'. Does that seem right to you? >I think M6.2 is not recommended. If it occurs, then again I think x >should be a+2. > > A B > M1 | reINVITE SDP1,V=a | > |---------------------->| > M2 | 180rel SDP2,V=b | > |<----------------------| > M5 | 4xx INVITE | > |<----------------------| > M6.1 | UPDATE SDP1,V=x | Either this > |---------------------->| > M6.2 | UPDATE SDP4,V=x | or this > |---------------------->| > I assume that PRACK transaction is not shown but exists. >In this simpler case, for M6.1 x='a' should be fine and prudent, >because somebody *might* complain if the get two successive SDPs that >are identical except for the version. On the contrary, somebody might complain about a "decrement" of the sess-version. At least an increment is not against a rule. I think x should be a+1 and SDP should be based on SDP2. Regards, Shinji >IMO the SDP version is untrustworthy and probably ought to be ignored, >but it seems that some do check it, depend upon it, and get upset if it >doesn't behave as they expect.) > Thanks, > Paul > > >> Regards, >> Shinji >> >>>> comment: >>>> If already-executed changes is made by only PRACK transaction, >>>> IMO UAC need not to generate a new offer to synchronize both UAs. >>> I don't understand what point you are making, or why. >>> >>> Thanks, >>> Paul >>> >>>> Regards, >>>> Shinji >>>> >>>> Internet-Drafts@ietf.org >>>> Sat, 8 May 2010 00:30:02 -0700 (PDT) >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> This draft is a work item of the Session Initiation Protocol Core Working Group of >>>>> the IETF. >>>>> >>>>> >>>>> Title : Re-INVITE and Target-refresh Request Handling in the Session >>>>> Initiation Protocol (SIP) >>>>> Author(s) : G. Camarillo, et al. >>>>> Filename : draft-ietf-sipcore-reinvite-04.txt >>>>> Pages : 24 >>>>> Date : 2010-05-08 >>>>> >>>>> In this document, we clarify the handling of re-INVITEs in SIP. We >>>>> clarify in which situations a UAS (User Agent Server) should generate >>>>> a success response and in which situations a UAS should generate an >>>>> error response to a re-INVITE. Additionally, we clarify issues >>>>> related to target-refresh requests. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. From shinji.okumura@softfront.jp Sat May 22 01:17:46 2010 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 339723A6BF7 for ; Sat, 22 May 2010 01:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.625 X-Spam-Level: X-Spam-Status: No, score=-95.625 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 65gymO1mT9qU for ; Sat, 22 May 2010 01:17:45 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id E22B23A6BD1 for ; Sat, 22 May 2010 01:17:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 29609428011; Sat, 22 May 2010 17:17:36 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KjyQDz6GzTD; Sat, 22 May 2010 17:17:33 +0900 (JST) Received: from softfront.jp (112.136.13.156.er.eaccess.ne.jp [112.136.13.156]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 33BD842800F; Sat, 22 May 2010 17:17:33 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Sat, 22 May 2010 17:17:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> Message-Id: <70CAF9873ACDA5shinji.okumura@softfront.jp> Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 22 May 2010 08:17:46 -0000 Hi Brett, I have a similar question too. RFC 3261 and 3311 describe the definition regarding 500 and 491 response. When UA rejects the INVITE during an INVITE transaction, or rejects the UPDATE during an UPDATE transaction, it has nothing to do with offer-answer which error code to be used. If both transaction have the same direction, the error code is 500. If not, the error code is 491. But an interworking of INVITE and UPDATE is unclear. The draft-offeranswer makes an efforts to clarify it in the section 4.3. >Howdy, > >Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate >that an UPDATE without SDP should be treated (from a glare >perspective) as though it contained an offer SDP. >However I currently find the definition of "glare" and the >expected behavior to be ambiguous. > >What is the precise meaning of glare? I ask mainly because >some vendors send a 491 when an RFC indicates to send a 500. > >If INVITE contains offer SDP and 18x was not reliable, how >SHOULD the called party respond if UPDATE without SDP is >received from caller: 491, 500, or process as though no glare? If UA must refuse it , parhaps it is 500. IMO it is another question whether UA must reject the UPDATE without an offer. >If INVITE contains offer SDP and 18x was not reliable, how >SHOULD the caller respond if UPDATE without SDP is received >from called party: 491, 500, or process as though no glare? Parhaps it is 491. >If caller receives INVITE 2xx without offer/answer, how SHOULD >or MUST the caller respond if UPDATE without SDP is received >from called party prior to sending ACK (if not willing to >queue or drop UPDATE): 491 or 500? Is it a SHOULD or MUST? UA may send 2xx to UPDATE. Because the INVITE transaction has been completed. For reference, the following figures are now under consideration. A B | | |INVITE | |--------------------->|<-+ <-----+ | 1xx(offer or answer)| | | |<---------------------| | reject INVITE | reject UPDATE |PRACK | | Don't send INVITE | Don't send UPDATE |--------------------->| | | | 2xx-PRA| | | |<---------------------| | <-----+ | | | | may send UPDATE | 2xx| | | may accept UPDATE |<---------------------|<-+ | | | | may send INVITE | |ACK | | may accept INVITE | |--------------------->| | | | | v v | | Figure 16 A B | | |INVITE | |--------------------->|<-+ <-----+ | 1xx(offer or answer)| | | |<---------------------| | reject INVITE | reject UPDATE |PRACK | | Don't send INVITE | Don't send UPDATE |--------------------->| | | | 2xx-PRA| | | |<---------------------| | <-----+ | | | | may send UPDATE | 4xx| | | may acceptUPDATE |<---------------------|<-+ | | | | Don't send INVITE | |ACK ACK | | may accept INVITE | <-- Should B reject UPDATE or not? |---------> -------->|<-+ <-----+ That is another question. | | | | | | v v Figure 17 In both figures, UA A reject all INVITE/UPDATE with 491. UA B reject all INVITE/UPDATE with 500. Regards, Shinji From brett@broadsoft.com Sun May 23 10:35:57 2010 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 D18613A6AF3 for ; Sun, 23 May 2010 10:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.838 X-Spam-Level: X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[AWL=-0.839, 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 jpmO1Z85imZa for ; Sun, 23 May 2010 10:35:56 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id AAB8E3A6A81 for ; Sun, 23 May 2010 10:35:56 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Sun, 23 May 2010 10:35:49 -0700 From: Brett Tate To: OKUMURA Shinji , "sipcore@ietf.org" Date: Sun, 23 May 2010 10:34:47 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP Thread-Index: Acr5h0B1IgxLMtX9TpK+lgsEI31aiQBDMWtw Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC21D@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <70CAF9873ACDA5shinji.okumura@softfront.jp> In-Reply-To: <70CAF9873ACDA5shinji.okumura@softfront.jp> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 23 May 2010 17:35:57 -0000 > But an interworking of INVITE and UPDATE is unclear. > The draft-offeranswer makes an efforts to clarify it in the > section 4.3. Thanks for the information. Draft-ietf-sipping-sip-offeranswer needs to be= updated to actually refer to draft-ietf-sipcore-reinvite. > >If INVITE contains offer SDP and 18x was not reliable, how > >SHOULD the called party respond if UPDATE without SDP is > >received from caller: 491, 500, or process as though no glare? >=20 > If UA must refuse it , perhaps it is 500. If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, the foll= owing snippets apply. "When checking for glare situations, UAs MUST treat every UPDATE request as= if it contained an offer." "Similarly, if an UPDATE is received that contains an offer, and the UAS ha= s received an offer (in an UPDATE, PRACK, or INVITE) to which it has not ye= t generated an answer, the UAS MUST reject the UPDATE with a 500 response, = and MUST include a Retry-After header field with a randomly chosen value be= tween 0 and 10 seconds." > IMO it is another question whether UA must reject the UPDATE > without an offer. My current understanding is that it MUST be rejected; see above. > >If INVITE contains offer SDP and 18x was not reliable, how > >SHOULD the caller respond if UPDATE without SDP is received > >from called party: 491, 500, or process as though no glare? >=20 > Perhaps it is 491. If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, the foll= owing snippets apply. "When checking for glare situations, UAs MUST treat every UPDATE request as= if it contained an offer." "If an UPDATE is received that contains an offer, and the UAS has generated= an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received = an answer, the UAS MUST reject the UPDATE with a 491 response." If the calling party supports draft-ietf-sipcore-reinvite but called party = doesn't, this can lead to numerous UPDATE/491 (retry interval 0-2 seconds) = until called party no longer mandated to return 491. > >If caller receives INVITE 2xx without offer/answer, how SHOULD > >or MUST the caller respond if UPDATE without SDP is received > >from called party prior to sending ACK (if not willing to > >queue or drop UPDATE): 491 or 500? Is it a SHOULD or MUST? >=20 > UA may send 2xx to UPDATE. Because the INVITE transaction has > been completed. If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, the foll= owing snippets apply. "When checking for glare situations, UAs MUST treat every UPDATE request as= if it contained an offer. Additionally, UAs MUST treat the exchange of a = 2xx response to an INVITE request and its corresponding ACK request as an o= ffer/answer exchange." "Similarly, if an UPDATE is received that contains an offer, and the UAS ha= s received an offer (in an UPDATE, PRACK, or INVITE) to which it has not ye= t generated an answer, the UAS MUST reject the UPDATE with a 500 response, = and MUST include a Retry-After header field with a randomly chosen value be= tween 0 and 10 seconds." From gao.yang2@zte.com.cn Sun May 23 20:08:44 2010 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 9CA773A6AA2 for ; Sun, 23 May 2010 20:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.658 X-Spam-Level: X-Spam-Status: No, score=-95.658 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 H+I-894vkY1A for ; Sun, 23 May 2010 20:08:43 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 760CB3A67B4 for ; Sun, 23 May 2010 20:08:41 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 24 May 2010 11:03:20 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 13308.3612446977; Mon, 24 May 2010 11:03:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4O37PmU022830; Mon, 24 May 2010 11:07:25 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC21D@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 11:04:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 11:07:16, Serialize complete at 2010-05-24 11:07:16 Content-Type: multipart/alternative; boundary="=_alternative 00111D214825772D_=" X-MAIL: mse2.zte.com.cn o4O37PmU022830 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 24 May 2010 03:08:44 -0000 This is a multipart message in MIME format. --=_alternative 00111D214825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTAtMDUtMjQgMDE6MzQ6NDc6 DQoNCj4gPiBCdXQgYW4gaW50ZXJ3b3JraW5nIG9mIElOVklURSBhbmQgVVBEQVRFIGlzIHVuY2xl YXIuDQo+ID4gVGhlIGRyYWZ0LW9mZmVyYW5zd2VyIG1ha2VzIGFuIGVmZm9ydHMgdG8gY2xhcmlm eSBpdCBpbiB0aGUNCj4gPiBzZWN0aW9uIDQuMy4NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGluZm9y bWF0aW9uLiAgRHJhZnQtaWV0Zi1zaXBwaW5nLXNpcC1vZmZlcmFuc3dlciANCj4gbmVlZHMgdG8g YmUgdXBkYXRlZCB0byBhY3R1YWxseSByZWZlciB0byBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZp dGUuDQo+IA0KPiANCj4gPiA+SWYgSU5WSVRFIGNvbnRhaW5zIG9mZmVyIFNEUCBhbmQgMTh4IHdh cyBub3QgcmVsaWFibGUsIGhvdw0KPiA+ID5TSE9VTEQgdGhlIGNhbGxlZCBwYXJ0eSByZXNwb25k IGlmIFVQREFURSB3aXRob3V0IFNEUCBpcw0KPiA+ID5yZWNlaXZlZCBmcm9tIGNhbGxlcjogNDkx LCA1MDAsIG9yIHByb2Nlc3MgYXMgdGhvdWdoIG5vIGdsYXJlPw0KPiA+IA0KPiA+IElmIFVBIG11 c3QgcmVmdXNlIGl0ICwgcGVyaGFwcyBpdCBpcyA1MDAuDQo+IA0KPiBJZiBJIHVuZGVyc3RhbmQg ZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlIGFuZCBSRkMzMzExIGNvcnJlY3RseSwgDQo+IHRo ZSBmb2xsb3dpbmcgc25pcHBldHMgYXBwbHkuDQo+IA0KPiAiV2hlbiBjaGVja2luZyBmb3IgZ2xh cmUgc2l0dWF0aW9ucywgVUFzIE1VU1QgdHJlYXQgZXZlcnkgVVBEQVRFIA0KPiByZXF1ZXN0IGFz IGlmIGl0IGNvbnRhaW5lZCBhbiBvZmZlci4iDQo+IA0KPiAiU2ltaWxhcmx5LCBpZiBhbiBVUERB VEUgaXMgcmVjZWl2ZWQgdGhhdCBjb250YWlucyBhbiBvZmZlciwgYW5kIHRoZQ0KPiBVQVMgaGFz IHJlY2VpdmVkIGFuIG9mZmVyIChpbiBhbiBVUERBVEUsIFBSQUNLLCBvciBJTlZJVEUpIHRvIHdo aWNoIA0KPiBpdCBoYXMgbm90IHlldCBnZW5lcmF0ZWQgYW4gYW5zd2VyLCB0aGUgVUFTIE1VU1Qg cmVqZWN0IHRoZSBVUERBVEUgDQo+IHdpdGggYSA1MDAgcmVzcG9uc2UsIGFuZCBNVVNUIGluY2x1 ZGUgYSBSZXRyeS1BZnRlciBoZWFkZXIgZmllbGQgDQo+IHdpdGggYSByYW5kb21seSBjaG9zZW4g dmFsdWUgYmV0d2VlbiAwIGFuZCAxMCBzZWNvbmRzLiINCj4gDQo+IA0KPiA+IElNTyBpdCBpcyBh bm90aGVyIHF1ZXN0aW9uIHdoZXRoZXIgVUEgbXVzdCByZWplY3QgdGhlIFVQREFURQ0KPiA+IHdp dGhvdXQgYW4gb2ZmZXIuDQo+IA0KPiBNeSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBp dCBNVVNUIGJlIHJlamVjdGVkOyBzZWUgYWJvdmUuDQo+IA0KPiANCj4gPiA+SWYgSU5WSVRFIGNv bnRhaW5zIG9mZmVyIFNEUCBhbmQgMTh4IHdhcyBub3QgcmVsaWFibGUsIGhvdw0KPiA+ID5TSE9V TEQgdGhlIGNhbGxlciByZXNwb25kIGlmIFVQREFURSB3aXRob3V0IFNEUCBpcyByZWNlaXZlZA0K PiA+ID5mcm9tIGNhbGxlZCBwYXJ0eTogNDkxLCA1MDAsIG9yIHByb2Nlc3MgYXMgdGhvdWdoIG5v IGdsYXJlPw0KPiA+IA0KPiA+IFBlcmhhcHMgaXQgaXMgNDkxLg0KPiANCj4gSWYgSSB1bmRlcnN0 YW5kIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZSBhbmQgUkZDMzMxMSBjb3JyZWN0bHksIA0K PiB0aGUgZm9sbG93aW5nIHNuaXBwZXRzIGFwcGx5Lg0KPiANCj4gIldoZW4gY2hlY2tpbmcgZm9y IGdsYXJlIHNpdHVhdGlvbnMsIFVBcyBNVVNUIHRyZWF0IGV2ZXJ5IFVQREFURSANCj4gcmVxdWVz dCBhcyBpZiBpdCBjb250YWluZWQgYW4gb2ZmZXIuIg0KPiANCj4gIklmIGFuIFVQREFURSBpcyBy ZWNlaXZlZCB0aGF0IGNvbnRhaW5zIGFuIG9mZmVyLCBhbmQgdGhlIFVBUyBoYXMgDQo+IGdlbmVy YXRlZCBhbiBvZmZlciAoaW4gYW4gVVBEQVRFLCBQUkFDSyBvciBJTlZJVEUpIHRvIHdoaWNoIGl0 IGhhcyANCj4gbm90IHlldCByZWNlaXZlZCBhbiBhbnN3ZXIsIHRoZSBVQVMgTVVTVCByZWplY3Qg dGhlIFVQREFURSB3aXRoIGEgDQo+IDQ5MSByZXNwb25zZS4iDQo+IA0KPiBJZiB0aGUgY2FsbGlu ZyBwYXJ0eSBzdXBwb3J0cyBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUgYnV0IGNhbGxlZA0K PiBwYXJ0eSBkb2Vzbid0LCB0aGlzIGNhbiBsZWFkIHRvIG51bWVyb3VzIFVQREFURS80OTEgKHJl dHJ5IGludGVydmFsIA0KPiAwLTIgc2Vjb25kcykgdW50aWwgY2FsbGVkIHBhcnR5IG5vIGxvbmdl ciBtYW5kYXRlZCB0byByZXR1cm4gNDkxLg0KDQogV2hpbGUgVUFTKGFzIHRoaXMgaXMgYWJvdXQg UmUtSU5WSVRFLCBVQVMgY291bGQgYmUgbW9yZSBwcm9wZXIgaGVyZSkgZG9lcyANCm5vdCBzdXBw b3J0IGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZSwgVUFTIG1heSBqdXN0IHNlbmQgMnh4IHRv IFVQREFURS4gDQpBbmQgdGhpcyBtYXkgY2F1c2UgYW1iaWd1b3VzIHNlc3Npb24gc3RhdGUuIElm IFVBQyBzdXBwb3J0IA0KZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLCB0aGUgVUFDIHNob3Vs ZCBzZW5kIGEgbmV3IFJlLUlOVklURS9VUERBVEUgdG8gDQpzeW5jaHJvbml6ZSB0aGUgc2Vzc2lv biBzdGF0ZS4NCklmIGJvdGggb2YgVUFDIGFuZCBVQVMgZG8gbm90IHN1cHBvcnQgZHJhZnQtaWV0 Zi1zaXBjb3JlLXJlaW52aXRlLCB0aGUgDQpzZXNzaW9uIHN0YXRlIHdvdWxkIGJlIGFtYmlndW91 cy4NCg0KSSB0aGluayB0aGUgY2lyY3VsYXRpb24gb2YgVVBEQVRFLzQ5MSB3b3VsZCBoYXBwZW4g aWYgVUFTIHN1cHBvcnQgDQpkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUsIG5vIG1hdHRlciBV QVMgc3VwcG9ydHMgDQpkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUgb3Igbm90LiBBbmQgdGhl IHRpbWVzIG9mIHRoaXMgY2lyY3VsYXRpb24gDQp3b3VsZCBub3QgYmUgbnVtZXJvdXMsIHRoZSBj aXJjdWxhdGlvbiB3b3VsZCBiZSBlbmRlZCBhZnRlciBVQVMgZ2V0cyB0aGUgDQpBQ0sob2YgUmUt SU5WSVRFJ3MgNHh4KS4gDQoNCj4gDQo+IA0KPiA+ID5JZiBjYWxsZXIgcmVjZWl2ZXMgSU5WSVRF IDJ4eCB3aXRob3V0IG9mZmVyL2Fuc3dlciwgaG93IFNIT1VMRA0KPiA+ID5vciBNVVNUIHRoZSBj YWxsZXIgcmVzcG9uZCBpZiBVUERBVEUgd2l0aG91dCBTRFAgaXMgcmVjZWl2ZWQNCj4gPiA+ZnJv bSBjYWxsZWQgcGFydHkgcHJpb3IgdG8gc2VuZGluZyBBQ0sgKGlmIG5vdCB3aWxsaW5nIHRvDQo+ ID4gPnF1ZXVlIG9yIGRyb3AgVVBEQVRFKTogNDkxIG9yIDUwMD8gIElzIGl0IGEgU0hPVUxEIG9y IE1VU1Q/DQo+ID4gDQo+ID4gVUEgbWF5IHNlbmQgMnh4IHRvIFVQREFURS4gQmVjYXVzZSB0aGUg SU5WSVRFIHRyYW5zYWN0aW9uIGhhcw0KPiA+IGJlZW4gY29tcGxldGVkLg0KPiANCj4gSWYgSSB1 bmRlcnN0YW5kIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZSBhbmQgUkZDMzMxMSBjb3JyZWN0 bHksIA0KPiB0aGUgZm9sbG93aW5nIHNuaXBwZXRzIGFwcGx5Lg0KPiANCj4gIldoZW4gY2hlY2tp bmcgZm9yIGdsYXJlIHNpdHVhdGlvbnMsIFVBcyBNVVNUIHRyZWF0IGV2ZXJ5IFVQREFURSANCj4g cmVxdWVzdCBhcyBpZiBpdCBjb250YWluZWQgYW4gb2ZmZXIuICBBZGRpdGlvbmFsbHksIFVBcyBN VVNUIHRyZWF0IA0KPiB0aGUgZXhjaGFuZ2Ugb2YgYSAyeHggcmVzcG9uc2UgdG8gYW4gSU5WSVRF IHJlcXVlc3QgYW5kIGl0cyANCj4gY29ycmVzcG9uZGluZyBBQ0sgcmVxdWVzdCBhcyBhbiBvZmZl ci9hbnN3ZXIgZXhjaGFuZ2UuIg0KDQpUaGlzIGlzIG5vIGEgZ2xhcmUgc2l0dWF0aW9uLiBVQUMg Y2FuIGhhbmRsZSB0aGUgVVBEQVRFIE9LLg0KDQpUaGFua3MsDQoNCkdhbw0KDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9u LiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFt ZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRv IG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFy ZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRv ciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJl IHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00111D214825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTAtMDUt MjQgMDE6MzQ6NDc6PGJyPg0KPGJyPg0KJmd0OyAmZ3Q7IEJ1dCBhbiBpbnRlcndvcmtpbmcgb2Yg SU5WSVRFIGFuZCBVUERBVEUgaXMgdW5jbGVhci48YnI+DQomZ3Q7ICZndDsgVGhlIGRyYWZ0LW9m ZmVyYW5zd2VyIG1ha2VzIGFuIGVmZm9ydHMgdG8gY2xhcmlmeSBpdCBpbiB0aGU8YnI+DQomZ3Q7 ICZndDsgc2VjdGlvbiA0LjMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgdGhlIGlu Zm9ybWF0aW9uLiAmbmJzcDtEcmFmdC1pZXRmLXNpcHBpbmctc2lwLW9mZmVyYW5zd2VyDQo8YnI+ DQomZ3Q7IG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8gYWN0dWFsbHkgcmVmZXIgdG8gZHJhZnQtaWV0 Zi1zaXBjb3JlLXJlaW52aXRlLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0O0lmIElOVklURSBjb250YWlucyBvZmZlciBTRFAgYW5kIDE4eCB3YXMgbm90IHJlbGlhYmxl LCBob3c8YnI+DQomZ3Q7ICZndDsgJmd0O1NIT1VMRCB0aGUgY2FsbGVkIHBhcnR5IHJlc3BvbmQg aWYgVVBEQVRFIHdpdGhvdXQgU0RQIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDtyZWNlaXZlZCBmcm9t IGNhbGxlcjogNDkxLCA1MDAsIG9yIHByb2Nlc3MgYXMgdGhvdWdoIG5vIGdsYXJlPzxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSWYgVUEgbXVzdCByZWZ1c2UgaXQgLCBwZXJoYXBzIGl0 IGlzIDUwMC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgSSB1bmRlcnN0YW5kIGRyYWZ0LWlldGYt c2lwY29yZS1yZWludml0ZSBhbmQgUkZDMzMxMSBjb3JyZWN0bHksDQo8YnI+DQomZ3Q7IHRoZSBm b2xsb3dpbmcgc25pcHBldHMgYXBwbHkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O1doZW4g Y2hlY2tpbmcgZm9yIGdsYXJlIHNpdHVhdGlvbnMsIFVBcyBNVVNUIHRyZWF0IGV2ZXJ5IFVQREFU RQ0KPGJyPg0KJmd0OyByZXF1ZXN0IGFzIGlmIGl0IGNvbnRhaW5lZCBhbiBvZmZlci4mcXVvdDs8 YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7U2ltaWxhcmx5LCBpZiBhbiBVUERBVEUgaXMgcmVj ZWl2ZWQgdGhhdCBjb250YWlucyBhbiBvZmZlciwNCmFuZCB0aGU8YnI+DQomZ3Q7IFVBUyBoYXMg cmVjZWl2ZWQgYW4gb2ZmZXIgKGluIGFuIFVQREFURSwgUFJBQ0ssIG9yIElOVklURSkgdG8gd2hp Y2gNCjxicj4NCiZndDsgaXQgaGFzIG5vdCB5ZXQgZ2VuZXJhdGVkIGFuIGFuc3dlciwgdGhlIFVB UyBNVVNUIHJlamVjdCB0aGUgVVBEQVRFDQo8YnI+DQomZ3Q7IHdpdGggYSA1MDAgcmVzcG9uc2Us IGFuZCBNVVNUIGluY2x1ZGUgYSBSZXRyeS1BZnRlciBoZWFkZXIgZmllbGQgPGJyPg0KJmd0OyB3 aXRoIGEgcmFuZG9tbHkgY2hvc2VuIHZhbHVlIGJldHdlZW4gMCBhbmQgMTAgc2Vjb25kcy4mcXVv dDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IElNTyBpdCBpcyBhbm90aGVy IHF1ZXN0aW9uIHdoZXRoZXIgVUEgbXVzdCByZWplY3QgdGhlIFVQREFURTxicj4NCiZndDsgJmd0 OyB3aXRob3V0IGFuIG9mZmVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBNeSBjdXJyZW50IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCBpdCBNVVNUIGJlIHJlamVjdGVkOyBzZWUgYWJvdmUuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7SWYgSU5WSVRFIGNvbnRhaW5zIG9mZmVy IFNEUCBhbmQgMTh4IHdhcyBub3QgcmVsaWFibGUsIGhvdzxicj4NCiZndDsgJmd0OyAmZ3Q7U0hP VUxEIHRoZSBjYWxsZXIgcmVzcG9uZCBpZiBVUERBVEUgd2l0aG91dCBTRFAgaXMgcmVjZWl2ZWQ8 YnI+DQomZ3Q7ICZndDsgJmd0O2Zyb20gY2FsbGVkIHBhcnR5OiA0OTEsIDUwMCwgb3IgcHJvY2Vz cyBhcyB0aG91Z2ggbm8gZ2xhcmU/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBQZXJo YXBzIGl0IGlzIDQ5MS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgSSB1bmRlcnN0YW5kIGRyYWZ0 LWlldGYtc2lwY29yZS1yZWludml0ZSBhbmQgUkZDMzMxMSBjb3JyZWN0bHksDQo8YnI+DQomZ3Q7 IHRoZSBmb2xsb3dpbmcgc25pcHBldHMgYXBwbHkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90 O1doZW4gY2hlY2tpbmcgZm9yIGdsYXJlIHNpdHVhdGlvbnMsIFVBcyBNVVNUIHRyZWF0IGV2ZXJ5 IFVQREFURQ0KPGJyPg0KJmd0OyByZXF1ZXN0IGFzIGlmIGl0IGNvbnRhaW5lZCBhbiBvZmZlci4m cXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7SWYgYW4gVVBEQVRFIGlzIHJlY2VpdmVk IHRoYXQgY29udGFpbnMgYW4gb2ZmZXIsIGFuZCB0aGUgVUFTDQpoYXMgPGJyPg0KJmd0OyBnZW5l cmF0ZWQgYW4gb2ZmZXIgKGluIGFuIFVQREFURSwgUFJBQ0sgb3IgSU5WSVRFKSB0byB3aGljaCBp dCBoYXMNCjxicj4NCiZndDsgbm90IHlldCByZWNlaXZlZCBhbiBhbnN3ZXIsIHRoZSBVQVMgTVVT VCByZWplY3QgdGhlIFVQREFURSB3aXRoIGENCjxicj4NCiZndDsgNDkxIHJlc3BvbnNlLiZxdW90 Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiB0aGUgY2FsbGluZyBwYXJ0eSBzdXBwb3J0cyBkcmFm dC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUgYnV0IGNhbGxlZDxicj4NCiZndDsgcGFydHkgZG9lc24n dCwgdGhpcyBjYW4gbGVhZCB0byBudW1lcm91cyBVUERBVEUvNDkxIChyZXRyeSBpbnRlcnZhbA0K PGJyPg0KJmd0OyAwLTIgc2Vjb25kcykgdW50aWwgY2FsbGVkIHBhcnR5IG5vIGxvbmdlciBtYW5k YXRlZCB0byByZXR1cm4gNDkxLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jm5ic3A7V2hpbGUgVUFTKGFzIHRoaXMgaXMgYWJvdXQgUmUtSU5WSVRFLCBVQVMgY291bGQN CmJlIG1vcmUgcHJvcGVyIGhlcmUpIGRvZXMgbm90IHN1cHBvcnQgZHJhZnQtaWV0Zi1zaXBjb3Jl LXJlaW52aXRlLCBVQVMNCm1heSBqdXN0IHNlbmQgMnh4IHRvIFVQREFURS4gQW5kIHRoaXMgbWF5 IGNhdXNlIGFtYmlndW91cyBzZXNzaW9uIHN0YXRlLg0KSWYgVUFDIHN1cHBvcnQgZHJhZnQtaWV0 Zi1zaXBjb3JlLXJlaW52aXRlLCB0aGUgVUFDIHNob3VsZCBzZW5kIGEgbmV3IFJlLUlOVklURS9V UERBVEUNCnRvIHN5bmNocm9uaXplIHRoZSBzZXNzaW9uIHN0YXRlLjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+SWYgYm90aCBvZiBVQUMgYW5kIFVBUyBkbyBub3Qgc3VwcG9ydCBk cmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUsDQp0aGUgc2Vzc2lvbiBzdGF0ZSB3b3VsZCBiZSBh bWJpZ3VvdXMuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIHRoaW5r IHRoZSBjaXJjdWxhdGlvbiBvZiBVUERBVEUvNDkxIHdvdWxkIGhhcHBlbg0KaWYgVUFTIHN1cHBv cnQgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLCBubyBtYXR0ZXIgVUFTIHN1cHBvcnRzIGRy YWZ0LWlldGYtc2lwY29yZS1yZWludml0ZQ0Kb3Igbm90LiBBbmQgdGhlIHRpbWVzIG9mIHRoaXMg Y2lyY3VsYXRpb24gd291bGQgbm90IGJlIG51bWVyb3VzLCB0aGUgY2lyY3VsYXRpb24NCndvdWxk IGJlIGVuZGVkIGFmdGVyIFVBUyBnZXRzIHRoZSBBQ0sob2YgUmUtSU5WSVRFJ3MgNHh4KS4gPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDtJZiBjYWxsZXIgcmVjZWl2ZXMgSU5WSVRFIDJ4eCB3aXRob3V0IG9m ZmVyL2Fuc3dlciwgaG93IFNIT1VMRDxicj4NCiZndDsgJmd0OyAmZ3Q7b3IgTVVTVCB0aGUgY2Fs bGVyIHJlc3BvbmQgaWYgVVBEQVRFIHdpdGhvdXQgU0RQIGlzIHJlY2VpdmVkPGJyPg0KJmd0OyAm Z3Q7ICZndDtmcm9tIGNhbGxlZCBwYXJ0eSBwcmlvciB0byBzZW5kaW5nIEFDSyAoaWYgbm90IHdp bGxpbmcgdG88YnI+DQomZ3Q7ICZndDsgJmd0O3F1ZXVlIG9yIGRyb3AgVVBEQVRFKTogNDkxIG9y IDUwMD8gJm5ic3A7SXMgaXQgYSBTSE9VTEQgb3INCk1VU1Q/PGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBVQSBtYXkgc2VuZCAyeHggdG8gVVBEQVRFLiBCZWNhdXNlIHRoZSBJTlZJVEUg dHJhbnNhY3Rpb24gaGFzPGJyPg0KJmd0OyAmZ3Q7IGJlZW4gY29tcGxldGVkLjxicj4NCiZndDsg PGJyPg0KJmd0OyBJZiBJIHVuZGVyc3RhbmQgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlIGFu ZCBSRkMzMzExIGNvcnJlY3RseSwNCjxicj4NCiZndDsgdGhlIGZvbGxvd2luZyBzbmlwcGV0cyBh cHBseS48YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7V2hlbiBjaGVja2luZyBmb3IgZ2xhcmUg c2l0dWF0aW9ucywgVUFzIE1VU1QgdHJlYXQgZXZlcnkgVVBEQVRFDQo8YnI+DQomZ3Q7IHJlcXVl c3QgYXMgaWYgaXQgY29udGFpbmVkIGFuIG9mZmVyLiAmbmJzcDtBZGRpdGlvbmFsbHksIFVBcyBN VVNUDQp0cmVhdCA8YnI+DQomZ3Q7IHRoZSBleGNoYW5nZSBvZiBhIDJ4eCByZXNwb25zZSB0byBh biBJTlZJVEUgcmVxdWVzdCBhbmQgaXRzIDxicj4NCiZndDsgY29ycmVzcG9uZGluZyBBQ0sgcmVx dWVzdCBhcyBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuJnF1b3Q7PGJyPg0KPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGlzIGlzIG5vIGEgZ2xhcmUgc2l0dWF0aW9uLiBVQUMg Y2FuIGhhbmRsZSB0aGUgVVBEQVRFDQpPSy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPlRoYW5rcyw8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkdhbzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24m bmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNw O2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVs eSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2Fu aXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZu YnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZu YnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5 Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtk aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5k Jm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZu YnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29s ZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5i c3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Jl Y2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFz ZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZu YnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hh cyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZu YnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwv cHJlPg== --=_alternative 00111D214825772D_=-- From gao.yang2@zte.com.cn Sun May 23 20:13:33 2010 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 9537F3A6A0E; Sun, 23 May 2010 20:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.667 X-Spam-Level: X-Spam-Status: No, score=-93.667 tagged_above=-999 required=5 tests=[AWL=-3.477, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, 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 nx1awcoxUQJ5; Sun, 23 May 2010 20:13:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 754203A68B5; Sun, 23 May 2010 20:13:31 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368872001811080; Mon, 24 May 2010 11:07:00 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 13308.5095341370; Mon, 24 May 2010 11:07:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4O3Cld2033174; Mon, 24 May 2010 11:12:47 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4BF68A0C.20204@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 11:10:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 11:12:38, Serialize complete at 2010-05-24 11:12:38 Content-Type: multipart/alternative; boundary="=_alternative 001199804825772D_=" X-MAIL: mse2.zte.com.cn o4O3Cld2033174 Cc: OKUMURA Shinji , sipcore@ietf.org, sipcore-bounces@ietf.org Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBJLUQgQWN0aW9uOmRyYWZ0LWlldGYt?= =?gb2312?b?c2lwY29yZS1yZWludml0ZS0wNC50eHQ=?= 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, 24 May 2010 03:13:33 -0000 This is a multipart message in MIME format. --=_alternative 001199804825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTAtMDUtMjEgMjE6MjY6MzY6 DQoNCj4gU2hpbmppLA0KPiANCj4gT0tVTVVSQSBTaGluamkgd3JvdGU6DQo+ID4gUGF1bCwNCj4g PiANCj4gPiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4NCj4gPiBXZWQsIDEyIE1h eSAyMDEwIDE2OjQ5OjMxIC0wNDAwDQo+ID4+IE9LVU1VUkEgU2hpbmppIHdyb3RlOg0KPiA+Pj4g SGksDQo+ID4+Pg0KPiA+Pj4gSSBoYXZlIG9uZSBxdWVzdGlvbiBhbmQgb25lIGNvbW1lbnQgYWJv dXQgVUFDIGJlaGF2aW9yLg0KPiA+Pj4NCj4gPj4+IHF1ZXN0aW9uOg0KPiA+Pj4gQXQgZmlyc3Qs IG9hIHN0YXR1cyBpcyBvbmx5IGF1ZGlvLCBhbmQgZHVyaW5nIGEgbmV4dCByZUlOVklURQ0KPiA+ Pj4gdHJhbnNhY3Rpb24gb2Egc3RhdHVzIGlzIGNoYW5nZWQgdG8gYXVkaW8gYW5kIHZpZGVvLiBB bmQgdGhlbg0KPiA+Pj4gVUFTIHNlbmRzIGEgNHh4IHJlc3BvbnNlIHRvIHRoZSByZUlOVklURS4N Cj4gPj4+IEluIHRoaXMgY2FzZSB3aGljaCBpcyBhIG5ldyBvZmZlciBVQUMgc2hvdWxkIHNlbmQs IG9ubHkgYXVkaW8NCj4gPj4+IG9yIGJvdGggb2YgYXVkaW8gYW5kIHZpZGVvIHdpdGggemVybyBw b3J0Pw0KPiA+PiBXZWxsLCB0aGUgbmV3IG8vYSBpcyB0byByZXN0YXRlIHRoZSBzdGF0dXMgcXVv Lg0KPiA+PiBTaW5jZSB0aGUgbmV3IG8vYSBuZXZlciBzdWNjZWVkZWQsIHRoZSBzdGF0dXMgcXVv IGluY2x1ZGVzIG9ubHkgb25lIA0KPiA+PiBtLWxpbmUuIFNvIEkgdGhpbmsgaXQgd291bGQgYmUg YWNjZXB0YWJsZSB0byBzZW5kIGFuIG9mZmVyIHdpdGggdGhhdC4NCj4gPj4NCj4gPj4gT1RPSCwg aXRzIHBvc3NpYmxlIHRoYXQgdGhlIG90aGVyIHBhcnR5IGlzIGNvbmZ1c2VkIGFuZCB0aGlua3Mg dGhlcmUgDQphcmUgDQo+ID4+IHR3byBtLWxpbmVzIGluIGVmZmVjdC4gSXQgbWlnaHQgYmUgZnVy dGhlciBjb25mdXNlZCB0byByZWNlaXZlIA0KYW5vdGhlciANCj4gPj4gb2ZmZXIgd2l0aCBvbmx5 IG9uZSBtLWxpbmUuIFNvIGl0IG1pZ2h0IGJlIHBydWRlbnQgdG8gc2VuZCB0aGUgbmV3IA0Kb2Zm ZXIgDQo+ID4+IGFzIHlvdSBzdWdnZXN0LiBJdHMgbGVnYWwgdG8gZG8gc28sIGFuZCBpdCBvdWdo dCBub3QgaHVydCBhbnl0aGluZy4NCj4gPj4gKEJ1dCBpdCBtaWdodCBjYXVzZSB0cm91YmxlIGlm IHRoZSBvdGhlciBVQSBzaW1wbHkgY2FuJ3QgaGFuZGxlIHRoZSANCj4gPj4gYWRkaXRpb25hbCBt LWxpbmUuIElmIHNvIGl0IGlzIHF1aXRlIGJyb2tlbi4pDQo+ID4gDQo+ID4gU2luY2UgYm90aCBV QXMgYWdyZWVkIHdpdGggdHdvIG0tbGluZXMgb25jZSwgcHJvYmFibHkgaXQgZG9lcw0KPiA+IG5v dCBjYXVzZSB0cm91YmxlLg0KPiANCj4gSXQgd291bGQgYmUgZ29vZCB0byBleHBsYWluIHRoZSBy ZWFzb25pbmcuDQo+IA0KPiA+IEFkZGl0aW9uYWxseSwgSU1PIGEgc2Vzcy12ZXJzaW9uIG9mIFNE UCBzaG91bGQgYmUgaW5jcmVhc2VkIHRvby4NCj4gDQo+IFNvbWUgcHJvYmxlbSBjYXNlcyB3b3Vs ZCBiZSB0aGUgZm9sbG93aW5nOg0KPiANCj4gICAgQSAgICAgICAgICAgICAgICAgICAgICAgQg0K PiAgIE0xICAgfCByZUlOVklURSBTRFAxLFY9YSAgICAgfA0KPiAgICB8LS0tLS0tLS0tLS0tLS0t LS0tLS0tLT58DQo+ICAgTTIgICB8IDE4MHJlbCBTRFAyLFY9YiAgICAgICB8DQo+ICAgIHw8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLXwNCj4gICBNMyAgIHwgUFJBQ0sgU0RQMyxWPWErMSAgICAgIHwN Cj4gICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KPiAgIE00ICAgfCAyMDBQUkEgU0RQNCxW PWIrMSAgICAgfA0KPiAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQo+ICAgTTUgICB8IDR4 eCBJTlZJVEUgICAgICAgICAgICB8DQo+ICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCj4g ICBNNi4xICAgfCBVUERBVEUgU0RQMSxWPXggICAgICAgfCBFaXRoZXIgdGhpcw0KPiAgICB8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+ICAgTTYuMiAgIHwgVVBEQVRFIFNEUDQsVj14ICAgICAg IHwgb3IgdGhpcw0KPiAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+IA0KPiBUaGUgcXVl c3Rpb24gYWJvdmUgaXM6IHNob3VsZCB4IGJlICdhJywgb3IgJ2ErMicgaW4gTTYuKiwgYW5kIGRv ZXMgdGhlIA0KPiBhbnN3ZXIgdG8gdGhhdCBtYXR0ZXIgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhl IFNEUCBpcyBTRFAxIG9yIFNEUDU/DQo+IA0KPiBJIHRoaW5rIHRoaXMgaXMgbW9vdCBpbiBtb3N0 IGNhc2VzIGJlY2F1c2UgdGhlcmUgd2lsbCBiZSBubyByZWplY3Rpb24gb2YgDQoNCj4gdGhlIGlu dml0ZSBhZnRlciB0d28gby9hIGV4Y2hhbmdlcy4gQnV0IGl0IGNhbiBoYXBwZW4sIHNheSBpbiBj YXNlIG9mIA0KPiBwcmVjb25kaXRpb25zIHRoYXQgYXJlbid0IG1ldC4NCj4gDQo+IEluIE02LjEg SSB0aGluayB4IHNob3VsZCBiZSAnYSsyJy4gRG9lcyB0aGF0IHNlZW0gcmlnaHQgdG8geW91Pw0K PiBJIHRoaW5rIE02LjIgaXMgbm90IHJlY29tbWVuZGVkLiBJZiBpdCBvY2N1cnMsIHRoZW4gYWdh aW4gSSB0aGluayB4IA0KPiBzaG91bGQgYmUgYSsyLg0KPiANCj4gICAgQSAgICAgICAgICAgICAg ICAgICAgICAgQg0KPiAgIE0xICAgfCByZUlOVklURSBTRFAxLFY9YSAgICAgfA0KPiAgICB8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+ICAgTTIgICB8IDE4MHJlbCBTRFAyLFY9YiAgICAgICB8 DQo+ICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCj4gICBNNSAgIHwgNHh4IElOVklURSAg ICAgICAgICAgIHwNCj4gICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KPiAgIE02LjEgICB8 IFVQREFURSBTRFAxLFY9eCAgICAgICB8IEVpdGhlciB0aGlzDQo+ICAgIHwtLS0tLS0tLS0tLS0t LS0tLS0tLS0tPnwNCj4gICBNNi4yICAgfCBVUERBVEUgU0RQNCxWPXggICAgICAgfCBvciB0aGlz DQo+ICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCj4gDQo+IEluIHRoaXMgc2ltcGxlciBj YXNlLCBmb3IgTTYuMSB4PSdhJyBzaG91bGQgYmUgZmluZSBhbmQgcHJ1ZGVudCwNCj4gYmVjYXVz ZSBzb21lYm9keSAqbWlnaHQqIGNvbXBsYWluIGlmIHRoZSBnZXQgdHdvIHN1Y2Nlc3NpdmUgU0RQ cyB0aGF0IA0KPiBhcmUgaWRlbnRpY2FsIGV4Y2VwdCBmb3IgdGhlIHZlcnNpb24uDQo+IA0KPiBJ TU8gdGhlIFNEUCB2ZXJzaW9uIGlzIHVudHJ1c3R3b3J0aHkgYW5kIHByb2JhYmx5IG91Z2h0IHRv IGJlIGlnbm9yZWQsIA0KPiBidXQgaXQgc2VlbXMgdGhhdCBzb21lIGRvIGNoZWNrIGl0LCBkZXBl bmQgdXBvbiBpdCwgYW5kIGdldCB1cHNldCBpZiBpdCANCj4gZG9lc24ndCBiZWhhdmUgYXMgdGhl eSBleHBlY3QuKQ0KDQoNCkkgYWdyZWUgd2l0aCB5b3VyIGFyZ3VtZW50LCB3aGlsZSBvbmx5IG9u ZSB0aGluZzoNCg0KKlNEUDEqIGluIE02LjEgbWVhbnMgdGhlIHNlc3Npb24gc3RhdGUgYmVmb3Jl IHRoaXMgUmUtSU5WSVRFLCBzbyBpdCBzaG91bGQgDQpub3QgYmUgdGhlIFNEUDEgaW4gTTEuDQoN ClRoYW5rcywNCg0KR2FvIA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 001199804825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTAtMDUt MjEgMjE6MjY6MzY6PGJyPg0KPGJyPg0KJmd0OyBTaGluamksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE9LVU1VUkEgU2hpbmppIHdyb3RlOjxicj4NCiZndDsgJmd0OyBQYXVsLDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgUGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IFdlZCwgMTIgTWF5IDIwMTAgMTY6NDk6MzEgLTA0MDA8YnI+DQomZ3Q7 ICZndDsmZ3Q7IE9LVU1VUkEgU2hpbmppIHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEhp LDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSSBoYXZlIG9u ZSBxdWVzdGlvbiBhbmQgb25lIGNvbW1lbnQgYWJvdXQgVUFDIGJlaGF2aW9yLjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgcXVlc3Rpb246PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsgQXQgZmlyc3QsIG9hIHN0YXR1cyBpcyBvbmx5IGF1ZGlvLCBhbmQgZHVyaW5n IGEgbmV4dA0KcmVJTlZJVEU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB0cmFuc2FjdGlvbiBvYSBz dGF0dXMgaXMgY2hhbmdlZCB0byBhdWRpbyBhbmQgdmlkZW8uDQpBbmQgdGhlbjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IFVBUyBzZW5kcyBhIDR4eCByZXNwb25zZSB0byB0aGUgcmVJTlZJVEUuPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSW4gdGhpcyBjYXNlIHdoaWNoIGlzIGEgbmV3IG9mZmVyIFVB QyBzaG91bGQgc2VuZCwgb25seQ0KYXVkaW88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBvciBib3Ro IG9mIGF1ZGlvIGFuZCB2aWRlbyB3aXRoIHplcm8gcG9ydD88YnI+DQomZ3Q7ICZndDsmZ3Q7IFdl bGwsIHRoZSBuZXcgby9hIGlzIHRvIHJlc3RhdGUgdGhlIHN0YXR1cyBxdW8uPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBTaW5jZSB0aGUgbmV3IG8vYSBuZXZlciBzdWNjZWVkZWQsIHRoZSBzdGF0dXMgcXVv IGluY2x1ZGVzDQpvbmx5IG9uZSA8YnI+DQomZ3Q7ICZndDsmZ3Q7IG0tbGluZS4gU28gSSB0aGlu ayBpdCB3b3VsZCBiZSBhY2NlcHRhYmxlIHRvIHNlbmQgYW4gb2ZmZXINCndpdGggdGhhdC48YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPVE9ILCBpdHMgcG9zc2libGUgdGhh dCB0aGUgb3RoZXIgcGFydHkgaXMgY29uZnVzZWQgYW5kIHRoaW5rcw0KdGhlcmUgYXJlIDxicj4N CiZndDsgJmd0OyZndDsgdHdvIG0tbGluZXMgaW4gZWZmZWN0LiBJdCBtaWdodCBiZSBmdXJ0aGVy IGNvbmZ1c2VkIHRvIHJlY2VpdmUNCmFub3RoZXIgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBvZmZlciB3 aXRoIG9ubHkgb25lIG0tbGluZS4gU28gaXQgbWlnaHQgYmUgcHJ1ZGVudCB0byBzZW5kDQp0aGUg bmV3IG9mZmVyIDxicj4NCiZndDsgJmd0OyZndDsgYXMgeW91IHN1Z2dlc3QuIEl0cyBsZWdhbCB0 byBkbyBzbywgYW5kIGl0IG91Z2h0IG5vdCBodXJ0DQphbnl0aGluZy48YnI+DQomZ3Q7ICZndDsm Z3Q7IChCdXQgaXQgbWlnaHQgY2F1c2UgdHJvdWJsZSBpZiB0aGUgb3RoZXIgVUEgc2ltcGx5IGNh bid0DQpoYW5kbGUgdGhlIDxicj4NCiZndDsgJmd0OyZndDsgYWRkaXRpb25hbCBtLWxpbmUuIElm IHNvIGl0IGlzIHF1aXRlIGJyb2tlbi4pPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBT aW5jZSBib3RoIFVBcyBhZ3JlZWQgd2l0aCB0d28gbS1saW5lcyBvbmNlLCBwcm9iYWJseSBpdCBk b2VzPGJyPg0KJmd0OyAmZ3Q7IG5vdCBjYXVzZSB0cm91YmxlLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBJdCB3b3VsZCBiZSBnb29kIHRvIGV4cGxhaW4gdGhlIHJlYXNvbmluZy48YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0OyBBZGRpdGlvbmFsbHksIElNTyBhIHNlc3MtdmVyc2lvbiBvZiBTRFAgc2hv dWxkIGJlIGluY3JlYXNlZCB0b28uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvbWUgcHJvYmxlbSBj YXNlcyB3b3VsZCBiZSB0aGUgZm9sbG93aW5nOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7QSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBCPGJyPg0KJmd0OyAmbmJzcDsgTTEgJm5ic3A7 IHwgcmVJTlZJVEUgU0RQMSxWPWEgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4NCiZndDsgJm5ic3A7IE0yICZuYnNw OyB8IDE4MHJlbCBTRFAyLFY9YiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4NCiZndDsgJm5ic3A7IE0z ICZuYnNwOyB8IFBSQUNLIFNEUDMsVj1hKzEgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4NCiZndDsgJm5i c3A7IE00ICZuYnNwOyB8IDIwMFBSQSBTRFA0LFY9YisxICZuYnNwOyAmbmJzcDsgfDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO3wmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+DQomZ3Q7ICZu YnNwOyBNNSAmbmJzcDsgfCA0eHggSU5WSVRFICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3wmbHQ7LS0tLS0tLS0tLS0tLS0t LS0tLS0tLXw8YnI+DQomZ3Q7ICZuYnNwOyBNNi4xICZuYnNwOyB8IFVQREFURSBTRFAxLFY9eCAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8IEVpdGhlcg0KdGhpczxicj4NCiZndDsgJm5ic3A7ICZuYnNw O3wtLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQomZ3Q7ICZuYnNwOyBNNi4yICZuYnNw OyB8IFVQREFURSBTRFA0LFY9eCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IG9yIHRoaXM8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFRoZSBxdWVzdGlvbiBhYm92ZSBpczogc2hvdWxkIHggYmUgJ2EnLCBvciAnYSsy JyBpbiBNNi4qLCBhbmQgZG9lcw0KdGhlIDxicj4NCiZndDsgYW5zd2VyIHRvIHRoYXQgbWF0dGVy IGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZSBTRFAgaXMgU0RQMSBvciBTRFA1Pzxicj4NCiZndDsg PGJyPg0KJmd0OyBJIHRoaW5rIHRoaXMgaXMgbW9vdCBpbiBtb3N0IGNhc2VzIGJlY2F1c2UgdGhl cmUgd2lsbCBiZSBubyByZWplY3Rpb24NCm9mIDxicj4NCiZndDsgdGhlIGludml0ZSBhZnRlciB0 d28gby9hIGV4Y2hhbmdlcy4gQnV0IGl0IGNhbiBoYXBwZW4sIHNheSBpbiBjYXNlDQpvZiA8YnI+ DQomZ3Q7IHByZWNvbmRpdGlvbnMgdGhhdCBhcmVuJ3QgbWV0Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyBJbiBNNi4xIEkgdGhpbmsgeCBzaG91bGQgYmUgJ2ErMicuIERvZXMgdGhhdCBzZWVtIHJpZ2h0 IHRvIHlvdT88YnI+DQomZ3Q7IEkgdGhpbmsgTTYuMiBpcyBub3QgcmVjb21tZW5kZWQuIElmIGl0 IG9jY3VycywgdGhlbiBhZ2FpbiBJIHRoaW5rDQp4IDxicj4NCiZndDsgc2hvdWxkIGJlIGErMi48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0EgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Qjxicj4NCiZndDsgJm5ic3A7IE0xICZuYnNwOyB8IHJlSU5WSVRFIFNEUDEsVj1hICZuYnNwOyAm bmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3wtLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0 O3w8YnI+DQomZ3Q7ICZuYnNwOyBNMiAmbmJzcDsgfCAxODByZWwgU0RQMixWPWIgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3wmbHQ7LS0tLS0tLS0tLS0tLS0t LS0tLS0tLXw8YnI+DQomZ3Q7ICZuYnNwOyBNNSAmbmJzcDsgfCA0eHggSU5WSVRFICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNw O3wmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+DQomZ3Q7ICZuYnNwOyBNNi4xICZuYnNw OyB8IFVQREFURSBTRFAxLFY9eCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IEVpdGhlcg0KdGhpczxi cj4NCiZndDsgJm5ic3A7ICZuYnNwO3wtLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQom Z3Q7ICZuYnNwOyBNNi4yICZuYnNwOyB8IFVQREFURSBTRFA0LFY9eCAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8IG9yIHRoaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLSZndDt8PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHRoaXMgc2ltcGxlciBjYXNlLCBmb3Ig TTYuMSB4PSdhJyBzaG91bGQgYmUgZmluZSBhbmQgcHJ1ZGVudCw8YnI+DQomZ3Q7IGJlY2F1c2Ug c29tZWJvZHkgKm1pZ2h0KiBjb21wbGFpbiBpZiB0aGUgZ2V0IHR3byBzdWNjZXNzaXZlIFNEUHMg dGhhdA0KPGJyPg0KJmd0OyBhcmUgaWRlbnRpY2FsIGV4Y2VwdCBmb3IgdGhlIHZlcnNpb24uPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IElNTyB0aGUgU0RQIHZlcnNpb24gaXMgdW50cnVzdHdvcnRoeSBh bmQgcHJvYmFibHkgb3VnaHQgdG8gYmUgaWdub3JlZCwNCjxicj4NCiZndDsgYnV0IGl0IHNlZW1z IHRoYXQgc29tZSBkbyBjaGVjayBpdCwgZGVwZW5kIHVwb24gaXQsIGFuZCBnZXQgdXBzZXQNCmlm IGl0IDxicj4NCiZndDsgZG9lc24ndCBiZWhhdmUgYXMgdGhleSBleHBlY3QuKTxicj4NCjwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSBhZ3JlZSB3aXRoIHlvdXIgYXJn dW1lbnQsIHdoaWxlIG9ubHkgb25lIHRoaW5nOjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+KlNEUDEqIGluIE02LjEgbWVhbnMgdGhlIHNlc3Npb24gc3RhdGUgYmVmb3Jl IHRoaXMNClJlLUlOVklURSwgc28gaXQgc2hvdWxkIG5vdCBiZSB0aGUgU0RQMSBpbiBNMS48L2Zv bnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRoYW5rcyw8L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkdhbyA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5i c3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBp ZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0 byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZu YnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50 cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVy cy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJh bnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJz cDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3Vz ZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5i c3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJ ZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZu YnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtv cmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3Zp ZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2Fy ZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVy Lg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNw O2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJz cDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 001199804825772D_=-- From harbhanu@huawei.com Sun May 23 22:41:02 2010 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 300223A6A16 for ; Sun, 23 May 2010 22:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_40=-0.185, 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 J+KJro3fl4as for ; Sun, 23 May 2010 22:40:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 294403A68D3 for ; Sun, 23 May 2010 22:40:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2W00C2FT3WOK@szxga04-in.huawei.com> for sipcore@ietf.org; Mon, 24 May 2010 13:40:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2W00FGQT3WR8@szxga04-in.huawei.com> for sipcore@ietf.org; Mon, 24 May 2010 13:40:44 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2W00FQST3VOP@szxml04-in.huawei.com> for sipcore@ietf.org; Mon, 24 May 2010 13:40:44 +0800 (CST) Date: Mon, 24 May 2010 11:10:43 +0530 From: Harbhanu To: sipcore@ietf.org Message-id: <56989ED64ED04F2884E459DCD5DBE57A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_qtOG1j8LJPkX/BO1VjNVIQ)" Thread-index: Acr7A6ac1DnnnV2nRY2JIzgvefDKzg== Subject: [sipcore] REg. draft-ietf-sipcore-reinvite-04 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, 24 May 2010 05:41:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_qtOG1j8LJPkX/BO1VjNVIQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 1. UE1 --- INVITE SE-1800 --> UE2 2. UE1 <--- 183 ------------------ UE2 3. UE1 --- UPDATE SE-600 --> UE2 4. UE1 <--- 200 UPDATE -SE600 -- UE2 5. UE1 <--- 200 INVITE SE-1800 -- UE2 Please refer the scenario above for handling of Session-Timer, (4028). As per the Draft-ietf-sipcore-reinvite-04 section 4.5: " When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer. Additionally, UAs MUST treat the exchange of a 2xx response to an INVITE request and its corresponding ACK request as an offer/answer exchange. Consequently, the rules regarding glare situations applicable to offer/answer exchanges are also applicable to those exchanges." Here, we are not able to conclude whether both UAs should run session timer with 1800 or 600, or otherwise whether the UPDATE should be rejected. As per my understanding this draft doesn't *explicitly* mention anything about the Session-Timer, wherein there is an early negotiation. Since 4028 also doesn't have any reference for early negotiation, so we suggest that it can better be incorporated in the above mentioned draft[ietf-sipcore-reinvite-04]. Please share your opinion and do guide us incase any of the existing RFC/active-draft already captures this. Thanks! Regards, Harbhanu **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_qtOG1j8LJPkX/BO1VjNVIQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

 

1. UE1 --- INVITE SE-1800 à = UE2

2. UE1 <--- 183 ------------------ = UE2

 

3. UE1 --- UPDATE SE-600 à = UE2

4. UE1 <--- 200 UPDATE -SE600 -- = UE2

 

5. UE1 <--- 200 INVITE SE-1800 -- = UE2

 

Please refer the scenario above for handling of = Session-Timer, (4028).

As per the = Draft-ietf-sipcore-reinvite-04 section 4.5:

“  When checking for glare situations, UAs MUST treat =
every UPDATE

   request as if it contained an offer.  Additionally, UAs MUST = treat

   the exchange of a 2xx response to an INVITE request and = its

   corresponding ACK request as an offer/answer exchange.  = Consequently,

   the rules regarding glare situations applicable to = offer/answer

   exchanges are also applicable to those = exchanges.”

 <= /o:p>

Here, we are not able to conclude whether both UAs = should run session timer with

1800 or 600, or otherwise whether the UPDATE should = be rejected.

 

As per my understanding this draft doesn’t = *explicitly* mention anything about = the Session-Timer, wherein there is an early negotiation. Since 4028 also = doesn’t

have any reference for early negotiation, so we = suggest that it can better be incorporated in the above mentioned = draft[ietf-sipcore-reinvite-04].<= /p>

 

Please share your opinion and do guide us incase any = of the existing RFC/active-draft already captures = this.

 

Thanks!

 

Regards,

Harbhanu

 

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

 

--Boundary_(ID_qtOG1j8LJPkX/BO1VjNVIQ)-- From gao.yang2@zte.com.cn Sun May 23 23:55:02 2010 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 8DC093A672E for ; Sun, 23 May 2010 23:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.624 X-Spam-Level: X-Spam-Status: No, score=-95.624 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 q6uyz574x71E for ; Sun, 23 May 2010 23:55:01 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id A5C413A69CD for ; Sun, 23 May 2010 23:55:00 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 24 May 2010 14:49:40 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.2876834374; Mon, 24 May 2010 14:54:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4O6rkPl003235; Mon, 24 May 2010 14:53:47 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <56989ED64ED04F2884E459DCD5DBE57A@china.huawei.com> To: Harbhanu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 14:51:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 14:53:34, Serialize complete at 2010-05-24 14:53:34 Content-Type: multipart/alternative; boundary="=_alternative 0025D4A54825772D_=" X-MAIL: mse2.zte.com.cn o4O6rkPl003235 Cc: sipcore@ietf.org Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer 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, 24 May 2010 06:55:02 -0000 This is a multipart message in MIME format. --=_alternative 0025D4A54825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCk5vdCBsaWtlIE8vQSB1c2FnZSBhbmQgdGFyZ2V0IHJlZnJlc2ggdXNhZ2UsIHRoZXJl J3Mgbm8gZXhwbGljaXQgDQpkZWZpbml0aW9uIG9mIGFsbG93aW5nIHN1YnNlcXVlbnQgc2Vzc2lv biByZWZyZXNoIHJlcXVlc3QgaW4gZW1iZWRkZWQgDQpyZXF1ZXN0cyhzdWNoIGFzIFVQREFURSBk dXJpbmcgcGVuZGluZyBSZS1JTlZJVEUpLiBTbywgSSB0aGluayBpdCBpcyBub3QgDQpyZWNvbW1l bmRlZCB0byBzZW5kaW5nIFVQREFURSBhcyBzdWJzZXF1ZW50IHNlc3Npb24gcmVmcmVzaCByZXF1 ZXN0IGluIA0KcGVuZGluZyBJTlZJVEUvUmUtSU5WSVRFLg0KDQpJJ2QgbGlrZSB0byB0YWxrIG1v cmUgYWJvdXQgc2Vzc2lvbiB0aW1lci4gSWYgcGVvcGxlIHdhbnQgdG8gZG8gdGhlIA0Kc2VtYW50 aWNzIGV4dGVuc2lvbiBmb3Igc2Vzc2lvbiB0aW1lcidzIHRvIGFsbG93IGVtYmVkZGVkIHJlcXVl c3RzKHN1Y2ggYXMgDQpVUERBVEUgZHVyaW5nIHBlbmRpbmcgUmUtSU5WSVRFKSwgdGhlcmUncyBv bmUgc3VnZ2VzdGlvbiB3YXkoSU5GT1JNQVRJVkUgDQphdCBhbGwpOg0KDQpEbyBpdCBsaWtlIHRh cmdldCByZWZyZXNoLCB0aGVuIHRoZSAyeHggb2YgSU5WSVRFL1JlLUlOVklURSdzIFNFIHZhbHVl IA0Kc2hvdWxkIGJlIGFzIHRoZSBTRSB2YWx1ZSBpbiB0aGUgbGFzdCBlbWJlZGRlZCBzdWJzZXF1 ZW50IHNlc3Npb24gcmVmcmVzaCANCnJlcXVlc3QncyAyeHguDQoNClRoZW4sIHRoZSBnbGFyZSBo YW5kbGluZyBmb3Igc3VjaCB1c2FnZSB3b3VsZCBiZSB0aGUgc2FtZSBhcyB0aGUgVGFyZ2V0IA0K UmVmcmVzaCBwYXJ0IGluIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS4NCg0KVGhhbmtzLA0K DQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAy MTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9t YWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQoNCg0KDQpIYXJiaGFudSA8aGFyYmhhbnVAaHVhd2VpLmNvbT4gDQq3orz+yMs6ICBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDUtMjQgMTM6NDANCg0KytW8/sjLDQpzaXBj b3JlQGlldGYub3JnDQqzrcvNDQoNCtb3zOINCltzaXBjb3JlXSBSRWcuIGRyYWZ0LWlldGYtc2lw Y29yZS1yZWludml0ZS0wNA0KDQoNCg0KDQoNCg0KIA0KMS4gVUUxIC0tLSBJTlZJVEUgU0UtMTgw MCCopCBVRTINCjIuIFVFMSA8LS0tIDE4MyAtLS0tLS0tLS0tLS0tLS0tLS0gVUUyDQogDQozLiBV RTEgLS0tIFVQREFURSBTRS02MDAgqKQgVUUyDQo0LiBVRTEgPC0tLSAyMDAgVVBEQVRFIC1TRTYw MCAtLSBVRTINCiANCjUuIFVFMSA8LS0tIDIwMCBJTlZJVEUgU0UtMTgwMCAtLSBVRTINCiANClBs ZWFzZSByZWZlciB0aGUgc2NlbmFyaW8gYWJvdmUgZm9yIGhhbmRsaW5nIG9mIFNlc3Npb24tVGlt ZXIsICg0MDI4KS4gDQpBcyBwZXIgdGhlIERyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNCBz ZWN0aW9uIDQuNToNCqGwICBXaGVuIGNoZWNraW5nIGZvciBnbGFyZSBzaXR1YXRpb25zLCBVQXMg TVVTVCB0cmVhdCBldmVyeSBVUERBVEUNCiAgIHJlcXVlc3QgYXMgaWYgaXQgY29udGFpbmVkIGFu IG9mZmVyLiAgQWRkaXRpb25hbGx5LCBVQXMgTVVTVCB0cmVhdA0KICAgdGhlIGV4Y2hhbmdlIG9m IGEgMnh4IHJlc3BvbnNlIHRvIGFuIElOVklURSByZXF1ZXN0IGFuZCBpdHMNCiAgIGNvcnJlc3Bv bmRpbmcgQUNLIHJlcXVlc3QgYXMgYW4gb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLiAgQ29uc2VxdWVu dGx5LA0KICAgdGhlIHJ1bGVzIHJlZ2FyZGluZyBnbGFyZSBzaXR1YXRpb25zIGFwcGxpY2FibGUg dG8gb2ZmZXIvYW5zd2VyDQogICBleGNoYW5nZXMgYXJlIGFsc28gYXBwbGljYWJsZSB0byB0aG9z ZSBleGNoYW5nZXMuobENCiANCkhlcmUsIHdlIGFyZSBub3QgYWJsZSB0byBjb25jbHVkZSB3aGV0 aGVyIGJvdGggVUFzIHNob3VsZCBydW4gc2Vzc2lvbiANCnRpbWVyIHdpdGggDQoxODAwIG9yIDYw MCwgb3Igb3RoZXJ3aXNlIHdoZXRoZXIgdGhlIFVQREFURSBzaG91bGQgYmUgcmVqZWN0ZWQuDQog DQpBcyBwZXIgbXkgdW5kZXJzdGFuZGluZyB0aGlzIGRyYWZ0IGRvZXNuoa90ICpleHBsaWNpdGx5 KiBtZW50aW9uIGFueXRoaW5nIA0KYWJvdXQgdGhlIFNlc3Npb24tVGltZXIsIHdoZXJlaW4gdGhl cmUgaXMgYW4gZWFybHkgbmVnb3RpYXRpb24uIFNpbmNlIDQwMjggDQphbHNvIGRvZXNuoa90IA0K aGF2ZSBhbnkgcmVmZXJlbmNlIGZvciBlYXJseSBuZWdvdGlhdGlvbiwgc28gd2Ugc3VnZ2VzdCB0 aGF0IGl0IGNhbiBiZXR0ZXIgDQpiZSBpbmNvcnBvcmF0ZWQgaW4gdGhlIGFib3ZlIG1lbnRpb25l ZCBkcmFmdFtpZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDRdLg0KIA0KUGxlYXNlIHNoYXJlIHlvdXIg b3BpbmlvbiBhbmQgZG8gZ3VpZGUgdXMgaW5jYXNlIGFueSBvZiB0aGUgZXhpc3RpbmcgDQpSRkMv YWN0aXZlLWRyYWZ0IGFscmVhZHkgY2FwdHVyZXMgdGhpcy4NCiANClRoYW5rcyENCiANClJlZ2Fy ZHMsDQpIYXJiaGFudQ0KIA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGUt bWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJv bSBIVUFXRUksIA0Kd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRp dHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgDQphYm92ZS4gQW55IHVzZSBvZiB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIA0KYnV0IG5vdCBs aW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3Ig DQpkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lw aWVudCdzKSBpcyANCnByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgDQpieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlh dGVseSBhbmQgZGVsZXRlIGl0IQ0KIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0 byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4g c2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0025D4A54825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Tm90IGxpa2UgTy9BIHVzYWdlIGFuZCB0 YXJnZXQgcmVmcmVzaA0KdXNhZ2UsIHRoZXJlJ3Mgbm8gZXhwbGljaXQgZGVmaW5pdGlvbiBvZiBh bGxvd2luZyBzdWJzZXF1ZW50IHNlc3Npb24gcmVmcmVzaA0KcmVxdWVzdCBpbiBlbWJlZGRlZCBy ZXF1ZXN0cyhzdWNoIGFzIFVQREFURSBkdXJpbmcgcGVuZGluZyBSZS1JTlZJVEUpLg0KU28sIEkg dGhpbmsgaXQgaXMgbm90IHJlY29tbWVuZGVkIHRvIHNlbmRpbmcgVVBEQVRFIGFzIHN1YnNlcXVl bnQgc2Vzc2lvbg0KcmVmcmVzaCByZXF1ZXN0IGluIHBlbmRpbmcgSU5WSVRFL1JlLUlOVklURS48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknZCBsaWtl IHRvIHRhbGsgbW9yZSBhYm91dCBzZXNzaW9uDQp0aW1lci4gSWYgcGVvcGxlIHdhbnQgdG8gZG8g dGhlIHNlbWFudGljcyBleHRlbnNpb24gZm9yIHNlc3Npb24gdGltZXIncw0KdG8gYWxsb3cgZW1i ZWRkZWQgcmVxdWVzdHMoc3VjaCBhcyBVUERBVEUgZHVyaW5nIHBlbmRpbmcgUmUtSU5WSVRFKSwg dGhlcmUncw0Kb25lIHN1Z2dlc3Rpb24gd2F5KElORk9STUFUSVZFIGF0IGFsbCk6PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5EbyBpdCBsaWtlIHRhcmdl dCByZWZyZXNoLCB0aGVuIHRoZQ0KMnh4IG9mIElOVklURS9SZS1JTlZJVEUncyBTRSB2YWx1ZSBz aG91bGQgYmUgYXMgdGhlIFNFIHZhbHVlIGluIHRoZSBsYXN0DQplbWJlZGRlZCBzdWJzZXF1ZW50 IHNlc3Npb24gcmVmcmVzaCByZXF1ZXN0J3MgMnh4LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlbiwgdGhlIGdsYXJlIGhhbmRsaW5nIGZvciBzdWNo IHVzYWdlDQp3b3VsZCBiZSB0aGUgc2FtZSBhcyB0aGUgVGFyZ2V0IFJlZnJlc2ggcGFydCBpbiBk cmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjEx PGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2Fv LnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5I YXJiaGFudSAmbHQ7aGFyYmhhbnVAaHVhd2VpLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7c2lwY29yZS1ib3VuY2Vz QGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAt MDUtMjQgMTM6NDA8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+c2lwY29yZUBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W3NpcGNvcmVdIFJFZy4gZHJhZnQtaWV0Zi1z aXBjb3JlLXJlaW52aXRlLTA0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj4xLiBVRTEgLS0tIElOVklURSBTRS0xODAwIDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iV2luZ2RpbmdzIj6opDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pg0KVUUyPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Mi4gVUUxICZsdDst LS0gMTgzIC0tLS0tLS0tLS0tLS0tLS0tLSBVRTI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4z LiBVRTEgLS0tIFVQREFURSBTRS02MDAgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJXaW5nZGlu Z3MiPqikPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+DQpVRTI8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj40LiBVRTEgJmx0Oy0tLSAyMDAgVVBEQVRFIC1TRTYw MCAtLSBVRTI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj41LiBVRTEgJmx0Oy0tLSAyMDAgSU5W SVRFIFNFLTE4MDAgLS0gVUUyPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgw IGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij5QbGVhc2UgcmVmZXIgdGhlIHNjZW5hcmlvIGFib3ZlIGZvciBoYW5kbGluZw0Kb2YgU2Vzc2lv bi1UaW1lciwgKDQwMjgpLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODA+ QXMgcGVyIHRoZSBEcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQNCnNlY3Rpb24gNC41Ojwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MD6hsDwvZm9udD48Zm9udCBzaXpl PTI+ICZuYnNwO1doZW4gY2hlY2tpbmcNCmZvciBnbGFyZSBzaXR1YXRpb25zLCBVQXMgTVVTVCB0 cmVhdCBldmVyeSBVUERBVEU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbmJzcDsgJm5ic3A7cmVxdWVzdCBhcyBpZiBpdCBjb250YWluZWQNCmFuIG9mZmVyLiAm bmJzcDtBZGRpdGlvbmFsbHksIFVBcyBNVVNUIHRyZWF0PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3RoZSBleGNoYW5nZSBvZiBhIDJ4eA0K cmVzcG9uc2UgdG8gYW4gSU5WSVRFIHJlcXVlc3QgYW5kIGl0czwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtjb3JyZXNwb25kaW5nIEFDSyBy ZXF1ZXN0DQphcyBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuICZuYnNwO0NvbnNlcXVlbnRseSw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7 dGhlIHJ1bGVzIHJlZ2FyZGluZyBnbGFyZQ0Kc2l0dWF0aW9ucyBhcHBsaWNhYmxlIHRvIG9mZmVy L2Fuc3dlcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNw OyAmbmJzcDtleGNoYW5nZXMgYXJlIGFsc28gYXBwbGljYWJsZQ0KdG8gdGhvc2UgZXhjaGFuZ2Vz LqGxPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkhlcmUsIHdlIGFyZSBub3QgYWJsZSB0byBj b25jbHVkZSB3aGV0aGVyDQpib3RoIFVBcyBzaG91bGQgcnVuIHNlc3Npb24gdGltZXIgd2l0aCA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4xODAwIG9yIDYwMCwgb3Igb3Ro ZXJ3aXNlIHdoZXRoZXIgdGhlIFVQREFURQ0Kc2hvdWxkIGJlIHJlamVjdGVkLjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPkFzIHBlciBteSB1bmRlcnN0YW5kaW5nIHRoaXMgZHJhZnQgZG9lc26h r3QNCio8Yj5leHBsaWNpdGx5PC9iPiogbWVudGlvbiBhbnl0aGluZyBhYm91dCB0aGUgU2Vzc2lv bi1UaW1lciwgd2hlcmVpbiB0aGVyZQ0KaXMgYW4gZWFybHkgbmVnb3RpYXRpb24uIFNpbmNlIDQw MjggYWxzbyBkb2VzbqGvdCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5o YXZlIGFueSByZWZlcmVuY2UgZm9yIGVhcmx5IG5lZ290aWF0aW9uLA0Kc28gd2Ugc3VnZ2VzdCB0 aGF0IGl0IGNhbiBiZXR0ZXIgYmUgaW5jb3Jwb3JhdGVkIGluIHRoZSBhYm92ZSBtZW50aW9uZWQN CmRyYWZ0WzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MD5pZXRmLXNpcGNvcmUtcmVp bnZpdGUtMDQ8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5dLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPlBsZWFzZSBzaGFyZSB5b3VyIG9waW5pb24gYW5kIGRvIGd1aWRlIHVzDQpp bmNhc2UgYW55IG9mIHRoZSBleGlzdGluZyBSRkMvYWN0aXZlLWRyYWZ0IGFscmVhZHkgY2FwdHVy ZXMgdGhpcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGFua3MhPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij5IYXJiaGFudTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKjxicj4NClRoaXMgZS1tYWlsIGFuZCBhdHRhY2htZW50cyBjb250YWluIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwNCndoaWNoIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkDQphYm92ZS4g QW55IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChp bmNsdWRpbmcsDQpidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3Vy ZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKQ0KYnkgcGVyc29ucyBvdGhlciB0aGFu IHRoZSBpbnRlbmRlZCByZWNpcGllbnQncykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUN CnRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUg b3IgZW1haWwgaW1tZWRpYXRlbHkNCmFuZCBkZWxldGUgaXQhPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48dHQ+PGZvbnQgc2l6ZT0y Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lw Y29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90 aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJz cDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNw O1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVk Jm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJz cDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7 Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJz cDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZu YnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50 aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUm bmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2Vu dGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQu Jm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7 ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhl Jm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkm bmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2Um bmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNw O3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5u ZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7 WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0025D4A54825772D_=-- From harbhanu@huawei.com Mon May 24 00:24:23 2010 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 C3D133A6A90 for ; Mon, 24 May 2010 00:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.649 X-Spam-Level: ** X-Spam-Status: No, score=2.649 tagged_above=-999 required=5 tests=[AWL=-2.321, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.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 1c83djF1dDln for ; Mon, 24 May 2010 00:24:22 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 511A93A6A38 for ; Mon, 24 May 2010 00:24:21 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2W00AIIXW3UJ@szxga01-in.huawei.com> for sipcore@ietf.org; Mon, 24 May 2010 15:24:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2W000TLXW30Q@szxga01-in.huawei.com> for sipcore@ietf.org; Mon, 24 May 2010 15:24:03 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2W0021JXW0WA@szxml04-in.huawei.com> for sipcore@ietf.org; Mon, 24 May 2010 15:24:01 +0800 (CST) Date: Mon, 24 May 2010 12:54:00 +0530 From: Harbhanu In-reply-to: To: gao.yang2@zte.com.cn Message-id: <640956B207584AB5AF5C377AAB6F8C1A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_4BdsttiBAT6hJaVhY1Zfjw)" Thread-index: Acr7DhEwZuTn1hBbSzCROZ2o8W5OwAAAFU4g References: <56989ED64ED04F2884E459DCD5DBE57A@china.huawei.com> Cc: sipcore@ietf.org Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer 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, 24 May 2010 07:24:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_4BdsttiBAT6hJaVhY1Zfjw) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Honest thanks for a prompt reply.. That said, below are some = clarifications for your mail - =20 >> Do it like target refresh, then the 2xx of INVITE/Re-INVITE's SE = value should be as the SE value in the last embedded subsequent session = refresh request's 2xx.=20 But then it might break the existing clause mentioned in RFC-4028, when = the scenario has INV(SE-600) & UPDATE(SE-1800),that =A8C =A1=B0 The UAS MUST NOT increase the value of the Session-Expires header field.=A1=B1 =20 >> So, I think it is not recommended to sending UPDATE as subsequent = session refresh request in pending INVITE/Re-INVITE. I suggest to incorporate its clear handling in this draft itself, since anyways it makes an excellent attempt to clear the muck around all the refresh-request handling. IMO this will make the draft a bit more comprehensive and might baseline/standardize the behavior for other extension handlings. =20 Thanks again! =20 Regards, Harbhanu =20 *************************************************************************= *** *********** This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it! _____ =20 From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: Monday, May 24, 2010 12:21 PM To: Harbhanu Cc: sipcore@ietf.org Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session = Timer =20 Hi,=20 Not like O/A usage and target refresh usage, there's no explicit = definition of allowing subsequent session refresh request in embedded requests(such = as UPDATE during pending Re-INVITE). So, I think it is not recommended to sending UPDATE as subsequent session refresh request in pending INVITE/Re-INVITE.=20 I'd like to talk more about session timer. If people want to do the semantics extension for session timer's to allow embedded requests(such = as UPDATE during pending Re-INVITE), there's one suggestion way(INFORMATIVE = at all):=20 Do it like target refresh, then the 2xx of INVITE/Re-INVITE's SE value should be as the SE value in the last embedded subsequent session = refresh request's 2xx.=20 Then, the glare handling for such usage would be the same as the Target Refresh part in draft-ietf-sipcore-reinvite.=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 Harbhanu =20 =B7=A2=BC=FE=C8=CB: sipcore-bounces@ietf.org=20 2010-05-24 13:40=20 =CA=D5=BC=FE=C8=CB sipcore@ietf.org=20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 [sipcore] REg. draft-ietf-sipcore-reinvite-04 =20 =20 =20 =20 1. UE1 --- INVITE SE-1800 --> UE2=20 2. UE1 <--- 183 ------------------ UE2=20 =20 3. UE1 --- UPDATE SE-600 --> UE2=20 4. UE1 <--- 200 UPDATE -SE600 -- UE2=20 =20 5. UE1 <--- 200 INVITE SE-1800 -- UE2=20 =20 Please refer the scenario above for handling of Session-Timer, (4028).=20 As per the Draft-ietf-sipcore-reinvite-04 section 4.5:=20 =A1=B0 When checking for glare situations, UAs MUST treat every UPDATE=20 request as if it contained an offer. Additionally, UAs MUST treat=20 the exchange of a 2xx response to an INVITE request and its=20 corresponding ACK request as an offer/answer exchange. Consequently, = the rules regarding glare situations applicable to offer/answer=20 exchanges are also applicable to those exchanges.=A1=B1=20 =20 Here, we are not able to conclude whether both UAs should run session = timer with=20 1800 or 600, or otherwise whether the UPDATE should be rejected.=20 =20 As per my understanding this draft doesn=A1=AFt *explicitly* mention = anything about the Session-Timer, wherein there is an early negotiation. Since = 4028 also doesn=A1=AFt=20 have any reference for early negotiation, so we suggest that it can = better be incorporated in the above mentioned draft[ietf-sipcore-reinvite-04].=20 =20 Please share your opinion and do guide us incase any of the existing RFC/active-draft already captures this.=20 =20 Thanks!=20 =20 Regards,=20 Harbhanu=20 =20 *************************************************************************= *** *********** This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it!=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =20 -------------------------------------------------------- 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. --Boundary_(ID_4BdsttiBAT6hJaVhY1Zfjw) Content-type: text/html; charset=GB2312 Content-transfer-encoding: quoted-printable

Honest thanks for a prompt reply.. = That said, below are some clarifications for your mail = -

 

>> Do it like target refresh, then the 2xx of INVITE/Re-INVITE's SE value should = be as the SE value in the last embedded subsequent session refresh request's = 2xx. 

But then it might break the existing =
clause mentioned in RFC-4028, when the scenario has INV(SE-600) & =
UPDATE(SE-1800),that =A8C
=A1=B0 The UAS MUST NOT increase the value of =
the Session-Expires header field.=A1=B1

 

>> So, I think it is not recommended to sending UPDATE as subsequent session = refresh request in pending INVITE/Re-INVITE.

I suggest to incorporate its clear handling in this draft itself, since anyways it makes an excellent = attempt to clear the muck around all the refresh-request = handling.

IMO this will make the draft a bit = more comprehensive and might baseline/standardize the behavior for other = extension handlings.

 

Thanks = again!

 

Regards,

Harbhanu

 

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

From: = gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Monday, May 24, = 2010 12:21 PM
To: Harbhanu
Cc: sipcore@ietf.org
Subject: Re: [sipcore] = REg. draft-ietf-sipcore-reinvite-04 //Session = Timer

 


Hi,

Not like O/A usage and target refresh usage, there's no explicit definition = of allowing subsequent session refresh request in embedded requests(such as = UPDATE during pending Re-INVITE). So, I think it is not recommended to sending = UPDATE as subsequent session refresh request in pending = INVITE/Re-INVITE.

I'd like to talk more about session timer. If people want to do the = semantics extension for session timer's to allow embedded requests(such as UPDATE = during pending Re-INVITE), there's one suggestion way(INFORMATIVE at = all):

Do it like target refresh, then the 2xx of INVITE/Re-INVITE's SE value = should be as the SE value in the last embedded subsequent session refresh = request's 2xx.

Then, the glare handling for such usage would be the same as the Target = Refresh part in draft-ietf-sipcore-reinvite.

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

Harbhanu <harbhanu@huawei.com>
=B7=A2=BC=FE=C8=CB:  sipcore-bounces@ietf.org

2010-05-24 13:40

=CA=D5=BC=FE=C8=CB

=

sipcore@ietf.org =

=B3=AD=CB=CD

 

=D6=F7=CC=E2

[sipcore] REg. = draft-ietf-sipcore-reinvite-04

 

 

 




 
1. UE1 --- INVITE SE-1800 =A8=A4 = UE2
2. UE1 <--- 183 ------------------ UE2
 
3. UE1 --- UPDATE SE-600 =A8=A4 = UE2
4. UE1 <--- 200 UPDATE -SE600 -- UE2
 
5. UE1 <--- 200 INVITE SE-1800 -- UE2
 
Please refer the scenario above for handling of Session-Timer, (4028). =
As per the Draft-ietf-sipcore-reinvite-04 section 4.5:
=A1=B0  When checking for glare = situations, UAs MUST treat every UPDATE
   request as if it contained an offer.  Additionally, UAs MUST = treat
   the exchange of a 2xx response to an INVITE request and = its
   corresponding ACK request as an offer/answer exchange.  Consequently,
   the rules regarding glare situations applicable to = offer/answer
   exchanges are also applicable to those = exchanges.=A1=B1
  =
Here, we are not able to conclude whether both UAs should run session timer = with
1800 or 600, or otherwise whether the UPDATE should be = rejected.
 
As per my understanding this draft doesn=A1=AFt *explicitly* mention anything about the Session-Timer, wherein there is an early = negotiation. Since 4028 also doesn=A1=AFt
have any reference for early negotiation, so we suggest that it can better be incorporated in the above mentioned draft[ietf-sipcore-reinvite-04<= /font>].
 
Please share your opinion and do guide us incase any of the existing = RFC/active-draft already captures this.
 
Thanks!
 
Regards,
Harbhanu
 
****************************= ***********************************************************
This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not = limited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient's) is prohibited. If you receive this = e-mail in error, please notify the sender by phone or email immediately and = delete it!
 ______________________________________________= _
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore 

 
----------------------------------------------=
----------
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.
--Boundary_(ID_4BdsttiBAT6hJaVhY1Zfjw)-- From shinji.okumura@softfront.jp Mon May 24 01:02:43 2010 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 6496D3A6AB1 for ; Mon, 24 May 2010 01:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.107 X-Spam-Level: X-Spam-Status: No, score=-95.107 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 9chFSMHQLXNy for ; Mon, 24 May 2010 01:02:42 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 892633A6A66 for ; Mon, 24 May 2010 01:02:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id A124F428015; Mon, 24 May 2010 17:02:33 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkMNsTVronhA; Mon, 24 May 2010 17:02:32 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 6190642800B; Mon, 24 May 2010 17:02:31 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 24 May 2010 17:02:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC21D@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <70CAF9873ACDA5shinji.okumura@softfront.jp> <747A6506A991724FB09B129B79D5FEB614816DC21D@EXMBXCLUS01.citservers.local> Message-Id: Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 24 May 2010 08:02:43 -0000 Brett, Brett Tate Sun, 23 May 2010 10:34:47 -0700 (snip) >> >If caller receives INVITE 2xx without offer/answer, how SHOULD >> >or MUST the caller respond if UPDATE without SDP is received >> >from called party prior to sending ACK (if not willing to >> >queue or drop UPDATE): 491 or 500? Is it a SHOULD or MUST? >> >> UA may send 2xx to UPDATE. Because the INVITE transaction has >> been completed. > >If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, >the following snippets apply. > >"When checking for glare situations, UAs MUST treat every UPDATE >request as if it contained an offer. Additionally, UAs MUST treat >the exchange of a 2xx response to an INVITE request and its >corresponding ACK request as an offer/answer exchange." IMO in this case, if a 2xx to a reINVITE is not an offer nor an answer, a UAS may accept an UPDATE. At least from an offer-answer perspective, the above additional rule is unnecessary. Regards, Shinji >"Similarly, if an UPDATE is received that contains an offer, and >the UAS has received an offer (in an UPDATE, PRACK, or INVITE) >to which it has not yet generated an answer, the UAS MUST reject >the UPDATE with a 500 response, and MUST include a Retry-After >header field with a randomly chosen value between 0 and 10 seconds." From gao.yang2@zte.com.cn Mon May 24 01:22:21 2010 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 0835D3A6AC7 for ; Mon, 24 May 2010 01:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.892 X-Spam-Level: X-Spam-Status: No, score=-95.892 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 3Lo8NodUyRry for ; Mon, 24 May 2010 01:22:17 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3C9BC3A6ACC for ; Mon, 24 May 2010 01:22:02 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 24 May 2010 16:15:47 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.2876834374; Mon, 24 May 2010 16:05:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4O81oIN049300; Mon, 24 May 2010 16:01:56 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <640956B207584AB5AF5C377AAB6F8C1A@china.huawei.com> To: Harbhanu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 15:59:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 16:01:41, Serialize complete at 2010-05-24 16:01:41 Content-Type: multipart/alternative; boundary="=_alternative 002C11A54825772D_=" X-MAIL: mse2.zte.com.cn o4O81oIN049300 Cc: sipcore@ietf.org Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer 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, 24 May 2010 08:22:22 -0000 This is a multipart message in MIME format. --=_alternative 002C11A54825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkhhcmJoYW51IDxoYXJiaGFudUBodWF3ZWkuY29tPiDQtNPaIDIwMTAtMDUtMjQgMTU6 MjQ6MDA6DQoNCj4gSG9uZXN0IHRoYW5rcyBmb3IgYSBwcm9tcHQgcmVwbHkuLiBUaGF0IHNhaWQs IGJlbG93IGFyZSBzb21lIA0KPiBjbGFyaWZpY2F0aW9ucyBmb3IgeW91ciBtYWlsIC0NCg0KV2Vs Y29tZS4NCg0KPiANCj4gPj4gRG8gaXQgbGlrZSB0YXJnZXQgcmVmcmVzaCwgdGhlbiB0aGUgMnh4 IG9mIElOVklURS9SZS1JTlZJVEUncyBTRSANCj4gdmFsdWUgc2hvdWxkIGJlIGFzIHRoZSBTRSB2 YWx1ZSBpbiB0aGUgbGFzdCBlbWJlZGRlZCBzdWJzZXF1ZW50IA0KPiBzZXNzaW9uIHJlZnJlc2gg cmVxdWVzdCdzIDJ4eC4gDQoNCj4gQnV0IHRoZW4gaXQgbWlnaHQgYnJlYWsgdGhlIGV4aXN0aW5n IGNsYXVzZSBtZW50aW9uZWQgaW4gUkZDLTQwMjgsIA0KPiB3aGVuIHRoZSBzY2VuYXJpbyBoYXMg SU5WKFNFLTYwMCkgJiBVUERBVEUoU0UtMTgwMCksdGhhdCCoQw0KPiChsCBUaGUgVUFTIE1VU1Qg Tk9UIGluY3JlYXNlIHRoZSB2YWx1ZSBvZiB0aGUgU2Vzc2lvbi1FeHBpcmVzIGhlYWRlciANCmZp ZWxkLqGxDQoNCldoYXQgSSBzdWdnZXN0IGlzIGFib3V0IHRoZSBwb3RlbnRpYWwgZXh0ZW5zaW9u LiBJZiBwZW9wbGUgd2FudCB0byBkbyB0aGUgDQpleHRlbnNpb24sIGl0IHdvdWxkIGJlIGEgVVBE QVRFIG9mIFJGQzQwMjguDQoNCkJ1dCBieSBteXNlbGYsIEkgdGhpbmsgdGhlcmUncyBubyByYXRp b25hbCByZWFzb24vdXNlLWNhc2UgdG8gZG8gc3VjaCANCmV4dGVuc2lvbiwgY3VycmVudGx5LiBJ ZiB5b3UgaGF2ZSBzb21lLCBwbGVhc2Ugc2hhcmUgdGhlbSB3aXRoIHVzLg0KDQo+IA0KPiA+PiBT bywgSSB0aGluayBpdCBpcyBub3QgcmVjb21tZW5kZWQgdG8gc2VuZGluZyBVUERBVEUgYXMgc3Vi c2VxdWVudA0KPiBzZXNzaW9uIHJlZnJlc2ggcmVxdWVzdCBpbiBwZW5kaW5nIElOVklURS9SZS1J TlZJVEUuDQo+IEkgc3VnZ2VzdCB0byBpbmNvcnBvcmF0ZSBpdHMgY2xlYXIgaGFuZGxpbmcgaW4g dGhpcyBkcmFmdCBpdHNlbGYsIA0KPiBzaW5jZSBhbnl3YXlzIGl0IG1ha2VzIGFuIGV4Y2VsbGVu dCBhdHRlbXB0IHRvIGNsZWFyIHRoZSBtdWNrIGFyb3VuZA0KPiBhbGwgdGhlIHJlZnJlc2gtcmVx dWVzdCBoYW5kbGluZy4NCj4gSU1PIHRoaXMgd2lsbCBtYWtlIHRoZSBkcmFmdCBhIGJpdCBtb3Jl IGNvbXByZWhlbnNpdmUgYW5kIG1pZ2h0IA0KPiBiYXNlbGluZS9zdGFuZGFyZGl6ZSB0aGUgYmVo YXZpb3IgZm9yIG90aGVyIGV4dGVuc2lvbiBoYW5kbGluZ3MuDQoNCkhlcmUsIHRoZXJlIGFyZSB0 aHJlZSB0aGluZ3MgaGVyZToNCg0KMS4gRG8gcGVvcGxlIHdhbnQgdG8gZG8gc3VjaCBVUERBVEUg Zm9yIFJGQzQwMjg/IC8vQnkgbXlzZWxmLCBJIGFtIG5vdCANCndhbnQgdG8gZG8gc3VjaCBVUERB VEUsIHVubGVzcyB0aGVyZSdzIHN0cm9uZyByZWFzb24uDQoNCjIuIEhvdyB3b3VsZCB0aGUgVVBE QVRFIGRldGFpbHMgYmU/IC8vTXkgc3VnZ2VzdGlvbiBpcyBqdXN0IGluZm9ybWF0aXZlLg0KDQoz LiBXaGVyZSBzaG91bGQgdGhlIFVQREFURSBiZSwgaWYgcGVvcGxlIG5lZWQgaXQuIC8vSSdkIGxp a2UgdG8gdGFsayB0aGUgDQpmaXJzdCB0d28gdGhpbmdzIGZyaXN0bHkuDQoNClRoYW5rcywNCg0K R2FvDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLg0K --=_alternative 002C11A54825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPkhhcmJoYW51ICZsdDtoYXJiaGFudUBodWF3ZWkuY29tJmd0OyDQ tNPaIDIwMTAtMDUtMjQNCjE1OjI0OjAwOjxicj4NCjxicj4NCiZndDsgSG9uZXN0IHRoYW5rcyBm b3IgYSBwcm9tcHQgcmVwbHkuLiBUaGF0IHNhaWQsIGJlbG93IGFyZSBzb21lIDxicj4NCiZndDsg Y2xhcmlmaWNhdGlvbnMgZm9yIHlvdXIgbWFpbCAtPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5XZWxjb21lLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg Jmd0OyZndDsgRG8gaXQgbGlrZSB0YXJnZXQgcmVmcmVzaCwgdGhlbiB0aGUNCjJ4eCBvZiBJTlZJ VEUvUmUtSU5WSVRFJ3MgU0UgPGJyPg0KJmd0OyB2YWx1ZSBzaG91bGQgYmUgYXMgdGhlIFNFIHZh bHVlIGluIHRoZSBsYXN0IGVtYmVkZGVkIHN1YnNlcXVlbnQgPGJyPg0KJmd0OyBzZXNzaW9uIHJl ZnJlc2ggcmVxdWVzdCdzIDJ4eC4gPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IEJ1dCB0aGVuIGl0IG1pZ2h0IGJyZWFrIHRoZSBleGlzdGluZyBjbGF1c2UgbWVu dGlvbmVkDQppbiBSRkMtNDAyOCwgPGJyPg0KJmd0OyB3aGVuIHRoZSBzY2VuYXJpbyBoYXMgSU5W KFNFLTYwMCkgJmFtcDsgVVBEQVRFKFNFLTE4MDApLHRoYXQgqEM8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgobAgVGhlIFVBUyBNVVNUIE5PVCBpbmNyZWFzZSB0aGUgdmFs dWUgb2YgdGhlDQpTZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxkLqGxPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5XaGF0IEkgc3VnZ2VzdCBpcyBhYm91dCB0aGUgcG90 ZW50aWFsIGV4dGVuc2lvbi4gSWYNCnBlb3BsZSB3YW50IHRvIGRvIHRoZSBleHRlbnNpb24sIGl0 IHdvdWxkIGJlIGEgVVBEQVRFIG9mIFJGQzQwMjguPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5CdXQgYnkgbXlzZWxmLCBJIHRoaW5rIHRoZXJlJ3Mgbm8gcmF0aW9uYWwg cmVhc29uL3VzZS1jYXNlDQp0byBkbyBzdWNoIGV4dGVuc2lvbiwgY3VycmVudGx5LiBJZiB5b3Ug aGF2ZSBzb21lLCBwbGVhc2Ugc2hhcmUgdGhlbSB3aXRoDQp1cy48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZndDsmZ3Q7IFNvLCBJIHRoaW5rIGl0IGlzIG5vdCByZWNvbW1lbmRl ZCB0bw0Kc2VuZGluZyBVUERBVEUgYXMgc3Vic2VxdWVudDxicj4NCiZndDsgc2Vzc2lvbiByZWZy ZXNoIHJlcXVlc3QgaW4gcGVuZGluZyBJTlZJVEUvUmUtSU5WSVRFLjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJIHN1Z2dlc3QgdG8gaW5jb3Jwb3JhdGUgaXRzIGNsZWFy IGhhbmRsaW5nIGluDQp0aGlzIGRyYWZ0IGl0c2VsZiwgPGJyPg0KJmd0OyBzaW5jZSBhbnl3YXlz IGl0IG1ha2VzIGFuIGV4Y2VsbGVudCBhdHRlbXB0IHRvIGNsZWFyIHRoZSBtdWNrIGFyb3VuZDxi cj4NCiZndDsgYWxsIHRoZSByZWZyZXNoLXJlcXVlc3QgaGFuZGxpbmcuPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IElNTyB0aGlzIHdpbGwgbWFrZSB0aGUgZHJhZnQgYSBi aXQgbW9yZSBjb21wcmVoZW5zaXZlDQphbmQgbWlnaHQgPGJyPg0KJmd0OyBiYXNlbGluZS9zdGFu ZGFyZGl6ZSB0aGUgYmVoYXZpb3IgZm9yIG90aGVyIGV4dGVuc2lvbiBoYW5kbGluZ3MuPC9mb250 PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IZXJlLCB0aGVyZSBhcmUgdGhyZWUg dGhpbmdzIGhlcmU6PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4xLiBE byBwZW9wbGUgd2FudCB0byBkbyBzdWNoIFVQREFURSBmb3IgUkZDNDAyOD8gLy9CeQ0KbXlzZWxm LCBJIGFtIG5vdCB3YW50IHRvIGRvIHN1Y2ggVVBEQVRFLCB1bmxlc3MgdGhlcmUncyBzdHJvbmcg cmVhc29uLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Mi4gSG93IHdv dWxkIHRoZSBVUERBVEUgZGV0YWlscyBiZT8gLy9NeSBzdWdnZXN0aW9uDQppcyBqdXN0IGluZm9y bWF0aXZlLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+My4gV2hlcmUg c2hvdWxkIHRoZSBVUERBVEUgYmUsIGlmIHBlb3BsZSBuZWVkIGl0Lg0KLy9JJ2QgbGlrZSB0byB0 YWxrIHRoZSBmaXJzdCB0d28gdGhpbmdzIGZyaXN0bHkuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5UaGFua3MsPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5HYW88L2ZvbnQ+PC90dD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDto YXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQm bmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8 L3ByZT4= --=_alternative 002C11A54825772D_=-- From john.elwell@siemens-enterprise.com Mon May 24 02:41:44 2010 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 E94D83A6DF3 for ; Mon, 24 May 2010 02:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_05=-1.11] 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 nE6dXOi7mbVm for ; Mon, 24 May 2010 02:41:44 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B500C3A6DEA for ; Mon, 24 May 2010 02:41:43 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-265951; Mon, 24 May 2010 11:41:34 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id E5AE123F0278; Mon, 24 May 2010 11:41:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 24 May 2010 11:41:34 +0200 From: "Elwell, John" To: Brett Tate , "sipcore@ietf.org" Date: Mon, 24 May 2010 11:41:33 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBig Message-ID: References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 09:41:45 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: 21 May 2010 18:34 > To: sipcore@ietf.org > Subject: [sipcore] draft-ietf-sipcore-reinvite-04: glare and=20 > UPDATE without SDP >=20 > Howdy, >=20 > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate=20 > that an UPDATE without SDP should be treated (from a glare=20 > perspective) as though it contained an offer SDP. However I=20 > currently find the definition of "glare" and the expected=20 > behavior to be ambiguous. >=20 > What is the precise meaning of glare? I ask mainly because=20 > some vendors send a 491 when an RFC indicates to send a 500. >=20 > If INVITE contains offer SDP and 18x was not reliable, how=20 > SHOULD the called party respond if UPDATE without SDP is=20 > received from caller: 491, 500, or process as though no glare? >=20 > If INVITE contains offer SDP and 18x was not reliable, how=20 > SHOULD the caller respond if UPDATE without SDP is received=20 > from called party: 491, 500, or process as though no glare? [JRE] I believe these two situations are both valid and should not result i= n a 4xx/5xx/6xx response unless something else is wrong with the request. John >=20 > If caller receives INVITE 2xx without offer/answer, how=20 > SHOULD or MUST the caller respond if UPDATE without SDP is=20 > received from called party prior to sending ACK (if not=20 > willing to queue or drop UPDATE): 491 or 500? Is it a SHOULD or MUST? >=20 >=20 > Thanks, > Brett >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From brett@broadsoft.com Mon May 24 04:56:05 2010 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 246EB3A6BAB for ; Mon, 24 May 2010 04:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.617, 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 RhtKmgkX51q4 for ; Mon, 24 May 2010 04:56:04 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 36FFC3A6B30 for ; Mon, 24 May 2010 04:56:04 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 24 May 2010 04:55:56 -0700 From: Brett Tate To: "Elwell, John" , "sipcore@ietf.org" Date: Mon, 24 May 2010 04:54:51 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0A= Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 11:56:05 -0000 > > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate > > that an UPDATE without SDP should be treated (from a glare > > perspective) as though it contained an offer SDP. However I > > currently find the definition of "glare" and the expected > > behavior to be ambiguous. > > > > What is the precise meaning of glare? I ask mainly because > > some vendors send a 491 when an RFC indicates to send a 500. > > > > If INVITE contains offer SDP and 18x was not reliable, how > > SHOULD the called party respond if UPDATE without SDP is > > received from caller: 491, 500, or process as though no glare? > > > > If INVITE contains offer SDP and 18x was not reliable, how > > SHOULD the caller respond if UPDATE without SDP is received > > from called party: 491, 500, or process as though no glare? > > [JRE] I believe these two situations are both valid and should not > result in a 4xx/5xx/6xx response unless something else is wrong with > the request. That was true before draft-ietf-sipcore-reinvite. However it looks like th= e following snippets make it no longer true. Draft-ietf-sipcore-reinvite section 3.5: "An UPDATE request without an offer can change dialog parameters. So can a non-2xx final response to a re-INVITE request or a 2xx response to an INVITE request (re-INVITE or initial INVITE). However, there are no rules to avoid a collision between an offerless UPDATE request and a final response to an INVITE request. The rules in Section 4.5, which are given in the context of target refreshes, cover these types of collisions as well. Therefore, there is no need to specify further rules here." Draft-ietf-sipcore-reinvite section 4.5: "When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer." RFC3311 section 5.2: "If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds." From brett@broadsoft.com Mon May 24 05:07:39 2010 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 8234F3A6E0D for ; Mon, 24 May 2010 05:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 mZIQ0KLJbaar for ; Mon, 24 May 2010 05:07:38 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 9D50F3A6DEC for ; Mon, 24 May 2010 05:07:38 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 24 May 2010 05:07:31 -0700 From: Brett Tate To: OKUMURA Shinji , "sipcore@ietf.org" Date: Mon, 24 May 2010 05:06:28 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP Thread-Index: Acr7F4tWoBAI2FCjTGSmQEXoxUMlLAAIP0yg Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC31A@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <70CAF9873ACDA5shinji.okumura@softfront.jp> <747A6506A991724FB09B129B79D5FEB614816DC21D@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 24 May 2010 12:07:39 -0000 > >If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, > >the following snippets apply. > > > >"When checking for glare situations, UAs MUST treat every UPDATE > >request as if it contained an offer. Additionally, UAs MUST treat > >the exchange of a 2xx response to an INVITE request and its > >corresponding ACK request as an offer/answer exchange." >=20 > IMO in this case, if a 2xx to a reINVITE is not an offer nor > an answer, a UAS may accept an UPDATE. > At least from an offer-answer perspective, the above additional > rule is unnecessary. Draft-ietf-sipcore-reinvite has changed the offer/answer rules by forcing o= ffer/answer rules upon requests/responses which don't actually contain an o= ffer or answer. And for completeness, draft-ietf-sipcore-reinvite (such as the above snippe= t) has impacts on both INVITE and re-INVITE. From gao.yang2@zte.com.cn Mon May 24 05:19:12 2010 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 D5AD23A6DCE; Mon, 24 May 2010 05:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.011 X-Spam-Level: X-Spam-Status: No, score=-96.011 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 mNGfLPI-qVV7; Mon, 24 May 2010 05:19:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 3A8193A6E13; Mon, 24 May 2010 05:19:09 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368872001811080; Mon, 24 May 2010 20:12:35 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.5174332398; Mon, 24 May 2010 20:18:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4OCIvYp060023; Mon, 24 May 2010 20:18:57 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC31A@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 20:16:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 20:18:37, Serialize complete at 2010-05-24 20:18:37 Content-Type: multipart/alternative; boundary="=_alternative 004397714825772D_=" X-MAIL: mse2.zte.com.cn o4OCIvYp060023 Cc: OKUMURA Shinji , "sipcore@ietf.org" , sipcore-bounces@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 24 May 2010 12:19:13 -0000 This is a multipart message in MIME format. --=_alternative 004397714825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHRoZSB0ZXh0IGRlY2xhcmVkLCBzdWNoIHJ1bGVzIGFyZSB1c2VkIFdoZW4gY2hl Y2tpbmcgZm9yIGdsYXJlIA0Kc2l0dWF0aW9ucy4NCkFueSBjYXNlcyB3aXRob3V0IGFtYmlndWl0 eSB3b3VsZCBiZSBoYW5kbGVkIGFzIFJGQzMyNjEgYW5kIDMzMTEuDQoNClRoYW5rcywNCg0KR2Fv DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEy DQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6 IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQoNCg0KQnJldHQgVGF0ZSA8YnJldHRAYnJvYWRzb2Z0LmNvbT4gDQq3orz+yMs6ICBzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDUtMjQgMjA6MDYNCg0KytW8/sjLDQpPS1VNVVJB IFNoaW5qaSA8c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwPiwgInNpcGNvcmVAaWV0Zi5vcmci IA0KPHNpcGNvcmVAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINClJlOiBbc2lwY29yZV0gZHJhZnQt aWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0OiBnbGFyZSBhbmQgVVBEQVRFIHdpdGhvdXRTRFANCg0K DQoNCg0KDQoNCj4gPklmIEkgdW5kZXJzdGFuZCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUg YW5kIFJGQzMzMTEgY29ycmVjdGx5LA0KPiA+dGhlIGZvbGxvd2luZyBzbmlwcGV0cyBhcHBseS4N Cj4gPg0KPiA+IldoZW4gY2hlY2tpbmcgZm9yIGdsYXJlIHNpdHVhdGlvbnMsIFVBcyBNVVNUIHRy ZWF0IGV2ZXJ5IFVQREFURQ0KPiA+cmVxdWVzdCBhcyBpZiBpdCBjb250YWluZWQgYW4gb2ZmZXIu ICBBZGRpdGlvbmFsbHksIFVBcyBNVVNUIHRyZWF0DQo+ID50aGUgZXhjaGFuZ2Ugb2YgYSAyeHgg cmVzcG9uc2UgdG8gYW4gSU5WSVRFIHJlcXVlc3QgYW5kIGl0cw0KPiA+Y29ycmVzcG9uZGluZyBB Q0sgcmVxdWVzdCBhcyBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuIg0KPiANCj4gSU1PIGluIHRo aXMgY2FzZSwgaWYgYSAyeHggdG8gYSByZUlOVklURSBpcyBub3QgYW4gb2ZmZXIgbm9yDQo+IGFu IGFuc3dlciwgYSBVQVMgbWF5IGFjY2VwdCBhbiBVUERBVEUuDQo+IEF0IGxlYXN0IGZyb20gYW4g b2ZmZXItYW5zd2VyIHBlcnNwZWN0aXZlLCB0aGUgYWJvdmUgYWRkaXRpb25hbA0KPiBydWxlIGlz IHVubmVjZXNzYXJ5Lg0KDQpEcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUgaGFzIGNoYW5nZWQg dGhlIG9mZmVyL2Fuc3dlciBydWxlcyBieSBmb3JjaW5nIA0Kb2ZmZXIvYW5zd2VyIHJ1bGVzIHVw b24gcmVxdWVzdHMvcmVzcG9uc2VzIHdoaWNoIGRvbid0IGFjdHVhbGx5IGNvbnRhaW4gYW4gDQpv ZmZlciBvciBhbnN3ZXIuDQoNCkFuZCBmb3IgY29tcGxldGVuZXNzLCBkcmFmdC1pZXRmLXNpcGNv cmUtcmVpbnZpdGUgKHN1Y2ggYXMgdGhlIGFib3ZlIA0Kc25pcHBldCkgaGFzIGltcGFjdHMgb24g Ym90aCBJTlZJVEUgYW5kIHJlLUlOVklURS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBz eXN0ZW0uDQo= --=_alternative 004397714825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgdGhlIHRleHQgZGVjbGFyZWQsIHN1 Y2ggcnVsZXMgYXJlDQp1c2VkIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxiPldoZW4gY2hlY2tpbmcgZm9yIGdsYXJlDQpzaXR1YXRpb25zPC9iPjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGI+LjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkFueSBjYXNlcyB3aXRob3V0IGFtYmlndWl0eSB3b3VsZCBiZQ0K aGFuZGxlZCBhcyBSRkMzMjYxIGFuZCAzMzExLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4N CiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIx MTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdh by55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ QnJldHQgVGF0ZSAmbHQ7YnJldHRAYnJvYWRzb2Z0LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIw MTAtMDUtMjQgMjA6MDY8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+T0tVTVVSQSBTaGluamkgJmx0O3NoaW5qaS5va3VtdXJhQHNvZnRmcm9u dC5qcCZndDssDQomcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGlldGYu b3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+UmU6IFtzaXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6DQpn bGFyZSBhbmQgVVBEQVRFIHdpdGhvdXRTRFA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0O0lmIEkgdW5kZXJzdGFuZCBkcmFm dC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUNCmFuZCBSRkMzMzExIGNvcnJlY3RseSw8YnI+DQomZ3Q7 ICZndDt0aGUgZm9sbG93aW5nIHNuaXBwZXRzIGFwcGx5Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZxdW90O1doZW4gY2hlY2tpbmcgZm9yIGdsYXJlIHNpdHVhdGlvbnMsIFVBcyBNVVNU IHRyZWF0IGV2ZXJ5DQpVUERBVEU8YnI+DQomZ3Q7ICZndDtyZXF1ZXN0IGFzIGlmIGl0IGNvbnRh aW5lZCBhbiBvZmZlci4gJm5ic3A7QWRkaXRpb25hbGx5LCBVQXMgTVVTVA0KdHJlYXQ8YnI+DQom Z3Q7ICZndDt0aGUgZXhjaGFuZ2Ugb2YgYSAyeHggcmVzcG9uc2UgdG8gYW4gSU5WSVRFIHJlcXVl c3QgYW5kIGl0czxicj4NCiZndDsgJmd0O2NvcnJlc3BvbmRpbmcgQUNLIHJlcXVlc3QgYXMgYW4g b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLiZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBJTU8gaW4g dGhpcyBjYXNlLCBpZiBhIDJ4eCB0byBhIHJlSU5WSVRFIGlzIG5vdCBhbiBvZmZlciBub3I8YnI+ DQomZ3Q7IGFuIGFuc3dlciwgYSBVQVMgbWF5IGFjY2VwdCBhbiBVUERBVEUuPGJyPg0KJmd0OyBB dCBsZWFzdCBmcm9tIGFuIG9mZmVyLWFuc3dlciBwZXJzcGVjdGl2ZSwgdGhlIGFib3ZlIGFkZGl0 aW9uYWw8YnI+DQomZ3Q7IHJ1bGUgaXMgdW5uZWNlc3NhcnkuPGJyPg0KPGJyPg0KRHJhZnQtaWV0 Zi1zaXBjb3JlLXJlaW52aXRlIGhhcyBjaGFuZ2VkIHRoZSBvZmZlci9hbnN3ZXIgcnVsZXMgYnkg Zm9yY2luZw0Kb2ZmZXIvYW5zd2VyIHJ1bGVzIHVwb24gcmVxdWVzdHMvcmVzcG9uc2VzIHdoaWNo IGRvbid0IGFjdHVhbGx5IGNvbnRhaW4NCmFuIG9mZmVyIG9yIGFuc3dlci48YnI+DQo8YnI+DQpB bmQgZm9yIGNvbXBsZXRlbmVzcywgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlIChzdWNoIGFz IHRoZSBhYm92ZSBzbmlwcGV0KQ0KaGFzIGltcGFjdHMgb24gYm90aCBJTlZJVEUgYW5kIHJlLUlO VklURS48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxi cj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjxi cj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24m bmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNw O2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVs eSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2Fu aXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZu YnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZu YnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5 Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtk aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5k Jm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZu YnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29s ZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5i c3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Jl Y2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFz ZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZu YnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hh cyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZu YnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwv cHJlPg== --=_alternative 004397714825772D_=-- From john.elwell@siemens-enterprise.com Mon May 24 05:23:16 2010 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 E33A03A6DCE for ; Mon, 24 May 2010 05:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_05=-1.11] 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 tV95WyqBIHyA for ; Mon, 24 May 2010 05:22:56 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CA1643A6E18 for ; Mon, 24 May 2010 05:22:55 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-266004; Mon, 24 May 2010 14:22:47 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id F18181EB82AB; Mon, 24 May 2010 14:22:46 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 24 May 2010 14:22:47 +0200 From: "Elwell, John" To: Brett Tate , "sipcore@ietf.org" Date: Mon, 24 May 2010 14:22:44 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQA== Message-ID: References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 12:23:16 -0000 Brett, Thanks for the clarification. So the changes do not prohibit the use of UPD= ATE after only a non-reliable provisional response, provided the UPDATE req= uest does not contain an offer - correct? If it does contain an offer it is= subject to the glare rules. John=20 > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com]=20 > Sent: 24 May 2010 12:55 > To: Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare=20 > and UPDATE without SDP >=20 > > > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate > > > that an UPDATE without SDP should be treated (from a glare > > > perspective) as though it contained an offer SDP. However I > > > currently find the definition of "glare" and the expected > > > behavior to be ambiguous. > > > > > > What is the precise meaning of glare? I ask mainly because > > > some vendors send a 491 when an RFC indicates to send a 500. > > > > > > If INVITE contains offer SDP and 18x was not reliable, how > > > SHOULD the called party respond if UPDATE without SDP is > > > received from caller: 491, 500, or process as though no glare? > > > > > > If INVITE contains offer SDP and 18x was not reliable, how > > > SHOULD the caller respond if UPDATE without SDP is received > > > from called party: 491, 500, or process as though no glare? > > > > [JRE] I believe these two situations are both valid and should not > > result in a 4xx/5xx/6xx response unless something else is wrong with > > the request. >=20 > That was true before draft-ietf-sipcore-reinvite. However it=20 > looks like the following snippets make it no longer true. >=20 > Draft-ietf-sipcore-reinvite section 3.5: >=20 > "An UPDATE request without an offer can change dialog parameters. So > can a non-2xx final response to a re-INVITE request or a 2xx response > to an INVITE request (re-INVITE or initial INVITE). However, there > are no rules to avoid a collision between an offerless UPDATE request > and a final response to an INVITE request. The rules in Section 4.5, > which are given in the context of target refreshes, cover these types > of collisions as well. Therefore, there is no need to specify > further rules here." >=20 > Draft-ietf-sipcore-reinvite section 4.5: >=20 > "When checking for glare situations, UAs MUST treat every UPDATE > request as if it contained an offer." >=20 > RFC3311 section 5.2: >=20 > "If an UPDATE is received that contains an offer, and the UAS has > generated an offer (in an UPDATE, PRACK or INVITE) to which it has > not yet received an answer, the UAS MUST reject the UPDATE with a 491 > response. Similarly, if an UPDATE is received that contains an > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > INVITE) to which it has not yet generated an answer, the UAS MUST > reject the UPDATE with a 500 response, and MUST include a Retry-After > header field with a randomly chosen value between 0 and 10 seconds." >=20 > = From brett@broadsoft.com Mon May 24 05:24:24 2010 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 9D7333A6E18 for ; Mon, 24 May 2010 05:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, J_CHICKENPOX_32=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 JDSKNbd3hOeu for ; Mon, 24 May 2010 05:24:23 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id B269A3A6E1B for ; Mon, 24 May 2010 05:24:20 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 24 May 2010 05:24:11 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 05:23:09 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP Thread-Index: Acr67mZ6ZWM3IyjgQk2W/wq5wAImyAAS1QdQ Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC32C@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DC21D@EXMBXCLUS01.citservers.local> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 24 May 2010 12:24:24 -0000 > While UAS(as this is about Re-INVITE, UAS could be more proper here)=20 Where does it say draft-ietf-sipcore-reinvite sections 3.5 and 4.5 are limi= ted to re-INVITE? Notice section 3.5 explicitly indicates "re-INVITE or in= itial INVITE". Section 3.5 indicates: "An UPDATE request without an offer can change dialog parameters. So can a non-2xx final response to a re-INVITE request or a 2xx response to an INVITE request (re-INVITE or initial INVITE). However, there are no rules to avoid a collision between an offerless UPDATE request and a final response to an INVITE request. The rules in Section 4.5, which are given in the context of target refreshes, cover these types of collisions as well. Therefore, there is no need to specify further rules here." > This is no a glare situation. UAC can handle the UPDATE OK.=20 Per draft-ietf-sipcore-reinvite sections 3.5 and 4.5 it is a 500 response s= ituation. The "offer" was within INVITE 2xx even though it contained no SD= P. Another "offer" was within the UPDATE even though it contained no SDP. = Thus per RFC3311, a 500 with Retry-After MUST be returned. From gao.yang2@zte.com.cn Mon May 24 05:31:54 2010 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 E6C1C3A6E3C for ; Mon, 24 May 2010 05:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.989 X-Spam-Level: X-Spam-Status: No, score=-95.989 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 eONV0rV-57u5 for ; Mon, 24 May 2010 05:31:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E5FDB3A6E2F for ; Mon, 24 May 2010 05:31:52 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Mon, 24 May 2010 20:25:17 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 13308.4963286206; Mon, 24 May 2010 20:26:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4OCVqBW071513; Mon, 24 May 2010 20:31:52 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 20:29:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 20:31:32, Serialize complete at 2010-05-24 20:31:32 Content-Type: multipart/alternative; boundary="=_alternative 0044C62A4825772D_=" X-MAIL: mse2.zte.com.cn o4OCVqBW071513 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 12:31:55 -0000 This is a multipart message in MIME format. --=_alternative 0044C62A4825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkFzIEkgc2FpZCBpbiB0aGUgcHJldmlvdXMgbWFpbC4NCg0KU3VjaCBydWxlcyBpbiB0 aGUgdGV4dCdzIDMuNSBhbmQgNC41LCBhcmUgdXNlZCBmb3IgZ2xhcmUgc2l0dWF0aW9ucywgd2hp Y2ggDQpoYXZlIGFtYmlndWl0eS4NCg0KU28sIGl0IGlzIG5vdCB3YW50IHRvIG92ZXJyaWRlIGN1 cnJlbnQgMzI2MSBhbmQgMzMxMSdzIHNlbWFudGljcy4gSXQgaXMgDQpVUERBVEUgYW5kIGNsYXJp ZmljYXRpb24gZm9yIHRoZSAqZGFyayBjb3JuZXIqLCB3aGljaCBpcyBhbWJpZ3VvdXMgY2FzZSBh dCANCmFsbC4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4 NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpCcmV0dCBUYXRlIDxicmV0dEBicm9h ZHNvZnQuY29tPiANCreivP7IyzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNS0y NCAxOTo1NA0KDQrK1bz+yMsNCiJFbHdlbGwsIEpvaG4iIDxqb2huLmVsd2VsbEBzaWVtZW5zLWVu dGVycHJpc2UuY29tPiwgInNpcGNvcmVAaWV0Zi5vcmciIA0KPHNpcGNvcmVAaWV0Zi5vcmc+DQqz rcvNDQoNCtb3zOINClJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0 OiBnbGFyZSBhbmQgVVBEQVRFIHdpdGhvdXQgU0RQDQoNCg0KDQoNCg0KDQo+ID4gRHJhZnQtaWV0 Zi1zaXBjb3JlLXJlaW52aXRlLTA0IHNlY3Rpb25zIDMuNSBhbmQgNC41IGluZGljYXRlDQo+ID4g dGhhdCBhbiBVUERBVEUgd2l0aG91dCBTRFAgc2hvdWxkIGJlIHRyZWF0ZWQgKGZyb20gYSBnbGFy ZQ0KPiA+IHBlcnNwZWN0aXZlKSBhcyB0aG91Z2ggaXQgY29udGFpbmVkIGFuIG9mZmVyIFNEUC4g IEhvd2V2ZXIgSQ0KPiA+IGN1cnJlbnRseSBmaW5kIHRoZSBkZWZpbml0aW9uIG9mICJnbGFyZSIg YW5kIHRoZSBleHBlY3RlZA0KPiA+IGJlaGF2aW9yIHRvIGJlIGFtYmlndW91cy4NCj4gPg0KPiA+ IFdoYXQgaXMgdGhlIHByZWNpc2UgbWVhbmluZyBvZiBnbGFyZT8gIEkgYXNrIG1haW5seSBiZWNh dXNlDQo+ID4gc29tZSB2ZW5kb3JzIHNlbmQgYSA0OTEgd2hlbiBhbiBSRkMgaW5kaWNhdGVzIHRv IHNlbmQgYSA1MDAuDQo+ID4NCj4gPiBJZiBJTlZJVEUgY29udGFpbnMgb2ZmZXIgU0RQIGFuZCAx OHggd2FzIG5vdCByZWxpYWJsZSwgaG93DQo+ID4gU0hPVUxEIHRoZSBjYWxsZWQgcGFydHkgcmVz cG9uZCBpZiBVUERBVEUgd2l0aG91dCBTRFAgaXMNCj4gPiByZWNlaXZlZCBmcm9tIGNhbGxlcjog NDkxLCA1MDAsIG9yIHByb2Nlc3MgYXMgdGhvdWdoIG5vIGdsYXJlPw0KPiA+DQo+ID4gSWYgSU5W SVRFIGNvbnRhaW5zIG9mZmVyIFNEUCBhbmQgMTh4IHdhcyBub3QgcmVsaWFibGUsIGhvdw0KPiA+ IFNIT1VMRCB0aGUgY2FsbGVyIHJlc3BvbmQgaWYgVVBEQVRFIHdpdGhvdXQgU0RQIGlzIHJlY2Vp dmVkDQo+ID4gZnJvbSBjYWxsZWQgcGFydHk6IDQ5MSwgNTAwLCBvciBwcm9jZXNzIGFzIHRob3Vn aCBubyBnbGFyZT8NCj4NCj4gW0pSRV0gSSBiZWxpZXZlIHRoZXNlIHR3byBzaXR1YXRpb25zIGFy ZSBib3RoIHZhbGlkIGFuZCBzaG91bGQgbm90DQo+IHJlc3VsdCBpbiBhIDR4eC81eHgvNnh4IHJl c3BvbnNlIHVubGVzcyBzb21ldGhpbmcgZWxzZSBpcyB3cm9uZyB3aXRoDQo+IHRoZSByZXF1ZXN0 Lg0KDQpUaGF0IHdhcyB0cnVlIGJlZm9yZSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUuICBI b3dldmVyIGl0IGxvb2tzIGxpa2UgDQp0aGUgZm9sbG93aW5nIHNuaXBwZXRzIG1ha2UgaXQgbm8g bG9uZ2VyIHRydWUuDQoNCkRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZSBzZWN0aW9uIDMuNToN Cg0KIkFuIFVQREFURSByZXF1ZXN0IHdpdGhvdXQgYW4gb2ZmZXIgY2FuIGNoYW5nZSBkaWFsb2cg cGFyYW1ldGVycy4gIFNvDQogY2FuIGEgbm9uLTJ4eCBmaW5hbCByZXNwb25zZSB0byBhIHJlLUlO VklURSByZXF1ZXN0IG9yIGEgMnh4IHJlc3BvbnNlDQogdG8gYW4gSU5WSVRFIHJlcXVlc3QgKHJl LUlOVklURSBvciBpbml0aWFsIElOVklURSkuICBIb3dldmVyLCB0aGVyZQ0KIGFyZSBubyBydWxl cyB0byBhdm9pZCBhIGNvbGxpc2lvbiBiZXR3ZWVuIGFuIG9mZmVybGVzcyBVUERBVEUgcmVxdWVz dA0KIGFuZCBhIGZpbmFsIHJlc3BvbnNlIHRvIGFuIElOVklURSByZXF1ZXN0LiAgVGhlIHJ1bGVz IGluIFNlY3Rpb24gNC41LA0KIHdoaWNoIGFyZSBnaXZlbiBpbiB0aGUgY29udGV4dCBvZiB0YXJn ZXQgcmVmcmVzaGVzLCBjb3ZlciB0aGVzZSB0eXBlcw0KIG9mIGNvbGxpc2lvbnMgYXMgd2VsbC4g IFRoZXJlZm9yZSwgdGhlcmUgaXMgbm8gbmVlZCB0byBzcGVjaWZ5DQogZnVydGhlciBydWxlcyBo ZXJlLiINCg0KRHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlIHNlY3Rpb24gNC41Og0KDQoiV2hl biBjaGVja2luZyBmb3IgZ2xhcmUgc2l0dWF0aW9ucywgVUFzIE1VU1QgdHJlYXQgZXZlcnkgVVBE QVRFDQogcmVxdWVzdCBhcyBpZiBpdCBjb250YWluZWQgYW4gb2ZmZXIuIg0KDQpSRkMzMzExIHNl Y3Rpb24gNS4yOg0KDQoiSWYgYW4gVVBEQVRFIGlzIHJlY2VpdmVkIHRoYXQgY29udGFpbnMgYW4g b2ZmZXIsIGFuZCB0aGUgVUFTIGhhcw0KIGdlbmVyYXRlZCBhbiBvZmZlciAoaW4gYW4gVVBEQVRF LCBQUkFDSyBvciBJTlZJVEUpIHRvIHdoaWNoIGl0IGhhcw0KIG5vdCB5ZXQgcmVjZWl2ZWQgYW4g YW5zd2VyLCB0aGUgVUFTIE1VU1QgcmVqZWN0IHRoZSBVUERBVEUgd2l0aCBhIDQ5MQ0KIHJlc3Bv bnNlLiAgU2ltaWxhcmx5LCBpZiBhbiBVUERBVEUgaXMgcmVjZWl2ZWQgdGhhdCBjb250YWlucyBh bg0KIG9mZmVyLCBhbmQgdGhlIFVBUyBoYXMgcmVjZWl2ZWQgYW4gb2ZmZXIgKGluIGFuIFVQREFU RSwgUFJBQ0ssIG9yDQogSU5WSVRFKSB0byB3aGljaCBpdCBoYXMgbm90IHlldCBnZW5lcmF0ZWQg YW4gYW5zd2VyLCB0aGUgVUFTIE1VU1QNCiByZWplY3QgdGhlIFVQREFURSB3aXRoIGEgNTAwIHJl c3BvbnNlLCBhbmQgTVVTVCBpbmNsdWRlIGEgUmV0cnktQWZ0ZXINCiBoZWFkZXIgZmllbGQgd2l0 aCBhIHJhbmRvbWx5IGNob3NlbiB2YWx1ZSBiZXR3ZWVuIDAgYW5kIDEwIHNlY29uZHMuIg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBt YWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkg cHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmlj YXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFu eSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZp ZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0044C62A4825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgSSBzYWlkIGluIHRoZSBwcmV2aW91 cyBtYWlsLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ U3VjaCBydWxlcyBpbiB0aGUgdGV4dCdzIDMuNSBhbmQgNC41LA0KYXJlIHVzZWQgZm9yIGdsYXJl IHNpdHVhdGlvbnMsIHdoaWNoIGhhdmUgYW1iaWd1aXR5LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28sIGl0IGlzIG5vdCB3YW50IHRvIG92ZXJyaWRl IGN1cnJlbnQNCjMyNjEgYW5kIDMzMTEncyBzZW1hbnRpY3MuIEl0IGlzIFVQREFURSBhbmQgY2xh cmlmaWNhdGlvbiBmb3IgdGhlICpkYXJrDQpjb3JuZXIqLCB3aGljaCBpcyBhbWJpZ3VvdXMgY2Fz ZSBhdCBhbGwuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7 OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7 IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248 YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5CcmV0dCBUYXRlICZsdDticmV0 dEBicm9hZHNvZnQuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wNS0yNCAxOTo1NDwvZm9u dD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv dDtFbHdlbGwsIEpvaG4mcXVvdDsgJmx0O2pvaG4uZWx3ZWxsQHNpZW1lbnMtZW50ZXJwcmlzZS5j b20mZ3Q7LA0KJnF1b3Q7c2lwY29yZUBpZXRmLm9yZyZxdW90OyAmbHQ7c2lwY29yZUBpZXRmLm9y ZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0Og0KZ2xh cmUgYW5kIFVQREFURSB3aXRob3V0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NEUDwvZm9u dD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90 YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmZ3Q7IERyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNCBzZWN0aW9ucw0KMy41IGFuZCA0 LjUgaW5kaWNhdGU8YnI+DQomZ3Q7ICZndDsgdGhhdCBhbiBVUERBVEUgd2l0aG91dCBTRFAgc2hv dWxkIGJlIHRyZWF0ZWQgKGZyb20gYSBnbGFyZTxicj4NCiZndDsgJmd0OyBwZXJzcGVjdGl2ZSkg YXMgdGhvdWdoIGl0IGNvbnRhaW5lZCBhbiBvZmZlciBTRFAuICZuYnNwO0hvd2V2ZXINCkk8YnI+ DQomZ3Q7ICZndDsgY3VycmVudGx5IGZpbmQgdGhlIGRlZmluaXRpb24gb2YgJnF1b3Q7Z2xhcmUm cXVvdDsgYW5kIHRoZSBleHBlY3RlZDxicj4NCiZndDsgJmd0OyBiZWhhdmlvciB0byBiZSBhbWJp Z3VvdXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFdoYXQgaXMgdGhlIHByZWNpc2Ug bWVhbmluZyBvZiBnbGFyZT8gJm5ic3A7SSBhc2sgbWFpbmx5IGJlY2F1c2U8YnI+DQomZ3Q7ICZn dDsgc29tZSB2ZW5kb3JzIHNlbmQgYSA0OTEgd2hlbiBhbiBSRkMgaW5kaWNhdGVzIHRvIHNlbmQg YSA1MDAuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElmIElOVklURSBjb250YWlucyBv ZmZlciBTRFAgYW5kIDE4eCB3YXMgbm90IHJlbGlhYmxlLCBob3c8YnI+DQomZ3Q7ICZndDsgU0hP VUxEIHRoZSBjYWxsZWQgcGFydHkgcmVzcG9uZCBpZiBVUERBVEUgd2l0aG91dCBTRFAgaXM8YnI+ DQomZ3Q7ICZndDsgcmVjZWl2ZWQgZnJvbSBjYWxsZXI6IDQ5MSwgNTAwLCBvciBwcm9jZXNzIGFz IHRob3VnaCBubyBnbGFyZT88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgSU5WSVRF IGNvbnRhaW5zIG9mZmVyIFNEUCBhbmQgMTh4IHdhcyBub3QgcmVsaWFibGUsIGhvdzxicj4NCiZn dDsgJmd0OyBTSE9VTEQgdGhlIGNhbGxlciByZXNwb25kIGlmIFVQREFURSB3aXRob3V0IFNEUCBp cyByZWNlaXZlZDxicj4NCiZndDsgJmd0OyBmcm9tIGNhbGxlZCBwYXJ0eTogNDkxLCA1MDAsIG9y IHByb2Nlc3MgYXMgdGhvdWdoIG5vIGdsYXJlPzxicj4NCiZndDs8YnI+DQomZ3Q7IFtKUkVdIEkg YmVsaWV2ZSB0aGVzZSB0d28gc2l0dWF0aW9ucyBhcmUgYm90aCB2YWxpZCBhbmQgc2hvdWxkIG5v dDxicj4NCiZndDsgcmVzdWx0IGluIGEgNHh4LzV4eC82eHggcmVzcG9uc2UgdW5sZXNzIHNvbWV0 aGluZyBlbHNlIGlzIHdyb25nIHdpdGg8YnI+DQomZ3Q7IHRoZSByZXF1ZXN0Ljxicj4NCjxicj4N ClRoYXQgd2FzIHRydWUgYmVmb3JlIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS4gJm5ic3A7 SG93ZXZlciBpdCBsb29rcw0KbGlrZSB0aGUgZm9sbG93aW5nIHNuaXBwZXRzIG1ha2UgaXQgbm8g bG9uZ2VyIHRydWUuPGJyPg0KPGJyPg0KRHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlIHNlY3Rp b24gMy41Ojxicj4NCjxicj4NCiZxdW90O0FuIFVQREFURSByZXF1ZXN0IHdpdGhvdXQgYW4gb2Zm ZXIgY2FuIGNoYW5nZSBkaWFsb2cgcGFyYW1ldGVycy4NCiZuYnNwO1NvPGJyPg0KIGNhbiBhIG5v bi0yeHggZmluYWwgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUgcmVxdWVzdCBvciBhIDJ4eCByZXNw b25zZTxicj4NCiB0byBhbiBJTlZJVEUgcmVxdWVzdCAocmUtSU5WSVRFIG9yIGluaXRpYWwgSU5W SVRFKS4gJm5ic3A7SG93ZXZlciwgdGhlcmU8YnI+DQogYXJlIG5vIHJ1bGVzIHRvIGF2b2lkIGEg Y29sbGlzaW9uIGJldHdlZW4gYW4gb2ZmZXJsZXNzIFVQREFURSByZXF1ZXN0PGJyPg0KIGFuZCBh IGZpbmFsIHJlc3BvbnNlIHRvIGFuIElOVklURSByZXF1ZXN0LiAmbmJzcDtUaGUgcnVsZXMgaW4g U2VjdGlvbg0KNC41LDxicj4NCiB3aGljaCBhcmUgZ2l2ZW4gaW4gdGhlIGNvbnRleHQgb2YgdGFy Z2V0IHJlZnJlc2hlcywgY292ZXIgdGhlc2UgdHlwZXM8YnI+DQogb2YgY29sbGlzaW9ucyBhcyB3 ZWxsLiAmbmJzcDtUaGVyZWZvcmUsIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3BlY2lmeTxicj4NCiBm dXJ0aGVyIHJ1bGVzIGhlcmUuJnF1b3Q7PGJyPg0KPGJyPg0KRHJhZnQtaWV0Zi1zaXBjb3JlLXJl aW52aXRlIHNlY3Rpb24gNC41Ojxicj4NCjxicj4NCiZxdW90O1doZW4gY2hlY2tpbmcgZm9yIGds YXJlIHNpdHVhdGlvbnMsIFVBcyBNVVNUIHRyZWF0IGV2ZXJ5IFVQREFURTxicj4NCiByZXF1ZXN0 IGFzIGlmIGl0IGNvbnRhaW5lZCBhbiBvZmZlci4mcXVvdDs8YnI+DQo8YnI+DQpSRkMzMzExIHNl Y3Rpb24gNS4yOjxicj4NCjxicj4NCiZxdW90O0lmIGFuIFVQREFURSBpcyByZWNlaXZlZCB0aGF0 IGNvbnRhaW5zIGFuIG9mZmVyLCBhbmQgdGhlIFVBUyBoYXM8YnI+DQogZ2VuZXJhdGVkIGFuIG9m ZmVyIChpbiBhbiBVUERBVEUsIFBSQUNLIG9yIElOVklURSkgdG8gd2hpY2ggaXQgaGFzPGJyPg0K IG5vdCB5ZXQgcmVjZWl2ZWQgYW4gYW5zd2VyLCB0aGUgVUFTIE1VU1QgcmVqZWN0IHRoZSBVUERB VEUgd2l0aCBhIDQ5MTxicj4NCiByZXNwb25zZS4gJm5ic3A7U2ltaWxhcmx5LCBpZiBhbiBVUERB VEUgaXMgcmVjZWl2ZWQgdGhhdCBjb250YWlucyBhbjxicj4NCiBvZmZlciwgYW5kIHRoZSBVQVMg aGFzIHJlY2VpdmVkIGFuIG9mZmVyIChpbiBhbiBVUERBVEUsIFBSQUNLLCBvcjxicj4NCiBJTlZJ VEUpIHRvIHdoaWNoIGl0IGhhcyBub3QgeWV0IGdlbmVyYXRlZCBhbiBhbnN3ZXIsIHRoZSBVQVMg TVVTVDxicj4NCiByZWplY3QgdGhlIFVQREFURSB3aXRoIGEgNTAwIHJlc3BvbnNlLCBhbmQgTVVT VCBpbmNsdWRlIGEgUmV0cnktQWZ0ZXI8YnI+DQogaGVhZGVyIGZpZWxkIHdpdGggYSByYW5kb21s eSBjaG9zZW4gdmFsdWUgYmV0d2VlbiAwIGFuZCAxMCBzZWNvbmRzLiZxdW90Ozxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lw Y29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+ DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0044C62A4825772D_=-- From gao.yang2@zte.com.cn Mon May 24 05:34:21 2010 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 3DFB43A6B8F for ; Mon, 24 May 2010 05:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.368 X-Spam-Level: X-Spam-Status: No, score=-95.368 tagged_above=-999 required=5 tests=[AWL=-1.533, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 3nk7Ep9I-tDY for ; Mon, 24 May 2010 05:34:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C25283A6B3A for ; Mon, 24 May 2010 05:34:19 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Mon, 24 May 2010 20:27:52 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3612446977; Mon, 24 May 2010 20:34:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4OCYHpf073289; Mon, 24 May 2010 20:34:21 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC32C@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 20:31:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 20:34:00, Serialize complete at 2010-05-24 20:34:00 Content-Type: multipart/alternative; boundary="=_alternative 0044FF254825772D_=" X-MAIL: mse2.zte.com.cn o4OCYHpf073289 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 24 May 2010 12:34:21 -0000 This is a multipart message in MIME format. --=_alternative 0044FF254825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QnJldHQgVGF0ZSA8YnJldHRAYnJvYWRzb2Z0LmNvbT4g0LTT2iAyMDEwLTA1LTI0IDIwOjIzOjA5 Og0KDQo+ID4gV2hpbGUgVUFTKGFzIHRoaXMgaXMgYWJvdXQgUmUtSU5WSVRFLCBVQVMgY291bGQg YmUgbW9yZSBwcm9wZXIgaGVyZSkgDQo+IA0KPiBXaGVyZSBkb2VzIGl0IHNheSBkcmFmdC1pZXRm LXNpcGNvcmUtcmVpbnZpdGUgc2VjdGlvbnMgMy41IGFuZCA0LjUgDQo+IGFyZSBsaW1pdGVkIHRv IHJlLUlOVklURT8gIE5vdGljZSBzZWN0aW9uIDMuNSBleHBsaWNpdGx5IGluZGljYXRlcyANCj4g InJlLUlOVklURSBvciBpbml0aWFsIElOVklURSIuDQoNCkkgbWVhbiBib3RoIHNpZGUoY2FsbGVy IGFuZCBjYWxsZWUpIGNhbiBzZW5kIFJlLUlOVklURSwgc28gY2FsbGVyIGlzIG5vdCANCnByb3Bl ciBoZXJlLiANCg0KPiANCj4gU2VjdGlvbiAzLjUgaW5kaWNhdGVzOg0KPiAiQW4gVVBEQVRFIHJl cXVlc3Qgd2l0aG91dCBhbiBvZmZlciBjYW4gY2hhbmdlIGRpYWxvZyBwYXJhbWV0ZXJzLiAgU28N Cj4gIGNhbiBhIG5vbi0yeHggZmluYWwgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUgcmVxdWVzdCBv ciBhIDJ4eCByZXNwb25zZQ0KPiAgdG8gYW4gSU5WSVRFIHJlcXVlc3QgKHJlLUlOVklURSBvciBp bml0aWFsIElOVklURSkuICBIb3dldmVyLCB0aGVyZQ0KPiAgYXJlIG5vIHJ1bGVzIHRvIGF2b2lk IGEgY29sbGlzaW9uIGJldHdlZW4gYW4gb2ZmZXJsZXNzIFVQREFURSByZXF1ZXN0DQo+ICBhbmQg YSBmaW5hbCByZXNwb25zZSB0byBhbiBJTlZJVEUgcmVxdWVzdC4gIFRoZSBydWxlcyBpbiBTZWN0 aW9uIDQuNSwNCj4gIHdoaWNoIGFyZSBnaXZlbiBpbiB0aGUgY29udGV4dCBvZiB0YXJnZXQgcmVm cmVzaGVzLCBjb3ZlciB0aGVzZSB0eXBlcw0KPiAgb2YgY29sbGlzaW9ucyBhcyB3ZWxsLiAgVGhl cmVmb3JlLCB0aGVyZSBpcyBubyBuZWVkIHRvIHNwZWNpZnkNCj4gIGZ1cnRoZXIgcnVsZXMgaGVy ZS4iDQo+IA0KPiA8c25pcD4NCj4gDQo+IA0KPiA+IFRoaXMgaXMgbm8gYSBnbGFyZSBzaXR1YXRp b24uIFVBQyBjYW4gaGFuZGxlIHRoZSBVUERBVEUgT0suIA0KPiANCj4gUGVyIGRyYWZ0LWlldGYt c2lwY29yZS1yZWludml0ZSBzZWN0aW9ucyAzLjUgYW5kIDQuNSBpdCBpcyBhIDUwMCANCj4gcmVz cG9uc2Ugc2l0dWF0aW9uLiAgVGhlICJvZmZlciIgd2FzIHdpdGhpbiBJTlZJVEUgMnh4IGV2ZW4g dGhvdWdoIA0KPiBpdCBjb250YWluZWQgbm8gU0RQLiAgQW5vdGhlciAib2ZmZXIiIHdhcyB3aXRo aW4gdGhlIFVQREFURSBldmVuIA0KPiB0aG91Z2ggaXQgY29udGFpbmVkIG5vIFNEUC4gIFRodXMg cGVyIFJGQzMzMTEsIGEgNTAwIHdpdGggUmV0cnktDQo+IEFmdGVyIE1VU1QgYmUgcmV0dXJuZWQu DQoNClBsZWFzZSByZWZlciB0byB0aGUgcHJldmlvdXMgbWFpbC4NCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0044FF254825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5CcmV0dCBUYXRlICZsdDticmV0dEBicm9hZHNvZnQuY29t Jmd0OyDQtNPaIDIwMTAtMDUtMjQNCjIwOjIzOjA5Ojxicj4NCjxicj4NCiZndDsgJmd0OyBXaGls ZSBVQVMoYXMgdGhpcyBpcyBhYm91dCBSZS1JTlZJVEUsIFVBUyBjb3VsZCBiZSBtb3JlIHByb3Bl cg0KaGVyZSkgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoZXJlIGRvZXMgaXQgc2F5IGRyYWZ0LWll dGYtc2lwY29yZS1yZWludml0ZSBzZWN0aW9ucyAzLjUgYW5kIDQuNQ0KPGJyPg0KJmd0OyBhcmUg bGltaXRlZCB0byByZS1JTlZJVEU/ICZuYnNwO05vdGljZSBzZWN0aW9uIDMuNSBleHBsaWNpdGx5 IGluZGljYXRlcw0KPGJyPg0KJmd0OyAmcXVvdDtyZS1JTlZJVEUgb3IgaW5pdGlhbCBJTlZJVEUm cXVvdDsuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIG1lYW4gYm90 aCBzaWRlKGNhbGxlciBhbmQgY2FsbGVlKSBjYW4gc2VuZCBSZS1JTlZJVEUsDQpzbyBjYWxsZXIg aXMgbm90IHByb3BlciBoZXJlLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxi cj4NCiZndDsgPGJyPg0KJmd0OyBTZWN0aW9uIDMuNSBpbmRpY2F0ZXM6PGJyPg0KJmd0OyAmcXVv dDtBbiBVUERBVEUgcmVxdWVzdCB3aXRob3V0IGFuIG9mZmVyIGNhbiBjaGFuZ2UgZGlhbG9nIHBh cmFtZXRlcnMuDQombmJzcDtTbzxicj4NCiZndDsgJm5ic3A7Y2FuIGEgbm9uLTJ4eCBmaW5hbCBy ZXNwb25zZSB0byBhIHJlLUlOVklURSByZXF1ZXN0IG9yIGEgMnh4DQpyZXNwb25zZTxicj4NCiZn dDsgJm5ic3A7dG8gYW4gSU5WSVRFIHJlcXVlc3QgKHJlLUlOVklURSBvciBpbml0aWFsIElOVklU RSkuICZuYnNwO0hvd2V2ZXIsDQp0aGVyZTxicj4NCiZndDsgJm5ic3A7YXJlIG5vIHJ1bGVzIHRv IGF2b2lkIGEgY29sbGlzaW9uIGJldHdlZW4gYW4gb2ZmZXJsZXNzIFVQREFURQ0KcmVxdWVzdDxi cj4NCiZndDsgJm5ic3A7YW5kIGEgZmluYWwgcmVzcG9uc2UgdG8gYW4gSU5WSVRFIHJlcXVlc3Qu ICZuYnNwO1RoZSBydWxlcyBpbg0KU2VjdGlvbiA0LjUsPGJyPg0KJmd0OyAmbmJzcDt3aGljaCBh cmUgZ2l2ZW4gaW4gdGhlIGNvbnRleHQgb2YgdGFyZ2V0IHJlZnJlc2hlcywgY292ZXIgdGhlc2UN CnR5cGVzPGJyPg0KJmd0OyAmbmJzcDtvZiBjb2xsaXNpb25zIGFzIHdlbGwuICZuYnNwO1RoZXJl Zm9yZSwgdGhlcmUgaXMgbm8gbmVlZCB0bw0Kc3BlY2lmeTxicj4NCiZndDsgJm5ic3A7ZnVydGhl ciBydWxlcyBoZXJlLiZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyAmbHQ7c25pcCZndDs8YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgaXMgbm8gYSBnbGFyZSBzaXR1 YXRpb24uIFVBQyBjYW4gaGFuZGxlIHRoZSBVUERBVEUgT0suIDxicj4NCiZndDsgPGJyPg0KJmd0 OyBQZXIgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlIHNlY3Rpb25zIDMuNSBhbmQgNC41IGl0 IGlzIGEgNTAwIDxicj4NCiZndDsgcmVzcG9uc2Ugc2l0dWF0aW9uLiAmbmJzcDtUaGUgJnF1b3Q7 b2ZmZXImcXVvdDsgd2FzIHdpdGhpbiBJTlZJVEUNCjJ4eCBldmVuIHRob3VnaCA8YnI+DQomZ3Q7 IGl0IGNvbnRhaW5lZCBubyBTRFAuICZuYnNwO0Fub3RoZXIgJnF1b3Q7b2ZmZXImcXVvdDsgd2Fz IHdpdGhpbiB0aGUNClVQREFURSBldmVuIDxicj4NCiZndDsgdGhvdWdoIGl0IGNvbnRhaW5lZCBu byBTRFAuICZuYnNwO1RodXMgcGVyIFJGQzMzMTEsIGEgNTAwIHdpdGggUmV0cnktPGJyPg0KJmd0 OyBBZnRlciBNVVNUIGJlIHJldHVybmVkLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+UGxlYXNlIHJlZmVyIHRvIHRoZSBwcmV2aW91cyBtYWlsLjxicj4NCjwvZm9udD48 L3R0Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7Zmls ZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZp ZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJz cDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVz c2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZu YnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNw O3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7 QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNz YWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtz Y2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZu YnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0044FF254825772D_=-- From brett@broadsoft.com Mon May 24 05:48:14 2010 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 42BB63A6BC7 for ; Mon, 24 May 2010 05:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.634, 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 MMxBgv+pfJvM for ; Mon, 24 May 2010 05:48:13 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 5D09B3A6BC1 for ; Mon, 24 May 2010 05:48:13 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 24 May 2010 05:48:05 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 05:47:03 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr7PRPwwuvWC0vRSTqRqcPN+8n2ngAAElQw Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC33D@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 12:48:14 -0000 > Such rules in the text's 3.5 and 4.5, are used for=20 > glare situations, which have ambiguity.=20 > > So, it is not want to override current 3261 and 3311's=20 > semantics. It is UPDATE and clarification for the * > dark corner*, which is ambiguous case at all.=20 Draft-ietf-sipcore-reinvite section 3.5 and 4.5 appear to have changed the = offer/answer rules by mandating that the rules apply when some requests and= responses don't actually contain an offer or answer. Hopefully the authors will clarify the intended behavior of sections 3.5 an= d 4.5 so that the text can be adjusted if needed. From shinji.okumura@softfront.jp Mon May 24 05:49:21 2010 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 1BE743A6BC0 for ; Mon, 24 May 2010 05:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.454 X-Spam-Level: X-Spam-Status: No, score=-95.454 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 azSkq51AV-dP for ; Mon, 24 May 2010 05:49:20 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 4CB383A6B8D for ; Mon, 24 May 2010 05:49:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 9E6DD42800C; Mon, 24 May 2010 21:49:11 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PvCPk+K24xZ; Mon, 24 May 2010 21:49:08 +0900 (JST) Received: from softfront.jp (123.230.58.209.er.eaccess.ne.jp [123.230.58.209]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id AC13A42800B; Mon, 24 May 2010 21:49:07 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 24 May 2010 21:49:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC31A@EXMBXCLUS01.citservers.local> References: <70CAF9873ACDA5shinji.okumura@softfront.jp> <747A6506A991724FB09B129B79D5FEB614816DC21D@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC31A@EXMBXCLUS01.citservers.local> Message-Id: <96CAFB3F808380shinji.okumura@softfront.jp> Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 12:49:21 -0000 Brett, >> >If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, >> >the following snippets apply. >> > >> >"When checking for glare situations, UAs MUST treat every UPDATE >> >request as if it contained an offer. Additionally, UAs MUST treat >> >the exchange of a 2xx response to an INVITE request and its >> >corresponding ACK request as an offer/answer exchange." >> >> IMO in this case, if a 2xx to a reINVITE is not an offer nor >> an answer, a UAS may accept an UPDATE. >> At least from an offer-answer perspective, the above additional >> rule is unnecessary. > >Draft-ietf-sipcore-reinvite has changed the offer/answer >rules by forcing offer/answer rules upon requests/responses >which don't actually contain an offer or answer. I think I understand it probably. What I make an issue is the validity of it. I doubt whether the aproch is appropriate. Regards, Shinji >And for completeness, draft-ietf-sipcore-reinvite (such as >the above snippet) has impacts on both INVITE and re-INVITE. From gao.yang2@zte.com.cn Mon May 24 05:55:27 2010 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 E5A953A6BC1 for ; Mon, 24 May 2010 05:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.971 X-Spam-Level: X-Spam-Status: No, score=-97.971 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_50=0.001, 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 vdI2P2Sw7hv2 for ; Mon, 24 May 2010 05:55: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 913FA3A6BBE for ; Mon, 24 May 2010 05:55:26 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 24 May 2010 20:50:05 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.4963286206; Mon, 24 May 2010 20:55:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4OCtRRG091265; Mon, 24 May 2010 20:55:27 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC33D@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 20:52:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 20:55:06, Serialize complete at 2010-05-24 20:55:06 Content-Type: multipart/alternative; boundary="=_alternative 0046EF0C4825772D_=" X-MAIL: mse2.zte.com.cn o4OCtRRG091265 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 12:55:28 -0000 This is a multipart message in MIME format. --=_alternative 0046EF0C4825772D_= Content-Type: text/plain; charset="US-ASCII" > Draft-ietf-sipcore-reinvite section 3.5 and 4.5 appear to have > changed the offer/answer rules by mandating that the rules apply > when some requests and responses don't actually contain an offer or answer. > > Hopefully the authors will clarify the intended behavior of sections > 3.5 and 4.5 so that the text can be adjusted if needed. We are trying to fix ambiguous case in 3261 and 3311, not want to override well-balanced things. So, if you think there's rules have impact on *once* well-balanced use cases, please show the use cases. And if you have better way for the ambigunous cases, please show it too. Thanks, Gao -------------------------------------------------------- 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 0046EF0C4825772D_= Content-Type: text/html; charset="US-ASCII"

> Draft-ietf-sipcore-reinvite section 3.5 and 4.5 appear to have
> changed the offer/answer rules by mandating that the rules apply
> when some requests and responses don't actually contain an offer or answer.
>
> Hopefully the authors will clarify the intended behavior of sections
> 3.5 and 4.5 so that the text can be adjusted if needed.
We are trying to fix ambiguous case in 3261 and 3311, not want to override well-balanced things.

So, if you think there's rules have impact on *once* well-balanced use cases, please show the use cases.

And if you have better way for the ambigunous cases, please show it too.

Thanks,

Gao 

--------------------------------------------------------
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 0046EF0C4825772D_=-- From brett@broadsoft.com Mon May 24 06:03:54 2010 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 8591B3A6AF0 for ; Mon, 24 May 2010 06:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394, 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 B-04Bh8zDUYd for ; Mon, 24 May 2010 06:03:53 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 983373A6BA3 for ; Mon, 24 May 2010 06:03:53 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 24 May 2010 06:03:45 -0700 From: Brett Tate To: "Elwell, John" , "sipcore@ietf.org" Date: Mon, 24 May 2010 06:02:44 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAAAY4vw Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC354@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:03:54 -0000 > Thanks for the clarification.=20 > So the changes do not prohibit the use of > UPDATE after only a non-reliable provisional response, provided the > UPDATE request does not contain an offer - correct? If it does contain > an offer it is subject to the glare rules. Concerning glare, my understanding is that the draft mandates treating UPDA= TE without offer as though it contained an offer. I'm still trying to understand how section 3.5 and 4.5 are to be interprete= d. Because the draft uses offer/answer rules for the "fix", it prevents us= ing UPDATE without SDP on an early dialog until allowed per offer/answer ru= les. Thus sending 18x using 100rel with answer SDP is now important to avo= id blocking ability to send UPDATE for non SDP reasons. From gao.yang2@zte.com.cn Mon May 24 06:15:43 2010 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 2440E3A6AF0 for ; Mon, 24 May 2010 06:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.303 X-Spam-Level: X-Spam-Status: No, score=-99.303 tagged_above=-999 required=5 tests=[AWL=2.535, 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 vOsa27b6J-mc for ; Mon, 24 May 2010 06:15: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 702353A6BD7 for ; Mon, 24 May 2010 06:15:33 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 24 May 2010 21:10:13 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.4963286206; Mon, 24 May 2010 21:15:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4ODFcnV006441; Mon, 24 May 2010 21:15:38 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC354@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 21:12:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 21:15:17, Serialize complete at 2010-05-24 21:15:17 Content-Type: multipart/alternative; boundary="=_alternative 0048C7F14825772D_=" X-MAIL: mse2.zte.com.cn o4ODFcnV006441 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:15:43 -0000 This is a multipart message in MIME format. --=_alternative 0048C7F14825772D_= Content-Type: text/plain; charset="US-ASCII" > Concerning glare, my understanding is that the draft mandates > treating UPDATE without offer as though it contained an offer. > > I'm still trying to understand how section 3.5 and 4.5 are to be > interpreted. Because the draft uses offer/answer rules for the > "fix", it prevents using UPDATE without SDP on an early dialog until > allowed per offer/answer rules. Not exactly here. The text never forbit usage of UPDATE without offer by O/A rules. People can use it as before, and just refer the rules here while it is a really glare case. -------------------------------------------------------- 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 0048C7F14825772D_= Content-Type: text/html; charset="US-ASCII"

> Concerning glare, my understanding is that the draft mandates
> treating UPDATE without offer as though it contained an offer.
>
> I'm still trying to understand how section 3.5 and 4.5 are to be
> interpreted.  Because the draft uses offer/answer rules for the
> "fix", it prevents using UPDATE without SDP on an early dialog until
> allowed per offer/answer rules.

Not exactly here. The text never forbit usage of UPDATE without offer by O/A rules.

People can use it as before, and just refer the rules here while it is a really glare case.

--------------------------------------------------------
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 0048C7F14825772D_=-- From brett@broadsoft.com Mon May 24 06:16:52 2010 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 D14AF3A6BCF for ; Mon, 24 May 2010 06:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.592, 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 vIcXwIcvf3FJ for ; Mon, 24 May 2010 06:16:52 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 059BC3A6BCA for ; Mon, 24 May 2010 06:16:52 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 24 May 2010 06:16:44 -0700 From: Brett Tate To: OKUMURA Shinji , "sipcore@ietf.org" Date: Mon, 24 May 2010 06:15:42 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr7P4UENaIVB2cfQTCBgcmZ5fZC5AAAfRqw Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC36C@EXMBXCLUS01.citservers.local> References: <70CAF9873ACDA5shinji.okumura@softfront.jp> <747A6506A991724FB09B129B79D5FEB614816DC21D@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC31A@EXMBXCLUS01.citservers.local> <96CAFB3F808380shinji.okumura@softfront.jp> In-Reply-To: <96CAFB3F808380shinji.okumura@softfront.jp> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:16:52 -0000 > What I make an issue is the validity of it. > I doubt whether the aproch is appropriate. The draft has already passed WGLC. The current status is "Publication Requ= ested". Thus I'm not sure how willing the authors and working group would be to alt= er the solution. However I'm not sure how many working group members notic= ed the impacts of section 3.5 and 4.5. It definitely encourages sending answer SDP within reliable 18x. Not doing= so would block ability to use UPDATE on the early dialog. From gao.yang2@zte.com.cn Mon May 24 06:25:46 2010 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 654183A6BE1 for ; Mon, 24 May 2010 06:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.236 X-Spam-Level: X-Spam-Status: No, score=-97.236 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 B5ahs8F4XTUR for ; Mon, 24 May 2010 06:25:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id DE17E3A6BD6 for ; Mon, 24 May 2010 06:25:44 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Mon, 24 May 2010 21:18:29 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.4900341499; Mon, 24 May 2010 21:25:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4ODPk4M013670; Mon, 24 May 2010 21:25:46 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC36C@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 21:23:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 21:25:25, Serialize complete at 2010-05-24 21:25:25 Content-Type: multipart/alternative; boundary="=_alternative 0049B4C84825772D_=" X-MAIL: mse2.zte.com.cn o4ODPk4M013670 Cc: OKUMURA Shinji , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:25:46 -0000 This is a multipart message in MIME format. --=_alternative 0049B4C84825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMC0wNS0yNCAyMToxNTo0MjoNCg0KPiA+ IFdoYXQgSSBtYWtlIGFuIGlzc3VlIGlzIHRoZSB2YWxpZGl0eSBvZiBpdC4NCj4gPiBJIGRvdWJ0 IHdoZXRoZXIgdGhlIGFwcm9jaCBpcyBhcHByb3ByaWF0ZS4NCj4gDQo+IFRoZSBkcmFmdCBoYXMg YWxyZWFkeSBwYXNzZWQgV0dMQy4gIFRoZSBjdXJyZW50IHN0YXR1cyBpcyANCj4gIlB1YmxpY2F0 aW9uIFJlcXVlc3RlZCIuDQoNClllcy4NCg0KPiANCj4gVGh1cyBJJ20gbm90IHN1cmUgaG93IHdp bGxpbmcgdGhlIGF1dGhvcnMgYW5kIHdvcmtpbmcgZ3JvdXAgd291bGQgYmUNCj4gdG8gYWx0ZXIg dGhlIHNvbHV0aW9uLiAgSG93ZXZlciBJJ20gbm90IHN1cmUgaG93IG1hbnkgd29ya2luZyBncm91 cCANCj4gbWVtYmVycyBub3RpY2VkIHRoZSBpbXBhY3RzIG9mIHNlY3Rpb24gMy41IGFuZCA0LjUu DQoNCk5vIG1hdHRlciBob3cgZWFnZXIgSSB3YW50IHRvIG1ha2UgdGhpcyB0ZXh0IHByb2Nlc3Ms IGlmIHlvdSBmaW5kIHJlYWwgDQpwcm9ibGVtIG9yIG90aGVyIGludGVyd29ya2luZyBpc3N1ZSwg anVzdCBwb2ludCBpdCBvdXQuDQoNCkluIGZhY3QsIHRoaXMgaXMgVVBEQVRFIG9mIDMyNjEuIEkg ZG8gbm90IHdhbnQgdG8gc2VlIFVQREFURSBvZiBvdXIgdGV4dCANCnNvbWVkYXkgZm9yIG91ciBu ZWdsaWdlbmNlLg0KDQo+IA0KPiBJdCBkZWZpbml0ZWx5IGVuY291cmFnZXMgc2VuZGluZyBhbnN3 ZXIgU0RQIHdpdGhpbiByZWxpYWJsZSAxOHguIA0KPiBOb3QgZG9pbmcgc28gd291bGQgYmxvY2sg YWJpbGl0eSB0byB1c2UgVVBEQVRFIG9uIHRoZSBlYXJseSBkaWFsb2cuDQoNCk5vdCBleGFjdGx5 LCBwbGVhc2Ugc2VlIG15IHByZXZpb3VzIG1haWwncyByZXBseS4NCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0049B4C84825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5zaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEw LTA1LTI0IDIxOjE1OjQyOjxicj4NCjxicj4NCiZndDsgJmd0OyBXaGF0IEkgbWFrZSBhbiBpc3N1 ZSBpcyB0aGUgdmFsaWRpdHkgb2YgaXQuPGJyPg0KJmd0OyAmZ3Q7IEkgZG91YnQgd2hldGhlciB0 aGUgYXByb2NoIGlzIGFwcHJvcHJpYXRlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgZHJhZnQg aGFzIGFscmVhZHkgcGFzc2VkIFdHTEMuICZuYnNwO1RoZSBjdXJyZW50IHN0YXR1cyBpcyA8YnI+ DQomZ3Q7ICZxdW90O1B1YmxpY2F0aW9uIFJlcXVlc3RlZCZxdW90Oy48L2ZvbnQ+PC90dD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlllcy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaHVzIEknbSBub3Qgc3VyZSBob3cgd2lsbGlu ZyB0aGUgYXV0aG9ycyBhbmQgd29ya2luZyBncm91cCB3b3VsZA0KYmU8YnI+DQomZ3Q7IHRvIGFs dGVyIHRoZSBzb2x1dGlvbi4gJm5ic3A7SG93ZXZlciBJJ20gbm90IHN1cmUgaG93IG1hbnkgd29y a2luZw0KZ3JvdXAgPGJyPg0KJmd0OyBtZW1iZXJzIG5vdGljZWQgdGhlIGltcGFjdHMgb2Ygc2Vj dGlvbiAzLjUgYW5kIDQuNS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Tm8gbWF0dGVyIGhvdyBlYWdlciBJIHdhbnQgdG8gbWFrZSB0aGlzDQp0 ZXh0IHByb2Nlc3MsIGlmIHlvdSBmaW5kIHJlYWwgcHJvYmxlbSBvciBvdGhlciBpbnRlcndvcmtp bmcgaXNzdWUsIGp1c3QNCnBvaW50IGl0IG91dC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIGZhY3QsIHRoaXMgaXMgVVBEQVRFIG9mIDMyNjEuIEkg ZG8NCm5vdCB3YW50IHRvIHNlZSBVUERBVEUgb2Ygb3VyIHRleHQgc29tZWRheSBmb3Igb3VyIG5l Z2xpZ2VuY2UuPC9mb250Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEl0IGRlZmluaXRlbHkgZW5jb3VyYWdlcyBzZW5kaW5nIGFuc3dlciBTRFAgd2l0aGluIHJl bGlhYmxlIDE4eC4gJm5ic3A7PGJyPg0KJmd0OyBOb3QgZG9pbmcgc28gd291bGQgYmxvY2sgYWJp bGl0eSB0byB1c2UgVVBEQVRFIG9uIHRoZSBlYXJseSBkaWFsb2cuPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Ob3QgZXhhY3RseSwgcGxlYXNlIHNlZSBteSBwcmV2aW91 cyBtYWlsJ3MgcmVwbHkuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 0049B4C84825772D_=-- From brett@broadsoft.com Mon May 24 06:26:39 2010 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 103AA3A6BED for ; Mon, 24 May 2010 06:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_05=-1.11] 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 v9cxRk9n0Iel for ; Mon, 24 May 2010 06:26:38 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 4D7823A6BD1 for ; Mon, 24 May 2010 06:26:38 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 24 May 2010 06:26:30 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 06:25:28 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr7Qyz3H+QHWNdTSwSlNkyEdY7eMgAAFjTA Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC383@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DC354@EXMBXCLUS01.citservers.local> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:26:39 -0000 > > Concerning glare, my understanding is that the draft mandates=20 > > treating UPDATE without offer as though it contained an offer. > >=20 > > I'm still trying to understand how section 3.5 and 4.5 are to be=20 > > interpreted. =A0Because the draft uses offer/answer rules for the=20 > > "fix", it prevents using UPDATE without SDP on an early dialog until > > allowed per offer/answer rules.=20 > > Not exactly here. The text never forbit usage of UPDATE without offer by = O/A rules.=20 I agree that it doesn't forbid sending it. It allows it and mandates the U= AS return 491 or 500 (depending upon direction). From gao.yang2@zte.com.cn Mon May 24 06:32:58 2010 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 A11523A6BD1; Mon, 24 May 2010 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.244 X-Spam-Level: X-Spam-Status: No, score=-97.244 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Pnz5P0I7-yZw; Mon, 24 May 2010 06:32:57 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id EC6123A6BF0; Mon, 24 May 2010 06:32:56 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368872001811080; Mon, 24 May 2010 21:26:14 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 13308.3886437876; Mon, 24 May 2010 21:27:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4ODX3X7018173; Mon, 24 May 2010 21:33:03 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC383@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 21:30:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 21:32:42, Serialize complete at 2010-05-24 21:32:42 Content-Type: multipart/alternative; boundary="=_alternative 004A5FAD4825772D_=" X-MAIL: mse2.zte.com.cn o4ODX3X7018173 Cc: "sipcore@ietf.org" , sipcore-bounces@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:32:58 -0000 This is a multipart message in MIME format. --=_alternative 004A5FAD4825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMC0wNS0yNCAyMToyNToyODoNCg0KPiA+ ID4gQ29uY2VybmluZyBnbGFyZSwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBkcmFmdCBt YW5kYXRlcyANCj4gPiA+IHRyZWF0aW5nIFVQREFURSB3aXRob3V0IG9mZmVyIGFzIHRob3VnaCBp dCBjb250YWluZWQgYW4gb2ZmZXIuDQo+ID4gPiANCj4gPiA+IEknbSBzdGlsbCB0cnlpbmcgdG8g dW5kZXJzdGFuZCBob3cgc2VjdGlvbiAzLjUgYW5kIDQuNSBhcmUgdG8gYmUgDQo+ID4gPiBpbnRl cnByZXRlZC4gIEJlY2F1c2UgdGhlIGRyYWZ0IHVzZXMgb2ZmZXIvYW5zd2VyIHJ1bGVzIGZvciB0 aGUgDQo+ID4gPiAiZml4IiwgaXQgcHJldmVudHMgdXNpbmcgVVBEQVRFIHdpdGhvdXQgU0RQIG9u IGFuIGVhcmx5IGRpYWxvZyB1bnRpbA0KPiA+ID4gYWxsb3dlZCBwZXIgb2ZmZXIvYW5zd2VyIHJ1 bGVzLiANCj4gPg0KPiA+IE5vdCBleGFjdGx5IGhlcmUuIFRoZSB0ZXh0IG5ldmVyIGZvcmJpdCB1 c2FnZSBvZiBVUERBVEUgd2l0aG91dCANCj4gb2ZmZXIgYnkgTy9BIHJ1bGVzLiANCj4gDQo+IEkg YWdyZWUgdGhhdCBpdCBkb2Vzbid0IGZvcmJpZCBzZW5kaW5nIGl0LiAgSXQgYWxsb3dzIGl0IGFu ZCANCj4gbWFuZGF0ZXMgdGhlIFVBUyByZXR1cm4gNDkxIG9yIDUwMCAoZGVwZW5kaW5nIHVwb24g ZGlyZWN0aW9uKS4NCg0KSXQgbWFuZGF0ZXMgdGhlIFVBUyBzZW5kIDR4eC81eHggdG8gVVBEQVRF IG9ubHkgd2hlbiB0aGUgVUFTIHNlbmQgNHh4LzV4eCANCnRvIHRoZSBSZS1JTlZJVEUgYW5kIHRo ZSBVQVMgZ2V0IHRoZSBVUERBVEUgYmVmb3JlIEFDSyBvZiANCjR4eC81eHgoUmUtSU5WSVRFKS4N Cg0KSWYgVUFTIHNlbmQgMnh4IHRvIFJlLUlOVklURSwgdGhlIFVBUyB3b3VsZCBub3Qgc2VuZCA0 eHgvNXh4IHRvIHRoZSANClVQREFURS4NCg0KQW5kIGlmIHRoZSBVQVMgZ2V0IHRoZSBBQ0soUmUt SU5WSVRFJ3MgNHh4LzV4eCkgZmlyc3RseSwgdGhlIFVBUyBhbHNvIA0Kd291bGQgbm90IG1hbmRh dGUgdG8gdGhlIHJ1bGVzLg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 004A5FAD4825772D_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5zaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcg5YaZ5LqOIDIw MTAtMDUtMjQgMjE6MjU6Mjg6PGJyPg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ29uY2VybmluZyBn bGFyZSwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBkcmFmdCBtYW5kYXRlcw0KPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgdHJlYXRpbmcgVVBEQVRFIHdpdGhvdXQgb2ZmZXIgYXMgdGhvdWdoIGl0 IGNvbnRhaW5lZCBhbg0Kb2ZmZXIuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgSSdtIHN0aWxsIHRyeWluZyB0byB1bmRlcnN0YW5kIGhvdyBzZWN0aW9uIDMuNSBhbmQg NC41IGFyZQ0KdG8gYmUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW50ZXJwcmV0ZWQuICZuYnNwO0Jl Y2F1c2UgdGhlIGRyYWZ0IHVzZXMgb2ZmZXIvYW5zd2VyIHJ1bGVzDQpmb3IgdGhlIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZxdW90O2ZpeCZxdW90OywgaXQgcHJldmVudHMgdXNpbmcgVVBEQVRFIHdp dGhvdXQgU0RQIG9uDQphbiBlYXJseSBkaWFsb2cgdW50aWw8YnI+DQomZ3Q7ICZndDsgJmd0OyBh bGxvd2VkIHBlciBvZmZlci9hbnN3ZXIgcnVsZXMuIDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBOb3QgZXhhY3RseSBoZXJlLiBUaGUgdGV4dCBuZXZlciBmb3JiaXQgdXNhZ2Ugb2YgVVBE QVRFIHdpdGhvdXQNCjxicj4NCiZndDsgb2ZmZXIgYnkgTy9BIHJ1bGVzLiA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgSSBhZ3JlZSB0aGF0IGl0IGRvZXNuJ3QgZm9yYmlkIHNlbmRpbmcgaXQuICZuYnNw O0l0IGFsbG93cyBpdCBhbmQNCjxicj4NCiZndDsgbWFuZGF0ZXMgdGhlIFVBUyByZXR1cm4gNDkx IG9yIDUwMCAoZGVwZW5kaW5nIHVwb24gZGlyZWN0aW9uKS48YnI+DQo8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPkl0IG1hbmRhdGVzIHRoZSBVQVMgc2VuZCA0eHgvNXh4IHRvIFVQ REFURSBvbmx5IHdoZW4NCnRoZSBVQVMgc2VuZCA0eHgvNXh4IHRvIHRoZSBSZS1JTlZJVEUgYW5k IHRoZSBVQVMgZ2V0IHRoZSBVUERBVEUgYmVmb3JlDQpBQ0sgb2YgNHh4LzV4eChSZS1JTlZJVEUp LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SWYgVUFTIHNlbmQgMnh4 IHRvIFJlLUlOVklURSwgdGhlIFVBUyB3b3VsZCBub3Qgc2VuZA0KNHh4LzV4eCB0byB0aGUgVVBE QVRFLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QW5kIGlmIHRoZSBV QVMgZ2V0IHRoZSBBQ0soUmUtSU5WSVRFJ3MgNHh4LzV4eCkgZmlyc3RseSwNCnRoZSBVQVMgYWxz byB3b3VsZCBub3QgbWFuZGF0ZSB0byB0aGUgcnVsZXMuPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+ PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZu YnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWls Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lw aWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7 dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3Qm bmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVu dHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhl cnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3Ry YW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5i c3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1 c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZu YnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7 SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwm bmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7 b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2 aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDth cmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRl ci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJz cDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5i c3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 004A5FAD4825772D_=-- From brett@broadsoft.com Mon May 24 06:38:13 2010 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 233A33A6C01; Mon, 24 May 2010 06:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_20=-0.74, 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 fzR9ZhHzLU9n; Mon, 24 May 2010 06:38:12 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id E9CAE3A6BFE; Mon, 24 May 2010 06:38:11 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 24 May 2010 06:38:04 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 06:37:01 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr7RZt5agjU3NuvSb6qUzsu5DLYygAADZPQ Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC3A2@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DC383@EXMBXCLUS01.citservers.local> In-Reply-To: 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_747A6506A991724FB09B129B79D5FEB614816DC3A2EXMBXCLUS01ci_" MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "sipcore-bounces@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:38:13 -0000 --_000_747A6506A991724FB09B129B79D5FEB614816DC3A2EXMBXCLUS01ci_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBtaWdodCBiZSB3aGF0IHlvdSB3YW50ZWQgc2VjdGlvbnMgMy41IGFuZCA0LjUgdG8gbWVh bjsgaG93ZXZlciBpdCBjdXJyZW50bHkgZG9lc27igJl0IG1lYW4gdGhhdCB3aGVuIHlvdSBmYWN0 b3IgaW4gUkZDMzMxMS4NCg0KRnJvbTogZ2FvLnlhbmcyQHp0ZS5jb20uY24gW21haWx0bzpnYW8u eWFuZzJAenRlLmNvbS5jbl0NClNlbnQ6IE1vbmRheSwgTWF5IDI0LCAyMDEwIDk6MzAgQU0NClRv OiBCcmV0dCBUYXRlDQpDYzogc2lwY29yZUBpZXRmLm9yZzsgc2lwY29yZS1ib3VuY2VzQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0w NDogZ2xhcmUgYW5kIFVQREFURSB3aXRob3V0IFNEUA0KDQoNCnNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZyDlhpnkuo4gMjAxMC0wNS0yNCAyMToyNToyODoNCg0KPiA+ID4gQ29uY2VybmluZyBnbGFy ZSwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBkcmFmdCBtYW5kYXRlcw0KPiA+ID4gdHJl YXRpbmcgVVBEQVRFIHdpdGhvdXQgb2ZmZXIgYXMgdGhvdWdoIGl0IGNvbnRhaW5lZCBhbiBvZmZl ci4NCj4gPiA+DQo+ID4gPiBJJ20gc3RpbGwgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IHNlY3Rp b24gMy41IGFuZCA0LjUgYXJlIHRvIGJlDQo+ID4gPiBpbnRlcnByZXRlZC4gIEJlY2F1c2UgdGhl IGRyYWZ0IHVzZXMgb2ZmZXIvYW5zd2VyIHJ1bGVzIGZvciB0aGUNCj4gPiA+ICJmaXgiLCBpdCBw cmV2ZW50cyB1c2luZyBVUERBVEUgd2l0aG91dCBTRFAgb24gYW4gZWFybHkgZGlhbG9nIHVudGls DQo+ID4gPiBhbGxvd2VkIHBlciBvZmZlci9hbnN3ZXIgcnVsZXMuDQo+ID4NCj4gPiBOb3QgZXhh Y3RseSBoZXJlLiBUaGUgdGV4dCBuZXZlciBmb3JiaXQgdXNhZ2Ugb2YgVVBEQVRFIHdpdGhvdXQN Cj4gb2ZmZXIgYnkgTy9BIHJ1bGVzLg0KPg0KPiBJIGFncmVlIHRoYXQgaXQgZG9lc24ndCBmb3Ji aWQgc2VuZGluZyBpdC4gIEl0IGFsbG93cyBpdCBhbmQNCj4gbWFuZGF0ZXMgdGhlIFVBUyByZXR1 cm4gNDkxIG9yIDUwMCAoZGVwZW5kaW5nIHVwb24gZGlyZWN0aW9uKS4NCg0KSXQgbWFuZGF0ZXMg dGhlIFVBUyBzZW5kIDR4eC81eHggdG8gVVBEQVRFIG9ubHkgd2hlbiB0aGUgVUFTIHNlbmQgNHh4 LzV4eCB0byB0aGUgUmUtSU5WSVRFIGFuZCB0aGUgVUFTIGdldCB0aGUgVVBEQVRFIGJlZm9yZSBB Q0sgb2YgNHh4LzV4eChSZS1JTlZJVEUpLg0KDQpJZiBVQVMgc2VuZCAyeHggdG8gUmUtSU5WSVRF LCB0aGUgVUFTIHdvdWxkIG5vdCBzZW5kIDR4eC81eHggdG8gdGhlIFVQREFURS4NCg0KQW5kIGlm IHRoZSBVQVMgZ2V0IHRoZSBBQ0soUmUtSU5WSVRFJ3MgNHh4LzV4eCkgZmlyc3RseSwgdGhlIFVB UyBhbHNvIHdvdWxkIG5vdCBtYW5kYXRlIHRvIHRoZSBydWxlcy4NCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90 aGVycy4NCg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4g c2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --_000_747A6506A991724FB09B129B79D5FEB614816DC3A2EXMBXCLUS01ci_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcg MiA1IDggMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQp0dA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNl Y3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJs dWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlRoYXQgbWlnaHQgYmUgd2hhdCB5b3Ugd2Fu dGVkIHNlY3Rpb25zIDMuNSBhbmQgNC41IHRvIG1lYW47DQpob3dldmVyIGl0IGN1cnJlbnRseSBk b2VzbuKAmXQgbWVhbiB0aGF0IHdoZW4geW91IGZhY3RvciBpbiBSRkMzMzExLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+ DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPg0KZ2FvLnlhbmcyQHp0ZS5j b20uY24gW21haWx0bzpnYW8ueWFuZzJAenRlLmNvbS5jbl0gPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgTWF5IDI0LCAyMDEwIDk6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyZXR0IFRhdGU8YnI+ DQo8Yj5DYzo8L2I+IHNpcGNvcmVAaWV0Zi5vcmc7IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIGRyYWZ0LWlldGYtc2lwY29yZS1yZWlu dml0ZS0wNDogZ2xhcmUgYW5kIFVQREFURQ0Kd2l0aG91dCBTRFA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIu MHB0Jz48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPnNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZyA8L3NwYW4+PC90dD48dHQ+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7lhpnkuo48L3NwYW4+PC90dD48dHQ+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gMjAxMC0wNS0yNCAyMToyNToyODo8L3NwYW4+PC90 dD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+PGJyPg0KPGJyPg0KPHR0PiZndDsgJmd0OyAmZ3Q7IENvbmNlcm5pbmcgZ2xhcmUsIG15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgZHJhZnQNCm1hbmRhdGVzIDwvdHQ+PGJyPg0KPHR0PiZn dDsgJmd0OyAmZ3Q7IHRyZWF0aW5nIFVQREFURSB3aXRob3V0IG9mZmVyIGFzIHRob3VnaCBpdCBj b250YWluZWQgYW4NCm9mZmVyLjwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyAmZ3Q7IDwvdHQ+PGJy Pg0KPHR0PiZndDsgJmd0OyAmZ3Q7IEknbSBzdGlsbCB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3cg c2VjdGlvbiAzLjUgYW5kIDQuNSBhcmUNCnRvIGJlIDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyAm Z3Q7IGludGVycHJldGVkLiAmbmJzcDtCZWNhdXNlIHRoZSBkcmFmdCB1c2VzIG9mZmVyL2Fuc3dl ciBydWxlcw0KZm9yIHRoZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgJmd0OyAmcXVvdDtmaXgm cXVvdDssIGl0IHByZXZlbnRzIHVzaW5nIFVQREFURSB3aXRob3V0IFNEUCBvbiBhbg0KZWFybHkg ZGlhbG9nIHVudGlsPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7ICZndDsgYWxsb3dlZCBwZXIgb2Zm ZXIvYW5zd2VyIHJ1bGVzLiA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDs8L3R0Pjxicj4NCjx0dD4m Z3Q7ICZndDsgTm90IGV4YWN0bHkgaGVyZS4gVGhlIHRleHQgbmV2ZXIgZm9yYml0IHVzYWdlIG9m IFVQREFURSB3aXRob3V0IDwvdHQ+PGJyPg0KPHR0PiZndDsgb2ZmZXIgYnkgTy9BIHJ1bGVzLiA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgSSBhZ3JlZSB0aGF0IGl0IGRv ZXNuJ3QgZm9yYmlkIHNlbmRpbmcgaXQuICZuYnNwO0l0IGFsbG93cyBpdCBhbmQgPC90dD48YnI+ DQo8dHQ+Jmd0OyBtYW5kYXRlcyB0aGUgVUFTIHJldHVybiA0OTEgb3IgNTAwIChkZXBlbmRpbmcg dXBvbiBkaXJlY3Rpb24pLjwvdHQ+PGJyPg0KPC9zcGFuPjxicj4NCjx0dD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+SXQgbWFuZGF0ZXMgdGhlIFVBUyBzZW5kIDR4eC81eHggdG8gVVBE QVRFDQpvbmx5IHdoZW4gdGhlIFVBUyBzZW5kIDR4eC81eHggdG8gdGhlIFJlLUlOVklURSBhbmQg dGhlIFVBUyBnZXQgdGhlIFVQREFURQ0KYmVmb3JlIEFDSyBvZiA0eHgvNXh4KFJlLUlOVklURSku PC9zcGFuPjwvdHQ+IDxicj4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+SWYgVUFTIHNlbmQgMnh4IHRvIFJlLUlOVklURSwgdGhlIFVBUyB3b3VsZA0Kbm90IHNlbmQg NHh4LzV4eCB0byB0aGUgVVBEQVRFLjwvc3Bhbj48L3R0PiA8YnI+DQo8YnI+DQo8dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkFuZCBpZiB0aGUgVUFTIGdldCB0aGUgQUNLKFJlLUlO VklURSdzDQo0eHgvNXh4KSBmaXJzdGx5LCB0aGUgVUFTIGFsc28gd291bGQgbm90IG1hbmRhdGUg dG8gdGhlIHJ1bGVzLjwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KDQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+PHByZT5aVEUmbmJzcDtJbmZvcm1h dGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9u Jm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7 c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7 b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fi b3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3Nl Y3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZu YnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuPG86cD48L286cD48L3ByZT48cHJl PlRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNt aXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDth bmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7 dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZu YnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNw O2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmln aW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdz Jm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZu YnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLjxv OnA+PC9vOnA+PC9wcmU+PHByZT5UaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4m bmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJz cDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS48bzpwPjwvbzpwPjwvcHJl PjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= --_000_747A6506A991724FB09B129B79D5FEB614816DC3A2EXMBXCLUS01ci_-- From gao.yang2@zte.com.cn Mon May 24 06:42:48 2010 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 EF01A3A6BEC for ; Mon, 24 May 2010 06:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.058 X-Spam-Level: X-Spam-Status: No, score=-96.058 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 NkJ3GHoDBNVi for ; Mon, 24 May 2010 06:42:46 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id BD9203A6C09 for ; Mon, 24 May 2010 06:42:45 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 24 May 2010 21:37:24 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3612446977; Mon, 24 May 2010 21:42:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4ODgjij024381; Mon, 24 May 2010 21:42:45 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC3A2@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 21:40:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 21:42:24, Serialize complete at 2010-05-24 21:42:24 Content-Type: multipart/alternative; boundary="=_alternative 004B434C4825772D_=" X-MAIL: mse2.zte.com.cn o4ODgjij024381 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:42:48 -0000 This is a multipart message in MIME format. --=_alternative 004B434C4825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U29ycnksIEkgY2FuJ3QgY2F0Y2ggdGhlIG1lYW5pbmcgb2YgIndoZW4geW91IGZhY3RvciBpbiBS RkMzMzExIi4gQ291bGQgDQp5b3Ugc2hvdyBtZSB0aGUgbWVhbmluZz8NCg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIx MQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5j b20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpCcmV0dCBU YXRlIDxicmV0dEBicm9hZHNvZnQuY29tPiANCjIwMTAtMDUtMjQgMjE6MzcNCg0KytW8/sjLDQoi Z2FvLnlhbmcyQHp0ZS5jb20uY24iIDxnYW8ueWFuZzJAenRlLmNvbS5jbj4NCrOty80NCiJzaXBj b3JlQGlldGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4sICJzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmciIA0KPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4NCtb3zOINClJFOiBbc2lwY29yZV0gZHJh ZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0OiBnbGFyZSBhbmQgVVBEQVRFIHdpdGhvdXQgU0RQ DQoNCg0KDQoNCg0KDQpUaGF0IG1pZ2h0IGJlIHdoYXQgeW91IHdhbnRlZCBzZWN0aW9ucyAzLjUg YW5kIDQuNSB0byBtZWFuOyBob3dldmVyIGl0IA0KY3VycmVudGx5IGRvZXNuoa90IG1lYW4gdGhh dCB3aGVuIHlvdSBmYWN0b3IgaW4gUkZDMzMxMS4NCiANCkZyb206IGdhby55YW5nMkB6dGUuY29t LmNuIFttYWlsdG86Z2FvLnlhbmcyQHp0ZS5jb20uY25dIA0KU2VudDogTW9uZGF5LCBNYXkgMjQs IDIwMTAgOTozMCBBTQ0KVG86IEJyZXR0IFRhdGUNCkNjOiBzaXBjb3JlQGlldGYub3JnOyBzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1z aXBjb3JlLXJlaW52aXRlLTA0OiBnbGFyZSBhbmQgVVBEQVRFIA0Kd2l0aG91dCBTRFANCiANCg0K c2lwY29yZS1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMC0wNS0yNCAyMToyNToyODoNCg0KPiA+ ID4gQ29uY2VybmluZyBnbGFyZSwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBkcmFmdCBt YW5kYXRlcyANCj4gPiA+IHRyZWF0aW5nIFVQREFURSB3aXRob3V0IG9mZmVyIGFzIHRob3VnaCBp dCBjb250YWluZWQgYW4gb2ZmZXIuDQo+ID4gPiANCj4gPiA+IEknbSBzdGlsbCB0cnlpbmcgdG8g dW5kZXJzdGFuZCBob3cgc2VjdGlvbiAzLjUgYW5kIDQuNSBhcmUgdG8gYmUgDQo+ID4gPiBpbnRl cnByZXRlZC4gIEJlY2F1c2UgdGhlIGRyYWZ0IHVzZXMgb2ZmZXIvYW5zd2VyIHJ1bGVzIGZvciB0 aGUgDQo+ID4gPiAiZml4IiwgaXQgcHJldmVudHMgdXNpbmcgVVBEQVRFIHdpdGhvdXQgU0RQIG9u IGFuIGVhcmx5IGRpYWxvZyB1bnRpbA0KPiA+ID4gYWxsb3dlZCBwZXIgb2ZmZXIvYW5zd2VyIHJ1 bGVzLiANCj4gPg0KPiA+IE5vdCBleGFjdGx5IGhlcmUuIFRoZSB0ZXh0IG5ldmVyIGZvcmJpdCB1 c2FnZSBvZiBVUERBVEUgd2l0aG91dCANCj4gb2ZmZXIgYnkgTy9BIHJ1bGVzLiANCj4gDQo+IEkg YWdyZWUgdGhhdCBpdCBkb2Vzbid0IGZvcmJpZCBzZW5kaW5nIGl0LiAgSXQgYWxsb3dzIGl0IGFu ZCANCj4gbWFuZGF0ZXMgdGhlIFVBUyByZXR1cm4gNDkxIG9yIDUwMCAoZGVwZW5kaW5nIHVwb24g ZGlyZWN0aW9uKS4NCg0KSXQgbWFuZGF0ZXMgdGhlIFVBUyBzZW5kIDR4eC81eHggdG8gVVBEQVRF IG9ubHkgd2hlbiB0aGUgVUFTIHNlbmQgNHh4LzV4eCANCnRvIHRoZSBSZS1JTlZJVEUgYW5kIHRo ZSBVQVMgZ2V0IHRoZSBVUERBVEUgYmVmb3JlIEFDSyBvZiANCjR4eC81eHgoUmUtSU5WSVRFKS4g DQoNCklmIFVBUyBzZW5kIDJ4eCB0byBSZS1JTlZJVEUsIHRoZSBVQVMgd291bGQgbm90IHNlbmQg NHh4LzV4eCB0byB0aGUgDQpVUERBVEUuIA0KDQpBbmQgaWYgdGhlIFVBUyBnZXQgdGhlIEFDSyhS ZS1JTlZJVEUncyA0eHgvNXh4KSBmaXJzdGx5LCB0aGUgVUFTIGFsc28gDQp3b3VsZCBub3QgbWFu ZGF0ZSB0byB0aGUgcnVsZXMuDQogDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0 byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQpUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBp bnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIA0KdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg DQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2 aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24u IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g b3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNj YW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 004B434C4825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvcnJ5LCBJIGNhbid0IGNhdGNo IHRoZSBtZWFuaW5nIG9mDQomcXVvdDt3aGVuIHlvdSBmYWN0b3IgaW4gUkZDMzMxMSZxdW90Oy4g Q291bGQgeW91IHNob3cgbWUgdGhlIG1lYW5pbmc/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7 OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+QnJldHQgVGF0ZSAmbHQ7YnJldHRAYnJvYWRzb2Z0LmNvbSZndDs8L2I+DQo8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wNS0yNCAyMTozNzwvZm9u dD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv dDtnYW8ueWFuZzJAenRlLmNvbS5jbiZxdW90OyAmbHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7 PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBj b3JlQGlldGYub3JnJmd0OywNCiZxdW90O3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyZxdW90OyAm bHQ7c2lwY29yZS1ib3VuY2VzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtz aXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6DQpnbGFyZSBhbmQgVVBEQVRF IHdpdGhvdXQgU0RQPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0ic2Fucy1zZXJpZiI+VGhhdCBtaWdodCBiZSB3 aGF0IHlvdQ0Kd2FudGVkIHNlY3Rpb25zIDMuNSBhbmQgNC41IHRvIG1lYW47IGhvd2V2ZXIgaXQg Y3VycmVudGx5IGRvZXNuoa90IG1lYW4NCnRoYXQgd2hlbiB5b3UgZmFjdG9yIGluIFJGQzMzMTEu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwv Yj4gZ2FvLnlhbmcyQHp0ZS5jb20uY24gW21haWx0bzpnYW8ueWFuZzJAenRlLmNvbS5jbl0NCjxi Pjxicj4NClNlbnQ6PC9iPiBNb25kYXksIE1heSAyNCwgMjAxMCA5OjMwIEFNPGI+PGJyPg0KVG86 PC9iPiBCcmV0dCBUYXRlPGI+PGJyPg0KQ2M6PC9iPiBzaXBjb3JlQGlldGYub3JnOyBzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBkcmFm dC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6IGdsYXJlIGFuZCBVUERBVEUNCndpdGhvdXQgU0RQ PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCnNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9Ik1TIEdvdGhpYyI+0LTT 2jwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPg0KMjAxMC0wNS0yNCAyMToy NToyODo8YnI+DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyBDb25jZXJuaW5nIGdsYXJlLCBteSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgdGhlIGRyYWZ0IG1hbmRhdGVzDQo8YnI+DQomZ3Q7ICZndDsgJmd0 OyB0cmVhdGluZyBVUERBVEUgd2l0aG91dCBvZmZlciBhcyB0aG91Z2ggaXQgY29udGFpbmVkIGFu DQpvZmZlci48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJJ20gc3Rp bGwgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IHNlY3Rpb24gMy41IGFuZCA0LjUgYXJlDQp0byBi ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBpbnRlcnByZXRlZC4gJm5ic3A7QmVjYXVzZSB0aGUgZHJh ZnQgdXNlcyBvZmZlci9hbnN3ZXIgcnVsZXMNCmZvciB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg JnF1b3Q7Zml4JnF1b3Q7LCBpdCBwcmV2ZW50cyB1c2luZyBVUERBVEUgd2l0aG91dCBTRFAgb24N CmFuIGVhcmx5IGRpYWxvZyB1bnRpbDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFsbG93ZWQgcGVyIG9m ZmVyL2Fuc3dlciBydWxlcy4gPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE5vdCBleGFj dGx5IGhlcmUuIFRoZSB0ZXh0IG5ldmVyIGZvcmJpdCB1c2FnZSBvZiBVUERBVEUgd2l0aG91dA0K PGJyPg0KJmd0OyBvZmZlciBieSBPL0EgcnVsZXMuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFn cmVlIHRoYXQgaXQgZG9lc24ndCBmb3JiaWQgc2VuZGluZyBpdC4gJm5ic3A7SXQgYWxsb3dzIGl0 IGFuZA0KPGJyPg0KJmd0OyBtYW5kYXRlcyB0aGUgVUFTIHJldHVybiA0OTEgb3IgNTAwIChkZXBl bmRpbmcgdXBvbiBkaXJlY3Rpb24pLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQpJdCBtYW5kYXRlcyB0aGUgVUFTIHNlbmQgNHh4LzV4eCB0byBVUERBVEUgb25seSB3aGVuIHRo ZSBVQVMgc2VuZCA0eHgvNXh4DQp0byB0aGUgUmUtSU5WSVRFIGFuZCB0aGUgVUFTIGdldCB0aGUg VVBEQVRFIGJlZm9yZSBBQ0sgb2YgNHh4LzV4eChSZS1JTlZJVEUpLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCklmIFVBUyBzZW5kIDJ4eCB0byBSZS1JTlZJVEUsIHRoZSBV QVMgd291bGQgbm90IHNlbmQgNHh4LzV4eCB0byB0aGUgVVBEQVRFLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCkFuZCBpZiB0aGUgVUFTIGdldCB0aGUgQUNLKFJlLUlOVklU RSdzIDR4eC81eHgpIGZpcnN0bHksIHRoZSBVQVMgYWxzbyB3b3VsZA0Kbm90IG1hbmRhdGUgdG8g dGhlIHJ1bGVzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+WlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNv bGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLg0KVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQNCnRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzDQpjb21tdW5pY2F0aW9uIHRvIG90aGVycy48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQNCndpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsDQpvciBlbnRpdHkgdG8gd2hv bSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4N CmVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQNCmluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1 YWwgc2VuZGVyLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRo aXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzDQphbmQgU3BhbSBieSBaVEUg QW50aS1TcGFtIHN5c3RlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZv cm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0 aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5i c3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5i c3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZu YnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNw O2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNw O3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0 byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwm bmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZu YnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQm bmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNw O3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZl Jm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5i c3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5i c3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZu YnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdl Jm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5i c3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lz dGVtLg0KPC9wcmU+ --=_alternative 004B434C4825772D_=-- From brett@broadsoft.com Mon May 24 06:49:01 2010 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 4289A3A6BFE for ; Mon, 24 May 2010 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 g1Ari5tVa2sK for ; Mon, 24 May 2010 06:49:00 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 541843A6BE7 for ; Mon, 24 May 2010 06:49:00 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 24 May 2010 06:48:52 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 06:47:48 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr7RvjGMQlolh7PSgW2xnhgqDOOCwAABNUg Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC3BA@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DC3A2@EXMBXCLUS01.citservers.local> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:49:01 -0000 > Sorry, I can't catch the meaning of "when you factor=20 > in RFC3311". Could you show me the meaning? Look at RFC3311 (especially section 5.2) concerning how to behave when UPDA= TE offer is received while there is an outstanding offer. " If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds." From gao.yang2@zte.com.cn Mon May 24 06:58:45 2010 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 DB6AD3A6E2A for ; Mon, 24 May 2010 06:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.252 X-Spam-Level: X-Spam-Status: No, score=-97.252 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 5Xtqp2rlxAHw for ; Mon, 24 May 2010 06:58:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 8FD023A6E3B for ; Mon, 24 May 2010 06:58:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Mon, 24 May 2010 21:52:16 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 13308.3612446977; Mon, 24 May 2010 21:53:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4ODwqvW034774; Mon, 24 May 2010 21:58:53 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC3BA@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 21:56:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 21:58:31, Serialize complete at 2010-05-24 21:58:31 Content-Type: multipart/alternative; boundary="=_alternative 004CBCDA4825772D_=" X-MAIL: mse2.zte.com.cn o4ODwqvW034774 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 13:58:45 -0000 This is a multipart message in MIME format. --=_alternative 004CBCDA4825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QnJldHQgVGF0ZSA8YnJldHRAYnJvYWRzb2Z0LmNvbT4g0LTT2iAyMDEwLTA1LTI0IDIxOjQ3OjQ4 Og0KDQo+ID4gU29ycnksIEkgY2FuJ3QgY2F0Y2ggdGhlIG1lYW5pbmcgb2YgIndoZW4geW91IGZh Y3RvciANCj4gPiBpbiBSRkMzMzExIi4gQ291bGQgeW91IHNob3cgbWUgdGhlIG1lYW5pbmc/DQo+ IA0KPiBMb29rIGF0IFJGQzMzMTEgKGVzcGVjaWFsbHkgc2VjdGlvbiA1LjIpIGNvbmNlcm5pbmcg aG93IHRvIGJlaGF2ZSANCj4gd2hlbiBVUERBVEUgb2ZmZXIgaXMgcmVjZWl2ZWQgd2hpbGUgdGhl cmUgaXMgYW4gb3V0c3RhbmRpbmcgb2ZmZXIuDQoNCkkga25vdyB0aGlzIHBhcnQgb2YgMzMxMS4g SSBkb24ndCBrbm93IHRoZSBtZWFuaW5nIG9mIHdoeSB5b3UgaGlnaGxpZ2h0IA0KdGhpcyBwYXJ0 Lg0KDQpEbyB5b3UgdGhpbmsgdGV4dCBvZiBvdXIgZHJhZnQgaGFzIGNvbmZsaWN0IHdpdGggdGhp cyBwYXJ0IG9mIDMzMTEgaGVyZT8NCg0KSSBkb24ndCB0aGluayBzbywgYXMgb3VyIHRleHQgb25s eSBmb3IgYW1iaWd1b3VzIGNhc2VzLg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 004CBCDA4825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5CcmV0dCBUYXRlICZsdDticmV0dEBicm9hZHNv ZnQuY29tJmd0OyDQtNPaIDIwMTAtMDUtMjQNCjIxOjQ3OjQ4Ojxicj4NCjxicj4NCiZndDsgJmd0 OyBTb3JyeSwgSSBjYW4ndCBjYXRjaCB0aGUgbWVhbmluZyBvZiAmcXVvdDt3aGVuIHlvdSBmYWN0 b3IgPGJyPg0KJmd0OyAmZ3Q7IGluIFJGQzMzMTEmcXVvdDsuIENvdWxkIHlvdSBzaG93IG1lIHRo ZSBtZWFuaW5nPzxicj4NCiZndDsgPGJyPg0KJmd0OyBMb29rIGF0IFJGQzMzMTEgKGVzcGVjaWFs bHkgc2VjdGlvbiA1LjIpIGNvbmNlcm5pbmcgaG93IHRvIGJlaGF2ZQ0KPGJyPg0KJmd0OyB3aGVu IFVQREFURSBvZmZlciBpcyByZWNlaXZlZCB3aGlsZSB0aGVyZSBpcyBhbiBvdXRzdGFuZGluZyBv ZmZlci48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkga25vdyB0aGlz IHBhcnQgb2YgMzMxMS4gSSBkb24ndCBrbm93IHRoZSBtZWFuaW5nDQpvZiB3aHkgeW91IGhpZ2hs aWdodCB0aGlzIHBhcnQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5E byB5b3UgdGhpbmsgdGV4dCBvZiBvdXIgZHJhZnQgaGFzIGNvbmZsaWN0IHdpdGggdGhpcw0KcGFy dCBvZiAzMzExIGhlcmU/PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5J IGRvbid0IHRoaW5rIHNvLCBhcyBvdXIgdGV4dCBvbmx5IGZvciBhbWJpZ3VvdXMgY2FzZXMuPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1Nl Y3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFp bmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7 cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9u LiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29u ZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJl Jm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDth bmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3Nl Jm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDth bnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJl Jm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJz cDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUm bmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQm bmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7 bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVz c2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7 YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3Bh bSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 004CBCDA4825772D_=-- From brett@broadsoft.com Mon May 24 07:19:21 2010 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 42F773A6816 for ; Mon, 24 May 2010 07:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_05=-1.11] 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 RRT3+YJYhi8q for ; Mon, 24 May 2010 07:19:20 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 17D7E3A6BF8 for ; Mon, 24 May 2010 07:19:20 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 24 May 2010 07:19:12 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 07:18:10 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr7STYnTonAf5FDRDeVocMwC8qGgAAABs1Q Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC3F5@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DC3BA@EXMBXCLUS01.citservers.local> 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 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 14:19:21 -0000 > > Look at RFC3311 (especially section 5.2) concerning how to behave=20 > > when UPDATE offer is received while there is an outstanding offer. >=20 > I know this part of 3311. I don't know the meaning of why=20 > you highlight this part.=20 > > Do you think text of our draft has conflict with this part of 3311 here?= =20 > > I don't think so, as our text only for ambiguous cases.=20 I'm indicating that the RFC3311 mandates the returning 491 or 500 (dependin= g upon direction). You are indicating that the RFC3311 text doesn't apply even though draft-ie= tf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate they would apply. RFC= 3311 section 5.2 includes glare checking as part of normal UPDATE processin= g. The drafts normative text causing the issue: "When checking for glare situa= tions, UAs MUST treat every UPDATE request as if it contained an offer." You keep interpreting/indicating that the normative text does not apply to = all UPDATEs. Please provide the normative text which indicates your interp= retation. Thanks, Brett From brett@broadsoft.com Mon May 24 07:28:48 2010 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 00A223A6407 for ; Mon, 24 May 2010 07:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 9LWCW294sLEn for ; Mon, 24 May 2010 07:28:47 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 3DBD83A6877 for ; Mon, 24 May 2010 07:28:47 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 24 May 2010 07:28:39 -0700 From: Brett Tate To: "sipcore@ietf.org" , "Gonzalo.Camarillo@ericsson.com" , "Christer.Holmberg@ericsson.com" , "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 07:27:37 -0700 Thread-Topic: draft-ietf-sipcore-reinvite-04: updates rfc3311 Thread-Index: Acr7TUHsmyb4SCAhTGiGS6yCCHxBLQ== Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC40C@EXMBXCLUS01.citservers.local> 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 Subject: [sipcore] draft-ietf-sipcore-reinvite-04: updates rfc3311 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, 24 May 2010 14:28:48 -0000 Doesn't draft-ietf-sipcore-reinvite-04 update RFC3311? For instance section 4.5 indicates the following: "When checking for glare = situations, UAs MUST treat every UPDATE request as if it contained an offer= ." If the answer is yes, does it need to be listed on first page next to 3261? Thanks, Brett From gao.yang2@zte.com.cn Mon May 24 07:37:48 2010 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 5478E3A67F2 for ; Mon, 24 May 2010 07:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.602 X-Spam-Level: X-Spam-Status: No, score=-98.602 tagged_above=-999 required=5 tests=[AWL=1.747, BAYES_05=-1.11, 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 sra0ODuR2G5U for ; Mon, 24 May 2010 07:37:47 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C8D503A6832 for ; Mon, 24 May 2010 07:37:46 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 24 May 2010 22:32:21 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 13308.8280906739; Mon, 24 May 2010 22:32:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4OEbhfj060401; Mon, 24 May 2010 22:37:43 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC3F5@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 22:35:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 22:37:20, Serialize complete at 2010-05-24 22:37:20 Content-Type: multipart/alternative; boundary="=_alternative 00504ADE4825772D_=" X-MAIL: mse2.zte.com.cn o4OEbhfj060401 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 14:37:48 -0000 This is a multipart message in MIME format. --=_alternative 00504ADE4825772D_= Content-Type: text/plain; charset="US-ASCII" Rules for "When checking for glare situations" in the draft text means the UAs's reasoning and handling while the UAs are in a glare situations, which is ambiguous. It does not means UAs reasoning and handling for every use case to figure out whether this case is a glare case. This is my understanding. And I'd like other co-authors and important reviewer to comment on this point. > > > Look at RFC3311 (especially section 5.2) concerning how to behave > > > when UPDATE offer is received while there is an outstanding offer. > > > > I know this part of 3311. I don't know the meaning of why > > you highlight this part. > > > > Do you think text of our draft has conflict with this part of 3311 here? > > > > I don't think so, as our text only for ambiguous cases. > > I'm indicating that the RFC3311 mandates the returning 491 or 500 > (depending upon direction). > > You are indicating that the RFC3311 text doesn't apply even though > draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate they > would apply. RFC3311 section 5.2 includes glare checking as part of > normal UPDATE processing. > > The drafts normative text causing the issue: "When checking for > glare situations, UAs MUST treat every UPDATE request as if it > contained an offer." > > You keep interpreting/indicating that the normative text does not > apply to all UPDATEs. Please provide the normative text which > indicates your interpretation. > > Thanks, > Brett > > -------------------------------------------------------- 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 00504ADE4825772D_= Content-Type: text/html; charset="US-ASCII"
Rules for "When checking for glare situations" in the draft text means the UAs's reasoning and handling while the UAs are in a glare situations, which is ambiguous.

It does not means UAs reasoning and handling for every use case to figure out whether this case is a glare case.

This is my understanding. And I'd like other co-authors and important reviewer to comment on this point.

> > > Look at RFC3311 (especially section 5.2) concerning how to behave
> > > when UPDATE offer is received while there is an outstanding offer.
> >
> > I know this part of 3311. I don't know the meaning of why
> > you highlight this part.
> >
> > Do you think text of our draft has conflict with this part of 3311 here?
> >
> > I don't think so, as our text only for ambiguous cases.
>
> I'm indicating that the RFC3311 mandates the returning 491 or 500
> (depending upon direction).
>
> You are indicating that the RFC3311 text doesn't apply even though
> draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate they
> would apply.  RFC3311 section 5.2 includes glare checking as part of
> normal UPDATE processing.
>
> The drafts normative text causing the issue: "When checking for
> glare situations, UAs MUST treat every UPDATE request as if it
> contained an offer."
>
> You keep interpreting/indicating that the normative text does not
> apply to all UPDATEs.  Please provide the normative text which
> indicates your interpretation.
>
> Thanks,
> Brett
>
> 

--------------------------------------------------------
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 00504ADE4825772D_=-- From gao.yang2@zte.com.cn Mon May 24 07:45:36 2010 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 3D7FB3A6832 for ; Mon, 24 May 2010 07:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.259 X-Spam-Level: X-Spam-Status: No, score=-97.259 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 HZDQyzR83KAs for ; Mon, 24 May 2010 07:45:35 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 919783A682A for ; Mon, 24 May 2010 07:45:34 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Mon, 24 May 2010 22:39:00 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 13308.6475270971; Mon, 24 May 2010 22:40:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4OEjaj9064829; Mon, 24 May 2010 22:45:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC40C@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 24 May 2010 22:42:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-24 22:45:14, Serialize complete at 2010-05-24 22:45:14 Content-Type: multipart/alternative; boundary="=_alternative 0051039E4825772D_=" X-MAIL: mse2.zte.com.cn o4OEjaj9064829 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: updates rfc3311 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, 24 May 2010 14:45:36 -0000 This is a multipart message in MIME format. --=_alternative 0051039E4825772D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIG5ldyBxdWVzdGlvbi4gQW5kIEkgdGhpbmsgSSBjYW4gb25seSBnaXZlIHRoZSBy ZXBseSBhZnRlciBhIA0KdGhvcm91Z2ggZXZhbHVhdGlvbi4NCg0KVGhhbmtzLA0KDQpHYW8NCg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBU ZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2Fv LnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN Cg0KDQpCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQuY29tPiANCreivP7IyzogIHNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNS0yNCAyMjoyNw0KDQrK1bz+yMsNCiJzaXBjb3JlQGll dGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4sICJHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5j b20iIA0KPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT4sICJDaHJpc3Rlci5Ib2xtYmVy Z0Blcmljc3Nvbi5jb20iIA0KPENocmlzdGVyLkhvbG1iZXJnQGVyaWNzc29uLmNvbT4sICJnYW8u eWFuZzJAenRlLmNvbS5jbiIgDQo8Z2FvLnlhbmcyQHp0ZS5jb20uY24+DQqzrcvNDQoNCtb3zOIN CltzaXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6IHVwZGF0ZXMgcmZjMzMx MQ0KDQoNCg0KDQoNCg0KRG9lc24ndCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQgdXBk YXRlIFJGQzMzMTE/DQoNCkZvciBpbnN0YW5jZSBzZWN0aW9uIDQuNSBpbmRpY2F0ZXMgdGhlIGZv bGxvd2luZzogIldoZW4gY2hlY2tpbmcgZm9yIGdsYXJlIA0Kc2l0dWF0aW9ucywgVUFzIE1VU1Qg dHJlYXQgZXZlcnkgVVBEQVRFIHJlcXVlc3QgYXMgaWYgaXQgY29udGFpbmVkIGFuIA0Kb2ZmZXIu Ig0KDQpJZiB0aGUgYW5zd2VyIGlzIHllcywgZG9lcyBpdCBuZWVkIHRvIGJlIGxpc3RlZCBvbiBm aXJzdCBwYWdlIG5leHQgdG8gDQozMjYxPw0KDQpUaGFua3MsDQpCcmV0dA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxp c3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkg b2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMg Y29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFp bnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkg ZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhl eSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBl eHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5k ZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBi eSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0051039E4825772D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoaXMgaXMgYSBuZXcgcXVlc3Rp b24uIEFuZCBJIHRoaW5rDQpJIGNhbiBvbmx5IGdpdmUgdGhlIHJlcGx5IGFmdGVyIGEgdGhvcm91 Z2ggZXZhbHVhdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAm bmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAm bmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNv bS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkJyZXR0IFRhdGUgJmx0 O2JyZXR0QGJyb2Fkc29mdC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA1LTI0IDIyOjI3 PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZxdW90O3NpcGNvcmVAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7LA0K JnF1b3Q7R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tJnF1b3Q7ICZsdDtHb256YWxvLkNh bWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7LA0KJnF1b3Q7Q2hyaXN0ZXIuSG9sbWJlcmdAZXJpY3Nz b24uY29tJnF1b3Q7ICZsdDtDaHJpc3Rlci5Ib2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7LA0KJnF1 b3Q7Z2FvLnlhbmcyQHp0ZS5jb20uY24mcXVvdDsgJmx0O2dhby55YW5nMkB6dGUuY29tLmNuJmd0 OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+W3NpcGNvcmVdIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNDoNCnVwZGF0ZXMgcmZj MzMxMTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+RG9lc24ndCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQgdXBkYXRlIFJGQzMz MTE/PGJyPg0KPGJyPg0KRm9yIGluc3RhbmNlIHNlY3Rpb24gNC41IGluZGljYXRlcyB0aGUgZm9s bG93aW5nOiAmcXVvdDtXaGVuIGNoZWNraW5nIGZvcg0KZ2xhcmUgc2l0dWF0aW9ucywgVUFzIE1V U1QgdHJlYXQgZXZlcnkgVVBEQVRFIHJlcXVlc3QgYXMgaWYgaXQgY29udGFpbmVkDQphbiBvZmZl ci4mcXVvdDs8YnI+DQo8YnI+DQpJZiB0aGUgYW5zd2VyIGlzIHllcywgZG9lcyBpdCBuZWVkIHRv IGJlIGxpc3RlZCBvbiBmaXJzdCBwYWdlIG5leHQgdG8gMzI2MT88YnI+DQo8YnI+DQpUaGFua3Ms PGJyPg0KQnJldHQ8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxi cj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3Jt YXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlv biZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNw O3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNw O29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJz cDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDth Ym92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtz ZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8m bmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5i c3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5i c3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJz cDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5i c3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0 aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZu YnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNw O3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNw O3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZu YnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNw O2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3Rl bS4NCjwvcHJlPg== --=_alternative 0051039E4825772D_=-- From brett@broadsoft.com Mon May 24 08:03:28 2010 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 AE5E83A694E for ; Mon, 24 May 2010 08:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 vGzcxyO8T4qX for ; Mon, 24 May 2010 08:03:27 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id C3E8B3A6935 for ; Mon, 24 May 2010 08:03:27 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 24 May 2010 08:03:19 -0700 From: Brett Tate To: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" , "Gonzalo.Camarillo@ericsson.com" , "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 08:02:10 -0700 Thread-Topic: draft-ietf-sipcore-reinvite-04: impacts upon REFER and NOTIFY Thread-Index: Acr7UhXEbOhnW+IIRaCuELyneAdcZw== Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC46A@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AHrz FTq2 HsgG Iz+p Lw+Q NvLz c6Cd fvUS f72n g1Oz g71Z kqGI ocvf rVIb szA9 t6Ar; 4; YwBoAHIAaQBzAHQAZQByAC4AaABvAGwAbQBiAGUAcgBnAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBnAGEAbwAuAHkAYQBuAGcAMgBAAHoAdABlAC4AYwBvAG0ALgBjAG4AOwBnAG8AbgB6AGEAbABvAC4AYwBhAG0AYQByAGkAbABsAG8AQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA7AHMAaQBwAGMAbwByAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A5E39993-E556-4C92-93DA-5AE6BB02C297}; YgByAGUAdAB0AEAAYgByAG8AYQBkAHMAbwBmAHQALgBjAG8AbQA=; Mon, 24 May 2010 15:02:10 GMT; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAHMAaQBwAGMAbwByAGUALQByAGUAaQBuAHYAaQB0AGUALQAwADQAOgAgAGkAbQBwAGEAYwB0AHMAIAB1AHAAbwBuACAAUgBFAEYARQBSACAAYQBuAGQAIABOAE8AVABJAEYAWQA= x-cr-puzzleid: {A5E39993-E556-4C92-93DA-5AE6BB02C297} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-reinvite-04: impacts upon REFER and NOTIFY 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, 24 May 2010 15:03:28 -0000 Since in-dialog REFER and NOTIFY are target refresh requests, what are the = impacts of section 4.5 "Race Conditions and Target Refreshes" upon REFER an= d NOTIFY? It doesn't look like there are any normative impacts. However I wasn't sur= e if this was intentional. Thanks, Brett From john.elwell@siemens-enterprise.com Mon May 24 08:12:46 2010 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 7FE573A69B1 for ; Mon, 24 May 2010 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, 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 mu+-j96TnBAQ for ; Mon, 24 May 2010 08:12:45 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9B33D3A68DA for ; Mon, 24 May 2010 08:12:44 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-269616; Mon, 24 May 2010 17:12:36 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 67CE41EB82AE; Mon, 24 May 2010 17:12:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 24 May 2010 17:12:36 +0200 From: "Elwell, John" To: Brett Tate , "gao.yang2@zte.com.cn" Date: Mon, 24 May 2010 17:12:35 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr7Qyz3H+QHWNdTSwSlNkyEdY7eMgAAFjTAAAPmxsA= Message-ID: References: <747A6506A991724FB09B129B79D5FEB614816DC354@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC383@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC383@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 24 May 2010 15:12:46 -0000 If an UPDATE request without SDP offer cannot be accepted when only an unre= liable provisional response has occurred, I believe this is a normative cha= nge to RFC 3311. John > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com]=20 > Sent: 24 May 2010 14:25 > To: gao.yang2@zte.com.cn > Cc: Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare=20 > and UPDATE without SDP >=20 > > > Concerning glare, my understanding is that the draft mandates=20 > > > treating UPDATE without offer as though it contained an offer. > > >=20 > > > I'm still trying to understand how section 3.5 and 4.5 are to be=20 > > > interpreted. =A0Because the draft uses offer/answer rules for the=20 > > > "fix", it prevents using UPDATE without SDP on an early=20 > dialog until > > > allowed per offer/answer rules.=20 > > > > Not exactly here. The text never forbit usage of UPDATE=20 > without offer by O/A rules.=20 >=20 > I agree that it doesn't forbid sending it. It allows it and=20 > mandates the UAS return 491 or 500 (depending upon direction). >=20 > = From glen@amsl.com Mon May 24 09:02:22 2010 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 25D6A3A6B63 for ; Mon, 24 May 2010 09:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.006 X-Spam-Level: X-Spam-Status: No, score=-102.006 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, 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 b9m1dsWwja8u for ; Mon, 24 May 2010 09:02:21 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 557693A6B05 for ; Mon, 24 May 2010 09:02:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 12E00E0862 for ; Mon, 24 May 2010 09:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+D+e7yuJkgi for ; Mon, 24 May 2010 09:02:13 -0700 (PDT) Received: from [192.168.1.103] (173-8-133-91-SFBA.hfc.comcastbusiness.net [173.8.133.91]) by c1a.amsl.com (Postfix) with ESMTPSA id BBF56E075A for ; Mon, 24 May 2010 09:02:13 -0700 (PDT) Message-Id: <8943F601-1D43-46CB-AE9C-6DE774164A67@amsl.com> From: "Glen Barney (AMS)" To: sipcore@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-5-56989838; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 May 2010 09:02:12 -0700 X-Mailer: Apple Mail (2.936) Subject: [sipcore] Test, please ignore 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, 24 May 2010 16:02:22 -0000 --Apple-Mail-5-56989838 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit AMS is checking the operation of the SIPCORE list to ensure that mail is flowing correctly. There may be several of these tests today. We apologize for the inconvenience. Glen Barney IT Director AMS (IETF Secretariat) --Apple-Mail-5-56989838 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILBDCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggYfMIIFB6AD AgECAhAWVoaeQZygo2d0zUaQSOaxMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEwMDQyMjAwMDAw MFoXDTExMDQyMjIzNTk1OVowgdQxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3JrIC0gUEVS U09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBvZiB1c2U6 IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAzIENvbW9k byBMaW1pdGVkMRQwEgYDVQQDEwtHbGVuIEJhcm5leTEcMBoGCSqGSIb3DQEJARYNZ2xlbkBhbXNs LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKK77Vp8AxCW8pQsXk2MvbN6oqi1 ysNgWqq510g7q2FLJmT0EvQb87vmEfnyoSwNGIl90SoyAKYhtKBsN+AYicBQ36Y0qa1mwBZntgyq DSXDJDOkLL7k/snEE9ud9hSJtMuLYW0w04SnqTOeM0r3bjHANzTvsBgdUAOxxBmoCBWJ1K21stWP ScbFTsj3ZIdSiJ1pb7G4tVrWefJI+mzfEQ2fejjzDHu02EhenuStUiLRMR+uncLvlBodkBRyqQuZ 6QDu+9ex68Qj7L0lba5gC4oiH18Og9Uvkuu/ybs1hh7hQnj51dJK38zICvY4D7dBwoC21cfrazjy UfmMOSKR1EkCAwEAAaOCAg8wggILMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0G A1UdDgQWBBRjbTGY2rh0cbj67bIKnjySX5yxDDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIw ADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYG A1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0 dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k RW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9j YS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wGAYDVR0RBBEwD4ENZ2xlbkBhbXNsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAX/mU8kg8 EKsmnqBUF8OoMWhuplMgypV1tiwwaFMDVagET3zxq5UItoVWHGUnwkzM1eVoKENlBoTUWyPhfdWN QeD4adpGzB5WWoFut6lTAh5rjuvG/M+o4D9J3w3yalB/pqD3hQipfVeSY5ExfEXA2G0GUv1M6V3C 8jca4bRGy6axCkM3m+/m/kkNL+nU87TrmljiuEn7TcpkVzR4tF8BOXXhe2Dp/8qkFm0aAUj+bg0y TAwDXJSq7ot+mTxY3au+t52pUjzXAB4do5u06toAPKGxRTdyWDefVKRzZ38WaxNsDSG0O8iJVU3M 2eRnlDshhCdAYoZgQMObR6tdtdM+UjGCA/wwggP4AgEBMIHDMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAWVoaeQZygo2d0zUaQ SOaxMAkGBSsOAwIaBQCgggINMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDUyNDE2MDIxM1owIwYJKoZIhvcNAQkEMRYEFKOTcB+x8dU3Ylr64E4rky4IEvNVMIHU BgkrBgEEAYI3EAQxgcYwgcMwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEBZWhp5BnKCjZ3TNRpBI5rEwgdYGCyqGSIb3DQEJEAIL MYHGoIHDMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhAWVoaeQZygo2d0zUaQSOaxMA0GCSqGSIb3DQEBAQUABIIBAFzxtOyxLjDr z32G5Q16GYofNvEy5vtz5MeXvsLfEVYkRyG1YbNr2VHDL6zgYlEht3mbnc44BESvANwnUCpBpdj0 4y083K8utb+Afz4htXX9QeldSNKuPjo3YejEaRXG9Y5LxdhGi0B0YKr2UhtqC4UoniPcoGyzTw2c NVadNn74nN0aDCg4ctPMVI7s9rXEYkEI+gH5DSG+HyAaKFWluRieYYNWQnC3LA93LqK+eeto2y+t +t9SwZn1YYgS15Yyl5wf0KN3rOkMg7s9XGGuZJjnVDUGa42o0JoRD82jVSRyTGF9JRy/DCtDLbSf eCpCCI8+d7P5dgiJlPjJqTmQzHoAAAAAAAA= --Apple-Mail-5-56989838-- From glen@amsl.com Mon May 24 09:09:14 2010 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 2EAF43A6C62 for ; Mon, 24 May 2010 09:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.08 X-Spam-Level: X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, 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 t6OGDY7W+1Kt for ; Mon, 24 May 2010 09:09:13 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id DF2263A6CCF for ; Mon, 24 May 2010 09:09:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 9E18CE08B6 for ; Mon, 24 May 2010 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUQ0t9ONFIl0 for ; Mon, 24 May 2010 09:09:00 -0700 (PDT) Received: from [192.168.1.103] (173-8-133-91-SFBA.hfc.comcastbusiness.net [173.8.133.91]) by c1a.amsl.com (Postfix) with ESMTPSA id 3E43DE087B for ; Mon, 24 May 2010 09:09:00 -0700 (PDT) Message-Id: <1AF640A1-244A-48ED-9D14-E4957763359C@amsl.com> From: "Glen Barney (AMS)" To: sipcore@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-7-57396715; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 May 2010 09:08:59 -0700 X-Mailer: Apple Mail (2.936) Subject: [sipcore] Test 2 - Please ignore 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, 24 May 2010 16:09:14 -0000 --Apple-Mail-7-57396715 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Test 2, please ignore --Apple-Mail-7-57396715 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILBDCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggYfMIIFB6AD AgECAhAWVoaeQZygo2d0zUaQSOaxMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEwMDQyMjAwMDAw MFoXDTExMDQyMjIzNTk1OVowgdQxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3JrIC0gUEVS U09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBvZiB1c2U6 IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAzIENvbW9k byBMaW1pdGVkMRQwEgYDVQQDEwtHbGVuIEJhcm5leTEcMBoGCSqGSIb3DQEJARYNZ2xlbkBhbXNs LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKK77Vp8AxCW8pQsXk2MvbN6oqi1 ysNgWqq510g7q2FLJmT0EvQb87vmEfnyoSwNGIl90SoyAKYhtKBsN+AYicBQ36Y0qa1mwBZntgyq DSXDJDOkLL7k/snEE9ud9hSJtMuLYW0w04SnqTOeM0r3bjHANzTvsBgdUAOxxBmoCBWJ1K21stWP ScbFTsj3ZIdSiJ1pb7G4tVrWefJI+mzfEQ2fejjzDHu02EhenuStUiLRMR+uncLvlBodkBRyqQuZ 6QDu+9ex68Qj7L0lba5gC4oiH18Og9Uvkuu/ybs1hh7hQnj51dJK38zICvY4D7dBwoC21cfrazjy UfmMOSKR1EkCAwEAAaOCAg8wggILMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0G A1UdDgQWBBRjbTGY2rh0cbj67bIKnjySX5yxDDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIw ADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYG A1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0 dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k RW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9j YS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wGAYDVR0RBBEwD4ENZ2xlbkBhbXNsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAX/mU8kg8 EKsmnqBUF8OoMWhuplMgypV1tiwwaFMDVagET3zxq5UItoVWHGUnwkzM1eVoKENlBoTUWyPhfdWN QeD4adpGzB5WWoFut6lTAh5rjuvG/M+o4D9J3w3yalB/pqD3hQipfVeSY5ExfEXA2G0GUv1M6V3C 8jca4bRGy6axCkM3m+/m/kkNL+nU87TrmljiuEn7TcpkVzR4tF8BOXXhe2Dp/8qkFm0aAUj+bg0y TAwDXJSq7ot+mTxY3au+t52pUjzXAB4do5u06toAPKGxRTdyWDefVKRzZ38WaxNsDSG0O8iJVU3M 2eRnlDshhCdAYoZgQMObR6tdtdM+UjGCA/wwggP4AgEBMIHDMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAWVoaeQZygo2d0zUaQ SOaxMAkGBSsOAwIaBQCgggINMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDUyNDE2MDg2MFowIwYJKoZIhvcNAQkEMRYEFP7uxbxN4Fx8SNZcKZyTXA4ysGt5MIHU BgkrBgEEAYI3EAQxgcYwgcMwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEBZWhp5BnKCjZ3TNRpBI5rEwgdYGCyqGSIb3DQEJEAIL MYHGoIHDMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhAWVoaeQZygo2d0zUaQSOaxMA0GCSqGSIb3DQEBAQUABIIBACnXQmcs2aVR GqdSN2Jj3u7VAa5MUs60lRcDpxnyHa2zHW/nECIjF1ZLvGROYzMhGEMzvB7OyGRUVDlgT4rrRajN CGcGse06Zxk9crv6Rvm4OezmpN6rRmBLdyYJwnjw35BGDf/jGYwVs7NNxzeqdIuMxX3E72Ovcr1l rfLPdQbudIi77UC2oQlRo9p/OzH4BQwqk15/tS4oj7eWXBoW6iGGRBLX/KfCgXiI5e9wyosOzBi2 M2WDabS8Axy7GmirVU2fEnxEE5Y3JNDQN1hdXvxHS/JpGz0jsxGMa4OsqlcU2yzaFS9q2k+jr9XA V5C3H6xSz2pfACx/smUf/ZzuSjgAAAAAAAA= --Apple-Mail-7-57396715-- From christer.holmberg@ericsson.com Mon May 24 09:56:11 2010 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 BA73E3A6C51 for ; Mon, 24 May 2010 09:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.265 X-Spam-Level: X-Spam-Status: No, score=-4.265 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_20=-0.74, 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 kxM5MRRvOpCw for ; Mon, 24 May 2010 09:56:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 76C8F3A6C52 for ; Mon, 24 May 2010 09:56:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-46-4bfaaf9ee742 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 98.18.08537.E9FAAFB4; Mon, 24 May 2010 18:55:58 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 24 May 2010 18:55:57 +0200 From: Christer Holmberg To: SIPCORE Date: Mon, 24 May 2010 18:55:57 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+Cg== 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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, 24 May 2010 16:56:11 -0000 Hi, I've submitted a new version of the keep draft. Based on feedback and comments, I've moved back to the original Via paramet= er based solution. I've done a number of editorial changes in order to make the draft more cle= ar. The currently only OPEN ISSUE is whether we should use the Flow-Timer heade= r field, defined in Outbound, to indicate the keep-alive frequency, or whet= her the frequency should be added directly to the Via parameter as a parame= ter value (instead of adding a "yes" value). Using Flow-Timer is alligned with Outbound, while using a keep parameter va= lue is more "compact". Flow-Timer example: 'Flow-Timer: 30' Via keep parameter example: Via:11.22.33.44;keep=3D30 The keep-draft allows usage of the Flow-Timer header field also in initial = requests for dialogs, and mid-dialog target refresh requests, but I did not= find any text in the Outbound spec which would restrict the usage of the h= eader field to REGISTER requests only. Once we've agreed on how to move forward with the keep-alive frequency issu= e I believe the draft is ready for WGLC. Regards, Christer From root@core3.amsl.com Mon May 24 10:00:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 005F93A6C59; Mon, 24 May 2010 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100524170002.005F93A6C59@core3.amsl.com> Date: Mon, 24 May 2010 10:00:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-03.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, 24 May 2010 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-03.txt Pages : 15 Date : 2010-05-24 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives are not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-keep-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-24094627.I-D@ietf.org> --NextPart-- From shinji.okumura@softfront.jp Mon May 24 20:27:25 2010 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 B8F683A715F for ; Mon, 24 May 2010 20:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.133 X-Spam-Level: X-Spam-Status: No, score=-95.133 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 PPyfjy02dl3v for ; Mon, 24 May 2010 20:27:24 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id AE8073A7062 for ; Mon, 24 May 2010 20:21:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 5106446B603; Tue, 25 May 2010 12:21:44 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkWWaZzeu0o5; Tue, 25 May 2010 12:21:42 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 089D346B602; Tue, 25 May 2010 12:21:41 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Tue, 25 May 2010 12:21:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC36C@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DC31A@EXMBXCLUS01.citservers.local> <96CAFB3F808380shinji.okumura@softfront.jp> <747A6506A991724FB09B129B79D5FEB614816DC36C@EXMBXCLUS01.citservers.local> Message-Id: <16CAFBB964A024shinji.okumura@softfront.jp> Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 25 May 2010 03:27:25 -0000 Brett, Sorry for my lack of experience for publication of ID. Was there an announcement about WGLC in this ML? In any case, I do not deny a basic concept. I agree that UAC generate new offer to synchronize. But I doubt that UAs treat the final response to INVITE and ACK as an offer/answer exchange. Perhaps I think that my opinion is similar to yours. Regards, Shinji Brett Tate Mon, 24 May 2010 06:15:42 -0700 >> What I make an issue is the validity of it. >> I doubt whether the approach is appropriate. > >The draft has already passed WGLC. The current status is >"Publication Requested". > >Thus I'm not sure how willing the authors and working group >would be to alter the solution. However I'm not sure how many >working group members noticed the impacts of section 3.5 and 4.5. > >It definitely encourages sending answer SDP within reliable 18x. >Not doing so would block ability to use UPDATE on the early dialog. From shinji.okumura@softfront.jp Mon May 24 22:30:52 2010 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 5C5643A6A7B for ; Mon, 24 May 2010 22:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.26 X-Spam-Level: X-Spam-Status: No, score=-95.26 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 9lcHE-LTR1Gv for ; Mon, 24 May 2010 22:30:28 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 8B8113A69F7 for ; Mon, 24 May 2010 22:29:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 9239842800C; Tue, 25 May 2010 14:27:25 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVZqdtrhV-5D; Tue, 25 May 2010 14:27:24 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 067F342800B; Tue, 25 May 2010 14:27:22 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Tue, 25 May 2010 14:27:21 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: <4DCAFBCAF34347shinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 25 May 2010 05:30:53 -0000 Gao, gao.yang2@zte.com.cn Mon, 24 May 2010 21:30:21 +0800 > >> > > Concerning glare, my understanding is that the draft mandates >> > > treating UPDATE without offer as though it contained an offer. >> > > >> > > I'm still trying to understand how section 3.5 and 4.5 are to be >> > > interpreted. Because the draft uses offer/answer rules for the >> > > "fix", it prevents using UPDATE without SDP on an early dialog until >> > > allowed per offer/answer rules. >> > >> > Not exactly here. The text never forbit usage of UPDATE without >> offer by O/A rules. >> >> I agree that it doesn't forbid sending it. It allows it and >> mandates the UAS return 491 or 500 (depending upon direction). > >It mandates the UAS send 4xx/5xx to UPDATE only when the UAS >send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before >ACK of 4xx/5xx(Re-INVITE). As you know, ACK to non-2xx is hop-by-hop. There is little benefit to reject such an UPDATE. A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x(answer1)| |<------------------------------| s1| non-2xx|s1 |<------------------------------|<-+ s0|ACK |s0| |-----------> | | |UPD(offer0) | | |==============================>|* | reject UPDATE | 491(UPD)| | |<==============================| | | ACK | | | ---------->|<-+ | | Figure 2 A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x(answer1)| |<------------------------------| s1| non-2xx|s1 | /-------------|<-+ | / ACK |s0| reject UPDATE | / ---------->|<-+ |UPD(offer2) / | |=============/================>| | / 200(UPD)| |<==========/===================| s2| / |s2 |<--------/ | s0|ACK | |-----------> | | | Figure 3 I've also been pointed out by Ian Elz. Regards, Shinji >If UAS send 2xx to Re-INVITE, the UAS would not send 4xx/5xx >to the UPDATE. > >And if the UAS get the ACK(Re-INVITE's 4xx/5xx) firstly, the >UAS also would not mandate to the rules. From gao.yang2@zte.com.cn Mon May 24 23:34:08 2010 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 6E4E23A6A0A for ; Mon, 24 May 2010 23:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.861 X-Spam-Level: X-Spam-Status: No, score=-97.861 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, 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 sEDYUR8JpybU for ; Mon, 24 May 2010 23:34: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 B81923A698E for ; Mon, 24 May 2010 23:34:06 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Tue, 25 May 2010 14:27:25 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.4900341499; Tue, 25 May 2010 14:22:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4P6HmUn026503; Tue, 25 May 2010 14:17:49 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4DCAFBCAF34347shinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 25 May 2010 14:15:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-25 14:17:36, Serialize complete at 2010-05-25 14:17:36 Content-Type: multipart/alternative; boundary="=_alternative 0022894F4825772E_=" X-MAIL: mse2.zte.com.cn o4P6HmUn026503 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 25 May 2010 06:34:08 -0000 This is a multipart message in MIME format. --=_alternative 0022894F4825772E_= Content-Type: text/plain; charset="US-ASCII" Hi, > >> I agree that it doesn't forbid sending it. It allows it and > >> mandates the UAS return 491 or 500 (depending upon direction). > > > >It mandates the UAS send 4xx/5xx to UPDATE only when the UAS > >send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before > >ACK of 4xx/5xx(Re-INVITE). > > As you know, ACK to non-2xx is hop-by-hop. > There is little benefit to reject such an UPDATE. UAS send 491 for the UPDATE(in the flow) to *tell* UAC that in it's(UAS) view, there's a glare case. When UAS get the ACK then UPDATE, it still has no precise criterion for whether the UAC gets non-2xx(Re-INVITE) first then send the UPDATE or not. Keeping rejecting the UPDATE is not a reasonable way here. So, the draft suggest the way, as UAS can send 2xx to the UPDATE. When UAC get UAS's 4xx of UPDATE, the session state is clear for it. And UAC would only send a synchronizing Re-INVITE/UPDATE when it is a glare case in the UAC's view. IMO, this way is better than the way we might once use: allowing B send 2xx to UPDATE, and both A and B *see* glare, and all send Re-INVITE/UPDATE to refresh session state by each's view. Thanks, Gao > > A B > | | > s0|re-INV (offer1) |s0 > |------------------------------>| > | 18x(answer1)| > |<------------------------------| > s1| non-2xx|s1 > |<------------------------------|<-+ > s0|ACK |s0| > |-----------> | | > |UPD(offer0) | | > |==============================>|* | reject UPDATE > | 491(UPD)| | > |<==============================| | > | ACK | | > | ---------->|<-+ > | | > Figure 2 > > A B > | | > s0|re-INV (offer1) |s0 > |------------------------------>| > | 18x(answer1)| > |<------------------------------| > s1| non-2xx|s1 > | /-------------|<-+ > | / ACK |s0| reject UPDATE > | / ---------->|<-+ > |UPD(offer2) / | > |=============/================>| > | / 200(UPD)| > |<==========/===================| > s2| / |s2 > |<--------/ | > s0|ACK | > |-----------> | > | | > Figure 3 > > I've also been pointed out by Ian Elz. > > Regards, > Shinji > > >If UAS send 2xx to Re-INVITE, the UAS would not send 4xx/5xx > >to the UPDATE. > > > >And if the UAS get the ACK(Re-INVITE's 4xx/5xx) firstly, the > >UAS also would not mandate to the rules. > -------------------------------------------------------- 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 0022894F4825772E_= Content-Type: text/html; charset="US-ASCII"
Hi,


> >> I agree that it doesn't forbid sending it.  It allows it and
> >> mandates the UAS return 491 or 500 (depending upon direction).
> >
> >It mandates the UAS send 4xx/5xx to UPDATE only when the UAS
> >send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before
> >ACK of 4xx/5xx(Re-INVITE).
>
> As you know, ACK to non-2xx is hop-by-hop.
> There is little benefit to reject such an UPDATE.

UAS send 491 for the UPDATE(in the flow) to *tell* UAC that in it's(UAS) view, there's a glare case.

When UAS get the ACK then UPDATE, it still has no precise criterion for whether the UAC gets non-2xx(Re-INVITE) first then send the UPDATE or not. Keeping rejecting the UPDATE is not a reasonable way here. So, the draft suggest the way, as UAS can send 2xx to the UPDATE.

When UAC get UAS's 4xx of UPDATE, the session state is clear for it. And UAC would only send a synchronizing Re-INVITE/UPDATE when it is a glare case in the UAC's view.

IMO, this way is better than the way we might once use: allowing B send 2xx to UPDATE, and both A and B *see* glare, and all send Re-INVITE/UPDATE to refresh session state by each's view.

Thanks,

Gao

>
>     A                               B
>     |                               |
>   s0|re-INV (offer1)                |s0
>     |------------------------------>|
>     |                   18x(answer1)|
>     |<------------------------------|
>   s1|                        non-2xx|s1
>     |<------------------------------|<-+
>   s0|ACK                            |s0|
>     |----------->                   |  |
>     |UPD(offer0)                    |  |
>     |==============================>|* | reject UPDATE
>     |                       491(UPD)|  |
>     |<==============================|  |
>     |                    ACK        |  |
>     |                    ---------->|<-+
>     |                               |
>                 Figure 2
>
>     A                               B
>     |                               |
>   s0|re-INV (offer1)                |s0
>     |------------------------------>|
>     |                   18x(answer1)|
>     |<------------------------------|
>   s1|                        non-2xx|s1
>     |                 /-------------|<-+
>     |                /   ACK        |s0| reject UPDATE
>     |               /    ---------->|<-+
>     |UPD(offer2)   /                |
>     |=============/================>|
>     |            /          200(UPD)|
>     |<==========/===================|
>   s2|          /                    |s2
>     |<--------/                     |
>   s0|ACK                            |
>     |----------->                   |
>     |                               |
>                 Figure 3
>
> I've also been pointed out by Ian Elz.
>
> Regards,
> Shinji
>
> >If UAS send 2xx to Re-INVITE, the UAS would not send 4xx/5xx
> >to the UPDATE.
> >
> >And if the UAS get the ACK(Re-INVITE's 4xx/5xx) firstly, the
> >UAS also would not mandate to the rules.
> 

--------------------------------------------------------
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 0022894F4825772E_=-- From gao.yang2@zte.com.cn Tue May 25 00:14:45 2010 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 4AFCB3A6A0A for ; Tue, 25 May 2010 00:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.685 X-Spam-Level: X-Spam-Status: No, score=-95.685 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 pw8MaPl1GzOw for ; Tue, 25 May 2010 00:14:43 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A0DFF3A691E for ; Tue, 25 May 2010 00:14:42 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Tue, 25 May 2010 15:08:09 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.6475270971; Tue, 25 May 2010 15:05:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4P6xZ01018209; Tue, 25 May 2010 14:59:37 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC46A@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 25 May 2010 14:56:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-25 14:59:22, Serialize complete at 2010-05-25 14:59:22 Content-Type: multipart/alternative; boundary="=_alternative 00265D314825772E_=" X-MAIL: mse2.zte.com.cn o4P6xZ01018209 Cc: "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: impacts upon REFER and NOTIFY 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, 25 May 2010 07:14:45 -0000 This is a multipart message in MIME format. --=_alternative 00265D314825772E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGFyZ2V0IFJlZnJlc2ggUmVxdWVzdDoNCkFzIHVuaXZlcnNhbCBUYXJnZXQgUmVmcmVzaCBSZXF1 ZXN0IGlzIGRlZmluZWQgaW4gMzI2MSwgYW5kIHNlY3Rpb24gNC41IGlzIA0KYWltZWQgZm9yIHN1 Y2ggdW5pdmVyc2FsIHR5cGUsIHdoaWxlIG5vdCBqdXN0IG9uZSBvciBtb3JlIGNvbmNyZXRlIFRh cmdldCANClJlZnJlc2ggUmVxdWVzdCwgc28gSSB0aGluayBzdWNoIHBhcnQgY2FuIGJlIHRyZWF0 ZWQgYXMgVVBEQVRFIDMyNjEuDQoNClRvIGJlIGhvbmVzdCwgd2hpbGUgSSByZXZpZXcgdGhlIHRl eHQgZm9yIHRoaXMgYWltLCBJIGZpbmQgc29tZXRoaW5nIG1pZ2h0IA0KYmUgdHJlYXRlZCBhcyBV UERBVEUgMzMxMjoNCg0KSW4gc2VjdGlvbiAzLjM6DQpUaGUgc3VjY2Vzc2Z1bCBjb21wbGV0aW9u IG9mIGFuIG9mZmVyL2Fuc3dlciBleGNoYW5nZSB3aXRob3V0DQogICBwcmVjb25kaXRpb25zIGlu ZGljYXRlcyB0aGF0IHRoZSBuZXcgcGFyYW1ldGVycyBmb3IgdGhlIG1lZGlhIHN0cmVhbQ0KICAg YXJlIGFscmVhZHkgY29uc2lkZXJlZCB0byBiZSBpbiB1c2UuICBUaGUgc3VjY2Vzc2Z1bCBjb21w bGV0aW9uIG9mIGFuDQogICBvZmZlci9hbnN3ZXIgZXhjaGFuZ2Ugd2l0aCBwcmVjb25kaXRpb25z IG1lYW5zIHNvbWV0aGluZyBkaWZmZXJlbnQuDQogICBUaGUgZmFjdCB0aGF0IGFsbCBtYW5kYXRv cnkgcHJlY29uZGl0aW9ucyBmb3IgdGhlIHN0cmVhbSBhcmUgbWV0DQogICBpbmRpY2F0ZXMgdGhh dCB0aGUgbmV3IHBhcmFtZXRlcnMgZm9yIHRoZSBtZWRpYSBzdHJlYW0gYXJlIHJlYWR5IHRvDQog ICBiZSB1c2VkLiAgSG93ZXZlciwgdGhleSB3aWxsIG5vdCBhY3R1YWxseSBiZSB1c2VkIHVudGls IHRoZSBVQVMNCiAgIGRlY2lkZXMgc28uICBEdXJpbmcgYSBzZXNzaW9uIGVzdGFibGlzaG1lbnQs IHRoZSBVQVMgY2FuIHdhaXQgYmVmb3JlDQogICB1c2luZyB0aGUgbWVkaWEgcGFyYW1ldGVycyB1 bnRpbCB0aGUgY2FsbGVlIHN0YXJ0cyBiZWluZyBhbGVydGVkIG9yDQogICB1bnRpbCB0aGUgY2Fs bGVlIGFjY2VwdHMgdGhlIHNlc3Npb24uICBEdXJpbmcgYSBzZXNzaW9uIG1vZGlmaWNhdGlvbiwN CiAgIHRoZSBVQVMgY2FuIHdhaXQgdW50aWwgaXRzIHVzZXIgYWNjZXB0cyB0aGUgY2hhbmdlcyB0 byB0aGUgc2Vzc2lvbi4NCg0KQnkgbXlzZWxmLCB0aGlzIHBhcnQgaXMgY2xhcmlmaWNhdGlvbiBv ZiAzMzEyIGZvciBtb2RpZmljYXRpb24gd2l0aCANCnByZWNvbmRpdG9uLCB3aGlsZSBub3QgY29y cmVjdGlvbi4gV291bGQgc3VjaCBkZWdyZWUgYWxzbyBuZWVkIHRvIGJlIA0KdHJlYXRlZCBhcyBV UERBVEUgb2YgUkZDeHh4PyBJIGFtIG5vdCBzdXJlLCBhbmQgd291bGQgbGlrZSB0byBoZWFyIA0K c2Vhc29uZWQgcGVyc29uJ3MgcG9pbnQoc3VjaCBhcyBQYXVsIGFuZCBHb256YWxvKS4NCg0KVGhh bmtzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAg ICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjEx DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQoNCg0KDQpCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQuY29tPiANCjIw MTAtMDUtMjQgMjM6MDINCg0KytW8/sjLDQoic2lwY29yZUBpZXRmLm9yZyIgPHNpcGNvcmVAaWV0 Zi5vcmc+LCAiQ2hyaXN0ZXIuSG9sbWJlcmdAZXJpY3Nzb24uY29tIiANCjxDaHJpc3Rlci5Ib2xt YmVyZ0Blcmljc3Nvbi5jb20+LCAiR29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tIiANCjxH b256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+LCAiZ2FvLnlhbmcyQHp0ZS5jb20uY24iIA0K PGdhby55YW5nMkB6dGUuY29tLmNuPg0Ks63LzQ0KDQrW98ziDQpkcmFmdC1pZXRmLXNpcGNvcmUt cmVpbnZpdGUtMDQ6IGltcGFjdHMgdXBvbiBSRUZFUiBhbmQgTk9USUZZDQoNCg0KDQoNCg0KDQpT aW5jZSBpbi1kaWFsb2cgUkVGRVIgYW5kIE5PVElGWSBhcmUgdGFyZ2V0IHJlZnJlc2ggcmVxdWVz dHMsIHdoYXQgYXJlIHRoZSANCmltcGFjdHMgb2Ygc2VjdGlvbiA0LjUgIlJhY2UgQ29uZGl0aW9u cyBhbmQgVGFyZ2V0IFJlZnJlc2hlcyIgdXBvbiBSRUZFUiANCmFuZCBOT1RJRlk/DQoNCkl0IGRv ZXNuJ3QgbG9vayBsaWtlIHRoZXJlIGFyZSBhbnkgbm9ybWF0aXZlIGltcGFjdHMuICBIb3dldmVy IEkgd2Fzbid0IA0Kc3VyZSBpZiB0aGlzIHdhcyBpbnRlbnRpb25hbC4NCg0KVGhhbmtzLA0KQnJl dHQNCg0KDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFp biBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4N ClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpU RSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00265D314825772E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRhcmdldCBSZWZyZXNoIFJlcXVl c3Q6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BcyB1bml2ZXJz YWwgVGFyZ2V0IFJlZnJlc2ggUmVxdWVzdA0KaXMgZGVmaW5lZCBpbiAzMjYxLCBhbmQgc2VjdGlv biA0LjUgaXMgYWltZWQgZm9yIHN1Y2ggdW5pdmVyc2FsIHR5cGUsIHdoaWxlDQpub3QganVzdCBv bmUgb3IgbW9yZSBjb25jcmV0ZSBUYXJnZXQgUmVmcmVzaCBSZXF1ZXN0LCBzbyBJIHRoaW5rIHN1 Y2ggcGFydA0KY2FuIGJlIHRyZWF0ZWQgYXMgVVBEQVRFIDMyNjEuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UbyBiZSBob25lc3QsIHdoaWxlIEkgcmV2 aWV3IHRoZSB0ZXh0DQpmb3IgdGhpcyBhaW0sIEkgZmluZCBzb21ldGhpbmcgbWlnaHQgYmUgdHJl YXRlZCBhcyBVUERBVEUgMzMxMjo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkluIHNlY3Rpb24gMy4zOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPlRoZSBzdWNjZXNzZnVsIGNvbXBsZXRpb24gb2YgYW4gb2ZmZXIvYW5z d2VyDQpleGNoYW5nZSB3aXRob3V0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3ByZWNvbmRpdGlvbnMgaW5kaWNhdGVzDQp0aGF0IHRoZSBu ZXcgcGFyYW1ldGVycyBmb3IgdGhlIG1lZGlhIHN0cmVhbTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDthcmUgYWxyZWFkeSBjb25zaWRlcmVk DQp0byBiZSBpbiB1c2UuICZuYnNwO1RoZSBzdWNjZXNzZnVsIGNvbXBsZXRpb24gb2YgYW48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7b2Zm ZXIvYW5zd2VyIGV4Y2hhbmdlDQp3aXRoIHByZWNvbmRpdGlvbnMgbWVhbnMgc29tZXRoaW5nIGRp ZmZlcmVudC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz cDsgJm5ic3A7VGhlIGZhY3QgdGhhdCBhbGwgbWFuZGF0b3J5DQpwcmVjb25kaXRpb25zIGZvciB0 aGUgc3RyZWFtIGFyZSBtZXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbmJzcDsgJm5ic3A7aW5kaWNhdGVzIHRoYXQgdGhlIG5ldw0KcGFyYW1ldGVycyBmb3Ig dGhlIG1lZGlhIHN0cmVhbSBhcmUgcmVhZHkgdG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7YmUgdXNlZC4gJm5ic3A7SG93ZXZlciwNCnRo ZXkgd2lsbCBub3QgYWN0dWFsbHkgYmUgdXNlZCB1bnRpbCB0aGUgVUFTPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO2RlY2lkZXMgc28uICZu YnNwO0R1cmluZw0KYSBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIHRoZSBVQVMgY2FuIHdhaXQgYmVm b3JlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZu YnNwO3VzaW5nIHRoZSBtZWRpYSBwYXJhbWV0ZXJzDQp1bnRpbCB0aGUgY2FsbGVlIHN0YXJ0cyBi ZWluZyBhbGVydGVkIG9yPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7ICZuYnNwO3VudGlsIHRoZSBjYWxsZWUgYWNjZXB0cw0KdGhlIHNlc3Npb24uICZu YnNwO0R1cmluZyBhIHNlc3Npb24gbW9kaWZpY2F0aW9uLDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDt0aGUgVUFTIGNhbiB3YWl0IHVudGls DQppdHMgdXNlciBhY2NlcHRzIHRoZSBjaGFuZ2VzIHRvIHRoZSBzZXNzaW9uLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QnkgbXlzZWxmLCB0aGlzIHBh cnQgaXMgY2xhcmlmaWNhdGlvbg0Kb2YgMzMxMiBmb3IgbW9kaWZpY2F0aW9uIHdpdGggcHJlY29u ZGl0b24sIHdoaWxlIG5vdCBjb3JyZWN0aW9uLiBXb3VsZA0Kc3VjaCBkZWdyZWUgYWxzbyBuZWVk IHRvIGJlIHRyZWF0ZWQgYXMgVVBEQVRFIG9mIFJGQ3h4eD8gSSBhbSBub3Qgc3VyZSwNCmFuZCB3 b3VsZCBsaWtlIHRvIGhlYXIgc2Vhc29uZWQgcGVyc29uJ3MgcG9pbnQoc3VjaCBhcyBQYXVsIGFu ZCBHb256YWxvKS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJz cDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJz cDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5j bjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkJyZXR0IFRhdGUgJmx0O2Jy ZXR0QGJyb2Fkc29mdC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjIwMTAtMDUtMjQgMjM6MDI8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7c2lwY29yZUBpZXRmLm9yZyZxdW90 OyAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDssDQomcXVvdDtDaHJpc3Rlci5Ib2xtYmVyZ0Blcmlj c3Nvbi5jb20mcXVvdDsgJmx0O0NocmlzdGVyLkhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDssDQom cXVvdDtHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20mcXVvdDsgJmx0O0dvbnphbG8uQ2Ft YXJpbGxvQGVyaWNzc29uLmNvbSZndDssDQomcXVvdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZxdW90 OyAmbHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvN PC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5kcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZp dGUtMDQ6IGltcGFjdHMNCnVwb24gUkVGRVIgYW5kIE5PVElGWTwvZm9udD48L3RhYmxlPg0KPGJy Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+U2luY2UgaW4tZGlhbG9nIFJF RkVSIGFuZCBOT1RJRlkgYXJlIHRhcmdldCByZWZyZXNoDQpyZXF1ZXN0cywgd2hhdCBhcmUgdGhl IGltcGFjdHMgb2Ygc2VjdGlvbiA0LjUgJnF1b3Q7UmFjZSBDb25kaXRpb25zIGFuZA0KVGFyZ2V0 IFJlZnJlc2hlcyZxdW90OyB1cG9uIFJFRkVSIGFuZCBOT1RJRlk/PGJyPg0KPGJyPg0KSXQgZG9l c24ndCBsb29rIGxpa2UgdGhlcmUgYXJlIGFueSBub3JtYXRpdmUgaW1wYWN0cy4gJm5ic3A7SG93 ZXZlciBJIHdhc24ndA0Kc3VyZSBpZiB0aGlzIHdhcyBpbnRlbnRpb25hbC48YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KQnJldHQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxi cj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtO b3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZu YnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5i c3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0 ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJz cDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZu YnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVz Jm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRl bnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3Ro ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7 ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3Nl ZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJz cDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0Fu eSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nh bm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJz cDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00265D314825772E_=-- From shinji.okumura@softfront.jp Tue May 25 01:32:07 2010 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 3EB5D3A6AC3 for ; Tue, 25 May 2010 01:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.889 X-Spam-Level: X-Spam-Status: No, score=-94.889 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_62=0.6, RELAY_IS_221=2.222, 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 OqpX4WwrHvZ3 for ; Tue, 25 May 2010 01:32:06 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 0D20E3A6917 for ; Tue, 25 May 2010 01:32:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id DD8E8428012; Tue, 25 May 2010 17:31:55 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWhAcVAIVoIK; Tue, 25 May 2010 17:31:52 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 4198B42800C; Tue, 25 May 2010 17:31:51 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Tue, 25 May 2010 17:31:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare andUPDATEwithout SDP 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, 25 May 2010 08:32:07 -0000 Gao, gao.yang2@zte.com.cn Tue, 25 May 2010 14:15:10 +0800 >Hi, > >> >> I agree that it doesn't forbid sending it. It allows it and >> >> mandates the UAS return 491 or 500 (depending upon direction). >> > >> >It mandates the UAS send 4xx/5xx to UPDATE only when the UAS >> >send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before >> >ACK of 4xx/5xx(Re-INVITE). >> >> As you know, ACK to non-2xx is hop-by-hop. >> There is little benefit to reject such an UPDATE. > >UAS send 491 for the UPDATE(in the flow) to *tell* UAC that in it's(UAS) >view, there's a glare case. But this UPDATE is sent in order to synchronize the common view. If UAS return 2xx, then the situation goes into nonglare. Probably another UPDATE will be sent, but this UPDATE transaction is supposed to be avoided. At the very start, the UAS rejects a reINVITE does not care about this text. Is it necessary to let such a UAS follow a new rule? >When UAS get the ACK then UPDATE, it still has no precise criterion for >whether the UAC gets non-2xx(Re-INVITE) first then send the UPDATE or not. >Keeping rejecting the UPDATE is not a reasonable way here. So, the draft >suggest the way, as UAS can send 2xx to the UPDATE. It is a conventional handling and enough for UAS. >When UAC get UAS's 4xx of UPDATE, the session state is clear for it. And >UAC would only send a synchronizing Re-INVITE/UPDATE when it is a glare >case in the UAC's view. UAS' behavior does not affect UAC' behavior directly. UAC will do the needful regardless of whether UAS rejects a reINVITE. >IMO, this way is better than the way we might once use: allowing B send >2xx to UPDATE, and both A and B *see* glare, and all send Re-INVITE/UPDATE >to refresh session state by each's view. The new rule for UAS does not seem to improve the situation. The new rule for UAC seems to be just enough to synchronize the view. Regards, Shinji >Thanks, > >Gao > >> >> A B >> | | >> s0|re-INV (offer1) |s0 >> |------------------------------>| >> | 18x(answer1)| >> |<------------------------------| >> s1| non-2xx|s1 >> |<------------------------------|<-+ >> s0|ACK |s0| >> |-----------> | | >> |UPD(offer0) | | >> |==============================>|* | reject UPDATE >> | 491(UPD)| | >> |<==============================| | >> | ACK | | >> | ---------->|<-+ >> | | >> Figure 2 >> >> A B >> | | >> s0|re-INV (offer1) |s0 >> |------------------------------>| >> | 18x(answer1)| >> |<------------------------------| >> s1| non-2xx|s1 >> | /-------------|<-+ >> | / ACK |s0| reject UPDATE >> | / ---------->|<-+ >> |UPD(offer2) / | >> |=============/================>| >> | / 200(UPD)| >> |<==========/===================| >> s2| / |s2 >> |<--------/ | >> s0|ACK | >> |-----------> | >> | | >> Figure 3 >> >> I've also been pointed out by Ian Elz. >> >> Regards, >> Shinji >> >> >If UAS send 2xx to Re-INVITE, the UAS would not send 4xx/5xx >> >to the UPDATE. >> > >> >And if the UAS get the ACK(Re-INVITE's 4xx/5xx) firstly, the >> >UAS also would not mandate to the rules. From john.elwell@siemens-enterprise.com Tue May 25 01:34:02 2010 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 DCF6F3A6D99 for ; Tue, 25 May 2010 01:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-0.842, 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 kg5blfcytRm2 for ; Tue, 25 May 2010 01:34:01 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 857ED3A6839 for ; Tue, 25 May 2010 01:34:01 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-276055; Tue, 25 May 2010 10:33:52 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A9C1B1EB82AE; Tue, 25 May 2010 10:33:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 25 May 2010 10:33:52 +0200 From: "Elwell, John" To: Christer Holmberg , SIPCORE Date: Tue, 25 May 2010 10:33:51 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGw 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 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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, 25 May 2010 08:34:02 -0000 Christer, Thanks, this addresses concerns I had with the previous version. Digging deeper into the issue with the Flow-Timer header field, I view it t= his way. The "keep" parameter is in the Via header field, which has one ent= ry per hop over which the request passes. Therefore the "keep" parameter is= clearly associated with a given hop. However, the Flow-Timer header field = does not have the concept of one entry per hop. Therefore the header field = is assumed to apply only to the current hop, and has to be removed before f= orwarding a response over a hop on which keep-alive has not been requested,= or needs to have its value modified before forwarding a response over a ho= p on which keep-alive has been requested. It seems odd that the two pieces = of information used by this feature should be handled in two completely dif= ferent ways. Another difference is that when a proxy receives a "keep" parameter in the = topmost Via header field entry, it adds "yes" as the value of that paramete= r when forwarding that Via header entry (which will no longer be the topmos= t entry and therefore will not be inspected by the next entity). Therefore = when the Via header field is returned in the response, it will already have= the "yes" value in place when it crosses the hop to which the entry applie= s. Therefore the proxy does not need to take special action concerning the = Via header field when forwarding the response. In contrast, a proxy has to = take special action with the Flow-Timer header field when forwarding a resp= onse, as described above. The way "keep" is handled seems to take account o= f transaction-stateless proxies, whereas the way Flow-Timer is handle does = not. I am not sure, however, whether this mechanism makes sense for use wit= h transaction-stateless proxies anyway, so perhaps this latter point is moo= t. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 24 May 2010 17:56 > To: SIPCORE > Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 >=20 > Hi, >=20 > I've submitted a new version of the keep draft. >=20 > Based on feedback and comments, I've moved back to the=20 > original Via parameter based solution. >=20 > I've done a number of editorial changes in order to make the=20 > draft more clear. >=20 > The currently only OPEN ISSUE is whether we should use the=20 > Flow-Timer header field, defined in Outbound, to indicate the=20 > keep-alive frequency, or whether the frequency should be=20 > added directly to the Via parameter as a parameter value=20 > (instead of adding a "yes" value). >=20 > Using Flow-Timer is alligned with Outbound, while using a=20 > keep parameter value is more "compact". >=20 > Flow-Timer example: 'Flow-Timer: 30' >=20 > Via keep parameter example: Via:11.22.33.44;keep=3D30 >=20 > The keep-draft allows usage of the Flow-Timer header field=20 > also in initial requests for dialogs, and mid-dialog target=20 > refresh requests, but I did not find any text in the Outbound=20 > spec which would restrict the usage of the header field to=20 > REGISTER requests only. >=20 > Once we've agreed on how to move forward with the keep-alive=20 > frequency issue I believe the draft is ready for WGLC. >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue May 25 02:36:27 2010 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 02B263A6AEA for ; Tue, 25 May 2010 02:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=-0.602, 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 jMKCHNMeUBKp for ; Tue, 25 May 2010 02:36:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8AAC63A69D3 for ; Tue, 25 May 2010 02:36:22 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-fd-4bfb9a0ca443 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DD.37.21861.C0A9BFB4; Tue, 25 May 2010 11:36:12 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 25 May 2010 11:36:12 +0200 From: Christer Holmberg To: "Elwell, John" , SIPCORE Date: Tue, 25 May 2010 11:36:11 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGwgAATqNk= 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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, 25 May 2010 09:36:27 -0000 Hi John, >Digging deeper into the issue with the Flow-Timer header field, I view it = this way. The "keep" parameter is in the Via header field, which has one en= try per hop over which the request passes. Therefore the "keep" parameter i= s clearly associated with a given hop. However,=20 >the Flow-Timer header field does not have the concept of one entry per hop= . Therefore the header field is assumed to apply only to the current hop, a= nd has to be removed before forwarding a response over a hop on which keep-= alive has not been requested, or needs to=20 >have its value modified before forwarding a response over a hop on which k= eep-alive has been requested.=20 True.=20 Of course, in Outbound that is not a problem, since Flow-Timer is only used= on one hop (between the UA and its edge proxy). >It seems odd that the two pieces of information used by this feature shoul= d be handled in two completely different ways. > >Another difference is that when a proxy receives a "keep" parameter in the= topmost Via header field entry, it adds "yes" as the value of that paramet= er when forwarding that Via header entry (which will no longer be the topmo= st entry and therefore will not be inspected by=20 >the next entity). Therefore when the Via header field is returned in the r= esponse, it will already have the "yes" value in place when it crosses the = hop to which the entry applies. Therefore the proxy does not need to take s= pecial action concerning the Via header field when=20 >forwarding the response. In contrast, a proxy has to take special action w= ith the Flow-Timer header field when forwarding a response, as described ab= ove. The way "keep" is handled seems to take account of transaction-statele= ss proxies, whereas the way Flow-Timer is=20 >handle does not. I am not sure, however, whether this mechanism makes sens= e for use with transaction-stateless proxies anyway, so perhaps this latter= point is moot. I think that proxies do need to be stateful - at least if they intend to se= nd keep-alives within a dialog (I doubt a proxy would negotiate sending of = proxies within a registration, since proxies are normally registration un-a= ware). Because, the proxy needs to know when the dialog is terminated, in o= rder to stop sending the keep-alives. Also, a proxy that receives keep-alives also needs to be stateful in case i= t intends to perform some actions in case negotiated keep-alives aren't rec= eived within a dialog. The draft (nor Outbound, afaik) defines what a proxy= does in those cases, because it is seen as an implementation issue. As said earlier, the reason for using Flow-Timer in the draft is because Ou= tbound already uses it, and the purpose of the keep-draft is to not change = the Outbound keep-alive mechanism as such, but rather define a mechanism to= explicitly negotiate usage of it. But, personally I have no strong preference for which solution we use. Howe= ver, IF we choose to indicate the frequency as a keep parameter value, I th= ink we should add some text to the draft explaining why Flow-Timer is not u= sed. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 24 May 2010 17:56 > To: SIPCORE > Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 > > Hi, > > I've submitted a new version of the keep draft. > > Based on feedback and comments, I've moved back to the > original Via parameter based solution. > > I've done a number of editorial changes in order to make the > draft more clear. > > The currently only OPEN ISSUE is whether we should use the > Flow-Timer header field, defined in Outbound, to indicate the > keep-alive frequency, or whether the frequency should be > added directly to the Via parameter as a parameter value > (instead of adding a "yes" value). > > Using Flow-Timer is alligned with Outbound, while using a > keep parameter value is more "compact". > > Flow-Timer example: 'Flow-Timer: 30' > > Via keep parameter example: Via:11.22.33.44;keep=3D30 > > The keep-draft allows usage of the Flow-Timer header field > also in initial requests for dialogs, and mid-dialog target > refresh requests, but I did not find any text in the Outbound > spec which would restrict the usage of the header field to > REGISTER requests only. > > Once we've agreed on how to move forward with the keep-alive > frequency issue I believe the draft is ready for WGLC. > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >= From gao.yang2@zte.com.cn Tue May 25 03:23:14 2010 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 547AA3A70D1 for ; Tue, 25 May 2010 03:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=-1.527, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 t8Eosm9oLaOi for ; Tue, 25 May 2010 03:23:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 2E4903A70D7 for ; Tue, 25 May 2010 03:22:51 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Tue, 25 May 2010 18:16:12 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3015714703; Tue, 25 May 2010 16:56:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4P8tv3m064827; Tue, 25 May 2010 16:56:01 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 25 May 2010 16:53:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-25 16:55:44, Serialize complete at 2010-05-25 16:55:44 Content-Type: multipart/alternative; boundary="=_alternative 003104604825772E_=" X-MAIL: mse2.zte.com.cn o4P8tv3m064827 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare andUPDATEwithout SDP 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, 25 May 2010 10:23:14 -0000 This is a multipart message in MIME format. --=_alternative 003104604825772E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCk9LVU1VUkEgU2hpbmppIDxzaGluamkub2t1bXVyYUBzb2Z0ZnJvbnQuanA+INC009og MjAxMC0wNS0yNSAxNjozMTo0OToNCg0KPiBHYW8sDQo+IA0KPiBnYW8ueWFuZzJAenRlLmNvbS5j bg0KPiBUdWUsIDI1IE1heSAyMDEwIDE0OjE1OjEwICswODAwDQo+ID5IaSwNCj4gPg0KPiA+PiA+ PiBJIGFncmVlIHRoYXQgaXQgZG9lc24ndCBmb3JiaWQgc2VuZGluZyBpdC4gIEl0IGFsbG93cyBp dCBhbmQgDQo+ID4+ID4+IG1hbmRhdGVzIHRoZSBVQVMgcmV0dXJuIDQ5MSBvciA1MDAgKGRlcGVu ZGluZyB1cG9uIGRpcmVjdGlvbikuDQo+ID4+ID4NCj4gPj4gPkl0IG1hbmRhdGVzIHRoZSBVQVMg c2VuZCA0eHgvNXh4IHRvIFVQREFURSBvbmx5IHdoZW4gdGhlIFVBUw0KPiA+PiA+c2VuZCA0eHgv NXh4IHRvIHRoZSBSZS1JTlZJVEUgYW5kIHRoZSBVQVMgZ2V0IHRoZSBVUERBVEUgYmVmb3JlDQo+ ID4+ID5BQ0sgb2YgNHh4LzV4eChSZS1JTlZJVEUpLg0KPiA+PiANCj4gPj4gQXMgeW91IGtub3cs IEFDSyB0byBub24tMnh4IGlzIGhvcC1ieS1ob3AuDQo+ID4+IFRoZXJlIGlzIGxpdHRsZSBiZW5l Zml0IHRvIHJlamVjdCBzdWNoIGFuIFVQREFURS4NCj4gPg0KPiA+VUFTIHNlbmQgNDkxIGZvciB0 aGUgVVBEQVRFKGluIHRoZSBmbG93KSB0byAqdGVsbCogVUFDIHRoYXQgaW4gDQppdCdzKFVBUykg DQo+ID52aWV3LCB0aGVyZSdzIGEgZ2xhcmUgY2FzZS4NCj4gDQo+IEJ1dCB0aGlzIFVQREFURSBp cyBzZW50IGluIG9yZGVyIHRvIHN5bmNocm9uaXplIHRoZSBjb21tb24gdmlldy4NCj4gSWYgVUFT IHJldHVybiAyeHgsIHRoZW4gdGhlIHNpdHVhdGlvbiBnb2VzIGludG8gbm9uZ2xhcmUuDQoNCkkg Z3Vlc3MgSSBoYXZlIGEgaW52ZXJzZSBwb2ludCBoZXJlLiBCeSB0aGlzIGRyYWZ0J3MgY2xhcmlm aWNhdGlvbiwgDQp0aGVyZSdzIG5vIGluY29uc2lzdGVudCBzZXNzaW9uIHN0YXRlIGZvciB0aGUg bm9uLXN1Y2Nlc3NmdWwgUmUtSU5WSVRFLiANClNvLCB3aHkgVUFDIHNlbmQgYSBVUERBVEUgdG8g c3luY2hyb25pemUgdGhlIGNvbW1vbiB2aWV3Pw0KDQpXaGlsZSBpZiBVQVMgcmV0dXJuIDJ4eChm b3IgdGhlIFVQREFURSksIHRoZSBzaXR1YXRpb24gd291bGQgZ2V0IGludG8gDQpnbGFyZShVQVMg aGFzIG5vIHdheSB0byBmaWd1cmUgb3V0IHRoaXMgVVBEQVRFIGlzIGluLXNjb3BlIG9mIFJlLUlO VklURSBvciANCm5vdCkuIFRoaXMgaXMgcmVsYXRpbmcgdG8gYXRvbWljIG9mIHNlc3Npb24gc3Rh dGUuIEknZCBsaWtlIHRvIGVtcGhhc2l6ZSANCnRoYXQga2VlcGluZyBSZS1JTlZJVEUgYXRvbWlj LCBleGNlcHQgZm9yIHRhcmdldCByZWZyZXNoLCBpcyB0aGUgbWFpbiBpZGVhIA0KaW4gdGhpcyBk cmFmdC4NCg0KPiBQcm9iYWJseSBhbm90aGVyIFVQREFURSB3aWxsIGJlIHNlbnQsIGJ1dCB0aGlz IFVQREFURQ0KPiB0cmFuc2FjdGlvbiBpcyBzdXBwb3NlZCB0byBiZSBhdm9pZGVkLg0KPiANCj4g QXQgdGhlIHZlcnkgc3RhcnQsIHRoZSBVQVMgcmVqZWN0cyBhIHJlSU5WSVRFIGRvZXMgbm90IGNh cmUNCj4gYWJvdXQgdGhpcyB0ZXh0LiBJcyBpdCBuZWNlc3NhcnkgdG8gbGV0IHN1Y2ggYSBVQVMg Zm9sbG93IGENCj4gbmV3IHJ1bGU/DQoNClRoZXNlIGRheXMsIHlvdSBndXlzIHNob3dlZCBhIGxv dCBvZiB1c2UgY2FzZXMuIEkgZG9uJ3QgcmVtZW1iZXIgdGhlIA0KZGV0YWlscy4gQ291bGQgeW91 IHNheSBtb3JlIGFib3V0IHRoaXMgdXNlIGNhc2UuDQoNCj4gDQo+ID5XaGVuIFVBUyBnZXQgdGhl IEFDSyB0aGVuIFVQREFURSwgaXQgc3RpbGwgaGFzIG5vIHByZWNpc2UgY3JpdGVyaW9uIGZvciAN Cg0KPiA+d2hldGhlciB0aGUgVUFDIGdldHMgbm9uLTJ4eChSZS1JTlZJVEUpIGZpcnN0IHRoZW4g c2VuZCB0aGUgVVBEQVRFIG9yIA0Kbm90LiANCj4gPktlZXBpbmcgcmVqZWN0aW5nIHRoZSBVUERB VEUgaXMgbm90IGEgcmVhc29uYWJsZSB3YXkgaGVyZS4gU28sIHRoZSANCmRyYWZ0IA0KPiA+c3Vn Z2VzdCB0aGUgd2F5LCBhcyBVQVMgY2FuIHNlbmQgMnh4IHRvIHRoZSBVUERBVEUuDQo+IA0KPiBJ dCBpcyBhIGNvbnZlbnRpb25hbCBoYW5kbGluZyBhbmQgZW5vdWdoIGZvciBVQVMuDQo+IA0KPiA+ V2hlbiBVQUMgZ2V0IFVBUydzIDR4eCBvZiBVUERBVEUsIHRoZSBzZXNzaW9uIHN0YXRlIGlzIGNs ZWFyIGZvciBpdC4gDQpBbmQgDQo+ID5VQUMgd291bGQgb25seSBzZW5kIGEgc3luY2hyb25pemlu ZyBSZS1JTlZJVEUvVVBEQVRFIHdoZW4gaXQgaXMgYSBnbGFyZSANCg0KPiA+Y2FzZSBpbiB0aGUg VUFDJ3Mgdmlldy4NCj4gDQo+IFVBUycgYmVoYXZpb3IgZG9lcyBub3QgYWZmZWN0IFVBQycgYmVo YXZpb3IgZGlyZWN0bHkuDQo+IFVBQyB3aWxsIGRvIHRoZSBuZWVkZnVsIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBVQVMgcmVqZWN0cw0KPiBhIHJlSU5WSVRFLg0KPiANCj4gPklNTywgdGhpcyB3YXkg aXMgYmV0dGVyIHRoYW4gdGhlIHdheSB3ZSBtaWdodCBvbmNlIHVzZTogYWxsb3dpbmcgQiBzZW5k IA0KDQo+ID4yeHggdG8gVVBEQVRFLCBhbmQgYm90aCBBIGFuZCBCICpzZWUqIGdsYXJlLCBhbmQg YWxsIHNlbmQgDQpSZS1JTlZJVEUvVVBEQVRFIA0KPiA+dG8gcmVmcmVzaCBzZXNzaW9uIHN0YXRl IGJ5IGVhY2gncyB2aWV3Lg0KPiANCj4gVGhlIG5ldyBydWxlIGZvciBVQVMgZG9lcyBub3Qgc2Vl bSB0byBpbXByb3ZlIHRoZSBzaXR1YXRpb24uDQo+IFRoZSBuZXcgcnVsZSBmb3IgVUFDIHNlZW1z IHRvIGJlIGp1c3QgZW5vdWdoIHRvIHN5bmNocm9uaXplDQo+IHRoZSB2aWV3Lg0KDQpUaGUga2V5 IG1lcml0IGZvciB0aGUgbmV3IHJ1bGUgaXMgbWFrZSBib3RoIFVBQyBhbmQgVUFTIGNsZWFyIGlu IHdoaWNoIA0Kc2l0dWF0aW9uIGlzIGl0J3MgcmVzcG9uc2liaWxpdHkgdG8gaGFuZGxlIGdsYXJl IGNhc2UsIGFuZCB0aGVyZSdzIG9ubHkgDQpvbmUgVUEgbmVlZCB0byBkbyBzb21ldGhpbmcuIEJv dGggc2lkZXMgd2FudCB0byByZWZyZXNoIHNlc3Npb24gc3RhdGUgYnkgDQplYWNoJ3MgdmlldyBp cyBub3QgYSBlbGVnYW50IHdheS4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 003104604825772E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPk9LVU1VUkEgU2hpbmppICZsdDtzaGluamkub2t1bXVyYUBzb2Z0 ZnJvbnQuanAmZ3Q7DQrQtNPaIDIwMTAtMDUtMjUgMTY6MzE6NDk6PGJyPg0KPGJyPg0KJmd0OyBH YW8sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0OyBU dWUsIDI1IE1heSAyMDEwIDE0OjE1OjEwICswODAwPGJyPg0KJmd0OyAmZ3Q7SGksPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGFncmVlIHRoYXQgaXQgZG9lc24n dCBmb3JiaWQgc2VuZGluZyBpdC4gJm5ic3A7SXQNCmFsbG93cyBpdCBhbmQgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBtYW5kYXRlcyB0aGUgVUFTIHJldHVybiA0OTEgb3IgNTAwIChkZXBl bmRpbmcgdXBvbg0KZGlyZWN0aW9uKS48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7ICZndDtJdCBtYW5kYXRlcyB0aGUgVUFTIHNlbmQgNHh4LzV4eCB0byBVUERBVEUg b25seSB3aGVuDQp0aGUgVUFTPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2VuZCA0eHgvNXh4IHRv IHRoZSBSZS1JTlZJVEUgYW5kIHRoZSBVQVMgZ2V0IHRoZSBVUERBVEUNCmJlZm9yZTxicj4NCiZn dDsgJmd0OyZndDsgJmd0O0FDSyBvZiA0eHgvNXh4KFJlLUlOVklURSkuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IEFzIHlvdSBrbm93LCBBQ0sgdG8gbm9uLTJ4eCBpcyBo b3AtYnktaG9wLjxicj4NCiZndDsgJmd0OyZndDsgVGhlcmUgaXMgbGl0dGxlIGJlbmVmaXQgdG8g cmVqZWN0IHN1Y2ggYW4gVVBEQVRFLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O1VBUyBz ZW5kIDQ5MSBmb3IgdGhlIFVQREFURShpbiB0aGUgZmxvdykgdG8gKnRlbGwqIFVBQyB0aGF0IGlu DQppdCdzKFVBUykgPGJyPg0KJmd0OyAmZ3Q7dmlldywgdGhlcmUncyBhIGdsYXJlIGNhc2UuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEJ1dCB0aGlzIFVQREFURSBpcyBzZW50IGluIG9yZGVyIHRvIHN5 bmNocm9uaXplIHRoZSBjb21tb24gdmlldy48YnI+DQomZ3Q7IElmIFVBUyByZXR1cm4gMnh4LCB0 aGVuIHRoZSBzaXR1YXRpb24gZ29lcyBpbnRvIG5vbmdsYXJlLjwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+SSBndWVzcyBJIGhhdmUgYSBpbnZlcnNlIHBvaW50IGhlcmUu IEJ5IHRoaXMgZHJhZnQncw0KY2xhcmlmaWNhdGlvbiwgdGhlcmUncyBubyBpbmNvbnNpc3RlbnQg c2Vzc2lvbiBzdGF0ZSBmb3IgdGhlIG5vbi1zdWNjZXNzZnVsDQpSZS1JTlZJVEUuIFNvLCB3aHkg VUFDIHNlbmQgYSBVUERBVEUgdG8gc3luY2hyb25pemUgdGhlIGNvbW1vbiB2aWV3PzwvZm9udD48 L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+V2hpbGUgaWYgVUFTIHJldHVybiAyeHgo Zm9yIHRoZSBVUERBVEUpLCB0aGUgc2l0dWF0aW9uDQp3b3VsZCBnZXQgaW50byBnbGFyZShVQVMg aGFzIG5vIHdheSB0byBmaWd1cmUgb3V0IHRoaXMgVVBEQVRFIGlzIGluLXNjb3BlDQpvZiBSZS1J TlZJVEUgb3Igbm90KS4gVGhpcyBpcyByZWxhdGluZyB0byBhdG9taWMgb2Ygc2Vzc2lvbiBzdGF0 ZS4gSSdkDQpsaWtlIHRvIGVtcGhhc2l6ZSB0aGF0IGtlZXBpbmcgUmUtSU5WSVRFIGF0b21pYywg ZXhjZXB0IGZvciB0YXJnZXQgcmVmcmVzaCwNCmlzIHRoZSBtYWluIGlkZWEgaW4gdGhpcyBkcmFm dC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgUHJvYmFibHkg YW5vdGhlciBVUERBVEUgd2lsbCBiZSBzZW50LCBidXQgdGhpcyBVUERBVEU8YnI+DQomZ3Q7IHRy YW5zYWN0aW9uIGlzIHN1cHBvc2VkIHRvIGJlIGF2b2lkZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEF0IHRoZSB2ZXJ5IHN0YXJ0LCB0aGUgVUFTIHJlamVjdHMgYSByZUlOVklURSBkb2VzIG5vdCBj YXJlPGJyPg0KJmd0OyBhYm91dCB0aGlzIHRleHQuIElzIGl0IG5lY2Vzc2FyeSB0byBsZXQgc3Vj aCBhIFVBUyBmb2xsb3cgYTxicj4NCiZndDsgbmV3IHJ1bGU/PC9mb250PjwvdHQ+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5UaGVzZSBkYXlzLCB5b3UgZ3V5cyBzaG93ZWQgYSBsb3Qgb2Yg dXNlIGNhc2VzLiBJDQpkb24ndCByZW1lbWJlciB0aGUgZGV0YWlscy4gQ291bGQgeW91IHNheSBt b3JlIGFib3V0IHRoaXMgdXNlIGNhc2UuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0O1doZW4gVUFTIGdldCB0aGUgQUNLIHRoZW4gVVBE QVRFLCBpdCBzdGlsbCBoYXMgbm8gcHJlY2lzZSBjcml0ZXJpb24NCmZvciA8YnI+DQomZ3Q7ICZn dDt3aGV0aGVyIHRoZSBVQUMgZ2V0cyBub24tMnh4KFJlLUlOVklURSkgZmlyc3QgdGhlbiBzZW5k IHRoZSBVUERBVEUNCm9yIG5vdC4gPGJyPg0KJmd0OyAmZ3Q7S2VlcGluZyByZWplY3RpbmcgdGhl IFVQREFURSBpcyBub3QgYSByZWFzb25hYmxlIHdheSBoZXJlLiBTbywNCnRoZSBkcmFmdCA8YnI+ DQomZ3Q7ICZndDtzdWdnZXN0IHRoZSB3YXksIGFzIFVBUyBjYW4gc2VuZCAyeHggdG8gdGhlIFVQ REFURS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQgaXMgYSBjb252ZW50aW9uYWwgaGFuZGxpbmcg YW5kIGVub3VnaCBmb3IgVUFTLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7V2hlbiBVQUMgZ2V0 IFVBUydzIDR4eCBvZiBVUERBVEUsIHRoZSBzZXNzaW9uIHN0YXRlIGlzIGNsZWFyIGZvcg0KaXQu IEFuZCA8YnI+DQomZ3Q7ICZndDtVQUMgd291bGQgb25seSBzZW5kIGEgc3luY2hyb25pemluZyBS ZS1JTlZJVEUvVVBEQVRFIHdoZW4gaXQgaXMNCmEgZ2xhcmUgPGJyPg0KJmd0OyAmZ3Q7Y2FzZSBp biB0aGUgVUFDJ3Mgdmlldy48YnI+DQomZ3Q7IDxicj4NCiZndDsgVUFTJyBiZWhhdmlvciBkb2Vz IG5vdCBhZmZlY3QgVUFDJyBiZWhhdmlvciBkaXJlY3RseS48YnI+DQomZ3Q7IFVBQyB3aWxsIGRv IHRoZSBuZWVkZnVsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBVQVMgcmVqZWN0czxicj4NCiZndDsg YSByZUlOVklURS48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0O0lNTywgdGhpcyB3YXkgaXMgYmV0 dGVyIHRoYW4gdGhlIHdheSB3ZSBtaWdodCBvbmNlIHVzZTogYWxsb3dpbmcNCkIgc2VuZCA8YnI+ DQomZ3Q7ICZndDsyeHggdG8gVVBEQVRFLCBhbmQgYm90aCBBIGFuZCBCICpzZWUqIGdsYXJlLCBh bmQgYWxsIHNlbmQgUmUtSU5WSVRFL1VQREFURQ0KPGJyPg0KJmd0OyAmZ3Q7dG8gcmVmcmVzaCBz ZXNzaW9uIHN0YXRlIGJ5IGVhY2gncyB2aWV3Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgbmV3 IHJ1bGUgZm9yIFVBUyBkb2VzIG5vdCBzZWVtIHRvIGltcHJvdmUgdGhlIHNpdHVhdGlvbi48YnI+ DQomZ3Q7IFRoZSBuZXcgcnVsZSBmb3IgVUFDIHNlZW1zIHRvIGJlIGp1c3QgZW5vdWdoIHRvIHN5 bmNocm9uaXplPGJyPg0KJmd0OyB0aGUgdmlldy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPlRoZSBrZXkgbWVyaXQgZm9yIHRoZSBuZXcgcnVsZSBpcyBtYWtlIGJvdGgg VUFDIGFuZA0KVUFTIGNsZWFyIGluIHdoaWNoIHNpdHVhdGlvbiBpcyBpdCdzIHJlc3BvbnNpYmls aXR5IHRvIGhhbmRsZSBnbGFyZSBjYXNlLA0KYW5kIHRoZXJlJ3Mgb25seSBvbmUgVUEgbmVlZCB0 byBkbyBzb21ldGhpbmcuIEJvdGggc2lkZXMgd2FudCB0byByZWZyZXNoDQpzZXNzaW9uIHN0YXRl IGJ5IGVhY2gncyB2aWV3IGlzIG5vdCBhIGVsZWdhbnQgd2F5LjwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+VGhhbmtzLDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+R2FvPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 003104604825772E_=-- From brett@broadsoft.com Tue May 25 04:39:13 2010 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 661C83A6B8B for ; Tue, 25 May 2010 04:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[AWL=-0.917, 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 v8ysu59JKQdH for ; Tue, 25 May 2010 04:39:12 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 3FB613A6B85 for ; Tue, 25 May 2010 04:39:12 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 25 May 2010 04:39:03 -0700 From: Brett Tate To: OKUMURA Shinji , "sipcore@ietf.org" Date: Tue, 25 May 2010 04:37:59 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr7uWnjYujDlOndTAG2q2dVT6w8TAAQSKlQ Message-ID: <747A6506A991724FB09B129B79D5FEB614816DC9BB@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DC31A@EXMBXCLUS01.citservers.local> <96CAFB3F808380shinji.okumura@softfront.jp> <747A6506A991724FB09B129B79D5FEB614816DC36C@EXMBXCLUS01.citservers.local> <16CAFBB964A024shinji.okumura@softfront.jp> In-Reply-To: <16CAFBB964A024shinji.okumura@softfront.jp> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 25 May 2010 11:39:13 -0000 Yes; there was a WGLC announcement. http://www.ietf.org/mail-archive/web/sipcore/current/msg01950.html=20 http://www.ietf.org/mail-archive/web/sipcore/current/msg02089.html=20 Even though I may not prefer the solution (as I understand it) mandated by = sections 3.5 are 4.5, I'm mainly just trying to understand it. Gao and I c= urrently don't agree upon how sections 3.5 and 4.5 impact UPDATE without SD= P on an early dialog. As Gao has requested, I hope the other authors and P= aul will reply. http://www.ietf.org/mail-archive/web/sipcore/current/msg02750.html=20 > -----Original Message----- > From: OKUMURA Shinji [mailto:shinji.okumura@softfront.jp] > Sent: Monday, May 24, 2010 11:22 PM > To: sipcore@ietf.org > Cc: Brett Tate > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE > without SDP >=20 > Brett, >=20 > Sorry for my lack of experience for publication of ID. > Was there an announcement about WGLC in this ML? >=20 > In any case, I do not deny a basic concept. > I agree that UAC generate new offer to synchronize. > But I doubt that UAs treat the final response to INVITE > and ACK as an offer/answer exchange. >=20 > Perhaps I think that my opinion is similar to yours. >=20 > Regards, > Shinji >=20 > Brett Tate > Mon, 24 May 2010 06:15:42 -0700 > >> What I make an issue is the validity of it. > >> I doubt whether the approach is appropriate. > > > >The draft has already passed WGLC. The current status is > >"Publication Requested". > > > >Thus I'm not sure how willing the authors and working group > >would be to alter the solution. However I'm not sure how many > >working group members noticed the impacts of section 3.5 and 4.5. > > > >It definitely encourages sending answer SDP within reliable 18x. > >Not doing so would block ability to use UPDATE on the early dialog. From shinji.okumura@softfront.jp Tue May 25 07:36:45 2010 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 3B3533A71D4 for ; Tue, 25 May 2010 07:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.236 X-Spam-Level: X-Spam-Status: No, score=-95.236 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_62=0.6, RELAY_IS_221=2.222, 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 Un4Hd1nW5HtD for ; Tue, 25 May 2010 07:36:44 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 2E2023A718F for ; Tue, 25 May 2010 07:32:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 03483428014; Tue, 25 May 2010 23:32:32 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsmEb7Y05CUT; Tue, 25 May 2010 23:32:28 +0900 (JST) Received: from softfront.jp (112.136.58.162.er.eaccess.ne.jp [112.136.58.162]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id AA111428013; Tue, 25 May 2010 23:32:27 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Tue, 25 May 2010 23:32:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: References: Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 25 May 2010 14:36:45 -0000 Gao, This is a figure I've assumed. A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| non-2xx|s1 |<------------------------------|<-+ s0|ACK |s0| |-----------> | | |UPD(offer0) | | |==============================>|* | reject UPDATE | 491(UPD)| | |<==============================| | | ACK | | | ---------->|<-+ | | Figure 2 >Hi, > >OKUMURA Shinji >> Gao, >> >> gao.yang2@zte.com.cn >> Tue, 25 May 2010 14:15:10 +0800 >> >Hi, >> > >> >> >> I agree that it doesn't forbid sending it. It allows it and >> >> >> mandates the UAS return 491 or 500 (depending upon direction). >> >> > >> >> >It mandates the UAS send 4xx/5xx to UPDATE only when the UAS >> >> >send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before >> >> >ACK of 4xx/5xx(Re-INVITE). >> >> >> >> As you know, ACK to non-2xx is hop-by-hop. >> >> There is little benefit to reject such an UPDATE. >> > >> >UAS send 491 for the UPDATE(in the flow) to *tell* UAC that in it's >> >(UAS) >> >view, there's a glare case. >> >> But this UPDATE is sent in order to synchronize the common view. >> If UAS return 2xx, then the situation goes into nonglare. > >I guess I have a inverse point here. By this draft's clarification, >there's no inconsistent session state for the non-successful Re-INVITE. >So, why UAC send a UPDATE to synchronize the common view? In 3.4. UAC Behavior, "In order to cope with these race condition situations, a UAC that receives an error response to a re-INVITE for which changes have been already executed SHOULD generate a new re- INVITE or UPDATE request in order to make sure that both UAs have a common view of the state of the dialog and the session." Under the above descriptions, this UAC generates a new UPDATE. >While if UAS return 2xx(for the UPDATE), the situation would get into >glare(UAS has no way to figure out this UPDATE is in-scope of Re-INVITE or >not). This is relating to atomic of session state. I'd like to emphasize >that keeping Re-INVITE atomic, except for target refresh, is the main idea >in this draft. This issue has nothing to do with the "atomic of session state". >> Probably another UPDATE will be sent, but this UPDATE >> transaction is supposed to be avoided. >> >> At the very start, the UAS rejects a reINVITE does not care >> about this text. Is it necessary to let such a UAS follow a >> new rule? > >These days, you guys showed a lot of use cases. I don't remember the >details. Could you say more about this use case. Please look at the original mail of mine, and re-comment it. You seem to be confused a little. >> >When UAS get the ACK then UPDATE, it still has no precise criterion for >> >whether the UAC gets non-2xx(Re-INVITE) first then send the UPDATE or not. >> >Keeping rejecting the UPDATE is not a reasonable way here. So, the draft >> >suggest the way, as UAS can send 2xx to the UPDATE. >> >> It is a conventional handling and enough for UAS. >> >> >When UAC get UAS's 4xx of UPDATE, the session state is clear for it. And >> >UAC would only send a synchronizing Re-INVITE/UPDATE when it is a glare >> >case in the UAC's view. >> >> UAS' behavior does not affect UAC' behavior directly. >> UAC will do the needful regardless of whether UAS rejects >> a reINVITE. >> >> >IMO, this way is better than the way we might once use: allowing B send >> >2xx to UPDATE, and both A and B *see* glare, and all send Re-INVITE/UPDATE >> >to refresh session state by each's view. >> >> The new rule for UAS does not seem to improve the situation. >> The new rule for UAC seems to be just enough to synchronize >> the view. > >The key merit for the new rule is make both UAC and UAS clear in which >situation is it's responsibility to handle glare case, and there's only >one UA need to do something. Both sides want to refresh session state by >each's view is not a elegant way. The crux of the matter is that a UAS can not recognize own glare situation anytime. It is UAC's duty to synchronize a common view. Regards, Shinji >Thanks, > >Gao From christer.holmberg@ericsson.com Tue May 25 11:51:18 2010 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 1C5853A69A0 for ; Tue, 25 May 2010 11:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=1.333, 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 w14J9T3cIn2q for ; Tue, 25 May 2010 11:51:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DF0CB3A67D7 for ; Tue, 25 May 2010 11:51:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-a2-4bfc1c1827d1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AE.E6.08537.81C1CFB4; Tue, 25 May 2010 20:51:04 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 25 May 2010 20:51:03 +0200 From: Christer Holmberg To: "'Elwell, John'" , Brett Tate , "sipcore@ietf.org" Date: Tue, 25 May 2010 20:51:03 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAA/3Eog Message-ID: References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 25 May 2010 18:51:18 -0000 Hi,=20 >Thanks for the clarification. So the changes do not prohibit the use of UP= DATE after only a non-reliable provisional response, provided the UPDATE re= quest does not contain an offer - correct? If it does contain an offer it i= s subject=20 >to the glare rules. Maybe I didn't understand, but what is the difference if you receive a reli= able or unreliable response (without SDP)? Regards, Christer > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 24 May 2010 12:55 > To: Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and=20 > UPDATE without SDP >=20 > > > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate that=20 > > > an UPDATE without SDP should be treated (from a glare > > > perspective) as though it contained an offer SDP. However I=20 > > > currently find the definition of "glare" and the expected behavior=20 > > > to be ambiguous. > > > > > > What is the precise meaning of glare? I ask mainly because some=20 > > > vendors send a 491 when an RFC indicates to send a 500. > > > > > > If INVITE contains offer SDP and 18x was not reliable, how SHOULD=20 > > > the called party respond if UPDATE without SDP is received from=20 > > > caller: 491, 500, or process as though no glare? > > > > > > If INVITE contains offer SDP and 18x was not reliable, how SHOULD=20 > > > the caller respond if UPDATE without SDP is received from called=20 > > > party: 491, 500, or process as though no glare? > > > > [JRE] I believe these two situations are both valid and should not=20 > > result in a 4xx/5xx/6xx response unless something else is wrong with=20 > > the request. >=20 > That was true before draft-ietf-sipcore-reinvite. However it looks=20 > like the following snippets make it no longer true. >=20 > Draft-ietf-sipcore-reinvite section 3.5: >=20 > "An UPDATE request without an offer can change dialog parameters. So =20 > can a non-2xx final response to a re-INVITE request or a 2xx response =20 > to an INVITE request (re-INVITE or initial INVITE). However, there =20 > are no rules to avoid a collision between an offerless UPDATE request =20 > and a final response to an INVITE request. The rules in Section 4.5, =20 > which are given in the context of target refreshes, cover these types =20 > of collisions as well. Therefore, there is no need to specify =20 > further rules here." >=20 > Draft-ietf-sipcore-reinvite section 4.5: >=20 > "When checking for glare situations, UAs MUST treat every UPDATE =20 > request as if it contained an offer." >=20 > RFC3311 section 5.2: >=20 > "If an UPDATE is received that contains an offer, and the UAS has =20 > generated an offer (in an UPDATE, PRACK or INVITE) to which it has =20 > not yet received an answer, the UAS MUST reject the UPDATE with a 491 =20 > response. Similarly, if an UPDATE is received that contains an =20 > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > INVITE) to which it has not yet generated an answer, the UAS MUST =20 > reject the UPDATE with a 500 response, and MUST include a Retry-After =20 > header field with a randomly chosen value between 0 and 10 seconds." >=20 >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Tue May 25 12:11:41 2010 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 663173A6781 for ; Tue, 25 May 2010 12:11: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 lrxr5y3h0jrl for ; Tue, 25 May 2010 12:11:40 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0E44A3A6980 for ; Tue, 25 May 2010 12:11:39 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-287094; Tue, 25 May 2010 21:11:30 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8A79723F0278; Tue, 25 May 2010 21:11:30 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 25 May 2010 21:11:30 +0200 From: "Elwell, John" To: Christer Holmberg , Brett Tate , "sipcore@ietf.org" Date: Tue, 25 May 2010 21:11:29 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAA/3EogAAByWSA= Message-ID: References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 25 May 2010 19:11:41 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 25 May 2010 19:51 > To: Elwell, John; Brett Tate; sipcore@ietf.org > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare=20 > and UPDATE without SDP >=20 >=20 > Hi,=20 >=20 > >Thanks for the clarification. So the changes do not prohibit=20 > the use of UPDATE after only a non-reliable provisional=20 > response, provided the UPDATE request does not contain an=20 > offer - correct? If it does contain an offer it is subject=20 > >to the glare rules. >=20 > Maybe I didn't understand, but what is the difference if you=20 > receive a reliable or unreliable response (without SDP)? [JRE] If only an unreliable provisional response has been received , an UPD= ATE is not allowed to contain SDP, so treating it as if it contained SDP is= rather odd. The following sequence: (re-)INVITE-----> <-----18x (unreliable) ----->UPDATE (no SDP) is valid in accordance with RFC 3311, I believe. What seems to be suggested= by the draft is that in some circumstances the UAS might treat the receive= d UPDATE as a glare. It is not clear to me under what conditions it might b= e treated as a glare, but in any case, that would seem to be a change to RF= C 3311 for those particular conditions. John >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Brett Tate [mailto:brett@broadsoft.com] > > Sent: 24 May 2010 12:55 > > To: Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and=20 > > UPDATE without SDP > >=20 > > > > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5=20 > indicate that=20 > > > > an UPDATE without SDP should be treated (from a glare > > > > perspective) as though it contained an offer SDP. However I=20 > > > > currently find the definition of "glare" and the=20 > expected behavior=20 > > > > to be ambiguous. > > > > > > > > What is the precise meaning of glare? I ask mainly=20 > because some=20 > > > > vendors send a 491 when an RFC indicates to send a 500. > > > > > > > > If INVITE contains offer SDP and 18x was not reliable,=20 > how SHOULD=20 > > > > the called party respond if UPDATE without SDP is received from=20 > > > > caller: 491, 500, or process as though no glare? > > > > > > > > If INVITE contains offer SDP and 18x was not reliable,=20 > how SHOULD=20 > > > > the caller respond if UPDATE without SDP is received=20 > from called=20 > > > > party: 491, 500, or process as though no glare? > > > > > > [JRE] I believe these two situations are both valid and=20 > should not=20 > > > result in a 4xx/5xx/6xx response unless something else is=20 > wrong with=20 > > > the request. > >=20 > > That was true before draft-ietf-sipcore-reinvite. However it looks=20 > > like the following snippets make it no longer true. > >=20 > > Draft-ietf-sipcore-reinvite section 3.5: > >=20 > > "An UPDATE request without an offer can change dialog=20 > parameters. So =20 > > can a non-2xx final response to a re-INVITE request or a=20 > 2xx response =20 > > to an INVITE request (re-INVITE or initial INVITE). =20 > However, there =20 > > are no rules to avoid a collision between an offerless=20 > UPDATE request =20 > > and a final response to an INVITE request. The rules in=20 > Section 4.5, =20 > > which are given in the context of target refreshes, cover=20 > these types =20 > > of collisions as well. Therefore, there is no need to specify =20 > > further rules here." > >=20 > > Draft-ietf-sipcore-reinvite section 4.5: > >=20 > > "When checking for glare situations, UAs MUST treat every UPDATE =20 > > request as if it contained an offer." > >=20 > > RFC3311 section 5.2: > >=20 > > "If an UPDATE is received that contains an offer, and the UAS has =20 > > generated an offer (in an UPDATE, PRACK or INVITE) to which it has =20 > > not yet received an answer, the UAS MUST reject the UPDATE=20 > with a 491 =20 > > response. Similarly, if an UPDATE is received that contains an =20 > > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > > INVITE) to which it has not yet generated an answer, the UAS MUST =20 > > reject the UPDATE with a 500 response, and MUST include a=20 > Retry-After =20 > > header field with a randomly chosen value between 0 and 10 seconds." > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue May 25 12:58:47 2010 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 A73EC3A6943 for ; Tue, 25 May 2010 12:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.671 X-Spam-Level: X-Spam-Status: No, score=-4.671 tagged_above=-999 required=5 tests=[AWL=1.928, 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 KRTetNwA3E90 for ; Tue, 25 May 2010 12:58:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 313AB3A68F5 for ; Tue, 25 May 2010 12:58:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-20-4bfc2becd55d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 56.C9.08537.CEB2CFB4; Tue, 25 May 2010 21:58:36 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 25 May 2010 21:58:36 +0200 From: Christer Holmberg To: "'Elwell, John'" , Brett Tate , "sipcore@ietf.org" Date: Tue, 25 May 2010 21:58:35 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAA/3EogAAByWSAAAbNkUA== Message-ID: References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 25 May 2010 19:58:47 -0000 Hi,=20 >>Thanks for the clarification. So the changes do not prohibit >>the use of UPDATE after only a non-reliable provisional response,=20 >>provided the UPDATE request does not contain an offer - correct? If it=20 >>does contain an offer it is subject >>to the glare rules. >=20 >Maybe I didn't understand, but what is the difference if you receive a rel= iable or unreliable response (without SDP)? > >[JRE] If only an unreliable provisional response has been received , an UP= DATE is not allowed to contain SDP, so treating it as if it contained SDP i= s rather odd. But, how is it less "odd" than treating an UPDATE as it it contained SDP wh= en you have received a reliable response (without SDP)?=20 >The following sequence: >(re-)INVITE-----> ><-----18x (unreliable) >----->UPDATE (no SDP) >is valid in accordance with RFC 3311, I believe. > >What seems to be suggested by the draft is that in some circumstances the = UAS might treat the received UPDATE as a glare. It is not clear to me under= what conditions=20 >it might be treated as a glare, but in any case, that would seem to be a c= hange to RFC 3311 for those particular conditions. I will have to try to refresh my memory, because I can't see how it would b= e a glare from an offer/answer perspective. Could it be related to target r= efresh? Regards, Christer >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Brett Tate [mailto:brett@broadsoft.com] > > Sent: 24 May 2010 12:55 > > To: Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and=20 > > UPDATE without SDP > >=20 > > > > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 > indicate that > > > > an UPDATE without SDP should be treated (from a glare > > > > perspective) as though it contained an offer SDP. However I=20 > > > > currently find the definition of "glare" and the > expected behavior > > > > to be ambiguous. > > > > > > > > What is the precise meaning of glare? I ask mainly > because some > > > > vendors send a 491 when an RFC indicates to send a 500. > > > > > > > > If INVITE contains offer SDP and 18x was not reliable, > how SHOULD > > > > the called party respond if UPDATE without SDP is received from > > > > caller: 491, 500, or process as though no glare? > > > > > > > > If INVITE contains offer SDP and 18x was not reliable, > how SHOULD > > > > the caller respond if UPDATE without SDP is received > from called > > > > party: 491, 500, or process as though no glare? > > > > > > [JRE] I believe these two situations are both valid and > should not > > > result in a 4xx/5xx/6xx response unless something else is > wrong with > > > the request. > >=20 > > That was true before draft-ietf-sipcore-reinvite. However it looks=20 > > like the following snippets make it no longer true. > >=20 > > Draft-ietf-sipcore-reinvite section 3.5: > >=20 > > "An UPDATE request without an offer can change dialog > parameters. So > > can a non-2xx final response to a re-INVITE request or a > 2xx response > > to an INVITE request (re-INVITE or initial INVITE). =20 > However, there > > are no rules to avoid a collision between an offerless > UPDATE request > > and a final response to an INVITE request. The rules in > Section 4.5, > > which are given in the context of target refreshes, cover > these types > > of collisions as well. Therefore, there is no need to specify=20 > > further rules here." > >=20 > > Draft-ietf-sipcore-reinvite section 4.5: > >=20 > > "When checking for glare situations, UAs MUST treat every UPDATE=20 > > request as if it contained an offer." > >=20 > > RFC3311 section 5.2: > >=20 > > "If an UPDATE is received that contains an offer, and the UAS has=20 > > generated an offer (in an UPDATE, PRACK or INVITE) to which it has=20 > > not yet received an answer, the UAS MUST reject the UPDATE > with a 491 > > response. Similarly, if an UPDATE is received that contains an=20 > > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > > INVITE) to which it has not yet generated an answer, the UAS MUST=20 > > reject the UPDATE with a 500 response, and MUST include a > Retry-After > > header field with a randomly chosen value between 0 and 10 seconds." > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue May 25 13:19:15 2010 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 A593C3A6A77 for ; Tue, 25 May 2010 13:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.885 X-Spam-Level: X-Spam-Status: No, score=-4.885 tagged_above=-999 required=5 tests=[AWL=1.714, 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 GYpO0GuV+XDL for ; Tue, 25 May 2010 13:19:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B2AB63A6A48 for ; Tue, 25 May 2010 13:19:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-47-4bfc309bdc61 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D4.AA.08537.B903CFB4; Tue, 25 May 2010 22:18:35 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.34]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 25 May 2010 22:18:34 +0200 From: Christer Holmberg To: "'Elwell, John'" , Brett Tate , "sipcore@ietf.org" Date: Tue, 25 May 2010 22:18:34 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAA/3EogAAByWSAAAbNkUAAAjcVA Message-ID: References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 25 May 2010 20:19:15 -0000 Hi, So, please note that the text in section 4.5 is about target refreshes - no= t offer/answers. So, if you have received an unreliable response, I guess you could send an = UPDATE. But, why would you want to? You cannot include SDP, and I don't bel= ieve you can include updated target information. But, if you have received an reliable response, you CAN send an UPDATE to u= pdate the target - and so can the remote party. And, then you may end up wi= th the glare situation described in section 4.5. So, I believe that is the reason for the "treat the UPDATE as if it contain= ed SDP" text, because in that case the UPDATE would be rejected (since you = don't know if the remote end replied to your UPDATE before it sent its own = UPDATE, or vice verse). Brett said that the procedure "forces" the UAS to include SDP in the reliab= le response, but I can't find any text indicating that...? Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 25. toukokuuta 2010 22:59 To: 'Elwell, John'; Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE wit= hout SDP Hi,=20 >>Thanks for the clarification. So the changes do not prohibit the use=20 >>of UPDATE after only a non-reliable provisional response, provided the=20 >>UPDATE request does not contain an offer - correct? If it does contain=20 >>an offer it is subject to the glare rules. >=20 >Maybe I didn't understand, but what is the difference if you receive a rel= iable or unreliable response (without SDP)? > >[JRE] If only an unreliable provisional response has been received , an UP= DATE is not allowed to contain SDP, so treating it as if it contained SDP i= s rather odd. But, how is it less "odd" than treating an UPDATE as it it contained SDP wh= en you have received a reliable response (without SDP)?=20 >The following sequence: >(re-)INVITE-----> ><-----18x (unreliable) >----->UPDATE (no SDP) >is valid in accordance with RFC 3311, I believe. > >What seems to be suggested by the draft is that in some circumstances=20 >the UAS might treat the received UPDATE as a glare. It is not clear to me = under what conditions it might be treated as a glare, but in any case, that= would seem to be a change to RFC 3311 for those particular conditions. I will have to try to refresh my memory, because I can't see how it would b= e a glare from an offer/answer perspective. Could it be related to target r= efresh? Regards, Christer >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Brett Tate [mailto:brett@broadsoft.com] > > Sent: 24 May 2010 12:55 > > To: Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and=20 > > UPDATE without SDP > >=20 > > > > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 > indicate that > > > > an UPDATE without SDP should be treated (from a glare > > > > perspective) as though it contained an offer SDP. However I=20 > > > > currently find the definition of "glare" and the > expected behavior > > > > to be ambiguous. > > > > > > > > What is the precise meaning of glare? I ask mainly > because some > > > > vendors send a 491 when an RFC indicates to send a 500. > > > > > > > > If INVITE contains offer SDP and 18x was not reliable, > how SHOULD > > > > the called party respond if UPDATE without SDP is received from > > > > caller: 491, 500, or process as though no glare? > > > > > > > > If INVITE contains offer SDP and 18x was not reliable, > how SHOULD > > > > the caller respond if UPDATE without SDP is received > from called > > > > party: 491, 500, or process as though no glare? > > > > > > [JRE] I believe these two situations are both valid and > should not > > > result in a 4xx/5xx/6xx response unless something else is > wrong with > > > the request. > >=20 > > That was true before draft-ietf-sipcore-reinvite. However it looks=20 > > like the following snippets make it no longer true. > >=20 > > Draft-ietf-sipcore-reinvite section 3.5: > >=20 > > "An UPDATE request without an offer can change dialog > parameters. So > > can a non-2xx final response to a re-INVITE request or a > 2xx response > > to an INVITE request (re-INVITE or initial INVITE). =20 > However, there > > are no rules to avoid a collision between an offerless > UPDATE request > > and a final response to an INVITE request. The rules in > Section 4.5, > > which are given in the context of target refreshes, cover > these types > > of collisions as well. Therefore, there is no need to specify=20 > > further rules here." > >=20 > > Draft-ietf-sipcore-reinvite section 4.5: > >=20 > > "When checking for glare situations, UAs MUST treat every UPDATE=20 > > request as if it contained an offer." > >=20 > > RFC3311 section 5.2: > >=20 > > "If an UPDATE is received that contains an offer, and the UAS has=20 > > generated an offer (in an UPDATE, PRACK or INVITE) to which it has=20 > > not yet received an answer, the UAS MUST reject the UPDATE > with a 491 > > response. Similarly, if an UPDATE is received that contains an=20 > > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > > INVITE) to which it has not yet generated an answer, the UAS MUST=20 > > reject the UPDATE with a 500 response, and MUST include a > Retry-After > > header field with a randomly chosen value between 0 and 10 seconds." > >=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 john.elwell@siemens-enterprise.com Tue May 25 23:35:34 2010 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 145033A6872 for ; Tue, 25 May 2010 23:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.233, 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 tjLf0Nfzo-gJ for ; Tue, 25 May 2010 23:35:33 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A4BC23A686E for ; Tue, 25 May 2010 23:35:32 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-289153; Wed, 26 May 2010 08:35:22 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B8D171EB82AB; Wed, 26 May 2010 08:35:22 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 26 May 2010 08:35:22 +0200 From: "Elwell, John" To: Christer Holmberg , Brett Tate , "sipcore@ietf.org" Date: Wed, 26 May 2010 08:35:20 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAA/3EogAAByWSAAAbNkUAAWfHVg Message-ID: References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 06:35:34 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 25 May 2010 20:59 > To: Elwell, John; Brett Tate; sipcore@ietf.org > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare=20 > and UPDATE without SDP >=20 >=20 > Hi,=20 >=20 > >>Thanks for the clarification. So the changes do not prohibit > >>the use of UPDATE after only a non-reliable provisional response,=20 > >>provided the UPDATE request does not contain an offer -=20 > correct? If it=20 > >>does contain an offer it is subject > >>to the glare rules. > >=20 > >Maybe I didn't understand, but what is the difference if you=20 > receive a reliable or unreliable response (without SDP)? > > > >[JRE] If only an unreliable provisional response has been=20 > received , an UPDATE is not allowed to contain SDP, so=20 > treating it as if it contained SDP is rather odd. >=20 > But, how is it less "odd" than treating an UPDATE as it it=20 > contained SDP when you have received a reliable response=20 > (without SDP)?=20 [JRE] You are right, a reliable response does not need to contain SDP if th= ere was an offer in the INVITE request. John >=20 > >The following sequence: > >(re-)INVITE-----> > ><-----18x (unreliable) > >----->UPDATE (no SDP) > >is valid in accordance with RFC 3311, I believe. > > > >What seems to be suggested by the draft is that in some=20 > circumstances the UAS might treat the received UPDATE as a=20 > glare. It is not clear to me under what conditions=20 > >it might be treated as a glare, but in any case, that would=20 > seem to be a change to RFC 3311 for those particular conditions. >=20 > I will have to try to refresh my memory, because I can't see=20 > how it would be a glare from an offer/answer perspective.=20 > Could it be related to target refresh? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > > -----Original Message----- > > > From: Brett Tate [mailto:brett@broadsoft.com] > > > Sent: 24 May 2010 12:55 > > > To: Elwell, John; sipcore@ietf.org > > > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and=20 > > > UPDATE without SDP > > >=20 > > > > > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 > > indicate that > > > > > an UPDATE without SDP should be treated (from a glare > > > > > perspective) as though it contained an offer SDP. However I=20 > > > > > currently find the definition of "glare" and the > > expected behavior > > > > > to be ambiguous. > > > > > > > > > > What is the precise meaning of glare? I ask mainly > > because some > > > > > vendors send a 491 when an RFC indicates to send a 500. > > > > > > > > > > If INVITE contains offer SDP and 18x was not reliable, > > how SHOULD > > > > > the called party respond if UPDATE without SDP is=20 > received from > > > > > caller: 491, 500, or process as though no glare? > > > > > > > > > > If INVITE contains offer SDP and 18x was not reliable, > > how SHOULD > > > > > the caller respond if UPDATE without SDP is received > > from called > > > > > party: 491, 500, or process as though no glare? > > > > > > > > [JRE] I believe these two situations are both valid and > > should not > > > > result in a 4xx/5xx/6xx response unless something else is > > wrong with > > > > the request. > > >=20 > > > That was true before draft-ietf-sipcore-reinvite. =20 > However it looks=20 > > > like the following snippets make it no longer true. > > >=20 > > > Draft-ietf-sipcore-reinvite section 3.5: > > >=20 > > > "An UPDATE request without an offer can change dialog > > parameters. So > > > can a non-2xx final response to a re-INVITE request or a > > 2xx response > > > to an INVITE request (re-INVITE or initial INVITE). =20 > > However, there > > > are no rules to avoid a collision between an offerless > > UPDATE request > > > and a final response to an INVITE request. The rules in > > Section 4.5, > > > which are given in the context of target refreshes, cover > > these types > > > of collisions as well. Therefore, there is no need to specify=20 > > > further rules here." > > >=20 > > > Draft-ietf-sipcore-reinvite section 4.5: > > >=20 > > > "When checking for glare situations, UAs MUST treat every UPDATE=20 > > > request as if it contained an offer." > > >=20 > > > RFC3311 section 5.2: > > >=20 > > > "If an UPDATE is received that contains an offer, and the UAS has=20 > > > generated an offer (in an UPDATE, PRACK or INVITE) to=20 > which it has=20 > > > not yet received an answer, the UAS MUST reject the UPDATE > > with a 491 > > > response. Similarly, if an UPDATE is received that contains an=20 > > > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > > > INVITE) to which it has not yet generated an answer, the=20 > UAS MUST=20 > > > reject the UPDATE with a 500 response, and MUST include a > > Retry-After > > > header field with a randomly chosen value between 0 and=20 > 10 seconds." > > >=20 > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > = From brett@broadsoft.com Wed May 26 05:05:43 2010 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 6124D3A6903 for ; Wed, 26 May 2010 05:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[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 JmAhbqe89WwN for ; Wed, 26 May 2010 05:05:42 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 765883A68E9 for ; Wed, 26 May 2010 05:05:42 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 26 May 2010 05:05:33 -0700 From: Brett Tate To: Christer Holmberg , "sipcore@ietf.org" Date: Wed, 26 May 2010 05:04:28 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAA/3EogAAByWSAAAbNkUAAAjcVAAB9MlyA= Message-ID: <747A6506A991724FB09B129B79D5FEB614816DD120@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 12:05:43 -0000 > So, please note that the text in section 4.5 is about target=20 > refreshes - not offer/answers. Section 3.5 indicates that section 4.5 isn't just about target refreshes. Section 4.5's fix explicitly uses offer/answer rules. And as far as I know= , it intentionally or unintentionally updates rfc3311 since all UPDATEs MUS= T now be treated like they contained an offer. If my understanding is not = true, please explain how the following quote is to be interpreted. Gao and= I appear to interpreting it (or when it applies) differently. Draft-ietf-sipcore-reinvite section 4.5: "When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer." > Brett said that the procedure "forces" the UAS to include SDP=20 > in the reliable response, but I can't find any text indicating=20 > that...? I never used the word "forces". And some may have thought my questions wer= e associated with re-INVITE; my questions were/are associated with INVITE.= =20 The following appears to require returning 491 or 500 to UPDATE without off= er SDP when the INVITE's offer SDP has not been answered. If my understand= ing is incorrect, please explain how the normative text does not require it= . Draft-ietf-sipcore-reinvite section 3.5: "An UPDATE request without an offer can change dialog parameters. So can a non-2xx final response to a re-INVITE request or a 2xx response to an INVITE request (re-INVITE or initial INVITE). However, there are no rules to avoid a collision between an offerless UPDATE request and a final response to an INVITE request. The rules in Section 4.5, which are given in the context of target refreshes, cover these types of collisions as well. Therefore, there is no need to specify further rules here." Draft-ietf-sipcore-reinvite section 4.5: "When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer." RFC3311 section 5.2: "If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds." Thanks, Brett From brett@broadsoft.com Wed May 26 05:47:16 2010 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 9A3A73A6943 for ; Wed, 26 May 2010 05:47:16 -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 B7t9kZ+RGLW8 for ; Wed, 26 May 2010 05:47:15 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id BC48D3A693C for ; Wed, 26 May 2010 05:47:15 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Wed, 26 May 2010 05:47:07 -0700 From: Brett Tate To: Christer Holmberg , "'Elwell, John'" , "sipcore@ietf.org" Date: Wed, 26 May 2010 05:46:04 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAA/3EogAAByWSAAAbNkUAAAjcVAACIthyA= Message-ID: <747A6506A991724FB09B129B79D5FEB614816DD14F@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 12:47:16 -0000 > So, if you have received an unreliable response, I guess you=20 > could send an UPDATE. But, why would you want to? You cannot=20 > include SDP, and I don't believe you can include updated=20 > target information. Prior to draft-ietf-sipcore-reinvite, you could use UPDATE without SDP to u= pdate/communicate things without being confined to the current offer/answer= state. For example, rfc5876 section 3.2 discusses communicating P-Asserte= d-Identity. It can no longer be successfully communicated within UPDATE ov= er an early dialog (resulting in 2xx response) unless the called party has = sent the answer for the INVITE's offer SDP. > But, if you have received an reliable response, you CAN send an UPDATE > to update the target - and so can the remote party. And, then you may > end up with the glare situation described in section 4.5. That isn't the only glare situation and it doesn't just apply to changing t= arget. As mentioned above, attempting to communicate P-Asserted-Identity w= ill also lead to a 491 if the called party has not sent an answer SDP for I= NVITE's offer SDP. > So, I believe that is the reason for the "treat the UPDATE as if it > contained SDP" text, because in that case the UPDATE would be rejected > (since you don't know if the remote end replied to your UPDATE before > it sent its own UPDATE, or vice verse). The normative text does not limit it only that situation. Draft-ietf-sipcore-reinvite-04 section 4.5:=20 "When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer." RFC3311 section 5.2: "If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds." From gao.yang2@zte.com.cn Wed May 26 06:34:37 2010 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 EE2353A691D for ; Wed, 26 May 2010 06:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.221 X-Spam-Level: X-Spam-Status: No, score=-95.221 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 gzEIgBxSRYrF for ; Wed, 26 May 2010 06:34:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id DD96A3A68F5 for ; Wed, 26 May 2010 06:34:35 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Wed, 26 May 2010 21:27:50 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 99325.5222410540; Wed, 26 May 2010 21:29:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4QDYVKD095359; Wed, 26 May 2010 21:34:31 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DD14F@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 26 May 2010 21:31:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-26 21:34:08, Serialize complete at 2010-05-26 21:34:08 Content-Type: multipart/alternative; boundary="=_alternative 004A81E54825772F_=" X-MAIL: mse2.zte.com.cn o4QDYVKD095359 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 13:34:38 -0000 This is a multipart message in MIME format. --=_alternative 004A81E54825772F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBndWVzcyB0aGUga2V5IGZvciB0aGlzIGRpdmFyaWNhdGlvbiBoZXJlIGlzIHN0aWxsIGFib3V0 IHRoZSBkaWZmZXJlbnQgDQp1bmRlcnN0YW5kaW5nIG9mIHRoZSBzZW1hbnRpY3Mgb2YgImNoZWNr aW5nIGZvciBnbGFyZSBzaXR1YXRpb25zIi4gSWYgaXQgDQppcyBvbmx5IGFwcGxpZWQgaW4gaGFw cGVuZWQgZ2xhcmUgc2l0dWF0aW9ucywgaXQgd291bGQgbm90IGJlIGEgcHJvYmxlbS4NCg0KVG8g bWFrZSB0aGUgdHdvIHVuZGVyc3RhbmRpbmcncyBtZXJpdCBhbmQgZGlzYWR2YW50YWdlIGNsZWFy LCBJJ2QgbGlrZSB0byANCnNheSBvbmUgZGlzYWR2YW50YWdlIGZvciB0aGUgdW5kZXJzdGFuZGlu ZyB5b3Ugc2hvd2VkOg0KSWYgdGhlIHJ1bGVzIGlzIGZvciBhbGwgdGFyZ2V0IHJlZnJlc2ggcmVx dWVzdCB3aXRob3V0IE8vQSwgaXQgcmVhbGx5IA0KZm9yYmlkIHNvbWUgYmVoYXZpb3JzIHdoaWNo IGlzIGxhd2Z1bCBvbmNlLiBObyBtYXR0ZXIgaG93IG11Y2ggYmVoYXZpb3IgDQp3b3VsZCBiZSBh ZmZlY3RlZCwgaXQgd291bGQgYmUgYSByZWFsIGFuZCByZW1hcmthYmxlIGNvbXBhdGlibGUgDQpp bnRlcndvcmtpbmcgcHJvYmxlbS4NCg0KU28sIHVyZ2VuY3kgaGVyZSBpcyBhYm91dCB0aGUgdW5k ZXJzdGFuZGluZyBvZiB0aGUgc2VtYW50aWNzIG9mICJjaGVja2luZyANCmZvciBnbGFyZSBzaXR1 YXRpb25zIi4NCg0KQW5kIEknZCBsaWtlIHRvIGhlYXIgeW91ciBjb21tZW50cyBhYm91dCB0aGUg Y2FzZXMgbWVudGlvbmVkIHVuZGVyIG15IA0KdW5kZXJzdGFuZGluZyAiY2hlY2tpbmcgZm9yIGds YXJlIHNpdHVhdGlvbnMiLiBJbiBmYWN0LCB3aGljaCANCnVuZGVyc3RhbmRpbmcgaXMgKnBlb3Bs ZSdzKiB1bmRlcnN0YW5kaW5nIGNhbiBub3Qgc29sdmUgcHJvYmxlbS4gTWF5YmUgd2UgDQpjYW4g c3RlcCBvdXQgdGhlIHF1ZXN0aW9uIGEgbGl0dGxlIHRvIGNvbmNlbnRyYXRlIG9uIHdoaWNoIG9u ZSBjYW4gc29sdmUgDQpwcm9ibGVtLg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0w MjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCkJyZXR0IFRhdGUgPGJyZXR0QGJyb2Fkc29m dC5jb20+IA0Kt6K8/sjLOiAgc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQoyMDEwLTA1LTI2IDIw OjQ2DQoNCsrVvP7Iyw0KQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4sICInRWx3ZWxsLCBKb2huJyIgDQo8am9obi5lbHdlbGxAc2llbWVucy1lbnRlcnBy aXNlLmNvbT4sICJzaXBjb3JlQGlldGYub3JnIiANCjxzaXBjb3JlQGlldGYub3JnPg0Ks63LzQ0K DQrW98ziDQpSZTogW3NpcGNvcmVdIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNDogZ2xh cmUgYW5kIFVQREFURSB3aXRob3V0IFNEUA0KDQoNCg0KDQoNCg0KPiBTbywgaWYgeW91IGhhdmUg cmVjZWl2ZWQgYW4gdW5yZWxpYWJsZSByZXNwb25zZSwgSSBndWVzcyB5b3UgDQo+IGNvdWxkIHNl bmQgYW4gVVBEQVRFLiBCdXQsIHdoeSB3b3VsZCB5b3Ugd2FudCB0bz8gWW91IGNhbm5vdCANCj4g aW5jbHVkZSBTRFAsIGFuZCBJIGRvbid0IGJlbGlldmUgeW91IGNhbiBpbmNsdWRlIHVwZGF0ZWQg DQo+IHRhcmdldCBpbmZvcm1hdGlvbi4NCg0KUHJpb3IgdG8gZHJhZnQtaWV0Zi1zaXBjb3JlLXJl aW52aXRlLCB5b3UgY291bGQgdXNlIFVQREFURSB3aXRob3V0IFNEUCB0byANCnVwZGF0ZS9jb21t dW5pY2F0ZSB0aGluZ3Mgd2l0aG91dCBiZWluZyBjb25maW5lZCB0byB0aGUgY3VycmVudCANCm9m ZmVyL2Fuc3dlciBzdGF0ZS4gIEZvciBleGFtcGxlLCByZmM1ODc2IHNlY3Rpb24gMy4yIGRpc2N1 c3NlcyANCmNvbW11bmljYXRpbmcgUC1Bc3NlcnRlZC1JZGVudGl0eS4gIEl0IGNhbiBubyBsb25n ZXIgYmUgc3VjY2Vzc2Z1bGx5IA0KY29tbXVuaWNhdGVkIHdpdGhpbiBVUERBVEUgb3ZlciBhbiBl YXJseSBkaWFsb2cgKHJlc3VsdGluZyBpbiAyeHggDQpyZXNwb25zZSkgdW5sZXNzIHRoZSBjYWxs ZWQgcGFydHkgaGFzIHNlbnQgdGhlIGFuc3dlciBmb3IgdGhlIElOVklURSdzIA0Kb2ZmZXIgU0RQ Lg0KDQoNCj4gQnV0LCBpZiB5b3UgaGF2ZSByZWNlaXZlZCBhbiByZWxpYWJsZSByZXNwb25zZSwg eW91IENBTiBzZW5kIGFuIFVQREFURQ0KPiB0byB1cGRhdGUgdGhlIHRhcmdldCAtIGFuZCBzbyBj YW4gdGhlIHJlbW90ZSBwYXJ0eS4gQW5kLCB0aGVuIHlvdSBtYXkNCj4gZW5kIHVwIHdpdGggdGhl IGdsYXJlIHNpdHVhdGlvbiBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjUuDQoNClRoYXQgaXNuJ3Qg dGhlIG9ubHkgZ2xhcmUgc2l0dWF0aW9uIGFuZCBpdCBkb2Vzbid0IGp1c3QgYXBwbHkgdG8gY2hh bmdpbmcgDQp0YXJnZXQuICBBcyBtZW50aW9uZWQgYWJvdmUsIGF0dGVtcHRpbmcgdG8gY29tbXVu aWNhdGUgUC1Bc3NlcnRlZC1JZGVudGl0eSANCndpbGwgYWxzbyBsZWFkIHRvIGEgNDkxIGlmIHRo ZSBjYWxsZWQgcGFydHkgaGFzIG5vdCBzZW50IGFuIGFuc3dlciBTRFAgZm9yIA0KSU5WSVRFJ3Mg b2ZmZXIgU0RQLg0KDQoNCj4gU28sIEkgYmVsaWV2ZSB0aGF0IGlzIHRoZSByZWFzb24gZm9yIHRo ZSAidHJlYXQgdGhlIFVQREFURSBhcyBpZiBpdA0KPiBjb250YWluZWQgU0RQIiB0ZXh0LCBiZWNh dXNlIGluIHRoYXQgY2FzZSB0aGUgVVBEQVRFIHdvdWxkIGJlIHJlamVjdGVkDQo+IChzaW5jZSB5 b3UgZG9uJ3Qga25vdyBpZiB0aGUgcmVtb3RlIGVuZCByZXBsaWVkIHRvIHlvdXIgVVBEQVRFIGJl Zm9yZQ0KPiBpdCBzZW50IGl0cyBvd24gVVBEQVRFLCBvciB2aWNlIHZlcnNlKS4NCg0KVGhlIG5v cm1hdGl2ZSB0ZXh0IGRvZXMgbm90IGxpbWl0IGl0IG9ubHkgdGhhdCBzaXR1YXRpb24uDQoNCkRy YWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNCBzZWN0aW9uIDQuNTogDQoNCiJXaGVuIGNoZWNr aW5nIGZvciBnbGFyZSBzaXR1YXRpb25zLCBVQXMgTVVTVCB0cmVhdCBldmVyeSBVUERBVEUNCiBy ZXF1ZXN0IGFzIGlmIGl0IGNvbnRhaW5lZCBhbiBvZmZlci4iDQoNClJGQzMzMTEgc2VjdGlvbiA1 LjI6DQoNCiJJZiBhbiBVUERBVEUgaXMgcmVjZWl2ZWQgdGhhdCBjb250YWlucyBhbiBvZmZlciwg YW5kIHRoZSBVQVMgaGFzDQogZ2VuZXJhdGVkIGFuIG9mZmVyIChpbiBhbiBVUERBVEUsIFBSQUNL IG9yIElOVklURSkgdG8gd2hpY2ggaXQgaGFzDQogbm90IHlldCByZWNlaXZlZCBhbiBhbnN3ZXIs IHRoZSBVQVMgTVVTVCByZWplY3QgdGhlIFVQREFURSB3aXRoIGEgNDkxDQogcmVzcG9uc2UuICBT aW1pbGFybHksIGlmIGFuIFVQREFURSBpcyByZWNlaXZlZCB0aGF0IGNvbnRhaW5zIGFuDQogb2Zm ZXIsIGFuZCB0aGUgVUFTIGhhcyByZWNlaXZlZCBhbiBvZmZlciAoaW4gYW4gVVBEQVRFLCBQUkFD Sywgb3INCiBJTlZJVEUpIHRvIHdoaWNoIGl0IGhhcyBub3QgeWV0IGdlbmVyYXRlZCBhbiBhbnN3 ZXIsIHRoZSBVQVMgTVVTVA0KIHJlamVjdCB0aGUgVVBEQVRFIHdpdGggYSA1MDAgcmVzcG9uc2Us IGFuZCBNVVNUIGluY2x1ZGUgYSBSZXRyeS1BZnRlcg0KIGhlYWRlciBmaWVsZCB3aXRoIGEgcmFu ZG9tbHkgY2hvc2VuIHZhbHVlIGJldHdlZW4gMCBhbmQgMTAgc2Vjb25kcy4iDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcg bGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBjb3JlDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 004A81E54825772F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZ3Vlc3MgdGhlIGtleSBmb3Ig dGhpcyBkaXZhcmljYXRpb24NCmhlcmUgaXMgc3RpbGwgYWJvdXQgdGhlIGRpZmZlcmVudCB1bmRl cnN0YW5kaW5nIG9mIHRoZSBzZW1hbnRpY3Mgb2YgJnF1b3Q7Y2hlY2tpbmcNCmZvciBnbGFyZSBz aXR1YXRpb25zJnF1b3Q7LiBJZiBpdCBpcyBvbmx5IGFwcGxpZWQgaW4gaGFwcGVuZWQgZ2xhcmUg c2l0dWF0aW9ucywNCml0IHdvdWxkIG5vdCBiZSBhIHByb2JsZW0uPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UbyBtYWtlIHRoZSB0d28gdW5kZXJzdGFu ZGluZydzIG1lcml0DQphbmQgZGlzYWR2YW50YWdlIGNsZWFyLCBJJ2QgbGlrZSB0byBzYXkgb25l IGRpc2FkdmFudGFnZSBmb3IgdGhlIHVuZGVyc3RhbmRpbmcNCnlvdSBzaG93ZWQ6PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB0aGUgcnVsZXMgaXMgZm9yIGFs bCB0YXJnZXQgcmVmcmVzaA0KcmVxdWVzdCB3aXRob3V0IE8vQSwgaXQgcmVhbGx5IGZvcmJpZCBz b21lIGJlaGF2aW9ycyB3aGljaCBpcyBsYXdmdWwgb25jZS4NCk5vIG1hdHRlciBob3cgbXVjaCBi ZWhhdmlvciB3b3VsZCBiZSBhZmZlY3RlZCwgaXQgd291bGQgYmUgYSByZWFsIGFuZCByZW1hcmth YmxlDQpjb21wYXRpYmxlIGludGVyd29ya2luZyBwcm9ibGVtLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28sIHVyZ2VuY3kgaGVyZSBpcyBhYm91dCB0 aGUgdW5kZXJzdGFuZGluZw0Kb2YgdGhlIHNlbWFudGljcyBvZiAmcXVvdDtjaGVja2luZyBmb3Ig Z2xhcmUgc2l0dWF0aW9ucyZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkFuZCBJJ2QgbGlrZSB0byBoZWFyIHlvdXIgY29tbWVudHMgYWJvdXQN CnRoZSBjYXNlcyBtZW50aW9uZWQgdW5kZXIgbXkgdW5kZXJzdGFuZGluZyAmcXVvdDtjaGVja2lu ZyBmb3IgZ2xhcmUgc2l0dWF0aW9ucyZxdW90Oy4NCkluIGZhY3QsIHdoaWNoIHVuZGVyc3RhbmRp bmcgaXMgKnBlb3BsZSdzKiB1bmRlcnN0YW5kaW5nIGNhbiBub3Qgc29sdmUNCnByb2JsZW0uIE1h eWJlIHdlIGNhbiBzdGVwIG91dCB0aGUgcXVlc3Rpb24gYSBsaXR0bGUgdG8gY29uY2VudHJhdGUg b24NCndoaWNoIG9uZSBjYW4gc29sdmUgcHJvYmxlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJz cDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9t YWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj48Yj5CcmV0dCBUYXRlICZsdDticmV0dEBicm9hZHNvZnQuY29tJmd0OzwvYj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAxMC0wNS0yNiAyMDo0NjwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5DaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tJmd0OywNCiZxdW90OydFbHdlbGwsIEpvaG4nJnF1b3Q7ICZsdDtq b2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29tJmd0OywNCiZxdW90O3NpcGNvcmVAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIGRyYWZ0 LWlldGYtc2lwY29yZS1yZWludml0ZS0wNDoNCmdsYXJlIGFuZCBVUERBVEUgd2l0aG91dCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTRFA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU28sIGlmIHlvdSBoYXZlIHJlY2VpdmVk IGFuIHVucmVsaWFibGUgcmVzcG9uc2UsDQpJIGd1ZXNzIHlvdSA8YnI+DQomZ3Q7IGNvdWxkIHNl bmQgYW4gVVBEQVRFLiBCdXQsIHdoeSB3b3VsZCB5b3Ugd2FudCB0bz8gWW91IGNhbm5vdCA8YnI+ DQomZ3Q7IGluY2x1ZGUgU0RQLCBhbmQgSSBkb24ndCBiZWxpZXZlIHlvdSBjYW4gaW5jbHVkZSB1 cGRhdGVkIDxicj4NCiZndDsgdGFyZ2V0IGluZm9ybWF0aW9uLjxicj4NCjxicj4NClByaW9yIHRv IGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZSwgeW91IGNvdWxkIHVzZSBVUERBVEUgd2l0aG91 dCBTRFANCnRvIHVwZGF0ZS9jb21tdW5pY2F0ZSB0aGluZ3Mgd2l0aG91dCBiZWluZyBjb25maW5l ZCB0byB0aGUgY3VycmVudCBvZmZlci9hbnN3ZXINCnN0YXRlLiAmbmJzcDtGb3IgZXhhbXBsZSwg cmZjNTg3NiBzZWN0aW9uIDMuMiBkaXNjdXNzZXMgY29tbXVuaWNhdGluZyBQLUFzc2VydGVkLUlk ZW50aXR5Lg0KJm5ic3A7SXQgY2FuIG5vIGxvbmdlciBiZSBzdWNjZXNzZnVsbHkgY29tbXVuaWNh dGVkIHdpdGhpbiBVUERBVEUgb3Zlcg0KYW4gZWFybHkgZGlhbG9nIChyZXN1bHRpbmcgaW4gMnh4 IHJlc3BvbnNlKSB1bmxlc3MgdGhlIGNhbGxlZCBwYXJ0eSBoYXMNCnNlbnQgdGhlIGFuc3dlciBm b3IgdGhlIElOVklURSdzIG9mZmVyIFNEUC48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IEJ1dCwgaWYg eW91IGhhdmUgcmVjZWl2ZWQgYW4gcmVsaWFibGUgcmVzcG9uc2UsIHlvdSBDQU4gc2VuZCBhbiBV UERBVEU8YnI+DQomZ3Q7IHRvIHVwZGF0ZSB0aGUgdGFyZ2V0IC0gYW5kIHNvIGNhbiB0aGUgcmVt b3RlIHBhcnR5LiBBbmQsIHRoZW4geW91DQptYXk8YnI+DQomZ3Q7IGVuZCB1cCB3aXRoIHRoZSBn bGFyZSBzaXR1YXRpb24gZGVzY3JpYmVkIGluIHNlY3Rpb24gNC41Ljxicj4NCjxicj4NClRoYXQg aXNuJ3QgdGhlIG9ubHkgZ2xhcmUgc2l0dWF0aW9uIGFuZCBpdCBkb2Vzbid0IGp1c3QgYXBwbHkg dG8gY2hhbmdpbmcNCnRhcmdldC4gJm5ic3A7QXMgbWVudGlvbmVkIGFib3ZlLCBhdHRlbXB0aW5n IHRvIGNvbW11bmljYXRlIFAtQXNzZXJ0ZWQtSWRlbnRpdHkNCndpbGwgYWxzbyBsZWFkIHRvIGEg NDkxIGlmIHRoZSBjYWxsZWQgcGFydHkgaGFzIG5vdCBzZW50IGFuIGFuc3dlciBTRFANCmZvciBJ TlZJVEUncyBvZmZlciBTRFAuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBTbywgSSBiZWxpZXZlIHRo YXQgaXMgdGhlIHJlYXNvbiBmb3IgdGhlICZxdW90O3RyZWF0IHRoZSBVUERBVEUgYXMNCmlmIGl0 PGJyPg0KJmd0OyBjb250YWluZWQgU0RQJnF1b3Q7IHRleHQsIGJlY2F1c2UgaW4gdGhhdCBjYXNl IHRoZSBVUERBVEUgd291bGQgYmUNCnJlamVjdGVkPGJyPg0KJmd0OyAoc2luY2UgeW91IGRvbid0 IGtub3cgaWYgdGhlIHJlbW90ZSBlbmQgcmVwbGllZCB0byB5b3VyIFVQREFURSBiZWZvcmU8YnI+ DQomZ3Q7IGl0IHNlbnQgaXRzIG93biBVUERBVEUsIG9yIHZpY2UgdmVyc2UpLjxicj4NCjxicj4N ClRoZSBub3JtYXRpdmUgdGV4dCBkb2VzIG5vdCBsaW1pdCBpdCBvbmx5IHRoYXQgc2l0dWF0aW9u Ljxicj4NCjxicj4NCkRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNCBzZWN0aW9uIDQuNTog PGJyPg0KPGJyPg0KJnF1b3Q7V2hlbiBjaGVja2luZyBmb3IgZ2xhcmUgc2l0dWF0aW9ucywgVUFz IE1VU1QgdHJlYXQgZXZlcnkgVVBEQVRFPGJyPg0KIHJlcXVlc3QgYXMgaWYgaXQgY29udGFpbmVk IGFuIG9mZmVyLiZxdW90Ozxicj4NCjxicj4NClJGQzMzMTEgc2VjdGlvbiA1LjI6PGJyPg0KPGJy Pg0KJnF1b3Q7SWYgYW4gVVBEQVRFIGlzIHJlY2VpdmVkIHRoYXQgY29udGFpbnMgYW4gb2ZmZXIs IGFuZCB0aGUgVUFTIGhhczxicj4NCiBnZW5lcmF0ZWQgYW4gb2ZmZXIgKGluIGFuIFVQREFURSwg UFJBQ0sgb3IgSU5WSVRFKSB0byB3aGljaCBpdCBoYXM8YnI+DQogbm90IHlldCByZWNlaXZlZCBh biBhbnN3ZXIsIHRoZSBVQVMgTVVTVCByZWplY3QgdGhlIFVQREFURSB3aXRoIGEgNDkxPGJyPg0K IHJlc3BvbnNlLiAmbmJzcDtTaW1pbGFybHksIGlmIGFuIFVQREFURSBpcyByZWNlaXZlZCB0aGF0 IGNvbnRhaW5zIGFuPGJyPg0KIG9mZmVyLCBhbmQgdGhlIFVBUyBoYXMgcmVjZWl2ZWQgYW4gb2Zm ZXIgKGluIGFuIFVQREFURSwgUFJBQ0ssIG9yPGJyPg0KIElOVklURSkgdG8gd2hpY2ggaXQgaGFz IG5vdCB5ZXQgZ2VuZXJhdGVkIGFuIGFuc3dlciwgdGhlIFVBUyBNVVNUPGJyPg0KIHJlamVjdCB0 aGUgVVBEQVRFIHdpdGggYSA1MDAgcmVzcG9uc2UsIGFuZCBNVVNUIGluY2x1ZGUgYSBSZXRyeS1B ZnRlcjxicj4NCiBoZWFkZXIgZmllbGQgd2l0aCBhIHJhbmRvbWx5IGNob3NlbiB2YWx1ZSBiZXR3 ZWVuIDAgYW5kIDEwIHNlY29uZHMuJnF1b3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxi cj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmU8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhl Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt YWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZu YnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNw O21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Bl cm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNw O29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRo aXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0 ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQm bmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8m bmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNw O3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2lu Jm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5h dG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5i c3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNw O3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZu YnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRp LVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 004A81E54825772F_=-- From HKaplan@acmepacket.com Wed May 26 07:13:31 2010 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 7F44D3A691A for ; Wed, 26 May 2010 07:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, 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 v1x1c5wFjPgy for ; Wed, 26 May 2010 07:13:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D8EAF3A6926 for ; Wed, 26 May 2010 07:13:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 26 May 2010 10:13:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 26 May 2010 10:13:16 -0400 From: Hadriel Kaplan To: "Elwell, John" , Christer Holmberg , SIPCORE Date: Wed, 26 May 2010 10:13:15 -0400 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGwgAH0Y8A= Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A302@mail> 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 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 14:13:31 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Elwell, John > Sent: Tuesday, May 25, 2010 4:34 AM >=20 > Thanks, this addresses concerns I had with the previous version. Same here. =20 > Digging deeper into the issue with the Flow-Timer header field, I view it > this way. The "keep" parameter is in the Via header field, which has one > entry per hop over which the request passes. Therefore the "keep" > parameter is clearly associated with a given hop. However, the Flow-Timer > header field does not have the concept of one entry per hop. Therefore th= e > header field is assumed to apply only to the current hop, and has to be > removed before forwarding a response over a hop on which keep-alive has > not been requested, or needs to have its value modified before forwarding > a response over a hop on which keep-alive has been requested. It seems od= d > that the two pieces of information used by this feature should be handled > in two completely different ways. Yes I had the same feeling when reading it - that it's odd/unnatural to do = the Flow-Timer header in when it would be simpler to just make it the keep = param's value. But obviously Flow-Timer is used in Outbound, so in some se= nse it also feels odd to make it different from that. =20 > Another difference is that when a proxy receives a "keep" parameter in th= e > topmost Via header field entry, it adds "yes" as the value of that > parameter when forwarding that Via header entry (which will no longer be > the topmost entry and therefore will not be inspected by the next entity)= . > Therefore when the Via header field is returned in the response, it will > already have the "yes" value in place when it crosses the hop to which th= e > entry applies. Therefore the proxy does not need to take special action > concerning the Via header field when forwarding the response. In contrast= , > a proxy has to take special action with the Flow-Timer header field when > forwarding a response, as described above. The way "keep" is handled seem= s > to take account of transaction-stateless proxies, whereas the way Flow- > Timer is handle does not. I am not sure, however, whether this mechanism > makes sense for use with transaction-stateless proxies anyway, so perhaps > this latter point is moot. We shouldn't disallow stateless proxies from doing it, but yeah it's not th= e "normal" case. Regardless, I'm not sure why the Proxy inserts the keep in the forwarded Re= quest, instead of just in the response(s)? -hadriel From christer.holmberg@ericsson.com Wed May 26 07:24:34 2010 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 76EDB3A67A2 for ; Wed, 26 May 2010 07:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_20=-0.74] 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 pdOYb6Gk6ZeX for ; Wed, 26 May 2010 07:24:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2CB553A66B4 for ; Wed, 26 May 2010 07:24:32 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-4d-4bfd2f1783b1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D2.0C.21861.71F2DFB4; Wed, 26 May 2010 16:24:23 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 26 May 2010 16:24:23 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , SIPCORE Date: Wed, 26 May 2010 16:24:21 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGwgAH0Y8CAAAPY0A== Message-ID: References: , <430FC6BDED356B4C8498F634416644A91C13B8A302@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A302@mail> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 14:24:34 -0000 Hi, >>Thanks, this addresses concerns I had with the previous version. > >Same here. Great! >> Digging deeper into the issue with the Flow-Timer header field, I view i= t >> this way. The "keep" parameter is in the Via header field, which has one >> entry per hop over which the request passes. Therefore the "keep" >> parameter is clearly associated with a given hop. However, the Flow-Time= r >> header field does not have the concept of one entry per hop. Therefore t= he >> header field is assumed to apply only to the current hop, and has to be >> removed before forwarding a response over a hop on which keep-alive has >> not been requested, or needs to have its value modified before forwardin= g >> a response over a hop on which keep-alive has been requested. It seems o= dd >> that the two pieces of information used by this feature should be handle= d >> in two completely different ways. > >Yes I had the same feeling when reading it - that it's odd/unnatural to do= the Flow-Timer header in when it would be simpler to just make it the keep= param's value. But obviously Flow-Timer is used in Outbound, so in some s= ense it also feels odd to make it different from that. So, we just need to pick one alternative :) Keep is leading 1 - 0. >> Another difference is that when a proxy receives a "keep" parameter in t= he >> topmost Via header field entry, it adds "yes" as the value of that >> parameter when forwarding that Via header entry (which will no longer be >> the topmost entry and therefore will not be inspected by the next entity= ). >> Therefore when the Via header field is returned in the response, it will >> already have the "yes" value in place when it crosses the hop to which t= he >> entry applies. Therefore the proxy does not need to take special action >> concerning the Via header field when forwarding the response. In contras= t, >> a proxy has to take special action with the Flow-Timer header field when >> forwarding a response, as described above. The way "keep" is handled see= ms >> to take account of transaction-stateless proxies, whereas the way Flow- >> Timer is handle does not. I am not sure, however, whether this mechanism >> makes sense for use with transaction-stateless proxies anyway, so perhap= s >> this latter point is moot. > >We shouldn't disallow stateless proxies from doing it, but yeah it's not t= he "normal" case. > >Regardless, I'm not sure why the Proxy inserts the keep in the forwarded R= equest, instead of just in the response(s)? In case it wants to indicate to ITS adjacent upstream entity (maybe another= proxy) that it is willing to send-keep alives. There may not be many use-c= ases (someone mentioned a PBX connection point acting as a proxy), but ther= e is no reason to forbid it. UAs and proxies can use the same procedures. Regards, Christer= From HKaplan@acmepacket.com Wed May 26 07:40:30 2010 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 4F26B3A691A for ; Wed, 26 May 2010 07:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_05=-1.11, J_CHICKENPOX_43=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 sw01vBQ9YUCF for ; Wed, 26 May 2010 07:40:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5C7F73A691E for ; Wed, 26 May 2010 07:40:29 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 26 May 2010 10:40:19 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 26 May 2010 10:40:19 -0400 From: Hadriel Kaplan To: Christer Holmberg , SIPCORE Date: Wed, 26 May 2010 10:40:18 -0400 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJjxHIw Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A32D@mail> 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 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 14:40:30 -0000 Hi Christer, I like this version a lot more. :) Technical comments/questions: 1) Why does the Proxy insert the keep in the forwarded Request, vs. just th= e response(s)? 2) You note that a keep=3Dyes in any response to a request means the next-h= op can handle keep. Does this mean a Proxy can send it in a 100 Trying? I= f so (and I assume it should be so), then the Proxy really needs to add the= "yes" to responses, not forwarded requests I think. 3) You use the phrase "within a registration" a lot. I assume this means f= or the lifetime of the Registration binding (as opposed to say the duration= of the REGISTER transaction, between the request and final response). So = does this mean that a REGISTER refresh (i.e., same call-id) does or does no= t re-negotiate keep? I think it must, since a real Proxy doesn't really kn= ow whether a REGISTER is a refresh vs. a new one. 4) Section 4.2.1 states: "The scope of the negotiated keep-alives depends on what SIP request met= hods are used for the keep-alive negotiation." I don't think you want to make it method-specific in the draft, except for = maybe REGISTER. But other than REGISTER, any dialog-forming or in-dialog r= equest affects the keep for the duration of the dialog. Any out-of-dialog,= non-dialog-forming Request other than REGISTER would presumably have no im= pact. I mention this because an out-of-dialog MESSAGE or PUBLISH would hav= e no bearing on keep I guess, but those same methods in-dialog could negoti= ate keep (as I read the current text in the draft). 5) Section 4.2.1 states: "The sending and receiving of keep-alives can be negotiated when a registration or dialog is initiated, or later during the registration or dialog. However, once a SIP entity has negotiated the sending of keep-alives within a registration or dialog, it can not re-negotiate the sending of keep-alives within the same registration or dialog. Likewise, once a SIP entity has indicated willingness to receive keep-alives within a registration or dialog, it MUST NOT indicate willingness to receive keep-alives in a response to a subsequent request within that registration or dialog." Why is there that last sentence's restriction? =20 -hadriel From HKaplan@acmepacket.com Wed May 26 07:46:01 2010 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 47C083A6958 for ; Wed, 26 May 2010 07:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[AWL=1.091, 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 d9x2eC0SHFJL for ; Wed, 26 May 2010 07:46:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 411CC3A6955 for ; Wed, 26 May 2010 07:46:00 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 26 May 2010 10:45:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 26 May 2010 10:45:50 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , SIPCORE Date: Wed, 26 May 2010 10:45:49 -0400 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGwgAH0Y8CAAAPY0IAABpeg Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A336@mail> References: , <430FC6BDED356B4C8498F634416644A91C13B8A302@mail> 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 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 14:46:01 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, May 26, 2010 10:24 AM > To: Hadriel Kaplan; Elwell, John; SIPCORE > > > >Regardless, I'm not sure why the Proxy inserts the keep in the forwarded > Request, instead of just in the response(s)? >=20 > In case it wants to indicate to ITS adjacent upstream entity (maybe > another proxy) that it is willing to send-keep alives. There may not be > many use-cases (someone mentioned a PBX connection point acting as a > proxy), but there is no reason to forbid it. UAs and proxies can use the > same procedures. Yeah I was worried you'd say that. :) I think that's a dangerous assumption. The Proxy may not be able to suppor= t keep-alive on that Proxy-Proxy connection/side, while it can for the UA-P= roxy side. Believing some lower Via isn't safe. What should really happen is the Proxy should add a keep param (without "ye= s") in ITS Via header, so that the downstream Proxy getting it can add a "y= es" to that Via, for that connection. In other words, all the logic should= be about top-most Via's. -hadriel From christer.holmberg@ericsson.com Wed May 26 08:19:08 2010 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 82E4B3A67F4 for ; Wed, 26 May 2010 08:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.93 X-Spam-Level: X-Spam-Status: No, score=-4.93 tagged_above=-999 required=5 tests=[AWL=1.669, 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 847s0hkvuQfC for ; Wed, 26 May 2010 08:19:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7C5FF3A68E1 for ; Wed, 26 May 2010 08:19:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-b1-4bfd3bde8924 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 05.36.08537.EDB3DFB4; Wed, 26 May 2010 17:18:54 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 26 May 2010 17:18:53 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , SIPCORE Date: Wed, 26 May 2010 17:14:50 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGwgAH0Y8CAAAPY0IAABpeggAAJaVM= Message-ID: References: , <430FC6BDED356B4C8498F634416644A91C13B8A302@mail> , <430FC6BDED356B4C8498F634416644A91C13B8A336@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A336@mail> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 15:19:08 -0000 Hi, >>>Regardless, I'm not sure why the Proxy inserts the keep in the forwarded >>Request, instead of just in the response(s)? > >>In case it wants to indicate to ITS adjacent upstream entity (maybe >>another proxy) that it is willing to send-keep alives. There may not be >>many use-cases (someone mentioned a PBX connection point acting as a >>proxy), but there is no reason to forbid it. UAs and proxies can use the >>same procedures. > >Yeah I was worried you'd say that. :) > >I think that's a dangerous assumption. The Proxy may not be able to suppo= rt keep-alive on that Proxy-Proxy connection/side, while it can for the UA-= Proxy side. Believing some lower Via isn't safe. I am not sure I understand. If the proxy wants to receive keep-alives on the UA-Proxy side, it inserts = a "yes" parameter value (or, the frequency, if we choose that alternative) = in the keep paramter inserted by the UA. in its Via parameter If the proxy wants to send keep-alives towards the next hop proxy, it inser= ts a keep paramter in its own Via header. So, there are two different procedures for indicating willingness to send a= nd received. >What should really happen is the Proxy should add a keep param (without "y= es") in ITS Via header, so that the downstream Proxy getting it can add a "= yes" to that Via, for that connection. In other words, all the logic shoul= d be about top-most Via's. That is how it works. If you are willing to receive, you insert "yes" in th= e Via of the previous hop (if it contains "keep", or course). If you are wi= lling to send, you insert "keep" in your OWN Via. Regards, Christer= From brett@broadsoft.com Wed May 26 08:19:41 2010 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 9653D3A67F4 for ; Wed, 26 May 2010 08:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 wOktc07dItbP for ; Wed, 26 May 2010 08:19:38 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 2B3843A679C for ; Wed, 26 May 2010 08:19:38 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 26 May 2010 08:19:29 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" Date: Wed, 26 May 2010 08:18:26 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr82CmmyFW+RSuGSfGzZV0ziV/kggACmxOw Message-ID: <747A6506A991724FB09B129B79D5FEB61481797BB1@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB614816DD14F@EXMBXCLUS01.citservers.local> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 15:19:41 -0000 You and I know where our disagreement is concerning what the draft mandates= . We are still waiting to hear for Paul, Christer, and Gonzalo concerning = how to interpret the following quote. "When checking for glare situations, UAs MUST treat every UPDATE request as= if it contained an offer." > I guess the key for this divarication here is still about=20 > the different understanding of the semantics of "checking=20 > for glare situations". If it is only applied in happened=20 > glare situations, it would not be a problem.=20 How can you only apply "checking for glare situations" during a glare situa= tion? Checking for offer/answer glare is part of normal RFC3311 UPDATE processing= . RFC3311 section 5.2: "If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds." > To make the two understanding's merit and disadvantage clear,=20 > I'd like to say one disadvantage for the understanding you showed:=20 > If the rules is for all target refresh request without O/A, it=20 > really forbid some behaviors which is lawful once. No matter how=20 > much behavior would be affected, it would be a real and remarkable=20 > compatible interworking problem.=20 I agree. That is why I'm trying to understand what the draft mandates or a= ttempted to mandate. > So, urgency here is about the understanding of the semantics of=20 > "checking for glare situations".=20 I agree. > And I'd like to hear your comments about the cases mentioned under=20 > my understanding "checking for glare situations". I don't know how to reconcile your interpretation with the RFC3311 section = 5.2 snippet checking for offer/answer glare (shown above). From christer.holmberg@ericsson.com Wed May 26 08:31:23 2010 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 DDB9C3A69B3 for ; Wed, 26 May 2010 08:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_20=-0.74, J_CHICKENPOX_43=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 LjJByB65qKXk for ; Wed, 26 May 2010 08:31:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C57403A6988 for ; Wed, 26 May 2010 08:31:19 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-c7-4bfd3ebd529f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D0.93.21861.DBE3DFB4; Wed, 26 May 2010 17:31:09 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 26 May 2010 17:31:08 +0200 From: Christer Holmberg To: Hadriel Kaplan , SIPCORE Date: Wed, 26 May 2010 17:31:07 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJjxHIwgAASUeA= Message-ID: References: , <430FC6BDED356B4C8498F634416644A91C13B8A32D@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A32D@mail> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 15:31:23 -0000 Hi, >Technical comments/questions: > >1) Why does the Proxy insert the keep in the forwarded Request, vs. just t= he response(s)? See my reply to your other mail. The proxy inserts "keep" in itw own Via to indicate willingess to SEND keep= -alives towards the adjacent upstream hop. The proxy inserts "=3Dyes" in the Via of the adjacent downstream hop to ind= iciate willingness to RECEIVE keep-alives from that hop. >2) You note that a keep=3Dyes in any response to a request means the next-= hop can handle keep. Does this mean a Proxy can send it in a 100 Trying? = If so (and I assume it should be so), then the Proxy really needs to add th= e "yes" to responses, not forwarded requests I think. That's a good point. We can change that. The only reason it currently adds "=3Dyes" to the request is because I thou= ght it is alligned with the received parameter. There is really no technica= l reason to do so, because it is the adjacent downstream entity that needs = the information. >3) You use the phrase "within a registration" a lot. I assume this means = for the lifetime of the Registration binding (as opposed to say the duratio= n of the REGISTER transaction, between the request and final response). Correct. >So does this mean that a REGISTER refresh (i.e., same call-id) does or doe= s not re-negotiate keep? I think it must, since a real Proxy doesn't reall= y know whether a REGISTER is a refresh vs. a new one. That's a good point. I will think a little about it, but if you're right th= e keep-alive would have to be re-negotiated in registration refreshes.=20 That should not be a big problem, though, as registration re-refreshes don'= t happen that occur (especially since one will not have to use them for kee= p-alives anymore). >4) Section 4.2.1 states: > "The scope of the negotiated keep-alives depends on what SIP request meth= ods are used for the keep-alive negotiation." >I don't think you want to make it method-specific in the draft, except for= maybe REGISTER. But other than REGISTER, any dialog-forming or in-dialog = request affects the keep for the duration of the dialog. The text DO talk about initial requests for dialogs, and mid-dialog target = refresh requests. It does not talk about methods for dialog keep-alives. So= , the text you refer to probably needs to be modified. Maybe it should say = "what type of SIP requests are used for...". >Any out-of-dialog, non-dialog-forming Request other than REGISTER would pr= esumably have no impact. I mention this because an out-of-dialog MESSAGE o= r PUBLISH would have no bearing on keep I guess, but those same methods in-= dialog could negotiate keep (as I read the current text in the draft). Correct. It would probably be good to mention that also. >5) Section 4.2.1 states: > "The sending and receiving of keep-alives can be negotiated when a > registration or dialog is initiated, or later during the registration > or dialog. However, once a SIP entity has negotiated the sending of > keep-alives within a registration or dialog, it can not re-negotiate > the sending of keep-alives within the same registration or dialog. > Likewise, once a SIP entity has indicated willingness to receive > keep-alives within a registration or dialog, it MUST NOT indicate > willingness to receive keep-alives in a response to a subsequent > request within that registration or dialog." > Why is there that last sentence's restriction? Maybe we don't need the sentence, becuase it should not receive a keep para= mter within the dialog in the first place. Based on your previous comment about proxies not knowing whether a REGISTER= is a refresh or not, for registrations we probably need to say that it MUS= T indicate willingness to receive also for registration refreshes. Regards, Christer= From christer.holmberg@ericsson.com Wed May 26 08:33:46 2010 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 9F19C3A6837 for ; Wed, 26 May 2010 08:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=-0.339, 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 3FjDJEQawUXI for ; Wed, 26 May 2010 08:33:41 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 572AA3A69C1 for ; Wed, 26 May 2010 08:33:30 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-71-4bfd3f409efa Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 90.D3.21861.04F3DFB4; Wed, 26 May 2010 17:33:20 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 26 May 2010 17:33:20 +0200 From: Christer Holmberg To: Brett Tate , "gao.yang2@zte.com.cn" Date: Wed, 26 May 2010 17:31:20 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr82CmmyFW+RSuGSfGzZV0ziV/kggACmxOwAAF5+qk= Message-ID: References: <747A6506A991724FB09B129B79D5FEB614816DD14F@EXMBXCLUS01.citservers.local> , <747A6506A991724FB09B129B79D5FEB61481797BB1@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61481797BB1@EXMBXCLUS01.citservers.local> 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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 15:33:46 -0000 Hi, Just to let you know, Gonzalo is out of office this and next week, with lim= ited access to his e-mail, so I doubt you will get his opinion before he is= back. I tried earlier to explain earlier how I understand the quote, but based on= the previous replies I need to do some more reading. Regards, Christer ________________________________________ From: Brett Tate [brett@broadsoft.com] Sent: Wednesday, May 26, 2010 6:18 PM To: gao.yang2@zte.com.cn Cc: Christer Holmberg; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE wit= hout SDP You and I know where our disagreement is concerning what the draft mandates= . We are still waiting to hear for Paul, Christer, and Gonzalo concerning = how to interpret the following quote. "When checking for glare situations, UAs MUST treat every UPDATE request as= if it contained an offer." > I guess the key for this divarication here is still about > the different understanding of the semantics of "checking > for glare situations". If it is only applied in happened > glare situations, it would not be a problem. How can you only apply "checking for glare situations" during a glare situa= tion? Checking for offer/answer glare is part of normal RFC3311 UPDATE processing= . RFC3311 section 5.2: "If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds." > To make the two understanding's merit and disadvantage clear, > I'd like to say one disadvantage for the understanding you showed: > If the rules is for all target refresh request without O/A, it > really forbid some behaviors which is lawful once. No matter how > much behavior would be affected, it would be a real and remarkable > compatible interworking problem. I agree. That is why I'm trying to understand what the draft mandates or a= ttempted to mandate. > So, urgency here is about the understanding of the semantics of > "checking for glare situations". I agree. > And I'd like to hear your comments about the cases mentioned under > my understanding "checking for glare situations". I don't know how to reconcile your interpretation with the RFC3311 section = 5.2 snippet checking for offer/answer glare (shown above).= From HKaplan@acmepacket.com Wed May 26 08:33:58 2010 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 C03ED3A66B4 for ; Wed, 26 May 2010 08:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, J_CHICKENPOX_34=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 1QOFZaJ-ZTNr for ; Wed, 26 May 2010 08:33:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3FB123A6888 for ; Wed, 26 May 2010 08:33:55 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 26 May 2010 11:33:45 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 26 May 2010 11:33:45 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , SIPCORE Date: Wed, 26 May 2010 11:33:43 -0400 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGwgAH0Y8CAAAPY0IAABpeggAAJaVOAAAPh4A== Message-ID: <430FC6BDED356B4C8498F634416644A91C13B8A35B@mail> References: , <430FC6BDED356B4C8498F634416644A91C13B8A302@mail> , <430FC6BDED356B4C8498F634416644A91C13B8A336@mail> 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 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 15:33:58 -0000 Ahh, sorry for the confusion. It occurs to me I didn't ask the question co= rrectly the first time, which resulted in us talking about different things= . In the current draft, I believe that a Proxy inserts the "yes" value for th= e keep of the Via it receives from the UA, in the *forwarded request* it se= nds onwards. My question is why is that done, instead of just inserting "y= es" in the response(s). In other words, why is this done: Alice P1 REGISTRAR | | | |--- REGISTER------------->| | | Via: UAC;keep | | | |--- REGISTER-------------->| | | Via: P1;keep | | | Via: UAC;keep=3Dyes | | | | | |<-- 200 OK ----------------| | | Via: P1;keep=3Dyes | | | Via: UAC;keep=3Dyes | |<-- 200 OK ---------------| | | Via: UAC;keep=3Dyes | | | Flow-Timer: 30 | | Instead of this: Alice P1 REGISTRAR | | | |--- REGISTER------------->| | | Via: UAC;keep | | | |--- REGISTER-------------->| | | Via: P1;keep | | | Via: UAC;keep | | | | | |<-- 200 OK ----------------| | | Via: P1;keep=3Dyes | | | Via: UAC;keep | |<-- 200 OK ---------------| | | Via: UAC;keep=3Dyes | | | Flow-Timer: 30 | | > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, May 26, 2010 11:15 AM > To: Hadriel Kaplan; Elwell, John; SIPCORE > Subject: RE: Draft new version: draft-ietf-sipcore-keep-03 >=20 > Hi, >=20 > >>>Regardless, I'm not sure why the Proxy inserts the keep in the > forwarded > >>Request, instead of just in the response(s)? > > > >>In case it wants to indicate to ITS adjacent upstream entity (maybe > >>another proxy) that it is willing to send-keep alives. There may not be > >>many use-cases (someone mentioned a PBX connection point acting as a > >>proxy), but there is no reason to forbid it. UAs and proxies can use th= e > >>same procedures. > > > >Yeah I was worried you'd say that. :) > > > >I think that's a dangerous assumption. The Proxy may not be able to > support keep-alive on that Proxy-Proxy connection/side, while it can for > the UA-Proxy side. Believing some lower Via isn't safe. >=20 > I am not sure I understand. >=20 > If the proxy wants to receive keep-alives on the UA-Proxy side, it insert= s > a "yes" parameter value (or, the frequency, if we choose that alternative= ) > in the keep paramter inserted by the UA. in its Via parameter >=20 > If the proxy wants to send keep-alives towards the next hop proxy, it > inserts a keep paramter in its own Via header. >=20 > So, there are two different procedures for indicating willingness to send > and received. >=20 > >What should really happen is the Proxy should add a keep param (without > "yes") in ITS Via header, so that the downstream Proxy getting it can add > a "yes" to that Via, for that connection. In other words, all the logic > should be about top-most Via's. >=20 > That is how it works. If you are willing to receive, you insert "yes" in > the Via of the previous hop (if it contains "keep", or course). If you ar= e > willing to send, you insert "keep" in your OWN Via. >=20 > Regards, >=20 > Christer From pkyzivat@cisco.com Wed May 26 08:53:37 2010 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 A25D13A67DB for ; Wed, 26 May 2010 08:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 rNF90k-IjSeb for ; Wed, 26 May 2010 08:53:36 -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 800BE3A66B4 for ; Wed, 26 May 2010 08:53:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALvg/EtAZnwM/2dsb2JhbACeHXGoGJoBhRME X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="115047632" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 May 2010 15:53:27 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QFrReA006390; Wed, 26 May 2010 15:53:27 GMT Message-ID: <4BFD43FE.4040503@cisco.com> Date: Wed, 26 May 2010 11:53:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brett Tate References: <747A6506A991724FB09B129B79D5FEB614816DD14F@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB61481797BB1@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61481797BB1@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 15:53:37 -0000 Brett, I'm aware. I got behind, and need to read through a whole bunch of messages carefully before I can comment meaningfully. Because of the backlog I now need some unbroken time to study all those, and haven't been able to steal it from my day job yet. My general (tentative) feeling right now is that the requirement in -reinvite- to treat UPDATEs as if they contained an offer is problematic. It may be necessary to spell out explicitly the desired behavior rather than doing so indirectly like this. Thanks, Paul Brett Tate wrote: > You and I know where our disagreement is concerning what the draft mandates. We are still waiting to hear for Paul, Christer, and Gonzalo concerning how to interpret the following quote. > > "When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer." > >> I guess the key for this divarication here is still about >> the different understanding of the semantics of "checking >> for glare situations". If it is only applied in happened >> glare situations, it would not be a problem. > > How can you only apply "checking for glare situations" during a glare situation? > > Checking for offer/answer glare is part of normal RFC3311 UPDATE processing. > > RFC3311 section 5.2: > > "If an UPDATE is received that contains an offer, and the UAS has > generated an offer (in an UPDATE, PRACK or INVITE) to which it has > not yet received an answer, the UAS MUST reject the UPDATE with a 491 > response. Similarly, if an UPDATE is received that contains an > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > INVITE) to which it has not yet generated an answer, the UAS MUST > reject the UPDATE with a 500 response, and MUST include a Retry-After > header field with a randomly chosen value between 0 and 10 seconds." > >> To make the two understanding's merit and disadvantage clear, >> I'd like to say one disadvantage for the understanding you showed: >> If the rules is for all target refresh request without O/A, it >> really forbid some behaviors which is lawful once. No matter how >> much behavior would be affected, it would be a real and remarkable >> compatible interworking problem. > > I agree. That is why I'm trying to understand what the draft mandates or attempted to mandate. > >> So, urgency here is about the understanding of the semantics of >> "checking for glare situations". > > I agree. > >> And I'd like to hear your comments about the cases mentioned under >> my understanding "checking for glare situations". > > I don't know how to reconcile your interpretation with the RFC3311 section 5.2 snippet checking for offer/answer glare (shown above). > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed May 26 11:43:13 2010 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 619953A6983 for ; Wed, 26 May 2010 11:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, J_CHICKENPOX_34=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 phcX8G1Hjaf9 for ; Wed, 26 May 2010 11:43:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B946F3A68D6 for ; Wed, 26 May 2010 11:43:11 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-83-4bfd6bb5b5fb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 61.73.06817.5BB6DFB4; Wed, 26 May 2010 20:43:01 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 26 May 2010 20:43:01 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Elwell, John" , SIPCORE Date: Wed, 26 May 2010 20:38:54 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGwgAH0Y8CAAAPY0IAABpeggAAJaVOAAAPh4IAANSLS Message-ID: References: , <430FC6BDED356B4C8498F634416644A91C13B8A302@mail> , <430FC6BDED356B4C8498F634416644A91C13B8A336@mail> , <430FC6BDED356B4C8498F634416644A91C13B8A35B@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91C13B8A35B@mail> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 18:43:13 -0000 Hi, >Ahh, sorry for the confusion. It occurs to me I didn't ask the question c= orrectly the first time, which resulted in us talking about different thing= s. > >In the current draft, I believe that a Proxy inserts the "yes" value for t= he keep of the Via it receives from the UA, in the *forwarded request* it s= ends onwards. My question is why is that done, instead of just inserting "= yes" in the response(s). As I said earlier, I can insert it in the response. It doesn't need to be i= n the request. I just thought that since the proxy anyway might insert the = received parameter in the request, it could as well insert "=3Dyes" at the = same time. But, if it confuses readers of the draft we can change it, and specify that= "=3Dyes" is inserted in the response. It would work even for transaction s= tateless proxies, since the "keep" parameter of the UA will be in the respo= nse. Regards, Christer In other words, why is this done: Alice P1 REGISTRAR | | | |--- REGISTER------------->| | | Via: UAC;keep | | | |--- REGISTER-------------->| | | Via: P1;keep | | | Via: UAC;keep=3Dyes | | | | | |<-- 200 OK ----------------| | | Via: P1;keep=3Dyes | | | Via: UAC;keep=3Dyes | |<-- 200 OK ---------------| | | Via: UAC;keep=3Dyes | | | Flow-Timer: 30 | | Instead of this: Alice P1 REGISTRAR | | | |--- REGISTER------------->| | | Via: UAC;keep | | | |--- REGISTER-------------->| | | Via: P1;keep | | | Via: UAC;keep | | | | | |<-- 200 OK ----------------| | | Via: P1;keep=3Dyes | | | Via: UAC;keep | |<-- 200 OK ---------------| | | Via: UAC;keep=3Dyes | | | Flow-Timer: 30 | | > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, May 26, 2010 11:15 AM > To: Hadriel Kaplan; Elwell, John; SIPCORE > Subject: RE: Draft new version: draft-ietf-sipcore-keep-03 > > Hi, > > >>>Regardless, I'm not sure why the Proxy inserts the keep in the > forwarded > >>Request, instead of just in the response(s)? > > > >>In case it wants to indicate to ITS adjacent upstream entity (maybe > >>another proxy) that it is willing to send-keep alives. There may not be > >>many use-cases (someone mentioned a PBX connection point acting as a > >>proxy), but there is no reason to forbid it. UAs and proxies can use th= e > >>same procedures. > > > >Yeah I was worried you'd say that. :) > > > >I think that's a dangerous assumption. The Proxy may not be able to > support keep-alive on that Proxy-Proxy connection/side, while it can for > the UA-Proxy side. Believing some lower Via isn't safe. > > I am not sure I understand. > > If the proxy wants to receive keep-alives on the UA-Proxy side, it insert= s > a "yes" parameter value (or, the frequency, if we choose that alternative= ) > in the keep paramter inserted by the UA. in its Via parameter > > If the proxy wants to send keep-alives towards the next hop proxy, it > inserts a keep paramter in its own Via header. > > So, there are two different procedures for indicating willingness to send > and received. > > >What should really happen is the Proxy should add a keep param (without > "yes") in ITS Via header, so that the downstream Proxy getting it can add > a "yes" to that Via, for that connection. In other words, all the logic > should be about top-most Via's. > > That is how it works. If you are willing to receive, you insert "yes" in > the Via of the previous hop (if it contains "keep", or course). If you ar= e > willing to send, you insert "keep" in your OWN Via. > > Regards, > > Christer= From christer.holmberg@ericsson.com Wed May 26 12:07:39 2010 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 2CDA63A698E for ; Wed, 26 May 2010 12:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=-0.274, 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 iGf2rsncjuT7 for ; Wed, 26 May 2010 12:07:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 039EC3A6999 for ; Wed, 26 May 2010 12:07:36 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-b6-4bfd716e1b0c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4F.84.06817.E617DFB4; Wed, 26 May 2010 21:07:27 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 26 May 2010 21:07:26 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 26 May 2010 21:07:26 +0200 From: Christer Holmberg To: Paul Kyzivat , Brett Tate Date: Wed, 26 May 2010 21:07:25 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr865kKsFe/GCrJToihdUqW6FOk8wAGebUY Message-ID: References: <747A6506A991724FB09B129B79D5FEB614816DD14F@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB61481797BB1@EXMBXCLUS01.citservers.local>, <4BFD43FE.4040503@cisco.com> In-Reply-To: <4BFD43FE.4040503@cisco.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-Brightmail-Tracker: AAAAAA== Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 19:07:39 -0000 Hi, Isn't what the text is trying to say the following: "When you are about to send an UPDATE, or when you receive an UPDATE, you s= hall apply the glare checking rules as if the UPDATE would contain an SDP o= ffer." So, it means you can only send an empty UPDATE if you in the same situation= were able to send an UPDATE with an offer. And, it means that you do whatever you would do if you have sent an UPDATE = with an offer, and a glare situation occurs. I am not sure what is meant by "while being in a glare situation". I guess = it means "while being in a situation where a glare could occur", or somethi= ng like that. But, these are just some unreliable provisional thoughts - I still need to = do further reading of the document. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Wednesday, May 26, 2010 6:53 PM To: Brett Tate Cc: gao.yang2@zte.com.cn; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE wit= hout SDP Brett, I'm aware. I got behind, and need to read through a whole bunch of messages carefully before I can comment meaningfully. Because of the backlog I now need some unbroken time to study all those, and haven't been able to steal it from my day job yet. My general (tentative) feeling right now is that the requirement in -reinvite- to treat UPDATEs as if they contained an offer is problematic. It may be necessary to spell out explicitly the desired behavior rather than doing so indirectly like this. Thanks, Paul Brett Tate wrote: > You and I know where our disagreement is concerning what the draft mandat= es. We are still waiting to hear for Paul, Christer, and Gonzalo concernin= g how to interpret the following quote. > > "When checking for glare situations, UAs MUST treat every UPDATE request = as if it contained an offer." > >> I guess the key for this divarication here is still about >> the different understanding of the semantics of "checking >> for glare situations". If it is only applied in happened >> glare situations, it would not be a problem. > > How can you only apply "checking for glare situations" during a glare sit= uation? > > Checking for offer/answer glare is part of normal RFC3311 UPDATE processi= ng. > > RFC3311 section 5.2: > > "If an UPDATE is received that contains an offer, and the UAS has > generated an offer (in an UPDATE, PRACK or INVITE) to which it has > not yet received an answer, the UAS MUST reject the UPDATE with a 491 > response. Similarly, if an UPDATE is received that contains an > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > INVITE) to which it has not yet generated an answer, the UAS MUST > reject the UPDATE with a 500 response, and MUST include a Retry-After > header field with a randomly chosen value between 0 and 10 seconds." > >> To make the two understanding's merit and disadvantage clear, >> I'd like to say one disadvantage for the understanding you showed: >> If the rules is for all target refresh request without O/A, it >> really forbid some behaviors which is lawful once. No matter how >> much behavior would be affected, it would be a real and remarkable >> compatible interworking problem. > > I agree. That is why I'm trying to understand what the draft mandates or= attempted to mandate. > >> So, urgency here is about the understanding of the semantics of >> "checking for glare situations". > > I agree. > >> And I'd like to hear your comments about the cases mentioned under >> my understanding "checking for glare situations". > > I don't know how to reconcile your interpretation with the RFC3311 sectio= n 5.2 snippet checking for offer/answer glare (shown above). > > _______________________________________________ > 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 gao.yang2@zte.com.cn Wed May 26 18:29:49 2010 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 05AE83A680A for ; Wed, 26 May 2010 18:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.061 X-Spam-Level: X-Spam-Status: No, score=-96.061 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_40=-0.185, FRT_SLUT=2.522, 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 oZWkihtWO2-v for ; Wed, 26 May 2010 18:29:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 291133A6767 for ; Wed, 26 May 2010 18:29:46 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Thu, 27 May 2010 09:23:03 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.5222410540; Thu, 27 May 2010 09:29:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4R1TCFZ091419; Thu, 27 May 2010 09:29:12 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <747A6506A991724FB09B129B79D5FEB61481797BB1@EXMBXCLUS01.citservers.local> To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 27 May 2010 09:26:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-27 09:29:03, Serialize complete at 2010-05-27 09:29:03 Content-Type: multipart/alternative; boundary="=_alternative 00081F6748257730_=" X-MAIL: mse2.zte.com.cn o4R1TCFZ091419 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 01:29:49 -0000 This is a multipart message in MIME format. --=_alternative 00081F6748257730_= Content-Type: text/plain; charset="US-ASCII" > How can you only apply "checking for glare situations" during a > glare situation? > > Checking for offer/answer glare is part of normal RFC3311 UPDATE processing. Making two analyzers in series as: ---> analyzer1 -----> analyzer2 ----> analyzer1 using the rules in RFC3311, and if there's glares case under it's rule, send 491 or (500+retry) directly; analyzer2 using the rules in the draft. analyzer2 also has two process: 1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If it can do so, pass the UPDATE to the next step normally; 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as if it contains Offer and using O/A rules to reject. The effected cases/siutation is only these cases/situation which are ambiguous before the draft. -------------------------------------------------------- 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 00081F6748257730_= Content-Type: text/html; charset="US-ASCII"

> How can you only apply "checking for glare situations" during a
> glare situation?
>
> Checking for offer/answer glare is part of normal RFC3311 UPDATE processing.

Making two analyzers in series as:

---> analyzer1 -----> analyzer2 ---->

analyzer1 using the rules in RFC3311, and if there's glares case under it's rule, send 491 or (500+retry) directly;
analyzer2 using the rules in the draft.

analyzer2 also has two process:
1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If it can do so, pass the UPDATE to the next step normally;
2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as if it contains Offer and using O/A rules to reject.

The effected cases/siutation is only these cases/situation which are ambiguous before the draft. 

--------------------------------------------------------
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 00081F6748257730_=-- From christer.holmberg@ericsson.com Thu May 27 02:51:51 2010 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 0D0B83A67AF for ; Thu, 27 May 2010 02:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_40=-0.185, 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 Lkh9bSCuvX+G for ; Thu, 27 May 2010 02:51:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8A79C3A68C0 for ; Thu, 27 May 2010 02:51:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7b73ae00000711c-49-4bfe40aad476 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 95.59.28956.AA04EFB4; Thu, 27 May 2010 11:51:39 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 27 May 2010 11:51:38 +0200 From: Christer Holmberg To: "gao.yang2@zte.com.cn" , Brett Tate Date: Thu, 27 May 2010 11:51:38 +0200 Thread-Topic: New deal [ was [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] Thread-Index: AQHK/YIzIec3lwaSDkq6NBhc86zKcg== 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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 May 2010 09:51:51 -0000 Below are some questions/ideas on how I think we could solve most issues. S= ome of the stuff shall be seen more as brain storming than actual proposal = at this point. I am fully aware that some of the ideas for sure may limit what is said in = RFCs etc, so you don't need to tell me about that. IDEA #1: Offer/answer: Usage of SDP o=3D version parameter I know this has been discussed at some point, but what is the reason we can= 't use the SDP o=3D version parameter to determine in which order the UAS h= as sent SDPs? I believe it would solve offer/answer glare situations where the UAC does n= ot known in which order the UAS has sent SDPs. That should not be controversial, and does not break any RFC etc. IDEA #2: Target update: Only outside re-INVITEs Let's forbid target updates "inside" re-INVITEs. I really doubt there is a = need for those while the UAs are doing something else with the re-INVITE. That at least solves the glare situation where the remote target may be upd= ated in a re-INVITE response and an UPDATE response. IDEA #3: UPDATE: Always use re-INVITE glare rules Let's not allow more than one outstanding UPDATE. Ie if a UA has sent an UP= DATE (with or without SDP), and receives another UPDATE request before the = answer, it rejects it (same rule as for re-INVITE). That would at least solve the problem where a UA sends an UPDATE, receives = a 200 OK and a UPDATE request, both with different target information. Ok, let the tomatoes fly... ...and let me know if there are any issues which the ideas above do NOT sol= ve. I have some more ideas, but I am not sure they are needed so I'll them = to myself for now :) Regards, Christer From gao.yang2@zte.com.cn Thu May 27 04:22:27 2010 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 281113A6AB5 for ; Thu, 27 May 2010 04:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.035 X-Spam-Level: X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 zHLm4uwS79Xp for ; Thu, 27 May 2010 04:22:23 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2C6C63A6AB6 for ; Thu, 27 May 2010 04:22:13 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Thu, 27 May 2010 19:16:38 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 74652.5222410540; Thu, 27 May 2010 19:16:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4RBM91k072926; Thu, 27 May 2010 19:22:09 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Christer Holmberg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 27 May 2010 19:19:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-27 19:21:48, Serialize complete at 2010-05-27 19:21:48 Content-Type: multipart/alternative; boundary="=_alternative 003E63AA48257730_=" X-MAIL: mse2.zte.com.cn o4RBM91k072926 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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 May 2010 11:22:27 -0000 This is a multipart message in MIME format. --=_alternative 003E63AA48257730_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Q2hyaXN0ZXIsDQoNCkFzIEkgdGhpbmsgc2VjdGlvbnMgMy41IGFuZCA0LjUgb2YgdGhlIGRyYWZ0 IGNhbiBzb2x2ZSB0aGUgcHJvYmxlbSBhbmQgDQpoYXZpbmcgbm8gbW9yZSBlZmZlY3RzIG9uIGN1 cnJlbnQgUkZDcywgSSdkIGxpa2UgdG8gZm9jdXMgb24gdGhlIGN1cnJlbnQgDQp0ZXh0LiANCg0K WW91IGNhbiByZWZlciB0byB0aGUgaW50ZXJwcmV0YXRpb24gaW46DQoNCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDI3ODguaHRtbA0KDQpU aGlzIGlzIGp1c3Qgb25lIHJlZmVyZW5jZWQgaW1wbGVtZW50YXRpb24gdG8gcHJvdmUgdGhhdCBz ZWN0aW9ucyAzLjUgYW5kIA0KNC41IGlzIHZpYWJsZSwgYW5kIEkgdGhpbmsgdGhlcmUgbWlnaHQg YmUgb3RoZXIgaW1wbGVtZW50YXRpb24gd2F5cyBmb3IgDQp0aGUgdHdvIHNlY3Rpb25zLg0KDQpS ZWdhcmRzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBa aXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3 MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQoNCg0KDQpDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPiANCreivP7IyzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KMjAx MC0wNS0yNyAxNzo1MQ0KDQrK1bz+yMsNCiJnYW8ueWFuZzJAenRlLmNvbS5jbiIgPGdhby55YW5n MkB6dGUuY29tLmNuPiwgQnJldHQgVGF0ZSANCjxicmV0dEBicm9hZHNvZnQuY29tPg0Ks63LzQ0K InNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3JlQGlldGYub3JnPg0K1vfM4g0KW3NpcGNvcmVdIE5l dyBkZWFsIFsgd2FzIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNDogZ2xhcmUgYW5kIFVQ REFURSANCndpdGhvdXQgU0RQXQ0KDQoNCg0KDQoNCg0KDQpCZWxvdyBhcmUgc29tZSBxdWVzdGlv bnMvaWRlYXMgb24gaG93IEkgdGhpbmsgd2UgY291bGQgc29sdmUgbW9zdCBpc3N1ZXMuIA0KU29t ZSBvZiB0aGUgc3R1ZmYgc2hhbGwgYmUgc2VlbiBtb3JlIGFzIGJyYWluIHN0b3JtaW5nIHRoYW4g YWN0dWFsIA0KcHJvcG9zYWwgYXQgdGhpcyBwb2ludC4NCg0KSSBhbSBmdWxseSBhd2FyZSB0aGF0 IHNvbWUgb2YgdGhlIGlkZWFzIGZvciBzdXJlIG1heSBsaW1pdCB3aGF0IGlzIHNhaWQgaW4gDQpS RkNzIGV0Yywgc28geW91IGRvbid0IG5lZWQgdG8gdGVsbCBtZSBhYm91dCB0aGF0Lg0KDQoNCg0K DQpJREVBICMxOiAgT2ZmZXIvYW5zd2VyOiBVc2FnZSBvZiBTRFAgbz0gdmVyc2lvbiBwYXJhbWV0 ZXINCg0KSSBrbm93IHRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGF0IHNvbWUgcG9pbnQsIGJ1dCB3 aGF0IGlzIHRoZSByZWFzb24gd2UgDQpjYW4ndCB1c2UgdGhlIFNEUCBvPSB2ZXJzaW9uIHBhcmFt ZXRlciB0byBkZXRlcm1pbmUgaW4gd2hpY2ggb3JkZXIgdGhlIFVBUyANCmhhcyBzZW50IFNEUHM/ DQoNCkkgYmVsaWV2ZSBpdCB3b3VsZCBzb2x2ZSBvZmZlci9hbnN3ZXIgZ2xhcmUgc2l0dWF0aW9u cyB3aGVyZSB0aGUgVUFDIGRvZXMgDQpub3Qga25vd24gaW4gd2hpY2ggb3JkZXIgdGhlIFVBUyBo YXMgc2VudCBTRFBzLg0KDQpUaGF0IHNob3VsZCBub3QgYmUgY29udHJvdmVyc2lhbCwgYW5kIGRv ZXMgbm90IGJyZWFrIGFueSBSRkMgZXRjLg0KDQoNCg0KDQpJREVBICMyOiAgIFRhcmdldCB1cGRh dGU6IE9ubHkgb3V0c2lkZSByZS1JTlZJVEVzDQoNCkxldCdzIGZvcmJpZCB0YXJnZXQgdXBkYXRl cyAiaW5zaWRlIiByZS1JTlZJVEVzLiBJIHJlYWxseSBkb3VidCB0aGVyZSBpcyBhIA0KbmVlZCBm b3IgdGhvc2Ugd2hpbGUgdGhlIFVBcyBhcmUgZG9pbmcgc29tZXRoaW5nIGVsc2Ugd2l0aCB0aGUg cmUtSU5WSVRFLg0KDQpUaGF0IGF0IGxlYXN0IHNvbHZlcyB0aGUgZ2xhcmUgc2l0dWF0aW9uIHdo ZXJlIHRoZSByZW1vdGUgdGFyZ2V0IG1heSBiZSANCnVwZGF0ZWQgaW4gYSByZS1JTlZJVEUgcmVz cG9uc2UgYW5kIGFuIFVQREFURSByZXNwb25zZS4NCg0KDQoNCg0KSURFQSAjMzogICAgVVBEQVRF OiBBbHdheXMgdXNlIHJlLUlOVklURSBnbGFyZSBydWxlcw0KDQpMZXQncyBub3QgYWxsb3cgbW9y ZSB0aGFuIG9uZSBvdXRzdGFuZGluZyBVUERBVEUuIEllIGlmIGEgVUEgaGFzIHNlbnQgYW4gDQpV UERBVEUgKHdpdGggb3Igd2l0aG91dCBTRFApLCBhbmQgcmVjZWl2ZXMgYW5vdGhlciBVUERBVEUg cmVxdWVzdCBiZWZvcmUgDQp0aGUgYW5zd2VyLCBpdCByZWplY3RzIGl0IChzYW1lIHJ1bGUgYXMg Zm9yIHJlLUlOVklURSkuDQoNCg0KVGhhdCB3b3VsZCBhdCBsZWFzdCBzb2x2ZSB0aGUgcHJvYmxl bSB3aGVyZSBhIFVBIHNlbmRzIGFuIFVQREFURSwgcmVjZWl2ZXMgDQphIDIwMCBPSyBhbmQgYSBV UERBVEUgcmVxdWVzdCwgYm90aCB3aXRoIGRpZmZlcmVudCB0YXJnZXQgaW5mb3JtYXRpb24uDQoN Cg0KT2ssIGxldCB0aGUgdG9tYXRvZXMgZmx5Li4uDQoNCi4uLmFuZCBsZXQgbWUga25vdyBpZiB0 aGVyZSBhcmUgYW55IGlzc3VlcyB3aGljaCB0aGUgaWRlYXMgYWJvdmUgZG8gTk9UIA0Kc29sdmUu IEkgaGF2ZSBzb21lIG1vcmUgaWRlYXMsIGJ1dCBJIGFtIG5vdCBzdXJlIHRoZXkgYXJlIG5lZWRl ZCBzbyBJJ2xsIA0KdGhlbSB0byBteXNlbGYgZm9yIG5vdyA6KQ0KDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMg bWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92 ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJz Lg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 003E63AA48257730_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNocmlzdGVyLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgSSB0aGluayBzZWN0aW9u cyAzLjUgYW5kIDQuNSBvZiB0aGUNCmRyYWZ0IGNhbiBzb2x2ZSB0aGUgcHJvYmxlbSBhbmQgaGF2 aW5nIG5vIG1vcmUgZWZmZWN0cyBvbiBjdXJyZW50IFJGQ3MsDQpJJ2QgbGlrZSB0byBmb2N1cyBv biB0aGUgY3VycmVudCB0ZXh0LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPllvdSBjYW4gcmVmZXIgdG8gdGhlIGludGVycHJldGF0aW9uDQppbjo8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDI3ODguaHRtbDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhpcyBpcyBq dXN0IG9uZSByZWZlcmVuY2VkIGltcGxlbWVudGF0aW9uDQp0byBwcm92ZSB0aGF0IHNlY3Rpb25z IDMuNSBhbmQgNC41IGlzIHZpYWJsZSwgYW5kIEkgdGhpbmsgdGhlcmUgbWlnaHQgYmUNCm90aGVy IGltcGxlbWVudGF0aW9uIHdheXMgZm9yIHRoZSB0d28gc2VjdGlvbnMuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzLDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJz cDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJy Pg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPreivP7IyzogJm5ic3A7c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDUtMjcgMTc6NTE8L2ZvbnQ+DQo8 dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Z2Fv LnlhbmcyQHp0ZS5jb20uY24mcXVvdDsgJmx0O2dhby55YW5nMkB6dGUuY29tLmNuJmd0OywNCkJy ZXR0IFRhdGUgJmx0O2JyZXR0QGJyb2Fkc29mdC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m cXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+W3NpcGNvcmVdIE5ldyBkZWFsIFsgd2FzIGRyYWZ0LWlldGYtc2lwY29y ZS1yZWludml0ZS0wNDoNCmdsYXJlIGFuZCBVUERBVEUgd2l0aG91dCBTRFBdPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpCZWxv dyBhcmUgc29tZSBxdWVzdGlvbnMvaWRlYXMgb24gaG93IEkgdGhpbmsgd2UgY291bGQgc29sdmUg bW9zdCBpc3N1ZXMuDQpTb21lIG9mIHRoZSBzdHVmZiBzaGFsbCBiZSBzZWVuIG1vcmUgYXMgYnJh aW4gc3Rvcm1pbmcgdGhhbiBhY3R1YWwgcHJvcG9zYWwNCmF0IHRoaXMgcG9pbnQuPGJyPg0KPGJy Pg0KSSBhbSBmdWxseSBhd2FyZSB0aGF0IHNvbWUgb2YgdGhlIGlkZWFzIGZvciBzdXJlIG1heSBs aW1pdCB3aGF0IGlzIHNhaWQNCmluIFJGQ3MgZXRjLCBzbyB5b3UgZG9uJ3QgbmVlZCB0byB0ZWxs IG1lIGFib3V0IHRoYXQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KSURFQSAjMTogJm5i c3A7T2ZmZXIvYW5zd2VyOiBVc2FnZSBvZiBTRFAgbz0gdmVyc2lvbiBwYXJhbWV0ZXI8YnI+DQo8 YnI+DQpJIGtub3cgdGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgYXQgc29tZSBwb2ludCwgYnV0IHdo YXQgaXMgdGhlIHJlYXNvbiB3ZQ0KY2FuJ3QgdXNlIHRoZSBTRFAgbz0gdmVyc2lvbiBwYXJhbWV0 ZXIgdG8gZGV0ZXJtaW5lIGluIHdoaWNoIG9yZGVyIHRoZQ0KVUFTIGhhcyBzZW50IFNEUHM/PGJy Pg0KPGJyPg0KSSBiZWxpZXZlIGl0IHdvdWxkIHNvbHZlIG9mZmVyL2Fuc3dlciBnbGFyZSBzaXR1 YXRpb25zIHdoZXJlIHRoZSBVQUMgZG9lcw0Kbm90IGtub3duIGluIHdoaWNoIG9yZGVyIHRoZSBV QVMgaGFzIHNlbnQgU0RQcy48YnI+DQo8YnI+DQpUaGF0IHNob3VsZCBub3QgYmUgY29udHJvdmVy c2lhbCwgYW5kIGRvZXMgbm90IGJyZWFrIGFueSBSRkMgZXRjLjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCklERUEgIzI6ICZuYnNwOyBUYXJnZXQgdXBkYXRlOiBPbmx5IG91dHNpZGUgcmUt SU5WSVRFczxicj4NCjxicj4NCkxldCdzIGZvcmJpZCB0YXJnZXQgdXBkYXRlcyAmcXVvdDtpbnNp ZGUmcXVvdDsgcmUtSU5WSVRFcy4gSSByZWFsbHkgZG91YnQNCnRoZXJlIGlzIGEgbmVlZCBmb3Ig dGhvc2Ugd2hpbGUgdGhlIFVBcyBhcmUgZG9pbmcgc29tZXRoaW5nIGVsc2Ugd2l0aCB0aGUNCnJl LUlOVklURS48YnI+DQo8YnI+DQpUaGF0IGF0IGxlYXN0IHNvbHZlcyB0aGUgZ2xhcmUgc2l0dWF0 aW9uIHdoZXJlIHRoZSByZW1vdGUgdGFyZ2V0IG1heSBiZQ0KdXBkYXRlZCBpbiBhIHJlLUlOVklU RSByZXNwb25zZSBhbmQgYW4gVVBEQVRFIHJlc3BvbnNlLjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCklERUEgIzM6ICZuYnNwOyAmbmJzcDtVUERBVEU6IEFsd2F5cyB1c2UgcmUtSU5WSVRF IGdsYXJlIHJ1bGVzPGJyPg0KPGJyPg0KTGV0J3Mgbm90IGFsbG93IG1vcmUgdGhhbiBvbmUgb3V0 c3RhbmRpbmcgVVBEQVRFLiBJZSBpZiBhIFVBIGhhcyBzZW50IGFuDQpVUERBVEUgKHdpdGggb3Ig d2l0aG91dCBTRFApLCBhbmQgcmVjZWl2ZXMgYW5vdGhlciBVUERBVEUgcmVxdWVzdCBiZWZvcmUN CnRoZSBhbnN3ZXIsIGl0IHJlamVjdHMgaXQgKHNhbWUgcnVsZSBhcyBmb3IgcmUtSU5WSVRFKS48 YnI+DQo8YnI+DQo8YnI+DQpUaGF0IHdvdWxkIGF0IGxlYXN0IHNvbHZlIHRoZSBwcm9ibGVtIHdo ZXJlIGEgVUEgc2VuZHMgYW4gVVBEQVRFLCByZWNlaXZlcw0KYSAyMDAgT0sgYW5kIGEgVVBEQVRF IHJlcXVlc3QsIGJvdGggd2l0aCBkaWZmZXJlbnQgdGFyZ2V0IGluZm9ybWF0aW9uLjxicj4NCjxi cj4NCjxicj4NCk9rLCBsZXQgdGhlIHRvbWF0b2VzIGZseS4uLjxicj4NCjxicj4NCi4uLmFuZCBs ZXQgbWUga25vdyBpZiB0aGVyZSBhcmUgYW55IGlzc3VlcyB3aGljaCB0aGUgaWRlYXMgYWJvdmUg ZG8gTk9UDQpzb2x2ZS4gSSBoYXZlIHNvbWUgbW9yZSBpZGVhcywgYnV0IEkgYW0gbm90IHN1cmUg dGhleSBhcmUgbmVlZGVkIHNvIEknbGwNCnRoZW0gdG8gbXlzZWxmIGZvciBub3cgOik8YnI+DQo8 YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBj b3JlIG1haWxpbmcgbGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJz cDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhp cyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwu Jm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxp Z2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2Fy ZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUm bmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0 byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2Zp bGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25m aWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNw O3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5i c3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJl c3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMm bmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJz cDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNw O0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVz c2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFs Jm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7 c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7Ynkm bmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 003E63AA48257730_=-- From christer.holmberg@ericsson.com Thu May 27 04:33:10 2010 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 DB70C3A6AB1 for ; Thu, 27 May 2010 04:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.042 X-Spam-Level: X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[AWL=-3.135, BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 clF98rhyMb8F for ; Thu, 27 May 2010 04:33:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 91BCE3A6822 for ; Thu, 27 May 2010 04:33:09 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-78-4bfe586a637b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CD.88.06817.B685EFB4; Thu, 27 May 2010 13:32:59 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 27 May 2010 13:32:59 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 27 May 2010 13:32:58 +0200 From: Christer Holmberg To: "gao.yang2@zte.com.cn" Date: Thu, 27 May 2010 13:32:34 +0200 Thread-Topic: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] Thread-Index: Acr9jtllMbKoO00BS7yElFzm9JRB3gAAXOid 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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 May 2010 11:33:10 -0000 SGksDQoNCkF0IGxlYXN0IHRoZSBmaXJzdCBpZGVhIGlzIG5vdGhpbmcgIm5ldyIsIGl0J3MgcGFy dCBvZiBleGlzdGluZyBTRFAuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogZ2FvLnlhbmcyQHp0ZS5jb20uY24gW2dh by55YW5nMkB6dGUuY29tLmNuXQ0KU2VudDogVGh1cnNkYXksIE1heSAyNywgMjAxMCAyOjE5IFBN DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBCcmV0dCBUYXRlOyBzaXBjb3JlQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIE5ldyBkZWFsIFsgd2FzIGRyYWZ0LWlldGYtc2lwY29y ZS1yZWludml0ZS0wNDogZ2xhcmUgYW5kIFVQREFURSB3aXRob3V0IFNEUF0NCg0KDQpDaHJpc3Rl ciwNCg0KQXMgSSB0aGluayBzZWN0aW9ucyAzLjUgYW5kIDQuNSBvZiB0aGUgZHJhZnQgY2FuIHNv bHZlIHRoZSBwcm9ibGVtIGFuZCBoYXZpbmcgbm8gbW9yZSBlZmZlY3RzIG9uIGN1cnJlbnQgUkZD cywgSSdkIGxpa2UgdG8gZm9jdXMgb24gdGhlIGN1cnJlbnQgdGV4dC4NCg0KWW91IGNhbiByZWZl ciB0byB0aGUgaW50ZXJwcmV0YXRpb24gaW46DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDI3ODguaHRtbA0KDQpUaGlzIGlzIGp1c3Qg b25lIHJlZmVyZW5jZWQgaW1wbGVtZW50YXRpb24gdG8gcHJvdmUgdGhhdCBzZWN0aW9ucyAzLjUg YW5kIDQuNSBpcyB2aWFibGUsIGFuZCBJIHRoaW5rIHRoZXJlIG1pZ2h0IGJlIG90aGVyIGltcGxl bWVudGF0aW9uIHdheXMgZm9yIHRoZSB0d28gc2VjdGlvbnMuDQoNClJlZ2FyZHMsDQoNCkdhbw0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KWmlwICAgIDogMjEwMDEyDQpU ZWwgICAgOiA4NzIxMQ0KVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCmVfbWFpbCA6IGdhby55 YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoN CkNocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQq3orz+ yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAxMC0wNS0yNyAxNzo1MQ0KDQoNCsrV vP7Iyw0KICAgICAgICAiZ2FvLnlhbmcyQHp0ZS5jb20uY24iIDxnYW8ueWFuZzJAenRlLmNvbS5j bj4sIEJyZXR0IFRhdGUgPGJyZXR0QGJyb2Fkc29mdC5jb20+DQqzrcvNDQogICAgICAgICJzaXBj b3JlQGlldGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4NCtb3zOINCiAgICAgICAgW3NpcGNvcmVd IE5ldyBkZWFsIFsgd2FzIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNDogZ2xhcmUgYW5k IFVQREFURSB3aXRob3V0IFNEUF0NCg0KDQoNCg0KDQoNCg0KDQpCZWxvdyBhcmUgc29tZSBxdWVz dGlvbnMvaWRlYXMgb24gaG93IEkgdGhpbmsgd2UgY291bGQgc29sdmUgbW9zdCBpc3N1ZXMuIFNv bWUgb2YgdGhlIHN0dWZmIHNoYWxsIGJlIHNlZW4gbW9yZSBhcyBicmFpbiBzdG9ybWluZyB0aGFu IGFjdHVhbCBwcm9wb3NhbCBhdCB0aGlzIHBvaW50Lg0KDQpJIGFtIGZ1bGx5IGF3YXJlIHRoYXQg c29tZSBvZiB0aGUgaWRlYXMgZm9yIHN1cmUgbWF5IGxpbWl0IHdoYXQgaXMgc2FpZCBpbiBSRkNz IGV0Yywgc28geW91IGRvbid0IG5lZWQgdG8gdGVsbCBtZSBhYm91dCB0aGF0Lg0KDQoNCg0KDQpJ REVBICMxOiAgT2ZmZXIvYW5zd2VyOiBVc2FnZSBvZiBTRFAgbz0gdmVyc2lvbiBwYXJhbWV0ZXIN Cg0KSSBrbm93IHRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGF0IHNvbWUgcG9pbnQsIGJ1dCB3aGF0 IGlzIHRoZSByZWFzb24gd2UgY2FuJ3QgdXNlIHRoZSBTRFAgbz0gdmVyc2lvbiBwYXJhbWV0ZXIg dG8gZGV0ZXJtaW5lIGluIHdoaWNoIG9yZGVyIHRoZSBVQVMgaGFzIHNlbnQgU0RQcz8NCg0KSSBi ZWxpZXZlIGl0IHdvdWxkIHNvbHZlIG9mZmVyL2Fuc3dlciBnbGFyZSBzaXR1YXRpb25zIHdoZXJl IHRoZSBVQUMgZG9lcyBub3Qga25vd24gaW4gd2hpY2ggb3JkZXIgdGhlIFVBUyBoYXMgc2VudCBT RFBzLg0KDQpUaGF0IHNob3VsZCBub3QgYmUgY29udHJvdmVyc2lhbCwgYW5kIGRvZXMgbm90IGJy ZWFrIGFueSBSRkMgZXRjLg0KDQoNCg0KDQpJREVBICMyOiAgIFRhcmdldCB1cGRhdGU6IE9ubHkg b3V0c2lkZSByZS1JTlZJVEVzDQoNCkxldCdzIGZvcmJpZCB0YXJnZXQgdXBkYXRlcyAiaW5zaWRl IiByZS1JTlZJVEVzLiBJIHJlYWxseSBkb3VidCB0aGVyZSBpcyBhIG5lZWQgZm9yIHRob3NlIHdo aWxlIHRoZSBVQXMgYXJlIGRvaW5nIHNvbWV0aGluZyBlbHNlIHdpdGggdGhlIHJlLUlOVklURS4N Cg0KVGhhdCBhdCBsZWFzdCBzb2x2ZXMgdGhlIGdsYXJlIHNpdHVhdGlvbiB3aGVyZSB0aGUgcmVt b3RlIHRhcmdldCBtYXkgYmUgdXBkYXRlZCBpbiBhIHJlLUlOVklURSByZXNwb25zZSBhbmQgYW4g VVBEQVRFIHJlc3BvbnNlLg0KDQoNCg0KDQpJREVBICMzOiAgICBVUERBVEU6IEFsd2F5cyB1c2Ug cmUtSU5WSVRFIGdsYXJlIHJ1bGVzDQoNCkxldCdzIG5vdCBhbGxvdyBtb3JlIHRoYW4gb25lIG91 dHN0YW5kaW5nIFVQREFURS4gSWUgaWYgYSBVQSBoYXMgc2VudCBhbiBVUERBVEUgKHdpdGggb3Ig d2l0aG91dCBTRFApLCBhbmQgcmVjZWl2ZXMgYW5vdGhlciBVUERBVEUgcmVxdWVzdCBiZWZvcmUg dGhlIGFuc3dlciwgaXQgcmVqZWN0cyBpdCAoc2FtZSBydWxlIGFzIGZvciByZS1JTlZJVEUpLg0K DQoNClRoYXQgd291bGQgYXQgbGVhc3Qgc29sdmUgdGhlIHByb2JsZW0gd2hlcmUgYSBVQSBzZW5k cyBhbiBVUERBVEUsIHJlY2VpdmVzIGEgMjAwIE9LIGFuZCBhIFVQREFURSByZXF1ZXN0LCBib3Ro IHdpdGggZGlmZmVyZW50IHRhcmdldCBpbmZvcm1hdGlvbi4NCg0KDQpPaywgbGV0IHRoZSB0b21h dG9lcyBmbHkuLi4NCg0KLi4uYW5kIGxldCBtZSBrbm93IGlmIHRoZXJlIGFyZSBhbnkgaXNzdWVz IHdoaWNoIHRoZSBpZGVhcyBhYm92ZSBkbyBOT1Qgc29sdmUuIEkgaGF2ZSBzb21lIG1vcmUgaWRl YXMsIGJ1dCBJIGFtIG5vdCBzdXJlIHRoZXkgYXJlIG5lZWRlZCBzbyBJJ2xsIHRoZW0gdG8gbXlz ZWxmIGZvciBub3cgOikNCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlz dA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXBjb3JlDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRz IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIu DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIHN5c3RlbS4NCg0K From gao.yang2@zte.com.cn Thu May 27 04:47:33 2010 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 7E8FD3A6A91 for ; Thu, 27 May 2010 04:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.641 X-Spam-Level: X-Spam-Status: No, score=-95.641 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 IlKJzDmV42GQ for ; Thu, 27 May 2010 04:47:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 53EF73A6AAC for ; Thu, 27 May 2010 04:47:31 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Thu, 27 May 2010 19:40:45 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 74652.5222410540; Thu, 27 May 2010 19:41:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4RBlaon008180; Thu, 27 May 2010 19:47:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Christer Holmberg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 27 May 2010 19:44:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-27 19:47:15, Serialize complete at 2010-05-27 19:47:15 Content-Type: multipart/alternative; boundary="=_alternative 0040B86948257730_=" X-MAIL: mse2.zte.com.cn o4RBlaon008180 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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 May 2010 11:47:33 -0000 This is a multipart message in MIME format. --=_alternative 0040B86948257730_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Q2hyaXN0ZXIsDQoNCkkganVzdCBtZWFuIHRvIHJlcXVlc3QgeW91IHRvIGV2YWx1YXRlICpteSB1 bmRlcnN0YW5kaW5nKiBvZiBzZWN0aW9ucyAzLjUgDQphbmQgNC41LCB0byBzZWUgd2hldGhlciBp dCBjYW4gc29sdmUgdGhlIHByb2JsZW0uDQoNClRoYW5rcywNCg0KR2FvIA0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3 MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KQ2hyaXN0ZXIg SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g0LTT2iAyMDEwLTA1LTI3 IA0KMTk6MzI6MzQ6DQoNCj4gSGksDQo+IA0KPiBBdCBsZWFzdCB0aGUgZmlyc3QgaWRlYSBpcyBu b3RoaW5nICJuZXciLCBpdCdzIHBhcnQgb2YgZXhpc3RpbmcgU0RQLg0KPiANCj4gUmVnYXJkcywN Cj4gDQo+IENocmlzdGVyDQo+IA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0040B86948257730_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNocmlzdGVyLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBqdXN0IG1lYW4gdG8gcmVx dWVzdCB5b3UgdG8gZXZhbHVhdGUNCipteSB1bmRlcnN0YW5kaW5nKiBvZiBzZWN0aW9ucyAzLjUg YW5kIDQuNSwgdG8gc2VlIHdoZXRoZXIgaXQgY2FuIHNvbHZlDQp0aGUgcHJvYmxlbS48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbyA8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQog VGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4 NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPkNocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20m Z3Q7DQrQtNPaIDIwMTAtMDUtMjcgMTk6MzI6MzQ6PGJyPg0KPGJyPg0KJmd0OyBIaSw8YnI+DQom Z3Q7IDxicj4NCiZndDsgQXQgbGVhc3QgdGhlIGZpcnN0IGlkZWEgaXMgbm90aGluZyAmcXVvdDtu ZXcmcXVvdDssIGl0J3MgcGFydCBvZiBleGlzdGluZw0KU0RQLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBSZWdhcmRzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBDaHJpc3Rlcjxicj4NCiZndDsgPC9mb250 PjwvdHQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0040B86948257730_=-- From john.elwell@siemens-enterprise.com Thu May 27 05:29:47 2010 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 A5EBB3A6AAC for ; Thu, 27 May 2010 05:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_05=-1.11] 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 p2w-EDTHDs90 for ; Thu, 27 May 2010 05:29:47 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9B7973A6A99 for ; Thu, 27 May 2010 05:29:46 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-309708; Thu, 27 May 2010 14:29:36 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id C0B001EB82AB; Thu, 27 May 2010 14:29:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 27 May 2010 14:29:36 +0200 From: "Elwell, John" To: Brett Tate , Christer Holmberg , "sipcore@ietf.org" Date: Thu, 27 May 2010 14:29:35 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP Thread-Index: Acr5C9t3FyhbKFLrTxyAlhmpyy4tDQCGNBigAARXG0AAAVzdQAA/3EogAAByWSAAAbNkUAAAjcVAACIthyAAMj2HYA== Message-ID: References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC310@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DD14F@EXMBXCLUS01.citservers.local> Keywords: SIPCORE In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DD14F@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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 May 2010 12:29:47 -0000 =20 > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com]=20 > Sent: 26 May 2010 13:46 > To: Christer Holmberg; Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare=20 > and UPDATE without SDP >=20 > > So, if you have received an unreliable response, I guess you=20 > > could send an UPDATE. But, why would you want to? You cannot=20 > > include SDP, and I don't believe you can include updated=20 > > target information. >=20 > Prior to draft-ietf-sipcore-reinvite, you could use UPDATE=20 > without SDP to update/communicate things without being=20 > confined to the current offer/answer state. For example,=20 > rfc5876 section 3.2 discusses communicating=20 > P-Asserted-Identity. It can no longer be successfully=20 > communicated within UPDATE over an early dialog (resulting in=20 > 2xx response) unless the called party has sent the answer for=20 > the INVITE's offer SDP. [JRE] That would be a change to RFC 3311 in my opinion. Also the ability to= send PAI if it changes (e.g., due to 3PCC transfer) without waiting for th= e 2xx is, in my opinion, a reasonable current use case. It should be possib= le to do this without using reliable provisional responses (the only way to= get SDP answer, as opposed to just a preview of SDP answer, in a 18x respo= nse). John From shinji.okumura@softfront.jp Thu May 27 05:31:58 2010 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 A80D53A6AAC for ; Thu, 27 May 2010 05:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.268 X-Spam-Level: X-Spam-Status: No, score=-95.268 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 uKVJ0yPuaOhE for ; Thu, 27 May 2010 05:31:54 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 9F6FD3A6AD2 for ; Thu, 27 May 2010 05:31:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 79FBA428018; Thu, 27 May 2010 21:31:44 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWtrcHDW-vX6; Thu, 27 May 2010 21:31:43 +0900 (JST) Received: from softfront.jp (112.136.46.168.er.eaccess.ne.jp [112.136.46.168]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 4D582428017; Thu, 27 May 2010 21:31:42 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Thu, 27 May 2010 21:31:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: References: Message-Id: <16CAFD9892CD8Cshinji.okumura@softfront.jp> Cc: "gao.yang2@zte.com.cn" Subject: Re: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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 May 2010 12:31:58 -0000 Christer, Christer Holmberg Thu, 27 May 2010 11:51:38 +0200 >Below are some questions/ideas on how I think we could solve >most issues. Some of the stuff shall be seen more as brain >storming than actual proposal at this point. > >I am fully aware that some of the ideas for sure may limit >what is said in RFCs etc, so you don't need to tell me >about that. > > > > >IDEA #1: Offer/answer: Usage of SDP o= version parameter > >I know this has been discussed at some point, but what is >the reason we can't use the SDP o= version parameter to >determine in which order the UAS has sent SDPs? > >I believe it would solve offer/answer glare situations where >the UAC does not known in which order the UAS has sent SDPs. > >That should not be controversial, and does not break any RFC >etc. A B | | s0|re-INV (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1| non-2xx|s1 | /------------|<-+ | / ACK |s0| | / ---------->| | | / UPD(offer2)| | |<=============/================| | |2xx(answer2) / | | |============/=================>| | s2| / |s2| |<---------/ |<-+ s0|ACK | |-----------> | | | At least in the above case, o-version seems to be useless for determining the order. I think the o-version of offer2 should be the one of answer1 +1. Even if the UPDATE has the pre-re-INVITE o-version, UA A might be confused by the decrement. Regards, Shinji >IDEA #2: Target update: Only outside re-INVITEs > >Let's forbid target updates "inside" re-INVITEs. I really >doubt there is a need for those while the UAs are doing >something else with the re-INVITE. > >That at least solves the glare situation where the remote >target may be updated in a re-INVITE response and an UPDATE >response. > > > > >IDEA #3: UPDATE: Always use re-INVITE glare rules > >Let's not allow more than one outstanding UPDATE. Ie if a UA >has sent an UPDATE (with or without SDP), and receives >another UPDATE request before the answer, it rejects it >(same rule as for re-INVITE). > > >That would at least solve the problem where a UA sends an >UPDATE, receives a 200 OK and a UPDATE request, both with >different target information. > > >Ok, let the tomatoes fly... > >...and let me know if there are any issues which the ideas >above do NOT solve. I have some more ideas, but I am not >sure they are needed so I'll them to myself for now :) > > >Regards, > >Christer From christer.holmberg@ericsson.com Thu May 27 09:52:35 2010 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 46CE13A6B4F for ; Thu, 27 May 2010 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 F3ECmqe4vrPv for ; Thu, 27 May 2010 09:52:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 286C43A6B36 for ; Thu, 27 May 2010 09:52:33 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-c5-4bfea347a818 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C3.DB.06817.743AEFB4; Thu, 27 May 2010 18:52:23 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 27 May 2010 18:52:22 +0200 From: Christer Holmberg To: OKUMURA Shinji , "sipcore@ietf.org" Date: Thu, 27 May 2010 18:52:22 +0200 Thread-Topic: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] - IDEA #1 Thread-Index: AQHK/bz6a/H6MFEGWk6ryGzQFoi+zg== 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-Brightmail-Tracker: AAAAAA== Cc: "gao.yang2@zte.com.cn" Subject: Re: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] - IDEA #1 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 May 2010 16:52:35 -0000 Hi, >>IDEA #1: Offer/answer: Usage of SDP o=3D version parameter >> >>I know this has been discussed at some point, but what is >>the reason we can't use the SDP o=3D version parameter to >>determine in which order the UAS has sent SDPs? >> >>I believe it would solve offer/answer glare situations where >>the UAC does not known in which order the UAS has sent SDPs. >> >>That should not be controversial, and does not break any RFC >>etc. A B | = | s0|re-INV (offer1) |s0 |-------------------------------------------->| | 18x-rel(answer1)| |<--------------------------------------------| s1| non-2xx|s1 | /------------|<-+ | / ACK |s0| | / ---------->| = | | / UPD(offer2)| | |<=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| | |2xx(answer2) / | | |=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>| | s2| / = |s2| |<---------------------/ |<-+ s0|ACK | |-----------> | | = | >At least in the above case, o-version seems to be useless for >determining the order. I think the o-version of offer2 should >be the one of answer1 +1. Yes. >Even if the UPDATE has the pre-re-INVITE o-version, UA A might >be confused by the decrement. I am not sure I understand. The version value shall not be decremented. In = my understanding the value is only with respect to the previous SDP - you c= an not use it to switch back to some "old" SDP. So, even if the UPDATE contains the pre-re-INVITE SDP, the value shall be a= nswer1 + 1 + 1, because it is a new SDP compared to the previously sent SDP= (in the 18x) Regards, Christer= From christer.holmberg@ericsson.com Thu May 27 10:25:49 2010 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 46C293A68D7 for ; Thu, 27 May 2010 10:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.707 X-Spam-Level: X-Spam-Status: No, score=-4.707 tagged_above=-999 required=5 tests=[AWL=1.892, 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 AVmTkCJeatJf for ; Thu, 27 May 2010 10:25:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3275E3A6B4C for ; Thu, 27 May 2010 10:25:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7b73ae00000711c-01-4bfeab0bca15 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1D.DC.28956.B0BAEFB4; Thu, 27 May 2010 19:25:31 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 27 May 2010 19:25:31 +0200 From: Christer Holmberg To: SIPCORE Date: Thu, 27 May 2010 19:25:29 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-03 Thread-Index: AQHK+2H7f5UZmtspEk2IGq1P7d4+CpJhzWGwgAH0Y8CAAAPY0IAABpeggAAJaVOAAAPh4IAANSLSgAF7wJM= Message-ID: References: , <430FC6BDED356B4C8498F634416644A91C13B8A302@mail> , <430FC6BDED356B4C8498F634416644A91C13B8A336@mail> , <430FC6BDED356B4C8498F634416644A91C13B8A35B@mail>, 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-03 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 May 2010 17:25:49 -0000 Hi, Based on the feedback and comments, I intend to produce a new version of th= e keep draft, with the following changes: 1. Instead of using the Flow-Timer header field, the server recommended kee= p-alive frequency is inserted as keep parameter value (instead of "yes"). 2. If an entity wants to receive keep-alives, it will add the keep paramete= r value (instead of "yes") in the response, instead of the request. It does= not need to be in the request, and it seems to confuse the reader of the d= raft. 3. The text will say that, when negotiated with REGISTER, the keep-alives a= re sent until a registration refresh is performed, when the keep-alives nee= ds to be negotiated again (if the sender still wants to send them). The rea= son is that it cannot be assumed that a proxy knows whether a REGISTER is f= or a new registration, or for a registration refresh. 4. The example flows will be updated to reflect the changes above. 5. Editorial changes. After that, I intend to ask the chairs to initiate WGLC. Regards, Christer= From shinji.okumura@softfront.jp Thu May 27 18:22:27 2010 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 A451C3A69F9 for ; Thu, 27 May 2010 18:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.746 X-Spam-Level: X-Spam-Status: No, score=-92.746 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_SLUT=2.522, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 HBBswJa1f0MR for ; Thu, 27 May 2010 18:22:09 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 6A7CB3A69F5 for ; Thu, 27 May 2010 18:21:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 91134428019; Fri, 28 May 2010 10:21:14 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHElom8GFiUS; Fri, 28 May 2010 10:21:11 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 7E64F42800F; Fri, 28 May 2010 10:21:10 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 28 May 2010 10:21:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: <49CAFE040D9537shinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 28 May 2010 01:22:41 -0000 X-List-Received-Date: Fri, 28 May 2010 01:22:41 -0000 X-List-Received-Date: Fri, 28 May 2010 01:22:41 -0000 Gao, I have a question regarding a target-refresh. If a UAS return 18x-rel, 2xx to reINVITE and an UPDATE, and each response has a different Contact-URI(it is a remote target for a UAC), then how should the UAC handle the UPDATE and the remote targets? How does your analyzer work? Please explain it concretely in order. A B | | |re-INV (offer1) | |------------------------------>| | 18x-rel(answer1)| m:c1 |<------------------------------| | 2xx(INV)| m:c2 |<------------------------------| | UPDATE| m:c3 |<------------------------------| | | or A B | | |re-INV (offer1) | |------------------------------>| | 18x-rel(answer1)| m:c1 |<------------------------------| | 2xx(INV)| m:c2 |<---------\ /------------------| | X UPDATE| m:c3 |<---------/ \------------------| | | Regards, Shinji >> How can you only apply "checking for glare situations" during a >> glare situation? >> >> Checking for offer/answer glare is part of normal RFC3311 UPDATE >processing. > >Making two analyzers in series as: > >---> analyzer1 -----> analyzer2 ----> > >analyzer1 using the rules in RFC3311, and if there's glares case under >it's rule, send 491 or (500+retry) directly; >analyzer2 using the rules in the draft. > >analyzer2 also has two process: >1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If >it >can do so, pass the UPDATE to the next step normally; >2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as >if >it contains Offer and using O/A rules to reject. > >The effected cases/siutation is only these cases/situation which are >ambiguous before the draft. From shinji.okumura@softfront.jp Thu May 27 20:39:44 2010 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 255543A67E2 for ; Thu, 27 May 2010 20:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.1 X-Spam-Level: X-Spam-Status: No, score=-94.1 tagged_above=-999 required=5 tests=[AWL=1.354, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 Ji5OIg9Cayly for ; Thu, 27 May 2010 20:39:43 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 1FAFD3A6452 for ; Thu, 27 May 2010 20:39:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 0AF3F428019; Fri, 28 May 2010 12:39:32 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWiOpUzwFXvw; Fri, 28 May 2010 12:39:30 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id C34D0428018; Fri, 28 May 2010 12:39:29 +0900 (JST) From: OKUMURA Shinji To: Christer Holmberg , "gao.yang2@zte.com.cn" , Brett Tate Date: Fri, 28 May 2010 12:39:28 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: <94CAFE17605BCDshinji.okumura@softfront.jp> Cc: "sipcore@ietf.org" Subject: Re: [sipcore] New deal - IDEA [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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, 28 May 2010 03:39:44 -0000 Christer, Christer Holmberg Thu, 27 May 2010 11:51:38 +0200 >Below are some questions/ideas on how I think we could solve >most issues. Some of the stuff shall be seen more as brain >storming than actual proposal at this point. > >I am fully aware that some of the ideas for sure may limit >what is said in RFCs etc, so you don't need to tell me >about that. > >IDEA #1: Offer/answer: Usage of SDP o= version parameter > >I know this has been discussed at some point, but what is >the reason we can't use the SDP o= version parameter to >determine in which order the UAS has sent SDPs? > >I believe it would solve offer/answer glare situations where >the UAC does not known in which order the UAS has sent SDPs. > >That should not be controversial, and does not break any RFC >etc. > >IDEA #2: Target update: Only outside re-INVITEs > >Let's forbid target updates "inside" re-INVITEs. I really >doubt there is a need for those while the UAs are doing >something else with the re-INVITE. > >That at least solves the glare situation where the remote >target may be updated in a re-INVITE response and an UPDATE >response. In the same sequence, since it is not possible to forbid a offer-anser, the idea seems to be ineffective. At least it might be difficult to actually use the rule. For example, when a 2xx response to an UPDATE within an INVITE transaction include both new remote target and an answer, how should the UAS handle the response? >IDEA #3: UPDATE: Always use re-INVITE glare rules > >Let's not allow more than one outstanding UPDATE. Ie if a UA >has sent an UPDATE (with or without SDP), and receives >another UPDATE request before the answer, it rejects it >(same rule as for re-INVITE). I couldn't agree more. Regards, Shinji >That would at least solve the problem where a UA sends an >UPDATE, receives a 200 OK and a UPDATE request, both with >different target information. >Ok, let the tomatoes fly... > >...and let me know if there are any issues which the ideas >above do NOT solve. I have some more ideas, but I am not >sure they are needed so I'll them to myself for now :) > >Regards, > >Christer From shinji.okumura@softfront.jp Thu May 27 21:27:00 2010 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 7C9E73A6A66 for ; Thu, 27 May 2010 21:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.777 X-Spam-Level: X-Spam-Status: No, score=-94.777 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 XWtwmEQLv1oW for ; Thu, 27 May 2010 21:26:33 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 6DAAB3A6A0E for ; Thu, 27 May 2010 21:21:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 8C5E942801B for ; Fri, 28 May 2010 13:19:11 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alkNb9lpQaan for ; Fri, 28 May 2010 13:19:07 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id CB34542801A for ; Fri, 28 May 2010 13:19:06 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 28 May 2010 13:19:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <20100508073002.1CBBE3A68A8@core3.amsl.com> References: <20100508073002.1CBBE3A68A8@core3.amsl.com> Message-Id: Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Fri, 28 May 2010 04:27:01 -0000 Hi all, Following texts seem to be conflicted. 3.8. Clarifications on Cancelling Re-INVITEs Per the rules specified in Section 3.3, if the INVITE request was a re- INVITE and some of its requested changes had already been executed, the UAS would return a 2xx response instead. 5.5. UAC Losing its Contact: UAC Behavior Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE and cause the INVITE client transaction corresponding to the re- INVITE to enter the "Terminated" state. At least there is a possibility that the conflict occurs. Regards, Shinji Internet-Drafts@ietf.org Sat, 8 May 2010 00:30:02 -0700 (PDT) >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > > Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-sipcore-reinvite-04.txt > Pages : 24 > Date : 2010-05-08 > >In this document, we clarify the handling of re-INVITEs in SIP. We >clarify in which situations a UAS (User Agent Server) should generate >a success response and in which situations a UAS should generate an >error response to a re-INVITE. Additionally, we clarify issues >related to target-refresh requests. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. From gao.yang2@zte.com.cn Thu May 27 21:51:26 2010 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 6FBBB3A6830 for ; Thu, 27 May 2010 21:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.774 X-Spam-Level: X-Spam-Status: No, score=-93.774 tagged_above=-999 required=5 tests=[AWL=-1.261, BAYES_50=0.001, FRT_SLUT=2.522, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 2IuIhY-LXb95 for ; Thu, 27 May 2010 21:51:25 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 6000E3A6869 for ; Thu, 27 May 2010 21:51:23 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Fri, 28 May 2010 12:45:40 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 87322.6510305062; Fri, 28 May 2010 12:44:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4S4maEb091105; Fri, 28 May 2010 12:48:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <49CAFE040D9537shinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 28 May 2010 12:45:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-28 12:48:22, Serialize complete at 2010-05-28 12:48:22 Content-Type: multipart/alternative; boundary="=_alternative 001A5EFE48257731_=" X-MAIL: mse2.zte.com.cn o4S4maEb091105 Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 28 May 2010 04:51:26 -0000 This is a multipart message in MIME format. --=_alternative 001A5EFE48257731_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 T25seSB0aGUgDQoNCklmIGEgVUENCiAgIHVzZXMgYW4gVVBEQVRFIHJlcXVlc3Qgb3IgcmVzcG9u c2UgdG8gbW9kaWZ5IHRoZSByZW1vdGUgdGFyZ2V0IHdoaWxlDQogICBhbiBJTlZJVEUgdHJhbnNh Y3Rpb24gaXMgaW4gcHJvZ3Jlc3MsIGFuZCBpdCBpcyBhIFVBUyBmb3IgdGhhdCBJTlZJVEUNCiAg IHRyYW5zYWN0aW9uLCBpdCBNVVNUIHBsYWNlIHRoZSBzYW1lIHZhbHVlIGludG8gdGhlIENvbnRh Y3QgaGVhZGVyDQogICBmaWVsZCBvZiB0aGUgMnh4IHRvIHRoZSBJTlZJVEUgdGhhdCBpdCBwbGFj ZWQgaW50byB0aGUgVVBEQVRFIHJlcXVlc3QNCiAgIG9yIHJlc3BvbnNlLg0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3 MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCk9LVU1V UkEgU2hpbmppIDxzaGluamkub2t1bXVyYUBzb2Z0ZnJvbnQuanA+IA0KMjAxMC0wNS0yOCAwOToy MQ0KDQrK1bz+yMsNCnNpcGNvcmVAaWV0Zi5vcmcNCrOty80NCmdhby55YW5nMkB6dGUuY29tLmNu LCBCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQuY29tPiwgDQpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20NCtb3zOINClJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52 aXRlLTA0OiBnbGFyZSBhbmQgVVBEQVRFd2l0aG91dCBTRFANCg0KDQoNCg0KDQoNCkdhbywNCg0K SSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIGEgdGFyZ2V0LXJlZnJlc2guDQoNCklmIGEgVUFT IHJldHVybiAxOHgtcmVsLCAyeHggdG8gcmVJTlZJVEUgYW5kIGFuIFVQREFURSwNCmFuZCBlYWNo IHJlc3BvbnNlIGhhcyBhIGRpZmZlcmVudCBDb250YWN0LVVSSShpdCBpcyBhIHJlbW90ZQ0KdGFy Z2V0IGZvciBhIFVBQyksIHRoZW4gaG93IHNob3VsZCB0aGUgVUFDIGhhbmRsZSB0aGUgVVBEQVRF DQphbmQgdGhlIHJlbW90ZSB0YXJnZXRzPw0KDQpIb3cgZG9lcyB5b3VyIGFuYWx5emVyIHdvcms/ DQpQbGVhc2UgZXhwbGFpbiBpdCBjb25jcmV0ZWx5IGluIG9yZGVyLg0KDQogICAgQSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBCDQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgfHJlLUlOViAob2ZmZXIxKSAgICAgICAgICAgICAgICB8DQogICAgfC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQogICAgfCAgICAgICAgICAgICAgIDE4eC1yZWwo YW5zd2VyMSl8IG06YzENCiAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAyeHgoSU5WKXwgbTpjMg0KICAgIHw8LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgVVBE QVRFfCBtOmMzDQogICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQogICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQpvcg0KICAgIEEgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQg0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgIHxyZS1JTlYgKG9mZmVyMSkgICAgICAgICAgICAgICAgfA0KICAgIHwtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgIHwgICAgICAgICAgICAgICAxOHgtcmVsKGFuc3dlcjEp fCBtOmMxDQogICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgMnh4KElOVil8IG06YzINCiAgICB8PC0tLS0tLS0tLVwgLy0tLS0t LS0tLS0tLS0tLS0tLXwNCiAgICB8ICAgICAgICAgICBYICAgICAgICAgICAgIFVQREFURXwgbTpj Mw0KICAgIHw8LS0tLS0tLS0tLyBcLS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KDQpSZWdhcmRzLA0KU2hpbmppDQoNCj4+IEhvdyBjYW4g eW91IG9ubHkgYXBwbHkgImNoZWNraW5nIGZvciBnbGFyZSBzaXR1YXRpb25zIiBkdXJpbmcgYSAN Cj4+IGdsYXJlIHNpdHVhdGlvbj8NCj4+IA0KPj4gQ2hlY2tpbmcgZm9yIG9mZmVyL2Fuc3dlciBn bGFyZSBpcyBwYXJ0IG9mIG5vcm1hbCBSRkMzMzExIFVQREFURSANCj5wcm9jZXNzaW5nLg0KPg0K Pk1ha2luZyB0d28gYW5hbHl6ZXJzIGluIHNlcmllcyBhczoNCj4NCj4tLS0+IGFuYWx5emVyMSAt LS0tLT4gYW5hbHl6ZXIyIC0tLS0+DQo+DQo+YW5hbHl6ZXIxIHVzaW5nIHRoZSBydWxlcyBpbiBS RkMzMzExLCBhbmQgaWYgdGhlcmUncyBnbGFyZXMgY2FzZSB1bmRlciANCj5pdCdzIHJ1bGUsIHNl bmQgNDkxIG9yICg1MDArcmV0cnkpIGRpcmVjdGx5Ow0KPmFuYWx5emVyMiB1c2luZyB0aGUgcnVs ZXMgaW4gdGhlIGRyYWZ0LiANCj4NCj5hbmFseXplcjIgYWxzbyBoYXMgdHdvIHByb2Nlc3M6DQo+ MS4gQ2hlY2sgd2hldGhlciBpdCBjYW4gZG8gdGhlIG9yZGVyaW5nIG9mIDJ4eChJTlZJVEUpYW5k IFVQREFURS4gSWYgDQo+aXQgDQo+Y2FuIGRvIHNvLCBwYXNzIHRoZSBVUERBVEUgdG8gdGhlIG5l eHQgc3RlcCBub3JtYWxseTsNCj4yLiBJZiBpdCBjYW4gbm90IGRvIHRoZSBvcmRlcmluZywgaGFu ZGxlIHRoZSBVUERBVEUgYW5kIDJ4eChJTlZJVEUpIGFzIA0KPmlmIA0KPml0IGNvbnRhaW5zIE9m ZmVyIGFuZCB1c2luZyBPL0EgcnVsZXMgdG8gcmVqZWN0Lg0KPg0KPlRoZSBlZmZlY3RlZCBjYXNl cy9zaXV0YXRpb24gaXMgb25seSB0aGVzZSBjYXNlcy9zaXR1YXRpb24gd2hpY2ggYXJlIA0KPmFt YmlndW91cyBiZWZvcmUgdGhlIGRyYWZ0Lg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 001A5EFE48257731_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9ubHkgdGhlIDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPklmIGEgVUE8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7dXNlcyBhbiBV UERBVEUgcmVxdWVzdA0Kb3IgcmVzcG9uc2UgdG8gbW9kaWZ5IHRoZSByZW1vdGUgdGFyZ2V0IHdo aWxlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZu YnNwO2FuIElOVklURSB0cmFuc2FjdGlvbg0KaXMgaW4gcHJvZ3Jlc3MsIGFuZCBpdCBpcyBhIFVB UyBmb3IgdGhhdCBJTlZJVEU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbmJzcDsgJm5ic3A7dHJhbnNhY3Rpb24sIGl0IE1VU1QgcGxhY2UNCnRoZSBzYW1lIHZh bHVlIGludG8gdGhlIENvbnRhY3QgaGVhZGVyPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO2ZpZWxkIG9mIHRoZSAyeHggdG8gdGhlDQpJTlZJ VEUgdGhhdCBpdCBwbGFjZWQgaW50byB0aGUgVVBEQVRFIHJlcXVlc3Q8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7b3IgcmVzcG9uc2UuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEy PGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4Nikt MDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+T0tVTVVSQSBTaGluamkgJmx0O3NoaW5qaS5v a3VtdXJhQHNvZnRmcm9udC5qcCZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMC0wNS0yOCAwOToyMTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5zaXBjb3JlQGlldGYub3JnPC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5nYW8ueWFuZzJAenRlLmNvbS5jbiwgQnJldHQgVGF0ZSAmbHQ7YnJldHRAYnJv YWRzb2Z0LmNvbSZndDssDQpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0Og0K Z2xhcmUgYW5kIFVQREFURXdpdGhvdXQgU0RQPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5HYW8sPGJyPg0KPGJyPg0KSSBoYXZlIGEgcXVl c3Rpb24gcmVnYXJkaW5nIGEgdGFyZ2V0LXJlZnJlc2guPGJyPg0KPGJyPg0KSWYgYSBVQVMgcmV0 dXJuIDE4eC1yZWwsIDJ4eCB0byByZUlOVklURSBhbmQgYW4gVVBEQVRFLDxicj4NCmFuZCBlYWNo IHJlc3BvbnNlIGhhcyBhIGRpZmZlcmVudCBDb250YWN0LVVSSShpdCBpcyBhIHJlbW90ZTxicj4N CnRhcmdldCBmb3IgYSBVQUMpLCB0aGVuIGhvdyBzaG91bGQgdGhlIFVBQyBoYW5kbGUgdGhlIFVQ REFURTxicj4NCmFuZCB0aGUgcmVtb3RlIHRhcmdldHM/PGJyPg0KPGJyPg0KSG93IGRvZXMgeW91 ciBhbmFseXplciB3b3JrPzxicj4NClBsZWFzZSBleHBsYWluIGl0IGNvbmNyZXRlbHkgaW4gb3Jk ZXIuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDtBICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCPGJyPg0KICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KICZuYnNwOyAmbmJz cDt8cmUtSU5WIChvZmZlcjEpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7fDxicj4NCiAmbmJzcDsgJm5ic3A7fC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSZndDt8PGJyPg0KICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxOHgtcmVsKGFuc3dlcjEpfA0KbTpjMTxi cj4NCiAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18PGJy Pg0KICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IDJ4eChJTlYpfCBtOmMyPGJy Pg0KICZuYnNwOyAmbmJzcDt8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+ DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFVQREFURXwgbTpj Mzxicj4NCiAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18 PGJyPg0KICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8PGJyPg0Kb3I8YnI+DQogJm5ic3A7ICZuYnNwO0EgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEI8YnI+DQogJm5ic3A7ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+ DQogJm5ic3A7ICZuYnNwO3xyZS1JTlYgKG9mZmVyMSkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDt8PGJyPg0KICZuYnNwOyAmbmJzcDt8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDE4eC1yZWwoYW5z d2VyMSl8DQptOmMxPGJyPg0KICZuYnNwOyAmbmJzcDt8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLXw8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgMnh4 KElOVil8IG06YzI8YnI+DQogJm5ic3A7ICZuYnNwO3wmbHQ7LS0tLS0tLS0tXCAvLS0tLS0tLS0t LS0tLS0tLS0tfDxicj4NCiAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFggJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFVQ REFURXwgbTpjMzxicj4NCiAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0vIFwtLS0tLS0tLS0t LS0tLS0tLS18PGJyPg0KICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpTaGluamk8 YnI+DQo8YnI+DQomZ3Q7Jmd0OyBIb3cgY2FuIHlvdSBvbmx5IGFwcGx5ICZxdW90O2NoZWNraW5n IGZvciBnbGFyZSBzaXR1YXRpb25zJnF1b3Q7DQpkdXJpbmcgYSA8YnI+DQomZ3Q7Jmd0OyBnbGFy ZSBzaXR1YXRpb24/PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQ2hlY2tpbmcgZm9yIG9m ZmVyL2Fuc3dlciBnbGFyZSBpcyBwYXJ0IG9mIG5vcm1hbCBSRkMzMzExIFVQREFURQ0KPGJyPg0K Jmd0O3Byb2Nlc3NpbmcuPGJyPg0KJmd0Ozxicj4NCiZndDtNYWtpbmcgdHdvIGFuYWx5emVycyBp biBzZXJpZXMgYXM6PGJyPg0KJmd0Ozxicj4NCiZndDstLS0mZ3Q7IGFuYWx5emVyMSAtLS0tLSZn dDsgYW5hbHl6ZXIyIC0tLS0mZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDthbmFseXplcjEgdXNpbmcg dGhlIHJ1bGVzIGluIFJGQzMzMTEsIGFuZCBpZiB0aGVyZSdzIGdsYXJlcyBjYXNlIHVuZGVyDQo8 YnI+DQomZ3Q7aXQncyBydWxlLCBzZW5kIDQ5MSBvciAoNTAwK3JldHJ5KSBkaXJlY3RseTs8YnI+ DQomZ3Q7YW5hbHl6ZXIyIHVzaW5nIHRoZSBydWxlcyBpbiB0aGUgZHJhZnQuIDxicj4NCiZndDs8 YnI+DQomZ3Q7YW5hbHl6ZXIyIGFsc28gaGFzIHR3byBwcm9jZXNzOjxicj4NCiZndDsxLiBDaGVj ayB3aGV0aGVyIGl0IGNhbiBkbyB0aGUgb3JkZXJpbmcgb2YgMnh4KElOVklURSlhbmQgVVBEQVRF LiBJZg0KPGJyPg0KJmd0O2l0IDxicj4NCiZndDtjYW4gZG8gc28sIHBhc3MgdGhlIFVQREFURSB0 byB0aGUgbmV4dCBzdGVwIG5vcm1hbGx5Ozxicj4NCiZndDsyLiBJZiBpdCBjYW4gbm90IGRvIHRo ZSBvcmRlcmluZywgaGFuZGxlIHRoZSBVUERBVEUgYW5kIDJ4eChJTlZJVEUpDQphcyA8YnI+DQom Z3Q7aWYgPGJyPg0KJmd0O2l0IGNvbnRhaW5zIE9mZmVyIGFuZCB1c2luZyBPL0EgcnVsZXMgdG8g cmVqZWN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7VGhlIGVmZmVjdGVkIGNhc2VzL3NpdXRhdGlvbiBp cyBvbmx5IHRoZXNlIGNhc2VzL3NpdHVhdGlvbiB3aGljaCBhcmUNCjxicj4NCiZndDthbWJpZ3Vv dXMgYmVmb3JlIHRoZSBkcmFmdC48YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5i c3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBp ZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0 byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZu YnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50 cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVy cy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJh bnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJz cDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3Vz ZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5i c3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJ ZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZu YnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtv cmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3Zp ZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2Fy ZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVy Lg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNw O2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJz cDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 001A5EFE48257731_=-- From gao.yang2@zte.com.cn Thu May 27 21:56:36 2010 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 450A33A6835 for ; Thu, 27 May 2010 21:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.408 X-Spam-Level: X-Spam-Status: No, score=-95.408 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 kjkYk43O0ord for ; Thu, 27 May 2010 21:56:34 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 931D03A6830 for ; Thu, 27 May 2010 21:56:33 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Fri, 28 May 2010 12:49:43 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 87322.6510305062; Fri, 28 May 2010 12:50:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4S4tgH9001703; Fri, 28 May 2010 12:56:06 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <94CAFE17605BCDshinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 28 May 2010 12:53:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-28 12:55:51, Serialize complete at 2010-05-28 12:55:51 Content-Type: multipart/alternative; boundary="=_alternative 001B0C9A48257731_=" X-MAIL: mse2.zte.com.cn o4S4tgH9001703 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] New deal - IDEA [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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, 28 May 2010 04:56:36 -0000 This is a multipart message in MIME format. --=_alternative 001B0C9A48257731_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 T25seSB0aGUgZmlyc3QgY2hhcnQgaXMgbGF3ZnVsLiBBcyB0aGUgdGV4dCBmcm9tIFJGQzMzMTE6 DQoNCklmIGEgVUENCiAgIHVzZXMgYW4gVVBEQVRFIHJlcXVlc3Qgb3IgcmVzcG9uc2UgdG8gbW9k aWZ5IHRoZSByZW1vdGUgdGFyZ2V0IHdoaWxlDQogICBhbiBJTlZJVEUgdHJhbnNhY3Rpb24gaXMg aW4gcHJvZ3Jlc3MsIGFuZCBpdCBpcyBhIFVBUyBmb3IgdGhhdCBJTlZJVEUNCiAgIHRyYW5zYWN0 aW9uLCBpdCBNVVNUIHBsYWNlIHRoZSBzYW1lIHZhbHVlIGludG8gdGhlIENvbnRhY3QgaGVhZGVy DQogICBmaWVsZCBvZiB0aGUgMnh4IHRvIHRoZSBJTlZJVEUgdGhhdCBpdCBwbGFjZWQgaW50byB0 aGUgVVBEQVRFIHJlcXVlc3QNCiAgIG9yIHJlc3BvbnNlLg0KDQpJZiB0aGUgVVBEQVRFIGlzIGlu LXNjb3BlIG9mIFJlLUlOVklURSwgdGhlIDJ4eCdzIGNvbnRhY3Qgc2hvdWxkIGJlIHRoZSANCnNh bWUgYXMgdGhlIChsYXN0KSBVUERBVEUncyBjb250YWN0LiBTbywgdGhlIHNlY29uZCBjaGFydCBj YW4gb25seSBoYXMgdGhlIA0KaW50ZXJwcmV0YXRpb24gYXMgdGhlIGZpcnN0IGNoYXJ0LiBUaGVu LCB0aGVyZSdzIG5vIGFtYmlndW91cyANCnJlcHJlc2VudGF0aW9uIGhlcmUuDQoNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDog ODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6 dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KT0tV TVVSQSBTaGluamkgPHNoaW5qaS5va3VtdXJhQHNvZnRmcm9udC5qcD4gDQoyMDEwLTA1LTI4IDEx OjM5DQoNCsrVvP7Iyw0KQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4sICJnYW8ueWFuZzJAenRlLmNvbS5jbiIgDQo8Z2FvLnlhbmcyQHp0ZS5jb20uY24+ LCBCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQuY29tPg0Ks63LzQ0KInNpcGNvcmVAaWV0Zi5v cmciIDxzaXBjb3JlQGlldGYub3JnPg0K1vfM4g0KUmU6IFtzaXBjb3JlXSBOZXcgZGVhbCAtIElE RUEgWyB3YXMgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0OiBnbGFyZSANCmFuZCBVUERB VEUgd2l0aG91dCBTRFBdDQoNCg0KDQoNCg0KDQpDaHJpc3RlciwNCg0KQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NClRodSwgMjcgTWF5IDIwMTAgMTE6 NTE6MzggKzAyMDANCj5CZWxvdyBhcmUgc29tZSBxdWVzdGlvbnMvaWRlYXMgb24gaG93IEkgdGhp bmsgd2UgY291bGQgc29sdmUNCj5tb3N0IGlzc3Vlcy4gU29tZSBvZiB0aGUgc3R1ZmYgc2hhbGwg YmUgc2VlbiBtb3JlIGFzIGJyYWluDQo+c3Rvcm1pbmcgdGhhbiBhY3R1YWwgcHJvcG9zYWwgYXQg dGhpcyBwb2ludC4NCj4NCj5JIGFtIGZ1bGx5IGF3YXJlIHRoYXQgc29tZSBvZiB0aGUgaWRlYXMg Zm9yIHN1cmUgbWF5IGxpbWl0DQo+d2hhdCBpcyBzYWlkIGluIFJGQ3MgZXRjLCBzbyB5b3UgZG9u J3QgbmVlZCB0byB0ZWxsIG1lDQo+YWJvdXQgdGhhdC4NCj4NCj5JREVBICMxOiAgT2ZmZXIvYW5z d2VyOiBVc2FnZSBvZiBTRFAgbz0gdmVyc2lvbiBwYXJhbWV0ZXINCj4NCj5JIGtub3cgdGhpcyBo YXMgYmVlbiBkaXNjdXNzZWQgYXQgc29tZSBwb2ludCwgYnV0IHdoYXQgaXMNCj50aGUgcmVhc29u IHdlIGNhbid0IHVzZSB0aGUgU0RQIG89IHZlcnNpb24gcGFyYW1ldGVyIHRvDQo+ZGV0ZXJtaW5l IGluIHdoaWNoIG9yZGVyIHRoZSBVQVMgaGFzIHNlbnQgU0RQcz8NCj4NCj5JIGJlbGlldmUgaXQg d291bGQgc29sdmUgb2ZmZXIvYW5zd2VyIGdsYXJlIHNpdHVhdGlvbnMgd2hlcmUNCj50aGUgVUFD IGRvZXMgbm90IGtub3duIGluIHdoaWNoIG9yZGVyIHRoZSBVQVMgaGFzIHNlbnQgU0RQcy4NCj4N Cj5UaGF0IHNob3VsZCBub3QgYmUgY29udHJvdmVyc2lhbCwgYW5kIGRvZXMgbm90IGJyZWFrIGFu eSBSRkMNCj5ldGMuDQo+DQo+SURFQSAjMjogICBUYXJnZXQgdXBkYXRlOiBPbmx5IG91dHNpZGUg cmUtSU5WSVRFcw0KPg0KPkxldCdzIGZvcmJpZCB0YXJnZXQgdXBkYXRlcyAiaW5zaWRlIiByZS1J TlZJVEVzLiBJIHJlYWxseQ0KPmRvdWJ0IHRoZXJlIGlzIGEgbmVlZCBmb3IgdGhvc2Ugd2hpbGUg dGhlIFVBcyBhcmUgZG9pbmcNCj5zb21ldGhpbmcgZWxzZSB3aXRoIHRoZSByZS1JTlZJVEUuDQo+ DQo+VGhhdCBhdCBsZWFzdCBzb2x2ZXMgdGhlIGdsYXJlIHNpdHVhdGlvbiB3aGVyZSB0aGUgcmVt b3RlDQo+dGFyZ2V0IG1heSBiZSB1cGRhdGVkIGluIGEgcmUtSU5WSVRFIHJlc3BvbnNlIGFuZCBh biBVUERBVEUNCj5yZXNwb25zZS4NCg0KSW4gdGhlIHNhbWUgc2VxdWVuY2UsIHNpbmNlIGl0IGlz IG5vdCBwb3NzaWJsZSB0byBmb3JiaWQgYQ0Kb2ZmZXItYW5zZXIsIHRoZSBpZGVhIHNlZW1zIHRv IGJlIGluZWZmZWN0aXZlLg0KQXQgbGVhc3QgaXQgbWlnaHQgYmUgZGlmZmljdWx0IHRvIGFjdHVh bGx5IHVzZSB0aGUgcnVsZS4NCg0KRm9yIGV4YW1wbGUsIHdoZW4gYSAyeHggcmVzcG9uc2UgdG8g YW4gVVBEQVRFIHdpdGhpbiBhbg0KSU5WSVRFIHRyYW5zYWN0aW9uIGluY2x1ZGUgYm90aCBuZXcg cmVtb3RlIHRhcmdldCBhbmQgYW4gYW5zd2VyLA0KaG93IHNob3VsZCB0aGUgVUFTIGhhbmRsZSB0 aGUgcmVzcG9uc2U/DQoNCj5JREVBICMzOiAgICBVUERBVEU6IEFsd2F5cyB1c2UgcmUtSU5WSVRF IGdsYXJlIHJ1bGVzDQo+DQo+TGV0J3Mgbm90IGFsbG93IG1vcmUgdGhhbiBvbmUgb3V0c3RhbmRp bmcgVVBEQVRFLiBJZSBpZiBhIFVBDQo+aGFzIHNlbnQgYW4gVVBEQVRFICh3aXRoIG9yIHdpdGhv dXQgU0RQKSwgYW5kIHJlY2VpdmVzDQo+YW5vdGhlciBVUERBVEUgcmVxdWVzdCBiZWZvcmUgdGhl IGFuc3dlciwgaXQgcmVqZWN0cyBpdA0KPihzYW1lIHJ1bGUgYXMgZm9yIHJlLUlOVklURSkuDQoN CkkgY291bGRuJ3QgYWdyZWUgbW9yZS4NCg0KUmVnYXJkcywNClNoaW5qaQ0KDQo+VGhhdCB3b3Vs ZCBhdCBsZWFzdCBzb2x2ZSB0aGUgcHJvYmxlbSB3aGVyZSBhIFVBIHNlbmRzIGFuDQo+VVBEQVRF LCByZWNlaXZlcyBhIDIwMCBPSyBhbmQgYSBVUERBVEUgcmVxdWVzdCwgYm90aCB3aXRoDQo+ZGlm ZmVyZW50IHRhcmdldCBpbmZvcm1hdGlvbi4NCj5PaywgbGV0IHRoZSB0b21hdG9lcyBmbHkuLi4N Cj4NCj4uLi5hbmQgbGV0IG1lIGtub3cgaWYgdGhlcmUgYXJlIGFueSBpc3N1ZXMgd2hpY2ggdGhl IGlkZWFzDQo+YWJvdmUgZG8gTk9UIHNvbHZlLiBJIGhhdmUgc29tZSBtb3JlIGlkZWFzLCBidXQg SSBhbSBub3QNCj5zdXJlIHRoZXkgYXJlIG5lZWRlZCBzbyBJJ2xsIHRoZW0gdG8gbXlzZWxmIGZv ciBub3cgOikNCj4NCj5SZWdhcmRzLA0KPg0KPkNocmlzdGVyDQoNCg0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90 aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBj b25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBv ZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 001B0C9A48257731_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9ubHkgdGhlIGZpcnN0IGNoYXJ0 IGlzIGxhd2Z1bC4gQXMgdGhlDQp0ZXh0IGZyb20gUkZDMzMxMTo8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5JZiBhIFVBPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3VzZXMgYW4gVVBEQVRFIHJl cXVlc3QNCm9yIHJlc3BvbnNlIHRvIG1vZGlmeSB0aGUgcmVtb3RlIHRhcmdldCB3aGlsZTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDthbiBJ TlZJVEUgdHJhbnNhY3Rpb24NCmlzIGluIHByb2dyZXNzLCBhbmQgaXQgaXMgYSBVQVMgZm9yIHRo YXQgSU5WSVRFPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5i c3A7ICZuYnNwO3RyYW5zYWN0aW9uLCBpdCBNVVNUIHBsYWNlDQp0aGUgc2FtZSB2YWx1ZSBpbnRv IHRoZSBDb250YWN0IGhlYWRlcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOyAmbmJzcDtmaWVsZCBvZiB0aGUgMnh4IHRvIHRoZQ0KSU5WSVRFIHRoYXQg aXQgcGxhY2VkIGludG8gdGhlIFVQREFURSByZXF1ZXN0PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO29yIHJlc3BvbnNlLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SWYgdGhlIFVQREFURSBpcyBp bi1zY29wZSBvZiBSZS1JTlZJVEUsDQp0aGUgMnh4J3MgY29udGFjdCBzaG91bGQgYmUgdGhlIHNh bWUgYXMgdGhlIChsYXN0KSBVUERBVEUncyBjb250YWN0LiBTbywNCnRoZSBzZWNvbmQgY2hhcnQg Y2FuIG9ubHkgaGFzIHRoZSBpbnRlcnByZXRhdGlvbiBhcyB0aGUgZmlyc3QgY2hhcnQuIFRoZW4s DQp0aGVyZSdzIG5vIGFtYmlndW91cyByZXByZXNlbnRhdGlvbiBoZXJlLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwg Jm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIx MTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxiPk9LVU1VUkEgU2hpbmppICZsdDtzaGluamkub2t1bXVyYUBzb2Z0 ZnJvbnQuanAmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTAtMDUtMjggMTE6Mzk8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbSZndDssDQomcXVvdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZxdW90OyAm bHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7LCBCcmV0dCBUYXRlDQombHQ7YnJldHRAYnJvYWRz b2Z0LmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3NpcGNvcmVAaWV0Zi5vcmcmcXVv dDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNv cmVdIE5ldyBkZWFsIC0gSURFQSBbIHdhcw0KZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0 OiBnbGFyZSBhbmQgVVBEQVRFIHdpdGhvdXQgU0RQXTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Q2hyaXN0ZXIsPGJyPg0KPGJyPg0KQ2hy aXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+ DQpUaHUsIDI3IE1heSAyMDEwIDExOjUxOjM4ICswMjAwPGJyPg0KJmd0O0JlbG93IGFyZSBzb21l IHF1ZXN0aW9ucy9pZGVhcyBvbiBob3cgSSB0aGluayB3ZSBjb3VsZCBzb2x2ZTxicj4NCiZndDtt b3N0IGlzc3Vlcy4gU29tZSBvZiB0aGUgc3R1ZmYgc2hhbGwgYmUgc2VlbiBtb3JlIGFzIGJyYWlu PGJyPg0KJmd0O3N0b3JtaW5nIHRoYW4gYWN0dWFsIHByb3Bvc2FsIGF0IHRoaXMgcG9pbnQuPGJy Pg0KJmd0Ozxicj4NCiZndDtJIGFtIGZ1bGx5IGF3YXJlIHRoYXQgc29tZSBvZiB0aGUgaWRlYXMg Zm9yIHN1cmUgbWF5IGxpbWl0PGJyPg0KJmd0O3doYXQgaXMgc2FpZCBpbiBSRkNzIGV0Yywgc28g eW91IGRvbid0IG5lZWQgdG8gdGVsbCBtZTxicj4NCiZndDthYm91dCB0aGF0Ljxicj4NCiZndDs8 YnI+DQomZ3Q7SURFQSAjMTogJm5ic3A7T2ZmZXIvYW5zd2VyOiBVc2FnZSBvZiBTRFAgbz0gdmVy c2lvbiBwYXJhbWV0ZXI8YnI+DQomZ3Q7PGJyPg0KJmd0O0kga25vdyB0aGlzIGhhcyBiZWVuIGRp c2N1c3NlZCBhdCBzb21lIHBvaW50LCBidXQgd2hhdCBpczxicj4NCiZndDt0aGUgcmVhc29uIHdl IGNhbid0IHVzZSB0aGUgU0RQIG89IHZlcnNpb24gcGFyYW1ldGVyIHRvPGJyPg0KJmd0O2RldGVy bWluZSBpbiB3aGljaCBvcmRlciB0aGUgVUFTIGhhcyBzZW50IFNEUHM/PGJyPg0KJmd0Ozxicj4N CiZndDtJIGJlbGlldmUgaXQgd291bGQgc29sdmUgb2ZmZXIvYW5zd2VyIGdsYXJlIHNpdHVhdGlv bnMgd2hlcmU8YnI+DQomZ3Q7dGhlIFVBQyBkb2VzIG5vdCBrbm93biBpbiB3aGljaCBvcmRlciB0 aGUgVUFTIGhhcyBzZW50IFNEUHMuPGJyPg0KJmd0Ozxicj4NCiZndDtUaGF0IHNob3VsZCBub3Qg YmUgY29udHJvdmVyc2lhbCwgYW5kIGRvZXMgbm90IGJyZWFrIGFueSBSRkM8YnI+DQomZ3Q7ZXRj Ljxicj4NCiZndDs8YnI+DQomZ3Q7SURFQSAjMjogJm5ic3A7IFRhcmdldCB1cGRhdGU6IE9ubHkg b3V0c2lkZSByZS1JTlZJVEVzPGJyPg0KJmd0Ozxicj4NCiZndDtMZXQncyBmb3JiaWQgdGFyZ2V0 IHVwZGF0ZXMgJnF1b3Q7aW5zaWRlJnF1b3Q7IHJlLUlOVklURXMuIEkgcmVhbGx5PGJyPg0KJmd0 O2RvdWJ0IHRoZXJlIGlzIGEgbmVlZCBmb3IgdGhvc2Ugd2hpbGUgdGhlIFVBcyBhcmUgZG9pbmc8 YnI+DQomZ3Q7c29tZXRoaW5nIGVsc2Ugd2l0aCB0aGUgcmUtSU5WSVRFLjxicj4NCiZndDs8YnI+ DQomZ3Q7VGhhdCBhdCBsZWFzdCBzb2x2ZXMgdGhlIGdsYXJlIHNpdHVhdGlvbiB3aGVyZSB0aGUg cmVtb3RlPGJyPg0KJmd0O3RhcmdldCBtYXkgYmUgdXBkYXRlZCBpbiBhIHJlLUlOVklURSByZXNw b25zZSBhbmQgYW4gVVBEQVRFPGJyPg0KJmd0O3Jlc3BvbnNlLjxicj4NCjxicj4NCkluIHRoZSBz YW1lIHNlcXVlbmNlLCBzaW5jZSBpdCBpcyBub3QgcG9zc2libGUgdG8gZm9yYmlkIGE8YnI+DQpv ZmZlci1hbnNlciwgdGhlIGlkZWEgc2VlbXMgdG8gYmUgaW5lZmZlY3RpdmUuPGJyPg0KQXQgbGVh c3QgaXQgbWlnaHQgYmUgZGlmZmljdWx0IHRvIGFjdHVhbGx5IHVzZSB0aGUgcnVsZS48YnI+DQo8 YnI+DQpGb3IgZXhhbXBsZSwgd2hlbiBhIDJ4eCByZXNwb25zZSB0byBhbiBVUERBVEUgd2l0aGlu IGFuPGJyPg0KSU5WSVRFIHRyYW5zYWN0aW9uIGluY2x1ZGUgYm90aCBuZXcgcmVtb3RlIHRhcmdl dCBhbmQgYW4gYW5zd2VyLDxicj4NCmhvdyBzaG91bGQgdGhlIFVBUyBoYW5kbGUgdGhlIHJlc3Bv bnNlPzxicj4NCjxicj4NCiZndDtJREVBICMzOiAmbmJzcDsgJm5ic3A7VVBEQVRFOiBBbHdheXMg dXNlIHJlLUlOVklURSBnbGFyZSBydWxlczxicj4NCiZndDs8YnI+DQomZ3Q7TGV0J3Mgbm90IGFs bG93IG1vcmUgdGhhbiBvbmUgb3V0c3RhbmRpbmcgVVBEQVRFLiBJZSBpZiBhIFVBPGJyPg0KJmd0 O2hhcyBzZW50IGFuIFVQREFURSAod2l0aCBvciB3aXRob3V0IFNEUCksIGFuZCByZWNlaXZlczxi cj4NCiZndDthbm90aGVyIFVQREFURSByZXF1ZXN0IGJlZm9yZSB0aGUgYW5zd2VyLCBpdCByZWpl Y3RzIGl0PGJyPg0KJmd0OyhzYW1lIHJ1bGUgYXMgZm9yIHJlLUlOVklURSkuPGJyPg0KPGJyPg0K SSBjb3VsZG4ndCBhZ3JlZSBtb3JlLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KU2hpbmppPGJy Pg0KPGJyPg0KJmd0O1RoYXQgd291bGQgYXQgbGVhc3Qgc29sdmUgdGhlIHByb2JsZW0gd2hlcmUg YSBVQSBzZW5kcyBhbjxicj4NCiZndDtVUERBVEUsIHJlY2VpdmVzIGEgMjAwIE9LIGFuZCBhIFVQ REFURSByZXF1ZXN0LCBib3RoIHdpdGg8YnI+DQomZ3Q7ZGlmZmVyZW50IHRhcmdldCBpbmZvcm1h dGlvbi48YnI+DQomZ3Q7T2ssIGxldCB0aGUgdG9tYXRvZXMgZmx5Li4uPGJyPg0KJmd0Ozxicj4N CiZndDsuLi5hbmQgbGV0IG1lIGtub3cgaWYgdGhlcmUgYXJlIGFueSBpc3N1ZXMgd2hpY2ggdGhl IGlkZWFzPGJyPg0KJmd0O2Fib3ZlIGRvIE5PVCBzb2x2ZS4gSSBoYXZlIHNvbWUgbW9yZSBpZGVh cywgYnV0IEkgYW0gbm90PGJyPg0KJmd0O3N1cmUgdGhleSBhcmUgbmVlZGVkIHNvIEknbGwgdGhl bSB0byBteXNlbGYgZm9yIG5vdyA6KTxicj4NCiZndDs8YnI+DQomZ3Q7UmVnYXJkcyw8YnI+DQom Z3Q7PGJyPg0KJmd0O0NocmlzdGVyPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZu YnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWls Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lw aWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7 dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3Qm bmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVu dHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhl cnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3Ry YW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5i c3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1 c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZu YnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7 SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwm bmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7 b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2 aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDth cmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRl ci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJz cDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5i c3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 001B0C9A48257731_=-- From gao.yang2@zte.com.cn Thu May 27 22:31:14 2010 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 143E13A6A08 for ; Thu, 27 May 2010 22:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.416 X-Spam-Level: X-Spam-Status: No, score=-97.416 tagged_above=-999 required=5 tests=[AWL=1.822, BAYES_50=0.001, 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 H5oIl9wNN8Jq for ; Thu, 27 May 2010 22:31:08 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 259B33A6A44 for ; Thu, 27 May 2010 22:19:13 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Fri, 28 May 2010 13:12:22 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 87322.3015714703; Fri, 28 May 2010 13:07:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4S5CJvo023852; Fri, 28 May 2010 13:12:24 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 28 May 2010 13:09:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-28 13:12:09, Serialize complete at 2010-05-28 13:12:09 Content-Type: multipart/alternative; boundary="=_alternative 001C8C1D48257731_=" X-MAIL: mse2.zte.com.cn o4S5CJvo023852 Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Fri, 28 May 2010 05:31:14 -0000 This is a multipart message in MIME format. --=_alternative 001C8C1D48257731_= Content-Type: text/plain; charset="US-ASCII" > Following texts seem to be conflicted. > > 3.8. Clarifications on Cancelling Re-INVITEs > Per > the rules specified in Section 3.3, if the INVITE request was a re- > INVITE and some of its requested changes had already been executed, > the UAS would return a 2xx response instead. This is about UAS's behavior. > > 5.5. UAC Losing its Contact: UAC Behavior > Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE > and cause the INVITE client transaction corresponding to the re- > INVITE to enter the "Terminated" state. This is about UAC's behavior. And which(2xx/Non-2xx) final response UAS would send is defined in section 3.8. As the UAC may not get the final response from UAS, it should send a new Re-INVITE(/UPDATE) to synchronize the state. And this is defined in the draft. This is the understanding while I did the review for this part, and I keep my understanding as so. -------------------------------------------------------- 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 001C8C1D48257731_= Content-Type: text/html; charset="US-ASCII"

> Following texts seem to be conflicted.
>
> 3.8.  Clarifications on Cancelling Re-INVITEs
>    Per
>    the rules specified in Section 3.3, if the INVITE request was a re-
>    INVITE and some of its requested changes had already been executed,
>    the UAS would return a 2xx response instead.

This is about UAS's behavior.

>
> 5.5.  UAC Losing its Contact: UAC Behavior
>    Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE
>    and cause the INVITE client transaction corresponding to the re-
>    INVITE to enter the "Terminated" state.

This is about UAC's behavior. And which(2xx/Non-2xx) final response UAS would send is defined in section 3.8.

As the UAC may not get the final response from UAS, it should send a new Re-INVITE(/UPDATE) to synchronize the state.
And this is defined in the draft.

This is the understanding while I did the review for this part, and I keep my understanding as so. 

--------------------------------------------------------
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 001C8C1D48257731_=-- From shinji.okumura@softfront.jp Thu May 27 23:19:06 2010 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 E6CC63A6A09 for ; Thu, 27 May 2010 23:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.349 X-Spam-Level: X-Spam-Status: No, score=-93.349 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_50=0.001, FRT_SLUT=2.522, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_64=0.6, RELAY_IS_221=2.222, 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 Z19vP+Phszv2 for ; Thu, 27 May 2010 23:19:02 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id C0BD03A6A10 for ; Thu, 27 May 2010 23:18:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id AF27542801B; Fri, 28 May 2010 15:18:43 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGnInd38Z1vQ; Fri, 28 May 2010 15:18:40 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 13B0342801A; Fri, 28 May 2010 15:18:39 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 28 May 2010 15:18:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 28 May 2010 06:19:06 -0000 Gao, The INVITE transaction has been already completed at the point to send the UPDATE. In my understanding, the UPDATE can have a different Contact. After all, you say that in 1st chart, UAC may return 2xx to the UPDATE and in 2nd chart, it should(must?) return 4xx. Is that right? Regards, Shinji gao.yang2@zte.com.cn Fri, 28 May 2010 12:45:49 +0800 >Only the first chart is lawful. As the text from RFC3311: > >If a UA > uses an UPDATE request or response to modify the remote target while > an INVITE transaction is in progress, and it is a UAS for that INVITE > transaction, it MUST place the same value into the Contact header > field of the 2xx to the INVITE that it placed into the UPDATE request > or response. > >If the UPDATE is in-scope of Re-INVITE, the 2xx's contact should be the >same as the (last) UPDATE's contact. So, the second chart can only has the >interpretation as the first chart. Then, there's no ambiguous >representation here. > >OKUMURA Shinji >2010-05-28 09:21 >Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP > >Gao, > >I have a question regarding a target-refresh. > >If a UAS return 18x-rel, 2xx to reINVITE and an UPDATE, >and each response has a different Contact-URI(it is a remote >target for a UAC), then how should the UAC handle the UPDATE >and the remote targets? > >How does your analyzer work? >Please explain it concretely in order. > > A B > | | > |re-INV (offer1) | > |------------------------------>| > | 18x-rel(answer1)| m:c1 > |<------------------------------| > | 2xx(INV)| m:c2 > |<------------------------------| > | UPDATE| m:c3 > |<------------------------------| > | | >or > A B > | | > |re-INV (offer1) | > |------------------------------>| > | 18x-rel(answer1)| m:c1 > |<------------------------------| > | 2xx(INV)| m:c2 > |<---------\ /------------------| > | X UPDATE| m:c3 > |<---------/ \------------------| > | | > >Regards, >Shinji > >>> How can you only apply "checking for glare situations" during a >>> glare situation? >>> >>> Checking for offer/answer glare is part of normal RFC3311 UPDATE >>processing. >> >>Making two analyzers in series as: >> >>---> analyzer1 -----> analyzer2 ----> >> >>analyzer1 using the rules in RFC3311, and if there's glares case under >>it's rule, send 491 or (500+retry) directly; >>analyzer2 using the rules in the draft. >> >>analyzer2 also has two process: >>1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If >>it >>can do so, pass the UPDATE to the next step normally; >>2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as >>if >>it contains Offer and using O/A rules to reject. >> >>The effected cases/siutation is only these cases/situation which are >>ambiguous before the draft. From gao.yang2@zte.com.cn Thu May 27 23:51:58 2010 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 64FE63A67EA for ; Thu, 27 May 2010 23:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.118 X-Spam-Level: X-Spam-Status: No, score=-94.118 tagged_above=-999 required=5 tests=[AWL=-2.205, BAYES_50=0.001, FRT_SLUT=2.522, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 XmhSJQnmaKWw for ; Thu, 27 May 2010 23:51:57 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6A3843A67F7 for ; Thu, 27 May 2010 23:51:55 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Fri, 28 May 2010 14:45:01 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3015714703; Fri, 28 May 2010 14:51:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4S6pBvB079047; Fri, 28 May 2010 14:51:11 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 28 May 2010 14:48:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-28 14:50:55, Serialize complete at 2010-05-28 14:50:55 Content-Type: multipart/alternative; boundary="=_alternative 0025964748257731_=" X-MAIL: mse2.zte.com.cn o4S6pBvB079047 Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 28 May 2010 06:51:58 -0000 This is a multipart message in MIME format. --=_alternative 0025964748257731_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WW91IHR3byBjaGFydHMgaGFzIGRpZmZlcmVuY2UgYXM6DQoNCkZpcnN0IGNoYXJ0OiAyeHggYmVm b3JlIFVQREFURTsgDQpVQUMgY2FuIHRyZWF0ZSB0aGUgVVBEQVRFJ3MgY29udGFjdCBhcyB0aGUg bmV3IG9uZS4NCg0KU2Vjb25kIGNoYXJ0OiBVUERBVEUgYmVmb3JlIDJ4eC4NCkkgZ3Vlc3MgeW91 ciBwdXp6bGUgaGVyZSBpcyBhYm91dCBob3cgVUFDIGNhbiBvcmRlciB0aGUgc2VxdWVuY2UsIHRo YXQgaXMgDQoiVVBEQVRFIGJlZm9yZSAyeHgiIG9yICIyeHggYmVmb3JlIFVQREFURSIuDQoNCkkg c2hvd2VkIHRoYXQsIGlmIHRoZSBVUERBVEUgaGFzIGRpZmZlcmVudCB0YXJnZXQsIGl0IE1VU1Qg YmUgc2VuZGVkIGFmdGVyIA0KdGhlIDJ4eCBieSBVQVMuIFRoZSByZWFzb24gaXMgdGhhdCwgaWYg VVBEQVRFIGhhcyBhIGRpZmZlcmVudCANCnRhcmdldChjb21wYXJlZCBhcyB0aGUgc3RhdGUgYmVm b3JlIHRoaXMgVVBEQVRFKSwgdGhlIDJ4eCBNVVNUIGhhcyB0aGUgDQpzYW1lIG9uZS4odGhpcyBp cyBkZWZpbmVkIGluIFJGQzMzMTEpLg0KDQpBcyB0aGlzLCB0aGUgVUFDIGNhbiB0cmVhdGUgdGhp cyBVUERBVEUgYWZ0ZXIgMnh4IGFuZCAgVVBEQVRFJ3MgdGFyZ2V0IGlzIA0KbmV3ZXIsIG5vIG1h dHRlciB3aGljaCBvbmUgcmVhY2hzIFVBQyBmaXJzdGx5Lg0KDQoNCg0KDQpPS1VNVVJBIFNoaW5q aSA8c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwPiANCjIwMTAtMDUtMjggMTQ6MTgNCg0KytW8 /sjLDQpzaXBjb3JlQGlldGYub3JnDQqzrcvNDQpnYW8ueWFuZzJAenRlLmNvbS5jbg0K1vfM4g0K UmU6IFtzaXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6IGdsYXJlIGFuZCBV UERBVEUgd2l0aG91dCBTRFANCg0KDQoNCg0KDQoNCkdhbywNCg0KVGhlIElOVklURSB0cmFuc2Fj dGlvbiBoYXMgYmVlbiBhbHJlYWR5IGNvbXBsZXRlZCBhdCB0aGUgcG9pbnQNCnRvIHNlbmQgdGhl IFVQREFURS4gSW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIFVQREFURSBjYW4gaGF2ZSBhDQpkaWZm ZXJlbnQgQ29udGFjdC4NCg0KQWZ0ZXIgYWxsLCB5b3Ugc2F5IHRoYXQNCmluIDFzdCBjaGFydCwg VUFDIG1heSByZXR1cm4gMnh4IHRvIHRoZSBVUERBVEUgYW5kDQppbiAybmQgY2hhcnQsIGl0IHNo b3VsZChtdXN0PykgcmV0dXJuIDR4eC4NCg0KSXMgdGhhdCByaWdodD8NCg0KUmVnYXJkcywNClNo aW5qaQ0KDQpnYW8ueWFuZzJAenRlLmNvbS5jbg0KRnJpLCAyOCBNYXkgMjAxMCAxMjo0NTo0OSAr MDgwMA0KPk9ubHkgdGhlIGZpcnN0IGNoYXJ0IGlzIGxhd2Z1bC4gQXMgdGhlIHRleHQgZnJvbSBS RkMzMzExOg0KPg0KPklmIGEgVUENCj4gICB1c2VzIGFuIFVQREFURSByZXF1ZXN0IG9yIHJlc3Bv bnNlIHRvIG1vZGlmeSB0aGUgcmVtb3RlIHRhcmdldCB3aGlsZQ0KPiAgIGFuIElOVklURSB0cmFu c2FjdGlvbiBpcyBpbiBwcm9ncmVzcywgYW5kIGl0IGlzIGEgVUFTIGZvciB0aGF0IElOVklURQ0K PiAgIHRyYW5zYWN0aW9uLCBpdCBNVVNUIHBsYWNlIHRoZSBzYW1lIHZhbHVlIGludG8gdGhlIENv bnRhY3QgaGVhZGVyDQo+ICAgZmllbGQgb2YgdGhlIDJ4eCB0byB0aGUgSU5WSVRFIHRoYXQgaXQg cGxhY2VkIGludG8gdGhlIFVQREFURSByZXF1ZXN0DQo+ICAgb3IgcmVzcG9uc2UuDQo+DQo+SWYg dGhlIFVQREFURSBpcyBpbi1zY29wZSBvZiBSZS1JTlZJVEUsIHRoZSAyeHgncyBjb250YWN0IHNo b3VsZCBiZSB0aGUgDQo+c2FtZSBhcyB0aGUgKGxhc3QpIFVQREFURSdzIGNvbnRhY3QuIFNvLCB0 aGUgc2Vjb25kIGNoYXJ0IGNhbiBvbmx5IGhhcyANCnRoZSANCj5pbnRlcnByZXRhdGlvbiBhcyB0 aGUgZmlyc3QgY2hhcnQuIFRoZW4sIHRoZXJlJ3Mgbm8gYW1iaWd1b3VzIA0KPnJlcHJlc2VudGF0 aW9uIGhlcmUuDQo+DQo+T0tVTVVSQSBTaGluamkgPHNoaW5qaS5va3VtdXJhQHNvZnRmcm9udC5q cD4gDQo+MjAxMC0wNS0yOCAwOToyMQ0KPlJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBjb3Jl LXJlaW52aXRlLTA0OiBnbGFyZSBhbmQgVVBEQVRFd2l0aG91dCBTRFANCj4NCj5HYW8sDQo+DQo+ SSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIGEgdGFyZ2V0LXJlZnJlc2guDQo+DQo+SWYgYSBV QVMgcmV0dXJuIDE4eC1yZWwsIDJ4eCB0byByZUlOVklURSBhbmQgYW4gVVBEQVRFLA0KPmFuZCBl YWNoIHJlc3BvbnNlIGhhcyBhIGRpZmZlcmVudCBDb250YWN0LVVSSShpdCBpcyBhIHJlbW90ZQ0K PnRhcmdldCBmb3IgYSBVQUMpLCB0aGVuIGhvdyBzaG91bGQgdGhlIFVBQyBoYW5kbGUgdGhlIFVQ REFURQ0KPmFuZCB0aGUgcmVtb3RlIHRhcmdldHM/DQo+DQo+SG93IGRvZXMgeW91ciBhbmFseXpl ciB3b3JrPw0KPlBsZWFzZSBleHBsYWluIGl0IGNvbmNyZXRlbHkgaW4gb3JkZXIuDQo+DQo+ICAg IEEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQg0KPiAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4gICAgfHJlLUlOViAob2ZmZXIxKSAgICAgICAgICAgICAgICB8 DQo+ICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KPiAgICB8ICAgICAgICAg ICAgICAgMTh4LXJlbChhbnN3ZXIxKXwgbTpjMQ0KPiAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLXwNCj4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgMnh4KElOVil8IG06YzIN Cj4gICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQo+ICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgVVBEQVRFfCBtOmMzDQo+ICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tfA0KPiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj5vcg0K PiAgICBBICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEINCj4gICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQo+ICAgIHxyZS1JTlYgKG9mZmVyMSkgICAgICAgICAgICAg ICAgfA0KPiAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgfCAgICAg ICAgICAgICAgIDE4eC1yZWwoYW5zd2VyMSl8IG06YzENCj4gICAgfDwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS18DQo+ICAgIHwgICAgICAgICAgICAgICAgICAgICAgIDJ4eChJTlYpfCBt OmMyDQo+ICAgIHw8LS0tLS0tLS0tXCAvLS0tLS0tLS0tLS0tLS0tLS0tfA0KPiAgICB8ICAgICAg ICAgICBYICAgICAgICAgICAgIFVQREFURXwgbTpjMw0KPiAgICB8PC0tLS0tLS0tLS8gXC0tLS0t LS0tLS0tLS0tLS0tLXwNCj4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ DQo+UmVnYXJkcywNCj5TaGluamkNCj4NCj4+PiBIb3cgY2FuIHlvdSBvbmx5IGFwcGx5ICJjaGVj a2luZyBmb3IgZ2xhcmUgc2l0dWF0aW9ucyIgZHVyaW5nIGEgDQo+Pj4gZ2xhcmUgc2l0dWF0aW9u Pw0KPj4+IA0KPj4+IENoZWNraW5nIGZvciBvZmZlci9hbnN3ZXIgZ2xhcmUgaXMgcGFydCBvZiBu b3JtYWwgUkZDMzMxMSBVUERBVEUgDQo+PnByb2Nlc3NpbmcuDQo+Pg0KPj5NYWtpbmcgdHdvIGFu YWx5emVycyBpbiBzZXJpZXMgYXM6DQo+Pg0KPj4tLS0+IGFuYWx5emVyMSAtLS0tLT4gYW5hbHl6 ZXIyIC0tLS0+DQo+Pg0KPj5hbmFseXplcjEgdXNpbmcgdGhlIHJ1bGVzIGluIFJGQzMzMTEsIGFu ZCBpZiB0aGVyZSdzIGdsYXJlcyBjYXNlIHVuZGVyIA0KPj5pdCdzIHJ1bGUsIHNlbmQgNDkxIG9y ICg1MDArcmV0cnkpIGRpcmVjdGx5Ow0KPj5hbmFseXplcjIgdXNpbmcgdGhlIHJ1bGVzIGluIHRo ZSBkcmFmdC4gDQo+Pg0KPj5hbmFseXplcjIgYWxzbyBoYXMgdHdvIHByb2Nlc3M6DQo+PjEuIENo ZWNrIHdoZXRoZXIgaXQgY2FuIGRvIHRoZSBvcmRlcmluZyBvZiAyeHgoSU5WSVRFKWFuZCBVUERB VEUuIElmIA0KPj5pdCANCj4+Y2FuIGRvIHNvLCBwYXNzIHRoZSBVUERBVEUgdG8gdGhlIG5leHQg c3RlcCBub3JtYWxseTsNCj4+Mi4gSWYgaXQgY2FuIG5vdCBkbyB0aGUgb3JkZXJpbmcsIGhhbmRs ZSB0aGUgVVBEQVRFIGFuZCAyeHgoSU5WSVRFKSBhcyANCj4+aWYgDQo+Pml0IGNvbnRhaW5zIE9m ZmVyIGFuZCB1c2luZyBPL0EgcnVsZXMgdG8gcmVqZWN0Lg0KPj4NCj4+VGhlIGVmZmVjdGVkIGNh c2VzL3NpdXRhdGlvbiBpcyBvbmx5IHRoZXNlIGNhc2VzL3NpdHVhdGlvbiB3aGljaCBhcmUgDQo+ PmFtYmlndW91cyBiZWZvcmUgdGhlIGRyYWZ0Lg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0025964748257731_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllvdSB0d28gY2hhcnRzIGhhcyBk aWZmZXJlbmNlIGFzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Rmlyc3QgY2hhcnQ6IDJ4eCBiZWZvcmUgVVBEQVRFOyA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlVBQyBjYW4gdHJlYXRlIHRoZSBVUERBVEUncyBjb250 YWN0DQphcyB0aGUgbmV3IG9uZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlNlY29uZCBjaGFydDogVVBEQVRFIGJlZm9yZSAyeHguPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGd1ZXNzIHlvdXIgcHV6emxlIGhlcmUg aXMgYWJvdXQgaG93DQpVQUMgY2FuIG9yZGVyIHRoZSBzZXF1ZW5jZSwgdGhhdCBpcyAmcXVvdDtV UERBVEUgYmVmb3JlIDJ4eCZxdW90OyBvciAmcXVvdDsyeHgNCmJlZm9yZSBVUERBVEUmcXVvdDsu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHNob3dl ZCB0aGF0LCBpZiB0aGUgVVBEQVRFIGhhcyBkaWZmZXJlbnQNCnRhcmdldCwgaXQgTVVTVCBiZSBz ZW5kZWQgYWZ0ZXIgdGhlIDJ4eCBieSBVQVMuIFRoZSByZWFzb24gaXMgdGhhdCwgaWYNClVQREFU RSBoYXMgYSBkaWZmZXJlbnQgdGFyZ2V0KGNvbXBhcmVkIGFzIHRoZSBzdGF0ZSBiZWZvcmUgdGhp cyBVUERBVEUpLA0KdGhlIDJ4eCBNVVNUIGhhcyB0aGUgc2FtZSBvbmUuKHRoaXMgaXMgZGVmaW5l ZCBpbiBSRkMzMzExKS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkFzIHRoaXMsIHRoZSBVQUMgY2FuIHRyZWF0ZSB0aGlzIFVQREFURQ0KYWZ0ZXIgMnh4 IGFuZCAmbmJzcDtVUERBVEUncyB0YXJnZXQgaXMgbmV3ZXIsIG5vIG1hdHRlciB3aGljaCBvbmUg cmVhY2hzDQpVQUMgZmlyc3RseS48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+T0tVTVVSQSBTaGluamkgJmx0O3NoaW5qaS5va3VtdXJh QHNvZnRmcm9udC5qcCZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+MjAxMC0wNS0yOCAxNDoxODwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5zaXBjb3JlQGlldGYub3JnPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5nYW8ueWFuZzJAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzaXBjb3Jl XSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6DQpnbGFyZSBhbmQgVVBEQVRFIHdpdGhv dXQgU0RQPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5HYW8sPGJyPg0KPGJyPg0KVGhlIElOVklURSB0cmFuc2FjdGlvbiBoYXMgYmVlbiBh bHJlYWR5IGNvbXBsZXRlZCBhdCB0aGUgcG9pbnQ8YnI+DQp0byBzZW5kIHRoZSBVUERBVEUuIElu IG15IHVuZGVyc3RhbmRpbmcsIHRoZSBVUERBVEUgY2FuIGhhdmUgYTxicj4NCmRpZmZlcmVudCBD b250YWN0Ljxicj4NCjxicj4NCkFmdGVyIGFsbCwgeW91IHNheSB0aGF0PGJyPg0KaW4gMXN0IGNo YXJ0LCBVQUMgbWF5IHJldHVybiAyeHggdG8gdGhlIFVQREFURSBhbmQ8YnI+DQppbiAybmQgY2hh cnQsIGl0IHNob3VsZChtdXN0PykgcmV0dXJuIDR4eC48YnI+DQo8YnI+DQpJcyB0aGF0IHJpZ2h0 Pzxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KU2hpbmppPGJyPg0KPGJyPg0KZ2FvLnlhbmcyQHp0 ZS5jb20uY248YnI+DQpGcmksIDI4IE1heSAyMDEwIDEyOjQ1OjQ5ICswODAwPGJyPg0KJmd0O09u bHkgdGhlIGZpcnN0IGNoYXJ0IGlzIGxhd2Z1bC4gQXMgdGhlIHRleHQgZnJvbSBSRkMzMzExOjxi cj4NCiZndDs8YnI+DQomZ3Q7SWYgYSBVQTxicj4NCiZndDsgJm5ic3A7IHVzZXMgYW4gVVBEQVRF IHJlcXVlc3Qgb3IgcmVzcG9uc2UgdG8gbW9kaWZ5IHRoZSByZW1vdGUgdGFyZ2V0DQp3aGlsZTxi cj4NCiZndDsgJm5ic3A7IGFuIElOVklURSB0cmFuc2FjdGlvbiBpcyBpbiBwcm9ncmVzcywgYW5k IGl0IGlzIGEgVUFTIGZvciB0aGF0DQpJTlZJVEU8YnI+DQomZ3Q7ICZuYnNwOyB0cmFuc2FjdGlv biwgaXQgTVVTVCBwbGFjZSB0aGUgc2FtZSB2YWx1ZSBpbnRvIHRoZSBDb250YWN0DQpoZWFkZXI8 YnI+DQomZ3Q7ICZuYnNwOyBmaWVsZCBvZiB0aGUgMnh4IHRvIHRoZSBJTlZJVEUgdGhhdCBpdCBw bGFjZWQgaW50byB0aGUgVVBEQVRFDQpyZXF1ZXN0PGJyPg0KJmd0OyAmbmJzcDsgb3IgcmVzcG9u c2UuPGJyPg0KJmd0Ozxicj4NCiZndDtJZiB0aGUgVVBEQVRFIGlzIGluLXNjb3BlIG9mIFJlLUlO VklURSwgdGhlIDJ4eCdzIGNvbnRhY3Qgc2hvdWxkIGJlDQp0aGUgPGJyPg0KJmd0O3NhbWUgYXMg dGhlIChsYXN0KSBVUERBVEUncyBjb250YWN0LiBTbywgdGhlIHNlY29uZCBjaGFydCBjYW4gb25s eQ0KaGFzIHRoZSA8YnI+DQomZ3Q7aW50ZXJwcmV0YXRpb24gYXMgdGhlIGZpcnN0IGNoYXJ0LiBU aGVuLCB0aGVyZSdzIG5vIGFtYmlndW91cyA8YnI+DQomZ3Q7cmVwcmVzZW50YXRpb24gaGVyZS48 YnI+DQomZ3Q7PGJyPg0KJmd0O09LVU1VUkEgU2hpbmppICZsdDtzaGluamkub2t1bXVyYUBzb2Z0 ZnJvbnQuanAmZ3Q7IDxicj4NCiZndDsyMDEwLTA1LTI4IDA5OjIxPGJyPg0KJmd0O1JlOiBbc2lw Y29yZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0OiBnbGFyZSBhbmQgVVBEQVRFd2l0 aG91dA0KU0RQPGJyPg0KJmd0Ozxicj4NCiZndDtHYW8sPGJyPg0KJmd0Ozxicj4NCiZndDtJIGhh dmUgYSBxdWVzdGlvbiByZWdhcmRpbmcgYSB0YXJnZXQtcmVmcmVzaC48YnI+DQomZ3Q7PGJyPg0K Jmd0O0lmIGEgVUFTIHJldHVybiAxOHgtcmVsLCAyeHggdG8gcmVJTlZJVEUgYW5kIGFuIFVQREFU RSw8YnI+DQomZ3Q7YW5kIGVhY2ggcmVzcG9uc2UgaGFzIGEgZGlmZmVyZW50IENvbnRhY3QtVVJJ KGl0IGlzIGEgcmVtb3RlPGJyPg0KJmd0O3RhcmdldCBmb3IgYSBVQUMpLCB0aGVuIGhvdyBzaG91 bGQgdGhlIFVBQyBoYW5kbGUgdGhlIFVQREFURTxicj4NCiZndDthbmQgdGhlIHJlbW90ZSB0YXJn ZXRzPzxicj4NCiZndDs8YnI+DQomZ3Q7SG93IGRvZXMgeW91ciBhbmFseXplciB3b3JrPzxicj4N CiZndDtQbGVhc2UgZXhwbGFpbiBpdCBjb25jcmV0ZWx5IGluIG9yZGVyLjxicj4NCiZndDs8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDtBICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBCPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNw O3xyZS1JTlYgKG9mZmVyMSkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTh4LXJlbChhbnN3ZXIxKXwN Cm06YzE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLXw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IDJ4 eChJTlYpfCBtOmMyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS18PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgVVBEQVRFfCBtOmMzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCZsdDstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDtv cjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0EgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7fHJlLUlOViAob2ZmZXIxKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxOHgtcmVsKGFuc3dl cjEpfA0KbTpjMTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3wmbHQ7LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgMnh4KElOVil8IG06YzI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8Jmx0Oy0tLS0tLS0tLVwg Ly0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWCAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgVVBEQVRFfCBtOmMzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCZsdDstLS0t LS0tLS0vIFwtLS0tLS0tLS0tLS0tLS0tLS18PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDs8 YnI+DQomZ3Q7UmVnYXJkcyw8YnI+DQomZ3Q7U2hpbmppPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBIb3cgY2FuIHlvdSBvbmx5IGFwcGx5ICZxdW90O2NoZWNraW5nIGZvciBnbGFyZSBzaXR1 YXRpb25zJnF1b3Q7DQpkdXJpbmcgYSA8YnI+DQomZ3Q7Jmd0OyZndDsgZ2xhcmUgc2l0dWF0aW9u Pzxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgQ2hlY2tpbmcgZm9yIG9mZmVy L2Fuc3dlciBnbGFyZSBpcyBwYXJ0IG9mIG5vcm1hbCBSRkMzMzExDQpVUERBVEUgPGJyPg0KJmd0 OyZndDtwcm9jZXNzaW5nLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtNYWtpbmcgdHdvIGFu YWx5emVycyBpbiBzZXJpZXMgYXM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Oy0tLSZndDsg YW5hbHl6ZXIxIC0tLS0tJmd0OyBhbmFseXplcjIgLS0tLSZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7YW5hbHl6ZXIxIHVzaW5nIHRoZSBydWxlcyBpbiBSRkMzMzExLCBhbmQgaWYgdGhl cmUncyBnbGFyZXMgY2FzZQ0KdW5kZXIgPGJyPg0KJmd0OyZndDtpdCdzIHJ1bGUsIHNlbmQgNDkx IG9yICg1MDArcmV0cnkpIGRpcmVjdGx5Ozxicj4NCiZndDsmZ3Q7YW5hbHl6ZXIyIHVzaW5nIHRo ZSBydWxlcyBpbiB0aGUgZHJhZnQuIDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDthbmFseXpl cjIgYWxzbyBoYXMgdHdvIHByb2Nlc3M6PGJyPg0KJmd0OyZndDsxLiBDaGVjayB3aGV0aGVyIGl0 IGNhbiBkbyB0aGUgb3JkZXJpbmcgb2YgMnh4KElOVklURSlhbmQgVVBEQVRFLg0KSWYgPGJyPg0K Jmd0OyZndDtpdCA8YnI+DQomZ3Q7Jmd0O2NhbiBkbyBzbywgcGFzcyB0aGUgVVBEQVRFIHRvIHRo ZSBuZXh0IHN0ZXAgbm9ybWFsbHk7PGJyPg0KJmd0OyZndDsyLiBJZiBpdCBjYW4gbm90IGRvIHRo ZSBvcmRlcmluZywgaGFuZGxlIHRoZSBVUERBVEUgYW5kIDJ4eChJTlZJVEUpDQphcyA8YnI+DQom Z3Q7Jmd0O2lmIDxicj4NCiZndDsmZ3Q7aXQgY29udGFpbnMgT2ZmZXIgYW5kIHVzaW5nIE8vQSBy dWxlcyB0byByZWplY3QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O1RoZSBlZmZlY3RlZCBj YXNlcy9zaXV0YXRpb24gaXMgb25seSB0aGVzZSBjYXNlcy9zaXR1YXRpb24gd2hpY2gNCmFyZSA8 YnI+DQomZ3Q7Jmd0O2FtYmlndW91cyBiZWZvcmUgdGhlIGRyYWZ0Ljxicj4NCjxicj4NCjwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1 cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5l ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3By b3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4m bmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZp ZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZu YnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5k Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZu YnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55 Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZu YnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7 Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5i c3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5i c3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25v dGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3Nh Z2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu ZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2Jl ZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0m bmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0025964748257731_=-- From shinji.okumura@softfront.jp Fri May 28 00:10:38 2010 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 E29523A686C for ; Fri, 28 May 2010 00:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.702 X-Spam-Level: X-Spam-Status: No, score=-94.702 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 BAZ9cJZqlWiA for ; Fri, 28 May 2010 00:10:36 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 7DC593A6818 for ; Fri, 28 May 2010 00:10:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 142EC42801B; Fri, 28 May 2010 16:10:26 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lXprVJ1Xnym; Fri, 28 May 2010 16:10:21 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 90B6142801A; Fri, 28 May 2010 16:10:20 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 28 May 2010 16:10:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Fri, 28 May 2010 07:10:38 -0000 Gao, I understand. The text says that the UAC can not expect to receive a 487 response to the INVITE. Right? And now, assuming that some of changes have already been executed, the UAS would send a new UPDATE to undo the changes. But the local target of the UAC has been changed, so I think UAC should an UPDATE to announce own new target before sending the CANCEL. Do you think so? Regards, Shinji gao.yang2@zte.com.cn Fri, 28 May 2010 13:09:35 +0800 >> Following texts seem to be conflicted. >> >> 3.8. Clarifications on Cancelling Re-INVITEs >> Per >> the rules specified in Section 3.3, if the INVITE request was a re- >> INVITE and some of its requested changes had already been executed, >> the UAS would return a 2xx response instead. > >This is about UAS's behavior. > >> >> 5.5. UAC Losing its Contact: UAC Behavior >> Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE >> and cause the INVITE client transaction corresponding to the re- >> INVITE to enter the "Terminated" state. > >This is about UAC's behavior. And which(2xx/Non-2xx) final response UAS >would send is defined in section 3.8. > >As the UAC may not get the final response from UAS, it should send a new >Re-INVITE(/UPDATE) to synchronize the state. >And this is defined in the draft. > >This is the understanding while I did the review for this part, and I keep >my understanding as so. From christer.holmberg@ericsson.com Fri May 28 00:35:00 2010 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 9462B3A6768 for ; Fri, 28 May 2010 00:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.888 X-Spam-Level: X-Spam-Status: No, score=-4.888 tagged_above=-999 required=5 tests=[AWL=1.711, 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 wB5axTbHm-nH for ; Fri, 28 May 2010 00:34:59 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 862BE3A6811 for ; Fri, 28 May 2010 00:34:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7b73ae00000711c-4c-4bff6e769194 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.5A.28956.67E6FFB4; Fri, 28 May 2010 09:19:18 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 28 May 2010 09:19:18 +0200 From: Christer Holmberg To: OKUMURA Shinji , "gao.yang2@zte.com.cn" , Brett Tate Date: Fri, 28 May 2010 09:19:16 +0200 Thread-Topic: [sipcore] New deal - IDEA [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] Thread-Index: Acr+F2SJTgBZBgr9R3yXrfOLmMKYpAAHm3mg Message-ID: References: <94CAFE17605BCDshinji.okumura@softfront.jp> In-Reply-To: <94CAFE17605BCDshinji.okumura@softfront.jp> 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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] New deal - IDEA [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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, 28 May 2010 07:35:00 -0000 Hi,=20 >>IDEA #2: Target update: Only outside re-INVITEs >> >>Let's forbid target updates "inside" re-INVITEs. I really=20 >>doubt there is a need for those while the UAs are doing something else wi= th the=20 >>re-INVITE. >> >>That at least solves the glare situation where the remote=20 >>target may be updated in a re-INVITE response and an UPDATE response. >=20 >In the same sequence, since it is not possible to forbid a=20 >offer-anser, the idea seems to be ineffective. >At least it might be difficult to actually use the rule. >=20 >For example, when a 2xx response to an UPDATE within an=20 >INVITE transaction include both new remote target and an=20 >answer, how should the UAS handle the response? As I said, the UPDATE request and/or response within the INVITE transation = must not include a new remote target. =20 Regards, Christer= From shinji.okumura@softfront.jp Fri May 28 00:35:34 2010 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 281393A6883 for ; Fri, 28 May 2010 00:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.198 X-Spam-Level: X-Spam-Status: No, score=-93.198 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, FRT_SLUT=2.522, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_64=0.6, RELAY_IS_221=2.222, 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 1hc+y1mXD2pD for ; Fri, 28 May 2010 00:35:33 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id F14043A6874 for ; Fri, 28 May 2010 00:35:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 0EB3C42801C; Fri, 28 May 2010 16:35:23 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGR-9ygcuoaB; Fri, 28 May 2010 16:35:18 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id D3DA842801A; Fri, 28 May 2010 16:35:17 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 28 May 2010 16:35:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 28 May 2010 07:35:34 -0000 Gao, gao.yang2@zte.com.cn Fri, 28 May 2010 14:48:19 +0800 >You two charts has difference as: > >First chart: 2xx before UPDATE; >UAC can treate the UPDATE's contact as the new one. > >Second chart: UPDATE before 2xx. >I guess your puzzle here is about how UAC can order the sequence, that is >"UPDATE before 2xx" or "2xx before UPDATE". I agree this is a puzzle. But your analyzer has to figure out this puzzle. >I showed that, if the UPDATE has different target, it MUST be sended after >the 2xx by UAS. The reason is that, if UPDATE has a different >target(compared as the state before this UPDATE), the 2xx MUST has the >same one.(this is defined in RFC3311). > >As this, the UAC can treate this UPDATE after 2xx and UPDATE's target is >newer, no matter which one reachs UAC firstly. After all, you say that in both case UAC may return 2xx to the UPDATE. BUT your analyzer2 seems to say "Reject it!". > 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as > if contains Offer and using O/A rules to reject. Regards, Shinji >OKUMURA Shinji >2010-05-28 14:18 >Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP > >Gao, > >The INVITE transaction has been already completed at the point >to send the UPDATE. In my understanding, the UPDATE can have a >different Contact. > >After all, you say that >in 1st chart, UAC may return 2xx to the UPDATE and >in 2nd chart, it should(must?) return 4xx. > >Is that right? > >Regards, >Shinji > >gao.yang2@zte.com.cn >Fri, 28 May 2010 12:45:49 +0800 >>Only the first chart is lawful. As the text from RFC3311: >> >>If a UA >> uses an UPDATE request or response to modify the remote target while >> an INVITE transaction is in progress, and it is a UAS for that INVITE >> transaction, it MUST place the same value into the Contact header >> field of the 2xx to the INVITE that it placed into the UPDATE request >> or response. >> >>If the UPDATE is in-scope of Re-INVITE, the 2xx's contact should be the >>same as the (last) UPDATE's contact. So, the second chart can only has >the >>interpretation as the first chart. Then, there's no ambiguous >>representation here. >> >>OKUMURA Shinji >>2010-05-28 09:21 >>Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP >> >>Gao, >> >>I have a question regarding a target-refresh. >> >>If a UAS return 18x-rel, 2xx to reINVITE and an UPDATE, >>and each response has a different Contact-URI(it is a remote >>target for a UAC), then how should the UAC handle the UPDATE >>and the remote targets? >> >>How does your analyzer work? >>Please explain it concretely in order. >> >> A B >> | | >> |re-INV (offer1) | >> |------------------------------>| >> | 18x-rel(answer1)| m:c1 >> |<------------------------------| >> | 2xx(INV)| m:c2 >> |<------------------------------| >> | UPDATE| m:c3 >> |<------------------------------| >> | | >>or >> A B >> | | >> |re-INV (offer1) | >> |------------------------------>| >> | 18x-rel(answer1)| m:c1 >> |<------------------------------| >> | 2xx(INV)| m:c2 >> |<---------\ /------------------| >> | X UPDATE| m:c3 >> |<---------/ \------------------| >> | | >> >>Regards, >>Shinji >> >>>> How can you only apply "checking for glare situations" during a >>>> glare situation? >>>> >>>> Checking for offer/answer glare is part of normal RFC3311 UPDATE >>>processing. >>> >>>Making two analyzers in series as: >>> >>>---> analyzer1 -----> analyzer2 ----> >>> >>>analyzer1 using the rules in RFC3311, and if there's glares case under >>>it's rule, send 491 or (500+retry) directly; >>>analyzer2 using the rules in the draft. >>> >>>analyzer2 also has two process: >>>1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If >>>it >>>can do so, pass the UPDATE to the next step normally; >>>2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as >>>if >>>it contains Offer and using O/A rules to reject. >>> >>>The effected cases/siutation is only these cases/situation which are >>>ambiguous before the draft. From shinji.okumura@softfront.jp Fri May 28 00:54:59 2010 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 0280A3A686D for ; Fri, 28 May 2010 00:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.884 X-Spam-Level: X-Spam-Status: No, score=-95.884 tagged_above=-999 required=5 tests=[AWL=1.984, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 3woURF1UOqDf for ; Fri, 28 May 2010 00:54:58 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 466C13A6811 for ; Fri, 28 May 2010 00:54:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id F03D442801A; Fri, 28 May 2010 16:54:47 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MAplxYv9ShG; Fri, 28 May 2010 16:54:46 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id C41EE42800E; Fri, 28 May 2010 16:54:45 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Fri, 28 May 2010 16:54:44 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: <94CAFE17605BCDshinji.okumura@softfront.jp> Message-Id: <27CAFE3B09763Dshinji.okumura@softfront.jp> Cc: "gao.yang2@zte.com.cn" Subject: Re: [sipcore] New deal - IDEA [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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, 28 May 2010 07:54:59 -0000 Christer, We have to prepare to recieve something forbidden. A UAC cannot reject a response to the UPDATE, even if it include a new remote target. So does the UAC ignore only the target? Regards, shinji Christer Holmberg Fri, 28 May 2010 09:19:16 +0200 >Hi, > >>>IDEA #2: Target update: Only outside re-INVITEs >>> >>>Let's forbid target updates "inside" re-INVITEs. I really >>>doubt there is a need for those while the UAs are doing something else with the >>>re-INVITE. >>> >>>That at least solves the glare situation where the remote >>>target may be updated in a re-INVITE response and an UPDATE response. >> >>In the same sequence, since it is not possible to forbid a >>offer-anser, the idea seems to be ineffective. >>At least it might be difficult to actually use the rule. >> >>For example, when a 2xx response to an UPDATE within an >>INVITE transaction include both new remote target and an >>answer, how should the UAS handle the response? > >As I said, the UPDATE request and/or response within the >INVITE transation must not include a new remote target. > >Regards, > >Christer From christer.holmberg@ericsson.com Fri May 28 00:59:27 2010 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 B14813A686C for ; Fri, 28 May 2010 00:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.965 X-Spam-Level: X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=1.634, 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 OwKNHr0fJBgw for ; Fri, 28 May 2010 00:59:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 47F9E3A6811 for ; Fri, 28 May 2010 00:59:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7b73ae00000711c-3d-4bff77d3104a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2C.E0.28956.3D77FFB4; Fri, 28 May 2010 09:59:15 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 28 May 2010 09:59:15 +0200 From: Christer Holmberg To: OKUMURA Shinji , "sipcore@ietf.org" Date: Fri, 28 May 2010 09:59:14 +0200 Thread-Topic: [sipcore] New deal - IDEA [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] Thread-Index: Acr+Ow5eBbipZV5XRiuCq4Efu2HkJwAAIINw Message-ID: References: <94CAFE17605BCDshinji.okumura@softfront.jp> <27CAFE3B09763Dshinji.okumura@softfront.jp> In-Reply-To: <27CAFE3B09763Dshinji.okumura@softfront.jp> 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-Brightmail-Tracker: AAAAAA== Cc: "gao.yang2@zte.com.cn" Subject: Re: [sipcore] New deal - IDEA [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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, 28 May 2010 07:59:27 -0000 Hi,=20 >We have to prepare to recieve something forbidden. >A UAC cannot reject a response to the UPDATE, even if it=20 >include a new remote target. So does the UAC ignore only the target? Correct - in the same way as it would ignore a "new" SDP answer. Regards, Christer > Christer Holmberg Fri, 28=20 > May 2010 09:19:16 +0200 > >Hi, > > > >>>IDEA #2: Target update: Only outside re-INVITEs > >>> > >>>Let's forbid target updates "inside" re-INVITEs. I really=20 > doubt there=20 > >>>is a need for those while the UAs are doing something else=20 > with the=20 > >>>re-INVITE. > >>> > >>>That at least solves the glare situation where the remote=20 > target may=20 > >>>be updated in a re-INVITE response and an UPDATE response. > >>=20 > >>In the same sequence, since it is not possible to forbid a=20 > >>offer-anser, the idea seems to be ineffective. > >>At least it might be difficult to actually use the rule. > >>=20 > >>For example, when a 2xx response to an UPDATE within an INVITE=20 > >>transaction include both new remote target and an answer,=20 > how should=20 > >>the UAS handle the response? > > > >As I said, the UPDATE request and/or response within the INVITE=20 > >transation must not include a new remote target. > >=20 > >Regards, > > > >Christer > = From gao.yang2@zte.com.cn Sat May 29 10:34:50 2010 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 0E2293A6852; Sat, 29 May 2010 10:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.206 X-Spam-Level: X-Spam-Status: No, score=-96.206 tagged_above=-999 required=5 tests=[AWL=2.432, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, 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 m0vHIggpST-0; Sat, 29 May 2010 10:34:49 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 8C7923A6832; Sat, 29 May 2010 10:34:48 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580712001811080; Sun, 30 May 2010 01:28:26 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 87322.3289705602; Fri, 28 May 2010 16:37:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4S8gCQm008964; Fri, 28 May 2010 16:42:12 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 28 May 2010 16:39:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-28 16:41:53, Serialize complete at 2010-05-28 16:41:53 Content-Type: multipart/alternative; boundary="=_alternative 002FC06348257731_=" X-MAIL: mse2.zte.com.cn o4S8gCQm008964 Cc: sipcore@ietf.org, sipcore-bounces@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Sat, 29 May 2010 17:34:50 -0000 This is a multipart message in MIME format. --=_alternative 002FC06348257731_= Content-Type: text/plain; charset="US-ASCII" > > I understand. > > The text says that the UAC can not expect to receive a 487 > response to the INVITE. Right? As UAC's old contact has been lost, UAC can not expect to receive any final response for the old Re-INVITE here. So, the specific for final response is not important here. And the UAC's next Re-INVITE as synchronization can refresh the state here. > > And now, assuming that some of changes have already been > executed, the UAS would send a new UPDATE to undo the changes. > But the local target of the UAC has been changed, so I think UAC > should an UPDATE to announce own new target before sending the > CANCEL. > > Do you think so? I think the UAC should send a target refresh UPDATE before CANCEL. But the reason is not about UAS's rollback usage UPDATE.(the state would be synchronized by a next Re-INVITE). To send a new request(the CANCEL) at new address, sending a target refresh UPDATE before the new request (the CANCEL) might be better. -------------------------------------------------------- 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 002FC06348257731_= Content-Type: text/html; charset="US-ASCII"

>
> I understand.
>
> The text says that the UAC can not expect to receive a 487
> response to the INVITE. Right?

As UAC's old contact has been lost, UAC can not expect to receive any final response for the old Re-INVITE here.
So, the specific for final response is not important here. And the UAC's next Re-INVITE as synchronization can refresh the state here.

>
> And now, assuming that some of changes have already been
> executed, the UAS would send a new UPDATE to undo the changes.
> But the local target of the UAC has been changed, so I think UAC
> should an UPDATE to announce own new target before sending the
> CANCEL.
>
> Do you think so?

I think the UAC should send a target refresh UPDATE before CANCEL. But the reason is not about UAS's rollback usage UPDATE.(the state would be synchronized by a next Re-INVITE).

To send a new request(the CANCEL) at new address, sending a target refresh UPDATE before the new request (the CANCEL) might be better. 

--------------------------------------------------------
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 002FC06348257731_=-- From gao.yang2@zte.com.cn Sat May 29 10:39:38 2010 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 C4A173A68F1 for ; Sat, 29 May 2010 10:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.413 X-Spam-Level: X-Spam-Status: No, score=-97.413 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_50=0.001, 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 hoM1cpVy-4S0 for ; Sat, 29 May 2010 10:39:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 22A703A688D for ; Sat, 29 May 2010 10:39:36 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Sun, 30 May 2010 01:32:38 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 87322.3015714703; Fri, 28 May 2010 16:52:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4S8uuEt043646; Fri, 28 May 2010 16:57:10 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 28 May 2010 16:54:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-28 16:56:51, Serialize complete at 2010-05-28 16:56:51 Content-Type: multipart/alternative; boundary="=_alternative 00311E8B48257731_=" X-MAIL: mse2.zte.com.cn o4S8uuEt043646 Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 29 May 2010 17:39:38 -0000 This is a multipart message in MIME format. --=_alternative 00311E8B48257731_= Content-Type: text/plain; charset="US-ASCII" > After all, you say that in both case UAC may return 2xx to the > UPDATE. > > BUT your analyzer2 seems to say "Reject it!". > > 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as > > if contains Offer and using O/A rules to reject. > As the analyzer show is aimed for Brett's puzzle. That is 2xx(of Re-INVITE) and UPDATE on different direction, mentioned in section 4.5 of the draft. Your case is not so. Our aim is to clear up ambiguity case, to cover your case, I'd like to add a new restriction highlighted in the analyzer2. ---> analyzer1 -----> analyzer2 ----> analyzer1 using the rules in RFC3311, and if there's glares case under it's rule, send 491 or (500+retry) directly; analyzer2 using the rules in the draft. analyzer2 also has two process: 1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If it can do so, pass the UPDATE to the next step normally; 2. If there is ambiguity and UAs can not do the ordering, handle the UPDATE and 2xx(INVITE) as if it contains Offer and using O/A rules to reject. -------------------------------------------------------- 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 00311E8B48257731_= Content-Type: text/html; charset="US-ASCII"

> After all, you say that in both case UAC may return 2xx to the
> UPDATE.
>
> BUT your analyzer2 seems to say "Reject it!".
> > 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as
> > if contains Offer and using O/A rules to reject.
>

As the analyzer show is aimed for Brett's puzzle. That is 2xx(of Re-INVITE) and UPDATE on different direction, mentioned in section 4.5 of the draft. Your case is not so.  

Our aim is to clear up ambiguity case, to cover your case, I'd like to add a new restriction highlighted in the analyzer2.

---> analyzer1 -----> analyzer2 ---->

analyzer1 using the rules in RFC3311, and if there's glares case under it's rule, send 491 or (500+retry) directly;
analyzer2 using the rules in the draft.

analyzer2 also has two process:
1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If it can do so, pass the UPDATE to the next step normally;
2. If there is ambiguity and UAs can not do the ordering, handle the UPDATE and 2xx(INVITE) as if it contains Offer and using O/A rules to reject. 


--------------------------------------------------------
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 00311E8B48257731_=-- From gao.yang2@zte.com.cn Sat May 29 11:13:32 2010 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 A97163A685A for ; Sat, 29 May 2010 11:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.617 X-Spam-Level: X-Spam-Status: No, score=-98.617 tagged_above=-999 required=5 tests=[AWL=3.221, 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 7x4ExEosMcO8 for ; Sat, 29 May 2010 11:13:31 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id A27273A688C for ; Sat, 29 May 2010 11:13:30 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Sun, 30 May 2010 02:07:44 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 87322.1727820181; Fri, 28 May 2010 19:04:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4SB9gDa047454 for ; Fri, 28 May 2010 19:09:42 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 28 May 2010 19:06:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-28 19:09:20, Serialize complete at 2010-05-28 19:09:20 Content-Type: multipart/alternative; boundary="=_alternative 003D400C48257731_=" X-MAIL: mse2.zte.com.cn o4SB9gDa047454 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 29 May 2010 18:13:33 -0000 This is a multipart message in MIME format. --=_alternative 003D400C48257731_= Content-Type: text/plain; charset="US-ASCII" //It seams that mail list doesn't dispatch this mail. To let other people catch up the thread, I re-send it. > After all, you say that in both case UAC may return 2xx to the > UPDATE. > > BUT your analyzer2 seems to say "Reject it!". > > 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as > > if contains Offer and using O/A rules to reject. > As the analyzer show is aimed for Brett's puzzle. That is 2xx(of Re-INVITE) and UPDATE on different direction, mentioned in section 4.5 of the draft. Your case is not so. Our aim is to clear up ambiguity case, to cover your case, I'd like to add a new restriction highlighted in the analyzer2. ---> analyzer1 -----> analyzer2 ----> analyzer1 using the rules in RFC3311, and if there's glares case under it's rule, send 491 or (500+retry) directly; analyzer2 using the rules in the draft. analyzer2 also has two process: 1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If it can do so, pass the UPDATE to the next step normally; 2. If there is ambiguity and UAs can not do the ordering, handle the UPDATE and 2xx(INVITE) as if it contains Offer and using O/A rules to reject. -------------------------------------------------------- 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 003D400C48257731_= Content-Type: text/html; charset="US-ASCII"
//It seams that mail list doesn't dispatch this mail. To let other people catch up the thread, I re-send it.

> After all, you say that in both case UAC may return 2xx to the
> UPDATE.
>
> BUT your analyzer2 seems to say "Reject it!".
> > 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as
> > if contains Offer and using O/A rules to reject.
>

As the analyzer show is aimed for Brett's puzzle. That is 2xx(of Re-INVITE) and UPDATE on different direction, mentioned in section 4.5 of the draft. Your case is not so.  

Our aim is to clear up ambiguity case, to cover your case, I'd like to add a new restriction highlighted in the analyzer2.

---> analyzer1 -----> analyzer2 ---->

analyzer1 using the rules in RFC3311, and if there's glares case under it's rule, send 491 or (500+retry) directly;
analyzer2 using the rules in the draft.

analyzer2 also has two process:
1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If it can do so, pass the UPDATE to the next step normally;
2. If there is ambiguity and UAs can not do the ordering, handle the UPDATE and 2xx(INVITE) as if it contains Offer and using O/A rules to reject. 


--------------------------------------------------------
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 003D400C48257731_=-- From gao.yang2@zte.com.cn Sat May 29 11:13:45 2010 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 8E2D13A6901 for ; Sat, 29 May 2010 11:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.122 X-Spam-Level: X-Spam-Status: No, score=-99.122 tagged_above=-999 required=5 tests=[AWL=2.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, 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 WrXscvS7tXyJ for ; Sat, 29 May 2010 11:13:44 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id BA4F03A68DA for ; Sat, 29 May 2010 11:13:43 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Sun, 30 May 2010 02:07:44 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 87322.1727820181; Fri, 28 May 2010 19:04:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4SBANnY047947 for ; Fri, 28 May 2010 19:10:23 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 28 May 2010 19:07:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-28 19:10:01, Serialize complete at 2010-05-28 19:10:01 Content-Type: multipart/alternative; boundary="=_alternative 003D504D48257731_=" X-MAIL: mse2.zte.com.cn o4SBANnY047947 Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Sat, 29 May 2010 18:13:45 -0000 This is a multipart message in MIME format. --=_alternative 003D504D48257731_= Content-Type: text/plain; charset="US-ASCII" //It seams that mail list doesn't dispatch this mail. To let other people catch up the thread, I re-send it. > > I understand. > > The text says that the UAC can not expect to receive a 487 > response to the INVITE. Right? As UAC's old contact has been lost, UAC can not expect to receive any final response for the old Re-INVITE here. So, the specific for final response is not important here. And the UAC's next Re-INVITE as synchronization can refresh the state here. > > And now, assuming that some of changes have already been > executed, the UAS would send a new UPDATE to undo the changes. > But the local target of the UAC has been changed, so I think UAC > should an UPDATE to announce own new target before sending the > CANCEL. > > Do you think so? I think the UAC should send a target refresh UPDATE before CANCEL. But the reason is not about UAS's rollback usage UPDATE.(the state would be synchronized by a next Re-INVITE). To send a new request(the CANCEL) at new address, sending a target refresh UPDATE before the new request (the CANCEL) might be better. -------------------------------------------------------- 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 003D504D48257731_= Content-Type: text/html; charset="US-ASCII"
//It seams that mail list doesn't dispatch this mail. To let other people catch up the thread, I re-send it.


>
> I understand.
>
> The text says that the UAC can not expect to receive a 487
> response to the INVITE. Right?

As UAC's old contact has been lost, UAC can not expect to receive any final response for the old Re-INVITE here.
So, the specific for final response is not important here. And the UAC's next Re-INVITE as synchronization can refresh the state here.

>
> And now, assuming that some of changes have already been
> executed, the UAS would send a new UPDATE to undo the changes.
> But the local target of the UAC has been changed, so I think UAC
> should an UPDATE to announce own new target before sending the
> CANCEL.
>
> Do you think so?

I think the UAC should send a target refresh UPDATE before CANCEL. But the reason is not about UAS's rollback usage UPDATE.(the state would be synchronized by a next Re-INVITE).

To send a new request(the CANCEL) at new address, sending a target refresh UPDATE before the new request (the CANCEL) might be better. 

--------------------------------------------------------
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 003D504D48257731_=-- From pkyzivat@cisco.com Sun May 30 14:25:52 2010 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 E919B3A68D1 for ; Sun, 30 May 2010 14:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Pi19rhbNUmMp for ; Sun, 30 May 2010 14:25:50 -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 962A33A6896 for ; Sun, 30 May 2010 14:25:49 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMZ0AkxAZnwN/2dsb2JhbACeMnGmIZhqhRYE X-IronPort-AV: E=Sophos;i="4.53,328,1272844800"; d="scan'208";a="116217633" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 May 2010 21:25:38 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4ULPbgr013508; Sun, 30 May 2010 21:25:37 GMT Message-ID: <4C02D7D1.70400@cisco.com> Date: Sun, 30 May 2010 17:25:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) 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 Cc: "Christer.Holmberg@ericsson.com" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 30 May 2010 21:25:52 -0000 Sorry to be so slow in responding. I got behind, and had to wait till I had time to read through all that has been said before I could make any sort of meaningful response. As it is, there is so much that I am responding after reading most of the -reinvite- traffic, without first checking if some of the mail with different subject is also relevant. gao.yang2@zte.com.cn wrote: > > Rules for "When checking for glare situations" in the draft text means > the UAs's reasoning and handling while the UAs are in a glare > situations, which is ambiguous. > > It does not means UAs reasoning and handling for every use case to > figure out whether this case is a glare case. > > This is my understanding. And I'd like other co-authors and important > reviewer to comment on this point. In light of all the discussion this has generated, I think -reinvite- is not sufficiently clear on what it means. I think we need to be looking for a way to revise it to be more clear, regardless of its current post-WGLC status. (Note that -offeranswer- is also in post-WGLC status, and we are debating changes to it.) We *REALLY* need to hear from Gonzalo for his opinion on this! My opinion at this point is that stating that "UPDATEs without SDP should be treated as if they contained an offer" is an insufficient technique for stating the required behavior - that it needs to be stated more explicitly, even though that will take more words. I *think* that considerations of *glare* occur when there is something to be *negotiated* and either side may initiate the negotiation. The negotiated piece of state that has been considered to date for glare is the pair of SDP bodies that describe the media sessions. As noted elsewhere in this thread, another piece state that is *negotiated* is session-timer. As a result, there could be a glare situation around that. The determination of whether glare has occurred ought to be independent for each kind of negotiated state. So one determination for SDP, another for session-timer. But there is only one mechanism for signaling the glare in either case, the 491 response code. So it would be used if *either* sdp-glare or session-timer-glare occurred. Target-refresh is somewhat different, because it isn't *negotiated* - it is simply *declared* independently in each direction. So I don't think it really ought to be considered a glare situation. Another in this category is sending an updated PAI, or changing From. This to is a declaration rather than a negotiation, so that glare shouldn't apply. In both of those cases, there remains an ordering issue, and perhaps the answer is to forbid behavior that can result in ambiguity. But I fear that cure is worse than the disease, so I'm inclined to seek a better cure. I'm especially concerned about that in the case of target refresh. If the sender has lost its old address, then we are on the brink of losing the call entirely. Saving the call is more important than whether we have the proper o/a state - that can be fixed after the new target address is established. Also, target refresh cases are typically rare. Two successive ones in close succession in the same direction should be rare^2. (A target refresh of both ends in quick succession could be more likely - for instance if the same event causes both to lose their address. It seems unlikely that this will be a recoverable event.) So, I think we ought not be forbidding target refresh just because of other state. Ambiguity about which is the old target and which is the new one can be measured by which is a change - assuming there aren't two changes in quick succession. I think Gao has also recommended this. Thanks, Paul > > > > Look at RFC3311 (especially section 5.2) concerning how to behave > > > > when UPDATE offer is received while there is an outstanding offer. > > > > > > I know this part of 3311. I don't know the meaning of why > > > you highlight this part. > > > > > > Do you think text of our draft has conflict with this part of 3311 > here? > > > > > > I don't think so, as our text only for ambiguous cases. > > > > I'm indicating that the RFC3311 mandates the returning 491 or 500 > > (depending upon direction). > > > > You are indicating that the RFC3311 text doesn't apply even though > > draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate they > > would apply. RFC3311 section 5.2 includes glare checking as part of > > normal UPDATE processing. > > > > The drafts normative text causing the issue: "When checking for > > glare situations, UAs MUST treat every UPDATE request as if it > > contained an offer." > > > > You keep interpreting/indicating that the normative text does not > > apply to all UPDATEs. Please provide the normative text which > > indicates your interpretation. > > > > Thanks, > > Brett > > > > > > -------------------------------------------------------- > 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 pkyzivat@cisco.com Sun May 30 14:34:41 2010 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 9C2D53A6831 for ; Sun, 30 May 2010 14:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_50=0.001, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45, 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 dYiH-8KgZL4Q for ; Sun, 30 May 2010 14:34:40 -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 538E13A6782 for ; Sun, 30 May 2010 14:34:40 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHh2AkxAZnwM/2dsb2JhbACDGJsacaYiiQkIj1yBIoMFbwSDMQ X-IronPort-AV: E=Sophos;i="4.53,328,1272844800"; d="scan'208";a="116354724" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 May 2010 21:34:28 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4ULYOFJ003304; Sun, 30 May 2010 21:34:28 GMT Message-ID: <4C02D9E0.5060306@cisco.com> Date: Sun, 30 May 2010 17:34:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org, Harbhanu Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer 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, 30 May 2010 21:34:41 -0000 I agree that there are issues with session-timer. Normally session-timer is simple, because it is negotiated anew with each exchange. That works reasonably well for reINVITE and for UPDATE outside of an invite transaction. Its a mess if an UPDATE within a (re)INVITE transaction negotiates S-T. I think that needs to be forbidden, which will be a revision to 4028. (A reINVITE should not take so long that a session-timer will expire before it is complete. Perhaps it should be specified that *if* a session-timer does expire while a reINVITE is in progress, that expiration is ignored.) Thanks, Paul gao.yang2@zte.com.cn wrote: > > Hi, > > Not like O/A usage and target refresh usage, there's no explicit > definition of allowing subsequent session refresh request in embedded > requests(such as UPDATE during pending Re-INVITE). So, I think it is not > recommended to sending UPDATE as subsequent session refresh request in > pending INVITE/Re-INVITE. > > I'd like to talk more about session timer. If people want to do the > semantics extension for session timer's to allow embedded requests(such > as UPDATE during pending Re-INVITE), there's one suggestion > way(INFORMATIVE at all): > > Do it like target refresh, then the 2xx of INVITE/Re-INVITE's SE value > should be as the SE value in the last embedded subsequent session > refresh request's 2xx. > > Then, the glare handling for such usage would be the same as the Target > Refresh part in draft-ietf-sipcore-reinvite. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Harbhanu * > ·¢¼þÈË: sipcore-bounces@ietf.org > > 2010-05-24 13:40 > > > ÊÕ¼þÈË > sipcore@ietf.org > ³­ËÍ > > Ö÷Ìâ > [sipcore] REg. draft-ietf-sipcore-reinvite-04 > > > > > > > > > > 1. UE1 --- INVITE SE-1800 ¨¤ UE2 > 2. UE1 <--- 183 ------------------ UE2 > > 3. UE1 --- UPDATE SE-600 ¨¤ UE2 > 4. UE1 <--- 200 UPDATE -SE600 -- UE2 > > 5. UE1 <--- 200 INVITE SE-1800 -- UE2 > > Please refer the scenario above for handling of Session-Timer, (4028). > As per the Draft-ietf-sipcore-reinvite-04 section 4.5: > ¡° When checking for glare situations, UAs MUST treat every UPDATE > request as if it contained an offer. Additionally, UAs MUST treat > the exchange of a 2xx response to an INVITE request and its > corresponding ACK request as an offer/answer exchange. Consequently, > the rules regarding glare situations applicable to offer/answer > exchanges are also applicable to those exchanges.¡± > > Here, we are not able to conclude whether both UAs should run session > timer with > 1800 or 600, or otherwise whether the UPDATE should be rejected. > > As per my understanding this draft doesn¡¯t **explicitly** mention > anything about the Session-Timer, wherein there is an early negotiation. > Since 4028 also doesn¡¯t > have any reference for early negotiation, so we suggest that it can > better be incorporated in the above mentioned > draft[ietf-sipcore-reinvite-04]. > > Please share your opinion and do guide us incase any of the existing > RFC/active-draft already captures this. > > Thanks! > > Regards, > Harbhanu > > *************************************************************************************** > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > -------------------------------------------------------- > 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Sun May 30 14:51:21 2010 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 A58373A6934 for ; Sun, 30 May 2010 14:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.537 X-Spam-Level: X-Spam-Status: No, score=-8.537 tagged_above=-999 required=5 tests=[AWL=2.062, 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 xn-WVT9pGxRI for ; Sun, 30 May 2010 14:51:20 -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 70E1D3A6782 for ; Sun, 30 May 2010 14:51:20 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABt7AkxAZnwM/2dsb2JhbACeMnGmMZhrhRYE X-IronPort-AV: E=Sophos;i="4.53,328,1272844800"; d="scan'208";a="116357458" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 May 2010 21:51:08 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4ULp7E7007485; Sun, 30 May 2010 21:51:08 GMT Message-ID: <4C02DDCB.1000201@cisco.com> Date: Sun, 30 May 2010 17:51:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brett Tate References: <747A6506A991724FB09B129B79D5FEB614816DC3A2@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC3BA@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB614816DC3BA@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 30 May 2010 21:51:21 -0000 This is evidence for my assertion that glare is really about conflicts in negotiation of state, and not about the specific messages used to conduct that negotiation. Thanks, Paul Brett Tate wrote: >> Sorry, I can't catch the meaning of "when you factor >> in RFC3311". Could you show me the meaning? > > Look at RFC3311 (especially section 5.2) concerning how to behave when UPDATE offer is received while there is an outstanding offer. > > " If an UPDATE is received that contains an offer, and the UAS has > generated an offer (in an UPDATE, PRACK or INVITE) to which it has > not yet received an answer, the UAS MUST reject the UPDATE with a 491 > response. Similarly, if an UPDATE is received that contains an > offer, and the UAS has received an offer (in an UPDATE, PRACK, or > INVITE) to which it has not yet generated an answer, the UAS MUST > reject the UPDATE with a 500 response, and MUST include a Retry-After > header field with a randomly chosen value between 0 and 10 seconds." > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Sun May 30 15:13:01 2010 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 3169B3A67F9 for ; Sun, 30 May 2010 15:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.924 X-Spam-Level: X-Spam-Status: No, score=-7.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, 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 TKgEKBwy5A9U for ; Sun, 30 May 2010 15:13:00 -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 F28CE3A6834 for ; Sun, 30 May 2010 15:12:59 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMt/AkxAZnwN/2dsb2JhbACeMnGmR5hrhRYE X-IronPort-AV: E=Sophos;i="4.53,329,1272844800"; d="scan'208";a="116362286" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 May 2010 22:12:48 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4UMClA8024746; Sun, 30 May 2010 22:12:48 GMT Message-ID: <4C02E2DF.5050909@cisco.com> Date: Sun, 30 May 2010 18:12:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) 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 Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Subject: Re: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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, 30 May 2010 22:13:01 -0000 Christer Holmberg wrote: > Below are some questions/ideas on how I think we could solve most issues. Some of the stuff shall be seen more as brain storming than actual proposal at this point. > > I am fully aware that some of the ideas for sure may limit what is said in RFCs etc, so you don't need to tell me about that. > > > > > IDEA #1: Offer/answer: Usage of SDP o= version parameter > > I know this has been discussed at some point, but what is the reason we can't use the SDP o= version parameter to determine in which order the UAS has sent SDPs? > > I believe it would solve offer/answer glare situations where the UAC does not known in which order the UAS has sent SDPs. > > That should not be controversial, and does not break any RFC etc. Shinji refuted this one. > IDEA #2: Target update: Only outside re-INVITEs > > Let's forbid target updates "inside" re-INVITEs. I really doubt there is a need for those while the UAs are doing something else with the re-INVITE. > > That at least solves the glare situation where the remote target may be updated in a re-INVITE response and an UPDATE response. For the case of a UA that loses its IP address and must switch to another, it may be essential to send the UPDATE immediately. And it won't be getting the response to the reINVITE in that case, so it can't wait till it does. In general you should almost never ignore a target refresh, unless there is something grievous such as an authentication failure. > IDEA #3: UPDATE: Always use re-INVITE glare rules > > Let's not allow more than one outstanding UPDATE. Ie if a UA has sent an UPDATE (with or without SDP), and receives another UPDATE request before the answer, it rejects it (same rule as for re-INVITE). > > > That would at least solve the problem where a UA sends an UPDATE, receives a 200 OK and a UPDATE request, both with different target information. I'm not convinced this solves anything. And if it prevented an essential target refresh then it would be a bad thing. As I stated elsewhere, I think glare should be detected individually for each piece of state being negotiated. Then the request can be rejected if some form of glare has been detected. Target refresh isn't a glare situation, so would never fall into that. Thanks, Paul > Ok, let the tomatoes fly... > > ...and let me know if there are any issues which the ideas above do NOT solve. I have some more ideas, but I am not sure they are needed so I'll them to myself for now :) > > > Regards, > > Christer > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Sun May 30 15:16:45 2010 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 2E32C3A68C2 for ; Sun, 30 May 2010 15:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.343 X-Spam-Level: X-Spam-Status: No, score=-7.343 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_50=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, 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 RUezRZoVgiFN for ; Sun, 30 May 2010 15:16:44 -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 DF1AF3A67B2 for ; Sun, 30 May 2010 15:16:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPeAAkxAZnwN/2dsb2JhbACeMnGmOJhqhRYE X-IronPort-AV: E=Sophos;i="4.53,329,1272844800"; d="scan'208";a="116363036" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 May 2010 22:16:32 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4UMGVOT025492; Sun, 30 May 2010 22:16:32 GMT Message-ID: <4C02E3BF.3080905@cisco.com> Date: Sun, 30 May 2010 18:16:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: OKUMURA Shinji References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gao.yang2@zte.com.cn, "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 30 May 2010 22:16:45 -0000 I read through this discussion, and I cannot figure out what the difference is between the two of you. As of this reply it seems to me that the two of you are agreeing. Can one of you restate the issue and the contrasting solutions? Thanks, Paul OKUMURA Shinji wrote: > Gao, > > This is a figure I've assumed. > > A B > | | > s0|re-INV (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1| non-2xx|s1 > |<------------------------------|<-+ > s0|ACK |s0| > |-----------> | | > |UPD(offer0) | | > |==============================>|* | reject UPDATE > | 491(UPD)| | > |<==============================| | > | ACK | | > | ---------->|<-+ > | | > Figure 2 > >> Hi, >> >> OKUMURA Shinji >>> Gao, >>> >>> gao.yang2@zte.com.cn >>> Tue, 25 May 2010 14:15:10 +0800 >>>> Hi, >>>> >>>>>>> I agree that it doesn't forbid sending it. It allows it and >>>>>>> mandates the UAS return 491 or 500 (depending upon direction). >>>>>> It mandates the UAS send 4xx/5xx to UPDATE only when the UAS >>>>>> send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before >>>>>> ACK of 4xx/5xx(Re-INVITE). >>>>> As you know, ACK to non-2xx is hop-by-hop. >>>>> There is little benefit to reject such an UPDATE. >>>> UAS send 491 for the UPDATE(in the flow) to *tell* UAC that in it's >>>> (UAS) >>>> view, there's a glare case. >>> But this UPDATE is sent in order to synchronize the common view. >>> If UAS return 2xx, then the situation goes into nonglare. >> I guess I have a inverse point here. By this draft's clarification, >> there's no inconsistent session state for the non-successful Re-INVITE. >> So, why UAC send a UPDATE to synchronize the common view? > > In 3.4. UAC Behavior, > "In order to cope with these race condition > situations, a UAC that receives an error response to a re-INVITE for > which changes have been already executed SHOULD generate a new re- > INVITE or UPDATE request in order to make sure that both UAs have a > common view of the state of the dialog and the session." > > Under the above descriptions, this UAC generates a new UPDATE. > >> While if UAS return 2xx(for the UPDATE), the situation would get into >> glare(UAS has no way to figure out this UPDATE is in-scope of Re-INVITE or >> not). This is relating to atomic of session state. I'd like to emphasize >> that keeping Re-INVITE atomic, except for target refresh, is the main idea >> in this draft. > > This issue has nothing to do with the "atomic of session state". > >>> Probably another UPDATE will be sent, but this UPDATE >>> transaction is supposed to be avoided. >>> >>> At the very start, the UAS rejects a reINVITE does not care >>> about this text. Is it necessary to let such a UAS follow a >>> new rule? >> These days, you guys showed a lot of use cases. I don't remember the >> details. Could you say more about this use case. > > Please look at the original mail of mine, and re-comment it. > You seem to be confused a little. > >>>> When UAS get the ACK then UPDATE, it still has no precise criterion for >>>> whether the UAC gets non-2xx(Re-INVITE) first then send the UPDATE or not. >>>> Keeping rejecting the UPDATE is not a reasonable way here. So, the draft >>>> suggest the way, as UAS can send 2xx to the UPDATE. >>> It is a conventional handling and enough for UAS. >>> >>>> When UAC get UAS's 4xx of UPDATE, the session state is clear for it. And >>>> UAC would only send a synchronizing Re-INVITE/UPDATE when it is a glare >>>> case in the UAC's view. >>> UAS' behavior does not affect UAC' behavior directly. >>> UAC will do the needful regardless of whether UAS rejects >>> a reINVITE. >>> >>>> IMO, this way is better than the way we might once use: allowing B send >>>> 2xx to UPDATE, and both A and B *see* glare, and all send Re-INVITE/UPDATE >>>> to refresh session state by each's view. >>> The new rule for UAS does not seem to improve the situation. >>> The new rule for UAC seems to be just enough to synchronize >>> the view. >> The key merit for the new rule is make both UAC and UAS clear in which >> situation is it's responsibility to handle glare case, and there's only >> one UA need to do something. Both sides want to refresh session state by >> each's view is not a elegant way. > > The crux of the matter is that a UAS can not recognize own glare > situation anytime. > It is UAC's duty to synchronize a common view. > > Regards, > Shinji > >> Thanks, >> >> Gao > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Sun May 30 15:28:43 2010 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 8DAE93A690D for ; Sun, 30 May 2010 15:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.204 X-Spam-Level: X-Spam-Status: No, score=-8.204 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_20=-0.74, 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 4DhGmGS-FGom for ; Sun, 30 May 2010 15:28:41 -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 7C2BA3A691E for ; Sun, 30 May 2010 15:28:41 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE+DAkxAZnwM/2dsb2JhbACeMnGmTZhohRYE X-IronPort-AV: E=Sophos;i="4.53,329,1272844800"; d="scan'208";a="116364935" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 May 2010 22:28:29 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4UMSTPL017249; Sun, 30 May 2010 22:28:29 GMT Message-ID: <4C02E68D.90005@cisco.com> Date: Sun, 30 May 2010 18:28:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: OKUMURA Shinji References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <70CAF9873ACDA5shinji.okumura@softfront.jp> In-Reply-To: <70CAF9873ACDA5shinji.okumura@softfront.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP 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, 30 May 2010 22:28:43 -0000 Shinji, I agree with what you say, but perhaps for different reasons, for based on different view of what "glare" means. IMO the 491 response should be used to indicate glare has been detected, specifically that a proposal to negotiate a state change has been *received* while a previously *sent* proposal to negotiate a state change is still unresolved. That can apply to o/a regardless of what messages cause the situation to be detected. And I think this can apply even when receiving an offerless reINVITE, which is a demand for an offer. OTOH the 500 response applies when a proposal to negotiate a state change has been *received* while a previously *received* proposal to negotiate state is still unresolved. This is not glare, because the problem is not the result of coincidence in valid behavior. The 500 is a suitable response because it is bad behavior by the sender of those proposals that results in the problem. Thanks, Paul OKUMURA Shinji wrote: > Hi Brett, > > I have a similar question too. > > RFC 3261 and 3311 describe the definition regarding 500 and > 491 response. > When UA rejects the INVITE during an INVITE transaction, or > rejects the UPDATE during an UPDATE transaction, it has nothing > to do with offer-answer which error code to be used. > > If both transaction have the same direction, the error code is 500. > If not, the error code is 491. > > But an interworking of INVITE and UPDATE is unclear. > The draft-offeranswer makes an efforts to clarify it in the > section 4.3. > >> Howdy, >> >> Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate >> that an UPDATE without SDP should be treated (from a glare >> perspective) as though it contained an offer SDP. >> However I currently find the definition of "glare" and the >> expected behavior to be ambiguous. >> >> What is the precise meaning of glare? I ask mainly because >> some vendors send a 491 when an RFC indicates to send a 500. >> >> If INVITE contains offer SDP and 18x was not reliable, how >> SHOULD the called party respond if UPDATE without SDP is >> received from caller: 491, 500, or process as though no glare? > > If UA must refuse it , parhaps it is 500. > IMO it is another question whether UA must reject the UPDATE > without an offer. > >> If INVITE contains offer SDP and 18x was not reliable, how >> SHOULD the caller respond if UPDATE without SDP is received >>from called party: 491, 500, or process as though no glare? > > Parhaps it is 491. > >> If caller receives INVITE 2xx without offer/answer, how SHOULD >> or MUST the caller respond if UPDATE without SDP is received >>from called party prior to sending ACK (if not willing to >> queue or drop UPDATE): 491 or 500? Is it a SHOULD or MUST? > > UA may send 2xx to UPDATE. Because the INVITE transaction has > been completed. > > For reference, the following figures are now under consideration. > > A B > | | > |INVITE | > |--------------------->|<-+ <-----+ > | 1xx(offer or answer)| | | > |<---------------------| | reject INVITE | reject UPDATE > |PRACK | | Don't send INVITE | Don't send UPDATE > |--------------------->| | | > | 2xx-PRA| | | > |<---------------------| | <-----+ > | | | | may send UPDATE > | 2xx| | | may accept UPDATE > |<---------------------|<-+ | > | | | may send INVITE | > |ACK | | may accept INVITE | > |--------------------->| | | > | | v v > | | > Figure 16 > > A B > | | > |INVITE | > |--------------------->|<-+ <-----+ > | 1xx(offer or answer)| | | > |<---------------------| | reject INVITE | reject UPDATE > |PRACK | | Don't send INVITE | Don't send UPDATE > |--------------------->| | | > | 2xx-PRA| | | > |<---------------------| | <-----+ > | | | | may send UPDATE > | 4xx| | | may acceptUPDATE > |<---------------------|<-+ | > | | | Don't send INVITE | > |ACK ACK | | may accept INVITE | <-- Should B reject UPDATE or not? > |---------> -------->|<-+ <-----+ That is another question. > | | | | > | | v v > Figure 17 > > In both figures, > UA A reject all INVITE/UPDATE with 491. > UA B reject all INVITE/UPDATE with 500. > > Regards, > Shinji > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Sun May 30 16:53:12 2010 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 D5DD73A696A for ; Sun, 30 May 2010 16:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.223 X-Spam-Level: X-Spam-Status: No, score=-9.223 tagged_above=-999 required=5 tests=[AWL=1.376, 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 oU-i2vhyw9x1 for ; Sun, 30 May 2010 16:53:11 -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 937A23A67B1 for ; Sun, 30 May 2010 16:53:11 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADuXAkxAZnwM/2dsb2JhbACeMnGmS5hohRYE X-IronPort-AV: E=Sophos;i="4.53,329,1272844800"; d="scan'208";a="116377870" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 May 2010 23:52:59 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4UNqxRT007895; Sun, 30 May 2010 23:52:59 GMT Message-ID: <4C02FA5B.70202@cisco.com> Date: Sun, 30 May 2010 19:52:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: OKUMURA Shinji References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gao.yang2@zte.com.cn, sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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: Sun, 30 May 2010 23:53:12 -0000 I think its important to send the target refresh ASAP (if the old target is no longer functional.) Whether sending it before/after CANCEL otherwise makes little difference. Either way the 487 won't be received. Thanks, Paul OKUMURA Shinji wrote: > Gao, > > I understand. > > The text says that the UAC can not expect to receive a 487 > response to the INVITE. Right? > > And now, assuming that some of changes have already been > executed, the UAS would send a new UPDATE to undo the changes. > But the local target of the UAC has been changed, so I think UAC > should an UPDATE to announce own new target before sending the > CANCEL. > > Do you think so? > > Regards, > Shinji > > gao.yang2@zte.com.cn > Fri, 28 May 2010 13:09:35 +0800 >>> Following texts seem to be conflicted. >>> >>> 3.8. Clarifications on Cancelling Re-INVITEs >>> Per >>> the rules specified in Section 3.3, if the INVITE request was a re- >>> INVITE and some of its requested changes had already been executed, >>> the UAS would return a 2xx response instead. >> This is about UAS's behavior. >> >>> 5.5. UAC Losing its Contact: UAC Behavior >>> Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE >>> and cause the INVITE client transaction corresponding to the re- >>> INVITE to enter the "Terminated" state. >> This is about UAC's behavior. And which(2xx/Non-2xx) final response UAS >> would send is defined in section 3.8. >> >> As the UAC may not get the final response from UAS, it should send a new >> Re-INVITE(/UPDATE) to synchronize the state. >> And this is defined in the draft. >> >> This is the understanding while I did the review for this part, and I keep >> my understanding as so. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Sun May 30 17:04:04 2010 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 44B293A68BB for ; Sun, 30 May 2010 17:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.42 X-Spam-Level: X-Spam-Status: No, score=-9.42 tagged_above=-999 required=5 tests=[AWL=1.179, 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 AAkjB+-ghy+O for ; Sun, 30 May 2010 17:04:03 -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 2189E3A692C for ; Sun, 30 May 2010 17:04:03 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJOZAkxAZnwN/2dsb2JhbACeMnGmQ5hnhRYE X-IronPort-AV: E=Sophos;i="4.53,329,1272844800"; d="scan'208";a="116379081" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 May 2010 00:03:51 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4V03pYF020353; Mon, 31 May 2010 00:03:51 GMT Message-ID: <4C02FCE7.90203@cisco.com> Date: Sun, 30 May 2010 20:03:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <747A6506A991724FB09B129B79D5FEB614816DC354@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614816DC383@EXMBXCLUS01.citservers.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 00:04:04 -0000 Elwell, John wrote: > If an UPDATE request without SDP offer cannot be accepted when only an unreliable provisional response has occurred, I believe this is a normative change to RFC 3311. Yes, I agree. And I think its an undesirable change too. Thanks, Paul > John > >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] >> Sent: 24 May 2010 14:25 >> To: gao.yang2@zte.com.cn >> Cc: Elwell, John; sipcore@ietf.org >> Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare >> and UPDATE without SDP >> >>>> Concerning glare, my understanding is that the draft mandates >>>> treating UPDATE without offer as though it contained an offer. >>>> >>>> I'm still trying to understand how section 3.5 and 4.5 are to be >>>> interpreted. Because the draft uses offer/answer rules for the >>>> "fix", it prevents using UPDATE without SDP on an early >> dialog until >>>> allowed per offer/answer rules. >>> Not exactly here. The text never forbit usage of UPDATE >> without offer by O/A rules. >> >> I agree that it doesn't forbid sending it. It allows it and >> mandates the UAS return 491 or 500 (depending upon direction). >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gao.yang2@zte.com.cn Sun May 30 17:56:58 2010 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 DED213A6974 for ; Sun, 30 May 2010 17:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.444 X-Spam-Level: X-Spam-Status: No, score=-96.444 tagged_above=-999 required=5 tests=[AWL=-1.409, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 6kusg5crJi8r for ; Sun, 30 May 2010 17:56:57 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2866D3A696F for ; Sun, 30 May 2010 17:56:56 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 31 May 2010 08:51:04 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.4884295178; Mon, 31 May 2010 08:56:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4V0uCKp051327; Mon, 31 May 2010 08:56:12 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C02FCE7.90203@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 31 May 2010 08:53:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-31 08:56:11, Serialize complete at 2010-05-31 08:56:11 Content-Type: multipart/alternative; boundary="=_alternative 0005195648257734_=" X-MAIL: mse2.zte.com.cn o4V0uCKp051327 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 00:56:59 -0000 This is a multipart message in MIME format. --=_alternative 0005195648257734_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBndWVzcyB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgc2VjdGlvbiA0LjUgb2YgdGhlIGRyYWZ0Lg0K DQpCdXQgc2VjdGlvbiA0LjUncyBydWxlcyBvbmx5IGFwcGx5IHRvIGNhc2Ugd2hpY2ggaGFzIGFt YmlndWl0eS4gSSB0aGluayANCnRoYXQgdGhlIHRhbGtlZCB1c2UgY2FzZSBoZXJlIGhhcyBubyBh bWJpZ3VpdHkuIFNvLCBub3RoaW5nIGlzIGZvcmJpZGRlbiANCmhlcmUuDQoNClRoYW5rcywNCg0K R2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEw MDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KDQoNCg0KUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBjaXNjby5jb20+IA0Kt6K8/sjLOiAg c2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQoyMDEwLTA1LTMxIDA4OjAzDQoNCsrVvP7Iyw0KIkVs d2VsbCwgSm9obiIgPGpvaG4uZWx3ZWxsQHNpZW1lbnMtZW50ZXJwcmlzZS5jb20+DQqzrcvNDQoi Z2FvLnlhbmcyQHp0ZS5jb20uY24iIDxnYW8ueWFuZzJAenRlLmNvbS5jbj4sICJzaXBjb3JlQGll dGYub3JnIiANCjxzaXBjb3JlQGlldGYub3JnPg0K1vfM4g0KUmU6IFtzaXBjb3JlXSBkcmFmdC1p ZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6IGdsYXJlIGFuZCBVUERBVEUgd2l0aG91dCBTRFANCg0K DQoNCg0KDQoNCg0KDQpFbHdlbGwsIEpvaG4gd3JvdGU6DQo+IElmIGFuIFVQREFURSByZXF1ZXN0 IHdpdGhvdXQgU0RQIG9mZmVyIGNhbm5vdCBiZSBhY2NlcHRlZCB3aGVuIG9ubHkgYW4gDQp1bnJl bGlhYmxlIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGhhcyBvY2N1cnJlZCwgSSBiZWxpZXZlIHRoaXMg aXMgYSANCm5vcm1hdGl2ZSBjaGFuZ2UgdG8gUkZDIDMzMTEuDQoNClllcywgSSBhZ3JlZS4gQW5k IEkgdGhpbmsgaXRzIGFuIHVuZGVzaXJhYmxlIGNoYW5nZSB0b28uDQoNCiAgICAgICAgICAgICAg ICAgVGhhbmtzLA0KICAgICAgICAgICAgICAgICBQYXVsDQoNCj4gSm9obg0KPiANCj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBCcmV0dCBUYXRlIFttYWlsdG86YnJldHRA YnJvYWRzb2Z0LmNvbV0gDQo+PiBTZW50OiAyNCBNYXkgMjAxMCAxNDoyNQ0KPj4gVG86IGdhby55 YW5nMkB6dGUuY29tLmNuDQo+PiBDYzogRWx3ZWxsLCBKb2huOyBzaXBjb3JlQGlldGYub3JnDQo+ PiBTdWJqZWN0OiBSRTogW3NpcGNvcmVdIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS0wNDog Z2xhcmUgDQo+PiBhbmQgVVBEQVRFIHdpdGhvdXQgU0RQDQo+Pg0KPj4+PiBDb25jZXJuaW5nIGds YXJlLCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIGRyYWZ0IG1hbmRhdGVzIA0KPj4+PiB0 cmVhdGluZyBVUERBVEUgd2l0aG91dCBvZmZlciBhcyB0aG91Z2ggaXQgY29udGFpbmVkIGFuIG9m ZmVyLg0KPj4+Pg0KPj4+PiBJJ20gc3RpbGwgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IHNlY3Rp b24gMy41IGFuZCA0LjUgYXJlIHRvIGJlIA0KPj4+PiBpbnRlcnByZXRlZC4gIEJlY2F1c2UgdGhl IGRyYWZ0IHVzZXMgb2ZmZXIvYW5zd2VyIHJ1bGVzIGZvciB0aGUgDQo+Pj4+ICJmaXgiLCBpdCBw cmV2ZW50cyB1c2luZyBVUERBVEUgd2l0aG91dCBTRFAgb24gYW4gZWFybHkgDQo+PiBkaWFsb2cg dW50aWwNCj4+Pj4gYWxsb3dlZCBwZXIgb2ZmZXIvYW5zd2VyIHJ1bGVzLiANCj4+PiBOb3QgZXhh Y3RseSBoZXJlLiBUaGUgdGV4dCBuZXZlciBmb3JiaXQgdXNhZ2Ugb2YgVVBEQVRFIA0KPj4gd2l0 aG91dCBvZmZlciBieSBPL0EgcnVsZXMuIA0KPj4NCj4+IEkgYWdyZWUgdGhhdCBpdCBkb2Vzbid0 IGZvcmJpZCBzZW5kaW5nIGl0LiAgSXQgYWxsb3dzIGl0IGFuZCANCj4+IG1hbmRhdGVzIHRoZSBV QVMgcmV0dXJuIDQ5MSBvciA1MDAgKGRlcGVuZGluZyB1cG9uIGRpcmVjdGlvbikuDQo+Pg0KPj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lw Y29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K DQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFs LiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVj eSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNt aXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVz c2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3Rp ZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1l c3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1T cGFtIHN5c3RlbS4NCg== --=_alternative 0005195648257734_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZ3Vlc3MgeW91IGFyZSB0YWxr aW5nIGFib3V0IHNlY3Rpb24NCjQuNSBvZiB0aGUgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CdXQgc2VjdGlvbiA0LjUncyBydWxlcyBvbmx5 IGFwcGx5IHRvDQpjYXNlIHdoaWNoIGhhcyBhbWJpZ3VpdHkuIEkgdGhpbmsgdGhhdCB0aGUgdGFs a2VkIHVzZSBjYXNlIGhlcmUgaGFzIG5vDQphbWJpZ3VpdHkuIFNvLCBub3RoaW5nIGlzIGZvcmJp ZGRlbiBoZXJlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNw OzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNw OyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNu PGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UGF1bCBLeXppdmF0ICZsdDtw a3l6aXZhdEBjaXNjby5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA1LTMxIDA4OjAzPC9m b250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K 1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O0Vsd2VsbCwgSm9obiZxdW90OyAmbHQ7am9obi5lbHdlbGxAc2llbWVucy1lbnRlcnByaXNl LmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2dhby55YW5nMkB6dGUuY29tLmNuJnF1 b3Q7ICZsdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZndDssDQomcXVvdDtzaXBjb3JlQGlldGYub3Jn JnF1b3Q7ICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtz aXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6DQpnbGFyZSBhbmQgVVBEQVRF IHdpdGhvdXQgU0RQPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQpFbHdlbGwsIEpvaG4gd3JvdGU6PGJyPg0KJmd0OyBJ ZiBhbiBVUERBVEUgcmVxdWVzdCB3aXRob3V0IFNEUCBvZmZlciBjYW5ub3QgYmUgYWNjZXB0ZWQg d2hlbiBvbmx5DQphbiB1bnJlbGlhYmxlIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGhhcyBvY2N1cnJl ZCwgSSBiZWxpZXZlIHRoaXMgaXMgYSBub3JtYXRpdmUNCmNoYW5nZSB0byBSRkMgMzMxMS48YnI+ DQo8YnI+DQpZZXMsIEkgYWdyZWUuIEFuZCBJIHRoaW5rIGl0cyBhbiB1bmRlc2lyYWJsZSBjaGFu Z2UgdG9vLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQpUaGFua3MsPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBhdWw8YnI+DQo8YnI+DQomZ3Q7IEpv aG48YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyZndDsgRnJvbTogQnJldHQgVGF0ZSBbbWFpbHRvOmJyZXR0QGJyb2Fkc29mdC5jb21d IDxicj4NCiZndDsmZ3Q7IFNlbnQ6IDI0IE1heSAyMDEwIDE0OjI1PGJyPg0KJmd0OyZndDsgVG86 IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0OyZndDsgQ2M6IEVsd2VsbCwgSm9objsgc2lw Y29yZUBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJFOiBbc2lwY29yZV0gZHJhZnQt aWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0OiBnbGFyZSA8YnI+DQomZ3Q7Jmd0OyBhbmQgVVBEQVRF IHdpdGhvdXQgU0RQPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENvbmNlcm5p bmcgZ2xhcmUsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgZHJhZnQgbWFuZGF0ZXMNCjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgdHJlYXRpbmcgVVBEQVRFIHdpdGhvdXQgb2ZmZXIgYXMgdGhv dWdoIGl0IGNvbnRhaW5lZCBhbg0Kb2ZmZXIuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgSSdtIHN0aWxsIHRyeWluZyB0byB1bmRlcnN0YW5kIGhvdyBzZWN0aW9u IDMuNSBhbmQgNC41DQphcmUgdG8gYmUgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBpbnRlcnByZXRl ZC4gJm5ic3A7QmVjYXVzZSB0aGUgZHJhZnQgdXNlcyBvZmZlci9hbnN3ZXINCnJ1bGVzIGZvciB0 aGUgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtmaXgmcXVvdDssIGl0IHByZXZlbnRzIHVz aW5nIFVQREFURSB3aXRob3V0IFNEUA0Kb24gYW4gZWFybHkgPGJyPg0KJmd0OyZndDsgZGlhbG9n IHVudGlsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBhbGxvd2VkIHBlciBvZmZlci9hbnN3ZXIgcnVs ZXMuIDxicj4NCiZndDsmZ3Q7Jmd0OyBOb3QgZXhhY3RseSBoZXJlLiBUaGUgdGV4dCBuZXZlciBm b3JiaXQgdXNhZ2Ugb2YgVVBEQVRFIDxicj4NCiZndDsmZ3Q7IHdpdGhvdXQgb2ZmZXIgYnkgTy9B IHJ1bGVzLiA8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgYWdyZWUgdGhhdCBpdCBkb2Vz bid0IGZvcmJpZCBzZW5kaW5nIGl0LiAmbmJzcDtJdCBhbGxvd3MgaXQNCmFuZCA8YnI+DQomZ3Q7 Jmd0OyBtYW5kYXRlcyB0aGUgVUFTIHJldHVybiA0OTEgb3IgNTAwIChkZXBlbmRpbmcgdXBvbiBk aXJlY3Rpb24pLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzaXBjb3Jl IG1haWxpbmcgbGlzdDxicj4NCiZndDsgc2lwY29yZUBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KJmd0OyA8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNv cmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7Zmls ZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZp ZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJz cDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVz c2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZu YnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNw O3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7 QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNz YWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtz Y2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZu YnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0005195648257734_=-- From pkyzivat@cisco.com Sun May 30 18:09:16 2010 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 3D0783A685B for ; Sun, 30 May 2010 18:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.342 X-Spam-Level: X-Spam-Status: No, score=-8.342 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 au51xuNkFWvs for ; Sun, 30 May 2010 18:09:13 -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 4360D3A6813 for ; Sun, 30 May 2010 18:09:13 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM6oAkxAZnwN/2dsb2JhbACDGJsacaZziQkIj1+BIoMFbwSDMQ X-IronPort-AV: E=Sophos;i="4.53,329,1272844800"; d="scan'208";a="116385913" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 May 2010 01:09:01 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4V191Mu004236; Mon, 31 May 2010 01:09:01 GMT Message-ID: <4C030C2D.9040003@cisco.com> Date: Sun, 30 May 2010 21:09:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 01:09:16 -0000 gao.yang2@zte.com.cn wrote: > > I guess you are talking about section 4.5 of the draft. Yes. > But section 4.5's rules only apply to case which has ambiguity. I think > that the talked use case here has no ambiguity. So, nothing is forbidden > here. I don't know for certain when those rules apply. It says "When checking for glare conditions". That is too vague for me. Under what circumstances does the UA check for glare conditions? My longer message on glare, etc. is probably a better context within which to have this discussion. Thanks, Paul > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Paul Kyzivat * > ·¢¼þÈË: sipcore-bounces@ietf.org > > 2010-05-31 08:03 > > > ÊÕ¼þÈË > "Elwell, John" > ³­ËÍ > "gao.yang2@zte.com.cn" , "sipcore@ietf.org" > > Ö÷Ìâ > Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP > > > > > > > > > > > Elwell, John wrote: > > If an UPDATE request without SDP offer cannot be accepted when only > an unreliable provisional response has occurred, I believe this is a > normative change to RFC 3311. > > Yes, I agree. And I think its an undesirable change too. > > Thanks, > Paul > > > John > > > >> -----Original Message----- > >> From: Brett Tate [mailto:brett@broadsoft.com] > >> Sent: 24 May 2010 14:25 > >> To: gao.yang2@zte.com.cn > >> Cc: Elwell, John; sipcore@ietf.org > >> Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare > >> and UPDATE without SDP > >> > >>>> Concerning glare, my understanding is that the draft mandates > >>>> treating UPDATE without offer as though it contained an offer. > >>>> > >>>> I'm still trying to understand how section 3.5 and 4.5 are to be > >>>> interpreted. Because the draft uses offer/answer rules for the > >>>> "fix", it prevents using UPDATE without SDP on an early > >> dialog until > >>>> allowed per offer/answer rules. > >>> Not exactly here. The text never forbit usage of UPDATE > >> without offer by O/A rules. > >> > >> I agree that it doesn't forbid sending it. It allows it and > >> mandates the UAS return 491 or 500 (depending upon direction). > >> > >> > > _______________________________________________ > > 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 > > > > -------------------------------------------------------- > 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 Sun May 30 18:13:29 2010 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 440C73A6982 for ; Sun, 30 May 2010 18:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.909 X-Spam-Level: X-Spam-Status: No, score=-96.909 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Pcrb1DT1B8vK for ; Sun, 30 May 2010 18:13: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 5BD733A6883 for ; Sun, 30 May 2010 18:13:25 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 31 May 2010 09:06:46 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 32518.4821350471; Mon, 31 May 2010 09:07:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4V1C2qE074106; Mon, 31 May 2010 09:12:05 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C02E3BF.3080905@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 31 May 2010 09:09:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-31 09:12:04, Serialize complete at 2010-05-31 09:12:04 Content-Type: multipart/alternative; boundary="=_alternative 00068CF048257734_=" X-MAIL: mse2.zte.com.cn o4V1C2qE074106 Cc: OKUMURA Shinji , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 01:13:29 -0000 This is a multipart message in MIME format. --=_alternative 00068CF048257734_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U2hpbmppIGlzIHF1ZXN0aW9uIGlzIGFib3V0IGhvdyB0byBkaXN0aW5ndWlzaCB0aGUgdHdvIGNo YXJ0Lg0KDQpJIGd1ZXNzIG15IHByZXZpb3VzIG1haWxzOg0KDQpodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzAyODExLmh0bWwNCmFuZCANCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDI4 MDQuaHRtbA0KDQpoYXZlIHNldHRsZWQgU2hpbmppJ3MgcXVlc3Rpb24gaGVyZS4NCg0KQW5kIGlm IFNoaW5qaSBoYXMgc29tZXRoaW5nIG5ldywgcGxlYXNlIGdvIG9uLg0KDQpUaGFua3MsDQoNCkdh bw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAx Mg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwg OiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCg0KDQoNClBhdWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPiANCreivP7IyzogIHNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNS0zMSAwNjoxNg0KDQrK1bz+yMsNCk9LVU1V UkEgU2hpbmppIDxzaGluamkub2t1bXVyYUBzb2Z0ZnJvbnQuanA+DQqzrcvNDQpnYW8ueWFuZzJA enRlLmNvbS5jbiwgInNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3JlQGlldGYub3JnPg0K1vfM4g0K UmU6IFtzaXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6IGdsYXJlIGFuZCBV UERBVEUgIHdpdGhvdXQgDQpTRFANCg0KDQoNCg0KDQoNCkkgcmVhZCB0aHJvdWdoIHRoaXMgZGlz Y3Vzc2lvbiwgYW5kIEkgY2Fubm90IGZpZ3VyZSBvdXQgd2hhdCB0aGUgDQpkaWZmZXJlbmNlIGlz IGJldHdlZW4gdGhlIHR3byBvZiB5b3UuIEFzIG9mIHRoaXMgcmVwbHkgaXQgc2VlbXMgdG8gbWUg DQp0aGF0IHRoZSB0d28gb2YgeW91IGFyZSBhZ3JlZWluZy4NCg0KQ2FuIG9uZSBvZiB5b3UgcmVz dGF0ZSB0aGUgaXNzdWUgYW5kIHRoZSBjb250cmFzdGluZyBzb2x1dGlvbnM/DQoNCiAgICAgICAg ICAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAgICBQYXVsDQoNCk9LVU1VUkEgU2hpbmpp IHdyb3RlOg0KPiBHYW8sDQo+IA0KPiBUaGlzIGlzIGEgZmlndXJlIEkndmUgYXNzdW1lZC4NCj4g DQo+ICAgICBBICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEINCj4gICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgIHMwfHJlLUlOViAob2ZmZXIxKSAgICAgICAg ICAgICAgICB8czANCj4gICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KPiAg ICAgfCAgICAgICAgICAgICAgIDE4eC1yZWwoYW5zd2VyMSl8DQo+ICAgICB8PC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLXwNCj4gICBzMXwgICAgICAgICAgICAgICAgICAgICAgICBub24t Mnh4fHMxDQo+ICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXw8LSsNCj4gICBz MHxBQ0sgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHMwfA0KPiAgICAgfC0tLS0tLS0tLS0t PiAgICAgICAgICAgICAgICAgICB8ICB8DQo+ICAgICB8VVBEKG9mZmVyMCkgICAgICAgICAgICAg ICAgICAgIHwgIHwNCj4gICAgIHw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0+fCogfCBy ZWplY3QgVVBEQVRFDQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICA0OTEoVVBEKXwgIHwN Cj4gICAgIHw8PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09fCAgfA0KPiAgICAgfCAgICAg ICAgICAgICAgICAgICAgQUNLICAgICAgICB8ICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAg ICAtLS0tLS0tLS0tPnw8LSsNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KPiAgICAgICAgICAgICAgICAgRmlndXJlIDINCj4gDQo+PiBIaSwNCj4+DQo+PiBPS1VNVVJB IFNoaW5qaSA8c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwPg0KPj4+IEdhbywNCj4+Pg0KPj4+ IGdhby55YW5nMkB6dGUuY29tLmNuDQo+Pj4gVHVlLCAyNSBNYXkgMjAxMCAxNDoxNToxMCArMDgw MA0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4+Pj4gSSBhZ3JlZSB0aGF0IGl0IGRvZXNuJ3QgZm9yYmlk IHNlbmRpbmcgaXQuICBJdCBhbGxvd3MgaXQgYW5kIA0KPj4+Pj4+PiBtYW5kYXRlcyB0aGUgVUFT IHJldHVybiA0OTEgb3IgNTAwIChkZXBlbmRpbmcgdXBvbiBkaXJlY3Rpb24pLg0KPj4+Pj4+IEl0 IG1hbmRhdGVzIHRoZSBVQVMgc2VuZCA0eHgvNXh4IHRvIFVQREFURSBvbmx5IHdoZW4gdGhlIFVB Uw0KPj4+Pj4+IHNlbmQgNHh4LzV4eCB0byB0aGUgUmUtSU5WSVRFIGFuZCB0aGUgVUFTIGdldCB0 aGUgVVBEQVRFIGJlZm9yZQ0KPj4+Pj4+IEFDSyBvZiA0eHgvNXh4KFJlLUlOVklURSkuDQo+Pj4+ PiBBcyB5b3Uga25vdywgQUNLIHRvIG5vbi0yeHggaXMgaG9wLWJ5LWhvcC4NCj4+Pj4+IFRoZXJl IGlzIGxpdHRsZSBiZW5lZml0IHRvIHJlamVjdCBzdWNoIGFuIFVQREFURS4NCj4+Pj4gVUFTIHNl bmQgNDkxIGZvciB0aGUgVVBEQVRFKGluIHRoZSBmbG93KSB0byAqdGVsbCogVUFDIHRoYXQgaW4g aXQncw0KPj4+PiAoVUFTKSANCj4+Pj4gdmlldywgdGhlcmUncyBhIGdsYXJlIGNhc2UuDQo+Pj4g QnV0IHRoaXMgVVBEQVRFIGlzIHNlbnQgaW4gb3JkZXIgdG8gc3luY2hyb25pemUgdGhlIGNvbW1v biB2aWV3Lg0KPj4+IElmIFVBUyByZXR1cm4gMnh4LCB0aGVuIHRoZSBzaXR1YXRpb24gZ29lcyBp bnRvIG5vbmdsYXJlLg0KPj4gSSBndWVzcyBJIGhhdmUgYSBpbnZlcnNlIHBvaW50IGhlcmUuIEJ5 IHRoaXMgZHJhZnQncyBjbGFyaWZpY2F0aW9uLCANCj4+IHRoZXJlJ3Mgbm8gaW5jb25zaXN0ZW50 IHNlc3Npb24gc3RhdGUgZm9yIHRoZSBub24tc3VjY2Vzc2Z1bCBSZS1JTlZJVEUuIA0KDQo+PiBT bywgd2h5IFVBQyBzZW5kIGEgVVBEQVRFIHRvIHN5bmNocm9uaXplIHRoZSBjb21tb24gdmlldz8N Cj4gDQo+IEluIDMuNC4gIFVBQyBCZWhhdmlvciwNCj4gICAiSW4gb3JkZXIgdG8gY29wZSB3aXRo IHRoZXNlIHJhY2UgY29uZGl0aW9uDQo+ICAgIHNpdHVhdGlvbnMsIGEgVUFDIHRoYXQgcmVjZWl2 ZXMgYW4gZXJyb3IgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUgZm9yDQo+ICAgIHdoaWNoIGNoYW5n ZXMgaGF2ZSBiZWVuIGFscmVhZHkgZXhlY3V0ZWQgU0hPVUxEIGdlbmVyYXRlIGEgbmV3IHJlLQ0K PiAgICBJTlZJVEUgb3IgVVBEQVRFIHJlcXVlc3QgaW4gb3JkZXIgdG8gbWFrZSBzdXJlIHRoYXQg Ym90aCBVQXMgaGF2ZSBhDQo+ICAgIGNvbW1vbiB2aWV3IG9mIHRoZSBzdGF0ZSBvZiB0aGUgZGlh bG9nIGFuZCB0aGUgc2Vzc2lvbi4iDQo+IA0KPiBVbmRlciB0aGUgYWJvdmUgZGVzY3JpcHRpb25z LCB0aGlzIFVBQyBnZW5lcmF0ZXMgYSBuZXcgVVBEQVRFLg0KPiANCj4+IFdoaWxlIGlmIFVBUyBy ZXR1cm4gMnh4KGZvciB0aGUgVVBEQVRFKSwgdGhlIHNpdHVhdGlvbiB3b3VsZCBnZXQgaW50byAN Cj4+IGdsYXJlKFVBUyBoYXMgbm8gd2F5IHRvIGZpZ3VyZSBvdXQgdGhpcyBVUERBVEUgaXMgaW4t c2NvcGUgb2YgUmUtSU5WSVRFIA0Kb3IgDQo+PiBub3QpLiBUaGlzIGlzIHJlbGF0aW5nIHRvIGF0 b21pYyBvZiBzZXNzaW9uIHN0YXRlLiBJJ2QgbGlrZSB0byANCmVtcGhhc2l6ZSANCj4+IHRoYXQg a2VlcGluZyBSZS1JTlZJVEUgYXRvbWljLCBleGNlcHQgZm9yIHRhcmdldCByZWZyZXNoLCBpcyB0 aGUgbWFpbiANCmlkZWEgDQo+PiBpbiB0aGlzIGRyYWZ0Lg0KPiANCj4gVGhpcyBpc3N1ZSBoYXMg bm90aGluZyB0byBkbyB3aXRoIHRoZSAiYXRvbWljIG9mIHNlc3Npb24gc3RhdGUiLg0KPiANCj4+ PiBQcm9iYWJseSBhbm90aGVyIFVQREFURSB3aWxsIGJlIHNlbnQsIGJ1dCB0aGlzIFVQREFURQ0K Pj4+IHRyYW5zYWN0aW9uIGlzIHN1cHBvc2VkIHRvIGJlIGF2b2lkZWQuDQo+Pj4NCj4+PiBBdCB0 aGUgdmVyeSBzdGFydCwgdGhlIFVBUyByZWplY3RzIGEgcmVJTlZJVEUgZG9lcyBub3QgY2FyZQ0K Pj4+IGFib3V0IHRoaXMgdGV4dC4gSXMgaXQgbmVjZXNzYXJ5IHRvIGxldCBzdWNoIGEgVUFTIGZv bGxvdyBhDQo+Pj4gbmV3IHJ1bGU/DQo+PiBUaGVzZSBkYXlzLCB5b3UgZ3V5cyBzaG93ZWQgYSBs b3Qgb2YgdXNlIGNhc2VzLiBJIGRvbid0IHJlbWVtYmVyIHRoZSANCj4+IGRldGFpbHMuIENvdWxk IHlvdSBzYXkgbW9yZSBhYm91dCB0aGlzIHVzZSBjYXNlLg0KPiANCj4gUGxlYXNlIGxvb2sgYXQg dGhlIG9yaWdpbmFsIG1haWwgb2YgbWluZSwgYW5kIHJlLWNvbW1lbnQgaXQuDQo+IFlvdSBzZWVt IHRvIGJlIGNvbmZ1c2VkIGEgbGl0dGxlLg0KPiANCj4+Pj4gV2hlbiBVQVMgZ2V0IHRoZSBBQ0sg dGhlbiBVUERBVEUsIGl0IHN0aWxsIGhhcyBubyBwcmVjaXNlIGNyaXRlcmlvbiANCmZvciANCj4+ Pj4gd2hldGhlciB0aGUgVUFDIGdldHMgbm9uLTJ4eChSZS1JTlZJVEUpIGZpcnN0IHRoZW4gc2Vu ZCB0aGUgVVBEQVRFIG9yIA0Kbm90LiANCj4+Pj4gS2VlcGluZyByZWplY3RpbmcgdGhlIFVQREFU RSBpcyBub3QgYSByZWFzb25hYmxlIHdheSBoZXJlLiBTbywgdGhlIA0KZHJhZnQgDQo+Pj4+IHN1 Z2dlc3QgdGhlIHdheSwgYXMgVUFTIGNhbiBzZW5kIDJ4eCB0byB0aGUgVVBEQVRFLg0KPj4+IEl0 IGlzIGEgY29udmVudGlvbmFsIGhhbmRsaW5nIGFuZCBlbm91Z2ggZm9yIFVBUy4NCj4+Pg0KPj4+ PiBXaGVuIFVBQyBnZXQgVUFTJ3MgNHh4IG9mIFVQREFURSwgdGhlIHNlc3Npb24gc3RhdGUgaXMg Y2xlYXIgZm9yIGl0LiANCkFuZCANCj4+Pj4gVUFDIHdvdWxkIG9ubHkgc2VuZCBhIHN5bmNocm9u aXppbmcgUmUtSU5WSVRFL1VQREFURSB3aGVuIGl0IGlzIGEgDQpnbGFyZSANCj4+Pj4gY2FzZSBp biB0aGUgVUFDJ3Mgdmlldy4NCj4+PiBVQVMnIGJlaGF2aW9yIGRvZXMgbm90IGFmZmVjdCBVQUMn IGJlaGF2aW9yIGRpcmVjdGx5Lg0KPj4+IFVBQyB3aWxsIGRvIHRoZSBuZWVkZnVsIHJlZ2FyZGxl c3Mgb2Ygd2hldGhlciBVQVMgcmVqZWN0cw0KPj4+IGEgcmVJTlZJVEUuDQo+Pj4NCj4+Pj4gSU1P LCB0aGlzIHdheSBpcyBiZXR0ZXIgdGhhbiB0aGUgd2F5IHdlIG1pZ2h0IG9uY2UgdXNlOiBhbGxv d2luZyBCIA0Kc2VuZA0KPj4+PiAyeHggdG8gVVBEQVRFLCBhbmQgYm90aCBBIGFuZCBCICpzZWUq IGdsYXJlLCBhbmQgYWxsIHNlbmQgDQpSZS1JTlZJVEUvVVBEQVRFIA0KPj4+PiB0byByZWZyZXNo IHNlc3Npb24gc3RhdGUgYnkgZWFjaCdzIHZpZXcuDQo+Pj4gVGhlIG5ldyBydWxlIGZvciBVQVMg ZG9lcyBub3Qgc2VlbSB0byBpbXByb3ZlIHRoZSBzaXR1YXRpb24uDQo+Pj4gVGhlIG5ldyBydWxl IGZvciBVQUMgc2VlbXMgdG8gYmUganVzdCBlbm91Z2ggdG8gc3luY2hyb25pemUNCj4+PiB0aGUg dmlldy4NCj4+IFRoZSBrZXkgbWVyaXQgZm9yIHRoZSBuZXcgcnVsZSBpcyBtYWtlIGJvdGggVUFD IGFuZCBVQVMgY2xlYXIgaW4gd2hpY2ggDQo+PiBzaXR1YXRpb24gaXMgaXQncyByZXNwb25zaWJp bGl0eSB0byBoYW5kbGUgZ2xhcmUgY2FzZSwgYW5kIHRoZXJlJ3Mgb25seSANCg0KPj4gb25lIFVB IG5lZWQgdG8gZG8gc29tZXRoaW5nLiBCb3RoIHNpZGVzIHdhbnQgdG8gcmVmcmVzaCBzZXNzaW9u IHN0YXRlIA0KYnkgDQo+PiBlYWNoJ3MgdmlldyBpcyBub3QgYSBlbGVnYW50IHdheS4NCj4gDQo+ IFRoZSBjcnV4IG9mIHRoZSBtYXR0ZXIgaXMgdGhhdCBhIFVBUyBjYW4gbm90IHJlY29nbml6ZSBv d24gZ2xhcmUNCj4gc2l0dWF0aW9uIGFueXRpbWUuDQo+IEl0IGlzIFVBQydzIGR1dHkgdG8gc3lu Y2hyb25pemUgYSBjb21tb24gdmlldy4NCj4gDQo+IFJlZ2FyZHMsDQo+IFNoaW5qaQ0KPiANCj4+ IFRoYW5rcywNCj4+DQo+PiBHYW8NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBt YWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkg cHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmlj YXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFu eSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZp ZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00068CF048257734_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNoaW5qaSBpcyBxdWVz dGlvbiBpcyBhYm91dCBob3cgdG8gZGlzdGluZ3Vpc2gNCnRoZSB0d28gY2hhcnQuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGd1ZXNzIG15IHByZXZp b3VzIG1haWxzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9t c2cwMjgxMS5odG1sPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5h bmQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzAyODA0Lmh0bWw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhhdmUgc2V0 dGxlZCBTaGluamkncyBxdWVzdGlvbiBoZXJlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIGlmIFNoaW5qaSBoYXMgc29tZXRoaW5nIG5ldywgcGxl YXNlDQpnbyBvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJz cDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJz cDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5j bjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlBhdWwgS3l6aXZhdCAmbHQ7 cGt5eml2YXRAY2lzY28uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wNS0zMSAwNjoxNjwv Zm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5P S1VNVVJBIFNoaW5qaSAmbHQ7c2hpbmppLm9rdW11cmFAc29mdGZyb250LmpwJmd0OzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+Z2FvLnlhbmcyQHp0ZS5jb20uY24sICZxdW90O3NpcGNvcmVAaWV0Zi5vcmcm cXVvdDsNCiZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtz aXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtMDQ6DQpnbGFyZSBhbmQgVVBEQVRF ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dpdGhvdXQgU0RQPC9mb250PjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIHJlYWQgdGhyb3VnaCB0 aGlzIGRpc2N1c3Npb24sIGFuZCBJIGNhbm5vdCBmaWd1cmUNCm91dCB3aGF0IHRoZSA8YnI+DQpk aWZmZXJlbmNlIGlzIGJldHdlZW4gdGhlIHR3byBvZiB5b3UuIEFzIG9mIHRoaXMgcmVwbHkgaXQg c2VlbXMgdG8gbWUgPGJyPg0KdGhhdCB0aGUgdHdvIG9mIHlvdSBhcmUgYWdyZWVpbmcuPGJyPg0K PGJyPg0KQ2FuIG9uZSBvZiB5b3UgcmVzdGF0ZSB0aGUgaXNzdWUgYW5kIHRoZSBjb250cmFzdGlu ZyBzb2x1dGlvbnM/PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClRoYW5rcyw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KUGF1bDxicj4NCjxicj4NCk9L VU1VUkEgU2hpbmppIHdyb3RlOjxicj4NCiZndDsgR2FvLDxicj4NCiZndDsgPGJyPg0KJmd0OyBU aGlzIGlzIGEgZmlndXJlIEkndmUgYXNzdW1lZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyBBICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBCPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyBzMHxyZS1JTlYgKG9mZmVy MSkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDt8czA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSZndDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDE4eC1yZWwoYW5zd2VyMSl8PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4NCiZn dDsgJm5ic3A7IHMxfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtub24tMnh4fHMxPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCZs dDstKzxicj4NCiZndDsgJm5ic3A7IHMwfEFDSyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3xzMHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfC0tLS0tLS0tLS0tJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHxVUEQob2ZmZXIwKSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fCAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHw9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0mZ3Q7fCogfCByZWplY3QgVVBEQVRFPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgNDkxKFVQRCl8ICZuYnNwO3w8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgfCZsdDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT18ICZu YnNwO3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7QUNLICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDstLS0tLS0tLS0tJmd0O3wmbHQ7LSs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBGaWd1cmUgMjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgSGksPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBPS1VNVVJBIFNoaW5qaSAmbHQ7c2hpbmppLm9rdW11cmFAc29mdGZyb250 LmpwJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBHYW8sPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0OyZndDsmZ3Q7IFR1ZSwgMjUg TWF5IDIwMTAgMTQ6MTU6MTAgKzA4MDA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhpLDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgYWdyZWUg dGhhdCBpdCBkb2Vzbid0IGZvcmJpZCBzZW5kaW5nIGl0Lg0KJm5ic3A7SXQgYWxsb3dzIGl0IGFu ZCA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hbmRhdGVzIHRoZSBVQVMgcmV0 dXJuIDQ5MSBvciA1MDAgKGRlcGVuZGluZw0KdXBvbiBkaXJlY3Rpb24pLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBtYW5kYXRlcyB0aGUgVUFTIHNlbmQgNHh4LzV4eCB0byBVUERB VEUgb25seQ0Kd2hlbiB0aGUgVUFTPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlbmQg NHh4LzV4eCB0byB0aGUgUmUtSU5WSVRFIGFuZCB0aGUgVUFTIGdldA0KdGhlIFVQREFURSBiZWZv cmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQUNLIG9mIDR4eC81eHgoUmUtSU5WSVRF KS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyB5b3Uga25vdywgQUNLIHRvIG5vbi0yeHgg aXMgaG9wLWJ5LWhvcC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBpcyBsaXR0bGUg YmVuZWZpdCB0byByZWplY3Qgc3VjaCBhbiBVUERBVEUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBV QVMgc2VuZCA0OTEgZm9yIHRoZSBVUERBVEUoaW4gdGhlIGZsb3cpIHRvICp0ZWxsKiBVQUMNCnRo YXQgaW4gaXQnczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgKFVBUykgPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyB2aWV3LCB0aGVyZSdzIGEgZ2xhcmUgY2FzZS48YnI+DQomZ3Q7Jmd0OyZndDsgQnV0IHRo aXMgVVBEQVRFIGlzIHNlbnQgaW4gb3JkZXIgdG8gc3luY2hyb25pemUgdGhlIGNvbW1vbg0Kdmll dy48YnI+DQomZ3Q7Jmd0OyZndDsgSWYgVUFTIHJldHVybiAyeHgsIHRoZW4gdGhlIHNpdHVhdGlv biBnb2VzIGludG8gbm9uZ2xhcmUuPGJyPg0KJmd0OyZndDsgSSBndWVzcyBJIGhhdmUgYSBpbnZl cnNlIHBvaW50IGhlcmUuIEJ5IHRoaXMgZHJhZnQncyBjbGFyaWZpY2F0aW9uLA0KPGJyPg0KJmd0 OyZndDsgdGhlcmUncyBubyBpbmNvbnNpc3RlbnQgc2Vzc2lvbiBzdGF0ZSBmb3IgdGhlIG5vbi1z dWNjZXNzZnVsIFJlLUlOVklURS4NCjxicj4NCiZndDsmZ3Q7IFNvLCB3aHkgVUFDIHNlbmQgYSBV UERBVEUgdG8gc3luY2hyb25pemUgdGhlIGNvbW1vbiB2aWV3Pzxicj4NCiZndDsgPGJyPg0KJmd0 OyBJbiAzLjQuICZuYnNwO1VBQyBCZWhhdmlvciw8YnI+DQomZ3Q7ICZuYnNwOyAmcXVvdDtJbiBv cmRlciB0byBjb3BlIHdpdGggdGhlc2UgcmFjZSBjb25kaXRpb248YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDtzaXR1YXRpb25zLCBhIFVBQyB0aGF0IHJlY2VpdmVzIGFuIGVycm9yIHJlc3BvbnNlIHRv DQphIHJlLUlOVklURSBmb3I8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt3aGljaCBjaGFuZ2VzIGhh dmUgYmVlbiBhbHJlYWR5IGV4ZWN1dGVkIFNIT1VMRCBnZW5lcmF0ZQ0KYSBuZXcgcmUtPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7SU5WSVRFIG9yIFVQREFURSByZXF1ZXN0IGluIG9yZGVyIHRvIG1h a2Ugc3VyZSB0aGF0IGJvdGgNClVBcyBoYXZlIGE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtjb21t b24gdmlldyBvZiB0aGUgc3RhdGUgb2YgdGhlIGRpYWxvZyBhbmQgdGhlIHNlc3Npb24uJnF1b3Q7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFVuZGVyIHRoZSBhYm92ZSBkZXNjcmlwdGlvbnMsIHRoaXMg VUFDIGdlbmVyYXRlcyBhIG5ldyBVUERBVEUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBXaGls ZSBpZiBVQVMgcmV0dXJuIDJ4eChmb3IgdGhlIFVQREFURSksIHRoZSBzaXR1YXRpb24gd291bGQg Z2V0DQppbnRvIDxicj4NCiZndDsmZ3Q7IGdsYXJlKFVBUyBoYXMgbm8gd2F5IHRvIGZpZ3VyZSBv dXQgdGhpcyBVUERBVEUgaXMgaW4tc2NvcGUgb2YNClJlLUlOVklURSBvciA8YnI+DQomZ3Q7Jmd0 OyBub3QpLiBUaGlzIGlzIHJlbGF0aW5nIHRvIGF0b21pYyBvZiBzZXNzaW9uIHN0YXRlLiBJJ2Qg bGlrZSB0bw0KZW1waGFzaXplIDxicj4NCiZndDsmZ3Q7IHRoYXQga2VlcGluZyBSZS1JTlZJVEUg YXRvbWljLCBleGNlcHQgZm9yIHRhcmdldCByZWZyZXNoLCBpcyB0aGUNCm1haW4gaWRlYSA8YnI+ DQomZ3Q7Jmd0OyBpbiB0aGlzIGRyYWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGlzc3Vl IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlICZxdW90O2F0b21pYyBvZiBzZXNzaW9uIHN0YXRl JnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFByb2JhYmx5IGFub3RoZXIgVVBE QVRFIHdpbGwgYmUgc2VudCwgYnV0IHRoaXMgVVBEQVRFPGJyPg0KJmd0OyZndDsmZ3Q7IHRyYW5z YWN0aW9uIGlzIHN1cHBvc2VkIHRvIGJlIGF2b2lkZWQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7IEF0IHRoZSB2ZXJ5IHN0YXJ0LCB0aGUgVUFTIHJlamVjdHMgYSByZUlOVklU RSBkb2VzIG5vdCBjYXJlPGJyPg0KJmd0OyZndDsmZ3Q7IGFib3V0IHRoaXMgdGV4dC4gSXMgaXQg bmVjZXNzYXJ5IHRvIGxldCBzdWNoIGEgVUFTIGZvbGxvdw0KYTxicj4NCiZndDsmZ3Q7Jmd0OyBu ZXcgcnVsZT88YnI+DQomZ3Q7Jmd0OyBUaGVzZSBkYXlzLCB5b3UgZ3V5cyBzaG93ZWQgYSBsb3Qg b2YgdXNlIGNhc2VzLiBJIGRvbid0IHJlbWVtYmVyDQp0aGUgPGJyPg0KJmd0OyZndDsgZGV0YWls cy4gQ291bGQgeW91IHNheSBtb3JlIGFib3V0IHRoaXMgdXNlIGNhc2UuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFBsZWFzZSBsb29rIGF0IHRoZSBvcmlnaW5hbCBtYWlsIG9mIG1pbmUsIGFuZCByZS1j b21tZW50IGl0Ljxicj4NCiZndDsgWW91IHNlZW0gdG8gYmUgY29uZnVzZWQgYSBsaXR0bGUuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFdoZW4gVUFTIGdldCB0aGUgQUNLIHRoZW4g VVBEQVRFLCBpdCBzdGlsbCBoYXMgbm8gcHJlY2lzZQ0KY3JpdGVyaW9uIGZvciA8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IHdoZXRoZXIgdGhlIFVBQyBnZXRzIG5vbi0yeHgoUmUtSU5WSVRFKSBmaXJz dCB0aGVuIHNlbmQNCnRoZSBVUERBVEUgb3Igbm90LiA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEtl ZXBpbmcgcmVqZWN0aW5nIHRoZSBVUERBVEUgaXMgbm90IGEgcmVhc29uYWJsZSB3YXkgaGVyZS4N ClNvLCB0aGUgZHJhZnQgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBzdWdnZXN0IHRoZSB3YXksIGFz IFVBUyBjYW4gc2VuZCAyeHggdG8gdGhlIFVQREFURS48YnI+DQomZ3Q7Jmd0OyZndDsgSXQgaXMg YSBjb252ZW50aW9uYWwgaGFuZGxpbmcgYW5kIGVub3VnaCBmb3IgVUFTLjxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgV2hlbiBVQUMgZ2V0IFVBUydzIDR4eCBvZiBVUERB VEUsIHRoZSBzZXNzaW9uIHN0YXRlIGlzDQpjbGVhciBmb3IgaXQuIEFuZCA8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IFVBQyB3b3VsZCBvbmx5IHNlbmQgYSBzeW5jaHJvbml6aW5nIFJlLUlOVklURS9V UERBVEUgd2hlbg0KaXQgaXMgYSBnbGFyZSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNhc2UgaW4g dGhlIFVBQydzIHZpZXcuPGJyPg0KJmd0OyZndDsmZ3Q7IFVBUycgYmVoYXZpb3IgZG9lcyBub3Qg YWZmZWN0IFVBQycgYmVoYXZpb3IgZGlyZWN0bHkuPGJyPg0KJmd0OyZndDsmZ3Q7IFVBQyB3aWxs IGRvIHRoZSBuZWVkZnVsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBVQVMgcmVqZWN0czxicj4NCiZn dDsmZ3Q7Jmd0OyBhIHJlSU5WSVRFLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgSU1PLCB0aGlzIHdheSBpcyBiZXR0ZXIgdGhhbiB0aGUgd2F5IHdlIG1pZ2h0IG9uY2Ug dXNlOg0KYWxsb3dpbmcgQiBzZW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAyeHggdG8gVVBEQVRF LCBhbmQgYm90aCBBIGFuZCBCICpzZWUqIGdsYXJlLCBhbmQgYWxsIHNlbmQNClJlLUlOVklURS9V UERBVEUgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0byByZWZyZXNoIHNlc3Npb24gc3RhdGUgYnkg ZWFjaCdzIHZpZXcuPGJyPg0KJmd0OyZndDsmZ3Q7IFRoZSBuZXcgcnVsZSBmb3IgVUFTIGRvZXMg bm90IHNlZW0gdG8gaW1wcm92ZSB0aGUgc2l0dWF0aW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUg bmV3IHJ1bGUgZm9yIFVBQyBzZWVtcyB0byBiZSBqdXN0IGVub3VnaCB0byBzeW5jaHJvbml6ZTxi cj4NCiZndDsmZ3Q7Jmd0OyB0aGUgdmlldy48YnI+DQomZ3Q7Jmd0OyBUaGUga2V5IG1lcml0IGZv ciB0aGUgbmV3IHJ1bGUgaXMgbWFrZSBib3RoIFVBQyBhbmQgVUFTIGNsZWFyDQppbiB3aGljaCA8 YnI+DQomZ3Q7Jmd0OyBzaXR1YXRpb24gaXMgaXQncyByZXNwb25zaWJpbGl0eSB0byBoYW5kbGUg Z2xhcmUgY2FzZSwgYW5kIHRoZXJlJ3MNCm9ubHkgPGJyPg0KJmd0OyZndDsgb25lIFVBIG5lZWQg dG8gZG8gc29tZXRoaW5nLiBCb3RoIHNpZGVzIHdhbnQgdG8gcmVmcmVzaCBzZXNzaW9uDQpzdGF0 ZSBieSA8YnI+DQomZ3Q7Jmd0OyBlYWNoJ3MgdmlldyBpcyBub3QgYSBlbGVnYW50IHdheS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGhlIGNydXggb2YgdGhlIG1hdHRlciBpcyB0aGF0IGEgVUFTIGNh biBub3QgcmVjb2duaXplIG93biBnbGFyZTxicj4NCiZndDsgc2l0dWF0aW9uIGFueXRpbWUuPGJy Pg0KJmd0OyBJdCBpcyBVQUMncyBkdXR5IHRvIHN5bmNocm9uaXplIGEgY29tbW9uIHZpZXcuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBTaGluamk8YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEdhbzxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IHNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBzaXBjb3JlQGlldGYub3JnPGJy Pg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+ DQomZ3Q7IDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KPGJyPg0K PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNw O1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29u dGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5i c3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0 aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7 Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7 YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJz cDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Ns b3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJz cDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7 YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkm bmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDth cmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2 ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5i c3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5i c3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7 U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00068CF048257734_=-- From gao.yang2@zte.com.cn Sun May 30 18:27:00 2010 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 E602D3A6971 for ; Sun, 30 May 2010 18:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.243 X-Spam-Level: X-Spam-Status: No, score=-98.243 tagged_above=-999 required=5 tests=[AWL=0.995, BAYES_50=0.001, 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 O8XWplxRaWz2 for ; Sun, 30 May 2010 18:26:59 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2B38A3A6813 for ; Sun, 30 May 2010 18:26:58 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 31 May 2010 09:21:07 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.4884295178; Mon, 31 May 2010 09:26:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4V1QIhZ099797; Mon, 31 May 2010 09:26:18 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C030C2D.9040003@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 31 May 2010 09:23:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-31 09:26:17, Serialize complete at 2010-05-31 09:26:17 Content-Type: multipart/alternative; boundary="=_alternative 0007DB2A48257734_=" X-MAIL: mse2.zte.com.cn o4V1QIhZ099797 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 01:27:01 -0000 This is a multipart message in MIME format. --=_alternative 0007DB2A48257734_= Content-Type: text/plain; charset="US-ASCII" > > I guess you are talking about section 4.5 of the draft. > > Yes. > > > But section 4.5's rules only apply to case which has ambiguity. I think > > that the talked use case here has no ambiguity. So, nothing is forbidden > > here. > > I don't know for certain when those rules apply. It says "When checking > for glare conditions". That is too vague for me. Under what > circumstances does the UA check for glare conditions? Yes. I also think the words is vague. So, I think we may need *words enhancement*, if my understanding of it's technical semantics is correct. If it's technical semantics is not correct or not comprehensive enough, we might need *words and technical enhancement* at the same time here. My point here is that as ther's arguement about it's technical semantics's correctness(IMO, section 3.5 and 4.5 is correct, technically), it would be more acceptable for me to describe it as "its an *potential* undesirable change too". > > My longer message on glare, etc. is probably a better context within > which to have this discussion. I am reading it, and will go on soon. Thanks, Gao -------------------------------------------------------- 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 0007DB2A48257734_= Content-Type: text/html; charset="US-ASCII"

> > I guess you are talking about section 4.5 of the draft.
>
> Yes.
>
> > But section 4.5's rules only apply to case which has ambiguity. I think
> > that the talked use case here has no ambiguity. So, nothing is forbidden
> > here.
>
> I don't know for certain when those rules apply. It says "When checking
> for glare conditions". That is too vague for me. Under what
> circumstances does the UA check for glare conditions?

Yes. I also think the words is vague.
So, I think we may need *words enhancement*, if my understanding of it's technical semantics is correct.
If it's technical semantics is not correct or not comprehensive enough, we might need *words and technical enhancement* at the same time here.

My point here is that as ther's arguement about it's technical semantics's correctness(IMO, section 3.5 and 4.5 is correct, technically), it would be more acceptable for me to describe it as "its an *potential* undesirable change too".

>
> My longer message on glare, etc. is probably a better context within
> which to have this discussion.

I am reading it, and will go on soon.

Thanks,

Gao

--------------------------------------------------------
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 0007DB2A48257734_=-- From shinji.okumura@softfront.jp Sun May 30 21:22:02 2010 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 4CB933A6925 for ; Sun, 30 May 2010 21:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.567 X-Spam-Level: X-Spam-Status: No, score=-94.567 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_73=0.6, RELAY_IS_221=2.222, 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 Mh2izTsMwtVa for ; Sun, 30 May 2010 21:21:59 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 969523A698F for ; Sun, 30 May 2010 21:21:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 2E4E6428019; Mon, 31 May 2010 13:21:43 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkaHbfkKeAKy; Mon, 31 May 2010 13:21:41 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id E7EEF428016; Mon, 31 May 2010 13:21:40 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Mon, 31 May 2010 13:21:42 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: References: Message-Id: <71CB0078C5EED8shinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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, 31 May 2010 04:22:02 -0000 Gao, >> I understand. >> >> The text says that the UAC can not expect to receive a 487 >> response to the INVITE. Right? > >As UAC's old contact has been lost, UAC can not expect to receive any >final response for the old Re-INVITE here. >So, the specific for final response is not important here. And the UAC's >next Re-INVITE as synchronization can refresh the state here. Even if the UAS would send a new UPDATE to undo the changes and return a 2xx to the reINVITE, the UAC never receive the 2xx. The UAC will assume that the reINVITE is rejected with 408 (Request Timeout) and send a new UPDATE or reINVITE to synchronize a common view. And if the UAS responds 2xx to the reINVITE, it waits for an ACK from the UAC, but the UAC never send an ACK. If the UAS responds a 487, it can expect to receive an ACK from an adjacent proxy. After all, if a UAS receives a target-refresh UPDATE within a reINVITE transaction, the UAS should send a 4xx(487?) to the reINVITE immediately without sending a new UPDATE to undo the changes. >> And now, assuming that some of changes have already been >> executed, the UAS would send a new UPDATE to undo the changes. >> But the local target of the UAC has been changed, so I think UAC >> should an UPDATE to announce own new target before sending the >> CANCEL. >> >> Do you think so? > >I think the UAC should send a target refresh UPDATE before CANCEL. But the >reason is not about UAS's rollback usage UPDATE.(the state would be >synchronized by a next Re-INVITE). > >To send a new request(the CANCEL) at new address, sending a target refresh >UPDATE before the new request (the CANCEL) might be better. IMO a CANCEL transaction doesn't depend on a local target. It has only one Via header that is identical to the one of the reINVITE. The UAC may not be able to receive a response to the CANCEL and an adjacent proxy may retransmit the response. Should the UAC send the CANCEL? Regards, Shinji From gao.yang2@zte.com.cn Sun May 30 22:35:45 2010 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 8CF543A697F for ; Sun, 30 May 2010 22:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.367 X-Spam-Level: X-Spam-Status: No, score=-99.367 tagged_above=-999 required=5 tests=[AWL=1.871, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, 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 cAhVKg8uTFFQ for ; Sun, 30 May 2010 22:35:40 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 0DC9E3A659C for ; Sun, 30 May 2010 22:35:39 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 31 May 2010 13:29:46 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3015714703; Mon, 31 May 2010 13:35:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4V5Z3k1028393; Mon, 31 May 2010 13:35:03 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <71CB0078C5EED8shinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 31 May 2010 13:32:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-31 13:34:58, Serialize complete at 2010-05-31 13:34:58 Content-Type: multipart/alternative; boundary="=_alternative 001E9F7D48257734_=" X-MAIL: mse2.zte.com.cn o4V5Z3k1028393 Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.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, 31 May 2010 05:35:45 -0000 This is a multipart message in MIME format. --=_alternative 001E9F7D48257734_= Content-Type: text/plain; charset="US-ASCII" > >As UAC's old contact has been lost, UAC can not expect to receive any > >final response for the old Re-INVITE here. > >So, the specific for final response is not important here. And the UAC's > >next Re-INVITE as synchronization can refresh the state here. > > Even if the UAS would send a new UPDATE to undo the changes > and return a 2xx to the reINVITE, the UAC never receive the 2xx. > The UAC will assume that the reINVITE is rejected with 408 > (Request Timeout) and send a new UPDATE or reINVITE to > synchronize a common view. I think, a new UPDATE or ReINVITE to synchronize state is mandatory here. I guess you have the same point here. 4xx to the old ReINVITE is not proper, if there's some change/modification in the ReINVITE has be enforced. This is the basic concept in the draft. If there's no change/modification in the ReINVITE has be enforced, 4xx would be OK. > And if the UAS responds 2xx to the reINVITE, it waits for an > ACK from the UAC, but the UAC never send an ACK. > If the UAS responds a 487, it can expect to receive an ACK > from an adjacent proxy. > > After all, if a UAS receives a target-refresh UPDATE within > a reINVITE transaction, the UAS should send a 4xx(487?) to > the reINVITE immediately without sending a new UPDATE to > undo the changes. > > >> And now, assuming that some of changes have already been > >> executed, the UAS would send a new UPDATE to undo the changes. > >> But the local target of the UAC has been changed, so I think UAC > >> should an UPDATE to announce own new target before sending the > >> CANCEL. > >> > >> Do you think so? > > > >I think the UAC should send a target refresh UPDATE before CANCEL. But the > >reason is not about UAS's rollback usage UPDATE.(the state would be > >synchronized by a next Re-INVITE). > > > >To send a new request(the CANCEL) at new address, sending a target refresh > >UPDATE before the new request (the CANCEL) might be better. > > IMO a CANCEL transaction doesn't depend on a local target. Yes. But if the CANCEL send before the target refresh, UAC would not get the response. That's why I think a target refresh request would be better. But this is not the critical point here. So, if there's vendors want to send CANCEL before target refresh UPDATE, I am OK with it. > It has only one Via header that is identical to the one of > the reINVITE. > > The UAC may not be able to receive a response to the CANCEL > and an adjacent proxy may retransmit the response. > > Should the UAC send the CANCEL? You seems arguing using target refresh UPDATE to trigger UAS's final response. IMO, CANCEL might be better here. And it is more natural for UAC to send a CANCEL, if it want to terminate current pending ReINVITE. -------------------------------------------------------- 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 001E9F7D48257734_= Content-Type: text/html; charset="US-ASCII"

> >As UAC's old contact has been lost, UAC can not expect to receive any
> >final response for the old Re-INVITE here.
> >So, the specific for final response is not important here. And the UAC's
> >next Re-INVITE as synchronization can refresh the state here.
>
> Even if the UAS would send a new UPDATE to undo the changes
> and return a 2xx to the reINVITE, the UAC never receive the 2xx.
> The UAC will assume that the reINVITE is rejected with 408
> (Request Timeout) and send a new UPDATE or reINVITE to
> synchronize a common view.

I think, a new UPDATE or ReINVITE to synchronize state is mandatory here. I guess you have the same point here.

4xx to the old ReINVITE is not proper, if there's some change/modification in the ReINVITE has be enforced. This is the basic concept in the draft.

If there's no change/modification in the ReINVITE has be enforced, 4xx would be OK.

> And if the UAS responds 2xx to the reINVITE, it waits for an
> ACK from the UAC, but the UAC never send an ACK.
> If the UAS responds a 487, it can expect to receive an ACK
> from an adjacent proxy.
>
> After all, if a UAS receives a target-refresh UPDATE within
> a reINVITE transaction, the UAS should send a 4xx(487?) to
> the reINVITE immediately without sending a new UPDATE to
> undo the changes.
>
> >> And now, assuming that some of changes have already been
> >> executed, the UAS would send a new UPDATE to undo the changes.
> >> But the local target of the UAC has been changed, so I think UAC
> >> should an UPDATE to announce own new target before sending the
> >> CANCEL.
> >>
> >> Do you think so?
> >
> >I think the UAC should send a target refresh UPDATE before CANCEL. But the
> >reason is not about UAS's rollback usage UPDATE.(the state would be
> >synchronized by a next Re-INVITE).
> >
> >To send a new request(the CANCEL) at new address, sending a target refresh
> >UPDATE before the new request (the CANCEL) might be better.
>
> IMO a CANCEL transaction doesn't depend on a local target.

Yes. But if the CANCEL send before the target refresh, UAC would not get the response.
That's why I think a target refresh request would be better. But this is not the critical point here.
So, if there's vendors want to send CANCEL before target refresh UPDATE, I am OK with it.

> It has only one Via header that is identical to the one of
> the reINVITE.
>
> The UAC may not be able to receive a response to the CANCEL
> and an adjacent proxy may retransmit the response.
>
> Should the UAC send the CANCEL?

You seems arguing using target refresh UPDATE to trigger UAS's final response. IMO, CANCEL might be better here.

And it is more natural for UAC to send a CANCEL, if it want to terminate current pending ReINVITE. 

--------------------------------------------------------
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 001E9F7D48257734_=-- From shinji.okumura@softfront.jp Sun May 30 23:10:11 2010 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 027913A69E7 for ; Sun, 30 May 2010 23:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.88 X-Spam-Level: X-Spam-Status: No, score=-94.88 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 x3k9IWfKK4Yb for ; Sun, 30 May 2010 23:10:10 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id D12843A69E6 for ; Sun, 30 May 2010 23:10:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 9D061428016; Mon, 31 May 2010 15:09:57 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iapSpGOn4+Gq; Mon, 31 May 2010 15:09:55 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id CA05842800D; Mon, 31 May 2010 15:09:54 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 31 May 2010 15:09:56 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C02E68D.90005@cisco.com> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <70CAF9873ACDA5shinji.okumura@softfront.jp> <4C02E68D.90005@cisco.com> Message-Id: Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare andUPDATE withoutSDP 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, 31 May 2010 06:10:11 -0000 Paul, Paul Kyzivat Sun, 30 May 2010 18:28:29 -0400 >Shinji, > >I agree with what you say, but perhaps for different reasons, for based >on different view of what "glare" means. > >IMO the 491 response should be used to indicate glare has been detected, >specifically that a proposal to negotiate a state change has been >*received* while a previously *sent* proposal to negotiate a state >change is still unresolved. That can apply to o/a regardless of what >messages cause the situation to be detected. And I think this can apply >even when receiving an offerless reINVITE, which is a demand for an offer. > >OTOH the 500 response applies when a proposal to negotiate a state >change has been *received* while a previously *received* proposal to >negotiate state is still unresolved. This is not glare, because the >problem is not the result of coincidence in valid behavior. The 500 is a >suitable response because it is bad behavior by the sender of those >proposals that results in the problem. IMO whether your view and mine are different depend on one disputed point. Which is a UAC that sends an offerless reINVITE, a "sender" of the negotiation or a "receiver"? If it is a "sender", then we say the same thing by a different wording. I call it "client transaction", you call it "sender". You say "an offerless reINVITE is a demand for an offer". I think we are agreeing. Regards, Shinji > Thanks, > Paul > >OKUMURA Shinji wrote: >> Hi Brett, >> >> I have a similar question too. >> >> RFC 3261 and 3311 describe the definition regarding 500 and >> 491 response. >> When UA rejects the INVITE during an INVITE transaction, or >> rejects the UPDATE during an UPDATE transaction, it has nothing >> to do with offer-answer which error code to be used. >> >> If both transaction have the same direction, the error code is 500. >> If not, the error code is 491. >> >> But an interworking of INVITE and UPDATE is unclear. >> The draft-offeranswer makes an efforts to clarify it in the >> section 4.3. >> >>> Howdy, >>> >>> Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate >>> that an UPDATE without SDP should be treated (from a glare >>> perspective) as though it contained an offer SDP. >>> However I currently find the definition of "glare" and the >>> expected behavior to be ambiguous. >>> >>> What is the precise meaning of glare? I ask mainly because >>> some vendors send a 491 when an RFC indicates to send a 500. >>> >>> If INVITE contains offer SDP and 18x was not reliable, how >>> SHOULD the called party respond if UPDATE without SDP is >>> received from caller: 491, 500, or process as though no glare? >> >> If UA must refuse it , parhaps it is 500. >> IMO it is another question whether UA must reject the UPDATE >> without an offer. >> >>> If INVITE contains offer SDP and 18x was not reliable, how >>> SHOULD the caller respond if UPDATE without SDP is received >>>from called party: 491, 500, or process as though no glare? >> >> Parhaps it is 491. >> >>> If caller receives INVITE 2xx without offer/answer, how SHOULD >>> or MUST the caller respond if UPDATE without SDP is received >>>from called party prior to sending ACK (if not willing to >>> queue or drop UPDATE): 491 or 500? Is it a SHOULD or MUST? >> >> UA may send 2xx to UPDATE. Because the INVITE transaction has >> been completed. >> >> For reference, the following figures are now under consideration. >> >> A B >> | | >> |INVITE | >> |--------------------->|<-+ <-----+ >> | 1xx(offer or answer)| | | >> |<---------------------| | reject INVITE | reject UPDATE >> |PRACK | | Don't send INVITE | Don't send UPDATE >> |--------------------->| | | >> | 2xx-PRA| | | >> |<---------------------| | <-----+ >> | | | | may send UPDATE >> | 2xx| | | may accept UPDATE >> |<---------------------|<-+ | >> | | | may send INVITE | >> |ACK | | may accept INVITE | >> |--------------------->| | | >> | | v v >> | | >> Figure 16 >> >> A B >> | | >> |INVITE | >> |--------------------->|<-+ <-----+ >> | 1xx(offer or answer)| | | >> |<---------------------| | reject INVITE | reject UPDATE >> |PRACK | | Don't send INVITE | Don't send UPDATE >> |--------------------->| | | >> | 2xx-PRA| | | >> |<---------------------| | <-----+ >> | | | | may send UPDATE >> | 4xx| | | may acceptUPDATE >> |<---------------------|<-+ | >> | | | Don't send INVITE | >> |ACK ACK | | may accept INVITE | <-- Should B reject UPDATE or not? >> |---------> -------->|<-+ <-----+ That is another question. >> | | | | >> | | v v >> Figure 17 >> >> In both figures, >> UA A reject all INVITE/UPDATE with 491. >> UA B reject all INVITE/UPDATE with 500. >> >> Regards, >> Shinji > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From shinji.okumura@softfront.jp Mon May 31 00:44:53 2010 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 8492B3A6A06 for ; Mon, 31 May 2010 00:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.323 X-Spam-Level: X-Spam-Status: No, score=-94.323 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, RELAY_IS_221=2.222, 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 OdUgTb2BAvqj for ; Mon, 31 May 2010 00:44:52 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 428383A6A02 for ; Mon, 31 May 2010 00:44:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id D3863428016; Mon, 31 May 2010 16:44:39 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C3hO0VSBbCn; Mon, 31 May 2010 16:44:35 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id F12BB42800D; Mon, 31 May 2010 16:44:34 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 31 May 2010 16:44:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C02E3BF.3080905@cisco.com> References: <4C02E3BF.3080905@cisco.com> Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 07:44:53 -0000 Paul, In my recognition, Gao and I are not agreeing. I have two comments regarding Figure 2. 1. Between a non-2xx to a reINVITE and an ACK, the UAS may accept a receiving UPDATE. This draft seems to forbid the UPDATE. 2. In this case, the common view of both UAs has already been synchronized. IMO if an UPDATE has been not used in offer-answer exchange before 4xx, then the original rollback process may work well. That is, a following UPDATE is unnecessary in this case. Does Gao agree with my comments? Regards, Shinji Paul Kyzivat Sun, 30 May 2010 18:16:31 -0400 >I read through this discussion, and I cannot figure out what the >difference is between the two of you. As of this reply it seems to me >that the two of you are agreeing. > >Can one of you restate the issue and the contrasting solutions? > > Thanks, > Paul > >OKUMURA Shinji wrote: >> Gao, >> >> This is a figure I've assumed. >> >> A B >> | | >> s0|re-INV (offer1) |s0 >> |------------------------------>| >> | 18x-rel(answer1)| >> |<------------------------------| >> s1| non-2xx|s1 >> |<------------------------------|<-+ >> s0|ACK |s0| >> |-----------> | | >> |UPD(offer0) | | >> |==============================>|* | reject UPDATE >> | 491(UPD)| | >> |<==============================| | >> | ACK | | >> | ---------->|<-+ >> | | >> Figure 2 >> >>> Hi, >>> >>> OKUMURA Shinji >>>> Gao, >>>> >>>> gao.yang2@zte.com.cn >>>> Tue, 25 May 2010 14:15:10 +0800 >>>>> Hi, >>>>> >>>>>>>> I agree that it doesn't forbid sending it. It allows it and >>>>>>>> mandates the UAS return 491 or 500 (depending upon direction). >>>>>>> It mandates the UAS send 4xx/5xx to UPDATE only when the UAS >>>>>>> send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before >>>>>>> ACK of 4xx/5xx(Re-INVITE). >>>>>> As you know, ACK to non-2xx is hop-by-hop. >>>>>> There is little benefit to reject such an UPDATE. >>>>> UAS send 491 for the UPDATE(in the flow) to *tell* UAC that in it's >>>>> (UAS) >>>>> view, there's a glare case. >>>> But this UPDATE is sent in order to synchronize the common view. >>>> If UAS return 2xx, then the situation goes into nonglare. >>> I guess I have a inverse point here. By this draft's clarification, >>> there's no inconsistent session state for the non-successful Re-INVITE. >>> So, why UAC send a UPDATE to synchronize the common view? >> >> In 3.4. UAC Behavior, >> "In order to cope with these race condition >> situations, a UAC that receives an error response to a re-INVITE for >> which changes have been already executed SHOULD generate a new re- >> INVITE or UPDATE request in order to make sure that both UAs have a >> common view of the state of the dialog and the session." >> >> Under the above descriptions, this UAC generates a new UPDATE. >> >>> While if UAS return 2xx(for the UPDATE), the situation would get into >>> glare(UAS has no way to figure out this UPDATE is in-scope of Re-INVITE or >>> not). This is relating to atomic of session state. I'd like to emphasize >>> that keeping Re-INVITE atomic, except for target refresh, is the main idea >>> in this draft. >> >> This issue has nothing to do with the "atomic of session state". >> >>>> Probably another UPDATE will be sent, but this UPDATE >>>> transaction is supposed to be avoided. >>>> >>>> At the very start, the UAS rejects a reINVITE does not care >>>> about this text. Is it necessary to let such a UAS follow a >>>> new rule? >>> These days, you guys showed a lot of use cases. I don't remember the >>> details. Could you say more about this use case. >> >> Please look at the original mail of mine, and re-comment it. >> You seem to be confused a little. >> >>>>> When UAS get the ACK then UPDATE, it still has no precise criterion for >>>>> whether the UAC gets non-2xx(Re-INVITE) first then send the UPDATE or not. >>>>> Keeping rejecting the UPDATE is not a reasonable way here. So, the draft >>>>> suggest the way, as UAS can send 2xx to the UPDATE. >>>> It is a conventional handling and enough for UAS. >>>> >>>>> When UAC get UAS's 4xx of UPDATE, the session state is clear for it. And >>>>> UAC would only send a synchronizing Re-INVITE/UPDATE when it is a glare >>>>> case in the UAC's view. >>>> UAS' behavior does not affect UAC' behavior directly. >>>> UAC will do the needful regardless of whether UAS rejects >>>> a reINVITE. >>>> >>>>> IMO, this way is better than the way we might once use: allowing B send >>>>> 2xx to UPDATE, and both A and B *see* glare, and all send Re-INVITE/UPDATE >>>>> to refresh session state by each's view. >>>> The new rule for UAS does not seem to improve the situation. >>>> The new rule for UAC seems to be just enough to synchronize >>>> the view. >>> The key merit for the new rule is make both UAC and UAS clear in which >>> situation is it's responsibility to handle glare case, and there's only >>> one UA need to do something. Both sides want to refresh session state by >>> each's view is not a elegant way. >> >> The crux of the matter is that a UAS can not recognize own glare >> situation anytime. >> It is UAC's duty to synchronize a common view. >> >> Regards, >> Shinji >> >>> Thanks, >>> >>> Gao From shinji.okumura@softfront.jp Mon May 31 01:27:50 2010 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 CBB4D28C0D9 for ; Mon, 31 May 2010 01:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.991 X-Spam-Level: X-Spam-Status: No, score=-94.991 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 h4uyRLBt0d65 for ; Mon, 31 May 2010 01:27:49 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 0962428C0D6 for ; Mon, 31 May 2010 01:27:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id A0411428016; Mon, 31 May 2010 17:27:36 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz0komdbovHi; Mon, 31 May 2010 17:27:35 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 0517442800D; Mon, 31 May 2010 17:27:33 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 31 May 2010 17:27:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C02E68D.90005@cisco.com> References: <747A6506A991724FB09B129B79D5FEB61481641B37@EXMBXCLUS01.citservers.local> <70CAF9873ACDA5shinji.okumura@softfront.jp> <4C02E68D.90005@cisco.com> Message-Id: Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare andUPDATE withoutSDP 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, 31 May 2010 08:27:50 -0000 Paul, In RFC3311 5.2 Receiving an UPDATE A UAS that receives an UPDATE before it has generated a final response to a previous UPDATE on the same dialog MUST return a 500 response to the new UPDATE, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds. The above descriptions have nothing to do with an offer-answer. Should this rule be applied only to an offer-answer situation? Regards, Shinji Paul Kyzivat Sun, 30 May 2010 18:28:29 -0400 >Shinji, > >I agree with what you say, but perhaps for different reasons, for based >on different view of what "glare" means. > >IMO the 491 response should be used to indicate glare has been detected, >specifically that a proposal to negotiate a state change has been >*received* while a previously *sent* proposal to negotiate a state >change is still unresolved. That can apply to o/a regardless of what >messages cause the situation to be detected. And I think this can apply >even when receiving an offerless reINVITE, which is a demand for an offer. > >OTOH the 500 response applies when a proposal to negotiate a state >change has been *received* while a previously *received* proposal to >negotiate state is still unresolved. This is not glare, because the >problem is not the result of coincidence in valid behavior. The 500 is a >suitable response because it is bad behavior by the sender of those >proposals that results in the problem. > > Thanks, > Paul > >OKUMURA Shinji wrote: >> Hi Brett, >> >> I have a similar question too. >> >> RFC 3261 and 3311 describe the definition regarding 500 and >> 491 response. >> When UA rejects the INVITE during an INVITE transaction, or >> rejects the UPDATE during an UPDATE transaction, it has nothing >> to do with offer-answer which error code to be used. >> >> If both transaction have the same direction, the error code is 500. >> If not, the error code is 491. >> >> But an interworking of INVITE and UPDATE is unclear. >> The draft-offeranswer makes an efforts to clarify it in the >> section 4.3. >> >>> Howdy, >>> >>> Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate >>> that an UPDATE without SDP should be treated (from a glare >>> perspective) as though it contained an offer SDP. >>> However I currently find the definition of "glare" and the >>> expected behavior to be ambiguous. >>> >>> What is the precise meaning of glare? I ask mainly because >>> some vendors send a 491 when an RFC indicates to send a 500. >>> >>> If INVITE contains offer SDP and 18x was not reliable, how >>> SHOULD the called party respond if UPDATE without SDP is >>> received from caller: 491, 500, or process as though no glare? >> >> If UA must refuse it , parhaps it is 500. >> IMO it is another question whether UA must reject the UPDATE >> without an offer. >> >>> If INVITE contains offer SDP and 18x was not reliable, how >>> SHOULD the caller respond if UPDATE without SDP is received >>>from called party: 491, 500, or process as though no glare? >> >> Parhaps it is 491. >> >>> If caller receives INVITE 2xx without offer/answer, how SHOULD >>> or MUST the caller respond if UPDATE without SDP is received >>>from called party prior to sending ACK (if not willing to >>> queue or drop UPDATE): 491 or 500? Is it a SHOULD or MUST? >> >> UA may send 2xx to UPDATE. Because the INVITE transaction has >> been completed. >> >> For reference, the following figures are now under consideration. >> >> A B >> | | >> |INVITE | >> |--------------------->|<-+ <-----+ >> | 1xx(offer or answer)| | | >> |<---------------------| | reject INVITE | reject UPDATE >> |PRACK | | Don't send INVITE | Don't send UPDATE >> |--------------------->| | | >> | 2xx-PRA| | | >> |<---------------------| | <-----+ >> | | | | may send UPDATE >> | 2xx| | | may accept UPDATE >> |<---------------------|<-+ | >> | | | may send INVITE | >> |ACK | | may accept INVITE | >> |--------------------->| | | >> | | v v >> | | >> Figure 16 >> >> A B >> | | >> |INVITE | >> |--------------------->|<-+ <-----+ >> | 1xx(offer or answer)| | | >> |<---------------------| | reject INVITE | reject UPDATE >> |PRACK | | Don't send INVITE | Don't send UPDATE >> |--------------------->| | | >> | 2xx-PRA| | | >> |<---------------------| | <-----+ >> | | | | may send UPDATE >> | 4xx| | | may acceptUPDATE >> |<---------------------|<-+ | >> | | | Don't send INVITE | >> |ACK ACK | | may accept INVITE | <-- Should B reject UPDATE or not? >> |---------> -------->|<-+ <-----+ That is another question. >> | | | | >> | | v v >> Figure 17 >> >> In both figures, >> UA A reject all INVITE/UPDATE with 491. >> UA B reject all INVITE/UPDATE with 500. >> >> Regards, >> Shinji > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From gao.yang2@zte.com.cn Mon May 31 01:43:16 2010 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 5BBAD3A69E5 for ; Mon, 31 May 2010 01:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.374 X-Spam-Level: X-Spam-Status: No, score=-97.374 tagged_above=-999 required=5 tests=[AWL=1.264, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 6ez0WnXIYhVz for ; Mon, 31 May 2010 01:43:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 25B373A69CE for ; Mon, 31 May 2010 01:43:12 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Mon, 31 May 2010 16:35:59 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 32518.8280906739; Mon, 31 May 2010 16:30:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4V8VWll054430; Mon, 31 May 2010 16:32:13 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C02D7D1.70400@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 31 May 2010 16:29:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-31 16:32:05, Serialize complete at 2010-05-31 16:32:05 Content-Type: multipart/alternative; boundary="=_alternative 002ED5FB48257734_=" X-MAIL: mse2.zte.com.cn o4V8VWll054430 Cc: "Christer.Holmberg@ericsson.com" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 08:43:16 -0000 This is a multipart message in MIME format. --=_alternative 002ED5FB48257734_= Content-Type: text/plain; charset="US-ASCII" > I *think* that considerations of *glare* occur when there is something > to be *negotiated* and either side may initiate the negotiation. The > negotiated piece of state that has been considered to date for glare is > the pair of SDP bodies that describe the media sessions. Your classification: "O/A glare case" and "Session Timer glare case" are subset of "negotiated glare case"; "Target-refresh ambiguous misorder" and "Updating PAI" are subset of "Declaring ambiguous misorder"; "negotiated glare case" and "Declaring ambiguous misorder" are subset of "ambiguous case". I once had a classification as "glare case" = "ambiguous case". But if we choose the "Patching way"(see below), I guess my classification is enough. If we want the "Refashion way", your more refined classification might be needed. > > As noted elsewhere in this thread, another piece state that is > *negotiated* is session-timer. As a result, there could be a glare > situation around that. The determination of whether glare has occurred > ought to be independent for each kind of negotiated state. So one > determination for SDP, another for session-timer. But there is only one > mechanism for signaling the glare in either case, the 491 response code. > So it would be used if *either* sdp-glare or session-timer-glare occurred. > > Target-refresh is somewhat different, because it isn't *negotiated* - it > is simply *declared* independently in each direction. So I don't think > it really ought to be considered a glare situation. > > Another in this category is sending an updated PAI, or changing From. > This to is a declaration rather than a negotiation, so that glare > shouldn't apply. > > In both of those cases, there remains an ordering issue, and perhaps the > answer is to forbid behavior that can result in ambiguity. But I fear >that cure is worse than the disease, so I'm inclined to seek a better cure. I think there are two different methodology for this issue: 1. Patching way: Saving current right case as it is, and cure ambiguous case without any breach for current right case(or making the breach as little as possible). I think the way defined in the draft belongs to "Patching way". 2. Refashion way: Based on the refined classification of "ambiguous case", seek solution and redefine rules on each classification's semantics. This way might forbid some *current right case*. Technically, I think "Refashion way" is better. But considering there's would be a serious interworking issue behind the "Refashion way"(there would be a quit long period for most vendors adopting this draft), I finally prefer the "Patching way" for nowadays. Personally, I prefer this draft has relative narrow aspect, and with tiny impact on current right working things. If someday, we have a 3261bis plan, I would prefer the "Refashion way" more. > > I'm especially concerned about that in the case of target refresh. If > the sender has lost its old address, then we are on the brink of losing > the call entirely. Saving the call is more important than whether we > have the proper o/a state - that can be fixed after the new target > address is established. I admire this point. > Also, target refresh cases are typically rare. > Two successive ones in close succession in the same direction should be > rare^2. (A target refresh of both ends in quick succession could be more > likely - for instance if the same event causes both to lose their > address. It seems unlikely that this will be a recoverable event.) > > So, I think we ought not be forbidding target refresh just because of > other state. Ambiguity about which is the old target and which is the > new one can be measured by which is a change - assuming there aren't two > changes in quick succession. I think Gao has also recommended this. Yes. And I think Gonzalo's current text in the draft covered this, technically. While some words level enhancement might needed for enhancing it's understandability. Thanks, Gao -------------------------------------------------------- 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 002ED5FB48257734_= Content-Type: text/html; charset="US-ASCII"



> I *think* that considerations of *glare* occur when there is something
> to be *negotiated* and either side may initiate the negotiation. The
> negotiated piece of state that has been considered to date for glare is
> the pair of SDP bodies that describe the media sessions.

Your classification:

"O/A glare case" and "Session Timer glare case" are subset of "negotiated glare case";

"Target-refresh ambiguous misorder" and "Updating PAI" are subset of "Declaring ambiguous misorder";

"negotiated glare case" and "Declaring ambiguous misorder" are subset of "ambiguous case".

I once had a classification as "glare case" = "ambiguous case". But if we choose the "Patching way"(see below), I guess my classification is enough. If we want the "Refashion way", your more refined classification might be needed.

>
> As noted elsewhere in this thread, another piece state that is
> *negotiated* is session-timer. As a result, there could be a glare
> situation around that. The determination of whether glare has occurred
> ought to be independent for each kind of negotiated state. So one
> determination for SDP, another for session-timer. But there is only one
> mechanism for signaling the glare in either case, the 491 response code.
> So it would be used if *either* sdp-glare or session-timer-glare occurred.
>
> Target-refresh is somewhat different, because it isn't *negotiated* - it
> is simply *declared* independently in each direction. So I don't think
> it really ought to be considered a glare situation.
>
> Another in this category is sending an updated PAI, or changing From.
> This to is a declaration rather than a negotiation, so that glare
> shouldn't apply.
>
> In both of those cases, there remains an ordering issue, and perhaps the
> answer is to forbid behavior that can result in ambiguity. But I fear
>that cure is worse than the disease, so I'm inclined to seek a better cure.

I think there are two different methodology for this issue:
1. Patching way: Saving current right case as it is, and cure ambiguous case without any breach for current right case(or making the breach as little as possible). I think the way defined in the draft belongs to "Patching way".

2. Refashion way: Based on the refined classification of "ambiguous case", seek solution and redefine rules on each classification's semantics. This way might forbid some *current right case*.

Technically, I think "Refashion way" is better. But considering there's would be a serious interworking issue behind the "Refashion way"(there would be a quit long period for most vendors adopting this draft), I finally prefer the "Patching way" for nowadays.

Personally, I prefer this draft has relative narrow aspect, and with tiny impact on current right working things. If someday, we have a 3261bis plan, I would prefer the "Refashion way" more.

>
> I'm especially concerned about that in the case of target refresh. If
> the sender has lost its old address, then we are on the brink of losing
> the call entirely. Saving the call is more important than whether we
> have the proper o/a state - that can be fixed after the new target
> address is established.

I admire this point.

> Also, target refresh cases are typically rare.
> Two successive ones in close succession in the same direction should be
> rare^2. (A target refresh of both ends in quick succession could be more
> likely - for instance if the same event causes both to lose their
> address. It seems unlikely that this will be a recoverable event.)
>
> So, I think we ought not be forbidding target refresh just because of
> other state. Ambiguity about which is the old target and which is the
> new one can be measured by which is a change - assuming there aren't two
> changes in quick succession. I think Gao has also recommended this.

Yes. And I think Gonzalo's current text in the draft covered this, technically.

While some words level enhancement might needed for enhancing it's understandability.

Thanks,

Gao 

--------------------------------------------------------
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 002ED5FB48257734_=-- From christer.holmberg@ericsson.com Mon May 31 03:06:27 2010 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 F193D3A69D6 for ; Mon, 31 May 2010 03:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=1.597, 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 YsPDFaa02lpU for ; Mon, 31 May 2010 03:06:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D9A063A69CB for ; Mon, 31 May 2010 03:06:25 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-9a-4c038a1403df Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.12.29106.41A830C4; Mon, 31 May 2010 12:06:12 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 31 May 2010 12:06:12 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Mon, 31 May 2010 12:06:11 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-04 Thread-Index: AcsAqOVeEaTYZ9W3SgCaA5UvZHO4HA== 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_FF84A09F50A6DC48ACB6714F4666CC7465C6202131ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-04 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, 31 May 2010 10:06:27 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC7465C6202131ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the discussions and comments, I have submitted a new version of th= e keep draft now. There are currently no open issues, and in my opinion the draft is ready fo= r WGLC. Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC7465C6202131ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on the discussions and comments, I have submitt= ed a new version of the keep draft now.
 
There are currently no open issues, and in my opinion= the draft is ready for WGLC.
 
Regards,
 
Christer
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC7465C6202131ESESSCMS0354e_-- From christer.holmberg@ericsson.com Mon May 31 03:11:53 2010 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 C2CF23A67C2 for ; Mon, 31 May 2010 03:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-2.865, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 Y7fznpZ5sS74 for ; Mon, 31 May 2010 03:11:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D4F3A3A6A00 for ; Mon, 31 May 2010 03:11:51 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-cc-4c038b5b9d78 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C5.AB.06817.B5B830C4; Mon, 31 May 2010 12:11:39 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 31 May 2010 12:11:38 +0200 From: Christer Holmberg To: Paul Kyzivat , "gao.yang2@zte.com.cn" Date: Mon, 31 May 2010 12:11:38 +0200 Thread-Topic: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer Thread-Index: AcsAP+a5jHgKpNSpRpSE/w1IwI2GoAAaTZcQ Message-ID: References: <4C02D9E0.5060306@cisco.com> In-Reply-To: <4C02D9E0.5060306@cisco.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , Harbhanu Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer 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, 31 May 2010 10:11:54 -0000 DQpIaSwgDQoNCj5JIGFncmVlIHRoYXQgdGhlcmUgYXJlIGlzc3VlcyB3aXRoIHNlc3Npb24tdGlt ZXIuDQo+IA0KPk5vcm1hbGx5IHNlc3Npb24tdGltZXIgaXMgc2ltcGxlLCBiZWNhdXNlIGl0IGlz IG5lZ290aWF0ZWQgDQo+YW5ldyB3aXRoIGVhY2ggZXhjaGFuZ2UuIFRoYXQgd29ya3MgcmVhc29u YWJseSB3ZWxsIGZvciANCj5yZUlOVklURSBhbmQgZm9yIFVQREFURSBvdXRzaWRlIG9mIGFuIGlu dml0ZSB0cmFuc2FjdGlvbi4gSXRzIA0KPmEgbWVzcyBpZiBhbiBVUERBVEUgd2l0aGluIGEgKHJl KUlOVklURSB0cmFuc2FjdGlvbiANCj5uZWdvdGlhdGVzIFMtVC4gSSB0aGluayB0aGF0IG5lZWRz IHRvIGJlIGZvcmJpZGRlbiwgd2hpY2ggDQo+d2lsbCBiZSBhIHJldmlzaW9uIHRvIDQwMjguDQoN ClRoYXQgY291bGQgYmUgYWRkZWQgdG8gbXkgIk5FVyBERUFMIiBsaXN0IG9mIHRoaW5ncyB3aGlj aCBzaG91bGRuJ3QgYmUgZG9uZSB3aXRoaW4gYSByZS1JTlZJVEUgOikNCg0KIA0KPihBIHJlSU5W SVRFIHNob3VsZCBub3QgdGFrZSBzbyBsb25nIHRoYXQgYSBzZXNzaW9uLXRpbWVyIHdpbGwgDQo+ ZXhwaXJlIGJlZm9yZSBpdCBpcyBjb21wbGV0ZS4gUGVyaGFwcyBpdCBzaG91bGQgYmUgc3BlY2lm aWVkIA0KPnRoYXQgKmlmKiBhIHNlc3Npb24tdGltZXIgZG9lcyBleHBpcmUgd2hpbGUgYSByZUlO VklURSBpcyBpbiANCj5wcm9ncmVzcywgdGhhdCBleHBpcmF0aW9uIGlzIGlnbm9yZWQuKQ0KDQpJ IGRvbid0IHRoaW5rIG9uZSBzaG91bGQgdHJ5IHRvIGRvIHRvbyBtYW55IHRoaW5ncyB3aXRoIGEg c2luZ2xlIHJlLUlOVklURSAob3IgVVBEQVRFKSBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCklmIHlv dSBhcmUgZ29pbmcgdG8gcGVyZm9ybSBhIHJlLUlOVklURSwgd2hpY2ggbWF5IHRha2Ugc29tZSB0 aW1lIHRvIGZpbmlzaCwgZG8geW91IFMtVCByZWZyZXNoICpiZWZvcmUqIHRoYXQsIGluIGEgc2Vw YXJhdGUgdHJhbnNhY3Rpb24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KDQo+ IGdhby55YW5nMkB6dGUuY29tLmNuIHdyb3RlOg0KPiA+IA0KPiA+IEhpLA0KPiA+IA0KPiA+IE5v dCBsaWtlIE8vQSB1c2FnZSBhbmQgdGFyZ2V0IHJlZnJlc2ggdXNhZ2UsIHRoZXJlJ3Mgbm8gZXhw bGljaXQgDQo+ID4gZGVmaW5pdGlvbiBvZiBhbGxvd2luZyBzdWJzZXF1ZW50IHNlc3Npb24gcmVm cmVzaCByZXF1ZXN0IA0KPiBpbiBlbWJlZGRlZCANCj4gPiByZXF1ZXN0cyhzdWNoIGFzIFVQREFU RSBkdXJpbmcgcGVuZGluZyBSZS1JTlZJVEUpLiBTbywgSSANCj4gdGhpbmsgaXQgaXMgDQo+ID4g bm90IHJlY29tbWVuZGVkIHRvIHNlbmRpbmcgVVBEQVRFIGFzIHN1YnNlcXVlbnQgc2Vzc2lvbiBy ZWZyZXNoIA0KPiA+IHJlcXVlc3QgaW4gcGVuZGluZyBJTlZJVEUvUmUtSU5WSVRFLg0KPiA+IA0K PiA+IEknZCBsaWtlIHRvIHRhbGsgbW9yZSBhYm91dCBzZXNzaW9uIHRpbWVyLiBJZiBwZW9wbGUg d2FudCB0byBkbyB0aGUgDQo+ID4gc2VtYW50aWNzIGV4dGVuc2lvbiBmb3Igc2Vzc2lvbiB0aW1l cidzIHRvIGFsbG93IGVtYmVkZGVkIA0KPiA+IHJlcXVlc3RzKHN1Y2ggYXMgVVBEQVRFIGR1cmlu ZyBwZW5kaW5nIFJlLUlOVklURSksIHRoZXJlJ3Mgb25lIA0KPiA+IHN1Z2dlc3Rpb24gd2F5KElO Rk9STUFUSVZFIGF0IGFsbCk6DQo+ID4gDQo+ID4gRG8gaXQgbGlrZSB0YXJnZXQgcmVmcmVzaCwg dGhlbiB0aGUgMnh4IG9mIA0KPiBJTlZJVEUvUmUtSU5WSVRFJ3MgU0UgdmFsdWUgDQo+ID4gc2hv dWxkIGJlIGFzIHRoZSBTRSB2YWx1ZSBpbiB0aGUgbGFzdCBlbWJlZGRlZCBzdWJzZXF1ZW50IHNl c3Npb24gDQo+ID4gcmVmcmVzaCByZXF1ZXN0J3MgMnh4Lg0KPiA+IA0KPiA+IFRoZW4sIHRoZSBn bGFyZSBoYW5kbGluZyBmb3Igc3VjaCB1c2FnZSB3b3VsZCBiZSB0aGUgc2FtZSBhcyB0aGUgDQo+ ID4gVGFyZ2V0IFJlZnJlc2ggcGFydCBpbiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUuDQo+ ID4gDQo+ID4gVGhhbmtzLA0KPiA+IA0KPiA+IEdhbw0KPiA+IA0KPiA+ID09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo+ID4gWmlwICAgIDogMjEwMDEyDQo+ID4gVGVsICAgIDog ODcyMTENCj4gPiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KPiA+IGVfbWFpbCA6IGdhby55 YW5nMkB6dGUuY29tLmNuDQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cj4gPiANCj4gPiANCj4gPiAqSGFyYmhhbnUgPGhhcmJoYW51QGh1YXdlaS5jb20+Kg0KPiA+ILei vP7IyzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KPiA+IA0KPiA+IDIwMTAtMDUtMjQgMTM6 NDANCj4gPiANCj4gPiAJDQo+ID4gytW8/sjLDQo+ID4gCXNpcGNvcmVAaWV0Zi5vcmcNCj4gPiCz rcvNDQo+ID4gCQ0KPiA+INb3zOINCj4gPiAJW3NpcGNvcmVdIFJFZy4gZHJhZnQtaWV0Zi1zaXBj b3JlLXJlaW52aXRlLTA0DQo+ID4gDQo+ID4gDQo+ID4gCQ0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ IA0KPiA+IA0KPiA+ICANCj4gPiAxLiBVRTEgLS0tIElOVklURSBTRS0xODAwIKikIFVFMg0KPiA+ IDIuIFVFMSA8LS0tIDE4MyAtLS0tLS0tLS0tLS0tLS0tLS0gVUUyDQo+ID4gIA0KPiA+IDMuIFVF MSAtLS0gVVBEQVRFIFNFLTYwMCCopCBVRTINCj4gPiA0LiBVRTEgPC0tLSAyMDAgVVBEQVRFIC1T RTYwMCAtLSBVRTINCj4gPiAgDQo+ID4gNS4gVUUxIDwtLS0gMjAwIElOVklURSBTRS0xODAwIC0t IFVFMg0KPiA+ICANCj4gPiBQbGVhc2UgcmVmZXIgdGhlIHNjZW5hcmlvIGFib3ZlIGZvciBoYW5k bGluZyBvZiANCj4gU2Vzc2lvbi1UaW1lciwgKDQwMjgpLg0KPiA+IEFzIHBlciB0aGUgRHJhZnQt aWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0IHNlY3Rpb24gNC41Og0KPiA+IKGwICBXaGVuIGNoZWNr aW5nIGZvciBnbGFyZSBzaXR1YXRpb25zLCBVQXMgTVVTVCB0cmVhdCBldmVyeSBVUERBVEUNCj4g PiAgICByZXF1ZXN0IGFzIGlmIGl0IGNvbnRhaW5lZCBhbiBvZmZlci4gIEFkZGl0aW9uYWxseSwg VUFzIA0KPiBNVVNUIHRyZWF0DQo+ID4gICAgdGhlIGV4Y2hhbmdlIG9mIGEgMnh4IHJlc3BvbnNl IHRvIGFuIElOVklURSByZXF1ZXN0IGFuZCBpdHMNCj4gPiAgICBjb3JyZXNwb25kaW5nIEFDSyBy ZXF1ZXN0IGFzIGFuIG9mZmVyL2Fuc3dlciBleGNoYW5nZS4gIA0KPiBDb25zZXF1ZW50bHksDQo+ ID4gICAgdGhlIHJ1bGVzIHJlZ2FyZGluZyBnbGFyZSBzaXR1YXRpb25zIGFwcGxpY2FibGUgdG8g b2ZmZXIvYW5zd2VyDQo+ID4gICAgZXhjaGFuZ2VzIGFyZSBhbHNvIGFwcGxpY2FibGUgdG8gdGhv c2UgZXhjaGFuZ2VzLqGxDQo+ID4gIA0KPiA+IEhlcmUsIHdlIGFyZSBub3QgYWJsZSB0byBjb25j bHVkZSB3aGV0aGVyIGJvdGggVUFzIHNob3VsZCANCj4gcnVuIHNlc3Npb24gDQo+ID4gdGltZXIg d2l0aCAxODAwIG9yIDYwMCwgb3Igb3RoZXJ3aXNlIHdoZXRoZXIgdGhlIFVQREFURSBzaG91bGQg YmUgDQo+ID4gcmVqZWN0ZWQuDQo+ID4gIA0KPiA+IEFzIHBlciBteSB1bmRlcnN0YW5kaW5nIHRo aXMgZHJhZnQgZG9lc26hr3QgKipleHBsaWNpdGx5KiogbWVudGlvbiANCj4gPiBhbnl0aGluZyBh Ym91dCB0aGUgU2Vzc2lvbi1UaW1lciwgd2hlcmVpbiB0aGVyZSBpcyBhbiBlYXJseSANCj4gbmVn b3RpYXRpb24uDQo+ID4gU2luY2UgNDAyOCBhbHNvIGRvZXNuoa90DQo+ID4gaGF2ZSBhbnkgcmVm ZXJlbmNlIGZvciBlYXJseSBuZWdvdGlhdGlvbiwgc28gd2Ugc3VnZ2VzdCB0aGF0IGl0IGNhbiAN Cj4gPiBiZXR0ZXIgYmUgaW5jb3Jwb3JhdGVkIGluIHRoZSBhYm92ZSBtZW50aW9uZWQgDQo+ID4g ZHJhZnRbaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTA0XS4NCj4gPiAgDQo+ID4gUGxlYXNlIHNoYXJl IHlvdXIgb3BpbmlvbiBhbmQgZG8gZ3VpZGUgdXMgaW5jYXNlIGFueSBvZiB0aGUgDQo+IGV4aXN0 aW5nIA0KPiA+IFJGQy9hY3RpdmUtZHJhZnQgYWxyZWFkeSBjYXB0dXJlcyB0aGlzLg0KPiA+ICAN Cj4gPiBUaGFua3MhDQo+ID4gIA0KPiA+IFJlZ2FyZHMsDQo+ID4gSGFyYmhhbnUNCj4gPiAgDQo+ ID4gDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCj4gPiAqKioqKioqKioqKioqKioqKiBUaGlzIGUtbWFpbCBh bmQgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgDQo+ID4gaW5mb3JtYXRpb24gZnJv bSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgDQo+ID4g ZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiANCj4gPiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0 IG5vdCBsaW1pdGVkIHRvLCANCj4gdG90YWwgb3IgDQo+ID4gcGFydGlhbCBkaXNjbG9zdXJlLCBy ZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IA0KPiBwZXJzb25zIG90aGVyIA0KPiA+ IHRoYW4gdGhlIGludGVuZGVkDQo+ID4gcmVjaXBpZW50J3MpIGlzIHByb2hpYml0ZWQuIElmIHlv dSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCANCj4gPiBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIA0KPiBkZWxldGUgaXQhDQo+ ID4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g c2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPiBzaXBjb3JlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID4gDQo+ID4gDQo+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g PiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIA0KPiBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIA0KPiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgDQo+IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2Vj cmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgDQo+IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBv ZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KPiA+IFRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSANCj4gY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIA0KPiBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgDQo+IHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCj4gdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiANCj4g dGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiA+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSANCj4gQW50aS1TcGFtIHN5c3RlbS4NCj4gPiAN Cj4gPiANCj4gPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4gDQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXBjb3JlIG1haWxp bmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4g From root@core3.amsl.com Mon May 31 03:15:03 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 72E313A6A2C; Mon, 31 May 2010 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100531101502.72E313A6A2C@core3.amsl.com> Date: Mon, 31 May 2010 03:15:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-04.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, 31 May 2010 10:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-04.txt Pages : 15 Date : 2010-05-31 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-keep-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-31030421.I-D@ietf.org> --NextPart-- From shinji.okumura@softfront.jp Mon May 31 03:17:09 2010 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 67B9628C0E9 for ; Mon, 31 May 2010 03:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.94 X-Spam-Level: X-Spam-Status: No, score=-94.94 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 LXYGVePyNjGL for ; Mon, 31 May 2010 03:17:03 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 25E183A67C2 for ; Mon, 31 May 2010 03:16:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id A15D242800E; Mon, 31 May 2010 19:16:31 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHZ9iou3qYPI; Mon, 31 May 2010 19:16:29 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 14D1342800D; Mon, 31 May 2010 19:16:28 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 31 May 2010 19:16:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C02D7D1.70400@cisco.com> References: <4C02D7D1.70400@cisco.com> Message-Id: <31CB00AA55A10Fshinji.okumura@softfront.jp> Cc: gao.yang2@zte.com.cn, "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 10:17:09 -0000 Paul, Paul Kyzivat Sun, 30 May 2010 17:25:37 -0400 >Sorry to be so slow in responding. I got behind, and had to wait till I >had time to read through all that has been said before I could make any >sort of meaningful response. > >As it is, there is so much that I am responding after reading most of >the -reinvite- traffic, without first checking if some of the mail with >different subject is also relevant. > >gao.yang2@zte.com.cn wrote: >> >> Rules for "When checking for glare situations" in the draft text means >> the UAs's reasoning and handling while the UAs are in a glare >> situations, which is ambiguous. >> >> It does not means UAs reasoning and handling for every use case to >> figure out whether this case is a glare case. >> >> This is my understanding. And I'd like other co-authors and important >> reviewer to comment on this point. > >In light of all the discussion this has generated, I think -reinvite- is >not sufficiently clear on what it means. I think we need to be looking >for a way to revise it to be more clear, regardless of its current >post-WGLC status. (Note that -offeranswer- is also in post-WGLC status, >and we are debating changes to it.) > >We *REALLY* need to hear from Gonzalo for his opinion on this! > >My opinion at this point is that stating that "UPDATEs without SDP >should be treated as if they contained an offer" is an insufficient >technique for stating the required behavior - that it needs to be stated >more explicitly, even though that will take more words. > >I *think* that considerations of *glare* occur when there is something >to be *negotiated* and either side may initiate the negotiation. The >negotiated piece of state that has been considered to date for glare is >the pair of SDP bodies that describe the media sessions. > >As noted elsewhere in this thread, another piece state that is >*negotiated* is session-timer. As a result, there could be a glare >situation around that. The determination of whether glare has occurred >ought to be independent for each kind of negotiated state. So one >determination for SDP, another for session-timer. But there is only one >mechanism for signaling the glare in either case, the 491 response code. >So it would be used if *either* sdp-glare or session-timer-glare occurred. > >Target-refresh is somewhat different, because it isn't *negotiated* - it >is simply *declared* independently in each direction. So I don't think >it really ought to be considered a glare situation. Exactly! I've thought the differences between offer-answer and target- refresh as below, 1. When a UAS sends 4xx to reINVITE, UAs rollback offer-answer, but don't rollback remote target. 2. All reliable response to a reINVITE refresh a remote target within one INVITE transaction. 3. PRACK is used in offer-answer, but is not a target refresh request. 4. A target-refresh is acknowledged by all SIP request(e.g. MESSAGE, INFO, etc.). An offer-answer and a target-refresh have a different concept each other. It seems to be unreasonable that those two rules are applied to both situations at the same time. Regards, Shinji >Another in this category is sending an updated PAI, or changing From. >This to is a declaration rather than a negotiation, so that glare >shouldn't apply. > >In both of those cases, there remains an ordering issue, and perhaps the >answer is to forbid behavior that can result in ambiguity. But I fear >that cure is worse than the disease, so I'm inclined to seek a better cure. > >I'm especially concerned about that in the case of target refresh. If >the sender has lost its old address, then we are on the brink of losing >the call entirely. Saving the call is more important than whether we >have the proper o/a state - that can be fixed after the new target >address is established. Also, target refresh cases are typically rare. >Two successive ones in close succession in the same direction should be >rare^2. (A target refresh of both ends in quick succession could be more >likely - for instance if the same event causes both to lose their >address. It seems unlikely that this will be a recoverable event.) > >So, I think we ought not be forbidding target refresh just because of >other state. Ambiguity about which is the old target and which is the >new one can be measured by which is a change - assuming there aren't two >changes in quick succession. I think Gao has also recommended this. > > Thanks, > Paul > >> > > > Look at RFC3311 (especially section 5.2) concerning how to behave >> > > > when UPDATE offer is received while there is an outstanding offer. >> > > >> > > I know this part of 3311. I don't know the meaning of why >> > > you highlight this part. >> > > >> > > Do you think text of our draft has conflict with this part of 3311 here? >> > > >> > > I don't think so, as our text only for ambiguous cases. >> > >> > I'm indicating that the RFC3311 mandates the returning 491 or 500 >> > (depending upon direction). >> > >> > You are indicating that the RFC3311 text doesn't apply even though >> > draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate they >> > would apply. RFC3311 section 5.2 includes glare checking as part of >> > normal UPDATE processing. >> > >> > The drafts normative text causing the issue: "When checking for >> > glare situations, UAs MUST treat every UPDATE request as if it >> > contained an offer." >> > >> > You keep interpreting/indicating that the normative text does not >> > apply to all UPDATEs. Please provide the normative text which >> > indicates your interpretation. >> > >> > Thanks, >> > Brett From christer.holmberg@ericsson.com Mon May 31 03:24:35 2010 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 1BE743A67C2 for ; Mon, 31 May 2010 03:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.957 X-Spam-Level: X-Spam-Status: No, score=-4.957 tagged_above=-999 required=5 tests=[AWL=1.642, 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 pt67uTzFpdBO for ; Mon, 31 May 2010 03:24:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 813443A6A17 for ; Mon, 31 May 2010 03:24:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-59-4c038e54798d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 09.64.29106.45E830C4; Mon, 31 May 2010 12:24:21 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 31 May 2010 12:24:20 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 31 May 2010 12:24:20 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 31 May 2010 12:24:19 +0200 Thread-Topic: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] Thread-Index: AcsART5ObnGj4NYTTcimEykqbM17MQAZJu1g Message-ID: References: <4C02E2DF.5050909@cisco.com> In-Reply-To: <4C02E2DF.5050909@cisco.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-Brightmail-Tracker: AAAAAA== Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Subject: Re: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP] 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, 31 May 2010 10:24:35 -0000 Hi,=20 >>Below are some questions/ideas on how I think we could=20 >>solve most issues. Some of the stuff shall be seen more as=20 >>brain storming than actual proposal at this point. >>=20 >>I am fully aware that some of the ideas for sure may limit=20 >>what is said in RFCs etc, so you don't need to tell me about that. >>=20 >>=20 >>=20 >>=20 >>IDEA #1: Offer/answer: Usage of SDP o=3D version parameter >>=20 >>I know this has been discussed at some point, but what is=20 >>the reason we can't use the SDP o=3D version parameter to=20 >>determine in which order the UAS has sent SDPs? >>=20 >>I believe it would solve offer/answer glare situations=20 >>where the UAC does not known in which order the UAS has sent SDPs. >>=20 >>That should not be controversial, and does not break any RFC etc. >=20 >Shinji refuted this one. Yes, but I think I didn't agree with what he said :) So, I still think it would work. =20 >>IDEA #2: Target update: Only outside re-INVITEs >>=20 >>Let's forbid target updates "inside" re-INVITEs. I really=20 >>doubt there is a need for those while the UAs are doing=20 >>something else with the re-INVITE. >>=20 >>That at least solves the glare situation where the remote=20 >>target may be updated in a re-INVITE response and an UPDATE response. >=20 >For the case of a UA that loses its IP address and must=20 >switch to another, it may be essential to send the UPDATE=20 >immediately. And it won't be getting the response to the=20 >reINVITE in that case, so it can't wait till it does. Will it EVER get the response to the re-INVITE? As far as I know a target u= pdate doesn't change the routing of responses. The re-INVITE will most like= ly time-out. I am not sure the re-INVITE draft talks about re-INVITE timeou= ts, but I assume it shall be regarded as a failure resposne? So, eventhough I agree it could happen, I REALLY doubt you are going to be = able to handle it inside a re-INVITE. As I've said before, in most cases it= will also require a new registration. =20 >In general you should almost never ignore a target refresh,=20 >unless there is something grievous such as an authentication failure. >=20 >>IDEA #3: UPDATE: Always use re-INVITE glare rules >>=20 >>Let's not allow more than one outstanding UPDATE. Ie if a=20 >>UA has sent an UPDATE (with or without SDP), and receives=20 >>another UPDATE request before the answer, it rejects it (same=20 >>rule as for re-INVITE). >>=20 >>=20 >>That would at least solve the problem where a UA sends an=20 >>UPDATE, receives a 200 OK and a UPDATE request, both with=20 >>different target information. >=20 >I'm not convinced this solves anything. And if it prevented=20 >an essential target refresh then it would be a bad thing. The target refresh can still be done in the UPDATE 200 OK. >As I stated elsewhere, I think glare should be detected=20 >individually for each piece of state being negotiated. Then=20 >the request can be rejected if some form of glare has been detected. But, if you receive a request first, and a response after, it may be too la= te to reject the request. >Target refresh isn't a glare situation, so would never fall into that. I think the case where you receive UPDATE 200 with target A and UPDATE requ= est with target B is. In which order were they sent from the remote end? Wh= ich target is valid? I just think that, by making some restrictions, we would have a much bigger= chance of reaching interoperability, instead of trying to specify complica= ted rules, which are going to require even more complicated code to impleme= nt... Regards, Christer > > Ok, let the tomatoes fly... > >=20 > > ...and let me know if there are any issues which the ideas above do=20 > > NOT solve. I have some more ideas, but I am not sure they=20 > are needed=20 > > so I'll them to myself for now :) > >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > = From gao.yang2@zte.com.cn Mon May 31 03:52:25 2010 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 7D30A3A690E for ; Mon, 31 May 2010 03:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.875 X-Spam-Level: X-Spam-Status: No, score=-99.875 tagged_above=-999 required=5 tests=[AWL=1.963, 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 S4qAZxHJf5Bn for ; Mon, 31 May 2010 03:52: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 D721B3A681D for ; Mon, 31 May 2010 03:52:23 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 31 May 2010 18:46:20 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.4821350471; Mon, 31 May 2010 18:52:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4VAq422048685; Mon, 31 May 2010 18:52:04 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 31 May 2010 18:48:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-31 18:51:53, Serialize complete at 2010-05-31 18:51:53 Content-Type: multipart/alternative; boundary="=_alternative 003BA28B48257734_=" X-MAIL: mse2.zte.com.cn o4VAq422048685 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 10:52:25 -0000 This is a multipart message in MIME format. --=_alternative 003BA28B48257734_= Content-Type: text/plain; charset="US-ASCII" your chart: >> >> A B >> | | >> s0|re-INV (offer1) |s0 >> |------------------------------>| >> | 18x-rel(answer1)| >> |<------------------------------| >> s1| non-2xx|s1 >> |<------------------------------|<-+ >> s0|ACK |s0| >> |-----------> | | >> |UPD(offer0) | | >> |==============================>|* | reject UPDATE >> | 491(UPD)| | >> |<==============================| | >> | ACK | | >> | ---------->|<-+ >> | | >> Figure 2 If the UPDATE is in scope of ReINVITE by UAS's view, and the modification(*negotiated*) in this UPDATE should not be committed. If the UPDATE is out scope of ReINVITE by UAS's view, the modification(*negotiated*) in this UPDATE can be committed. As there is a ambiguous for UAS, so UAS should reject it. > In my recognition, Gao and I are not agreeing. > > I have two comments regarding Figure 2. > > 1. Between a non-2xx to a reINVITE and an ACK, the UAS may > accept a receiving UPDATE. > > This draft seems to forbid the UPDATE. > > 2. In this case, the common view of both UAs has already > been synchronized. IMO if an UPDATE has been not used in > offer-answer exchange before 4xx, then the original > rollback process may work well. > That is, a following UPDATE is unnecessary in this case. And if the UPDATE is in scope of ReINVITE, the state could not be treated as synchronized. Thanks, Gao -------------------------------------------------------- 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 003BA28B48257734_= Content-Type: text/html; charset="US-ASCII"
your chart:

>>
>>     A                               B
>>     |                               |
>>   s0|re-INV (offer1)                |s0
>>     |------------------------------>|
>>     |               18x-rel(answer1)|
>>     |<------------------------------|
>>   s1|                        non-2xx|s1
>>     |<------------------------------|<-+
>>   s0|ACK                            |s0|
>>     |----------->                   |  |
>>     |UPD(offer0)                    |  |
>>     |==============================>|* | reject UPDATE
>>     |                       491(UPD)|  |
>>     |<==============================|  |
>>     |                    ACK        |  |
>>     |                    ---------->|<-+
>>     |                               |
>>                 Figure 2



If the UPDATE is in scope of ReINVITE by UAS's view, and the modification(*negotiated*) in this UPDATE should not be committed.

If the UPDATE is out scope of ReINVITE by UAS's view, the modification(*negotiated*) in this UPDATE can be committed.

As there is a ambiguous for UAS, so UAS should reject it.


> In my recognition, Gao and I are not agreeing.
>
> I have two comments regarding Figure 2.
>
> 1. Between a non-2xx to a reINVITE and an ACK, the UAS may
>    accept a receiving UPDATE.
>
>    This draft seems to forbid the UPDATE.
>
> 2. In this case, the common view of both UAs has already
>    been synchronized. IMO if an UPDATE has been not used in
>    offer-answer exchange before 4xx, then the original
>    rollback process may work well.
>    That is, a following UPDATE is unnecessary in this case.

And if the UPDATE is in scope of ReINVITE, the state could not be treated as synchronized.

Thanks,

Gao 

--------------------------------------------------------
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 003BA28B48257734_=-- From gao.yang2@zte.com.cn Mon May 31 04:06:03 2010 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 278EB3A6A1F for ; Mon, 31 May 2010 04:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.37 X-Spam-Level: X-Spam-Status: No, score=-96.37 tagged_above=-999 required=5 tests=[AWL=-1.935, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 QWrqnoAlOXFH for ; Mon, 31 May 2010 04:06:01 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 65C1C3A6A33 for ; Mon, 31 May 2010 04:06:00 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580711727820181; Mon, 31 May 2010 19:00:06 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 32518.8280906739; Mon, 31 May 2010 19:00:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4VB3QJn059683; Mon, 31 May 2010 19:03:26 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 31 May 2010 19:00:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-31 19:03:15, Serialize complete at 2010-05-31 19:03:15 Content-Type: multipart/alternative; boundary="=_alternative 003CACF248257734_=" X-MAIL: mse2.zte.com.cn o4VB3QJn059683 Cc: "Christer.Holmberg@ericsson.com" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 11:06:03 -0000 This is a multipart message in MIME format. --=_alternative 003CACF248257734_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SXQgc2VhbXMgdGhlIHR3byBtZXRob2RvbG9neSBhcmUgYW50aXRoZXNlcy4NCg0KQnV0IEkgdGhp bmsgaXQgYWdhaW4sIGFuZCAqZmVlbCogdGhlIHR3byBtZXRob2RvbG9neSBtaWdodCBoYXZlIA0K aW50ZXJzZWN0aW9uLiBUaGF0IGlzLCB1c2luZyAiUmVmYXNoaW9uIHdheSIsIGJ1dCBzYXZlcyBj dXJyZW50IHJpZ2h0IGNhc2UgDQphcyBpdCBpcy4gVGhlbiwgdGhlIHR3byBtZXRob2RvbG9neSB3 b3VsZCBiZSBzYW1lIHRlY2huaWNhbGx5LCB3aGlsZSB1c2luZyANCmRpZmZlcmVudCByZXByZXNl bnRhdGlvbi4NCg0KSWYgd2UgY2FuIGRvIGl0IGxpa2UgdGhpcywgSSdkIGxpa2UgdG8gY2hhbmdl IG15IHByZWZlcmVuY2UgZnJvbSAiUGF0Y2hpbmcgDQp3YXkiIHRvICJSZWZhc2hpb24gd2F5Ii4N Cg0KQW5kIEkgbmVlZCBhIGxpdHRsZSB0aW1lIHRvIGRvIHRoZSBldmFsdWF0aW9uIGNhcmVmdWxs eS4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1 LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQotLS0tLSDXqreiyMsgR2FvWWFuZzE0MDE5Ny91c2VyL3p0 ZV9sdGQgyrG85CAyMDEwLTA1LTMxIDE4OjUxIC0tLS0tDQoNCkdhb1lhbmcxNDAxOTcvdXNlci96 dGVfbHRkINC009ogMjAxMC0wNS0zMSAxNjoyOToxMToNCg0KPiANCj4gDQo+IA0KPiA+IEkgKnRo aW5rKiB0aGF0IGNvbnNpZGVyYXRpb25zIG9mICpnbGFyZSogb2NjdXIgd2hlbiB0aGVyZSBpcyBz b21ldGhpbmcgDQoNCj4gPiB0byBiZSAqbmVnb3RpYXRlZCogYW5kIGVpdGhlciBzaWRlIG1heSBp bml0aWF0ZSB0aGUgbmVnb3RpYXRpb24uIFRoZSANCj4gPiBuZWdvdGlhdGVkIHBpZWNlIG9mIHN0 YXRlIHRoYXQgaGFzIGJlZW4gY29uc2lkZXJlZCB0byBkYXRlIGZvciBnbGFyZSANCmlzIA0KPiA+ IHRoZSBwYWlyIG9mIFNEUCBib2RpZXMgdGhhdCBkZXNjcmliZSB0aGUgbWVkaWEgc2Vzc2lvbnMu DQo+IA0KPiBZb3VyIGNsYXNzaWZpY2F0aW9uOiANCj4gDQo+ICJPL0EgZ2xhcmUgY2FzZSIgYW5k ICJTZXNzaW9uIFRpbWVyIGdsYXJlIGNhc2UiIGFyZSBzdWJzZXQgb2YgDQo+ICJuZWdvdGlhdGVk IGdsYXJlIGNhc2UiOw0KPiANCj4gIlRhcmdldC1yZWZyZXNoIGFtYmlndW91cyBtaXNvcmRlciIg YW5kICJVcGRhdGluZyBQQUkiIGFyZSBzdWJzZXQgb2YNCj4gIkRlY2xhcmluZyBhbWJpZ3VvdXMg bWlzb3JkZXIiOw0KPiANCj4gIm5lZ290aWF0ZWQgZ2xhcmUgY2FzZSIgYW5kICJEZWNsYXJpbmcg YW1iaWd1b3VzIG1pc29yZGVyIiBhcmUgDQo+IHN1YnNldCBvZiAiYW1iaWd1b3VzIGNhc2UiLg0K PiANCj4gSSBvbmNlIGhhZCBhIGNsYXNzaWZpY2F0aW9uIGFzICJnbGFyZSBjYXNlIiA9ICJhbWJp Z3VvdXMgY2FzZSIuIEJ1dCANCj4gaWYgd2UgY2hvb3NlIHRoZSAiUGF0Y2hpbmcgd2F5IihzZWUg YmVsb3cpLCBJIGd1ZXNzIG15IA0KPiBjbGFzc2lmaWNhdGlvbiBpcyBlbm91Z2guIElmIHdlIHdh bnQgdGhlICJSZWZhc2hpb24gd2F5IiwgeW91ciBtb3JlIA0KPiByZWZpbmVkIGNsYXNzaWZpY2F0 aW9uIG1pZ2h0IGJlIG5lZWRlZC4NCj4gDQo+ID4gDQo+ID4gQXMgbm90ZWQgZWxzZXdoZXJlIGlu IHRoaXMgdGhyZWFkLCBhbm90aGVyIHBpZWNlIHN0YXRlIHRoYXQgaXMgDQo+ID4gKm5lZ290aWF0 ZWQqIGlzIHNlc3Npb24tdGltZXIuIEFzIGEgcmVzdWx0LCB0aGVyZSBjb3VsZCBiZSBhIGdsYXJl IA0KPiA+IHNpdHVhdGlvbiBhcm91bmQgdGhhdC4gVGhlIGRldGVybWluYXRpb24gb2Ygd2hldGhl ciBnbGFyZSBoYXMgb2NjdXJyZWQgDQoNCj4gPiBvdWdodCB0byBiZSBpbmRlcGVuZGVudCBmb3Ig ZWFjaCBraW5kIG9mIG5lZ290aWF0ZWQgc3RhdGUuIFNvIG9uZSANCj4gPiBkZXRlcm1pbmF0aW9u IGZvciBTRFAsIGFub3RoZXIgZm9yIHNlc3Npb24tdGltZXIuIEJ1dCB0aGVyZSBpcyBvbmx5IA0K b25lIA0KPiA+IG1lY2hhbmlzbSBmb3Igc2lnbmFsaW5nIHRoZSBnbGFyZSBpbiBlaXRoZXIgY2Fz ZSwgdGhlIDQ5MSByZXNwb25zZSANCmNvZGUuIA0KPiA+IFNvIGl0IHdvdWxkIGJlIHVzZWQgaWYg KmVpdGhlciogc2RwLWdsYXJlIG9yIHNlc3Npb24tdGltZXItZ2xhcmUgDQpvY2N1cnJlZC4NCj4g PiANCj4gPiBUYXJnZXQtcmVmcmVzaCBpcyBzb21ld2hhdCBkaWZmZXJlbnQsIGJlY2F1c2UgaXQg aXNuJ3QgKm5lZ290aWF0ZWQqIC0gDQppdCANCj4gPiBpcyBzaW1wbHkgKmRlY2xhcmVkKiBpbmRl cGVuZGVudGx5IGluIGVhY2ggZGlyZWN0aW9uLiBTbyBJIGRvbid0IHRoaW5rIA0KDQo+ID4gaXQg cmVhbGx5IG91Z2h0IHRvIGJlIGNvbnNpZGVyZWQgYSBnbGFyZSBzaXR1YXRpb24uDQo+ID4gDQo+ ID4gQW5vdGhlciBpbiB0aGlzIGNhdGVnb3J5IGlzIHNlbmRpbmcgYW4gdXBkYXRlZCBQQUksIG9y IGNoYW5naW5nIEZyb20uIA0KPiA+IFRoaXMgdG8gaXMgYSBkZWNsYXJhdGlvbiByYXRoZXIgdGhh biBhIG5lZ290aWF0aW9uLCBzbyB0aGF0IGdsYXJlIA0KPiA+IHNob3VsZG4ndCBhcHBseS4NCj4g PiANCj4gPiBJbiBib3RoIG9mIHRob3NlIGNhc2VzLCB0aGVyZSByZW1haW5zIGFuIG9yZGVyaW5n IGlzc3VlLCBhbmQgcGVyaGFwcyANCnRoZSANCj4gPiBhbnN3ZXIgaXMgdG8gZm9yYmlkIGJlaGF2 aW9yIHRoYXQgY2FuIHJlc3VsdCBpbiBhbWJpZ3VpdHkuIEJ1dCBJIGZlYXIgDQo+ID50aGF0IGN1 cmUgaXMgd29yc2UgdGhhbiB0aGUgZGlzZWFzZSwgc28gSSdtIGluY2xpbmVkIHRvIHNlZWsgYSBi ZXR0ZXIgDQpjdXJlLg0KPiANCj4gSSB0aGluayB0aGVyZSBhcmUgdHdvIGRpZmZlcmVudCBtZXRo b2RvbG9neSBmb3IgdGhpcyBpc3N1ZToNCj4gMS4gUGF0Y2hpbmcgd2F5OiBTYXZpbmcgY3VycmVu dCByaWdodCBjYXNlIGFzIGl0IGlzLCBhbmQgY3VyZSANCj4gYW1iaWd1b3VzIGNhc2Ugd2l0aG91 dCBhbnkgYnJlYWNoIGZvciBjdXJyZW50IHJpZ2h0IGNhc2Uob3IgbWFraW5nIA0KPiB0aGUgYnJl YWNoIGFzIGxpdHRsZSBhcyBwb3NzaWJsZSkuIEkgdGhpbmsgdGhlIHdheSBkZWZpbmVkIGluIHRo ZSANCj4gZHJhZnQgYmVsb25ncyB0byAiUGF0Y2hpbmcgd2F5Ii4gDQo+IA0KPiAyLiBSZWZhc2hp b24gd2F5OiBCYXNlZCBvbiB0aGUgcmVmaW5lZCBjbGFzc2lmaWNhdGlvbiBvZiAiYW1iaWd1b3Vz IA0KPiBjYXNlIiwgc2VlayBzb2x1dGlvbiBhbmQgcmVkZWZpbmUgcnVsZXMgb24gZWFjaCBjbGFz c2lmaWNhdGlvbidzIA0KPiBzZW1hbnRpY3MuIFRoaXMgd2F5IG1pZ2h0IGZvcmJpZCBzb21lICpj dXJyZW50IHJpZ2h0IGNhc2UqLg0KPiANCj4gVGVjaG5pY2FsbHksIEkgdGhpbmsgIlJlZmFzaGlv biB3YXkiIGlzIGJldHRlci4gQnV0IGNvbnNpZGVyaW5nIA0KPiB0aGVyZSdzIHdvdWxkIGJlIGEg c2VyaW91cyBpbnRlcndvcmtpbmcgaXNzdWUgYmVoaW5kIHRoZSAiUmVmYXNoaW9uIA0KPiB3YXki KHRoZXJlIHdvdWxkIGJlIGEgcXVpdCBsb25nIHBlcmlvZCBmb3IgbW9zdCB2ZW5kb3JzIGFkb3B0 aW5nIA0KPiB0aGlzIGRyYWZ0KSwgSSBmaW5hbGx5IHByZWZlciB0aGUgIlBhdGNoaW5nIHdheSIg Zm9yIG5vd2FkYXlzLg0KPiANCj4gUGVyc29uYWxseSwgSSBwcmVmZXIgdGhpcyBkcmFmdCBoYXMg cmVsYXRpdmUgbmFycm93IGFzcGVjdCwgYW5kIHdpdGgNCj4gdGlueSBpbXBhY3Qgb24gY3VycmVu dCByaWdodCB3b3JraW5nIHRoaW5ncy4gSWYgc29tZWRheSwgd2UgaGF2ZSBhIA0KPiAzMjYxYmlz IHBsYW4sIEkgd291bGQgcHJlZmVyIHRoZSAiUmVmYXNoaW9uIHdheSIgbW9yZS4NCj4gDQo+ID4g DQo+ID4gSSdtIGVzcGVjaWFsbHkgY29uY2VybmVkIGFib3V0IHRoYXQgaW4gdGhlIGNhc2Ugb2Yg dGFyZ2V0IHJlZnJlc2guIElmIA0KPiA+IHRoZSBzZW5kZXIgaGFzIGxvc3QgaXRzIG9sZCBhZGRy ZXNzLCB0aGVuIHdlIGFyZSBvbiB0aGUgYnJpbmsgb2YgDQpsb3NpbmcgDQo+ID4gdGhlIGNhbGwg ZW50aXJlbHkuIFNhdmluZyB0aGUgY2FsbCBpcyBtb3JlIGltcG9ydGFudCB0aGFuIHdoZXRoZXIg d2UgDQo+ID4gaGF2ZSB0aGUgcHJvcGVyIG8vYSBzdGF0ZSAtIHRoYXQgY2FuIGJlIGZpeGVkIGFm dGVyIHRoZSBuZXcgdGFyZ2V0IA0KPiA+IGFkZHJlc3MgaXMgZXN0YWJsaXNoZWQuIA0KPiANCj4g SSBhZG1pcmUgdGhpcyBwb2ludC4NCj4gDQo+ID4gQWxzbywgdGFyZ2V0IHJlZnJlc2ggY2FzZXMg YXJlIHR5cGljYWxseSByYXJlLiANCj4gPiBUd28gc3VjY2Vzc2l2ZSBvbmVzIGluIGNsb3NlIHN1 Y2Nlc3Npb24gaW4gdGhlIHNhbWUgZGlyZWN0aW9uIHNob3VsZCANCmJlIA0KPiA+IHJhcmVeMi4g KEEgdGFyZ2V0IHJlZnJlc2ggb2YgYm90aCBlbmRzIGluIHF1aWNrIHN1Y2Nlc3Npb24gY291bGQg YmUgDQptb3JlIA0KPiA+IGxpa2VseSAtIGZvciBpbnN0YW5jZSBpZiB0aGUgc2FtZSBldmVudCBj YXVzZXMgYm90aCB0byBsb3NlIHRoZWlyIA0KPiA+IGFkZHJlc3MuIEl0IHNlZW1zIHVubGlrZWx5 IHRoYXQgdGhpcyB3aWxsIGJlIGEgcmVjb3ZlcmFibGUgZXZlbnQuKQ0KPiA+IA0KPiA+IFNvLCBJ IHRoaW5rIHdlIG91Z2h0IG5vdCBiZSBmb3JiaWRkaW5nIHRhcmdldCByZWZyZXNoIGp1c3QgYmVj YXVzZSBvZiANCj4gPiBvdGhlciBzdGF0ZS4gQW1iaWd1aXR5IGFib3V0IHdoaWNoIGlzIHRoZSBv bGQgdGFyZ2V0IGFuZCB3aGljaCBpcyB0aGUgDQo+ID4gbmV3IG9uZSBjYW4gYmUgbWVhc3VyZWQg Ynkgd2hpY2ggaXMgYSBjaGFuZ2UgLSBhc3N1bWluZyB0aGVyZSBhcmVuJ3QgDQp0d28gDQo+ID4g Y2hhbmdlcyBpbiBxdWljayBzdWNjZXNzaW9uLiBJIHRoaW5rIEdhbyBoYXMgYWxzbyByZWNvbW1l bmRlZCB0aGlzLg0KPiANCj4gWWVzLiBBbmQgSSB0aGluayBHb256YWxvJ3MgY3VycmVudCB0ZXh0 IGluIHRoZSBkcmFmdCBjb3ZlcmVkIHRoaXMsIA0KPiB0ZWNobmljYWxseS4gDQo+IA0KPiBXaGls ZSBzb21lIHdvcmRzIGxldmVsIGVuaGFuY2VtZW50IG1pZ2h0IG5lZWRlZCBmb3IgZW5oYW5jaW5n IGl0J3MgDQo+IHVuZGVyc3RhbmRhYmlsaXR5LiANCj4gDQo+IFRoYW5rcywNCj4gDQo+IEdhbw0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 003CACF248257734_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0IHNlYW1zIHRoZSB0d28gPC9m b250Pjx0dD48Zm9udCBzaXplPTI+bWV0aG9kb2xvZ3kNCjwvZm9udD48L3R0Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5hcmUgYW50aXRoZXNlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5CdXQgSSB0aGluayBpdCBhZ2FpbiwgYW5kICpmZWVsKiB0aGUgdHdvIG1l dGhvZG9sb2d5DQptaWdodCBoYXZlIGludGVyc2VjdGlvbi4gVGhhdCBpcywgdXNpbmcgJnF1b3Q7 UmVmYXNoaW9uIHdheSZxdW90OywgYnV0DQpzYXZlcyBjdXJyZW50IHJpZ2h0IGNhc2UgYXMgaXQg aXMuIFRoZW4sIHRoZSB0d28gbWV0aG9kb2xvZ3kgd291bGQgYmUgc2FtZQ0KdGVjaG5pY2FsbHks IHdoaWxlIHVzaW5nIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbi48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPklmIHdlIGNhbiBkbyBpdCBsaWtlIHRoaXMsIEknZCBsaWtl IHRvIGNoYW5nZSBteSBwcmVmZXJlbmNlDQpmcm9tICZxdW90O1BhdGNoaW5nIHdheSZxdW90OyB0 byAmcXVvdDtSZWZhc2hpb24gd2F5JnF1b3Q7LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+QW5kIEkgbmVlZCBhIGxpdHRsZSB0aW1lIHRvIGRvIHRoZSBldmFsdWF0aW9u IGNhcmVmdWxseS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRoYW5r cyw8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkdhbzwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJy Pg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1 LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNv bG9yPSM4MDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+LS0tLS0g16q3osjLIEdhb1lhbmcxNDAxOTcv dXNlci96dGVfbHRkDQrKsbzkIDIwMTAtMDUtMzEgMTg6NTEgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5HYW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZCDQtNPaIDIwMTAt MDUtMzEgMTY6Mjk6MTE6PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IEkgKnRoaW5rKiB0aGF0IGNvbnNpZGVyYXRpb25zIG9mICpnbGFyZSogb2Nj dXIgd2hlbiB0aGVyZSBpcw0Kc29tZXRoaW5nIDxicj4NCiZndDsgJmd0OyB0byBiZSAqbmVnb3Rp YXRlZCogYW5kIGVpdGhlciBzaWRlIG1heSBpbml0aWF0ZSB0aGUgbmVnb3RpYXRpb24uDQpUaGUg PGJyPg0KJmd0OyAmZ3Q7IG5lZ290aWF0ZWQgcGllY2Ugb2Ygc3RhdGUgdGhhdCBoYXMgYmVlbiBj b25zaWRlcmVkIHRvIGRhdGUgZm9yDQpnbGFyZSBpcyA8YnI+DQomZ3Q7ICZndDsgdGhlIHBhaXIg b2YgU0RQIGJvZGllcyB0aGF0IGRlc2NyaWJlIHRoZSBtZWRpYSBzZXNzaW9ucy48L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBZb3VyIGNsYXNzaWZpY2F0 aW9uOiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAm cXVvdDtPL0EgZ2xhcmUgY2FzZSZxdW90OyBhbmQgJnF1b3Q7U2Vzc2lvbiBUaW1lciBnbGFyZSBj YXNlJnF1b3Q7DQphcmUgc3Vic2V0IG9mIDxicj4NCiZndDsgJnF1b3Q7bmVnb3RpYXRlZCBnbGFy ZSBjYXNlJnF1b3Q7OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7ICZxdW90O1RhcmdldC1yZWZyZXNoIGFtYmlndW91cyBtaXNvcmRlciZxdW90OyBhbmQg JnF1b3Q7VXBkYXRpbmcgUEFJJnF1b3Q7DQphcmUgc3Vic2V0IG9mPGJyPg0KJmd0OyAmcXVvdDtE ZWNsYXJpbmcgYW1iaWd1b3VzIG1pc29yZGVyJnF1b3Q7OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZxdW90O25lZ290aWF0ZWQgZ2xhcmUgY2FzZSZx dW90OyBhbmQgJnF1b3Q7RGVjbGFyaW5nIGFtYmlndW91cyBtaXNvcmRlciZxdW90Ow0KYXJlIDxi cj4NCiZndDsgc3Vic2V0IG9mICZxdW90O2FtYmlndW91cyBjYXNlJnF1b3Q7LjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEkgb25jZSBoYWQgYSBjbGFz c2lmaWNhdGlvbiBhcyAmcXVvdDtnbGFyZSBjYXNlJnF1b3Q7ID0gJnF1b3Q7YW1iaWd1b3VzDQpj YXNlJnF1b3Q7LiBCdXQgPGJyPg0KJmd0OyBpZiB3ZSBjaG9vc2UgdGhlICZxdW90O1BhdGNoaW5n IHdheSZxdW90OyhzZWUgYmVsb3cpLCBJIGd1ZXNzIG15IDxicj4NCiZndDsgY2xhc3NpZmljYXRp b24gaXMgZW5vdWdoLiBJZiB3ZSB3YW50IHRoZSAmcXVvdDtSZWZhc2hpb24gd2F5JnF1b3Q7LA0K eW91ciBtb3JlIDxicj4NCiZndDsgcmVmaW5lZCBjbGFzc2lmaWNhdGlvbiBtaWdodCBiZSBuZWVk ZWQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgQXMgbm90ZWQgZWxzZXdoZXJlIGluIHRoaXMgdGhyZWFkLCBhbm90 aGVyIHBpZWNlIHN0YXRlIHRoYXQgaXMNCjxicj4NCiZndDsgJmd0OyAqbmVnb3RpYXRlZCogaXMg c2Vzc2lvbi10aW1lci4gQXMgYSByZXN1bHQsIHRoZXJlIGNvdWxkIGJlIGENCmdsYXJlIDxicj4N CiZndDsgJmd0OyBzaXR1YXRpb24gYXJvdW5kIHRoYXQuIFRoZSBkZXRlcm1pbmF0aW9uIG9mIHdo ZXRoZXIgZ2xhcmUgaGFzDQpvY2N1cnJlZCA8YnI+DQomZ3Q7ICZndDsgb3VnaHQgdG8gYmUgaW5k ZXBlbmRlbnQgZm9yIGVhY2gga2luZCBvZiBuZWdvdGlhdGVkIHN0YXRlLiBTbw0Kb25lIDxicj4N CiZndDsgJmd0OyBkZXRlcm1pbmF0aW9uIGZvciBTRFAsIGFub3RoZXIgZm9yIHNlc3Npb24tdGlt ZXIuIEJ1dCB0aGVyZSBpcw0Kb25seSBvbmUgPGJyPg0KJmd0OyAmZ3Q7IG1lY2hhbmlzbSBmb3Ig c2lnbmFsaW5nIHRoZSBnbGFyZSBpbiBlaXRoZXIgY2FzZSwgdGhlIDQ5MSByZXNwb25zZQ0KY29k ZS4gPGJyPg0KJmd0OyAmZ3Q7IFNvIGl0IHdvdWxkIGJlIHVzZWQgaWYgKmVpdGhlciogc2RwLWds YXJlIG9yIHNlc3Npb24tdGltZXItZ2xhcmUNCm9jY3VycmVkLjxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgVGFyZ2V0LXJlZnJlc2ggaXMgc29tZXdoYXQgZGlmZmVyZW50LCBiZWNhdXNl IGl0IGlzbid0ICpuZWdvdGlhdGVkKg0KLSBpdCA8YnI+DQomZ3Q7ICZndDsgaXMgc2ltcGx5ICpk ZWNsYXJlZCogaW5kZXBlbmRlbnRseSBpbiBlYWNoIGRpcmVjdGlvbi4gU28gSSBkb24ndA0KdGhp bmsgPGJyPg0KJmd0OyAmZ3Q7IGl0IHJlYWxseSBvdWdodCB0byBiZSBjb25zaWRlcmVkIGEgZ2xh cmUgc2l0dWF0aW9uLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQW5vdGhlciBpbiB0 aGlzIGNhdGVnb3J5IGlzIHNlbmRpbmcgYW4gdXBkYXRlZCBQQUksIG9yIGNoYW5naW5nDQpGcm9t LiA8YnI+DQomZ3Q7ICZndDsgVGhpcyB0byBpcyBhIGRlY2xhcmF0aW9uIHJhdGhlciB0aGFuIGEg bmVnb3RpYXRpb24sIHNvIHRoYXQgZ2xhcmUNCjxicj4NCiZndDsgJmd0OyBzaG91bGRuJ3QgYXBw bHkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbiBib3RoIG9mIHRob3NlIGNhc2Vz LCB0aGVyZSByZW1haW5zIGFuIG9yZGVyaW5nIGlzc3VlLCBhbmQNCnBlcmhhcHMgdGhlIDxicj4N CiZndDsgJmd0OyBhbnN3ZXIgaXMgdG8gZm9yYmlkIGJlaGF2aW9yIHRoYXQgY2FuIHJlc3VsdCBp biBhbWJpZ3VpdHkuIEJ1dA0KSSBmZWFyIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmZ3Q7dGhhdCBjdXJlIGlzIHdvcnNlIHRoYW4gdGhlIGRpc2Vhc2UsIHNvIEknbQ0K aW5jbGluZWQgdG8gc2VlayBhIGJldHRlciBjdXJlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsgdGhlcmUgYXJlIHR3byBkaWZmZXJlbnQg bWV0aG9kb2xvZ3kgZm9yIHRoaXMgaXNzdWU6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDEuIFBhdGNoaW5nIHdheTogU2F2aW5nIGN1cnJlbnQgcmlnaHQgY2FzZSBhcw0K aXQgaXMsIGFuZCBjdXJlIDxicj4NCiZndDsgYW1iaWd1b3VzIGNhc2Ugd2l0aG91dCBhbnkgYnJl YWNoIGZvciBjdXJyZW50IHJpZ2h0IGNhc2Uob3IgbWFraW5nDQo8YnI+DQomZ3Q7IHRoZSBicmVh Y2ggYXMgbGl0dGxlIGFzIHBvc3NpYmxlKS4gSSB0aGluayB0aGUgd2F5IGRlZmluZWQgaW4gdGhl DQo8YnI+DQomZ3Q7IGRyYWZ0IGJlbG9uZ3MgdG8gJnF1b3Q7UGF0Y2hpbmcgd2F5JnF1b3Q7LiA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAyLiBSZWZh c2hpb24gd2F5OiBCYXNlZCBvbiB0aGUgcmVmaW5lZCBjbGFzc2lmaWNhdGlvbiBvZiAmcXVvdDth bWJpZ3VvdXMNCjxicj4NCiZndDsgY2FzZSZxdW90Oywgc2VlayBzb2x1dGlvbiBhbmQgcmVkZWZp bmUgcnVsZXMgb24gZWFjaCBjbGFzc2lmaWNhdGlvbidzDQo8YnI+DQomZ3Q7IHNlbWFudGljcy4g VGhpcyB3YXkgbWlnaHQgZm9yYmlkIHNvbWUgKmN1cnJlbnQgcmlnaHQgY2FzZSouPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGVjaG5pY2FsbHksIEkg dGhpbmsgJnF1b3Q7UmVmYXNoaW9uIHdheSZxdW90OyBpcyBiZXR0ZXIuIEJ1dCBjb25zaWRlcmlu Zw0KPGJyPg0KJmd0OyB0aGVyZSdzIHdvdWxkIGJlIGEgc2VyaW91cyBpbnRlcndvcmtpbmcgaXNz dWUgYmVoaW5kIHRoZSAmcXVvdDtSZWZhc2hpb24NCjxicj4NCiZndDsgd2F5JnF1b3Q7KHRoZXJl IHdvdWxkIGJlIGEgcXVpdCBsb25nIHBlcmlvZCBmb3IgbW9zdCB2ZW5kb3JzIGFkb3B0aW5nDQo8 YnI+DQomZ3Q7IHRoaXMgZHJhZnQpLCBJIGZpbmFsbHkgcHJlZmVyIHRoZSAmcXVvdDtQYXRjaGlu ZyB3YXkmcXVvdDsgZm9yIG5vd2FkYXlzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyA8YnI+DQomZ3Q7IFBlcnNvbmFsbHksIEkgcHJlZmVyIHRoaXMgZHJhZnQgaGFzIHJl bGF0aXZlIG5hcnJvdyBhc3BlY3QsIGFuZCB3aXRoPGJyPg0KJmd0OyB0aW55IGltcGFjdCBvbiBj dXJyZW50IHJpZ2h0IHdvcmtpbmcgdGhpbmdzLiBJZiBzb21lZGF5LCB3ZSBoYXZlIGENCjxicj4N CiZndDsgMzI2MWJpcyBwbGFuLCBJIHdvdWxkIHByZWZlciB0aGUgJnF1b3Q7UmVmYXNoaW9uIHdh eSZxdW90OyBtb3JlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEknbSBlc3BlY2lhbGx5IGNvbmNlcm5lZCBhYm91 dCB0aGF0IGluIHRoZSBjYXNlIG9mIHRhcmdldCByZWZyZXNoLg0KSWYgPGJyPg0KJmd0OyAmZ3Q7 IHRoZSBzZW5kZXIgaGFzIGxvc3QgaXRzIG9sZCBhZGRyZXNzLCB0aGVuIHdlIGFyZSBvbiB0aGUg YnJpbmsNCm9mIGxvc2luZyA8YnI+DQomZ3Q7ICZndDsgdGhlIGNhbGwgZW50aXJlbHkuIFNhdmlu ZyB0aGUgY2FsbCBpcyBtb3JlIGltcG9ydGFudCB0aGFuIHdoZXRoZXINCndlIDxicj4NCiZndDsg Jmd0OyBoYXZlIHRoZSBwcm9wZXIgby9hIHN0YXRlIC0gdGhhdCBjYW4gYmUgZml4ZWQgYWZ0ZXIg dGhlIG5ldyB0YXJnZXQNCjxicj4NCiZndDsgJmd0OyBhZGRyZXNzIGlzIGVzdGFibGlzaGVkLiA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBJIGFkbWly ZSB0aGlzIHBvaW50LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7ICZndDsgQWxzbywgdGFyZ2V0IHJlZnJlc2ggY2FzZXMgYXJlIHR5cGljYWxseSByYXJl LiA8YnI+DQomZ3Q7ICZndDsgVHdvIHN1Y2Nlc3NpdmUgb25lcyBpbiBjbG9zZSBzdWNjZXNzaW9u IGluIHRoZSBzYW1lIGRpcmVjdGlvbg0Kc2hvdWxkIGJlIDxicj4NCiZndDsgJmd0OyByYXJlXjIu IChBIHRhcmdldCByZWZyZXNoIG9mIGJvdGggZW5kcyBpbiBxdWljayBzdWNjZXNzaW9uIGNvdWxk DQpiZSBtb3JlIDxicj4NCiZndDsgJmd0OyBsaWtlbHkgLSBmb3IgaW5zdGFuY2UgaWYgdGhlIHNh bWUgZXZlbnQgY2F1c2VzIGJvdGggdG8gbG9zZSB0aGVpcg0KPGJyPg0KJmd0OyAmZ3Q7IGFkZHJl c3MuIEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgdGhpcyB3aWxsIGJlIGEgcmVjb3ZlcmFibGUgZXZl bnQuKTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgU28sIEkgdGhpbmsgd2Ugb3VnaHQg bm90IGJlIGZvcmJpZGRpbmcgdGFyZ2V0IHJlZnJlc2gganVzdCBiZWNhdXNlDQpvZiA8YnI+DQom Z3Q7ICZndDsgb3RoZXIgc3RhdGUuIEFtYmlndWl0eSBhYm91dCB3aGljaCBpcyB0aGUgb2xkIHRh cmdldCBhbmQgd2hpY2gNCmlzIHRoZSA8YnI+DQomZ3Q7ICZndDsgbmV3IG9uZSBjYW4gYmUgbWVh c3VyZWQgYnkgd2hpY2ggaXMgYSBjaGFuZ2UgLSBhc3N1bWluZyB0aGVyZQ0KYXJlbid0IHR3byA8 YnI+DQomZ3Q7ICZndDsgY2hhbmdlcyBpbiBxdWljayBzdWNjZXNzaW9uLiBJIHRoaW5rIEdhbyBo YXMgYWxzbyByZWNvbW1lbmRlZA0KdGhpcy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyBZZXMuIEFuZCBJIHRoaW5rIEdvbnphbG8ncyBjdXJyZW50IHRl eHQgaW4gdGhlIGRyYWZ0IGNvdmVyZWQgdGhpcywNCjxicj4NCiZndDsgdGVjaG5pY2FsbHkuIDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFdoaWxlIHNv bWUgd29yZHMgbGV2ZWwgZW5oYW5jZW1lbnQgbWlnaHQgbmVlZGVkIGZvciBlbmhhbmNpbmcgaXQn cw0KPGJyPg0KJmd0OyB1bmRlcnN0YW5kYWJpbGl0eS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEdhbzwvZm9udD48L3R0Pg0KPGJyPjxwcmU+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUm bmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21h aWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5i c3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7 bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVy bWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7 b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhp cyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRl ZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZu YnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZu YnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4m bmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0 b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJz cDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7 dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5i c3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGkt U3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 003CACF248257734_=-- From gao.yang2@zte.com.cn Mon May 31 05:50:34 2010 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 2CF5D3A6835; Mon, 31 May 2010 05:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.551 X-Spam-Level: X-Spam-Status: No, score=-98.551 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_81=0.6, 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 f0c93k1pM3Iq; Mon, 31 May 2010 05:50:32 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E68C33A6807; Mon, 31 May 2010 05:50:29 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 580712001811080; Mon, 31 May 2010 20:44:29 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 32518.4899669165; Mon, 31 May 2010 20:44:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4VCoHic061260; Mon, 31 May 2010 20:50:17 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <31CB00AA55A10Fshinji.okumura@softfront.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 31 May 2010 20:47:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-31 20:50:04, Serialize complete at 2010-05-31 20:50:04 Content-Type: multipart/alternative; boundary="=_alternative 004674BC48257734_=" X-MAIL: mse2.zte.com.cn o4VCoHic061260 Cc: sipcore-bounces@ietf.org, "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 31 May 2010 12:50:34 -0000 This is a multipart message in MIME format. --=_alternative 004674BC48257734_= Content-Type: text/plain; charset="US-ASCII" > >Target-refresh is somewhat different, because it isn't *negotiated* - it > >is simply *declared* independently in each direction. So I don't think > >it really ought to be considered a glare situation. > > Exactly! > I've thought the differences between offer-answer and target- > refresh as below, > > 1. When a UAS sends 4xx to reINVITE, UAs rollback offer-answer, > but don't rollback remote target. If target refresh is committed, it would no be rollback by non-2xx of Re-INVITE(not means at any situation of 4xx of Re-INVITE, the remote target would be enforced). But it doesn't mean that target refresh or other *non-negotiated-declare* is non-rejective. The point here is the commitment of target refresh. And the commitment for target refresh has been defined in the draft, that is the first reliable response(a reliable provisional response or a 2xx response to the target-refresh request), or a request on the new target from UAS. [Discussion 1] It seams that this commitment rule can be generalized for all *non-negotiated-declare*. And the commitment for target refresh can be maintained by two ways: "would no be rollback by non-2xx of Re-INVITE" or "restrict UAS send 2xx to Re-INVITE". See details in [Discussion 2]. > 2. All reliable response to a reINVITE refresh a remote target > within one INVITE transaction. this is clearly clarfied in section 4.3 of the draft. (If the UAC receives a reliable provisional response or a 2xx response to the target-refresh request, or the UAC receives a request on the new target, the UAS has updated its remote target. The UAC can consider the target refresh operation completed.) > > 3. PRACK is used in offer-answer, but is not a target refresh > request. this is 3262's defintion, we need to stick to. > > 4. A target-refresh is acknowledged by all SIP request(e.g. > MESSAGE, INFO, etc.). this is clearly clarfied in section 4.3 of the draft. (If the UAC receives a reliable provisional response or a 2xx response to the target-refresh request, or the UAC receives a request on the new target, the UAS has updated its remote target. The UAC can consider the target refresh operation completed.) [Discussion 2] Current draft has the text in section 4.2 as: The new behavior regarding target-refresh requests implies that a target- refresh request can, in some cases, update the remote target even if the request is responded with a final error response. This means that target-refresh requests are not atomic. I think that there's no negative impact on the function and behavior, if we restrict the UAS send 2xx to Re-INVITE while there's target refresh(or other *non-negotiated-declare*) during it. And if the UAS want to reject something *negotiated*, it can send another Re-INVITE-in-scope UPDATE. If we do so, we can unify the semantic of Re-INVITE atomicity. Thanks, Gao -------------------------------------------------------- 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 004674BC48257734_= Content-Type: text/html; charset="US-ASCII"

> >Target-refresh is somewhat different, because it isn't *negotiated* - it
> >is simply *declared* independently in each direction. So I don't think
> >it really ought to be considered a glare situation.
>
> Exactly!
> I've thought the differences between offer-answer and target-
> refresh as below,
>
> 1. When a UAS sends 4xx to reINVITE, UAs rollback offer-answer,
>    but don't rollback remote target.

If target refresh is committed, it would no be rollback by non-2xx of Re-INVITE(not means at any situation of 4xx of Re-INVITE, the remote target would be enforced). But it doesn't mean that target refresh or other *non-negotiated-declare* is non-rejective. The point here is the commitment of target refresh.

And the commitment for target refresh has been defined in the draft, that is the first reliable response(a reliable provisional response or a 2xx response to the target-refresh request), or a request on the new target from UAS.

[Discussion 1] It seams that this commitment rule can be generalized for all *non-negotiated-declare*. And the commitment for target refresh can be maintained by two ways: "would no be rollback by non-2xx of Re-INVITE" or "restrict UAS send 2xx to Re-INVITE". See details in [Discussion 2].
   
> 2. All reliable response to a reINVITE refresh a remote target
>    within one INVITE transaction.

this is clearly clarfied in section 4.3 of the draft.
(If the UAC receives a reliable provisional response or a 2xx response
   to the target-refresh request, or the UAC receives a request on the
   new target, the UAS has updated its remote target.  The UAC can
   consider the target refresh operation completed.)

>    
> 3. PRACK is used in offer-answer, but is not a target refresh
>    request.

this is 3262's defintion, we need to stick to.

>    
> 4. A target-refresh is acknowledged by all SIP request(e.g.
>    MESSAGE, INFO, etc.).

this is clearly clarfied in section 4.3 of the draft.
(If the UAC receives a reliable provisional response or a 2xx response
   to the target-refresh request, or the UAC receives a request on the
   new target, the UAS has updated its remote target.  The UAC can
   consider the target refresh operation completed.)

[Discussion 2] Current draft has the text in section 4.2 as:

The new
   behavior regarding target-refresh requests implies that a target-
   refresh request can, in some cases, update the remote target even if
   the request is responded with a final error response.  This means
   that target-refresh requests are not atomic.

I think that there's no negative impact on the function and behavior, if we restrict the UAS send 2xx to Re-INVITE while there's target refresh(or other *non-negotiated-declare*) during it. And if the UAS want to reject something *negotiated*, it can send another Re-INVITE-in-scope UPDATE.
If we do so, we can unify the semantic of Re-INVITE atomicity.

Thanks,

Gao 

--------------------------------------------------------
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 004674BC48257734_=-- From shinji.okumura@softfront.jp Mon May 31 07:18:14 2010 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 C2D403A6A1F for ; Mon, 31 May 2010 07:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.268 X-Spam-Level: X-Spam-Status: No, score=-95.268 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 G78k8Dj+NTMS for ; Mon, 31 May 2010 07:18:12 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id B782928C0EC for ; Mon, 31 May 2010 07:18:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 4324242800E; Mon, 31 May 2010 23:17:59 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNVmD4MKGIdP; Mon, 31 May 2010 23:17:55 +0900 (JST) Received: from softfront.jp (123.230.58.155.er.eaccess.ne.jp [123.230.58.155]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 56CC842800D; Mon, 31 May 2010 23:17:55 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 31 May 2010 23:17:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: References: Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 31 May 2010 14:18:14 -0000 Gao, >your chart: > >>> >>> A B >>> | | >>> s0|re-INV (offer1) |s0 >>> |------------------------------>| >>> | 18x-rel(answer1)| >>> |<------------------------------| >>> s1| non-2xx|s1 >>> |<------------------------------|<-+ >>> s0|ACK |s0| >>> |-----------> | | >>> |UPD(offer0) | | >>> |==============================>|* | reject UPDATE >>> | 491(UPD)| | >>> |<==============================| | >>> | ACK | | >>> | ---------->|<-+ >>> | | >>> Figure 2 > >If the UPDATE is in scope of ReINVITE by UAS's view, and the >modification(*negotiated*) in this UPDATE should not be committed. > >If the UPDATE is out scope of ReINVITE by UAS's view, the >modification(*negotiated*) in this UPDATE can be committed. You say "the UPDATE is out scope of ReINVITE" or "the UPDATE is in scope of ReINVITE". That is meaningless. The crux of the matter is that a UAS can not recognize whether the UPDATE is in scope of a ReINVITE or out scope of it. >As there is a ambiguous for UAS, so UAS should reject it. Why? Even if there is a ambiguous, it's not that a UAS should reject all ambiguous things. Such a new restriction is unnecessary. It is UAC's duty to synchronize a common view. >> In my recognition, Gao and I are not agreeing. >> >> I have two comments regarding Figure 2. >> >> 1. Between a non-2xx to a reINVITE and an ACK, the UAS may >> accept a receiving UPDATE. >> >> This draft seems to forbid the UPDATE. >> >> 2. In this case, the common view of both UAs has already >> been synchronized. IMO if an UPDATE has been not used in >> offer-answer exchange before 4xx, then the original >> rollback process may work well. >> That is, a following UPDATE is unnecessary in this case. > >And if the UPDATE is in scope of ReINVITE, the state could not be >treated as synchronized. As I said, an UPDATE is not used. The state is not ambiguous, the both views are synchronized. Regards, Shinji >Thanks, > >Gao From shinji.okumura@softfront.jp Mon May 31 07:30:44 2010 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 A158F3A6869 for ; Mon, 31 May 2010 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.968 X-Spam-Level: X-Spam-Status: No, score=-94.968 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_81=0.6, RELAY_IS_221=2.222, 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 rvkFhQe1cLby for ; Mon, 31 May 2010 07:30:43 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 36E5C3A67A1 for ; Mon, 31 May 2010 07:30:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 6305A42800E; Mon, 31 May 2010 23:30:31 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msVzc0xM53qG; Mon, 31 May 2010 23:30:30 +0900 (JST) Received: from softfront.jp (123.230.58.155.er.eaccess.ne.jp [123.230.58.155]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 435A742800D; Mon, 31 May 2010 23:30:29 +0900 (JST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Mon, 31 May 2010 23:30:32 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: References: Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP 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, 31 May 2010 14:30:44 -0000 Gao, >> >Target-refresh is somewhat different, because it isn't *negotiated* - it >> >is simply *declared* independently in each direction. So I don't think >> >it really ought to be considered a glare situation. >> >> Exactly! >> I've thought the differences between offer-answer and target- >> refresh as below, >> >> 1. When a UAS sends 4xx to reINVITE, UAs rollback offer-answer, >> but don't rollback remote target. > >If target refresh is committed, it would no be rollback by non-2xx of >Re-INVITE(not means at any situation of 4xx of Re-INVITE, the remote >target would be enforced). But it doesn't mean that target refresh or >other *non-negotiated-declare* is non-rejective. The point here is the >commitment of target refresh. > >And the commitment for target refresh has been defined in the draft, that >is the first reliable response(a reliable provisional response or a 2xx >response to the target-refresh request), or a request on the new target >from UAS. Only "first" reliable response? Is it correct? Regards, Shinji From pkyzivat@cisco.com Mon May 31 18:56:45 2010 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 E1A523A6900 for ; Mon, 31 May 2010 18:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.021 X-Spam-Level: X-Spam-Status: No, score=-8.021 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45, 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 4fJjfE7GN4dn for ; Mon, 31 May 2010 18:56:44 -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 70FEF3A67AC for ; Mon, 31 May 2010 18:56:44 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI4FBExAZnwN/2dsb2JhbACDGJsUcaUwiQkIkEqBIoFlBIEcbwSDMQ X-IronPort-AV: E=Sophos;i="4.53,337,1272844800"; d="scan'208";a="116539464" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 Jun 2010 01:56:32 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o511uVwY009869; Tue, 1 Jun 2010 01:56:31 GMT Message-ID: <4C0468CF.4010006@cisco.com> Date: Mon, 31 May 2010 21:56:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4C02D9E0.5060306@cisco.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" , Harbhanu Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer 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, 01 Jun 2010 01:56:46 -0000 Christer Holmberg wrote: > Hi, > >> I agree that there are issues with session-timer. >> >> Normally session-timer is simple, because it is negotiated >> anew with each exchange. That works reasonably well for >> reINVITE and for UPDATE outside of an invite transaction. Its >> a mess if an UPDATE within a (re)INVITE transaction >> negotiates S-T. I think that needs to be forbidden, which >> will be a revision to 4028. > > That could be added to my "NEW DEAL" list of things which shouldn't be done within a re-INVITE :) > > >> (A reINVITE should not take so long that a session-timer will >> expire before it is complete. Perhaps it should be specified >> that *if* a session-timer does expire while a reINVITE is in >> progress, that expiration is ignored.) > > I don't think one should try to do too many things with a single re-INVITE (or UPDATE) in the first place. > > If you are going to perform a re-INVITE, which may take some time to finish, do you S-T refresh *before* that, in a separate transaction. By current definition, you can't do this. Every reinvite and every update renegotiates the session timer - either a new timer value or else the absence of a session timer. So if you want to keep your session timer going you must respecify it on each reinvite. It will require a normative change to alter this. The normative change I advocate is simply the one that says an update within a reinvite transaction does not affect the session timer. This however still has issues when there is ambiguity as to whether the update is within the reinvite or not. Thanks, Paul > Regards, > > Christer > > > > > > >> gao.yang2@zte.com.cn wrote: >>> Hi, >>> >>> Not like O/A usage and target refresh usage, there's no explicit >>> definition of allowing subsequent session refresh request >> in embedded >>> requests(such as UPDATE during pending Re-INVITE). So, I >> think it is >>> not recommended to sending UPDATE as subsequent session refresh >>> request in pending INVITE/Re-INVITE. >>> >>> I'd like to talk more about session timer. If people want to do the >>> semantics extension for session timer's to allow embedded >>> requests(such as UPDATE during pending Re-INVITE), there's one >>> suggestion way(INFORMATIVE at all): >>> >>> Do it like target refresh, then the 2xx of >> INVITE/Re-INVITE's SE value >>> should be as the SE value in the last embedded subsequent session >>> refresh request's 2xx. >>> >>> Then, the glare handling for such usage would be the same as the >>> Target Refresh part in draft-ietf-sipcore-reinvite. >>> >>> Thanks, >>> >>> Gao >>> >>> =================================== >>> Zip : 210012 >>> Tel : 87211 >>> Tel2 :(+86)-025-52877211 >>> e_mail : gao.yang2@zte.com.cn >>> =================================== >>> >>> >>> *Harbhanu * >>> ·¢¼þÈË: sipcore-bounces@ietf.org >>> >>> 2010-05-24 13:40 >>> >>> >>> ÊÕ¼þÈË >>> sipcore@ietf.org >>> ³­ËÍ >>> >>> Ö÷Ìâ >>> [sipcore] REg. draft-ietf-sipcore-reinvite-04 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 1. UE1 --- INVITE SE-1800 ¨¤ UE2 >>> 2. UE1 <--- 183 ------------------ UE2 >>> >>> 3. UE1 --- UPDATE SE-600 ¨¤ UE2 >>> 4. UE1 <--- 200 UPDATE -SE600 -- UE2 >>> >>> 5. UE1 <--- 200 INVITE SE-1800 -- UE2 >>> >>> Please refer the scenario above for handling of >> Session-Timer, (4028). >>> As per the Draft-ietf-sipcore-reinvite-04 section 4.5: >>> ¡° When checking for glare situations, UAs MUST treat every UPDATE >>> request as if it contained an offer. Additionally, UAs >> MUST treat >>> the exchange of a 2xx response to an INVITE request and its >>> corresponding ACK request as an offer/answer exchange. >> Consequently, >>> the rules regarding glare situations applicable to offer/answer >>> exchanges are also applicable to those exchanges.¡± >>> >>> Here, we are not able to conclude whether both UAs should >> run session >>> timer with 1800 or 600, or otherwise whether the UPDATE should be >>> rejected. >>> >>> As per my understanding this draft doesn¡¯t **explicitly** mention >>> anything about the Session-Timer, wherein there is an early >> negotiation. >>> Since 4028 also doesn¡¯t >>> have any reference for early negotiation, so we suggest that it can >>> better be incorporated in the above mentioned >>> draft[ietf-sipcore-reinvite-04]. >>> >>> Please share your opinion and do guide us incase any of the >> existing >>> RFC/active-draft already captures this. >>> >>> Thanks! >>> >>> Regards, >>> Harbhanu >>> >>> >> ********************************************************************** >>> ***************** This e-mail and attachments contain confidential >>> information from HUAWEI, which is intended only for the person or >>> entity whose address is listed above. Any use of the information >>> contained herein in any way (including, but not limited to, >> total or >>> partial disclosure, reproduction, or dissemination) by >> persons other >>> than the intended >>> recipient's) is prohibited. If you receive this e-mail in error, >>> please notify the sender by phone or email immediately and >> delete it! >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> -------------------------------------------------------- >>> 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. >>> >>> >> ---------------------------------------------------------------------- >>> -- >>> >>> _______________________________________________ >>> 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 May 31 19:18:18 2010 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 B07563A67AC; Mon, 31 May 2010 19:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.51 X-Spam-Level: X-Spam-Status: No, score=-8.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_72=0.6, 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 hRyKIJnYrReg; Mon, 31 May 2010 19:18:17 -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 796783A67C1; Mon, 31 May 2010 19:18:17 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAEAKBEytJV2Z/2dsb2JhbACSJYwIcaUrmVyFFgQ X-IronPort-AV: E=Sophos;i="4.53,337,1272844800"; d="scan'208";a="116543544" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 01 Jun 2010 02:18:04 +0000 Received: from [10.86.252.208] ([10.86.252.208]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o512I3wM024260; Tue, 1 Jun 2010 02:18:04 GMT Message-ID: <4C046DDB.5070402@cisco.com> Date: Mon, 31 May 2010 22:18:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) 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 Cc: OKUMURA Shinji , sipcore-bounces@ietf.org, "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 01 Jun 2010 02:18:18 -0000 gao.yang2@zte.com.cn wrote: ... > *[Discussion 2]* Current draft has the text in section 4.2 as: > > The new > behavior regarding target-refresh requests implies that a target- > refresh request can, in some cases, update the remote target even if > the request is responded with a final error response. This means > that target-refresh requests are not atomic. > > I think that there's no negative impact on the function and behavior, if > we restrict the UAS send 2xx to Re-INVITE while there's target > refresh(or other *non-negotiated-declare*) during it. And if the UAS > want to reject something *negotiated*, it can send another > Re-INVITE-in-scope UPDATE. > If we do so, we can unify the semantic of Re-INVITE atomicity. There is always one case when requiring a 2xx response to reinvite is totally unacceptable - when it fails authentication. E.g. this could be a forged request by a third party. It could even be an attempt by a third party to hijack the session by introducing a target change to itself. There must be other similar cases, such as when the request is malformed. So IMO requiring a 2xx response is not a successful solution. Thanks, Paul From gao.yang2@zte.com.cn Mon May 31 19:41:38 2010 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 CA0F73A6819; Mon, 31 May 2010 19:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.832 X-Spam-Level: X-Spam-Status: No, score=-98.832 tagged_above=-999 required=5 tests=[AWL=2.406, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 QlNhkiSU0B7I; Mon, 31 May 2010 19:41:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 2AB023A67AC; Mon, 31 May 2010 19:41:36 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368872001811080; Tue, 1 Jun 2010 10:34:20 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.6705304933; Tue, 1 Jun 2010 10:41:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o512epuZ010049; Tue, 1 Jun 2010 10:40:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C046DDB.5070402@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 1 Jun 2010 10:37:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-01 10:40:50, Serialize complete at 2010-06-01 10:40:50 Content-Type: multipart/alternative; boundary="=_alternative 000EAD6F48257735_=" X-MAIL: mse2.zte.com.cn o512epuZ010049 Cc: OKUMURA Shinji , sipcore-bounces@ietf.org, "sipcore@ietf.org" , "Christer.Holmberg@ericsson.com" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP 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, 01 Jun 2010 02:41:39 -0000 This is a multipart message in MIME format. --=_alternative 000EAD6F48257735_= Content-Type: text/plain; charset="US-ASCII" > > *[Discussion 2]* Current draft has the text in section 4.2 as: > > > > The new > > behavior regarding target-refresh requests implies that a target- > > refresh request can, in some cases, update the remote target even if > > the request is responded with a final error response. This means > > that target-refresh requests are not atomic. > > > > I think that there's no negative impact on the function and behavior, if > > we restrict the UAS send 2xx to Re-INVITE while there's target > > refresh(or other *non-negotiated-declare*) during it. And if the UAS > > want to reject something *negotiated*, it can send another > > Re-INVITE-in-scope UPDATE. > > If we do so, we can unify the semantic of Re-INVITE atomicity. > > There is always one case when requiring a 2xx response to reinvite is > totally unacceptable - when it fails authentication. E.g. this could be > a forged request by a third party. It could even be an attempt by a > third party to hijack the session by introducing a target change to itself. > > There must be other similar cases, such as when the request is malformed. > > So IMO requiring a 2xx response is not a successful solution. Yes. And I considered this case. As authentication failure, UAS should reject the target request directly. That is, there *MUST NOT* be any 100rel or other in-scope new request (to the new target) to do the commitment of the target request. In other words, as the UAS commit the target request, there *MUST* be 2xx of the Re-INVITE. Thanks, Gao -------------------------------------------------------- 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 000EAD6F48257735_= Content-Type: text/html; charset="US-ASCII"

> > *[Discussion 2]* Current draft has the text in section 4.2 as:
> >
> > The new
> >    behavior regarding target-refresh requests implies that a target-
> >    refresh request can, in some cases, update the remote target even if
> >    the request is responded with a final error response.  This means
> >    that target-refresh requests are not atomic.
> >
> > I think that there's no negative impact on the function and behavior, if
> > we restrict the UAS send 2xx to Re-INVITE while there's target
> > refresh(or other *non-negotiated-declare*) during it. And if the UAS
> > want to reject something *negotiated*, it can send another
> > Re-INVITE-in-scope UPDATE.
> > If we do so, we can unify the semantic of Re-INVITE atomicity.
>
> There is always one case when requiring a 2xx response to reinvite is
> totally unacceptable - when it fails authentication. E.g. this could be
> a forged request by a third party. It could even be an attempt by a
> third party to hijack the session by introducing a target change to itself.
>
> There must be other similar cases, such as when the request is malformed.
>
> So IMO requiring a 2xx response is not a successful solution.

Yes. And I considered this case.

As authentication failure, UAS should reject the target request directly. That is, there *MUST NOT* be any 100rel or other in-scope new request (to the new target) to do the commitment of the target request.

In other words, as the UAS commit the target request, there *MUST* be 2xx of the Re-INVITE.

Thanks,

Gao 

--------------------------------------------------------
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 000EAD6F48257735_=-- From gao.yang2@zte.com.cn Mon May 31 20:12:14 2010 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 443B13A6937 for ; Mon, 31 May 2010 20:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.677 X-Spam-Level: X-Spam-Status: No, score=-96.677 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, 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 ENi+uG30mR9h for ; Mon, 31 May 2010 20:12:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id BAB033A686A for ; Mon, 31 May 2010 20:12:12 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871727820181; Tue, 1 Jun 2010 11:04:58 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.3015714703; Tue, 1 Jun 2010 11:11:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5139EQu051260; Tue, 1 Jun 2010 11:09:15 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 1 Jun 2010 11:06:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-01 11:09:13, Serialize complete at 2010-06-01 11:09:13 Content-Type: multipart/alternative; boundary="=_alternative 0011461248257735_=" X-MAIL: mse2.zte.com.cn o5139EQu051260 Cc: "sipcore@ietf.org" Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1pZXRmLXNpcGNvcmUtcmVp?= =?gb2312?b?bnZpdGUtMDQ6IGdsYXJlIGFuZCBVUERBVEV3aXRob3V0IFNEUA==?= 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, 01 Jun 2010 03:12:14 -0000 This is a multipart message in MIME format. --=_alternative 0011461248257735_= Content-Type: text/plain; charset="US-ASCII" > > >> >Target-refresh is somewhat different, because it isn't *negotiated* - it > >> >is simply *declared* independently in each direction. So I don't think > >> >it really ought to be considered a glare situation. > >> > >> Exactly! > >> I've thought the differences between offer-answer and target- > >> refresh as below, > >> > >> 1. When a UAS sends 4xx to reINVITE, UAs rollback offer-answer, > >> but don't rollback remote target. > > > >If target refresh is committed, it would no be rollback by non-2xx of > >Re-INVITE(not means at any situation of 4xx of Re-INVITE, the remote > >target would be enforced). But it doesn't mean that target refresh or > >other *non-negotiated-declare* is non-rejective. The point here is the > >commitment of target refresh. > > > >And the commitment for target refresh has been defined in the draft, that > >is the first reliable response(a reliable provisional response or a 2xx > >response to the target-refresh request), or a request on the new target > >from UAS. > > Only "first" reliable response? > Is it correct? This is about the triggering of commitment. After the first reliable response or a request to the new target, the target modification is committed. UAS can send subsequent reliable response with new target. Thanks, Gao -------------------------------------------------------- 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 0011461248257735_= Content-Type: text/html; charset="US-ASCII"

>
> >> >Target-refresh is somewhat different, because it isn't *negotiated* - it
> >> >is simply *declared* independently in each direction. So I don't think
> >> >it really ought to be considered a glare situation.
> >>
> >> Exactly!
> >> I've thought the differences between offer-answer and target-
> >> refresh as below,
> >>
> >> 1. When a UAS sends 4xx to reINVITE, UAs rollback offer-answer,
> >>    but don't rollback remote target.
> >
> >If target refresh is committed, it would no be rollback by non-2xx of
> >Re-INVITE(not means at any situation of 4xx of Re-INVITE, the remote
> >target would be enforced). But it doesn't mean that target refresh or
> >other *non-negotiated-declare* is non-rejective. The point here is the
> >commitment of target refresh.
> >
> >And the commitment for target refresh has been defined in the draft, that
> >is the first reliable response(a reliable provisional response or a 2xx
> >response to the target-refresh request), or a request on the new target
> >from UAS.
>
> Only "first" reliable response?
> Is it correct?
This is about the triggering of commitment. After the first reliable response or a request to the new target, the target modification is committed.

UAS can send subsequent reliable response with new target.

Thanks,

Gao 

--------------------------------------------------------
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 0011461248257735_=--