From sip-bounces@ietf.org Sun Feb 1 11:54:23 2009 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F813A684A; Sun, 1 Feb 2009 11:54:23 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881E93A684A for ; Sun, 1 Feb 2009 11:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 S4Kgwhn8JbDf for ; Sun, 1 Feb 2009 11:54:21 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 0C6F63A63CB for ; Sun, 1 Feb 2009 11:54:20 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n11Jrws04417 for ; Sun, 1 Feb 2009 19:53:58 GMT Received: from [47.141.31.187] ([47.141.31.187]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Feb 2009 14:53:57 -0500 From: "Dale Worley" To: SIP Organization: Nortel Networks Date: Sun, 01 Feb 2009 14:53:56 -0500 Message-Id: <1233518036.5226.1.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) X-OriginalArrivalTime: 01 Feb 2009 19:53:57.0343 (UTC) FILETIME=[D1A48EF0:01C984A6] Subject: [Sip] Problems with History-Info X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org To get discussion going for 2009, let me start with some complaints about the History-Info header. One problem is identifying which value in the History-Info header corresponds to the request carrying the header, that is, which branch of the History-Info request tree represents the current request. Reading RFC 4244, it's clear that what is intended is that the History-Info values will be written in depth-first tree-walk order, and that syntactically *last* value corresponds to the request carrying the History-Info header. Neither of these principles is stated explicitly as far as I can tell. Difficulty arises when there is parallel forking, or any similar situation when a request has multiple redirects or retargets that become known in one processing step. If one maintains the rule that the enclosing request corresponds to the last History-Info value, one must choose among: (Assume that sip:1@example.com has been retargeted to sip:1A@example.com and sip:1B@example.com.) 1.each derived request carries only one of the new History-Info values INVITE sip:1A@example.com History-Info: ;index=1, ;index=1.1 INVITE sip:1B@example.com History-Info: ;index=1, ;index=1.1 2.each derived request carries only the new History-Info values that are "before" (in some ordering) the one for the current request INVITE sip:1A@example.com History-Info: ;index=1, ;index=1.1 INVITE sip:1B@example.com History-Info: ;index=1, ;index=1.1, ;index=1.2 3.each derived request carries all of the new History-Info values, but in each request, they are ordered so that the value corresponding to the request is last INVITE sip:1A@example.com History-Info: ;index=1, ;index=1.1, ;index=1.2 INVITE sip:1B@example.com History-Info: ;index=1, ;index=1.1, ;index=1.2 Solutions 1 and 3 are troublesome because the generated History-Info values are not consistent between the derived requests, and solutions 1 and 2 are troublesome because the downstream network elements are given less information than is available about the forking of the request. Note that this isn't just a theoretical problem, draft-rosenberg-sip-target-uri-delivery-00 is already running up against it (section 5): "Furthermore, if that URI had an 'index' of N, the URIs with indices N.M for all M, are the registered contacts to that URI." If the I-D is taken at face value, solution 3 must be used, giving different History-Info values on different derived requests. Let us then consider putting all known targets of a request in History-Info, but not require that the last History-Info value corresponds to the containing request. In terms of the above example, both derived requests would have the same History-Info header: INVITE sip:1A@example.com History-Info: ;index=1, ;index=1.1, ;index=1.2 INVITE sip:1B@example.com History-Info: ;index=1, ;index=1.1, ;index=1.2 If we do this, we need to be able to identify the value that corresponds to the current request by some method other than the index values and syntactic ordering. In a perfect world, we could compare the request-URI with the URIs in History-Info to see which one matches. However, this fails if: - two URIs in History-Info are the same (In theory, this should not happen, but it can happen sensibly if two derived requests differed substantially in some manner which could affect the ultimate resolution of the request-URI; e.g., caller preferences.) - if an intermediate proxy has changed the request-URI but not updated History-Info (In this case, we want to know which History-Info value corresponds to the most recent parent request that was logged in History-Info.) A more reliable solution would be to add a "current" marker to the leaf of the History-Info tree that corresponds to the containing request. In the example above: INVITE sip:1A@example.com History-Info: ;index=1, ;index=1.1;current, ;index=1.2 INVITE sip:1B@example.com History-Info: ;index=1, ;index=1.1, ;index=1.2;current ---------------------------------------------------------------------- A second problem with History-Info as it is currently structured is in the handling of requests generated as a consequence of recursing on 3xx responses. History-Info as it is now defined correctly shows the "forking structure" of a request. But we also want to know the "derivation" of the current request-URI, the sequence of transformations from the original request-URI (presumably the same as the To URI) to the current request-URI. Assuming that the transformations are done in the ordinary manner by proxies, History-Info carries the needed information. From RFC 4244 section 4.5: UA1 Proxy1 Proxy2 UA2 | | | | |--INVITE sip:Bob@P1... -->| | | History-Info: ;index=1 | |-INVITE sip:Bob@P2... -->| | History-Info: ;index=1, ;index=1.1 | | | | | | |-INVITE sip:User2@UA2...-->| History-Info: ;index=1, ;index=1.1, ;index=1.1.1 In the last INVITE, starting with the last URI and working our way up the tree, we see that the URI sequence is: sip:Bob@P1.example.com -> sip:Bob@P2.example.com -> sip:User2@UA2.example.com However, if one of the transformations is supplied by a 3xx response (e.g., if the request is sent to a "redirect server"), the History-Info data does not effectively show the source of the current request-URI: UA1 Proxy1 Proxy2 UA2 | | | | |--INVITE sip:Bob@P1... -->| | | History-Info: ;index=1 | |-INVITE sip:Bob@P2... -->| | History-Info: ;index=1, ;index=1.1 | |<-- 302 Contact: | | | | | |-INVITE sip:User2@UA2...----------->| History-Info: ;index=1, ;index=1.1, ;index=1.2 The apparent URI sequence is: sip:Bob@P1.example.com -> sip:User2@UA2.example.com There is no unambiguous way determine that the target sip:User2@UA2.example.com came from the 302 response to the request to sip:Bob@P2.example.com. What is needed is a pointer from a History-Info value to the value representing the request which yielded the 3xx response that cause the value in question. I suggest using a parameter named "3xx" for this purpose, so that the last request in the above example becomes: INVITE sip:User2@UA2.example.com History-Info: ;index=1, ;index=1.1, ;index=1.2;3xx=1.1 Which this additional information present, the predecessor of a listed URI is either the URI of its 3xx value (if present), or its parent in the tree. This allows us to recover the URI transformation sequence: sip:Bob@P1.example.com -> sip:Bob@P2.example.com -> sip:User2@UA2.example.com Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 1 22:23:17 2009 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DB928C182; Sun, 1 Feb 2009 22:23:17 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D603A6870 for ; Sun, 1 Feb 2009 22:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IjmiLsGIbS4 for ; Sun, 1 Feb 2009 22:23:15 -0800 (PST) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id 4EE9528C182 for ; Sun, 1 Feb 2009 22:23:01 -0800 (PST) X-AuditID: cb5bdd58-a8706bb0000077d1-b2-4986912c32ed Received: from blr-ec-aa01.wipro.com (unknown [10.201.18.41]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id 3C7CB558002 for ; Mon, 2 Feb 2009 11:52:36 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 11:52:35 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 11:52:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 11:50:39 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is Contact Header mandatory in REFER message? Thread-Index: Aclat9VOiYE7yko7Q8eiUEqGkmaVygqRC9iA From: To: X-OriginalArrivalTime: 02 Feb 2009 06:22:36.0021 (UTC) FILETIME=[A3BA1250:01C984FE] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] Is Contact Header mandatory in REFER message? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1134678620==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1134678620== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C984FE.A39661B2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C984FE.A39661B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Is it mandatory to have a Contact Header field in REFER message? =20 =20 RFC 3261 SIP: Session Initiation Protocol June 2002 =20 =20 8.1.1.8 Contact =20 The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. =20 If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. =20 =20 =20 =20 =20 RFC 3515 The SIP Refer Method April 2003 =20 =20 2. The REFER Method =20 REFER is a SIP method as defined by RFC 3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request. =20 Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1]. =20 A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2]. =20 A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record- Route logic of that dialog. =20 =20 Regards, Sunil =20 =20 ------_=_NextPart_001_01C984FE.A39661B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Is it mandatory to have a Contact = Header field in REFER message?

 

 

RFC =
3261            =
SIP: Session Initiation =
Protocol           =
June 2002

 

 

8.1.1.8 =
Contact
 
   The Contact header field =
provides a SIP or SIPS URI that can be =
used
   to contact that specific =
instance of the UA for subsequent =
requests.
   The Contact header field MUST be present and =
contain exactly one =
SIP
   or SIPS URI in =
any request that can result in the establishment of =
a
   dialog.  =
For the methods defined in this specification, that =
includes
   only the INVITE =
request.  For these requests, the scope of =
the
   Contact is global.  That =
is, the Contact header field value =
contains
   the URI at which the UA would =
like to receive requests, and this =
URI
   MUST be valid even if used in =
subsequent requests outside of =
any
   =
dialogs.
 
   If the Request-URI or top Route =
header field value contains a =
SIPS
   URI, the Contact header field =
MUST contain a SIPS URI as well.

 

 

 

 

 

RFC =
3515           &nb=
sp;      The SIP Refer =
Method           &=
nbsp;    April =
2003
 
 
2. The =
REFER Method
 
   REFER is a SIP method as defined =
by RFC 3261 [1].  The REFER =
method
   indicates that the recipient =
(identified by the Request-URI) =
should
   contact a third party using the =
contact information provided in =
the
   =
request.
 
   Unless stated otherwise, the =
protocol for emitting and responding =
to
   a REFER request are identical to =
those for a BYE request in [1].  =
The
   behavior of SIP entities not =
implementing the REFER (or any =
other
   unknown) method is explicitly =
defined in [1].
 
   A REFER request implicitly =
establishes a subscription to the =
refer
   event.  Event subscriptions =
are defined in [2].
 
   A REFER request MAY be placed outside the =
scope of a dialog =
created
   with an =
INVITE.  REFER creates a dialog, and MAY be =
Record-Routed,
   hence MUST =
contain a single Contact header field value.  =
REFERs
   occurring inside an existing =
dialog MUST follow the =
Route/Record-
   Route logic of that =
dialog.
 

 

Regards,

Sunil

 

 

------_=_NextPart_001_01C984FE.A39661B2-- --===============1134678620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1134678620==-- From sip-bounces@ietf.org Mon Feb 2 00:48:14 2009 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026D13A6896; Mon, 2 Feb 2009 00:48:14 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232C93A6403 for ; Mon, 2 Feb 2009 00:48:12 -0800 (PST) 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=[AWL=-0.001, 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 6B1w1zf7OaAp for ; Mon, 2 Feb 2009 00:48:11 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8FABF3A6896 for ; Mon, 2 Feb 2009 00:48:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,364,1231113600"; d="scan'208,217";a="35615621" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2009 08:47:51 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n128lpEX022094; Mon, 2 Feb 2009 03:47:51 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n128lpf3022355; Mon, 2 Feb 2009 08:47:51 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 03:47:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 03:47:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Is Contact Header mandatory in REFER message? thread-index: Aclat9VOiYE7yko7Q8eiUEqGkmaVygqRC9iAAAW46DA= References: From: "Sanjay Sinha (sanjsinh)" To: , X-OriginalArrivalTime: 02 Feb 2009 08:47:51.0100 (UTC) FILETIME=[EE5197C0:01C98512] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15939; t=1233564471; x=1234428471; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20Is=20Contact=20Header=20mandato ry=20in=20REFER=20message? |Sender:=20 |To:=20,=20; bh=7VHX2qAa4itfDF24TAGUz8OFguQBhHXqlNDSmxMTX7Q=; b=IiIMM8q/hhTn6Py1AY/Ypyi1kHc4V/76bwoIbPWC5khweP3dYhBcVNEbhX UmWA9k+Jo5BY5K3xnUD/UeRH2OGZ9SNlk9ucZVcR979XT+1XBUcxlqqTTBfc aJT6VmjmPv; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Sip] Is Contact Header mandatory in REFER message? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1985489263==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1985489263== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98512.EE2BE6B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98512.EE2BE6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Yes ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sunil.bhagat@wipro.com Sent: Monday, February 02, 2009 11:51 AM To: sip@ietf.org Subject: [Sip] Is Contact Header mandatory in REFER message? =09 =09 Hi, =20 Is it mandatory to have a Contact Header field in REFER message? =20 =20 RFC 3261 SIP: Session Initiation Protocol June 2002 =20 =20 8.1.1.8 Contact =20 The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. =20 If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. =20 =20 =20 =20 =20 RFC 3515 The SIP Refer Method April 2003 =20 =20 2. The REFER Method =20 REFER is a SIP method as defined by RFC 3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request. =20 Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1]. =20 A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2]. =20 A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record- Route logic of that dialog. =20 =20 Regards, Sunil =20 =20 ------_=_NextPart_001_01C98512.EE2BE6B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Yes
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of=20 sunil.bhagat@wipro.com
Sent: Monday, February 02, 2009 = 11:51=20 AM
To: sip@ietf.org
Subject: [Sip] Is Contact = Header=20 mandatory in REFER message?

Hi,

 

Is it = mandatory to=20 have a Contact Header field in REFER = message?

 

 

RFC =
3261            =
SIP: Session Initiation =
Protocol           =
June 2002

 

 

8.1.1.8 =
Contact
 
   The Contact =
header field provides a SIP or SIPS URI that can be =
used
   to contact that =
specific instance of the UA for subsequent =
requests.
   The Contact header field MUST be present and =
contain exactly one =
SIP
   or SIPS URI in any request that can result =
in the establishment of =
a
   =
dialog.  For the methods defined in this specification, that =
includes
   only the INVITE request.  For =
these requests, the scope of the
   Contact is global.  That is, the Contact header =
field value contains
   the URI at which the UA would like to receive =
requests, and this URI
   MUST be valid even if used in subsequent requests =
outside of any
   =
dialogs.
 
   If the =
Request-URI or top Route header field value contains a =
SIPS
   URI, the Contact =
header field MUST contain a SIPS URI as =
well.

 

 

 

 

 

RFC =
3515           &nb=
sp;      The SIP Refer =
Method           &=
nbsp;    April =
2003
 
 
2. The REFER =
Method
 
   REFER is a =
SIP method as defined by RFC 3261 [1].  The REFER =
method
   indicates that the =
recipient (identified by the Request-URI) =
should
   contact a third =
party using the contact information provided in =
the
   =
request.
 
   Unless stated =
otherwise, the protocol for emitting and responding =
to
   a REFER request =
are identical to those for a BYE request in [1].  =
The
   behavior of SIP =
entities not implementing the REFER (or any =
other
   unknown) method is =
explicitly defined in [1].
 
   A REFER =
request implicitly establishes a subscription to the =
refer
   event.  Event =
subscriptions are defined in =
[2].
 
   A REFER request MAY be placed outside the =
scope of a dialog =
created
   with an INVITE.  REFER creates a =
dialog, and MAY be =
Record-Routed,
   hence MUST contain a single Contact header =
field value.  REFERs
   occurring inside an existing dialog MUST follow the =
Route/Record-
   Route logic =
of that dialog.
 

 

Regards,

Sunil

 

 

------_=_NextPart_001_01C98512.EE2BE6B0-- --===============1985489263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1985489263==-- From sip-bounces@ietf.org Tue Feb 3 11:22:12 2009 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383193A6C48; Tue, 3 Feb 2009 11:22:12 -0800 (PST) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405863A6C48 for ; Tue, 3 Feb 2009 11:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.478, 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 eOXb1483OOhi for ; Tue, 3 Feb 2009 11:22:10 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 45DA03A6C51 for ; Tue, 3 Feb 2009 11:22:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,373,1231113600"; d="scan'208";a="35829908" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2009 19:21:48 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13JLmlH018969; Tue, 3 Feb 2009 14:21:48 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n13JLmPv010008; Tue, 3 Feb 2009 19:21:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 14:21:48 -0500 Received: from [10.86.245.79] ([10.86.245.79]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 14:21:48 -0500 Message-ID: <4988994B.2000304@cisco.com> Date: Tue, 03 Feb 2009 14:21:47 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "hanifa.mohammed" References: <0D5F89FAC29E2C41B98A6A762007F5D0017416E3@GBNTHT12009MSX.gb002.siemens.net> <025c01c97e0d$5014b9e0$830810ac@globaledgesoft.com> In-Reply-To: <025c01c97e0d$5014b9e0$830810ac@globaledgesoft.com> X-OriginalArrivalTime: 03 Feb 2009 19:21:48.0066 (UTC) FILETIME=[A887C020:01C98634] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=755; t=1233688908; x=1234552908; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20[SIP]=20Max=20no=20of=20non-inv ite=20pending=20transaction=20within=20a=0A=20dialog |Sender:=20 |To:=20=22hanifa.mohammed=22=20; bh=Vkja+x1Ln3Tx81RAKat/M7fJms8rUBRCDgDzp0P2caw=; b=YGKvZVZ3cr7Uhma7eS2HbPck78oqDUjltsvZt5FXjomdUSDrzGkKJzEPA8 WgKTtFs/JDb6LY4TSzBK8VrTp3eKHjROXxmKj4cAH0kHogsJjXaM3pohJMYV i+Ov8TT9fJ; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] [SIP] Max no of non-invite pending transaction within a dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org hanifa.mohammed wrote: > Hi, > > 1. Only one INVITE request may be pending within a dialog. Else, 491 > will be sent. > 2. Only one non-INVITE request may be pending within a dialog (in one > direction): it is not possible to send UPDATE if no final response has > been received to PRACK. > > Pl clarify whether the above points are right. Esp, the second point. It is possible to have more than one non-invite transaction in progress, but it is usually unwise. If they get out of order, so the 2nd arrives before the first, then the first will be rejected with a 500 response. There are a few cases where this is acceptable. But in most cases you would be well advised to restrict to one transaction at a time. Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sunil.bhagat@wipro.com Wed Feb 4 01:39:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4193A6821 for ; Wed, 4 Feb 2009 01:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2lYGM46lLDg for ; Wed, 4 Feb 2009 01:39:54 -0800 (PST) Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by core3.amsl.com (Postfix) with ESMTP id 6360A3A6B76 for ; Wed, 4 Feb 2009 01:39:53 -0800 (PST) X-AuditID: cb5bdd58-ab70cbb0000077d1-4e-4989624e8d2d Received: from blr-ec-aa01.wipro.com (unknown [10.201.18.41]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with ESMTP id A795A558003 for ; Wed, 4 Feb 2009 15:09:26 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 15:09:26 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 15:09:26 +0530 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_01C986AC.77CAD32E" Date: Wed, 4 Feb 2009 15:07:30 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Is Contact Header mandatory in REFER message? Thread-Index: Aclat9VOiYE7yko7Q8eiUEqGkmaVygqRC9iAAAW46DAAZkHCUA== From: To: , X-OriginalArrivalTime: 04 Feb 2009 09:39:26.0065 (UTC) FILETIME=[77E34610:01C986AC] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Is Contact Header mandatory in REFER message? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 09:39:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C986AC.77CAD32E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Sanjay. =20 So, is the Contact Header mandatory for all SIP messages (Response and Requests)? =20 Regards, Sunil =20 ________________________________ From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 Sent: Monday, February 02, 2009 2:18 PM To: Sunil Bhagat (WT01 - Telecom Equipment); sip@ietf.org Subject: RE: [Sip] Is Contact Header mandatory in REFER message? =20 =20 Yes ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sunil.bhagat@wipro.com Sent: Monday, February 02, 2009 11:51 AM To: sip@ietf.org Subject: [Sip] Is Contact Header mandatory in REFER message? Hi, =20 Is it mandatory to have a Contact Header field in REFER message? =20 =20 RFC 3261 SIP: Session Initiation Protocol June 2002 =20 =20 8.1.1.8 Contact =20 The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. =20 If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. =20 =20 =20 =20 =20 RFC 3515 The SIP Refer Method April 2003 =20 =20 2. The REFER Method =20 REFER is a SIP method as defined by RFC 3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request. =20 Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1]. =20 A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2]. =20 A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record- Route logic of that dialog. =20 =20 Regards, Sunil =20 =20 ------_=_NextPart_001_01C986AC.77CAD32E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks = Sanjay.

 

So, is the Contact Header mandatory = for all SIP messages (Response and Requests)?

 

Regards,

Sunil

 

From: = Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]
Sent: Monday, February = 02, 2009 2:18 PM
To: Sunil Bhagat (WT01 - = Telecom Equipment); sip@ietf.org
Subject: RE: [Sip] Is = Contact Header mandatory in REFER message?

 

 

Yes

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sunil.bhagat@wipro.com
Sent: Monday, February = 02, 2009 11:51 AM
To: sip@ietf.org
Subject: [Sip] Is Contact = Header mandatory in REFER message?

Hi,

 

Is it mandatory to have a Contact = Header field in REFER message?

 

 

RFC =
3261            =
SIP: Session Initiation =
Protocol           =
June 2002

 

 

8.1.1.8 =
Contact
 
   The Contact header field =
provides a SIP or SIPS URI that can be =
used
   to contact that specific =
instance of the UA for subsequent =
requests.
   The Contact header field MUST be present and =
contain exactly one =
SIP
   or SIPS URI in =
any request that can result in the establishment of =
a
   dialog.  =
For the methods defined in this specification, that =
includes
   only the INVITE =
request.  For these requests, the scope of =
the
   Contact is global.  That =
is, the Contact header field value =
contains
   the URI at which the UA would =
like to receive requests, and this =
URI
   MUST be valid even if used in =
subsequent requests outside of =
any
   =
dialogs.
 
   If the Request-URI or top Route =
header field value contains a =
SIPS
   URI, the Contact header field =
MUST contain a SIPS URI as well.

 

 

 

 

 

RFC =
3515           &nb=
sp;      The SIP Refer =
Method           &=
nbsp;    April =
2003
 
 
2. The =
REFER Method
 
   REFER is a SIP method as defined =
by RFC 3261 [1].  The REFER =
method
   indicates that the recipient =
(identified by the Request-URI) =
should
   contact a third party using the =
contact information provided in =
the
   =
request.
 
   Unless stated otherwise, the =
protocol for emitting and responding =
to
   a REFER request are identical to =
those for a BYE request in [1].  =
The
   behavior of SIP entities not =
implementing the REFER (or any =
other
   unknown) method is explicitly =
defined in [1].
 
   A REFER request implicitly =
establishes a subscription to the =
refer
   event.  Event subscriptions =
are defined in [2].
 
   A REFER request MAY be placed outside the =
scope of a dialog =
created
   with an =
INVITE.  REFER creates a dialog, and MAY be =
Record-Routed,
   hence MUST =
contain a single Contact header field value.  =
REFERs
   occurring inside an existing =
dialog MUST follow the =
Route/Record-
   Route logic of that =
dialog.
 

 

Regards,

Sunil

 

 

------_=_NextPart_001_01C986AC.77CAD32E-- From avinashkoneru@huawei.com Wed Feb 4 01:26:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5663A69CA for ; Wed, 4 Feb 2009 01:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 49U350pkADxW for ; Wed, 4 Feb 2009 01:26:09 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 426DD3A6C46 for ; Wed, 4 Feb 2009 01:26:09 -0800 (PST) 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 <0KEJ00DSFBJ0PU@szxga04-in.huawei.com> for sip@ietf.org; Wed, 04 Feb 2009 17:25:48 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEJ00CDJBJ01E@szxga04-in.huawei.com> for sip@ietf.org; Wed, 04 Feb 2009 17:25:48 +0800 (CST) Received: from HTIPLA40203 ([10.18.17.88]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEJ00K3FBIWWN@szxml04-in.huawei.com> for sip@ietf.org; Wed, 04 Feb 2009 17:25:48 +0800 (CST) Date: Wed, 04 Feb 2009 14:55:43 +0530 From: avinashkoneru To: sip@ietf.org Message-id: <000501c986aa$8e3c5250$5811120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_GobjIyDzy9JA7q6jNVbWxw)" Thread-index: AcmGqo22aXeNPy6DRlGBRJ9ypL7hJQ== Subject: [Sip] How do we adress this SDP issue in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: avinashkoneru@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 11:28:18 -0000 This is a multi-part message in MIME format. --Boundary_(ID_GobjIyDzy9JA7q6jNVbWxw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT To SIP & SDP experts, Iam having some doubts in RFC4566 (i.e SDP)could you please explain them briefly RFC 4566 PAGE 14 Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. As per my understanding the above line says that (Trade off between bandwidth and quality ) Ex : I have a media file of 1 GB size .If I use layered encoding that 1 GB media file could be made into 700k size with some loss of date or 500k size or 1GB only as per users choice? Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning How would I know which layer is mapped to which multicast address (and size of each layer)?.. I think this issue is addressed by the protocol above SDP (i.e in SIP or SAP)?.. Could anyone plz let me know .How and where this issue is addressed Thanks and Regards, Avinash Koneru **************************************************************************** *********** 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_GobjIyDzy9JA7q6jNVbWxw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

To SIP & SDP = experts,

 

         =             &= nbsp;         Iam having some doubts in RFC4566 (i.e SDP)could you please explain them briefly

 

RFC 4566 PAGE 14

 

Hierarchical or layered encoding schemes are data streams where the encoding from a = single media source is split into a number of = layers.

 

As per = my understanding the above line says that  (Trade off between = bandwidth and quality )

Ex : I = have a media file of 1 GB size .If I use layered encoding that 1 GB media file = could be made into 700k size with some loss of date  or 500k  size = or 1GB only as per users choice?

 

Such = layered encodings are normally transmitted in multiple multicast groups to allow = multicast pruning

 

How = would I know which layer is mapped to which multicast address (and size of each = layer)?..

 

I think = this issue is addressed by the protocol above SDP (i.e in SIP or SAP)?.. = Could  anyone plz let me know .How and where this issue is addressed =

 

 

 

Thanks = and Regards,

Avinash = Koneru

 

 

 

******************************************************= *********************************
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_GobjIyDzy9JA7q6jNVbWxw)-- From ron.even.tlv@gmail.com Wed Feb 4 05:19:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEED728C236 for ; Wed, 4 Feb 2009 05:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+9QzNLIpy9W for ; Wed, 4 Feb 2009 05:19:36 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 1638D28C114 for ; Wed, 4 Feb 2009 05:19:35 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so1202838fgb.41 for ; Wed, 04 Feb 2009 05:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=YARRoMSM2VrvMHEbyYXwW9ZmNg4b/XifImhXqwZZucg=; b=NDvRT0yQj+q2p7yQPH4AcwFDIUTpO9ZjM4+tKM6VLmGWh+mDJ3GZDOL3HgmRmK7bvK 3uoYWMExDzQ9fj8ytW5nUQ2kLrxZ96RFmbt/uFT1e0yDADdY+PgpV/+dSnuOFbb9SnXb Wl1P9OvOClhyGW721joaoKnNcnIszXhJBZGLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=YTw5ukm6aVjMMDKH7yMUX1DtMja44HngrIzoSfEbn+aBAZUS+Pd1M9kBD0ylqShHgc 0fQ5OdxB1f1E7lIK9u8vLEY7CfJvccxFxC4vWru04ZS1QYe7lYa8cEIqbYkYZHEkE0wy uXoNrzucUe4CJhqDeBNMMf29NHLrnCwPas2E4= Received: by 10.86.74.4 with SMTP id w4mr1241721fga.2.1233753555611; Wed, 04 Feb 2009 05:19:15 -0800 (PST) Received: from windows8d787f9 (bzq-82-81-3-198.red.bezeqint.net [82.81.3.198]) by mx.google.com with ESMTPS id e20sm1268433fga.16.2009.02.04.05.19.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Feb 2009 05:19:15 -0800 (PST) From: "Roni Even" To: , References: <000501c986aa$8e3c5250$5811120a@china.huawei.com> In-Reply-To: <000501c986aa$8e3c5250$5811120a@china.huawei.com> Date: Wed, 4 Feb 2009 15:17:37 +0200 Message-ID: <498995d3.1438560a.5379.fffff0e6@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C986DB.BC15E0C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmGqo22aXeNPy6DRlGBRJ9ypL7hJQAH+4tg Content-Language: en-us Subject: Re: [Sip] How do we adress this SDP issue in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 13:19:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0025_01C986DB.BC15E0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, You can start by looking at http://tools.ietf.org/html/draft-ietf-mmusic-decoding-dependency-05 As for the layer description you can also look at the draft-ietf-avt-rtp-svc. Roni Even From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of avinashkoneru Sent: Wednesday, February 04, 2009 11:26 AM To: sip@ietf.org Subject: [Sip] How do we adress this SDP issue in SIP To SIP & SDP experts, Iam having some doubts in RFC4566 (i.e SDP)could you please explain them briefly RFC 4566 PAGE 14 Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. As per my understanding the above line says that (Trade off between bandwidth and quality ) Ex : I have a media file of 1 GB size .If I use layered encoding that 1 GB media file could be made into 700k size with some loss of date or 500k size or 1GB only as per users choice? Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning How would I know which layer is mapped to which multicast address (and size of each layer)?.. I think this issue is addressed by the protocol above SDP (i.e in SIP or SAP)?.. Could anyone plz let me know .How and where this issue is addressed Thanks and Regards, Avinash Koneru **************************************************************************** *********** 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! ------=_NextPart_000_0025_01C986DB.BC15E0C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

You can start by looking at http://tools.ietf.org/html/draft-ietf-mmusic-decoding-dependency-05

As for the layer description you can also look at the draft-ietf-avt-rtp-svc.

 

Roni Even

 

From:= sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = avinashkoneru
Sent: Wednesday, February 04, 2009 11:26 AM
To: sip@ietf.org
Subject: [Sip] How do we adress this SDP issue in = SIP

 

To SIP & SDP experts,

 

  &= nbsp;           &n= bsp;           &nb= sp;    Iam having some doubts in RFC4566 (i.e SDP)could you please explain them = briefly

 

RFC 4566 PAGE 14

 

Hierarchical or layered encoding schemes are data streams = where the encoding from a single media source is split into a number of = layers.

 

As per my understanding the above line says that  = (Trade off between bandwidth and quality )

Ex : I have a media file of 1 GB size .If I use layered = encoding that 1 GB media file could be made into 700k size with some loss of date  or 500k  size or 1GB only as per users choice? =

 

Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning

 

How would I know which layer is mapped to which multicast = address (and size of each layer)?..

 

I think this issue is addressed by the protocol above SDP = (i.e in SIP or SAP)?.. Could  anyone plz let me know .How and where this = issue is addressed

 

 

 

Thanks and Regards,

Avinash Koneru

 

 

 

*************= *************************************************************************= *
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!

 

------=_NextPart_000_0025_01C986DB.BC15E0C0-- From john.elwell@siemens.com Wed Feb 4 08:34:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A595628C141 for ; Wed, 4 Feb 2009 08:34:10 -0800 (PST) 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.065, 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 Tq4ypy3UAcw3 for ; Wed, 4 Feb 2009 08:34:09 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id A523F3A6C76 for ; Wed, 4 Feb 2009 08:34:09 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEJ00B48VA1CU@siemenscomms.co.uk> for sip@ietf.org; Wed, 04 Feb 2009 16:32:25 +0000 (GMT) Date: Wed, 04 Feb 2009 16:31:25 +0000 From: "Elwell, John" To: sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Question on loop detection Thread-Index: AcmG5gWuIX+s+DYpTzuEJJuxUjV2FQ== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "Armenio, Joao" Subject: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 16:34:10 -0000 Apologies if this has been discussed in the past. Consider a domain proxy that is configured to parallel fork an INVITE request to two targets. As a result it would forward the INVITE request twice, and as far as I can see the two forwarded requests would in general differ only in the following respects: - different Request-URIs (the respective contact URIs); - different top Via header field entries (different branch parameters); - if applicable, different History-Info header field values. =20 Supposing the two new targets are both reachable via the same edge "proxy", which is actually implemented as a B2BUA (e.g., an SBC). The edge B2BUA would receive one request and shortly afterwards would receive the other request. The similarity and differences between the two requests are such that, in accordance with RFC 3261, the second request would be treated by the B2BUA (acting as a UAS) as a loop and be rejected with 482, assuming it arrives within a given time period. For TCP transport the second INVITE request would need to arrive before the ACK relating to the first INVITE request, but for UDP transport the window is extended by T4 seconds. The text concerned in RFC 3261 is in 8.2.2.2: "If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction." in 17.2.3: "The INVITE request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq, and top Via header field match those of the INVITE request which created the transaction. In this case, the INVITE is a retransmission of the original one that created the transaction." and in 17.1.2.2: "Once the client transaction enters the "Completed" state, it MUST set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. The "Completed" state exists to buffer any additional response retransmissions that may be received (which is why the client transaction remains there only for unreliable transports). T4 represents the amount of time the network will take to clear messages between client and server transactions. The default value of T4 is 5s." Questions: Has this problem has been seen in practice? If so, what steps have been taken to overcome it? If not, have I misinterpreted RFC 3261? John From theo@crazygreek.co.uk Wed Feb 4 09:00:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4E528C146 for ; Wed, 4 Feb 2009 09:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Q4+eoeVXv4kg for ; Wed, 4 Feb 2009 09:00:43 -0800 (PST) Received: from chip3og57.obsmtp.com (chip3og57.obsmtp.com [64.18.14.179]) by core3.amsl.com (Postfix) with SMTP id 5438F28C0FE for ; Wed, 4 Feb 2009 09:00:43 -0800 (PST) Received: from source ([209.85.219.21]) by chip3ob57.postini.com ([64.18.6.12]) with SMTP ID DSNKSYnJpzlcCsIukeOoUN0d8ULoNsyqq5Ox@postini.com; Wed, 04 Feb 2009 09:00:24 PST Received: by mail-ew0-f21.google.com with SMTP id 14so3576586ewy.13 for ; Wed, 04 Feb 2009 09:00:23 -0800 (PST) MIME-Version: 1.0 Sender: theo@crazygreek.co.uk Received: by 10.86.60.14 with SMTP id i14mr2992430fga.21.1233766823470; Wed, 04 Feb 2009 09:00:23 -0800 (PST) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 4 Feb 2009 17:00:23 +0000 X-Google-Sender-Auth: 9d92271a3d0f6a58 Message-ID: <167dfb9b0902040900t145c941bwac13e74731cdacaf@mail.gmail.com> From: Theo Zourzouvillys To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:00:45 -0000 On Wed, Feb 4, 2009 at 4:31 PM, Elwell, John wrote: > Questions: Has this problem has been seen in practice? If so, what steps > have been taken to overcome it? If not, have I misinterpreted RFC 3261? The behaviour as you described it is correct when the SBC device is a B2BUA with a single UA core for all sessions flowing through it, which it isn't - or at least probably isn't what you want. if instead you considered an SBC to have multiple logical UA cores, one for each target that it's currently being an SBC for, then that behaviour would be incorrect (as matching would be done by comparing all other ongoing transactions within the same UAS core), and both calls would flow through correctly. this is how we have had our SBC behaving for the last 3 years without problem [1]. ~ Theo 1 - standard SBCs don't exist and it's all in our heads disclaimer applies :) -- Theo Zourzouvillys Chief Technical Officer VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD Tel: +44 1908 764 196 From john.elwell@siemens.com Wed Feb 4 09:24:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC943A6B7F for ; Wed, 4 Feb 2009 09:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 8DxKjYxJTvzN for ; Wed, 4 Feb 2009 09:24:58 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id F0DC23A6C6B for ; Wed, 4 Feb 2009 09:24:57 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEJ00E2CXP0EF@siemenscomms.co.uk> for sip@ietf.org; Wed, 04 Feb 2009 17:24:38 +0000 (GMT) Date: Wed, 04 Feb 2009 17:24:30 +0000 From: "Elwell, John" In-reply-to: <167dfb9b0902040900t145c941bwac13e74731cdacaf@mail.gmail.com> To: Theo Zourzouvillys Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0017FBA0D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Question on loop detection Thread-Index: AcmG6hOTrf4sjwd2TnO1KUHHm4rp1wAArtZw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> <167dfb9b0902040900t145c941bwac13e74731cdacaf@mail.gmail.com> Cc: sip@ietf.org, "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 17:24:58 -0000 Theo, Thanks. That is indeed one solution, but I am not sure all B2BUAs deployable in such situations behave in this way, so I would welcome other opinions. John > -----Original Message----- > From: theo@crazygreek.co.uk [mailto:theo@crazygreek.co.uk] On=20 > Behalf Of Theo Zourzouvillys > Sent: 04 February 2009 17:00 > To: Elwell, John > Cc: sip@ietf.org; Armenio, Joao > Subject: Re: [Sip] Question on loop detection >=20 > On Wed, Feb 4, 2009 at 4:31 PM, Elwell, John=20 > wrote: >=20 > > Questions: Has this problem has been seen in practice? If=20 > so, what steps > > have been taken to overcome it? If not, have I=20 > misinterpreted RFC 3261? >=20 > The behaviour as you described it is correct when the SBC device is a > B2BUA with a single UA core for all sessions flowing through it, which > it isn't - or at least probably isn't what you want. >=20 > if instead you considered an SBC to have multiple logical UA cores, > one for each target that it's currently being an SBC for, then that > behaviour would be incorrect (as matching would be done by comparing > all other ongoing transactions within the same UAS core), and both > calls would flow through correctly. >=20 > this is how we have had our SBC behaving for the last 3 years without > problem [1]. >=20 > ~ Theo >=20 > 1 - standard SBCs don't exist and it's all in our heads=20 > disclaimer applies :) >=20 > --=20 > Theo Zourzouvillys > Chief Technical Officer > VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD > Tel: +44 1908 764 196 >=20 From dworley@nortel.com Wed Feb 4 10:59:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9E03A6A3D for ; Wed, 4 Feb 2009 10:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Oe8yTVFrVGjn for ; Wed, 4 Feb 2009 10:59:35 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9E87F3A6954 for ; Wed, 4 Feb 2009 10:59:35 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n14Ix7K25748; Wed, 4 Feb 2009 18:59:07 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 13:59:07 -0500 From: "Dale Worley" To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0017FBA0D@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> <167dfb9b0902040900t145c941bwac13e74731cdacaf@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0017FBA0D@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 04 Feb 2009 13:59:07 -0500 Message-Id: <1233773947.4934.11.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2009 18:59:07.0812 (UTC) FILETIME=[A82B3640:01C986FA] Cc: sip@ietf.org, Theo Zourzouvillys , "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:59:36 -0000 On Wed, 2009-02-04 at 17:24 +0000, Elwell, John wrote: > Thanks. That is indeed one solution, but I am not sure all B2BUAs > deployable in such situations behave in this way, so I would welcome > other opinions. I agree with Theo in results, though I'd phrase the answer differently -- In this case, the SBC is acting as a pseudo-proxy, and so its loop detection behavior must be different from what a true UAS would do; it should be detecting loops in the same way that a proxy would. Otherwise you would get the functional problem that you describe. Dale From rjsparks@nostrum.com Wed Feb 4 14:08:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCAE028C12A for ; Wed, 4 Feb 2009 14:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYyH-Hd+BjDd for ; Wed, 4 Feb 2009 14:08:20 -0800 (PST) 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 87C863A68D7 for ; Wed, 4 Feb 2009 14:08:19 -0800 (PST) Received: from [67.134.36.165] ([67.134.36.165]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n14M7ujF037931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Feb 2009 16:07:57 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> From: Robert Sparks To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Feb 2009 16:07:56 -0600 References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 67.134.36.165 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/8950/Wed Feb 4 05:19:05 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip@ietf.org, "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 22:08:20 -0000 You are describing a merge, not a loop, and as Dale pointed out, if the B2BUA is playing the role of a proxy, it shouldn't merge detect. If it's being more than a proxy, then it needs to choose one and reject the other with the same kind of local-policy logic an actual endpoint would use. RjS On Feb 4, 2009, at 10:31 AM, Elwell, John wrote: > Apologies if this has been discussed in the past. > > Consider a domain proxy that is configured to parallel fork an INVITE > request to two targets. As a result it would forward the INVITE > request > twice, and as far as I can see the two forwarded requests would in > general differ only in the following respects: > - different Request-URIs (the respective contact URIs); > - different top Via header field entries (different branch > parameters); > - if applicable, different History-Info header field values. > > Supposing the two new targets are both reachable via the same edge > "proxy", which is actually implemented as a B2BUA (e.g., an SBC). The > edge B2BUA would receive one request and shortly afterwards would > receive the other request. The similarity and differences between the > two requests are such that, in accordance with RFC 3261, the second > request would be treated by the B2BUA (acting as a UAS) as a loop > and be > rejected with 482, assuming it arrives within a given time period. For > TCP transport the second INVITE request would need to arrive before > the > ACK relating to the first INVITE request, but for UDP transport the > window is extended by T4 seconds. > > The text concerned in RFC 3261 is in 8.2.2.2: > "If the request has no tag in the To header field, the UAS core MUST > check the request against ongoing transactions. If the From tag, > Call-ID, and CSeq exactly match those associated with an ongoing > transaction, but the request does not match that transaction (based > on the matching rules in Section 17.2.3), the UAS core SHOULD > generate a 482 (Loop Detected) response and pass it to the server > transaction." > in 17.2.3: > "The INVITE request matches a transaction if the Request-URI, To tag, > From tag, Call-ID, CSeq, and top Via header field match those of the > INVITE request which created the transaction. In this case, the > INVITE is a retransmission of the original one that created the > transaction." > and in 17.1.2.2: > "Once the client transaction enters the "Completed" state, it MUST set > Timer K to fire in T4 seconds for unreliable transports, and zero > seconds for reliable transports. The "Completed" state exists to > buffer any additional response retransmissions that may be received > (which is why the client transaction remains there only for > unreliable transports). T4 represents the amount of time the > network > will take to clear messages between client and server transactions. > The default value of T4 is 5s." > > Questions: Has this problem has been seen in practice? If so, what > steps > have been taken to overcome it? If not, have I misinterpreted RFC > 3261? > > John > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From rfc-editor@rfc-editor.org Wed Feb 4 15:34:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A086C28C16B; Wed, 4 Feb 2009 15:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.814 X-Spam-Level: X-Spam-Status: No, score=-16.814 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhVhGkO9zVxD; Wed, 4 Feb 2009 15:34:28 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 9EA3D28C11B; Wed, 4 Feb 2009 15:34:28 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 75E6420ADB0; Wed, 4 Feb 2009 15:34:09 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090204233409.75E6420ADB0@bosco.isi.edu> Date: Wed, 4 Feb 2009 15:34:09 -0800 (PST) Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 5411 on A Hitchhiker's Guide to the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 23:34:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5411 Title: A Hitchhiker's Guide to the Session Initiation Protocol (SIP) Author: J. Rosenberg Status: Informational Date: February 2009 Mailbox: jdrosen@cisco.com Pages: 39 Characters: 96538 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-hitchhikers-guide-06.txt URL: http://www.rfc-editor.org/rfc/rfc5411.txt The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. This memo provides information for the Internet community. This document is a product of the Session Initiation Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 USC/Information Sciences Institute From abhatnagar192006@gmail.com Wed Feb 4 19:44:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCA83A68E1 for ; Wed, 4 Feb 2009 19:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 5FvyQ2reWJUo for ; Wed, 4 Feb 2009 19:44:05 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by core3.amsl.com (Postfix) with ESMTP id 106953A6858 for ; Wed, 4 Feb 2009 19:44:04 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so3031nfh.39 for ; Wed, 04 Feb 2009 19:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WdXohOWXb5SvtgDYBcsDZDElm1+oA/5YvF9Mgv4cl1c=; b=AQ1zIG2Dn01HJKm9KRozi0AAdtYO2wTo++W/2nP1vr0rlHLAURpfS9+Iny8OFOmDnJ O/FhhCiaI3DrtCXlIvX7yvm3DWfu2HkKw0WvxuWRkuuzRSD5g+qfrwOa/z0EaF30Wd+h AR58hyrXh1Cn+bJe7fzqdfTn/oUg2jpnqKeiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gPWzmdf4x6da76Pi0xlHiMDHalT4Tliyr3Ddd8aqjDJkfvsInSVhZeg8qDER+GfKgj 2Oy/s9q7R3lmIL7dCecmmF1CpURoeJB+/8N/4VRhvFUa6mTsR7X10VcTAo9YWvdwE06U 1JH6BNDTkSkZa/t1ILTrdzwzdky37fGj/fX7I= MIME-Version: 1.0 Received: by 10.210.65.15 with SMTP id n15mr7449820eba.123.1233805423929; Wed, 04 Feb 2009 19:43:43 -0800 (PST) In-Reply-To: <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> Date: Thu, 5 Feb 2009 03:43:43 +0000 Message-ID: From: aayush bhatnagar To: Robert Sparks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "Elwell, John" , "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 03:44:06 -0000 I dont think the SBC will detect a loop. As per the RFC text above, a loop situation will occur, only when the request does not match an ongoing transaction at the UAS(as per the rules mentioned above), but the call id, from tag and cseq match that of an ''ongoing'' transaction.. This situation will not arise in a parallel forking case, as each forked branch creates a unique transaction of its own (and hence a unique from tag). i have a doubt on why a SBC should behave as a B2BUA? Should it not behave as a proxy server between 2 sip domains? aayush. On 2/4/09, Robert Sparks wrote: > You are describing a merge, not a loop, and as Dale pointed out, if > the B2BUA is > playing the role of a proxy, it shouldn't merge detect. If it's being > more than a proxy, > then it needs to choose one and reject the other with the same kind of > local-policy > logic an actual endpoint would use. > > RjS > > > On Feb 4, 2009, at 10:31 AM, Elwell, John wrote: > >> Apologies if this has been discussed in the past. >> >> Consider a domain proxy that is configured to parallel fork an INVITE >> request to two targets. As a result it would forward the INVITE >> request >> twice, and as far as I can see the two forwarded requests would in >> general differ only in the following respects: >> - different Request-URIs (the respective contact URIs); >> - different top Via header field entries (different branch >> parameters); >> - if applicable, different History-Info header field values. >> >> Supposing the two new targets are both reachable via the same edge >> "proxy", which is actually implemented as a B2BUA (e.g., an SBC). The >> edge B2BUA would receive one request and shortly afterwards would >> receive the other request. The similarity and differences between the >> two requests are such that, in accordance with RFC 3261, the second >> request would be treated by the B2BUA (acting as a UAS) as a loop >> and be >> rejected with 482, assuming it arrives within a given time period. For >> TCP transport the second INVITE request would need to arrive before >> the >> ACK relating to the first INVITE request, but for UDP transport the >> window is extended by T4 seconds. >> >> The text concerned in RFC 3261 is in 8.2.2.2: >> "If the request has no tag in the To header field, the UAS core MUST >> check the request against ongoing transactions. If the From tag, >> Call-ID, and CSeq exactly match those associated with an ongoing >> transaction, but the request does not match that transaction (based >> on the matching rules in Section 17.2.3), the UAS core SHOULD >> generate a 482 (Loop Detected) response and pass it to the server >> transaction." >> in 17.2.3: >> "The INVITE request matches a transaction if the Request-URI, To tag, >> From tag, Call-ID, CSeq, and top Via header field match those of the >> INVITE request which created the transaction. In this case, the >> INVITE is a retransmission of the original one that created the >> transaction." >> and in 17.1.2.2: >> "Once the client transaction enters the "Completed" state, it MUST set >> Timer K to fire in T4 seconds for unreliable transports, and zero >> seconds for reliable transports. The "Completed" state exists to >> buffer any additional response retransmissions that may be received >> (which is why the client transaction remains there only for >> unreliable transports). T4 represents the amount of time the >> network >> will take to clear messages between client and server transactions. >> The default value of T4 is 5s." >> >> Questions: Has this problem has been seen in practice? If so, what >> steps >> have been taken to overcome it? If not, have I misinterpreted RFC >> 3261? >> >> John >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From root@core3.amsl.com Wed Feb 4 22:45:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 94B383A6B9E; Wed, 4 Feb 2009 22:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090205064501.94B383A6B9E@core3.amsl.com> Date: Wed, 4 Feb 2009 22:45:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-ua-privacy-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 06:45:01 -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 Working Group of the IETF. Title : UA-Driven Privacy Mechanism for SIP Author(s) : M. Munakata, et al. Filename : draft-ietf-sip-ua-privacy-04.txt Pages : 11 Date : 2009-02-04 This document defines a best current practice for a user agent to generate an anonymous SIP message by utilizing mechanisms such as GRUU (Globally Routable User Agent URIs) and TURN (Traversal Using Relays around NAT) without the need for a privacy service defined in RFC 3323. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-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-sip-ua-privacy-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-04223752.I-D@ietf.org> --NextPart-- From john.elwell@siemens.com Thu Feb 5 05:20:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5B63A6909 for ; Thu, 5 Feb 2009 05:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 FDoCYuc+fuHs for ; Thu, 5 Feb 2009 05:20:16 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 756AD3A6940 for ; Thu, 5 Feb 2009 05:20:15 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEL00FARH17PG@siemenscomms.co.uk> for sip@ietf.org; Thu, 05 Feb 2009 13:19:55 +0000 (GMT) Date: Thu, 05 Feb 2009 13:19:54 +0000 From: "Elwell, John" To: Mayumi Munakata , Shida Schubert , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00182CF0E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/mixed; boundary="----_=_NextPart_001_01C98794.6EEB04BA" Thread-Topic: Nits in draft-ietf-sip-ua-privacy-04 thread-index: AcmHhEj15RKXzbtpQMGqmmExzuu7lA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] Nits in draft-ietf-sip-ua-privacy-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 13:20:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98794.6EEB04BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mayumi, I note that my previous comments of substance have all been taken into account. However, nits that I sent to you privately (see attached email) have not been into account. In addition I have detected a further nit: In section 5.1.1 it says: "...and refer to Section 4.2 for details on how to obtain an IP address through TURN." Since IP addresses are not mentioned in the rest of 5.1.1, this seems irrelevant. The words should be deleted. When these nits have been fixed, in my opinion the document will be ready to go. John ------_=_NextPart_001_01C98794.6EEB04BA Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Nits in draft-ietf-sip-ua-privacy-03 Date: Tue, 11 Nov 2008 14:35:25 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nits in draft-ietf-sip-ua-privacy-03 thread-index: AclECrwMmlFdoxpmTLWuWk9B9Oiw1w== From: "Elwell, John" To: "Mayumi Munakata" , "Shida Schubert" Mayumi, Shida, I am sending you nits separately. My main comments have been posted to the SIP list. 1. "by allowing user agent to take control of its privacy, rather than being completely dependent on external privacy service." Change to "by allowing a user agent to ^^ take control of its privacy, rather than being completely dependent on an external privacy service." ^^^ 2. "If revealing the domain name in Contact header field " Change to: "If revealing the domain name in the Contact ^^^^ header field " 3. "A user agent that is not provided with a functional anonymous IP address through some administrative means, MUST obtain a relayed address if anonymity is desired (IP address of the media relay) for use in SDP and in Via header. Such IP address is to be derived from a STUN relay server through TURN mechanism, which allows a STUN server to act as a media relay." Change to: "A user agent that is not provided with a functional anonymous IP address through some administrative means MUST obtain a relayed address (IP address of a relay) if anonymity is desired for use in SDP and in the Via header field. Such an IP address is to be derived from a STUN relay server through the TURN mechanism, which allows a STUN server to act as a relay." (Various changes, including deletion of "media", since the relay is also used for Via (signalling)). 4. "A user agent SHOULD go with option 1 to conceal its domain name in From header field." Insert "the" in front of "From". 5. "If user wants both anonymity and strong identity, use a third party anonymization service which issues AoR for the use in From address which also provides SIP-Identity." Various changes: "If the user wants both anonymity and strong identity, a solution would be to use a third party anonymization service that issues an Address of Record (AoR) for use in the From header field of a request and that also provides a SIP-Identity Authentication Service." 6. "Without privacy considerations, the bottommost Via header field added by a user agent" Add "to a request". 7. "Via header SHOULD NOT include a host name." Change to: "The Via header field SHOULD NOT include a host name." 8. "Furthermore, if the provider of the caller intending to obscure its identity consists of a small number of people (e.g. small enterprise, SOHO), the domain name alone can reveal the identity of the caller when this specification is used." Delete "when this specification is used". It is irrelevant whether this specification is used - the domain name can in any case reveal information. 9. "Same can be true when the provider is large, but the receiver of the call only knows few people from the source of call." Change to: "The same can be true when the provider is large but the receiver of the ^^^^^ ^ (delete commma) call only knows a few people from the source of call." ^^ 10. "The domain name in From header can be obscured as described in section 5.1.2, on contrary the Contact header needs to contain a valid domain name at all time to function properly." Change to: "The domain name in the From header field can be obscured as described in section 5.1.2, whereas the Contact header field needs to contain a valid domain name at all times in order to function properly." 11. "If one wants to assure anonymization, it is recommended for the user to seek and rely on third party anonymization service." Change "third" to "a third". 12. "A third party anonymization service provides registrar and TURN service which has no affiliation with the caller's provider, allowing caller to completely withhold its identity." Change to: "A third party anonymization service provides registrar and TURN services that have no affiliation with the caller's provider, allowing the caller to completely withhold its identity." There are still several places where "header" is used instead of "header field". A SIP message, like an HTTP message, has only one header yet many header fields. Regards, John ------_=_NextPart_001_01C98794.6EEB04BA-- From john.elwell@siemens.com Thu Feb 5 05:20:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1940F3A6940 for ; Thu, 5 Feb 2009 05:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 mGWR-xhYfTwL for ; Thu, 5 Feb 2009 05:20:17 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id F073C3A6AF0 for ; Thu, 5 Feb 2009 05:20:16 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEL00FB0H18PG@siemenscomms.co.uk> for sip@ietf.org; Thu, 05 Feb 2009 13:19:56 +0000 (GMT) Date: Thu, 05 Feb 2009 13:19:54 +0000 From: "Elwell, John" In-reply-to: To: aayush bhatnagar , Robert Sparks Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00182CF0F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Question on loop detection thread-index: AcmHQ/SbOOD+2v8TTNO8GsOE/m1bowARA+rw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> Cc: sip@ietf.org, "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 13:20:18 -0000 Aayush,=20 > -----Original Message----- > From: aayush bhatnagar [mailto:abhatnagar192006@gmail.com]=20 > Sent: 05 February 2009 03:44 > To: Robert Sparks > Cc: Elwell, John; sip@ietf.org; Armenio, Joao > Subject: Re: [Sip] Question on loop detection >=20 > I dont think the SBC will detect a loop. As per the RFC text above, a > loop situation will occur, only when the request does not match an > ongoing transaction at the UAS(as per the rules mentioned above), but > the call id, from tag and cseq match that of an ''ongoing'' > transaction.. > This situation will not arise in a parallel forking case, as each > forked branch creates a unique transaction of its own (and hence a > unique from tag). [JRE] If an upstream proxy has forked, each branch will have the same >From tag. >=20 > i have a doubt on why a SBC should behave as a B2BUA? Should it not > behave as a proxy server between 2 sip domains? [JRE] I believe in practice SBCs do behave as B2BUAs, but perhaps not in this respect. Behaving as proxies in this respect would indeed solve this problem. The reason for my original question is that I am aware of a device that is a UAS and sends 482 when it ought not to, although according to RFC 3261 it is correct in doing so. By behaving as several UASs rather than a single UAS, it would avoid the problem. But that made me question whether the problem would also arise in other situations, e.g., with B2BUAs such as SBCs. The answers I received to date suggest that proxy behaviour in this respect would get round the problem, so perhaps that is how such devices work in practice. John >=20 > aayush. >=20 > On 2/4/09, Robert Sparks wrote: > > You are describing a merge, not a loop, and as Dale pointed out, if > > the B2BUA is > > playing the role of a proxy, it shouldn't merge detect. If=20 > it's being > > more than a proxy, > > then it needs to choose one and reject the other with the=20 > same kind of > > local-policy > > logic an actual endpoint would use. > > > > RjS > > > > > > On Feb 4, 2009, at 10:31 AM, Elwell, John wrote: > > > >> Apologies if this has been discussed in the past. > >> > >> Consider a domain proxy that is configured to parallel=20 > fork an INVITE > >> request to two targets. As a result it would forward the INVITE > >> request > >> twice, and as far as I can see the two forwarded requests would in > >> general differ only in the following respects: > >> - different Request-URIs (the respective contact URIs); > >> - different top Via header field entries (different branch > >> parameters); > >> - if applicable, different History-Info header field values. > >> > >> Supposing the two new targets are both reachable via the same edge > >> "proxy", which is actually implemented as a B2BUA (e.g.,=20 > an SBC). The > >> edge B2BUA would receive one request and shortly afterwards would > >> receive the other request. The similarity and differences=20 > between the > >> two requests are such that, in accordance with RFC 3261, the second > >> request would be treated by the B2BUA (acting as a UAS) as a loop > >> and be > >> rejected with 482, assuming it arrives within a given time=20 > period. For > >> TCP transport the second INVITE request would need to arrive before > >> the > >> ACK relating to the first INVITE request, but for UDP transport the > >> window is extended by T4 seconds. > >> > >> The text concerned in RFC 3261 is in 8.2.2.2: > >> "If the request has no tag in the To header field, the UAS=20 > core MUST > >> check the request against ongoing transactions. If the From tag, > >> Call-ID, and CSeq exactly match those associated with an ongoing > >> transaction, but the request does not match that=20 > transaction (based > >> on the matching rules in Section 17.2.3), the UAS core SHOULD > >> generate a 482 (Loop Detected) response and pass it to the server > >> transaction." > >> in 17.2.3: > >> "The INVITE request matches a transaction if the=20 > Request-URI, To tag, > >> From tag, Call-ID, CSeq, and top Via header field match=20 > those of the > >> INVITE request which created the transaction. In this case, the > >> INVITE is a retransmission of the original one that created the > >> transaction." > >> and in 17.1.2.2: > >> "Once the client transaction enters the "Completed" state,=20 > it MUST set > >> Timer K to fire in T4 seconds for unreliable transports, and zero > >> seconds for reliable transports. The "Completed" state exists to > >> buffer any additional response retransmissions that may=20 > be received > >> (which is why the client transaction remains there only for > >> unreliable transports). T4 represents the amount of time the > >> network > >> will take to clear messages between client and server=20 > transactions. > >> The default value of T4 is 5s." > >> > >> Questions: Has this problem has been seen in practice? If so, what > >> steps > >> have been taken to overcome it? If not, have I misinterpreted RFC > >> 3261? > >> > >> John > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 From john.elwell@siemens.com Thu Feb 5 06:03:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31733A6927 for ; Thu, 5 Feb 2009 06:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ThS2ICFmjiSD for ; Thu, 5 Feb 2009 06:03:53 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B33DC3A6A84 for ; Thu, 5 Feb 2009 06:03:53 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEL00ID7J1W2O@siemenscomms.co.uk> for sip@ietf.org; Thu, 05 Feb 2009 14:03:32 +0000 (GMT) Date: Thu, 05 Feb 2009 14:03:30 +0000 From: "Elwell, John" In-reply-to: <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> To: Robert Sparks Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00182CF72@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Question on loop detection thread-index: AcmHFQ0ldqL3LvzjSpyRuRk5zBxALAAcs/iQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> Cc: sip@ietf.org, "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:03:54 -0000 Robert, It is true this is a merge rather than a loop situation, but the conditions I describe are conditions for sending a 482 "loop detected". John=20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: 04 February 2009 22:08 > To: Elwell, John > Cc: sip@ietf.org; Armenio, Joao > Subject: Re: [Sip] Question on loop detection >=20 > You are describing a merge, not a loop, and as Dale pointed out, if =20 > the B2BUA is > playing the role of a proxy, it shouldn't merge detect. If=20 > it's being =20 > more than a proxy, > then it needs to choose one and reject the other with the=20 > same kind of =20 > local-policy > logic an actual endpoint would use. >=20 > RjS >=20 >=20 > On Feb 4, 2009, at 10:31 AM, Elwell, John wrote: >=20 > > Apologies if this has been discussed in the past. > > > > Consider a domain proxy that is configured to parallel fork=20 > an INVITE > > request to two targets. As a result it would forward the INVITE =20 > > request > > twice, and as far as I can see the two forwarded requests would in > > general differ only in the following respects: > > - different Request-URIs (the respective contact URIs); > > - different top Via header field entries (different branch =20 > > parameters); > > - if applicable, different History-Info header field values. > > > > Supposing the two new targets are both reachable via the same edge > > "proxy", which is actually implemented as a B2BUA (e.g., an=20 > SBC). The > > edge B2BUA would receive one request and shortly afterwards would > > receive the other request. The similarity and differences=20 > between the > > two requests are such that, in accordance with RFC 3261, the second > > request would be treated by the B2BUA (acting as a UAS) as a loop =20 > > and be > > rejected with 482, assuming it arrives within a given time=20 > period. For > > TCP transport the second INVITE request would need to=20 > arrive before =20 > > the > > ACK relating to the first INVITE request, but for UDP transport the > > window is extended by T4 seconds. > > > > The text concerned in RFC 3261 is in 8.2.2.2: > > "If the request has no tag in the To header field, the UAS core MUST > > check the request against ongoing transactions. If the From tag, > > Call-ID, and CSeq exactly match those associated with an ongoing > > transaction, but the request does not match that=20 > transaction (based > > on the matching rules in Section 17.2.3), the UAS core SHOULD > > generate a 482 (Loop Detected) response and pass it to the server > > transaction." > > in 17.2.3: > > "The INVITE request matches a transaction if the=20 > Request-URI, To tag, > > From tag, Call-ID, CSeq, and top Via header field match=20 > those of the > > INVITE request which created the transaction. In this case, the > > INVITE is a retransmission of the original one that created the > > transaction." > > and in 17.1.2.2: > > "Once the client transaction enters the "Completed" state,=20 > it MUST set > > Timer K to fire in T4 seconds for unreliable transports, and zero > > seconds for reliable transports. The "Completed" state exists to > > buffer any additional response retransmissions that may=20 > be received > > (which is why the client transaction remains there only for > > unreliable transports). T4 represents the amount of time the =20 > > network > > will take to clear messages between client and server=20 > transactions. > > The default value of T4 is 5s." > > > > Questions: Has this problem has been seen in practice? If so, what =20 > > steps > > have been taken to overcome it? If not, have I misinterpreted RFC =20 > > 3261? > > > > John > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 From abhatnagar192006@gmail.com Thu Feb 5 07:45:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC7128C1EE for ; Thu, 5 Feb 2009 07:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=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 Li7Ke3K8CVIX for ; Thu, 5 Feb 2009 07:45:26 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 459EE28C1F9 for ; Thu, 5 Feb 2009 07:45:26 -0800 (PST) Received: by ewy14 with SMTP id 14so460909ewy.13 for ; Thu, 05 Feb 2009 07:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=R+/fuyjX1GE78ckhjJzDvtdV/cT4bc730qYXEj/3kWc=; b=bLuN/Am5O/XEsIBuFhl6mCfwMuW4jrQKf1zj0EbXgl5k70IDXXmbhyyAXaaSVsY96C TjaWVHTq7UEQpUwy7YTVDieNuvqHTXUlG3O0rxu61G6tGfR92NowlLHEfKKfU2noPFej rovdOBUVbtJT6ZEWlU5p7jsZX9Rx/aQVdsr7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OD6DrZk5MToPNdHBqfmz9MVRGpUb1aLDdgRbVeiMsCUPBsd/EfbZiFRmoz/uHKIGcw t9uDdjMH0kHaeCLY2qn/cpYbo/hn3YkWfXFZGQsqzwm4KxQbNZ13th88tPj5fUP2BknU r4Y/uDcQP2nQP6YXI61QdbACEEhkeBpHpvSfc= MIME-Version: 1.0 Received: by 10.210.125.13 with SMTP id x13mr454460ebc.134.1233848704404; Thu, 05 Feb 2009 07:45:04 -0800 (PST) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00182CF72@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D00182CF72@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 5 Feb 2009 21:15:04 +0530 Message-ID: From: aayush bhatnagar To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 15:45:27 -0000 >>[JRE] If an upstream proxy has forked, each branch will have the same >>From tag. True..agreed. Another thing regarding section 17.2.3. The branch parameter will be different for each forked branch, as specified by you inline. However, the transaction matching rules of 17.2.3 you quote inline are applicable only if the branch parameter is absent, or does not have a magic cookie. If you have a magic cookie present, the matching wont fail as per 17.2.3..and subsequently as per 8.2.2.2, there will be no loop detection. I suppose your implementation is not following the magic cookie paradigm? >>[JRE] I believe in practice SBCs do behave as B2BUAs, but perhaps not in >>this respect. Behaving as proxies in this respect would indeed solve >>this problem. Whether the SBC acts as a B2BUA or a proxy also depends on the services that it is offering. If your SBC is handling media, QoS, admission control,call screening and regulatory services such as Lawful Intercept, then it will need to act as a B2BUA. It has no choice. However, if the SBC only needs to provide a point of interconnect between trusted/non-trusted domains, then proxy behavior might be sufficient. On 2/5/09, Elwell, John wrote: > Robert, > > It is true this is a merge rather than a loop situation, but the > conditions I describe are conditions for sending a 482 "loop detected". > > John > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: 04 February 2009 22:08 >> To: Elwell, John >> Cc: sip@ietf.org; Armenio, Joao >> Subject: Re: [Sip] Question on loop detection >> >> You are describing a merge, not a loop, and as Dale pointed out, if >> the B2BUA is >> playing the role of a proxy, it shouldn't merge detect. If >> it's being >> more than a proxy, >> then it needs to choose one and reject the other with the >> same kind of >> local-policy >> logic an actual endpoint would use. >> >> RjS >> >> >> On Feb 4, 2009, at 10:31 AM, Elwell, John wrote: >> >> > Apologies if this has been discussed in the past. >> > >> > Consider a domain proxy that is configured to parallel fork >> an INVITE >> > request to two targets. As a result it would forward the INVITE >> > request >> > twice, and as far as I can see the two forwarded requests would in >> > general differ only in the following respects: >> > - different Request-URIs (the respective contact URIs); >> > - different top Via header field entries (different branch >> > parameters); >> > - if applicable, different History-Info header field values. >> > >> > Supposing the two new targets are both reachable via the same edge >> > "proxy", which is actually implemented as a B2BUA (e.g., an >> SBC). The >> > edge B2BUA would receive one request and shortly afterwards would >> > receive the other request. The similarity and differences >> between the >> > two requests are such that, in accordance with RFC 3261, the second >> > request would be treated by the B2BUA (acting as a UAS) as a loop >> > and be >> > rejected with 482, assuming it arrives within a given time >> period. For >> > TCP transport the second INVITE request would need to >> arrive before >> > the >> > ACK relating to the first INVITE request, but for UDP transport the >> > window is extended by T4 seconds. >> > >> > The text concerned in RFC 3261 is in 8.2.2.2: >> > "If the request has no tag in the To header field, the UAS core MUST >> > check the request against ongoing transactions. If the From tag, >> > Call-ID, and CSeq exactly match those associated with an ongoing >> > transaction, but the request does not match that >> transaction (based >> > on the matching rules in Section 17.2.3), the UAS core SHOULD >> > generate a 482 (Loop Detected) response and pass it to the server >> > transaction." >> > in 17.2.3: >> > "The INVITE request matches a transaction if the >> Request-URI, To tag, >> > From tag, Call-ID, CSeq, and top Via header field match >> those of the >> > INVITE request which created the transaction. In this case, the >> > INVITE is a retransmission of the original one that created the >> > transaction." >> > and in 17.1.2.2: >> > "Once the client transaction enters the "Completed" state, >> it MUST set >> > Timer K to fire in T4 seconds for unreliable transports, and zero >> > seconds for reliable transports. The "Completed" state exists to >> > buffer any additional response retransmissions that may >> be received >> > (which is why the client transaction remains there only for >> > unreliable transports). T4 represents the amount of time the >> > network >> > will take to clear messages between client and server >> transactions. >> > The default value of T4 is 5s." >> > >> > Questions: Has this problem has been seen in practice? If so, what >> > steps >> > have been taken to overcome it? If not, have I misinterpreted RFC >> > 3261? >> > >> > John >> > _______________________________________________ >> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From john.elwell@siemens.com Thu Feb 5 08:48:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F14C3A677E for ; Thu, 5 Feb 2009 08:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_74=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 mXUP5AGwyIto for ; Thu, 5 Feb 2009 08:48:10 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 9EFF13A697A for ; Thu, 5 Feb 2009 08:48:09 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KEL0054NQNMGK@siemenscomms.co.uk> for sip@ietf.org; Thu, 05 Feb 2009 16:47:46 +0000 (GMT) Date: Thu, 05 Feb 2009 16:47:46 +0000 From: "Elwell, John" In-reply-to: To: aayush bhatnagar Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00182D0C9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Question on loop detection thread-index: AcmHqMw9YOWoVYVsRrmgF54X76G+TAABIm7Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D00182CF72@GBNTHT12009MSX.gb002.siemens.net> Cc: sip@ietf.org, "Armenio, Joao" Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 16:48:11 -0000 Aayush,=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of aayush bhatnagar > Sent: 05 February 2009 15:45 > To: Elwell, John > Cc: sip@ietf.org; Armenio, Joao > Subject: Re: [Sip] Question on loop detection >=20 > >>[JRE] If an upstream proxy has forked, each branch will=20 > have the same > >>From tag. >=20 > True..agreed. >=20 > Another thing regarding section 17.2.3. The branch parameter will be > different for each forked branch, as specified by you inline. However, > the transaction matching rules of 17.2.3 you quote inline are > applicable only if the branch parameter is absent, or does not have a > magic cookie. If you have a magic cookie present, the matching wont > fail as per 17.2.3..and subsequently as per 8.2.2.2, there will be no > loop detection. [JRE] Whether or not the branch parameter matches, the Request-URI will not match. So therefore the transactions do not match and the rules for 182 come into play. >=20 > I suppose your implementation is not following the magic=20 > cookie paradigm? >=20 > >>[JRE] I believe in practice SBCs do behave as B2BUAs, but=20 > perhaps not in > >>this respect. Behaving as proxies in this respect would indeed solve > >>this problem. >=20 > Whether the SBC acts as a B2BUA or a proxy also depends on the > services that it is offering. If your SBC is handling media, QoS, > admission control,call screening and regulatory services such as > Lawful Intercept, then it will need to act as a B2BUA. It has no > choice. [JRE] I agree, but it might behave as a proxy with respect to this particular issue. John >=20 > However, if the SBC only needs to provide a point of interconnect > between trusted/non-trusted domains, then proxy behavior might be > sufficient. >=20 > On 2/5/09, Elwell, John wrote: > > Robert, > > > > It is true this is a merge rather than a loop situation, but the > > conditions I describe are conditions for sending a 482=20 > "loop detected". > > > > John > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Sent: 04 February 2009 22:08 > >> To: Elwell, John > >> Cc: sip@ietf.org; Armenio, Joao > >> Subject: Re: [Sip] Question on loop detection > >> > >> You are describing a merge, not a loop, and as Dale pointed out, if > >> the B2BUA is > >> playing the role of a proxy, it shouldn't merge detect. If > >> it's being > >> more than a proxy, > >> then it needs to choose one and reject the other with the > >> same kind of > >> local-policy > >> logic an actual endpoint would use. > >> > >> RjS > >> > >> > >> On Feb 4, 2009, at 10:31 AM, Elwell, John wrote: > >> > >> > Apologies if this has been discussed in the past. > >> > > >> > Consider a domain proxy that is configured to parallel fork > >> an INVITE > >> > request to two targets. As a result it would forward the INVITE > >> > request > >> > twice, and as far as I can see the two forwarded=20 > requests would in > >> > general differ only in the following respects: > >> > - different Request-URIs (the respective contact URIs); > >> > - different top Via header field entries (different branch > >> > parameters); > >> > - if applicable, different History-Info header field values. > >> > > >> > Supposing the two new targets are both reachable via the=20 > same edge > >> > "proxy", which is actually implemented as a B2BUA (e.g., an > >> SBC). The > >> > edge B2BUA would receive one request and shortly afterwards would > >> > receive the other request. The similarity and differences > >> between the > >> > two requests are such that, in accordance with RFC 3261,=20 > the second > >> > request would be treated by the B2BUA (acting as a UAS) as a loop > >> > and be > >> > rejected with 482, assuming it arrives within a given time > >> period. For > >> > TCP transport the second INVITE request would need to > >> arrive before > >> > the > >> > ACK relating to the first INVITE request, but for UDP=20 > transport the > >> > window is extended by T4 seconds. > >> > > >> > The text concerned in RFC 3261 is in 8.2.2.2: > >> > "If the request has no tag in the To header field, the=20 > UAS core MUST > >> > check the request against ongoing transactions. If=20 > the From tag, > >> > Call-ID, and CSeq exactly match those associated with=20 > an ongoing > >> > transaction, but the request does not match that > >> transaction (based > >> > on the matching rules in Section 17.2.3), the UAS core SHOULD > >> > generate a 482 (Loop Detected) response and pass it to=20 > the server > >> > transaction." > >> > in 17.2.3: > >> > "The INVITE request matches a transaction if the > >> Request-URI, To tag, > >> > From tag, Call-ID, CSeq, and top Via header field match > >> those of the > >> > INVITE request which created the transaction. In this=20 > case, the > >> > INVITE is a retransmission of the original one that created the > >> > transaction." > >> > and in 17.1.2.2: > >> > "Once the client transaction enters the "Completed" state, > >> it MUST set > >> > Timer K to fire in T4 seconds for unreliable=20 > transports, and zero > >> > seconds for reliable transports. The "Completed"=20 > state exists to > >> > buffer any additional response retransmissions that may > >> be received > >> > (which is why the client transaction remains there only for > >> > unreliable transports). T4 represents the amount of time the > >> > network > >> > will take to clear messages between client and server > >> transactions. > >> > The default value of T4 is 5s." > >> > > >> > Questions: Has this problem has been seen in practice?=20 > If so, what > >> > steps > >> > have been taken to overcome it? If not, have I misinterpreted RFC > >> > 3261? > >> > > >> > John > >> > _______________________________________________ > >> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> > This list is for NEW development of the core SIP Protocol > >> > Use sip-implementors@cs.columbia.edu for questions on current sip > >> > Use sipping@ietf.org for new developments on the=20 > application of sip > >> > >> > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From dworley@nortel.com Thu Feb 5 12:54:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1EDA28C0F8 for ; Thu, 5 Feb 2009 12:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 L4DwKU6cPnAW for ; Thu, 5 Feb 2009 12:54:49 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 14D3A3A6AB8 for ; Thu, 5 Feb 2009 12:54:49 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n15KskX25861; Thu, 5 Feb 2009 20:54:46 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 15:54:31 -0500 From: "Dale Worley" To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00182CF72@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0017FB96D@GBNTHT12009MSX.gb002.siemens.net> <8CEAB1E3-265E-4C2A-ACA6-1F80DA8CCB30@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D00182CF72@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 05 Feb 2009 15:54:31 -0500 Message-Id: <1233867271.3711.18.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2009 20:54:31.0710 (UTC) FILETIME=[F18BF3E0:01C987D3] Cc: sip@ietf.org Subject: Re: [Sip] Question on loop detection X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 20:54:50 -0000 On Thu, 2009-02-05 at 14:03 +0000, Elwell, John wrote: > It is true this is a merge rather than a loop situation, but the > conditions I describe are conditions for sending a 482 "loop detected". RFC 3261 is correct but not at all clear in this regard. There are *two* error conditions, and RFC 3261 calls both "482 (Loop Detected)". But in reality, there is "482 (Loop Detected)" and "482 (Merged Request)". 482 Merged Request is generated by UASs, as described in section 8.2.2.2, and it is based on noticing that two incoming requests originated as the same UAC request. But the gotcha is that 8.2.2.2 describes UAS behavior, not proxy behavior. 482 Loop Detected is generated by proxies, as described in section 16.3 item 4, and is based on detecting that this request has an "upstream ancestor" request that passed through this same proxy. In regard to a B2BUA acting as an SBC, or a "quasi-proxy" as I like to call it, it needs to apply the loop detection logic, not the merged request logic. Dale From eburger@standardstrack.com Fri Feb 6 10:49:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E6A3A67CC for ; Fri, 6 Feb 2009 10:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCePyhIOvmSx for ; Fri, 6 Feb 2009 10:49:05 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id B13FF3A6B0A for ; Fri, 6 Feb 2009 10:49:02 -0800 (PST) Received: from [75.68.112.157] (port=61833 helo=[192.168.45.106]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LVVl4-0007ew-NN; Fri, 06 Feb 2009 10:49:00 -0800 Message-Id: From: Eric Burger To: Gonzalo Camarillo Content-Type: multipart/signed; boundary=Apple-Mail-200-71625796; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 09:09:39 -0500 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIP List Subject: [Sip] Comments on draft-ietf-sip-body-handling-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 18:49:06 -0000 --Apple-Mail-200-71625796 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Good work and almost done! General ======= Many of the rules for multipart/mumble say things like "all parts must be foo." This construction is not strictly correct. For example, in multipart/alternative, I could have a multipart/mixed. Saying something like "all parts in a multipart/alternative must be marked foo" means that ALL parts, including walking down the multipart/mixed contained therein, must be marked foo. What we really want to say is "all top-level parts in a multipart/alternative must be marked foo." That means, for example, if one of the parts is a multipart/mixed, the multipart/mixed needs to have the foo marking, but things within the multipart/mixed, I presume, will follow the appropriate rules for multipart/mixed and the body's context. Section 3.2 =========== Please make clear that binary *SIP* message body parts MUST be binary, as the text currently says. However, it is quite possible, and should be legal, to encode application parts transported in SIP, such as INFO or NOTIFY bodies. For example, one might forward a base64 e-mail or a uuencoded file. Since that would be an application-level message, there is no reason to burden the application with decoding the body part to get it to binary, just for the other side to re-encode it. Section 6.2 =========== What confused me is section 6.2 starts with what looks like a normative statement, but it really is a forward reference. To me, there is no reference to which 'same' we are referring to. The text then seems to jump to what looks like a special case for 'session' and 'early-session'. I would suggest the following: 6.2. UA Behavior to Generate 'multipart/alternative' Message Bodies Section 8.2 mandates all top-level body parts within a 'multipart/ alternative' have the same disposition type as the enclosing 'multipart/alternative'. The 'session' and 'early-session' [RFC3959] disposition types require that all body parts of a 'multipart/alternative' body have different content types. Consequently, for the 'session' and 'early- session' disposition types, each top-level body type within the 'multipart/alternative' body MUST be different. Otherwise, the rules for the specific disposition type apply. NOTE: One could envision situations where a UA presents multiple alternatives with the same body type, where the receiving UA picks the best or richest alternative it can use. Section 6.3 =========== Ah, but there ARE handling rules for multipart/alternative. I would replace this section with: When a UA receives a message with a 'multipart/alternative' body part, if the body part has a 'required' handling, then the UA MUST pick the best alternative body part to use. If the UA is unable to use any of the body parts, the UA MUST reject the request with a 415 error response. This could occur if the UA did not understand any of the top-level body parts within the 'multipart/alternative'. The handling marking for top-level body parts in a 'multipart/ alternative' has no meaning. Therefore, the UA MUST ignore any 'handling' tags in the top-level body parts of the 'multipart/ alternative' body part. Once the UA picks one of the top-level body parts to use, then the UA MUST use the appropriate processing rules for the 'handling' tags within the selected top-level body part. Section 8.2 =========== For multipart/alternative, a top-level body type with 'handling=required' makes no sense. By definition, using multipart/ alternative means we expect the UA to not be able to handle one or more of the body parts - we just do not know which one. I would remove the note and incorporate the gist into the text: If the sending UA requires the handling of a 'multipart/ alternative' body as a whole, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body to 'required'. Otherwise, the UA MUST set the 'handling' parameter to 'optional'. The sending UA MUST set all the top-level body parts within the 'multipart/alternative' to 'handling=optional'. Section 8.2 =========== For multipart/related, I disagree that if any part is required, the / related is required. The last sentence is a non-sequitur. Either I mandate doing something with the 'multipart/related' body or I do not. I could see, for example, saying that processing the multipart/ related is optional, but if you do process it, one or more of the sub- parts is required. In this case, the multipart/related is optional, yet one of the sub-parts is required. How about: If the sending UA requires the handling of a 'multipart/related' body as a whole, the UA MUST set the 'handling' parameter of the 'multipart/related' body to 'required'. Otherwise, the UA MUST set the handling to 'optional'. The UA sets the 'handling' parameters of the body parts within the 'multipart/related' body independently from the 'handling' parameter o the 'multipart/related' body. If the sending UA requires the handling of a particular body, the UA MUST set the 'handling' parameter of that body part 'required'. Otherwise, the UA MUST set the parameter to 'optional'. Section 8.2 =========== General: I really do not like the construction "If the UA requires the handling of foo the UA MUST mark it with 'handling=required'." The reason I do not like this is this is precisely what RFC 3459 says to do. All this draft does is repeat what is in that draft. Saying "You MUST do what you MUST do" seems redundant and error prone. Section 8.3 =========== This section is redundant with section 6.3. Remove section 8.3, as section 6.3 talks about processing. Section 8.4 =========== OK, I'll bite: what if I do not feel like returning a 415? Either enumerate the situation where I MUST return a 415 or enumerate the situations where I would return something other than 415. Section 9.2 =========== Nit in last line of Note: s/constrain/constraint/ Section 9.4 =========== Since RFC 3459 updated 3204, would not the normative current reference be to 3459? Section 11 ========== I would offer we point out the potential for DoS attacks from complex MIME bodies. UA's need to be aware of potential stack depth overflow, line length overflow, pointers to missing content, incorrect content- lengths, correct content-lengths that span what a parser that does not look at content-lengths might consider to be content boundaries with other body parts snuck in. --Apple-Mail-200-71625796 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMDYxNDA5NDBaMCMGCSqGSIb3 DQEJBDEWBBRlog1EpKns2Zsc27kkBe2mnt9/gDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQAB/Ck0NQHyPiq+RvhLI20wbLNbjrEOeuE/flNpeJGsMsm0 iRfysv2b9LxIwy31CBUum6Cy9LIJZU4gijNw4TOxu3IjpG24Ppcb+EMPvIwXEhJJJHhgqJWHAf82 kmv9U5t7rOun7/iU7qQPCL7IT/e8zViLEQDvmY4GVvH1iSqRM3FSZ28+axTJKnvmAL08F8C4AO/a 6oDaA8GOSDwt5GJiZd9ZLePr5D4W1i+YYc3s07qybuePRi1qRfPbrV7Dyb2FsCW5mjpXwKG6k1Y/ murR/uaJQDwED0fqPYzLfCFUC+7NplOEbMx8MLPivsdgU6+7AFWw4XZ6Zgk+kvBDqcoXAAAAAAAA --Apple-Mail-200-71625796-- From munakata.mayumi@lab.ntt.co.jp Sun Feb 8 19:01:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790B13A69D3 for ; Sun, 8 Feb 2009 19:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEuOPaLnR8JD for ; Sun, 8 Feb 2009 19:01:15 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 6C91A3A67A2 for ; Sun, 8 Feb 2009 19:01:14 -0800 (PST) Received: (qmail 73591 invoked by alias); 9 Feb 2009 03:01:17 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 9 Feb 2009 03:01:17 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id n1931Fj1017822; Mon, 9 Feb 2009 12:01:16 +0900 Received: from gwall2.bb.ntt-at.co.jp (gwall2.bb.ntt-at.co.jp [192.168.5.202]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n1931GWL023405; Mon, 9 Feb 2009 12:01:16 +0900 (JST) (envelope-from munakata.mayumi@lab.ntt.co.jp) Received: (from root@localhost) by gwall2.bb.ntt-at.co.jp (8.13.1/8.13.1) id n1931CWV005772; Mon, 9 Feb 2009 12:01:12 +0900 Received: from mercury.tec.ntt-at.co.jp [192.168.22.39] by gwall2.bb.ntt-at.co.jp with ESMTP id NAA05771; Mon, 9 Feb 2009 12:01:12 +0900 Received: from [127.0.0.1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 4A43C53F61; Mon, 9 Feb 2009 12:01:12 +0900 (JST) Message-ID: <498F9C72.6040005@lab.ntt.co.jp> Date: Mon, 09 Feb 2009 12:01:06 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D00182CF0E@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00182CF0E@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] Nits in draft-ietf-sip-ua-privacy-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 03:01:16 -0000 John, Thank you for the reminder. I am so sorry that I totally missed those nits comments. I will correct the draft to incorporate your comments and submit 05 version soon. Mayumi > Mayumi, > > I note that my previous comments of substance have all been taken into > account. > > However, nits that I sent to you privately (see attached email) have not > been into account. > > In addition I have detected a further nit: > > In section 5.1.1 it says: > "...and refer to Section 4.2 for details on how to obtain > an IP address through TURN." > Since IP addresses are not mentioned in the rest of 5.1.1, this seems > irrelevant. The words should be deleted. > > When these nits have been fixed, in my opinion the document will be > ready to go. > > John > > > ------------------------------------------------------------------------ > > Subject: > Nits in draft-ietf-sip-ua-privacy-03 > From: > "Elwell, John" > Date: > Tue, 11 Nov 2008 14:35:25 -0000 > To: > "Mayumi Munakata" , "Shida Schubert" > > > To: > "Mayumi Munakata" , "Shida Schubert" > > > > Mayumi, Shida, > > I am sending you nits separately. My main comments have been posted to > the SIP list. > > 1. "by allowing user agent to > take control of its privacy, rather than being completely dependent > on external privacy service." > Change to > "by allowing a user agent to > ^^ > take control of its privacy, rather than being completely dependent > on an external privacy service." > ^^^ > > 2. "If revealing the domain name in Contact > header field " > Change to: > "If revealing the domain name in the Contact > ^^^^ > header field " > > 3. "A user agent that is not provided with a functional anonymous IP > address through some administrative means, MUST obtain a relayed > address if anonymity is desired (IP address of the media relay) for > use in SDP and in Via header. Such IP address is to be derived from > a STUN relay server through TURN mechanism, which allows a STUN > server to act as a media relay." > Change to: > "A user agent that is not provided with a functional anonymous IP > address through some administrative means MUST obtain a relayed address > (IP address of a relay) if anonymity is desired for use in SDP and in > the Via header field. Such an IP address is to be derived from a STUN > relay server through the TURN mechanism, which allows a STUN server to > act as a relay." > (Various changes, including deletion of "media", since the relay is also > used for Via (signalling)). > > 4. "A user agent SHOULD go with option 1 to conceal its domain name in > From header field." > Insert "the" in front of "From". > > 5. "If user wants both anonymity and strong identity, use a third party > anonymization service which issues AoR for the use in From address > which also provides SIP-Identity." > Various changes: > "If the user wants both anonymity and strong identity, a solution would > be to use a third party anonymization service that issues an Address of > Record (AoR) for use in the From header field of a request and that also > provides a SIP-Identity Authentication Service." > > 6. "Without privacy considerations, the bottommost Via header field > added > by a user agent" > Add "to a request". > > 7. "Via header SHOULD NOT include a host name." > Change to: > "The Via header field SHOULD NOT include a host name." > > 8. "Furthermore, if the provider of the caller intending to obscure its > identity consists of a small number of people (e.g. small enterprise, > SOHO), the domain name alone can reveal the identity of the caller > when this specification is used." > Delete "when this specification is used". It is irrelevant whether this > specification is used - the domain name can in any case reveal > information. > > 9. "Same can be true when the provider is large, but the receiver of the > call only knows few people from the source of call." > Change to: > "The same can be true when the provider is large but the receiver of the > ^^^^^ ^ (delete commma) > call only knows a few people from the source of call." > ^^ > > 10. "The domain name in From header can be obscured as described in > section 5.1.2, on contrary the Contact header needs to contain a > valid domain name at all time to function properly." > Change to: > "The domain name in the From header field can be obscured as described > in > section 5.1.2, whereas the Contact header field needs to contain a > valid domain name at all times in order to function properly." > > 11. "If one wants to assure anonymization, it is recommended for the > user > to seek and rely on third party anonymization service." > Change "third" to "a third". > > 12. "A third party anonymization service provides registrar and TURN > service which has no affiliation with the caller's provider, allowing > caller to completely withhold its identity." > Change to: > "A third party anonymization service provides registrar and TURN > services that have no affiliation with the caller's provider, > allowing > the caller to completely withhold its identity." > > There are still several places where "header" is used instead of "header > field". A SIP message, like an HTTP message, has only one header yet > many header fields. > > Regards, > > John > From sunil.bhagat@wipro.com Sun Feb 8 21:19:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECFC28C0E7 for ; Sun, 8 Feb 2009 21:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KmXDb38qugF for ; Sun, 8 Feb 2009 21:19:46 -0800 (PST) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 3787E3A6877 for ; Sun, 8 Feb 2009 21:19:46 -0800 (PST) X-AuditID: cb5bdd57-ae6ddbb000001f7d-13-498fbcf2d20c Received: from blr-ec-aa03.wipro.com (unknown [10.201.18.42]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id 9B2A54E4013 for ; Mon, 9 Feb 2009 10:49:46 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 10:49:24 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 10:49:23 +0530 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_01C98A75.F77E5BDE" Date: Mon, 9 Feb 2009 10:47:30 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Can we use From Header's value to build Contact in REFER Thread-Index: AcmKdS8GWFwqNAscT1+XlqUbozLoWgAAGmiA From: To: X-OriginalArrivalTime: 09 Feb 2009 05:19:23.0670 (UTC) FILETIME=[F8337B60:01C98A75] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] Can we use From Header's value to build Contact in REFER X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 05:19:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98A75.F77E5BDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All. =20 I have a small query regarding the Contact Header while building a REFER message. RFC 3515 specifies that Contact Header is mandatory in REFER message.=20 If Contact Header is missing in REFER, can we populate its value from the "From" Header? =20 If yes, Can the same be done for SUBSCRIBE and NOTIFY messages? =20 Thanks, Sunil =20 ------_=_NextPart_001_01C98A75.F77E5BDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All.

 

I have a small query regarding the = Contact Header while building a REFER message.

RFC 3515 specifies that Contact = Header is mandatory in REFER message.

If Contact Header is missing in = REFER, can we populate its value from the “From” = Header?

 

If yes, Can the same be done for = SUBSCRIBE and NOTIFY messages?

 

Thanks,

=

Sunil

 

------_=_NextPart_001_01C98A75.F77E5BDE-- From rjsparks@nostrum.com Mon Feb 9 08:42:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD313A6AD7 for ; Mon, 9 Feb 2009 08:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 qtfdirZjloPJ for ; Mon, 9 Feb 2009 08:42:26 -0800 (PST) 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 8877D3A69BB for ; Mon, 9 Feb 2009 08:42:14 -0800 (PST) Received: from dn3-232.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 n19FY0Y9030762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Feb 2009 09:34:00 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <55D2A8A8-29A6-4099-BEA7-7452B8B794C7@nostrum.com> From: Robert Sparks To: "" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-62-335886395 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Feb 2009 09:34:00 -0600 References: X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/8967/Mon Feb 9 02:38:55 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip@ietf.org Subject: Re: [Sip] Can we use From Header's value to build Contact in REFER X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 16:42:27 -0000 --Apple-Mail-62-335886395 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Generally speaking, no. The =46rom header field is likely (but not guaranteed) to contain =20 something with AOR properties, and you want an identifier that =20 corresponds to exactly the endpoint that sent the REFER. You're better off rejecting such a REFER as malformed. The same is true of SUBSCRIBE, and because of forking, initial NOTIFYs. You could consider being more lenient if Contact is missing in =20 subsequent NOTIFYs, using the remote target already stored in the =20 dialog, but remember that you'd be writing code to deal with a peer that is not =20 following the protocol and that other exceptions are quite likely. RjS On Feb 8, 2009, at 11:17 PM, = wrote: > Hi All. > > I have a small query regarding the Contact Header while building a =20 > REFER message. > RFC 3515 specifies that Contact Header is mandatory in REFER message. > If Contact Header is missing in REFER, can we populate its value =20 > from the =93From=94 Header? > > If yes, Can the same be done for SUBSCRIBE and NOTIFY messages? > > Thanks, > Sunil > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-62-335886395 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Generally speaking, = no.

The =46rom header field is likely (but not guaranteed) = to contain something with AOR properties, and you want an identifier = that corresponds to 
exactly the endpoint that sent the = REFER.

You're better off rejecting such a REFER = as malformed.

The same is true of SUBSCRIBE, = and because of forking, initial NOTIFYs.

You = could consider being more lenient if Contact is missing in subsequent = NOTIFYs, using the remote target already stored in the dialog, = but
remember that you'd be writing code to deal with a peer = that is not following the protocol and that other exceptions are quite = likely.

RjS


Hi All.
I have a small query regarding the Contact Header while = building a REFER message.
RFC 3515 = specifies that Contact Header is mandatory in REFER = message.
If Contact Header is missing in REFER, can we populate = its value from the =93From=94 Header?
If yes, Can the same be done for SUBSCRIBE and NOTIFY = messages?
 
Sunil
 sip-implementors@cs.columbia.edu for questions on current = sip
Use sipping@ietf.org for new developments on the = application of = sip

= --Apple-Mail-62-335886395-- From web-usrn@ISI.EDU Mon Feb 9 09:37:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECD63A69A9 for ; Mon, 9 Feb 2009 09:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.219 X-Spam-Level: X-Spam-Status: No, score=-16.219 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGON3C6wEnNR for ; Mon, 9 Feb 2009 09:37:29 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 7CADF3A67DA for ; Mon, 9 Feb 2009 09:37:29 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n19HaaoZ027184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Feb 2009 09:36:36 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n19HaYee027174; Mon, 9 Feb 2009 09:36:34 -0800 (PST) Date: Mon, 9 Feb 2009 09:36:34 -0800 (PST) Message-Id: <200902091736.n19HaYee027174@boreas.isi.edu> To: srd@cisco.com, jdrosen@cisco.com, jon.peterson@neustar.biz, fluffy@cisco.com, dean.willis@softarmor.com, drage@alcatel-lucent.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: sip@ietf.org, mperumal@cisco.com, rfc-editor@rfc-editor.org Subject: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:37:30 -0000 The following errata report has been submitted for RFC4028, "Session Timers in the Session Initiation Protocol (SIP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4028&eid=1681 -------------------------------------- Type: Technical Reported by: Muthu Arul Mozhi Section: 13 Original Text ------------- In section 13 (Example Call Flow) the From tag never changes between the initial INVITE message and the subsequent INVITE messages sent after receiving a 422: message 1 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 message 4 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: Content-Type: application/sdp Content-Length: 142 message 10 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Supported: timer Session-Expires: 4000 Min-SE: 4000 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: Content-Type: application/sdp However, as per RFC 3261, if an initial INVITE generates a non-2xx final response, that terminates all sessions and all dialogs that were created. Hence, these are not re-INVITE messages, rather new INVITE messages and should use a new From tag. Corrected Text -------------- message 1 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 message 4 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob From: Alice ;tag=2568701785 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: Content-Type: application/sdp Content-Length: 142 message 10 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Supported: timer Session-Expires: 4000 Min-SE: 4000 Max-Forwards: 70 To: Bob From: Alice ;tag=5647301796 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: Content-Type: application/sdp Notes ----- -----Original Message----- From: Paul Kyzivat (pkyzivat) Sent: Monday, February 09, 2009 10:09 PM To: Muthu ArulMozhi Perumal (mperumal) Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg (jdrosen); Ram Mohan R (rmohanr) Subject: Re: UAS behavior after sending 422 for initial INVITE yes, I think so. Paul Muthu ArulMozhi Perumal (mperumal) wrote: > In section 13 (Example Call Flow) of RFC 4028 the From tag never changes > between the initial INVITE message and the subsequent INVITE messages > sent after receiving a 422: > > message 1 > INVITE sips:bob@biloxi.example.com SIP/2.0 > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > > message 4 > INVITE sips:bob@biloxi.example.com SIP/2.0 > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > > message 10 > INVITE sips:bob@biloxi.example.com SIP/2.0 > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > > Is this a bug in the RFC? > > thanks, > Muthu > > |-----Original Message----- > |From: Paul Kyzivat (pkyzivat) > |Sent: Wednesday, February 04, 2009 12:36 AM > |To: Radha Krishna Saragadam (rsaragad) > |Cc: Jonathan Rosenberg (jdrosen); Muthu ArulMozhi Perumal (mperumal); > Ram Mohan R (rmohanr) > |Subject: Re: UAS behavior after sending 422 for initial INVITE > | > |Radha, > | > |It is not a reinvite, because a dialog was never established - the > first > |call failed. > | > |So you are starting a new invite. You can use the same callid, but > |should use a new from-tag. > | > | Thanks, > | Paul > | > |Radha Krishna Saragadam (rsaragad) wrote: > |> Hi Paul > |> > |> My question is for initial INVITE. For initial INVITE if UA > |> receives 422 and UA want to retry INVITE with new value increased > value > |> then what should be the To(with tag), From(with tag) and CallID > values? > |> Is it a Re-INVITE or new a Dialog? Section 7.3 says same value for > |> To,From and CallID > |> > |> Regards > |> S.Radha krishna Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4028 (draft-ietf-sip-session-timer-15) -------------------------------------- Title : Session Timers in the Session Initiation Protocol (SIP) Publication Date : April 2005 Author(s) : S. Donovan, J. Rosenberg Category : PROPOSED STANDARD Source : Session Initiation Protocol Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From brett@broadsoft.com Mon Feb 9 09:59:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71453A6B8D for ; Mon, 9 Feb 2009 09:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=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 DAorcvSBVtkD for ; Mon, 9 Feb 2009 09:59:48 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id A48743A67D4 for ; Mon, 9 Feb 2009 09:59:48 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 9 Feb 2009 09:59:44 -0800 From: Brett Tate To: "sip@ietf.org" Date: Mon, 9 Feb 2009 09:59:46 -0800 Thread-Topic: [Sip] [Technical Errata Reported] RFC4028 (1681) Thread-Index: AcmK3TDTs8M8j5bdS/W6z+tHa4K/IwAAfh0A Message-ID: <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> References: <200902091736.n19HaYee027174@boreas.isi.edu> In-Reply-To: <200902091736.n19HaYee027174@boreas.isi.edu> 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: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:59:50 -0000 The reported error does not sound correct. If RFC 4028 is incorrect concer= ning From tag, so is RFC 3261 (section 8.1 and likely other sections) and v= arious other RFCs. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of RFC > Errata System > Sent: Monday, February 09, 2009 12:37 PM > To: srd@cisco.com; jdrosen@cisco.com; jon.peterson@neustar.biz; > fluffy@cisco.com; dean.willis@softarmor.com; drage@alcatel-lucent.com > Cc: sip@ietf.org; mperumal@cisco.com; rfc-editor@rfc-editor.org > Subject: [Sip] [Technical Errata Reported] RFC4028 (1681) >=20 >=20 > The following errata report has been submitted for RFC4028, > "Session Timers in the Session Initiation Protocol (SIP)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4028&eid=3D1681 >=20 > -------------------------------------- > Type: Technical > Reported by: Muthu Arul Mozhi >=20 > Section: 13 >=20 > Original Text > ------------- > In section 13 (Example Call Flow) the From tag never changes > between the initial INVITE message and the subsequent INVITE > messages sent after receiving a 422: >=20 > message 1 > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds8 > Supported: timer > Session-Expires: 50 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > Content-Type: application/sdp > Content-Length: 142 >=20 > message 4 > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds9 > Supported: timer > Session-Expires: 3600 > Min-SE: 3600 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314160 INVITE > Contact: > Content-Type: application/sdp > Content-Length: 142 >=20 > message 10 > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds10 > Supported: timer > Session-Expires: 4000 > Min-SE: 4000 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314161 INVITE > Contact: > Content-Type: application/sdp >=20 > However, as per RFC 3261, if an initial INVITE generates a non-2xx final > response, that terminates all sessions and all dialogs that were created. >=20 > Hence, these are not re-INVITE messages, rather new INVITE messages and > should use a new From tag. >=20 > Corrected Text > -------------- > message 1 > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds8 > Supported: timer > Session-Expires: 50 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > Content-Type: application/sdp > Content-Length: 142 >=20 > message 4 > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds9 > Supported: timer > Session-Expires: 3600 > Min-SE: 3600 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=3D2568701785 > Call-ID: a84b4c76e66710 > CSeq: 314160 INVITE > Contact: > Content-Type: application/sdp > Content-Length: 142 >=20 > message 10 > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds10 > Supported: timer > Session-Expires: 4000 > Min-SE: 4000 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=3D5647301796 > Call-ID: a84b4c76e66710 > CSeq: 314161 INVITE > Contact: > Content-Type: application/sdp >=20 > Notes > ----- > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Monday, February 09, 2009 10:09 PM > To: Muthu ArulMozhi Perumal (mperumal) > Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg (jdrosen); Ram > Mohan R (rmohanr) > Subject: Re: UAS behavior after sending 422 for initial INVITE >=20 > yes, I think so. >=20 > Paul >=20 > Muthu ArulMozhi Perumal (mperumal) wrote: > > In section 13 (Example Call Flow) of RFC 4028 the From tag never change= s > > between the initial INVITE message and the subsequent INVITE messages > > sent after receiving a 422: > > > > message 1 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > From: Alice ;tag=3D1928301774 > > Call-ID: a84b4c76e66710 > > > > message 4 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > From: Alice ;tag=3D1928301774 > > Call-ID: a84b4c76e66710 > > > > message 10 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > From: Alice ;tag=3D1928301774 > > Call-ID: a84b4c76e66710 > > > > Is this a bug in the RFC? > > > > thanks, > > Muthu > > > > |-----Original Message----- > > |From: Paul Kyzivat (pkyzivat) > > |Sent: Wednesday, February 04, 2009 12:36 AM > > |To: Radha Krishna Saragadam (rsaragad) > > |Cc: Jonathan Rosenberg (jdrosen); Muthu ArulMozhi Perumal (mperumal); > > Ram Mohan R (rmohanr) > > |Subject: Re: UAS behavior after sending 422 for initial INVITE > > | > > |Radha, > > | > > |It is not a reinvite, because a dialog was never established - the > > first > > |call failed. > > | > > |So you are starting a new invite. You can use the same callid, but > > |should use a new from-tag. > > | > > | Thanks, > > | Paul > > | > > |Radha Krishna Saragadam (rsaragad) wrote: > > |> Hi Paul > > |> > > |> My question is for initial INVITE. For initial INVITE if UA > > |> receives 422 and UA want to retry INVITE with new value increased > > value > > |> then what should be the To(with tag), From(with tag) and CallID > > values? > > |> Is it a Re-INVITE or new a Dialog? Section 7.3 says same value for > > |> To,From and CallID > > |> > > |> Regards > > |> S.Radha krishna >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC4028 (draft-ietf-sip-session-timer-15) > -------------------------------------- > Title : Session Timers in the Session Initiation Protocol > (SIP) > Publication Date : April 2005 > Author(s) : S. Donovan, J. Rosenberg > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From brett@broadsoft.com Mon Feb 9 10:03:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C903A6BC4 for ; Mon, 9 Feb 2009 10:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=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 Iz+beMYIk7PG for ; Mon, 9 Feb 2009 10:03:17 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 1BF863A6A06 for ; Mon, 9 Feb 2009 10:03:17 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 9 Feb 2009 10:03:19 -0800 From: Brett Tate To: "sip@ietf.org" Date: Mon, 9 Feb 2009 10:03:21 -0800 Thread-Topic: [Sip] [Technical Errata Reported] RFC4028 (1681) Thread-Index: AcmK3TDTs8M8j5bdS/W6z+tHa4K/IwAAfh0AAABXOjA= Message-ID: <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE64@mbx02.citservers.local> References: <200902091736.n19HaYee027174@boreas.isi.edu> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.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: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:03:18 -0000 Sorry about the repost, I intended to indicate section RFC 3261 section 8.1= .3.5. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Brett Tate > Sent: Monday, February 09, 2009 1:00 PM > To: sip@ietf.org > Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) >=20 > The reported error does not sound correct. If RFC 4028 is incorrect > concerning From tag, so is RFC 3261 (section 8.1 and likely other > sections) and various other RFCs. >=20 >=20 >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > RFC > > Errata System > > Sent: Monday, February 09, 2009 12:37 PM > > To: srd@cisco.com; jdrosen@cisco.com; jon.peterson@neustar.biz; > > fluffy@cisco.com; dean.willis@softarmor.com; drage@alcatel-lucent.com > > Cc: sip@ietf.org; mperumal@cisco.com; rfc-editor@rfc-editor.org > > Subject: [Sip] [Technical Errata Reported] RFC4028 (1681) > > > > > > The following errata report has been submitted for RFC4028, > > "Session Timers in the Session Initiation Protocol (SIP)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4028&eid=3D1681 > > > > -------------------------------------- > > Type: Technical > > Reported by: Muthu Arul Mozhi > > > > Section: 13 > > > > Original Text > > ------------- > > In section 13 (Example Call Flow) the From tag never changes > > between the initial INVITE message and the subsequent INVITE > > messages sent after receiving a 422: > > > > message 1 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds8 > > Supported: timer > > Session-Expires: 50 > > Max-Forwards: 70 > > To: Bob > > From: Alice ;tag=3D1928301774 > > Call-ID: a84b4c76e66710 > > CSeq: 314159 INVITE > > Contact: > > Content-Type: application/sdp > > Content-Length: 142 > > > > message 4 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds9 > > Supported: timer > > Session-Expires: 3600 > > Min-SE: 3600 > > Max-Forwards: 70 > > To: Bob > > From: Alice ;tag=3D1928301774 > > Call-ID: a84b4c76e66710 > > CSeq: 314160 INVITE > > Contact: > > Content-Type: application/sdp > > Content-Length: 142 > > > > message 10 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds10 > > Supported: timer > > Session-Expires: 4000 > > Min-SE: 4000 > > Max-Forwards: 70 > > To: Bob > > From: Alice ;tag=3D1928301774 > > Call-ID: a84b4c76e66710 > > CSeq: 314161 INVITE > > Contact: > > Content-Type: application/sdp > > > > However, as per RFC 3261, if an initial INVITE generates a non-2xx fina= l > > response, that terminates all sessions and all dialogs that were > created. > > > > Hence, these are not re-INVITE messages, rather new INVITE messages and > > should use a new From tag. > > > > Corrected Text > > -------------- > > message 1 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds8 > > Supported: timer > > Session-Expires: 50 > > Max-Forwards: 70 > > To: Bob > > From: Alice ;tag=3D1928301774 > > Call-ID: a84b4c76e66710 > > CSeq: 314159 INVITE > > Contact: > > Content-Type: application/sdp > > Content-Length: 142 > > > > message 4 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds9 > > Supported: timer > > Session-Expires: 3600 > > Min-SE: 3600 > > Max-Forwards: 70 > > To: Bob > > From: Alice ;tag=3D2568701785 > > Call-ID: a84b4c76e66710 > > CSeq: 314160 INVITE > > Contact: > > Content-Type: application/sdp > > Content-Length: 142 > > > > message 10 > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds10 > > Supported: timer > > Session-Expires: 4000 > > Min-SE: 4000 > > Max-Forwards: 70 > > To: Bob > > From: Alice ;tag=3D5647301796 > > Call-ID: a84b4c76e66710 > > CSeq: 314161 INVITE > > Contact: > > Content-Type: application/sdp > > > > Notes > > ----- > > -----Original Message----- > > From: Paul Kyzivat (pkyzivat) > > Sent: Monday, February 09, 2009 10:09 PM > > To: Muthu ArulMozhi Perumal (mperumal) > > Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg (jdrosen); > Ram > > Mohan R (rmohanr) > > Subject: Re: UAS behavior after sending 422 for initial INVITE > > > > yes, I think so. > > > > Paul > > > > Muthu ArulMozhi Perumal (mperumal) wrote: > > > In section 13 (Example Call Flow) of RFC 4028 the From tag never > changes > > > between the initial INVITE message and the subsequent INVITE messages > > > sent after receiving a 422: > > > > > > message 1 > > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > > From: Alice ;tag=3D1928301774 > > > Call-ID: a84b4c76e66710 > > > > > > message 4 > > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > > From: Alice ;tag=3D1928301774 > > > Call-ID: a84b4c76e66710 > > > > > > message 10 > > > INVITE sips:bob@biloxi.example.com SIP/2.0 > > > From: Alice ;tag=3D1928301774 > > > Call-ID: a84b4c76e66710 > > > > > > Is this a bug in the RFC? > > > > > > thanks, > > > Muthu > > > > > > |-----Original Message----- > > > |From: Paul Kyzivat (pkyzivat) > > > |Sent: Wednesday, February 04, 2009 12:36 AM > > > |To: Radha Krishna Saragadam (rsaragad) > > > |Cc: Jonathan Rosenberg (jdrosen); Muthu ArulMozhi Perumal (mperumal)= ; > > > Ram Mohan R (rmohanr) > > > |Subject: Re: UAS behavior after sending 422 for initial INVITE > > > | > > > |Radha, > > > | > > > |It is not a reinvite, because a dialog was never established - the > > > first > > > |call failed. > > > | > > > |So you are starting a new invite. You can use the same callid, but > > > |should use a new from-tag. > > > | > > > | Thanks, > > > | Paul > > > | > > > |Radha Krishna Saragadam (rsaragad) wrote: > > > |> Hi Paul > > > |> > > > |> My question is for initial INVITE. For initial INVITE if UA > > > |> receives 422 and UA want to retry INVITE with new value increased > > > value > > > |> then what should be the To(with tag), From(with tag) and CallID > > > values? > > > |> Is it a Re-INVITE or new a Dialog? Section 7.3 says same value for > > > |> To,From and CallID > > > |> > > > |> Regards > > > |> S.Radha krishna > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4028 (draft-ietf-sip-session-timer-15) > > -------------------------------------- > > Title : Session Timers in the Session Initiation Protocol > > (SIP) > > Publication Date : April 2005 > > Author(s) : S. Donovan, J. Rosenberg > > Category : PROPOSED STANDARD > > Source : Session Initiation Protocol > > Area : Real-time Applications and Infrastructure > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From rjsparks@nostrum.com Mon Feb 9 11:03:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F6B3A6B8D for ; Mon, 9 Feb 2009 11:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=0.6, 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 ED2qz5FiHW7T for ; Mon, 9 Feb 2009 11:03:51 -0800 (PST) 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 9DDD13A6A0A for ; Mon, 9 Feb 2009 11:03:50 -0800 (PST) Received: from dn3-232.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 n19J3n8p046085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Feb 2009 13:03:49 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Brett Tate In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Feb 2009 13:03:48 -0600 References: <200902091736.n19HaYee027174@boreas.isi.edu> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/8968/Mon Feb 9 09:06:24 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: "sip@ietf.org" Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 19:03:52 -0000 I agree - the example is not flawed (at least in the way the errata reports). Muthu seems to troubled by the reuse of the call-id and from tag when the initial transaction didn't create a dialog. While doing so is not required by the specification, nothing makes it illegal either. RjS On Feb 9, 2009, at 11:59 AM, Brett Tate wrote: > The reported error does not sound correct. If RFC 4028 is incorrect > concerning From tag, so is RFC 3261 (section 8.1 and likely other > sections) and various other RFCs. > > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >> Of RFC >> Errata System >> Sent: Monday, February 09, 2009 12:37 PM >> To: srd@cisco.com; jdrosen@cisco.com; jon.peterson@neustar.biz; >> fluffy@cisco.com; dean.willis@softarmor.com; drage@alcatel-lucent.com >> Cc: sip@ietf.org; mperumal@cisco.com; rfc-editor@rfc-editor.org >> Subject: [Sip] [Technical Errata Reported] RFC4028 (1681) >> >> >> The following errata report has been submitted for RFC4028, >> "Session Timers in the Session Initiation Protocol (SIP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4028&eid=1681 >> >> -------------------------------------- >> Type: Technical >> Reported by: Muthu Arul Mozhi >> >> Section: 13 >> >> Original Text >> ------------- >> In section 13 (Example Call Flow) the From tag never changes >> between the initial INVITE message and the subsequent INVITE >> messages sent after receiving a 422: >> >> message 1 >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 >> Supported: timer >> Session-Expires: 50 >> Max-Forwards: 70 >> To: Bob >> From: Alice ;tag=1928301774 >> Call-ID: a84b4c76e66710 >> CSeq: 314159 INVITE >> Contact: >> Content-Type: application/sdp >> Content-Length: 142 >> >> message 4 >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 >> Supported: timer >> Session-Expires: 3600 >> Min-SE: 3600 >> Max-Forwards: 70 >> To: Bob >> From: Alice ;tag=1928301774 >> Call-ID: a84b4c76e66710 >> CSeq: 314160 INVITE >> Contact: >> Content-Type: application/sdp >> Content-Length: 142 >> >> message 10 >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 >> Supported: timer >> Session-Expires: 4000 >> Min-SE: 4000 >> Max-Forwards: 70 >> To: Bob >> From: Alice ;tag=1928301774 >> Call-ID: a84b4c76e66710 >> CSeq: 314161 INVITE >> Contact: >> Content-Type: application/sdp >> >> However, as per RFC 3261, if an initial INVITE generates a non-2xx >> final >> response, that terminates all sessions and all dialogs that were >> created. >> >> Hence, these are not re-INVITE messages, rather new INVITE messages >> and >> should use a new From tag. >> >> Corrected Text >> -------------- >> message 1 >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 >> Supported: timer >> Session-Expires: 50 >> Max-Forwards: 70 >> To: Bob >> From: Alice ;tag=1928301774 >> Call-ID: a84b4c76e66710 >> CSeq: 314159 INVITE >> Contact: >> Content-Type: application/sdp >> Content-Length: 142 >> >> message 4 >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 >> Supported: timer >> Session-Expires: 3600 >> Min-SE: 3600 >> Max-Forwards: 70 >> To: Bob >> From: Alice ;tag=2568701785 >> Call-ID: a84b4c76e66710 >> CSeq: 314160 INVITE >> Contact: >> Content-Type: application/sdp >> Content-Length: 142 >> >> message 10 >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 >> Supported: timer >> Session-Expires: 4000 >> Min-SE: 4000 >> Max-Forwards: 70 >> To: Bob >> From: Alice ;tag=5647301796 >> Call-ID: a84b4c76e66710 >> CSeq: 314161 INVITE >> Contact: >> Content-Type: application/sdp >> >> Notes >> ----- >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Monday, February 09, 2009 10:09 PM >> To: Muthu ArulMozhi Perumal (mperumal) >> Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg >> (jdrosen); Ram >> Mohan R (rmohanr) >> Subject: Re: UAS behavior after sending 422 for initial INVITE >> >> yes, I think so. >> >> Paul >> >> Muthu ArulMozhi Perumal (mperumal) wrote: >>> In section 13 (Example Call Flow) of RFC 4028 the From tag never >>> changes >>> between the initial INVITE message and the subsequent INVITE >>> messages >>> sent after receiving a 422: >>> >>> message 1 >>> INVITE sips:bob@biloxi.example.com SIP/2.0 >>> From: Alice ;tag=1928301774 >>> Call-ID: a84b4c76e66710 >>> >>> message 4 >>> INVITE sips:bob@biloxi.example.com SIP/2.0 >>> From: Alice ;tag=1928301774 >>> Call-ID: a84b4c76e66710 >>> >>> message 10 >>> INVITE sips:bob@biloxi.example.com SIP/2.0 >>> From: Alice ;tag=1928301774 >>> Call-ID: a84b4c76e66710 >>> >>> Is this a bug in the RFC? >>> >>> thanks, >>> Muthu >>> >>> |-----Original Message----- >>> |From: Paul Kyzivat (pkyzivat) >>> |Sent: Wednesday, February 04, 2009 12:36 AM >>> |To: Radha Krishna Saragadam (rsaragad) >>> |Cc: Jonathan Rosenberg (jdrosen); Muthu ArulMozhi Perumal >>> (mperumal); >>> Ram Mohan R (rmohanr) >>> |Subject: Re: UAS behavior after sending 422 for initial INVITE >>> | >>> |Radha, >>> | >>> |It is not a reinvite, because a dialog was never established - the >>> first >>> |call failed. >>> | >>> |So you are starting a new invite. You can use the same callid, but >>> |should use a new from-tag. >>> | >>> | Thanks, >>> | Paul >>> | >>> |Radha Krishna Saragadam (rsaragad) wrote: >>> |> Hi Paul >>> |> >>> |> My question is for initial INVITE. For initial INVITE if UA >>> |> receives 422 and UA want to retry INVITE with new value increased >>> value >>> |> then what should be the To(with tag), From(with tag) and CallID >>> values? >>> |> Is it a Re-INVITE or new a Dialog? Section 7.3 says same value >>> for >>> |> To,From and CallID >>> |> >>> |> Regards >>> |> S.Radha krishna >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4028 (draft-ietf-sip-session-timer-15) >> -------------------------------------- >> Title : Session Timers in the Session Initiation >> Protocol >> (SIP) >> Publication Date : April 2005 >> Author(s) : S. Donovan, J. Rosenberg >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From dworley@nortel.com Mon Feb 9 13:14:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3643A6B5E for ; Mon, 9 Feb 2009 13:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 X0ZqKLWxl8we for ; Mon, 9 Feb 2009 13:14:39 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8C1333A68AC for ; Mon, 9 Feb 2009 13:14:39 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n19LEcE12891 for ; Mon, 9 Feb 2009 21:14:38 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 16:14:10 -0500 From: "Dale Worley" To: SIP In-Reply-To: References: <200902091736.n19HaYee027174@boreas.isi.edu> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 09 Feb 2009 16:14:09 -0500 Message-Id: <1234214049.4033.62.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2009 21:14:10.0333 (UTC) FILETIME=[59B68CD0:01C98AFB] Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 21:14:40 -0000 On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks wrote: > I agree - the example is not flawed (at least in the way the errata > reports). > > Muthu seems to troubled by the reuse of the call-id and from tag when > the initial transaction didn't create a dialog. > While doing so is not required by the specification, nothing makes it > illegal either. Are we agreed that "doing so is not required by the specification"? In RFC 3261, requests that are retried after 401, 407, 413, 415, 416, and 420 responses are required to have the same from-tag as the original request. Is 422 different? Dale From brett@broadsoft.com Mon Feb 9 13:25:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2653A68AC for ; Mon, 9 Feb 2009 13:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6GRntDvnN-F for ; Mon, 9 Feb 2009 13:25:05 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 614E83A672F for ; Mon, 9 Feb 2009 13:25:05 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 9 Feb 2009 13:25:03 -0800 From: Brett Tate To: Dale Worley , SIP Date: Mon, 9 Feb 2009 13:25:06 -0800 Thread-Topic: [Sip] [Technical Errata Reported] RFC4028 (1681) Thread-Index: AcmK+3WgpfwWPkrTTOaQ7FiiI+f3nAAALKQQ Message-ID: <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DF1E@mbx02.citservers.local> References: <200902091736.n19HaYee027174@boreas.isi.edu> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> <1234214049.4033.62.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1234214049.4033.62.camel@victoria-pingtel-com.us.nortel.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 Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 21:25:06 -0000 Based upon the following snippet, my understanding is that RFC 4028 is corr= ectly following the SHOULD. RFC 3261 section 8.1.3.5 snippet: "In all of the above cases, the request is retried by creating a new reques= t with the appropriate modifications. This new request constitutes a new t= ransaction and SHOULD have the same value of the Call-ID, To, and From of t= he previous request, but the CSeq should contain a new sequence number that= is one higher than the previous. With other 4xx responses, including those= yet to be defined, a retry may or may not be possible depending on the met= hod and the use case." > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dal= e > Worley > Sent: Monday, February 09, 2009 4:14 PM > To: SIP > Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) >=20 > On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks wrote: > > I agree - the example is not flawed (at least in the way the errata > > reports). > > > > Muthu seems to troubled by the reuse of the call-id and from tag when > > the initial transaction didn't create a dialog. > > While doing so is not required by the specification, nothing makes it > > illegal either. >=20 > Are we agreed that "doing so is not required by the specification"? In > RFC 3261, requests that are retried after 401, 407, 413, 415, 416, and > 420 responses are required to have the same from-tag as the original > request. Is 422 different? >=20 > Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From dworley@nortel.com Mon Feb 9 15:04:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E88D28C0F7 for ; Mon, 9 Feb 2009 15:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 y9FwNIP9PhdH for ; Mon, 9 Feb 2009 15:04:09 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 9F3F228C186 for ; Mon, 9 Feb 2009 15:01:19 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n19N1J518499 for ; Mon, 9 Feb 2009 23:01:19 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 18:01:19 -0500 From: "Dale Worley" To: SIP Content-Type: text/plain Organization: Nortel Networks Date: Mon, 09 Feb 2009 18:01:18 -0500 Message-Id: <1234220478.4033.99.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2009 23:01:19.0036 (UTC) FILETIME=[5184C7C0:01C98B0A] Subject: [Sip] Retargeting difficulties X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 23:04:13 -0000 It is my contention that the "retargeting problem" is more complex than people have been allowing for. In examples that have been presented, there have usually been at most two relevant retarget/redirect operations, and all of them have been associated with one single AOR. For example, in section 2.1 of draft-rosenberg-sip-target-uri-delivery-00, "Unknown Aliases", the situation is: sip:worley-alias@serviceprovider -> (alias address) sip:worley@serviceprovider -> (AOR) sip:10.1.1.123 (registered contact) Both of these mappings are tightly coupled with AOR sip:worley@serviceprovider. But let us consider a more complicated example: I am included as an element of a "hunt group" for some work-related purpose: sip:hunt@group -> sip:worley@serviceprovider I have a UA that registers: sip:worley@serviceprovider -> sip:10.1.1.1 However, I am vacationing at a friend's Roman villa, and since I haven't paid serviceprovider for call forwarding, I direct my home UA to forward my calls: sip:10.1.1.1 -> sip:amico@fornitorediservizio I take another UA to the Roman villa, where it registers: sip:amico@fornitorediservizio -> sip:10.2.2.2 sip:hunt@group -> sip:worley@serviceprovider -> sip:10.1.1.1 -> sip:amico@fornitorediservizio -> sip:10.2.2.2 Each of these mappings is associated with a different business/social/technological activity. Now let us assume that a call initially directed to sip:hunt@group arrives as sip:10.2.2.2. What should my UA do with it? Or rather, which request-URI should it consider to be the "real" target of the call? Once you look at it, the answer clearly depends on which of these URIs the UA has knowledge of. If it is stupid, all it can understand is that there is an incoming call, and alert me. If it has some knowledge about the AOR sip:amico@fornitorediservizio, it can base its action on the fact that the call came to that AOR, or in variants of this scenario, that the call came via a request-URI that was related to this AOR. If the phone understands that sip:worley@serviceprovider has been forwarded to sip:amico@fornitorediservizio, it can alert in a different manner than it would for calls that are "just" to sip:amico@fornitorediservizio (*). And if the phone knows about sip:hunt@group, it could provide yet another alternative action. So I think that any solution to the "retargeting problem" that is going to be practical in the long run -- that is, will be adaptable to future networks where multiple "features" are ganged together -- because it is the only solution that has "recursiveness", "If you can do it [retargeting] once, you can do it many times." Recursiveness requires that the entire request-URI history of the call be presented to the UAS, and that the UAS will inspect that history for the earliest request-URI that it has knowledge of to determine the "context" that it should apply to this request. Fortunately, History-Info is (or is close to being) the needed solution. Conversely, all other proposed solutions fail to provide enough information: They either provide the *next-to-last* request-URI (P-Called-Party-Id) or the *first* request-URI (From or Target header). This data is insufficient, as can be seen from the carefully constructed example (*) above -- where the UAS does not understand the first request-URI, and the last and next-to-last request-URIs do not contain the information the UAS should act on -- only the 2nd of the 5 request-URIs contains the needed information. Dale From muthu.arul@gmail.com Mon Feb 9 20:57:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A7C3A688A for ; Mon, 9 Feb 2009 20:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 urjvSgiYF1kD for ; Mon, 9 Feb 2009 20:57:19 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 441FB3A686D for ; Mon, 9 Feb 2009 20:57:19 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so1331180wag.5 for ; Mon, 09 Feb 2009 20:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qRT6Uyk0HJrPyJCgf3ziEkUq+vn1gU7qkzuAad0MANI=; b=MTrixyq7hxKeagN3Z5NeCBR3fpxiDjZ7PDtwy+zuveH1uOCOMEmTKYfiFy1jRKJu9s cf6BmNbMKfVdMdeoAB8Z8VFph52fAfh//OojWuqwGmV9GlRQQtHldfdAbTkrv2xp77Kh i/AqinFXh6oWDqRMnVE+d1KQQ8zT3wyx/TU1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IAhOeQwvW9sAJYqH3NcPR6zTLsvoW7e7KN1FnVdx+oS93c/FTLE6q3Hal9Dt3ocUls DXAUBINkSHUxEpmE7V4UsBgoAbG9r2p51XrW8Qrcc6W38fP/WiheqBf4J/ceXgB8GNpp YYB6venwFZHZZ0COj4ckl0TJjlIO0pI6iWlrk= MIME-Version: 1.0 Received: by 10.114.209.1 with SMTP id h1mr4207346wag.105.1234241842116; Mon, 09 Feb 2009 20:57:22 -0800 (PST) In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DF1E@mbx02.citservers.local> References: <200902091736.n19HaYee027174@boreas.isi.edu> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> <1234214049.4033.62.camel@victoria-pingtel-com.us.nortel.com> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DF1E@mbx02.citservers.local> Date: Tue, 10 Feb 2009 10:27:22 +0530 Message-ID: <8c400f2e0902092057y5b98ce09nc69e5748d6032faa@mail.gmail.com> From: Muthu Arul To: Brett Tate Content-Type: multipart/alternative; boundary=00163646d74490faf60462895211 Cc: SIP Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 04:57:20 -0000 --00163646d74490faf60462895211 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If the From tag doesn't change, can the UAS retrain the same To tag as well? If the new INVITE reaches the UAS before the ACK for the previous INVITE, what should the UAS do? Should it reject the new INVITE and expect the UAC to retry again? I thought it would have been much simpler had the From/To tag changed b/w the INVITE messages.. thanks, Muthu On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate wrote: > Based upon the following snippet, my understanding is that RFC 4028 is > correctly following the SHOULD. > > RFC 3261 section 8.1.3.5 snippet: > > "In all of the above cases, the request is retried by creating a new > request with the appropriate modifications. This new request constitutes a > new transaction and SHOULD have the same value of the Call-ID, To, and From > of the previous request, but the CSeq should contain a new sequence number > that is one higher than the previous. With other 4xx responses, including > those yet to be defined, a retry may or may not be possible depending on the > method and the use case." > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Dale > > Worley > > Sent: Monday, February 09, 2009 4:14 PM > > To: SIP > > Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) > > > > On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks wrote: > > > I agree - the example is not flawed (at least in the way the errata > > > reports). > > > > > > Muthu seems to troubled by the reuse of the call-id and from tag when > > > the initial transaction didn't create a dialog. > > > While doing so is not required by the specification, nothing makes it > > > illegal either. > > > > Are we agreed that "doing so is not required by the specification"? In > > RFC 3261, requests that are retried after 401, 407, 413, 415, 416, and > > 420 responses are required to have the same from-tag as the original > > request. Is 422 different? > > > > Dale > > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --00163646d74490faf60462895211 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If the From tag doesn't change, can the UAS retrain the same To tag as = well? If the new INVITE reaches the UAS before the ACK for the previous INV= ITE, what should the UAS do? Should it reject the new INVITE and expect the= UAC to retry again?

I thought it would have been much simpler had the From/To tag changed b= /w the INVITE messages..

thanks,
Muthu

On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate <<= a href=3D"mailto:brett@broadsoft.com">brett@broadsoft.com> wr= ote:
Based upon the fo= llowing snippet, my understanding is that RFC 4028 is correctly following t= he SHOULD.

RFC 3261 section 8.1.3.5 snippet:

"In all of the above cases, the request is retried by creating a new r= equest with the appropriate modifications.  This new request constitut= es a new transaction and SHOULD have the same value of the Call-ID, To, and= From of the previous request, but the CSeq should contain a new sequence n= umber that is one higher than the previous. With other 4xx responses, inclu= ding those yet to be defined, a retry may or may not be possible depending = on the method and the use case."

> -----Original Message-----
> From: sip-bounces@ietf.org= [mailto:sip-bounces@ietf.org] = On Behalf Of Dale
> Worley
> Sent: Monday, February 09, 2009 4:14 PM
> To: SIP
> Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681)
>
> On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks wrote:
> > I agree - the example is not flawed (at least in the way the erra= ta
> > reports).
> >
> > Muthu seems to troubled by the reuse of the call-id and from tag = when
> > the initial transaction didn't create a dialog.
> > While doing so is not required by the specification, nothing make= s it
> > illegal either.
>
> Are we agreed that "doing so is not required by the specification= "?  In
> RFC 3261, requests that are retried after 401, 407, 413, 415, 416, and=
> 420 responses are required to have the same from-tag as the original > request.  Is 422 different?
>
> Dale
>
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implemento= rs@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new d= evelopments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs= .columbia.edu for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip

--00163646d74490faf60462895211-- From root@core3.amsl.com Mon Feb 9 21:15:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 97B213A6B31; Mon, 9 Feb 2009 21:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090210051501.97B213A6B31@core3.amsl.com> Date: Mon, 9 Feb 2009 21:15:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-ua-privacy-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 05:15:01 -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 Working Group of the IETF. Title : UA-Driven Privacy Mechanism for SIP Author(s) : M. Munakata, et al. Filename : draft-ietf-sip-ua-privacy-05.txt Pages : 11 Date : 2009-02-09 This document defines a guideline for a user agent to generate an anonymous SIP message by utilizing mechanisms such as GRUU (Globally Routable User Agent URIs) and TURN (Traversal Using Relays around NAT) without the need for a privacy service defined in RFC 3323. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-05.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-sip-ua-privacy-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-09210610.I-D@ietf.org> --NextPart-- From munakata.mayumi@lab.ntt.co.jp Mon Feb 9 21:20:01 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25373A6B73 for ; Mon, 9 Feb 2009 21:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXl8zUyMx7AX for ; Mon, 9 Feb 2009 21:20:01 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 6CF4028C16A for ; Mon, 9 Feb 2009 21:20:00 -0800 (PST) Received: (qmail 54748 invoked by alias); 10 Feb 2009 05:20:01 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 10 Feb 2009 05:20:01 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id n1A5K0j1005566 for ; Tue, 10 Feb 2009 14:20:00 +0900 Received: from gwall2.bb.ntt-at.co.jp (gwall2.bb.ntt-at.co.jp [192.168.5.202]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n1A5K0oE072894 for ; Tue, 10 Feb 2009 14:20:00 +0900 (JST) (envelope-from munakata.mayumi@lab.ntt.co.jp) Received: (from root@localhost) by gwall2.bb.ntt-at.co.jp (8.13.1/8.13.1) id n1A5JtxT023305 for sip@ietf.org; Tue, 10 Feb 2009 14:19:55 +0900 Received: from mercury.tec.ntt-at.co.jp [192.168.22.39] by gwall2.bb.ntt-at.co.jp with ESMTP id QAA23304; Tue, 10 Feb 2009 14:19:54 +0900 Received: from [127.0.0.1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 9AFB453F61; Tue, 10 Feb 2009 14:19:55 +0900 (JST) Message-ID: <49910E78.5080202@lab.ntt.co.jp> Date: Tue, 10 Feb 2009 14:19:52 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Sip] Update of draft-ietf-sip-ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 05:20:01 -0000 All; I have updated the ua-privacy draft. http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-05.txt After submission of -04 version, John pointed that some nits comments were not taken into account. So I submitted -05 version to incorporate them. Changes between -03 and -05 are as follows: Krishna and John gave us valuable comments in mail list and privately (Thank you to both of you!) and I incorporated the comments as follows; 1) In Section 4.1, mentions that third party GRUU server is out of scope. 2) In Section 5.1.2, mentions that third party anonymization service is out of scope. 3) In Section 5.1.1, deleted the use of TURN mechanism for the Contact header. 4) In Section 5.1.1, changed the text in order not to anonymize the Contact header in REGISTER requests and 3xx responses. 5) Many editorial changes that John proposed. I also changed the expression of "best current practice" to "guideline" because people agreed that this document should be Informational not BCP. The editors believe that there is no remaining issues. Thanks, Mayumi From sanjsinh@cisco.com Tue Feb 10 00:14:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2787F3A6C43 for ; Tue, 10 Feb 2009 00:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 kCpfRJM5itT0 for ; Tue, 10 Feb 2009 00:14:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 756243A6A2D for ; Tue, 10 Feb 2009 00:14:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,185,1233532800"; d="scan'208,217";a="36544344" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2009 08:14:49 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1A8EnKf032253; Tue, 10 Feb 2009 03:14:49 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1A8Enrp021882; Tue, 10 Feb 2009 08:14:49 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Feb 2009 03:14:49 -0500 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_01C98B57.A47DBE0C" Date: Tue, 10 Feb 2009 03:14:46 -0500 Message-ID: In-Reply-To: <8c400f2e0902092057y5b98ce09nc69e5748d6032faa@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] [Technical Errata Reported] RFC4028 (1681) Thread-Index: AcmLPBeo/w1cMruLTOWw/XpnN/POCAAGkkbA References: <200902091736.n19HaYee027174@boreas.isi.edu><9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local><1234214049.4033.62.camel@victoria-pingtel-com.us.nortel.com><9B2A061A1137254BBE4F4B2CD843646A0FD3B1DF1E@mbx02.citservers.local> <8c400f2e0902092057y5b98ce09nc69e5748d6032faa@mail.gmail.com> From: "Sanjay Sinha (sanjsinh)" To: "Muthu Arul" , "Brett Tate" X-OriginalArrivalTime: 10 Feb 2009 08:14:49.0843 (UTC) FILETIME=[A4B3C430:01C98B57] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10128; t=1234253690; x=1235117690; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20[Technical=20Errata=20Reported] =20RFC4028=20(1681) |Sender:=20 |To:=20=22Muthu=20Arul=22=20,=20=22Br ett=20Tate=22=20; bh=8JM/zCT13mbp5TlVtfmhXL2Kry5/xkdCN8c/dYavAbY=; b=GbQfPGUr9Ri6MeBjQZKW3hjveNQ9D/M0RR/Ovviy8h3wvHiuuo2GAPCkHn RdmiKMcjLUnVTK8XnH6K/+yTZIwuP0VZmek07OFMUcdKhUvX74H05r9V+yrm HTk3u0NlOS; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 08:14:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98B57.A47DBE0C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pl. see inline ... ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Muthu Arul Sent: Tuesday, February 10, 2009 10:27 AM To: Brett Tate Cc: SIP Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) =09 =09 If the From tag doesn't change, can the UAS retrain the same To tag as well?=20 [Sanjay Sinha (sanjsinh)] When can UAS retain to-tag, when it is rejecting *resubmitted* request? =20 If the new INVITE reaches the UAS before the ACK for the previous INVITE, what should the UAS do?=20 [Sanjay Sinha (sanjsinh)] Since the resubmitted request will not have a to-tag, even if Call-Id and from-tag is same, it wont match any ongoing transaction and so should be treated as a new request.=20 =20 Should it reject the new INVITE and expect the UAC to retry again? =09 I thought it would have been much simpler had the From/To tag changed b/w the INVITE messages.. [Sanjay Sinha (sanjsinh)] It would have been better, but it is not illegal for Call-id + from-tag to not change. Besides, it is an example and should be treated as such..=20 =09 thanks, Muthu =09 =09 On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate wrote: =09 Based upon the following snippet, my understanding is that RFC 4028 is correctly following the SHOULD. =09 RFC 3261 section 8.1.3.5 snippet: =09 "In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case." =09 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dale > Worley > Sent: Monday, February 09, 2009 4:14 PM > To: SIP > Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) > > On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks wrote: > > I agree - the example is not flawed (at least in the way the errata > > reports). > > > > Muthu seems to troubled by the reuse of the call-id and from tag when > > the initial transaction didn't create a dialog. > > While doing so is not required by the specification, nothing makes it > > illegal either. > > Are we agreed that "doing so is not required by the specification"? In > RFC 3261, requests that are retried after 401, 407, 413, 415, 416, and > 420 responses are required to have the same from-tag as the original > request. Is 422 different? > > Dale > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C98B57.A47DBE0C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pl.=20 see inline ...
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Muthu = Arul
Sent:=20 Tuesday, February 10, 2009 10:27 AM
To: Brett = Tate
Cc:=20 SIP
Subject: Re: [Sip] [Technical Errata Reported] RFC4028=20 (1681)

If the From tag doesn't change, can the UAS retrain the same To = tag as=20 well?
[Sanjay Sinha (sanjsinh)]  When can UAS retain = to-tag,=20 when it is rejecting *resubmitted* request?
 
 If the new INVITE reaches the = UAS before=20 the ACK for the previous INVITE, what should the UAS do?
[Sanjay Sinha=20 (sanjsinh)] Since the resubmitted request will not have a to-tag, = even if Call-Id and from-tag is same, it wont match any = ongoing=20 transaction and so should be treated as a new=20 request. 
 
Should it reject the new INVITE and expect the UAC to retry=20 again?

I thought it would have been much simpler had the = From/To tag=20 changed b/w the INVITE messages..
[Sanjay Sinha (sanjsinh)]  = It would=20 have been better, but it is not illegal for Call-id + from-tag to = not change. Besides, it is an example and should be treated as=20 such.. 

thanks,
Muthu

On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate = <brett@broadsoft.com> = wrote:
Based=20 upon the following snippet, my understanding is that RFC 4028 is = correctly=20 following the SHOULD.

RFC 3261 section 8.1.3.5 = snippet:

"In=20 all of the above cases, the request is retried by creating a new = request=20 with the appropriate modifications.  This new request = constitutes a new=20 transaction and SHOULD have the same value of the Call-ID, To, and = >From of=20 the previous request, but the CSeq should contain a new sequence = number that=20 is one higher than the previous. With other 4xx responses, including = those=20 yet to be defined, a retry may or may not be possible depending on = the=20 method and the use case."

> -----Original Message-----
> = From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] On = Behalf Of=20 Dale
> Worley
> Sent: Monday, February 09, 2009 4:14 = PM
>=20 To: SIP
> Subject: Re: [Sip] [Technical Errata Reported] = RFC4028=20 (1681)
>
> On Mon, 2009-02-09 at 13:03 -0600, Robert = Sparks=20 wrote:
> > I agree - the example is not flawed (at least in = the way=20 the errata
> > reports).
> >
> > Muthu = seems to=20 troubled by the reuse of the call-id and from tag when
> > = the=20 initial transaction didn't create a dialog.
> > While doing = so is=20 not required by the specification, nothing makes it
> > = illegal=20 either.
>
> Are we agreed that "doing so is not required = by the=20 specification"?  In
> RFC 3261, requests that are retried = after=20 401, 407, 413, 415, 416, and
> 420 responses are required to = have the=20 same from-tag as the original
> request.  Is 422=20 different?
>
> Dale
>
>
>=20 _______________________________________________
> Sip mailing = list=20  https://www.ietf.org/mailman/listinfo/sip
> = This=20 list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
> Use sipping@ietf.org for new = developments on=20 the application of=20 sip
_______________________________________________
Sip = mailing list=20  https://www.ietf.org/mailman/listinfo/sip
This = list is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of=20 sip

------_=_NextPart_001_01C98B57.A47DBE0C-- From muthu.arul@gmail.com Tue Feb 10 06:55:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3541B3A6BF1 for ; Tue, 10 Feb 2009 06:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 i-tBFOlS9c5L for ; Tue, 10 Feb 2009 06:55:41 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id E9EB03A6B76 for ; Tue, 10 Feb 2009 06:55:40 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2634100wfd.31 for ; Tue, 10 Feb 2009 06:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nam20jpRlgZdItE4hYxBeMS5d/iMw28gspO30jshtcY=; b=k9Ox1eIL8w2fZc65M/y0498UgDi+LcuzeEEhihj2N3EvsmdTwXcUrYbdSI2JvLAwQB SVLtvGDCLnXho6YN7OQ+QrIdi8I+SydBqcphIRPE9kyP5M1OWwFLvz/NYmVfySgsgNH0 B72zIOkg50Fn51F84jE8GZljYw0yOGVmZyMX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V9I2M8Fpwu/tQ/7rmjyWw9ZCKVrF5TwZkh0GZRs9+6m/15es5NdK+6cDAa/Y2tEJOu 7nx4r+R97mDejOsOjz3B8+OUWUQtBhwJB0kuwHI/kZgs2zkR5Oe40UXmcZoS5rKaJCRS jMKrIqt3qGGJgQIMV12XrUns7lABLxSkrEVYE= MIME-Version: 1.0 Received: by 10.114.148.2 with SMTP id v2mr4477498wad.169.1234277743513; Tue, 10 Feb 2009 06:55:43 -0800 (PST) In-Reply-To: References: <200902091736.n19HaYee027174@boreas.isi.edu> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> <1234214049.4033.62.camel@victoria-pingtel-com.us.nortel.com> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DF1E@mbx02.citservers.local> <8c400f2e0902092057y5b98ce09nc69e5748d6032faa@mail.gmail.com> Date: Tue, 10 Feb 2009 20:25:43 +0530 Message-ID: <8c400f2e0902100655g3e62afafmec4e5f90a5fa950f@mail.gmail.com> From: Muthu Arul To: "Sanjay Sinha (sanjsinh)" Content-Type: multipart/alternative; boundary=0016e64f809074d30f046291ae0d Cc: SIP , Brett Tate Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 14:55:42 -0000 --0016e64f809074d30f046291ae0d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Another source of confusion is that section 8.1.3.5 of RFC 3261 says the new INVITE request SHOULD use same value of Call-ID, To and From as the previous INVITE request. It is not clear whether it means just the same value of the URI portion of To and From or also the same tags. If it means the same tags then it is probably wrong --the new INVITE request can not have a To tag, since the dialog is already gone. Muthu On Tue, Feb 10, 2009 at 1:44 PM, Sanjay Sinha (sanjsinh) wrote: > Pl. see inline ... > > ------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On Behalf Of *Muthu > Arul > *Sent:* Tuesday, February 10, 2009 10:27 AM > *To:* Brett Tate > *Cc:* SIP > *Subject:* Re: [Sip] [Technical Errata Reported] RFC4028 (1681) > > If the From tag doesn't change, can the UAS retrain the same To tag as > well? > [Sanjay Sinha (sanjsinh)] When can UAS retain to-tag, when it is rejecting > *resubmitted* request? > > If the new INVITE reaches the UAS before the ACK for the previous INVITE, > what should the UAS do? > [Sanjay Sinha (sanjsinh)] Since the resubmitted request will not have a > to-tag, even if Call-Id and from-tag is same, it wont match any ongoing > transaction and so should be treated as a new request. > > Should it reject the new INVITE and expect the UAC to retry again? > > I thought it would have been much simpler had the From/To tag changed b/w > the INVITE messages.. > [Sanjay Sinha (sanjsinh)] It would have been better, but it is not illegal > for Call-id + from-tag to not change. Besides, it is an example and should > be treated as such.. > > thanks, > Muthu > > On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate wrote: > >> Based upon the following snippet, my understanding is that RFC 4028 is >> correctly following the SHOULD. >> >> RFC 3261 section 8.1.3.5 snippet: >> >> "In all of the above cases, the request is retried by creating a new >> request with the appropriate modifications. This new request constitutes a >> new transaction and SHOULD have the same value of the Call-ID, To, and From >> of the previous request, but the CSeq should contain a new sequence number >> that is one higher than the previous. With other 4xx responses, including >> those yet to be defined, a retry may or may not be possible depending on the >> method and the use case." >> >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Dale >> > Worley >> > Sent: Monday, February 09, 2009 4:14 PM >> > To: SIP >> > Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) >> > >> > On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks wrote: >> > > I agree - the example is not flawed (at least in the way the errata >> > > reports). >> > > >> > > Muthu seems to troubled by the reuse of the call-id and from tag when >> > > the initial transaction didn't create a dialog. >> > > While doing so is not required by the specification, nothing makes it >> > > illegal either. >> > >> > Are we agreed that "doing so is not required by the specification"? In >> > RFC 3261, requests that are retried after 401, 407, 413, 415, 416, and >> > 420 responses are required to have the same from-tag as the original >> > request. Is 422 different? >> > >> > Dale >> > >> > >> > _______________________________________________ >> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > --0016e64f809074d30f046291ae0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another source of confusion is that section 8.1.3.5 of RFC 3261 says the ne= w INVITE request SHOULD use same value of Call-ID, To and From as the previ= ous INVITE request. It is not clear whether it means just the same value of= the URI portion of To and From or also the same tags.

If it means the same tags then it is probably wrong --the new INVITE re= quest can not have a To tag, since the dialog is already gone.

Muthu=

On Tue, Feb 10, 2009 at 1:44 PM, Sanjay = Sinha (sanjsinh) <sanjsinh@cisco.com> wrote:
Pl.=20 see inline ...
From: sip-bounces@ietf.org=20 [mailto:sip-bou= nces@ietf.org] On Behalf Of Muthu Arul
Sent:=20 Tuesday, February 10, 2009 10:27 AM
To: Brett Tate
Cc:=20 SIP

Subject: Re: [Sip] [Technical Errata = Reported] RFC4028=20 (1681)

If the From tag doesn't change, can the UA= S retrain the same To tag as=20 well?
[= Sanjay Sinha (sanjsinh)]  When can UAS retain to-tag,=20 when it is rejecting *resubmitted* request?
 
 If the new INV= ITE reaches the UAS before=20 the ACK for the previous INVITE, what should the UAS do?
= [Sanjay Sinha=20 (sanjsinh)] Since the resubmitted request will not have a to-tag,=20 even if Call-Id and from-tag is same, it wont match any ongoing= =20 transaction and so should be treated as a new=20 request. 
 
Should it reject the new INVITE and expect the= UAC to retry=20 again?

I thought it would have been much simpler had the From/To t= ag=20 changed b/w the INVITE messages..
[Sanjay Sinha (sanjsinh)]  It would=20 have been better, but it is not illegal for Call-id + from-tag to=20 not change. Besides, it is an example and should be treated as=20 such.. 

thanks,
Muthu

On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate <brett@broadsoft.com>=20 wrote:
Based=20 upon the following snippet, my understanding is that RFC 4028 is correc= tly=20 following the SHOULD.

RFC 3261 section 8.1.3.5 snippet:

&= quot;In=20 all of the above cases, the request is retried by creating a new reques= t=20 with the appropriate modifications.  This new request constitutes = a new=20 transaction and SHOULD have the same value of the Call-ID, To, and From= of=20 the previous request, but the CSeq should contain a new sequence number= that=20 is one higher than the previous. With other 4xx responses, including th= ose=20 yet to be defined, a retry may or may not be possible depending on the= =20 method and the use case."

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:= sip-bounces@ietf.= org] On Behalf Of=20 Dale
> Worley
> Sent: Monday, February 09, 2009 4:14 PM
= >=20 To: SIP
> Subject: Re: [Sip] [Technical Errata Reported] RFC4028= =20 (1681)
>
> On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks= =20 wrote:
> > I agree - the example is not flawed (at least in th= e way=20 the errata
> > reports).
> >
> > Muthu seems= to=20 troubled by the reuse of the call-id and from tag when
> > the= =20 initial transaction didn't create a dialog.
> > While doin= g so is=20 not required by the specification, nothing makes it
> > illega= l=20 either.
>
> Are we agreed that "doing so is not requir= ed by the=20 specification"?  In
> RFC 3261, requests that are retri= ed after=20 401, 407, 413, 415, 416, and
> 420 responses are required to have= the=20 same from-tag as the original
> request.  Is 422=20 different?
>
> Dale
>
>
>=20 _______________________________________________
> Sip mailing lis= t=20  https://www.ietf.org/mailman/listinfo/sip
> This=20 list is for NEW development of the core SIP Protocol
> Use sip-impleme= ntors@cs.columbia.edu=20 for questions on current sip
> Use sipping@ietf.org for new developments on=20 the application of=20 sip
_______________________________________________
Sip mailing l= ist=20  https://www.ietf.org/mailman/listinfo/sip
This list is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new developments on=20 the application of=20 sip


--0016e64f809074d30f046291ae0d-- From BPenfield@acmepacket.com Tue Feb 10 08:58:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C83E28C0DF for ; Tue, 10 Feb 2009 08:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, 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 hGjWrLkrAySK for ; Tue, 10 Feb 2009 08:58:05 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A67FE3A69AD for ; Tue, 10 Feb 2009 08:58:04 -0800 (PST) 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.291.1; Tue, 10 Feb 2009 11:56:48 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 10 Feb 2009 11:56:48 -0500 From: Bob Penfield To: Muthu Arul , "Sanjay Sinha (sanjsinh)" Date: Tue, 10 Feb 2009 11:56:47 -0500 Thread-Topic: [Sip] [Technical Errata Reported] RFC4028 (1681) Thread-Index: AcmLj5J3JBjpSq0XQIyzsIXHuUH4hAABs9PQ Message-ID: References: <200902091736.n19HaYee027174@boreas.isi.edu> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> <1234214049.4033.62.camel@victoria-pingtel-com.us.nortel.com> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DF1E@mbx02.citservers.local> <8c400f2e0902092057y5b98ce09nc69e5748d6032faa@mail.gmail.com> <8c400f2e0902100655g3e62afafmec4e5f90a5fa950f@mail.gmail.com> In-Reply-To: <8c400f2e0902100655g3e62afafmec4e5f90a5fa950f@mail.gmail.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_E6C2E8958BA59A4FB960963D475F7AC313DDD5BE6Dmail_" MIME-Version: 1.0 Cc: SIP , Brett Tate Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 16:58:06 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC313DDD5BE6Dmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text in 8.1.3.5 means that the From and To headers in the new INVITE sh= ould have the same value including tags as the rejected INVITE. If it was a= n initial (out-of-dialog) INVITE, there will be no to-tag in the To, and th= us the re-submitted request will not have a to-tag either. There is no need= to change the Call-ID or the from tag because no dialogs were created. If it is an in-dialog request, it must have the same tags otherwise it will= not match the dialog. This could happen if authentication is required for = in-dialog requests and the UAC did not include the credentials, or the cred= entials are stale. >From an implementation point of view, it is simpler if the procedures for r= e-submitting requests for repairable 4xx errors are the same for in-dialog = and out-of-dialog requests. I see no reason to change the Call-ID or from tag. As for the question "If the From tag doesn't change, can the UAS retrain th= e same To tag as well?", I would say that UAS should not use the same to-ta= g for a new request. cheers, (-:bob ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Muthu= Arul Sent: Tuesday, February 10, 2009 9:56 AM To: Sanjay Sinha (sanjsinh) Cc: SIP; Brett Tate Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) Another source of confusion is that section 8.1.3.5 of RFC 3261 says the ne= w INVITE request SHOULD use same value of Call-ID, To and From as the previ= ous INVITE request. It is not clear whether it means just the same value of= the URI portion of To and From or also the same tags. If it means the same tags then it is probably wrong --the new INVITE reques= t can not have a To tag, since the dialog is already gone. Muthu On Tue, Feb 10, 2009 at 1:44 PM, Sanjay Sinha (sanjsinh) > wrote: Pl. see inline ... ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces= @ietf.org] On Behalf Of Muthu Arul Sent: Tuesday, February 10, 2009 10:27 AM To: Brett Tate Cc: SIP Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) If the From tag doesn't change, can the UAS retrain the same To tag as well= ? [Sanjay Sinha (sanjsinh)] When can UAS retain to-tag, when it is rejecting= *resubmitted* request? If the new INVITE reaches the UAS before the ACK for the previous INVITE, = what should the UAS do? [Sanjay Sinha (sanjsinh)] Since the resubmitted request will not have a to-= tag, even if Call-Id and from-tag is same, it wont match any ongoing transa= ction and so should be treated as a new request. Should it reject the new INVITE and expect the UAC to retry again? I thought it would have been much simpler had the From/To tag changed b/w t= he INVITE messages.. [Sanjay Sinha (sanjsinh)] It would have been better, but it is not illegal= for Call-id + from-tag to not change. Besides, it is an example and should= be treated as such.. thanks, Muthu On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate > wrote: Based upon the following snippet, my understanding is that RFC 4028 is corr= ectly following the SHOULD. RFC 3261 section 8.1.3.5 snippet: "In all of the above cases, the request is retried by creating a new reques= t with the appropriate modifications. This new request constitutes a new t= ransaction and SHOULD have the same value of the Call-ID, To, and From of t= he previous request, but the CSeq should contain a new sequence number that= is one higher than the previous. With other 4xx responses, including those= yet to be defined, a retry may or may not be possible depending on the met= hod and the use case." > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounc= es@ietf.org] On Behalf Of Dale > Worley > Sent: Monday, February 09, 2009 4:14 PM > To: SIP > Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) > > On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks wrote: > > I agree - the example is not flawed (at least in the way the errata > > reports). > > > > Muthu seems to troubled by the reuse of the call-id and from tag when > > the initial transaction didn't create a dialog. > > While doing so is not required by the specification, nothing makes it > > illegal either. > > Are we agreed that "doing so is not required by the specification"? In > RFC 3261, requests that are retried after 401, 407, 413, 415, 416, and > 420 responses are required to have the same from-tag as the original > request. Is 422 different? > > Dale > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the= application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the a= pplication of sip --_000_E6C2E8958BA59A4FB960963D475F7AC313DDD5BE6Dmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The text in 8.1.3.5 means that the From = and To=20 headers in the new INVITE should have the same value including tags as=20 the rejected INVITE. If it was an initial (out-of-dialog) INVITE, ther= e=20 will be no to-tag in the To, and thus the re-submitted request will not hav= e a=20 to-tag either. There is no need to change the Call-ID or the from tag becau= se no=20 dialogs were created.
 
If it is an in-dialog request, it must have the sa= me tags=20 otherwise it will not match the dialog. This could happen if authentication= is=20 required for in-dialog requests and the UAC did not include the credentials= , or=20 the credentials are stale.
 
From an implementation point of view, it is simple= r if the=20 procedures for re-submitting requests for repairable 4xx errors are th= e=20 same for in-dialog and out-of-dialog requests.
 
I see no reason to change the Call-ID or from=20 tag.
 
As for the question "If the From tag doesn't chang= e, can=20 the UAS retrain the same To tag as well?", I would say that UAS should not = use=20 the same to-tag for a new request.
 
cheers,
(-:bob

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Muthu Arul
Sent:=20 Tuesday, February 10, 2009 9:56 AM
To: Sanjay Sinha=20 (sanjsinh)
Cc: SIP; Brett Tate
Subject: Re: [Sip] [Tech= nical=20 Errata Reported] RFC4028 (1681)

Another source of confusion is that section 8.1.3.5 of RFC 3261 = says=20 the new INVITE request SHOULD use same value of Call-ID, To and From as the= =20 previous INVITE request. It is not clear whether it means just the same val= ue of=20 the URI portion of To and From or also the same tags.

If it means th= e=20 same tags then it is probably wrong --the new INVITE request can not have a= To=20 tag, since the dialog is already gone.

Muthu

On Tue, Feb 10, 2009 at 1:44 PM, Sanjay Sinha (san= jsinh)=20 <sanjsinh@cisco.com> wrote:=
Pl. see inline=20 ...
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.o= rg]=20 On Behalf Of Muthu Arul
Sent: Tuesday, February 10, 20= 09=20 10:27 AM
To: Brett Tate
Cc: SIP

Subject: Re: [Sip] [Technical Errata Rep= orted]=20 RFC4028 (1681)

If the From tag doesn't change, can the UAS retrain= the=20 same To tag as well?
[Sanjay Sinha (sanjsinh)]  When can UAS retain = to-tag,=20 when it is rejecting *resubmitted* request?
 
 If the new INVITE r= eaches=20 the UAS before the ACK for the previous INVITE, what should the UAS do?= =20
[Sanjay Sin= ha=20 (sanjsinh)] Since the resubmitted request will not have a to-tag,= =20 even if Call-Id and from-tag is same, it wont match any ongoi= ng=20 transaction and so should be treated as a new=20 request. 
&n= bsp;
Should it reject the new INVITE and expect the UAC = to=20 retry again?

I thought it would have been much simpler had the=20 From/To tag changed b/w the INVITE messages..
[Sanjay Sinha (sanjsinh)] =20 It would have been better, but it is not illegal for Call-id = +=20 from-tag to not change. Besides, it is an example and should be tr= eated=20 as such.. 

thanks,
Muthu

On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate <brett@broadsoft.com> wrote:
Based=20 upon the following snippet, my understanding is that RFC 4028 is corr= ectly=20 following the SHOULD.

RFC 3261 section 8.1.3.5 snippet:
"In=20 all of the above cases, the request is retried by creating a new requ= est=20 with the appropriate modifications.  This new request constitute= s a=20 new transaction and SHOULD have the same value of the Call-ID, To, an= d=20 From of the previous request, but the CSeq should contain a new seque= nce=20 number that is one higher than the previous. With other 4xx responses= ,=20 including those yet to be defined, a retry may or may not be possible= =20 depending on the method and the use case."

> -----Original Message-----
> From: sip-bounces@ietf= .org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Dale
>=20 Worley
> Sent: Monday, February 09, 2009 4:14 PM
> To:=20 SIP
> Subject: Re: [Sip] [Technical Errata Reported] RFC4028=20 (1681)
>
> On Mon, 2009-02-09 at 13:03 -0600, Robert Spar= ks=20 wrote:
> > I agree - the example is not flawed (at least in = the=20 way the errata
> > reports).
> >
> > Muthu= =20 seems to troubled by the reuse of the call-id and from tag when
&g= t;=20 > the initial transaction didn't create a dialog.
> > Whi= le=20 doing so is not required by the specification, nothing makes it
&g= t;=20 > illegal either.
>
> Are we agreed that "doing so is = not=20 required by the specification"?  In
> RFC 3261, requests t= hat=20 are retried after 401, 407, 413, 415, 416, and
> 420 responses = are=20 required to have the same from-tag as the original
> request.=20  Is 422 different?
>
> Dale
>
>
>= =20 _______________________________________________
> Sip mailing l= ist=20  https://www.ietf.org/mailman/listinfo/sip
>= This=20 list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on= =20 current sip
> Use sipping@ietf.org for new developments on the appl= ication=20 of sip
_______________________________________________
Sip mail= ing=20 list  https://www.ietf.org/mailman/listinfo/sip
This= list=20 is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on= =20 current sip
Use sipping@ietf.org for new developments on the appl= ication=20 of=20 sip


--_000_E6C2E8958BA59A4FB960963D475F7AC313DDD5BE6Dmail_-- From dworley@nortel.com Tue Feb 10 09:12:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52753A6C09 for ; Tue, 10 Feb 2009 09:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 K951tbMwNokA for ; Tue, 10 Feb 2009 09:12:30 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 9BE2A3A6A59 for ; Tue, 10 Feb 2009 09:12:30 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1AHCME29949; Tue, 10 Feb 2009 17:12:22 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 12:12:22 -0500 From: "Dale Worley" To: Bob Penfield In-Reply-To: References: <200902091736.n19HaYee027174@boreas.isi.edu> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DE5F@mbx02.citservers.local> <1234214049.4033.62.camel@victoria-pingtel-com.us.nortel.com> <9B2A061A1137254BBE4F4B2CD843646A0FD3B1DF1E@mbx02.citservers.local> <8c400f2e0902092057y5b98ce09nc69e5748d6032faa@mail.gmail.com> <8c400f2e0902100655g3e62afafmec4e5f90a5fa950f@mail.gmail.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 10 Feb 2009 12:12:21 -0500 Message-Id: <1234285941.4275.7.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2009 17:12:22.0430 (UTC) FILETIME=[BCBDFBE0:01C98BA2] Cc: "Sanjay Sinha \(sanjsinh\)" , SIP , Brett Tate Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 17:12:31 -0000 On Tue, 2009-02-10 at 11:56 -0500, Bob Penfield wrote: > The text in 8.1.3.5 means that the From and To headers in the new > INVITE should have the same value including tags as the rejected > INVITE. If it was an initial (out-of-dialog) INVITE, there will be no > to-tag in the To, and thus the re-submitted request will not have a > to-tag either. There is no need to change the Call-ID or the from tag > because no dialogs were created. > > If it is an in-dialog request, it must have the same tags otherwise it > will not match the dialog. This could happen if authentication is > required for in-dialog requests and the UAC did not include the > credentials, or the credentials are stale. > > From an implementation point of view, it is simpler if the procedures > for re-submitting requests for repairable 4xx errors are the same for > in-dialog and out-of-dialog requests. > > I see no reason to change the Call-ID or from tag. All of the above matches my understanding and the discussions that I've seen here. > As for the question "If the From tag doesn't change, can the UAS > retrain the same To tag as well?", I would say that UAS should not use > the same to-tag for a new request. I'm sure that the UAS should not use the same to-tag in its response to the new request -- the first request did not establish a dialog, so the second request could not be part of that dialog. And indeed, it would be difficult to build a UAS that did use the same to-tag, as it would have to remember the to-tag it used in the first request and use it in the second -- but nonetheless, if it received two copies of the first INVITE and rejected both, it would have to use different to-tags for the two error responses. Dale From web-usrn@ISI.EDU Tue Feb 10 13:34:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2703A6D3E for ; Tue, 10 Feb 2009 13:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.828 X-Spam-Level: X-Spam-Status: No, score=-16.828 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnBOoY+0pf3b for ; Tue, 10 Feb 2009 13:34:53 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id C59463A6D0C for ; Tue, 10 Feb 2009 13:34:53 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n1ALXX2t022902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Feb 2009 13:33:34 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n1ALXTb8022755; Tue, 10 Feb 2009 13:33:29 -0800 (PST) Date: Tue, 10 Feb 2009 13:33:29 -0800 (PST) Message-Id: <200902102133.n1ALXTb8022755@boreas.isi.edu> To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, Gonzalo.Camarillo@ericsson.com, alan.johnston@wcom.com, jon.peterson@neustar.com, rsparks@dynamicsoft.com, mjh@icir.org, schooler@research.att.com, jon.peterson@neustar.biz, fluffy@cisco.com, dean.willis@softarmor.com, drage@alcatel-lucent.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: sip@ietf.org, ibc@aliax.net, rfc-editor@rfc-editor.org Subject: [Sip] [Technical Errata Reported] RFC3261 (1682) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 21:34:54 -0000 The following errata report has been submitted for RFC3261, "SIP: Session Initiation Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=1682 -------------------------------------- Type: Technical Reported by: Iñaki Baz Castillo Section: 20.7 Original Text ------------- Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e", response="7587245234b3434cc3412213e5f113a5432" Corrected Text -------------- Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e", response="7587245234b3434cc3412213e5f113a5" Notes ----- 'response' field in original example has 35 hexadecimal characters while they must be 32: dresponse = "response" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3261 (draft-ietf-sip-rfc2543bis-09) -------------------------------------- Title : SIP: Session Initiation Protocol Publication Date : June 2002 Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler Category : PROPOSED STANDARD Source : Session Initiation Protocol Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From mary.barnes@nortel.com Wed Feb 11 08:42:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E383A6B1C for ; Wed, 11 Feb 2009 08:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 ck+SJUvomwtW for ; Wed, 11 Feb 2009 08:42:33 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 291D73A6A13 for ; Wed, 11 Feb 2009 08:42:32 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1BGgXG14822 for ; Wed, 11 Feb 2009 16:42:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Feb 2009 10:44:37 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1C331157@zrc2hxm0.corp.nortel.com> In-Reply-To: <1233518036.5226.1.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Problems with History-Info Thread-Index: AcmEpt+I3Ooi7mVxQF2BrxHuWFhY6AHvsCCg References: <1233518036.5226.1.camel@victoria-pingtel-com.us.nortel.com> From: "Mary Barnes" To: "Dale Worley" , "SIP" Subject: Re: [Sip] Problems with History-Info X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 16:42:35 -0000 Hi Dale, Sorry for the delay in responding - responses below [MB]. Mary. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Worley, Dale (BL60:9D30) Sent: Sunday, February 01, 2009 1:54 PM To: SIP Subject: [Sip] Problems with History-Info To get discussion going for 2009, let me start with some complaints about the History-Info header. One problem is identifying which value in the History-Info header corresponds to the request carrying the header, that is, which branch of the History-Info request tree represents the current request. Reading RFC 4244, it's clear that what is intended is that the History-Info values will be written in depth-first tree-walk order, and that syntactically *last* value corresponds to the request carrying the History-Info header. Neither of these principles is stated explicitly as far as I can tell.=20 [MB] RFC 4244 is clear that the entries are in a tree structure - you are correct that we don't identify it as a "depth-first" and perhaps we can add that, although I think it's quite clear from examples and normative text. As far as your concern wrt to "synctactically *last* value corresponds to the request carrying HI", I'm not sure what you mean here. [/MB] Difficulty arises when there is parallel forking, or any similar situation when a request has multiple redirects or retargets that become known in one processing step. If one maintains the rule that the enclosing request corresponds to the last History-Info value, one must choose among: [MB] There is not a problem here. The spec is very clear about what happens when a proxy (sip:1@example.com) retargets either sequentially or in parallel. And, RFC 4244 defines a 4th choice not listed below: =20 INVITE sip:1A@example.com History-Info: ;index=3D1, ;index=3D1.1 INVITE sip:1B@example.com History-Info: ;index=3D1, ;index=3D1.2 This is specified in section 4.3.3.1.3, in particular steps 2 and 3 result in the above HI entries with an example of this behavior in section 4.5 (sorry no figure number - something we should add in the -bis). Per the spec, there are never any entries that are identical - if there, it's a bug. If you think there is text in RFC 4244 that contradicts this, please identify it and we can clarify it in the -bis.=20 [/MB] (Assume that sip:1@example.com has been retargeted to sip:1A@example.com and sip:1B@example.com.)=20 1.each derived request carries only one of the new History-Info values INVITE sip:1A@example.com History-Info: ;index=3D1, ;index=3D1.1 INVITE sip:1B@example.com History-Info: ;index=3D1, ;index=3D1.1 2.each derived request carries only the new History-Info values that are "before" (in some ordering) the one for the current request INVITE sip:1A@example.com History-Info: ;index=3D1, ;index=3D1.1 INVITE sip:1B@example.com History-Info: ;index=3D1, ;index=3D1.1, ;index=3D1.2 3.each derived request carries all of the new History-Info values, but in each request, they are ordered so that the value corresponding to the request is last INVITE sip:1A@example.com History-Info: ;index=3D1, ;index=3D1.1, ;index=3D1.2 INVITE sip:1B@example.com History-Info: ;index=3D1, ;index=3D1.1, ;index=3D1.2 Solutions 1 and 3 are troublesome because the generated History-Info values are not consistent between the derived requests, and solutions 1 and 2 are troublesome because the downstream network elements are given less information than is available about the forking of the request. Note that this isn't just a theoretical problem, draft-rosenberg-sip-target-uri-delivery-00 is already running up against it (section 5): "Furthermore, if that URI had an 'index' of N, the URIs with indices N.M for all M, are the registered contacts to that URI." If the I-D is taken at face value, solution 3 must be used, giving different History-Info values on different derived requests. Let us then consider putting all known targets of a request in History-Info, but not require that the last History-Info value corresponds to the containing request. In terms of the above example, both derived requests would have the same History-Info header: INVITE sip:1A@example.com History-Info: ;index=3D1, ;index=3D1.1, ;index=3D1.2 INVITE sip:1B@example.com History-Info: ;index=3D1, ;index=3D1.1, ;index=3D1.2 If we do this, we need to be able to identify the value that corresponds to the current request by some method other than the index values and syntactic ordering. In a perfect world, we could compare the request-URI with the URIs in History-Info to see which one matches. However, this fails if: - two URIs in History-Info are the same (In theory, this should not happen, but it can happen sensibly if two derived requests differed substantially in some manner which could affect the ultimate resolution of the request-URI; e.g., caller preferences.) - if an intermediate proxy has changed the request-URI but not updated History-Info (In this case, we want to know which History-Info value corresponds to the most recent parent request that was logged in History-Info.) A more reliable solution would be to add a "current" marker to the leaf of the History-Info tree that corresponds to the containing request. In the example above: INVITE sip:1A@example.com History-Info: ;index=3D1, ;index=3D1.1;current, ;index=3D1.2 INVITE sip:1B@example.com History-Info: ;index=3D1, ;index=3D1.1, ;index=3D1.2;current ---------------------------------------------------------------------- A second problem with History-Info as it is currently structured is in the handling of requests generated as a consequence of recursing on 3xx responses. History-Info as it is now defined correctly shows the "forking structure" of a request. But we also want to know the "derivation" of the current request-URI, the sequence of transformations from the original request-URI (presumably the same as the To URI) to the current request-URI. Assuming that the transformations are done in the ordinary manner by proxies, History-Info carries the needed information. From RFC 4244 section 4.5: UA1 Proxy1 Proxy2 UA2 | | | | |--INVITE sip:Bob@P1... -->| | | History-Info: ;index=3D1 | |-INVITE sip:Bob@P2... -->| | History-Info: ;index=3D1, =20 ;index=3D1.1 | | | | | | |-INVITE sip:User2@UA2...-->| History-Info: ;index=3D1, =20 ;index=3D1.1, =20 ;index=3D1.1.1 In the last INVITE, starting with the last URI and working our way up the tree, we see that the URI sequence is: sip:Bob@P1.example.com -> sip:Bob@P2.example.com -> sip:User2@UA2.example.com However, if one of the transformations is supplied by a 3xx response (e.g., if the request is sent to a "redirect server"), the History-Info data does not effectively show the source of the current request-URI: UA1 Proxy1 Proxy2 UA2 | | | | |--INVITE sip:Bob@P1... -->| | | History-Info: ;index=3D1 | |-INVITE sip:Bob@P2... -->| | History-Info: ;index=3D1, =20 ;index=3D1.1 | |<-- 302 Contact: | | | | | |-INVITE sip:User2@UA2...----------->| History-Info: ;index=3D1, =20 ;index=3D1.1, =20 ;index=3D1.2 The apparent URI sequence is: sip:Bob@P1.example.com -> sip:User2@UA2.example.com There is no unambiguous way determine that the target sip:User2@UA2.example.com came from the 302 response to the request to sip:Bob@P2.example.com. =20 [MB] I don't see a problem here, as you can indeed determine that the request was retargetted to User2 as a result of the 3xx - Proxy 1 absolutely knows that and that's the reason why the "reason" is added to the previous HI entry - i.e., the rule being that the reason is associated with the "Why the request was retargeted?" from the previous HI entry (Bob@P2.example.com) to the new HI entry User@UA2.example.com). Thus, you can derive the sequence from the above -i.e., it's ALL there in that last INVITE. It does require that you look for the reason, but you really don't need the redundant data. An old, old version of this document actually did have redundant data in that the "old" and "new" were captured in each entry. The current approach is that if the "old" isn't captured, then the entity retargeting captures it along with the "new" to ensure that you have the entire chain. If you can point to the specific text that seems to introduce the gap you suggest, that would be helpful and we can make sure it's clear in the -bis.=20 [/MB] What is needed is a pointer from a History-Info value to the value representing the request which yielded the 3xx response that cause the value in question. I suggest using a parameter named "3xx" for this purpose, so that the last request in the above example becomes: INVITE sip:User2@UA2.example.com History-Info: ;index=3D1, =09 ;index=3D1.1, ;index=3D1.2;3xx=3D1.1 Which this additional information present, the predecessor of a listed URI is either the URI of its 3xx value (if present), or its parent in the tree. This allows us to recover the URI transformation sequence: sip:Bob@P1.example.com -> sip:Bob@P2.example.com -> sip:User2@UA2.example.com Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From dworley@nortel.com Wed Feb 11 13:44:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F913A6B60 for ; Wed, 11 Feb 2009 13:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 ucnBITVZEZSW for ; Wed, 11 Feb 2009 13:44:26 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id D86E33A6B4D for ; Wed, 11 Feb 2009 13:44:25 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1BLiPe24266 for ; Wed, 11 Feb 2009 21:44:26 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 16:44:25 -0500 From: "Dale Worley" To: "Mary Barnes" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1C331157@zrc2hxm0.corp.nortel.com> References: <1233518036.5226.1.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1C331157@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 11 Feb 2009 16:44:25 -0500 Message-Id: <1234388665.3785.73.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2009 21:44:25.0767 (UTC) FILETIME=[E89F4B70:01C98C91] Cc: SIP Subject: Re: [Sip] Problems with History-Info X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:44:27 -0000 On Wed, 2009-02-11 at 11:44 -0500, Barnes, Mary (RICH2:AR00) wrote: > > Reading RFC 4244, it's clear that what is intended is that the > > History-Info values will be written in depth-first tree-walk order, and > > that syntactically *last* value corresponds to the request carrying the > > History-Info header. Neither of these principles is stated explicitly > > as far as I can tell. > > [MB] RFC 4244 is clear that the entries are in a tree structure - you > are correct that we don't identify it as a "depth-first" and perhaps we > can add that, although I think it's quite clear from examples and > normative text. As far as your concern wrt to "synctactically *last* > value corresponds to the request carrying HI", I'm not sure what you > mean here. [/MB] What I see is that all examples are presented in depth-first order, and various operations are described in terms of "adding a value". But I don't see a specification that the values must be listed in depth-first order, nor that the added values must go in a certain position in the list of values. Given that the values are tagged with indexes, I could interpret the text to mean that the values are associated based on their index values, and it was just convenience or accident that all examples presented in the RFC were written in depth-first order. In regard to "syntactically last", I was looking at the question of knowing which entry in History-Info is meant to describe the request that contains it. It seems from the examples that the current request is described by the linearly last (lowest-rightmost in tree order) element, but it's not clear that is intended to be specified. One could search for the request-URI in the History-Info elements, but (1) URI matching is treacherous, and (2) one can construct cases where the same request-URI can sensibly appear in more than one incarnation of an INVITE. It seems that the intention is that the last element is expected to match the current request, but I don't see that stated. > Difficulty arises when there is parallel forking, or any similar > situation when a request has multiple redirects or retargets that become > known in one processing step. If one maintains the rule that the > enclosing request corresponds to the last History-Info value, one must > choose among: > > [MB] There is not a problem here. The spec is very clear about what > happens when a proxy (sip:1@example.com) retargets either sequentially > or in parallel. And, RFC 4244 defines a 4th choice not listed below: > > INVITE sip:1A@example.com > History-Info: ;index=1, > ;index=1.1 > > INVITE sip:1B@example.com > History-Info: ;index=1, > ;index=1.2 > > This is specified in section 4.3.3.1.3, in particular steps 2 and 3 > result in the above HI entries with an example of this behavior in > section 4.5 (sorry no figure number - something we should add in the > -bis). Per the spec, there are never any entries that are identical - > if there, it's a bug. If you think there is text in RFC 4244 that > contradicts this, please identify it and we can clarify it in the -bis. > [/MB] I'll grant I overlooked that example. The implication is that the tree presented in History-Info can be *incomplete*, there can be a 1.2 branch without a 1.1 branch, not because the user used weird numbering, but because there is a 1.1. branch that is not being described in this History-Info -- something that is not so common in representations of trees, and doesn't seem to be explicitly pointed out in the text. In regard to 4.3.3.1.3, the text is not very clear if you don't already know what it means: Retargeting within a Proxy - subsequent instance: For each subsequent retargeting of a request by the same proxy, another branch is added. With the index for each new branch calculated by incrementing the last/lowest digit at the current level, the index in the next request forwarded by this same proxy, following the example above, would be 1.1.2. What is not stated is that the first forked request gets the xxx.1 value added to its History-Info, the second forked request gets the xxx.2 value added to its History-Info (but not the xxx.1 value), etc. When I read this, I assumed that "instance" meant History-Info value, and that each forked request was expected to have the same set of History-Info values, namely the whole set generated by the forking, of which the first "instance" would be numbers xxx.1, etc. > (Assume that sip:1@example.com has been retargeted to sip:1A@example.com > and sip:1B@example.com.) > > 1.each derived request carries only one of the new History-Info values > > INVITE sip:1A@example.com > History-Info: ;index=1, > ;index=1.1 > > INVITE sip:1B@example.com > History-Info: ;index=1, > ;index=1.1 So the correct answer is case 1, but modified in that the index for sip:1B@example.com is 1.2; the numbering was globally consistent across all the History-Info values, but that each value was a subset of the global forking tree. > [MB] I don't see a problem here, as you can indeed determine that the > request was retargetted to User2 as a result of the 3xx - Proxy 1 > absolutely knows that and that's the reason why the "reason" is added to > the previous HI entry - i.e., the rule being that the reason is > associated with the "Why the request was retargeted?" from the previous > HI entry (Bob@P2.example.com) to the new HI entry User@UA2.example.com). > Thus, you can derive the sequence from the above -i.e., it's ALL there > in that last INVITE. It does require that you look for the reason, but > you really don't need the redundant data. An old, old version of this > document actually did have redundant data in that the "old" and "new" > were captured in each entry. The current approach is that if the "old" > isn't captured, then the entity retargeting captures it along with the > "new" to ensure that you have the entire chain. If you can point to the > specific text that seems to introduce the gap you suggest, that would be > helpful and we can make sure it's clear in the -bis. > [/MB] I was thinking of the case where there are two or more forks preceding the current fork that have returned 3xx. It seems that you'd get H-I like: History-Info: ;index=1, ;index=1.1, ;index=1.2, ;index=1.3 >From that, I don't see how to determine whether UserC was generated from UserA1 or UserB, or for that matter, if it was derived from UserA. Perhaps there is an unstated rule that History-Info should contain only that subset of the global forking tree that describes requests that are logically ancestral to the request that contains it? (Oh, yeah, and the example in RFC 4244 from which I derived the above example is: F12 486 Busy Here Proxy1 -> UA1 SIP/2.0 486 Busy Here Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net History-Info: ; index=1, ;index=1.1, ;index=1.2, ;index=1.3 CSeq: 1 INVITE Content-Length: 0 Note that it presents a case where one request-URI appears in more than one History-Info value, which was a question I raised above.) Dale From brett@broadsoft.com Wed Feb 11 16:00:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F3D3A67E9 for ; Wed, 11 Feb 2009 16:00:08 -0800 (PST) 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 lpIiGCy+HeR0 for ; Wed, 11 Feb 2009 16:00:07 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 6C7213A6403 for ; Wed, 11 Feb 2009 16:00:07 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 11 Feb 2009 16:00:08 -0800 From: Brett Tate To: SIP Date: Wed, 11 Feb 2009 16:00:09 -0800 Thread-Topic: rfc3261: default contact q-value Thread-Index: AcmMpN5enq1IQ8xrQzu/cpOgRz/5nQ== Message-ID: <9B2A061A1137254BBE4F4B2CD843646A0FD7114C59@mbx02.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {8AF6C85C-0739-4DE4-A0FD-0EE282E81486} x-cr-hashedpuzzle: Ar9m BEYS BoJw B2pP C3X7 C/C8 FryT GeX6 IQYv I38w JXVB JoBF LTFK LYtR Mho7 MssA; 1; cwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8AF6C85C-0739-4DE4-A0FD-0EE282E81486}; YgByAGUAdAB0AEAAYgByAG8AYQBkAHMAbwBmAHQALgBjAG8AbQA=; Thu, 12 Feb 2009 00:00:09 GMT; cgBmAGMAMwAyADYAMQA6ACAAZABlAGYAYQB1AGwAdAAgAGMAbwBuAHQAYQBjAHQAIABxAC0AdgBhAGwAdQBlAA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Sip] rfc3261: default contact q-value X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 00:00:08 -0000 Greetings, Within RFC 3261, I was unable to find a default q-value for Contact. Versions 2 through 4 of draft-ietf-sip-rfc2543bis indicated 0.5 as default.= It looks like it was unintentionally removed; however I'm not certain. What is the default Contact q-value and where is it documented? Thanks, Brett From sreeramk@qualcomm.com Wed Feb 11 16:11:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D39928C106 for ; Wed, 11 Feb 2009 16:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V4vL+iqPD4k for ; Wed, 11 Feb 2009 16:11:56 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5D68A3A690A for ; Wed, 11 Feb 2009 16:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sreeramk@qualcomm.com; q=dns/txt; s=qcdkim; t=1234397521; x=1265933521; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Kanumuri,=20Sreeram"=20 |To:=20Brett=20Tate=20,=20SIP=20|Date:=20Wed,=2011=20Feb=202009=2016:11:38=20-0 800|Subject:=20RE:=20rfc3261:=20default=20contact=20q-val ue|Thread-Topic:=20rfc3261:=20default=20contact=20q-value |Thread-Index:=20AcmMpN5enq1IQ8xrQzu/cpOgRz/5nQAAMQ3Q |Message-ID:=20|References:=20<9B2A061A113 7254BBE4F4B2CD843646A0FD7114C59@mbx02.citservers.local> |In-Reply-To:=20<9B2A061A1137254BBE4F4B2CD843646A0FD7114C 59@mbx02.citservers.local>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5523"=3B=20a=3D"15428665"; bh=xhhCEU0bHeEd6Vkh1b5edVkikHAZvrrKzSbED85OxVU=; b=ssWuULV71Wplw5GOkMYKo2xht1k6jT8Hf64FLtWBF3R8OY1m/zIQCMeE eylRYxeeXPB0/oDrrl/F1z4hwiI6hSdLU3zpT/6UeMReVFaHTvFgif33X UEaeqs+o1KbKAYxA0Qm9PAe/hC7q5PQZyR52CkKGfFX2YbMgCkSiYDZdW U=; X-IronPort-AV: E=McAfee;i="5300,2777,5523"; a="15428665" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2009 16:11:45 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1C0BjiO029728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Feb 2009 16:11:45 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1C0BghZ004759 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Feb 2009 16:11:45 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 11 Feb 2009 16:11:42 -0800 Received: from NALASEXMB06.na.qualcomm.com ([10.47.7.244]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 11 Feb 2009 16:11:41 -0800 From: "Kanumuri, Sreeram" To: Brett Tate , SIP Date: Wed, 11 Feb 2009 16:11:38 -0800 Thread-Topic: rfc3261: default contact q-value Thread-Index: AcmMpN5enq1IQ8xrQzu/cpOgRz/5nQAAMQ3Q Message-ID: References: <9B2A061A1137254BBE4F4B2CD843646A0FD7114C59@mbx02.citservers.local> In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A0FD7114C59@mbx02.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: [Sip] rfc3261: default contact q-value X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 00:11:57 -0000 Hi Brett, The default value of q-value is 1. I am not sure when but there was discussion in sip implementers list some t= ime back on this. It takes from HTTP where it is mentioned default is 1 when not specified. HTH, Sreeram -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Brett= Tate Sent: Wednesday, February 11, 2009 4:00 PM To: SIP Subject: [Sip] rfc3261: default contact q-value Greetings, Within RFC 3261, I was unable to find a default q-value for Contact. Versions 2 through 4 of draft-ietf-sip-rfc2543bis indicated 0.5 as default.= It looks like it was unintentionally removed; however I'm not certain. What is the default Contact q-value and where is it documented? Thanks, Brett _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From frank.shearar@angband.za.org Thu Feb 12 00:59:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A2A3A6971 for ; Thu, 12 Feb 2009 00:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4dbOzi9Ex-5 for ; Thu, 12 Feb 2009 00:59:12 -0800 (PST) Received: from mx1.shearar.net (mx1.shearar.net [72.21.63.189]) by core3.amsl.com (Postfix) with ESMTP id AB4303A68CC for ; Thu, 12 Feb 2009 00:59:12 -0800 (PST) Received: from [41.241.61.195] (helo=bismuth) by mx1.shearar.net with smtp (Exim 4.63) (envelope-from ) id 1LXXQm-0006bg-4m for sip@ietf.org; Thu, 12 Feb 2009 11:00:25 +0200 Message-ID: <03ef01c98cf0$2f1fc260$0600000a@newtechnologies.org.uk> From: "Frank Shearar" To: Date: Thu, 12 Feb 2009 10:59:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1933 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 Subject: [Sip] draft-ietf-sip-media-security-requirements-09 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Frank Shearar List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:59:13 -0000 The second last paragraph of section refers to a "active-signaling-active-attack-detect" category. Should that not be "active-signalling-active-media-detect" ? frank From victor.pascual.avila@gmail.com Thu Feb 12 02:00:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8AD3A6927 for ; Thu, 12 Feb 2009 02:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsoNsn-Ld7dY for ; Thu, 12 Feb 2009 02:00:43 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id 02EE13A6880 for ; Thu, 12 Feb 2009 02:00:42 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so60891nfc.39 for ; Thu, 12 Feb 2009 02:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5ozhNFpk4MFJ3BwWgfuqqscdRbLTA/g5MB4LNLXe1Xc=; b=l/LWCRUETX+6RxW/3fx2wHGxPzGhWTFZpPG3Wyxmk0+qjOjePbqv76P3iD26w5m4/5 PveKz2ywuygZUiHXu4tdTofYeZImnQ28fTZsZYIKQ6Edk9Nq1qXosdAS8ZkVTjZ+niV1 ucZ0elKU/f9BomjZzJMDKTJ7hFPRtbNsufrRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fos6SlgrMc6ltF/aQPQF3X1/Wz7G0fBEBe5sUofUGnsZ9/xFFIZoiYoC6zZ75yHdlm NEXJi2MfokBYfZCLGXHhTnIllmLDOg7UnXSAvyAd2fhutLmDoRyF3Wy35VzDZkPm/Tz6 lEm5g6uK1TXixHQGW7BmEzHz/5BZwoZrI4gjA= MIME-Version: 1.0 Received: by 10.210.133.19 with SMTP id g19mr543876ebd.133.1234432847393; Thu, 12 Feb 2009 02:00:47 -0800 (PST) In-Reply-To: References: <9B2A061A1137254BBE4F4B2CD843646A0FD7114C59@mbx02.citservers.local> Date: Thu, 12 Feb 2009 11:00:47 +0100 Message-ID: <618e24240902120200t6ad75674m49002757dd8daadd@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: "Kanumuri, Sreeram" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: SIP , Brett Tate Subject: Re: [Sip] rfc3261: default contact q-value X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 10:00:44 -0000 On Thu, Feb 12, 2009 at 1:11 AM, Kanumuri, Sreeram wrote: > The default value of q-value is 1. https://lists.cs.columbia.edu/pipermail/sip-implementors/2005-November/0112= 37.html > It takes from HTTP where it is mentioned default is 1 when not specified. https://lists.cs.columbia.edu/pipermail/sip-implementors/2005-November/0112= 38.html Regards, --=20 Victor Pascual =C3=81vila From brett@broadsoft.com Thu Feb 12 05:42:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A13A3A69B0 for ; Thu, 12 Feb 2009 05:42:12 -0800 (PST) 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 kueFORdySqZB for ; Thu, 12 Feb 2009 05:42:12 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id E81923A68CC for ; Thu, 12 Feb 2009 05:42:11 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 12 Feb 2009 05:42:13 -0800 From: Brett Tate To: SIP Date: Thu, 12 Feb 2009 05:42:14 -0800 Thread-Topic: rfc3261: default contact q-value Thread-Index: AcmMpN5enq1IQ8xrQzu/cpOgRz/5nQAbnPWA Message-ID: <9B2A061A1137254BBE4F4B2CD843646A0FD7114CA3@mbx02.citservers.local> References: <9B2A061A1137254BBE4F4B2CD843646A0FD7114C59@mbx02.citservers.local> In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A0FD7114C59@mbx02.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: [Sip] rfc3261: default contact q-value X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 13:42:12 -0000 Thanks for the responses, especially the reference to RFC 3841. I guess the working group agreed to remove it from being "0.5" (or document= ed within the rfc2543bis) when creating draft-ietf-sip-rfc2543bis-05 and ag= reed to start documenting it as "1.0" within draft-ietf-sip-callerprefs-06. Including the default value for "q" within the base specification sounds be= tter to me; however documenting the default within RFC 3841 (or non SIP RFC= s as some have indicated) might be adequate. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Brett Tate > Sent: Wednesday, February 11, 2009 7:00 PM > To: SIP > Subject: [Sip] rfc3261: default contact q-value >=20 > Greetings, >=20 > Within RFC 3261, I was unable to find a default q-value for Contact. >=20 > Versions 2 through 4 of draft-ietf-sip-rfc2543bis indicated 0.5 as > default. It looks like it was unintentionally removed; however I'm not > certain. >=20 > What is the default Contact q-value and where is it documented? >=20 > Thanks, > Brett >=20 From mary.barnes@nortel.com Thu Feb 12 09:18:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324BD28C242 for ; Thu, 12 Feb 2009 09:18:36 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 AxJjYQcdXoqB for ; Thu, 12 Feb 2009 09:18:34 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 789C928C224 for ; Thu, 12 Feb 2009 09:18:34 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1CHIa220846 for ; Thu, 12 Feb 2009 17:18:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2009 11:20:58 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1C3D815B@zrc2hxm0.corp.nortel.com> In-Reply-To: <1234388665.3785.73.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Problems with History-Info Thread-Index: AcmMkekJJbqWTTVgRCCZJJR2LQJrFwAClx8Q References: <1233518036.5226.1.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1C331157@zrc2hxm0.corp.nortel.com> <1234388665.3785.73.camel@victoria-pingtel-com.us.nortel.com> From: "Mary Barnes" To: "Dale Worley" Cc: SIP Subject: Re: [Sip] Problems with History-Info X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:18:36 -0000 More responses inline below [MB2]. -----Original Message----- From: Worley, Dale (BL60:9D30)=20 Sent: Wednesday, February 11, 2009 3:44 PM To: Barnes, Mary (RICH2:AR00) Cc: SIP Subject: RE: [Sip] Problems with History-Info On Wed, 2009-02-11 at 11:44 -0500, Barnes, Mary (RICH2:AR00) wrote: > > Reading RFC 4244, it's clear that what is intended is that the=20 > > History-Info values will be written in depth-first tree-walk order,=20 > > and that syntactically *last* value corresponds to the request=20 > > carrying the History-Info header. Neither of these principles is=20 > > stated explicitly as far as I can tell. >=20 > [MB] RFC 4244 is clear that the entries are in a tree structure - you=20 > are correct that we don't identify it as a "depth-first" and perhaps=20 > we can add that, although I think it's quite clear from examples and=20 > normative text. As far as your concern wrt to "synctactically *last* > value corresponds to the request carrying HI", I'm not sure what you=20 > mean here. [/MB] What I see is that all examples are presented in depth-first order, and various operations are described in terms of "adding a value". But I don't see a specification that the values must be listed in depth-first order, nor that the added values must go in a certain position in the list of values. Given that the values are tagged with indexes, I could interpret the text to mean that the values are associated based on their index values, and it was just convenience or accident that all examples presented in the RFC were written in depth-first order. [MB2] With the indices, it actually doesn't matter if the entries are added in depth first order. However, RFC 4244 does specify in section 4.3.3.1 that the entries MUST be added following any HI entry received in the request. Now, certainly, in the parallel forking situation, you wouldn't know if an entry 1.2.1 was really added before an entry 1.3.1, but that's more because the order of responses is entirely indeterminate per core SIP when a request is forked. It might be sensible (but not required for things to work) that the proxy that forked the requests would keep the HI entries grouped logically. We could add a suggestion to this effect in the -bis. [/MB2]=20 In regard to "syntactically last", I was looking at the question of knowing which entry in History-Info is meant to describe the request that contains it. It seems from the examples that the current request is described by the linearly last (lowest-rightmost in tree order) element, but it's not clear that is intended to be specified. One could search for the request-URI in the History-Info elements, but (1) URI matching is treacherous, and (2) one can construct cases where the same request-URI can sensibly appear in more than one incarnation of an INVITE. It seems that the intention is that the last element is expected to match the current request, but I don't see that stated. [MB2] When a proxy receives a request that doesn't have an entry for the hop that got the request to this proxy, then it is suggested to add an entry, so if I understand you, yes, when a request reaches a proxy, the last entry should be the same as the request URI in the request. I don't know how that can be stated more clearly as that's a fundamental to how HI is captured and comprises the basic definition of the "Targeted-to-URI" field in the header per section 4.1. It's also described in section 4.3.1 (UAC behavior). It may not be quite so clear in section 4.3.3.1 (Proxy behavior) and we could be more explicit about that when we discuss that "if the request doesn't contain a History-Info header" to state the "hi-targeted-to-uri" is set to the URI in the request". [/MB2] > Difficulty arises when there is parallel forking, or any similar=20 > situation when a request has multiple redirects or retargets that=20 > become known in one processing step. If one maintains the rule that=20 > the enclosing request corresponds to the last History-Info value, one=20 > must choose among: >=20 > [MB] There is not a problem here. The spec is very clear about what=20 > happens when a proxy (sip:1@example.com) retargets either sequentially > or in parallel. And, RFC 4244 defines a 4th choice not listed below: >=20 > INVITE sip:1A@example.com > History-Info: ;index=3D1, > ;index=3D1.1 >=20 > INVITE sip:1B@example.com > History-Info: ;index=3D1, > ;index=3D1.2 >=20 > This is specified in section 4.3.3.1.3, in particular steps 2 and 3=20 > result in the above HI entries with an example of this behavior in=20 > section 4.5 (sorry no figure number - something we should add in the=20 > -bis). Per the spec, there are never any entries that are identical - > if there, it's a bug. If you think there is text in RFC 4244 that=20 > contradicts this, please identify it and we can clarify it in the -bis. > [/MB] I'll grant I overlooked that example. The implication is that the tree presented in History-Info can be *incomplete*, there can be a 1.2 branch without a 1.1 branch, not because the user used weird numbering, but because there is a 1.1. branch that is not being described in this History-Info -- something that is not so common in representations of trees, and doesn't seem to be explicitly pointed out in the text. [MB2] Per the spec the only reason to drop entries is due to privacy and yes, you will know there's been a branch, you just may not know what the request URI was for that branch nor what the leaves are - kindof like an incomplete family tree. And, section 5 (item 3) does highlight the importance for applications to deal with these situations. So, I'm still confused as to what text in the current specification is lacking. [/MB2] In regard to 4.3.3.1.3, the text is not very clear if you don't already know what it means: Retargeting within a Proxy - subsequent instance: For each subsequent retargeting of a request by the same proxy, another branch is added. With the index for each new branch calculated by incrementing the last/lowest digit at the current level, the index in the next request forwarded by this same proxy, following the example above, would be 1.1.2. What is not stated is that the first forked request gets the xxx.1 value added to its History-Info, the second forked request gets the xxx.2 value added to its History-Info (but not the xxx.1 value), etc. When I read this, I assumed that "instance" meant History-Info value, and that each forked request was expected to have the same set of History-Info values, namely the whole set generated by the forking, of which the first "instance" would be numbers xxx.1, etc. [MB2] I can't see a source of confusion in the RFC - it's talking about subsequent retargets - i.e., another instance of retargeting and it is consistent with examples. How would you state it more accurately? Sorry, I can't grok your point above, so I can't quite see a way to qualify the text to resolve your concern. [/MB] > (Assume that sip:1@example.com has been retargeted to=20 > sip:1A@example.com and sip:1B@example.com.) >=20 > 1.each derived request carries only one of the new History-Info values >=20 > INVITE sip:1A@example.com > History-Info: ;index=3D1, > ;index=3D1.1 >=20 > INVITE sip:1B@example.com > History-Info: ;index=3D1, > ;index=3D1.1 So the correct answer is case 1, but modified in that the index for sip:1B@example.com is 1.2; the numbering was globally consistent across all the History-Info values, but that each value was a subset of the global forking tree. [MB2] I'm not clear on why you see case 1 as correct, when the index is wrong. Yes, in the case of parallel forking that's all the info the proxy has - i.e., HI can't be more deterministic or provide more information than what you would get from looking at a message trace. But, that wouldn't be the case for sequential. [/MB2] > [MB] I don't see a problem here, as you can indeed determine that the=20 > request was retargetted to User2 as a result of the 3xx - Proxy 1=20 > absolutely knows that and that's the reason why the "reason" is added=20 > to the previous HI entry - i.e., the rule being that the reason is=20 > associated with the "Why the request was retargeted?" from the=20 > previous HI entry (Bob@P2.example.com) to the new HI entry User@UA2.example.com). > Thus, you can derive the sequence from the above -i.e., it's ALL there > in that last INVITE. It does require that you look for the reason,=20 > but you really don't need the redundant data. An old, old version of=20 > this document actually did have redundant data in that the "old" and "new" > were captured in each entry. The current approach is that if the "old" > isn't captured, then the entity retargeting captures it along with the > "new" to ensure that you have the entire chain. If you can point to=20 > the specific text that seems to introduce the gap you suggest, that=20 > would be helpful and we can make sure it's clear in the -bis. > [/MB] I was thinking of the case where there are two or more forks preceding the current fork that have returned 3xx. It seems that you'd get H-I like: History-Info: ;index=3D1, ;index=3D1.1, ;index=3D1.2, ;index=3D1.3 >From that, I don't see how to determine whether UserC was generated=20 >from UserA1 or UserB, or for that matter, if it was derived from UserA. Perhaps there is an unstated rule that History-Info should contain only that subset of the global forking tree that describes requests that are logically ancestral to the request that contains it? [MB2] I'm not sure of your use of the term "subset" here. If you're suggesting that only the branches (and not the leaves for a given branch) are required, that's not really the case UNLESS the privacy header is being used for some of entries. You can't determine from the HI entries whether UserC was in the Contact header for the response to the request forwarded to UserA or UserB OR whether UserC was a 3rd parallel forked request. The only way to know that for certain would be to look at the message trace. It's up to a proxy as to how it might arbitrate the receipt of the 3xx responses - it is not REQUIRED that there even be a Contact header in the 3xx. History-Info captures "Why" the request to UserA and UserB was not successful and NOT why the new request URI is chosen. [/MB2] (Oh, yeah, and the example in RFC 4244 from which I derived the above example is: F12 486 Busy Here Proxy1 -> UA1 SIP/2.0 486 Busy Here Via: SIP/2.0/UDP example.net:5060 From: Alice To: Bob Call-Id: 12345600@example.net History-Info: ; index=3D1, ;index=3D1.1, ;index=3D1.2, ;index=3D1.3 CSeq: 1 INVITE Content-Length: 0 Note that it presents a case where one request-URI appears in more than one History-Info value, which was a question I raised above.) [MB2] Which request URI in the above example is contained in more than one HI entry? There are 4 HI entries with 4 different request URIs: UserA@example.com, UserA@ims.example.com, UserB@example.com and UserC@example.com However, it really doesn't matter as there's nothing that states that the same HI value can't be in multiple entries - it's the indices that matter - per section 4.3.3.1, this would be just the case if you are doing loose routing. [/MB2] Dale From dwing@cisco.com Thu Feb 12 18:01:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A1428C17D for ; Thu, 12 Feb 2009 18:01:02 -0800 (PST) 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 6hCNXSX-O965 for ; Thu, 12 Feb 2009 18:01:01 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A403E28C16F for ; Thu, 12 Feb 2009 18:01:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,199,1233532800"; d="scan'208";a="141849110" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Feb 2009 02:01:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1D214ZM001356; Thu, 12 Feb 2009 18:01:04 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1D21348004129; Fri, 13 Feb 2009 02:01:03 GMT From: "Dan Wing" To: "'Frank Shearar'" , References: <03ef01c98cf0$2f1fc260$0600000a@newtechnologies.org.uk> Date: Thu, 12 Feb 2009 18:01:03 -0800 Message-ID: <01fd01c98d7e$ed415f90$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <03ef01c98cf0$2f1fc260$0600000a@newtechnologies.org.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmM8Ecewz5p0MDqQJOkfBeESqDO0AAjpVOA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=234; t=1234490464; x=1235354464; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20draft-ietf-sip-media-security-r equirements-09 |Sender:=20; bh=RabP3UO7K5NUeiccOBUGOMBGvWO37EWvDOGlst8Dzso=; b=WwxQWCoaLJWUWdb1+G5ku7O5frx71ViVP/vb368vp8gN1wT1iC+8UOHrgZ iuKq1m1+Tkpq94pQCWyv4LuEh4dMF9FvfQi+a5renG4Qute9PXcm2NIbVEQm 57Pem7X5YY; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: draft-ietf-sip-media-security-requirements@tools.ietf.org Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-09 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 02:01:02 -0000 > The second last paragraph of section refers to a > "active-signaling-active-attack-detect" category. Should that not be > "active-signalling-active-media-detect" ? Yes, thanks for catching that. We'll fix it in AUTH48. -d From theo@crazygreek.co.uk Thu Feb 12 18:32:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB453A6D3E for ; Thu, 12 Feb 2009 18:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eUwSF7EHOnho for ; Thu, 12 Feb 2009 18:32:39 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with SMTP id 2F9D23A6D47 for ; Thu, 12 Feb 2009 18:32:39 -0800 (PST) Received: from source ([209.85.128.188]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSZTbzZbH7NI4zAP/0FXESRITuXk+p3tu@postini.com; Thu, 12 Feb 2009 18:32:46 PST Received: by fk-out-0910.google.com with SMTP id 22so826766fkq.1 for ; Thu, 12 Feb 2009 18:32:44 -0800 (PST) MIME-Version: 1.0 Sender: theo@crazygreek.co.uk Received: by 10.86.52.6 with SMTP id z6mr28327fgz.35.1234492364405; Thu, 12 Feb 2009 18:32:44 -0800 (PST) In-Reply-To: <4967C1F7.7030407@nostrum.com> References: <4967C1F7.7030407@nostrum.com> Date: Fri, 13 Feb 2009 02:32:44 +0000 X-Google-Sender-Auth: e5c11d060205fa87 Message-ID: <167dfb9b0902121832i261164b6o7635c534e2242b79@mail.gmail.com> From: Theo Zourzouvillys To: SIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "Elwell, John" Subject: Re: [Sip] New HTTP Event Package Draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 02:32:40 -0000 On Fri, Jan 9, 2009 at 9:30 PM, Adam Roach wrote: > I've submitted a new version of draft-roach-sip-http-subscribe, which should > address most or all of the comments made to date. Hi Adam, I really like this version, and will try and find time to implement it internally over the next few weeks. in the mean time, a few comments: 2.2, para 3: [...] If a server wishes to reject such requests, the "403 Forbidden" response code is appropriate. It would be good to provide a way of returning to the client which ones it was unhappy with in the response, to save it having to go off and perform a HEAD on each original resource to find out which one has changed. 2.2, para 5: Finally, for each such group, it initiates a subscription to the group's monitor-list URI; do you mean "monitor-group" instead of "monitor-list"? ~ Theo From drage@alcatel-lucent.com Sun Feb 15 21:15:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0DF3A6B91 for ; Sun, 15 Feb 2009 21:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csbO86TdYxbu for ; Sun, 15 Feb 2009 21:15:57 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 942653A6B86 for ; Sun, 15 Feb 2009 21:15:53 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1G5Fu7x013915 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 16 Feb 2009 06:16:01 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 16 Feb 2009 06:15:56 +0100 From: "DRAGE, Keith (Keith)" To: SIP List Date: Mon, 16 Feb 2009 06:15:52 +0100 Thread-Topic: Last Call for Comments: Proposed work-around to the Pre-5378 Problem Thread-Index: AcmOC2r0GW6c9X1SSkK4ByiuVMLB3QB6glGw Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A08C20@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.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_28B7C3AA2A7ABA4A841F11217ABE78D674A08C20FRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [Sip] FW: Last Call for Comments: Proposed work-around to the Pre-5378 Problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 05:15:58 -0000 --_000_28B7C3AA2A7ABA4A841F11217ABE78D674A08C20FRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I expect all those who have been holding off revisions due to the RFC 5378 = issues to start submitting on Monday. You have of course all got the text ready, and it is just a matter of hitti= ng the submit button. regards Keith ________________________________ From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behal= f Of Ed Juskevicius Sent: Friday, February 13, 2009 12:53 AM To: ietf@ietf.org; ietf-announce@ietf.org; wgchairs@ietf.org; iab@iab.org; = iesg@ietf.org; rfc-editor@rfc-editor.org Cc: Trustees; Ray Pelletier; Contreras, Jorge Subject: Re: Last Call for Comments: Proposed work-around to the Pre-5378 P= roblem I am pleased to announce that the IETF Trustees have just finished work on = a revision to our "Legal Provisions Relating to IETF Documents" policy. Th= e revision includes optional new legend text in Section 6.c.iii of the poli= cy to serve as a work-around for people experiencing the "pre-5378 problem.= " Please note the newly approved policy is dated 2009-02-12. Please also not= e that the Effective Date of this revised policy has been set to 2009-02-15= . The old policy (effective from November 10, 2008) remains in force until= 00h00 UTC on February 15th. The approved text is available now on IETF Trust website at http://trustee.ietf.org/policyandprocedures.html Please look for the document dated 2009-02-12, just below the heading label= ed "DRAFT Policy and Procedures Being Developed." On or shortly after February 15th, the Trust website will be updated so as = to archive all of the recent draft versions of the new policy, and to make = it easier to navigagte to the newly approved policy. Please review the new policy so you are aware of the latest copyright state= ments and other boilerplate legend text that will be required on all contri= butions to the IETF starting on February 15, 2009. Regards, and Thanks in advance, Ed Juskevicius, on behalf of the IETF Trustees edj.etc@gmail.com --_000_28B7C3AA2A7ABA4A841F11217ABE78D674A08C20FRMRSSXCHMBSB3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I expect all those who have been holding off rev= isions=20 due to the RFC 5378 issues to start submitting on Monday.
 
You have of course all got the text ready, and i= t is=20 just a matter of hitting the submit button.
 
regards
 
Keith

From: wgchairs-bounces@ietf.org=20 [mailto:wgchairs-bounces@ietf.org] On Behalf Of Ed=20 Juskevicius
Sent: Friday, February 13, 2009 12:53 AM
To:=20 ietf@ietf.org; ietf-announce@ietf.org; wgchairs@ietf.org; iab@iab.org;=20 iesg@ietf.org; rfc-editor@rfc-editor.org
Cc: Trustees; Ray Pellet= ier;=20 Contreras, Jorge
Subject: Re: Last Call for Comments: Proposed=20 work-around to the Pre-5378 Problem

I am pleased to announce that the IETF Trustees have just finishe= d=20 work on a revision to our "Legal Provisions Relating to IETF=20 Documents" policy.  The revision includes optional new legen= d=20 text in Section 6.c.iii of the policy to serve as a work-around f= or=20 people experiencing the "pre-5378 problem."
 
Please note the newly approved policy is dated 2009-02-12. = =20 Please also note that the Effective Date of this revised policy h= as=20 been set to 2009-02-15.  The old policy=20 (effective from November 10, 2008) remains in force unt= il=20 00h00 UTC on February 15th.
 
The approved text is available now on IETF Trust website at<= /DIV>
 http://trustee.ie= tf.org/policyandprocedures.html

Please=20 look for the document dated 2009-02-12, just below the headi= ng=20 labeled "DRAFT Policy and Procedures Being Developed."
 
On or shortly after February 15th, the Trust website will be updated s= o as=20 to archive all of the recent draft versions of the new policy, and to = make=20 it easier to navigagte to the newly approved policy.
 
Please review the new policy so you are aware of the latest copyright= =20 statements and other boilerplate legend text that will be required on= =20 all contributions to the IETF starting on February 15, 2009. 
 
Regards, and Thanks in advance,
 
 
Ed Juskevicius, on behalf of the IETF Trustees
--_000_28B7C3AA2A7ABA4A841F11217ABE78D674A08C20FRMRSSXCHMBSB3d_-- From dean.willis@softarmor.com Mon Feb 16 11:07:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42333A6C73 for ; Mon, 16 Feb 2009 11:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=0.808, 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 WUSifBzA3iVe for ; Mon, 16 Feb 2009 11:07:42 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1C93B3A6B99 for ; Mon, 16 Feb 2009 11:07:42 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n1GJ7ne8023026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Feb 2009 13:07:51 -0600 Message-Id: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> From: Dean Willis To: SIP IETF Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 13:07:44 -0600 X-Mailer: Apple Mail (2.930.3) Cc: Keith Drage Subject: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 19:07:43 -0000 I'd like to request the SIP Working Group perform final review on the INFO Events draft: http://tools.ietf.org/id/draft-ietf-sip-info-events-03.txt Please review this draft and bring any issues to the mailing list, copying the author. Please conclude this review process by March 4, 2009. -- Dean Willis cp-Chair, SIP WG From drage@alcatel-lucent.com Mon Feb 16 16:00:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265E43A6842 for ; Mon, 16 Feb 2009 16:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0NkyxuzbJboB for ; Mon, 16 Feb 2009 16:00:53 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 2CB5F3A6838 for ; Mon, 16 Feb 2009 16:00:52 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1H00wFq013652 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Feb 2009 01:01:01 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 17 Feb 2009 01:00:58 +0100 From: "DRAGE, Keith (Keith)" To: SIP List Date: Tue, 17 Feb 2009 01:00:55 +0100 Thread-Topic: WGLC for draft-ietf-sip-ua-privacy Thread-Index: AcmQks5lzLuuTjaiSi+I84Fl0y/8og== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A08F78@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "draft-ietf-sip-ua-privacy@tools.ietf.org" , Dean Willis Subject: [Sip] WGLC for draft-ietf-sip-ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 00:00:54 -0000 (As WG cochair) This mail is to initiate working group last call on draft-ietf-sip-ua-priva= cy which may be found here: http://tools.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-05.txt Please provide comments to both the authors and to the SIP WG list by Monda= y 2nd March 2009. The intended status of the document is informational. regards Keith= From brett@broadsoft.com Mon Feb 16 16:18:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBCA3A6974 for ; Mon, 16 Feb 2009 16:18:26 -0800 (PST) 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 eka3sycodQHc for ; Mon, 16 Feb 2009 16:18:25 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D823B3A6818 for ; Mon, 16 Feb 2009 16:18:25 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 16 Feb 2009 16:18:29 -0800 From: Brett Tate To: SIP , "draft-ietf-sip-info-events@tools.ietf.org" Date: Mon, 16 Feb 2009 16:18:28 -0800 Thread-Topic: draft-ietf-sip-info-events-03: comments and questions Thread-Index: AcmQlUG6WL+lSSXFQyiINROQVkSCAg== Message-ID: <9B2A061A1137254BBE4F4B2CD843646A0FD7115231@mbx02.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: [Sip] draft-ietf-sip-info-events-03: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 00:18:26 -0000 Howdy, The following are a few comments and questions concerning draft-ietf-sip-in= fo-events-03. Thanks, Brett ------------- Section 3.1 paragraph 1: Concerning "MUST advertise" and "provisional 1xx"= , please clarify that the "MUST advertise" is not applicable to the 100 res= ponse. Does the "MUST advertise" and "provisional 1xx" apply to all (first= and subsequent within dialog) INVITE non 101-199 (intentionally indicated = 199)? Concerning ACK for initial INVITE's 2xx, does the "MUST advertise" a= lways apply? Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1 indicates "session pa= rameters" and sentence 2 indicates "dialog parameters" concerning Info Pack= age negotiation, I'm not sure when the negotiation/renegotiation occurs. D= oes it follow SDP offer/answer rules or something else; if something else, = what? I have the same question concerning "dialog refresh" text discussed = later within the same section since incorrect interpretations might trigger= deactivation. Section 4.3: When sending a 489, it indicates "MUST terminate the INVITE di= alog". The "MUST terminate" seems severe even if all the negotiation race = conditions are adequately addressed. The mentioned "protocol failure" reas= on seems contrary to the "strictly send and lenient receive" mantra. Section 5.1 Table 1: The usage of "g" seems potentially outdated or incorre= ctly reference since discussed within RFC 2543 instead of RFC 3261. The sa= me applies to usage Via row concerning "(2)". Section 5.2.2: The "general-header" reference is outdated or incorrectly re= ference since defined within RFC 2543 instead of RFC 3261. RFC 3261 uses "= Message-Header". Section 7.7 paragraph 2: The following potentially could be reworded since = it is okay to return failure responses (401, 503, 500, ...) even when overl= apping occurs: "in the event a UAC issues overlapping INFO requests for an = Info Package, the UAS MUST NOT return an error response". Section 8: Why specifically defining and using "nil"? I'm mainly just curi= ous of the benefit over not having defined "nil" for similar use within the= Supported header. From michael@voip.co.uk Tue Feb 17 00:51:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDE83A6B5C for ; Tue, 17 Feb 2009 00:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 1SNSh1WHH1H1 for ; Tue, 17 Feb 2009 00:51:04 -0800 (PST) Received: from voip.co.uk (smtp.sov.voip.co.uk [80.249.108.49]) by core3.amsl.com (Postfix) with ESMTP id 4A3F83A68B2 for ; Tue, 17 Feb 2009 00:51:03 -0800 (PST) Message-ID: <499A7A8A.1030201@voip.co.uk> Date: Tue, 17 Feb 2009 08:51:22 +0000 From: Michael Procter User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: draft-ietf-sip-ua-privacy@tools.ietf.org, "sip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Sip] Comment on sip-ua-privacy-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 08:51:05 -0000 Just a minor point: Is it worth adding (either in section 4.1 or 6) that a temp-gruu might not be as anonymous as you might hope? An observer using RFC 3680 (reg-event) with gruu extensions would be able to correlate temp-gruus with AoRs and contacts, should they be so authorised. There is some text in RFC 3680 warning of the risks of reg-event, but that is probably of more direct interest to registrar authors. A reminder of the risk in this document might highlight it for UA authors, so that they can consider the wider implications. Best regards, Michael From christer.holmberg@ericsson.com Tue Feb 17 05:49:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230DE3A6895 for ; Tue, 17 Feb 2009 05:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CurB8RdPDM6d for ; Tue, 17 Feb 2009 05:49:20 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1F3D03A63D3 for ; Tue, 17 Feb 2009 05:49:20 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0BB7620253; Tue, 17 Feb 2009 14:49:30 +0100 (CET) X-AuditID: c1b4fb3e-af0c1bb000001315-c5-499ac069f716 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EA389200A8; Tue, 17 Feb 2009 14:49:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 14:49:29 +0100 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_01C99106.8DF12076" Date: Tue, 17 Feb 2009 14:49:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-holmberg-sip-keep thread-index: AcmRBo3K3KLaTF+fR3OFoVVC03qkJw== From: "Christer Holmberg" To: X-OriginalArrivalTime: 17 Feb 2009 13:49:29.0989 (UTC) FILETIME=[8E4B2350:01C99106] X-Brightmail-Tracker: AAAAAA== Cc: Keith Drage , Dean Willis Subject: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 13:49:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99106.8DF12076 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of draft-holmberg-sip-keep. The draft is more or less identical to the previous one, with an open issue removed. I actually thought that we reached concensus of some of the use-cases (not the actual mechanism) presented at the MSP meeting, and that we were going to start working on this. But, obviously I was wrong, because no milestone has been created for this... So, I will now need some guidance from the chairs and/or ADs on what to do next... You can also find the draft at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-keep-03.txt Regards, Christer ------_=_NextPart_001_01C99106.8DF12076 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of draft-holmberg-sip-keep

Hi,

I've submitted a new version of = draft-holmberg-sip-keep. The draft is more or less identical to the = previous one, with an open issue removed.

I actually thought that we reached = concensus of some of the use-cases (not the actual mechanism) presented = at the MSP meeting, and that we were going to start working on this. = But, obviously I was wrong, because no milestone has been created for = this...

So, I will now need some guidance from = the chairs and/or ADs on what to do next...

You can also find the draft at:

http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-= keep-03.txt

Regards,

Christer

------_=_NextPart_001_01C99106.8DF12076-- From drage@alcatel-lucent.com Tue Feb 17 17:53:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B009028C1C9 for ; Tue, 17 Feb 2009 17:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ZnfKF-fZzK0D for ; Tue, 17 Feb 2009 17:53:12 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 9334828C1C4 for ; Tue, 17 Feb 2009 17:53:11 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1I1rLMB015163 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Feb 2009 02:53:21 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 18 Feb 2009 02:53:21 +0100 From: "DRAGE, Keith (Keith)" To: Michael Procter , "draft-ietf-sip-ua-privacy@tools.ietf.org" , "sip@ietf.org" Date: Wed, 18 Feb 2009 02:53:17 +0100 Thread-Topic: [Sip] Comment on sip-ua-privacy-05.txt Thread-Index: AcmQ3PRuFo7HDWPJSLeQ9uDJyMu0KAAizO1w Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A092EB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <499A7A8A.1030201@voip.co.uk> In-Reply-To: <499A7A8A.1030201@voip.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Sip] Comment on sip-ua-privacy-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:53:13 -0000 There is a similar issue with the instance-id as used by outbound and GRUU = as well. In a mobile, this uses the IMEI which is not necessarily meant to = be revealed. 3GPP obfuscate the IMEI on generation of the GRUU. regards Keith=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Michael Procter > Sent: Tuesday, February 17, 2009 8:51 AM > To: draft-ietf-sip-ua-privacy@tools.ietf.org; sip@ietf.org > Subject: [Sip] Comment on sip-ua-privacy-05.txt >=20 > Just a minor point: Is it worth adding (either in section=20 > 4.1 or 6) that a temp-gruu might not be as anonymous as you=20 > might hope? An observer using RFC 3680 (reg-event) with gruu=20 > extensions would be able to correlate temp-gruus with AoRs=20 > and contacts, should they be so authorised. >=20 > There is some text in RFC 3680 warning of the risks of=20 > reg-event, but that is probably of more direct interest to=20 > registrar authors. A reminder of the risk in this document=20 > might highlight it for UA authors, so that they can consider=20 > the wider implications. >=20 > Best regards, >=20 > Michael > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip > = From shida@ntt-at.com Wed Feb 18 23:34:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13BF3A6783 for ; Wed, 18 Feb 2009 23:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jEcw8uupVQO for ; Wed, 18 Feb 2009 23:34:38 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.66.25]) by core3.amsl.com (Postfix) with SMTP id 68C4F3A6A35 for ; Wed, 18 Feb 2009 23:34:37 -0800 (PST) Received: (qmail 7924 invoked from network); 19 Feb 2009 07:54:36 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway07.websitewelcome.com with SMTP; 19 Feb 2009 07:54:36 -0000 Received: from fl1-119-242-13-244.tky.mesh.ad.jp ([119.242.13.244]:52362 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1La3Ql-0001Rd-Ox; Thu, 19 Feb 2009 01:34:47 -0600 Message-Id: From: Shida Schubert To: Michael Procter In-Reply-To: <499A7A8A.1030201@voip.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 16:34:45 +0900 References: <499A7A8A.1030201@voip.co.uk> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: "sip@ietf.org" , draft-ietf-sip-ua-privacy@tools.ietf.org Subject: Re: [Sip] Comment on sip-ua-privacy-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:34:39 -0000 Thanks for pointing this out.. I went and looked at gruu-reg-event draft and saw what kind of security consideration text is there, the text described a authorization policy limiting only allowing subscription to those who actually registered and requested the temp-gruu. I do agree that implication of reg-event and some consideration for the implementors will be beneficial and will add some text in the security consideration. Many Thanks Shida On 17-Feb-09, at 5:51 PM, Michael Procter wrote: > Just a minor point: Is it worth adding (either in section 4.1 or 6) > that a temp-gruu might not be as anonymous as you might hope? An > observer using RFC 3680 (reg-event) with gruu extensions would be able > to correlate temp-gruus with AoRs and contacts, should they be so > authorised. > > There is some text in RFC 3680 warning of the risks of reg-event, but > that is probably of more direct interest to registrar authors. A > reminder of the risk in this document might highlight it for UA > authors, > so that they can consider the wider implications. > > Best regards, > > Michael > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From shida@ntt-at.com Wed Feb 18 23:52:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAD83A6975 for ; Wed, 18 Feb 2009 23:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sds+x0m7Canq for ; Wed, 18 Feb 2009 23:52:40 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.183.8]) by core3.amsl.com (Postfix) with SMTP id 553333A6783 for ; Wed, 18 Feb 2009 23:52:40 -0800 (PST) Received: (qmail 5693 invoked from network); 19 Feb 2009 08:11:21 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway16.websitewelcome.com with SMTP; 19 Feb 2009 08:11:21 -0000 Received: from fl1-119-242-13-244.tky.mesh.ad.jp ([119.242.13.244]:52748 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1La3iF-0005Bc-Vy; Thu, 19 Feb 2009 01:52:52 -0600 Message-Id: From: Shida Schubert To: "DRAGE, Keith (Keith)" In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A092EB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 16:52:50 +0900 References: <499A7A8A.1030201@voip.co.uk> <28B7C3AA2A7ABA4A841F11217ABE78D674A092EB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: "sip@ietf.org" , "draft-ietf-sip-ua-privacy@tools.ietf.org" Subject: Re: [Sip] Comment on sip-ua-privacy-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:52:41 -0000 Keith; I just looked at outbound and gruu again, and AFAICT temp-gruu doesn't carry the instance-id unlike the pub-gruu which does. With outbound the instance-id is only present in the REGISTER request when you are establishing the flow, and if temp-gruu is used, the only time instance-id will be visible when GRUU is used is also in the REGISTER request. I may be blind but I can't seem to see the problem. Regards Shida On 18-Feb-09, at 10:53 AM, DRAGE, Keith (Keith) wrote: > There is a similar issue with the instance-id as used by outbound > and GRUU as well. In a mobile, this uses the IMEI which is not > necessarily meant to be revealed. > > 3GPP obfuscate the IMEI on generation of the GRUU. > > regards > > Keith > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Michael Procter >> Sent: Tuesday, February 17, 2009 8:51 AM >> To: draft-ietf-sip-ua-privacy@tools.ietf.org; sip@ietf.org >> Subject: [Sip] Comment on sip-ua-privacy-05.txt >> >> Just a minor point: Is it worth adding (either in section >> 4.1 or 6) that a temp-gruu might not be as anonymous as you >> might hope? An observer using RFC 3680 (reg-event) with gruu >> extensions would be able to correlate temp-gruus with AoRs >> and contacts, should they be so authorised. >> >> There is some text in RFC 3680 warning of the risks of >> reg-event, but that is probably of more direct interest to >> registrar authors. A reminder of the risk in this document >> might highlight it for UA authors, so that they can consider >> the wider implications. >> >> Best regards, >> >> Michael >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From web-usrn@ISI.EDU Thu Feb 19 03:02:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDFC3A6AC9 for ; Thu, 19 Feb 2009 03:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.848 X-Spam-Level: X-Spam-Status: No, score=-16.848 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVcW7ZYYEwt8 for ; Thu, 19 Feb 2009 03:02:12 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id DB6F23A69A3 for ; Thu, 19 Feb 2009 03:02:12 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n1JB22kG025713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Feb 2009 03:02:03 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n1JB22BZ025710; Thu, 19 Feb 2009 03:02:02 -0800 (PST) Date: Thu, 19 Feb 2009 03:02:02 -0800 (PST) Message-Id: <200902191102.n1JB22BZ025710@boreas.isi.edu> To: srd@cisco.com, jdrosen@cisco.com, jon.peterson@neustar.biz, fluffy@cisco.com, dean.willis@softarmor.com, drage@alcatel-lucent.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: sip@ietf.org, rsaragad@cisco.com, rfc-editor@rfc-editor.org Subject: [Sip] [Technical Errata Reported] RFC4028 (1687) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 11:02:14 -0000 The following errata report has been submitted for RFC4028, "Session Timers in the Session Initiation Protocol (SIP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4028&eid=1687 -------------------------------------- Type: Technical Reported by: Radha krishna Saragadam Section: 9 Original Text ------------- The UAS MUST NOT increase the value of the Session-Expires header field. Corrected Text -------------- same as session 8.1 If the request doesn't indicate support for the session timer but contains a session interval that is too small, the UAS cannot usefully reject the request, as this would result in a call failure. Rather, the UAS SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the UAS SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The UAS MUST then increase the Session-Expires header field value to be equal to the value in the Min-SE header field Notes ----- ----- Forwarded Message ---- From: Radha krishna To: Brett Tate ; "sip-implementors@lists.cs.columbia.edu" Sent: Thursday, February 19, 2009 10:56:31 AM Subject: Re: [Sip-implementors] Sending 422 Thanks Brett, So I think same should be added for UAS If the request doesn't indicate support for the session timer but contains a session interval that is too small, the proxy cannot usefully reject the request, as this would result in a call failure. Rather, the proxy SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the proxy SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The proxy MUST then increase the Session-Expires header field value to be equal to the value in the Min-SE header field, as described above. Regards S.Radha krishna ________________________________ From: Brett Tate To: Radha krishna ; "sip-implementors@lists.cs.columbia.edu" Sent: Wednesday, February 18, 2009 6:42:31 PM Subject: RE: [Sip-implementors] Sending 422 It looks like Section 9 may have forgotten to indicate the behavior when UAC timer support not indicated. Section 8.1 allows a proxy to increase the Session-Expires; I see no reason why the same cannot be done by the UAS. > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Radha krishna > Sent: Tuesday, February 17, 2009 9:48 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Sending 422 > > Hi > > Consider the following topology > UA1 ----- Call-stateful-proxy ------ UA2 > > UA1 does not support session timer, Make a call to UA2. Call- > stateful-proxy adds Session-Expires:100 header and forwards to UA2. UA2 > minimum session expires is 900. But in this case INVITE will not contain > "support: timer". According section 9, UAS can reject with 422 only if > there is a timer tag in supported header > > > > If an incoming request contains a Supported header field with a value > 'timer' and a Session Expires header field, the UAS MAY reject the > INVITE request with a 422 (Session Interval Too Small) response if > the session interval in the Session-Expires header field is smaller > than the minimum interval defined by the UAS' local policy. When > sending the 422 response, the UAS MUST include a Min-SE header field > with the value of its minimum interval. This minimum interval MUST > NOT be lower than 90 seconds. > > > Also UAS cannot increase the session expires duration > > The UAS MUST > NOT increase the value of the Session-Expires header field. > > > What should be the behavior of UAS here? > 1) accept the call with 100 seconds? > 2) Increase the duration to 900 seconds while sending 200 Ok? > Note: Session timer should not be turned-off > > Regards > S.Radha krishna > > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4028 (draft-ietf-sip-session-timer-15) -------------------------------------- Title : Session Timers in the Session Initiation Protocol (SIP) Publication Date : April 2005 Author(s) : S. Donovan, J. Rosenberg Category : PROPOSED STANDARD Source : Session Initiation Protocol Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From christer.holmberg@ericsson.com Thu Feb 19 03:11:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0FE3A69A3 for ; Thu, 19 Feb 2009 03:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.42 X-Spam-Level: X-Spam-Status: No, score=-5.42 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmJzKzwjIDeM for ; Thu, 19 Feb 2009 03:11:51 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4EAFA3A679F for ; Thu, 19 Feb 2009 03:11:51 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 742F0206AA; Thu, 19 Feb 2009 12:12:03 +0100 (CET) X-AuditID: c1b4fb3c-aa283bb00000127c-c1-499d3e82559a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4216420680; Thu, 19 Feb 2009 12:12:02 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 12:12:02 +0100 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_01C99282.E3B800CE" Date: Thu, 19 Feb 2009 12:12:01 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version (-05) of the 199 draft - ready for WGLC? thread-index: AcmSguOJ6zQLTxPzQv6/SIZypgTFrw== From: "Christer Holmberg" To: X-OriginalArrivalTime: 19 Feb 2009 11:12:02.0486 (UTC) FILETIME=[E3F81560:01C99282] X-Brightmail-Tracker: AAAAAA== Cc: Keith Drage , Dean Willis Subject: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 11:11:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99282.E3B800CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of draft-ietf-sip-199. I have done changes and updates based on feedback and discussions (please let me know if you think I've forgotten something), and I've also added text to the security chapter. I propose that we start the WGLC process for the draft. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-05.txt Regards, Christer ------_=_NextPart_001_01C99282.E3B800CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version (-05) of the 199 draft - ready for WGLC?

Hi,

I've submitted a new version of = draft-ietf-sip-199. I have done changes and updates based on feedback = and discussions (please let me know if you think I've forgotten = something), and I've also added text to the security chapter.

I propose that we start the WGLC = process for the draft.

The draft can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-= 05.txt

Regards,

Christer

------_=_NextPart_001_01C99282.E3B800CE-- From root@core3.amsl.com Thu Feb 19 03:15:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C36493A6405; Thu, 19 Feb 2009 03:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090219111501.C36493A6405@core3.amsl.com> Date: Thu, 19 Feb 2009 03:15:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-199-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 11:15:01 -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 Working Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sip-199-05.txt Pages : 14 Date : 2009-02-19 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-199-05.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-sip-199-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-19030824.I-D@ietf.org> --NextPart-- From cnmjbm@gmail.com Thu Feb 19 17:01:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383F33A6A2D for ; Thu, 19 Feb 2009 17:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgJcW8myQf-p for ; Thu, 19 Feb 2009 17:00:59 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 7295A3A6907 for ; Thu, 19 Feb 2009 17:00:59 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so791355wfd.31 for ; Thu, 19 Feb 2009 17:01:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:reply-to:from:to :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=DMlM2unwvPFd2ZzOYgjPMju4g5hPAkuVwBU7div2r6E=; b=aCmbgJ+VznmzvCg2Q97GMawKkgGaUw6AvC+lgKE8sTiMS2C2cVBJvADy+nZVuHXpeP XU+ds+wK3jvef4yMnRCChyhMqHWidtjXOagYNTBr4/rYkeCjR37DV5jLT88nRcxKA191 B6ghD5dqQ/2MmreV9qan07NluAgO1jAdal2kQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:reply-to:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; b=s1w3NDMjZgx1O0VSjCpsSVAl4rsZEw++FopasijKAQET/qAm7DaGXj2ebedmVdEKz6 NYTsASMhNhuyIWLdqznE/gxtfsIFPY1as6BuYNw+WI9IxnteruB8cB6VZxLXvx4dhaSb Q3VkRgSWmDavQ4ynsotQAngwcxZRcNnWUWI5s= Received: by 10.142.141.21 with SMTP id o21mr86426wfd.308.1235091672732; Thu, 19 Feb 2009 17:01:12 -0800 (PST) Received: from panpipi (jerico.innomedia.com [209.133.49.18]) by mx.google.com with ESMTPS id 30sm1274953wfa.58.2009.02.19.17.01.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 17:01:12 -0800 (PST) Message-ID: <001101c992f7$527fbb90$840010ac@panpipi> From: "Cowby" To: Date: Thu, 19 Feb 2009 17:05:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Subject: [Sip] questions about usage of tel URI with a SIP UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Cowby List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:01:00 -0000 Hi, I have few question about "tel" uri defined in RFC 3966. Q1: is it possible that a SIP UA can receive incoming requests with tel uri as the request-uri? Q2: if the answer to Q1 is yes, how does a SIP UA normally handle tel uri to match the UA itself? For example, if a UA has a mailto:"sip:cowby@cows.com' as its IMS public identity and +1-408-555-6666 as it global phone number, Q1: is it possible that the UA's P-CSCF can route an INVITE tel:+1-408-555-6666 request to the UA? Q2: how can the UA match itself when it is configured as cowby@cows.com but know nothing of its phone number? Thanks. Cowby From theo@crazygreek.co.uk Thu Feb 19 20:20:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8ED93A6B0C for ; Thu, 19 Feb 2009 20:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JxtgSq+b5df6 for ; Thu, 19 Feb 2009 20:20:00 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with SMTP id 845133A698B for ; Thu, 19 Feb 2009 20:19:59 -0800 (PST) Received: from source ([209.85.218.166]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ4vd4zJ1YAHHKnvzAiK8OyMPogfNhbK@postini.com; Thu, 19 Feb 2009 20:20:14 PST Received: by mail-bw0-f166.google.com with SMTP id 10so2462381bwz.6 for ; Thu, 19 Feb 2009 20:20:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.181.199.11 with SMTP id b11mr121336bkq.127.1235103607584; Thu, 19 Feb 2009 20:20:07 -0800 (PST) Date: Fri, 20 Feb 2009 04:20:07 +0000 Message-ID: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> From: Theo Zourzouvillys To: SIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 04:20:00 -0000 Hi, I've just submitted an ID that discusses the inherent UDP "problem", along with a potential workaround to stop it being used maliciously. I would really welcome any feedback: http://www.ietf.org/internet-drafts/draft-zourzouvillys-sip-via-cookie-00.txt ~ Theo From shamik.saha@wipro.com Thu Feb 19 22:13:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE84E3A67AA for ; Thu, 19 Feb 2009 22:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g69a83NRFAhL for ; Thu, 19 Feb 2009 22:13:21 -0800 (PST) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 1FA183A6765 for ; Thu, 19 Feb 2009 22:13:21 -0800 (PST) X-AuditID: cb5bdd57-adedcbb000001f7d-37-499e4a0dcf64 Received: from blr-ec-aa01.wipro.com (unknown [10.201.18.41]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with ESMTP id 1459F4E400D for ; Fri, 20 Feb 2009 11:43:33 +0530 (IST) Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 11:43:11 +0530 Received: from BLR-EC-MBX06.wipro.com ([10.201.50.167]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 11:43:11 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2009 11:33:24 +0530 Message-ID: <65980D196089A349AE990CC10D24FE8F0617DE9E@BLR-EC-MBX06.wipro.com> In-Reply-To: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-zourzouvillys-sip-via-cookie-00 Thread-Index: AcmTEqIwoncj7SljRL+ZQ7oRKyejZgACxaCg References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> From: To: X-OriginalArrivalTime: 20 Feb 2009 06:13:11.0547 (UTC) FILETIME=[4EB5ACB0:01C99322] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 06:13:22 -0000 Hi Theo, I was just thinking of a scenario,suppose the attacker creates a spoofed invite,and inserts his ip in the Via header field and an empty cookie parameter in the via header field.The Proxie which he wants to use as an ampilfier in a DoS attack,on receiving such a request will respond with a 4xx response,and the value of the cookie parameter to be used.On receiving the cookie,the attacker,resends the invite with the cookie value and deletes its entry from the Via header field.Thus now the responses for this invite will be sent back to the UAC which is to be the victim of the DoS attack only.The UAC which is attacked will receive a minimum of 22 responses only. What do you think about this. Thanks and regards, =20 Shamik Saha Project Engineer Voice Protocols Cell : +91-9886704155 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Theo Zourzouvillys Sent: Friday, February 20, 2009 9:50 AM To: SIP WG Subject: [Sip] draft-zourzouvillys-sip-via-cookie-00 Hi, I've just submitted an ID that discusses the inherent UDP "problem", along with a potential workaround to stop it being used maliciously. I would really welcome any feedback: =20 http://www.ietf.org/internet-drafts/draft-zourzouvillys-sip-via-cookie-0 0.txt ~ Theo _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From theo@crazygreek.co.uk Thu Feb 19 23:43:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898103A6960 for ; Thu, 19 Feb 2009 23:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=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 VwNkJmcfVDJG for ; Thu, 19 Feb 2009 23:43:19 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with SMTP id DC3C23A695D for ; Thu, 19 Feb 2009 23:43:17 -0800 (PST) Received: from source ([72.14.220.158]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ5fFLywQglhvWix7mBZ168AsIG4hJ4p@postini.com; Thu, 19 Feb 2009 23:43:32 PST Received: by fg-out-1718.google.com with SMTP id 19so1533747fgg.5 for ; Thu, 19 Feb 2009 23:43:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.65.9 with SMTP id n9mr881341fga.55.1235115795947; Thu, 19 Feb 2009 23:43:15 -0800 (PST) In-Reply-To: <65980D196089A349AE990CC10D24FE8F0617DE9E@BLR-EC-MBX06.wipro.com> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> <65980D196089A349AE990CC10D24FE8F0617DE9E@BLR-EC-MBX06.wipro.com> Date: Fri, 20 Feb 2009 07:43:15 +0000 Message-ID: <167dfb9b0902192343y12409fa6s2d2a67d84382832e@mail.gmail.com> From: Theo Zourzouvillys To: shamik.saha@wipro.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 07:43:20 -0000 On Fri, Feb 20, 2009 at 6:03 AM, wrote: > I was just thinking of a scenario,suppose the attacker creates a spoofed > invite,and inserts his ip in the Via header field and an empty cookie > parameter in the via header field.The Proxie which he wants to use as an > ampilfier in a DoS attack,on receiving such a request will respond with > a 4xx response,and the value of the cookie parameter to be used.On > receiving the cookie,the attacker,resends the invite with the cookie > value and deletes its entry from the Via header field.Thus now the > responses for this invite will be sent back to the UAC which is to be > the victim of the DoS attack only.The UAC which is attacked will receive > a minimum of 22 responses only. SIP responses will always be sent back to the source of the request (and if rport is included also to the source port), and not the value of sent-by in the first instance. The cookie the server generates would always use the source ip and port in the cookie it creates, so sending the second request with a different source IP would mean the server can detect the cookie is invalid. However, an attacker could indeed make sent-by the address of the victim, perform the cookie dance (legitimately), and then play dead by sending ICMP messages for any responses received. However, following rfc3261 sect 18.2.2 and rfc3263 to the last dot would result in the response being transmitted every time to the source (attacker) first before then being transmitted to the victim (after an ICMP port/host unreachable response), therefore making it a highly unattractive proposition for the attacker. ~ Theo From theo@crazygreek.co.uk Thu Feb 19 23:45:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AE53A68BA for ; Thu, 19 Feb 2009 23:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 O3oRlCfgSpwh for ; Thu, 19 Feb 2009 23:45:28 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with SMTP id 689853A694F for ; Thu, 19 Feb 2009 23:45:28 -0800 (PST) Received: from source ([72.14.220.157]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ5fpqzEZtBAVX8AcXd3X+6ImLJdTVU3@postini.com; Thu, 19 Feb 2009 23:45:43 PST Received: by fg-out-1718.google.com with SMTP id l27so1334922fgb.38 for ; Thu, 19 Feb 2009 23:45:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.53.8 with SMTP id b8mr881389fga.58.1235115942101; Thu, 19 Feb 2009 23:45:42 -0800 (PST) In-Reply-To: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> Date: Fri, 20 Feb 2009 07:45:42 +0000 Message-ID: <167dfb9b0902192345r538645c9s33bb85ca430ea7f7@mail.gmail.com> From: Theo Zourzouvillys To: SIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 07:45:29 -0000 On Fri, Feb 20, 2009 at 4:20 AM, Theo Zourzouvillys wrote: > I've just submitted an ID that discusses the inherent UDP "problem", > along with a potential workaround to stop it being used maliciously. note that it's *only* trying to solve the drive-by-shooting problem that is inherent in UDP where an attacker can just "fire and forget" by spoofing the source; it does _not_ try to solve the problem of verifying Contact or Route header values when establishing a dialog. I believe this is a separate issue (as it affects all transports, not just UDP), and am only trying to bring UDP onto the same footing as connection oriented transports. Having just read through the draft it again, it would undoubtedly make more sense to use a non 2xx response as an example instead, and remove the mention of 100rel to make it clear i'm not trying to solve that :) ~ Theo From lists@ohlmeier.org Fri Feb 20 00:58:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7427B3A67C1 for ; Fri, 20 Feb 2009 00:58:41 -0800 (PST) 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 WsKlfiqAc0bX for ; Fri, 20 Feb 2009 00:58:40 -0800 (PST) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 8E27B3A6853 for ; Fri, 20 Feb 2009 00:58:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id B9B3D7F82; Fri, 20 Feb 2009 09:58:51 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fNrRgjc0lkn; Fri, 20 Feb 2009 09:58:51 +0100 (CET) Received: from Nils-MacBook-2.local (unknown [78.52.229.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bespin.rfc3261.net (Postfix) with ESMTPSA id 6CA5C7F55; Fri, 20 Feb 2009 09:58:51 +0100 (CET) Message-ID: <499E70CB.3000004@ohlmeier.org> Date: Fri, 20 Feb 2009 09:58:51 +0100 From: Nils Ohlmeier User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Cowby References: <001101c992f7$527fbb90$840010ac@panpipi> In-Reply-To: <001101c992f7$527fbb90$840010ac@panpipi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] questions about usage of tel URI with a SIP UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 08:58:41 -0000 Hello, Am 20.02.2009 2:05 Uhr, schrieb Cowby: > Q1: is it possible that a SIP UA can receive incoming requests with tel uri > as the request-uri? In IMS yes. > Q2: if the answer to Q1 is yes, how does a SIP UA normally handle tel uri to > match the UA itself? Take a look at the P-Associated-URI header. > For example, if a UA has a mailto:"sip:cowby@cows.com' as its IMS public > identity and +1-408-555-6666 as it global phone number, > > Q1: is it possible that the UA's P-CSCF can route an INVITE > tel:+1-408-555-6666 request to the UA? Yes, see above. > Q2: how can the UA match itself when it is configured as cowby@cows.com but > know nothing of its phone number? See above as well. BTW such questions should be directed to the sip-implementors mailing list instead (although I'm not sure if they discuss IMS as well). Best regards Nils Ohlmeier From lists@ohlmeier.org Fri Feb 20 01:46:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899B728C1F5 for ; Fri, 20 Feb 2009 01:46:22 -0800 (PST) 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 3GhoWFWZ4FsA for ; Fri, 20 Feb 2009 01:46:21 -0800 (PST) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 7F8203A6A0F for ; Fri, 20 Feb 2009 01:46:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 5DA0C7F82; Fri, 20 Feb 2009 10:46:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkTlfxPd8ny9; Fri, 20 Feb 2009 10:46:33 +0100 (CET) Received: from Nils-MacBook-2.local (unknown [78.52.229.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bespin.rfc3261.net (Postfix) with ESMTPSA id 0D9D37F55; Fri, 20 Feb 2009 10:46:33 +0100 (CET) Message-ID: <499E7BF8.7000109@ohlmeier.org> Date: Fri, 20 Feb 2009 10:46:32 +0100 From: Nils Ohlmeier User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Theo Zourzouvillys References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> In-Reply-To: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 09:46:22 -0000 Hi Theo, Am 20.02.2009 5:20 Uhr, schrieb Theo Zourzouvillys: > I've just submitted an ID that discusses the inherent UDP "problem", > along with a potential workaround to stop it being used maliciously. > > I would really welcome any feedback: > > http://www.ietf.org/internet-drafts/draft-zourzouvillys-sip-via-cookie-00.txt in general I like your proposal, but I have a few questions/thoughts: I think the whole "attack scenario" which is described in the draft works only if the attacker uses the proxy/registrar of the victim as a relay. Reason 1): because the attacker hopefully does not know which UDP port of the victim is currently "open" to accept incoming UDP packets. And if their is a NAT or firewall in between the UA it will hopefully only accept UDP packets from the proxy/registrar. If the UA of the victim runs on a public IP without any "protection" it might accept SIP requests from anywhere, although I would call this a very bad UA implementation. Reason 2): when the UA of the victim registeres itself it provides a Contact URI. I general I believe UA should only accept incoming requests from their registrar IP and port which contains the Contact URI which they provided at the registration. This prevents very easily that someone sends drive by requests just with the AOR of the victim as R-URI to the UA of the victim. If a registrar forwards requests to registered UAs with the AOR of the user in the R-URI the registrar is broken in my opinion. Now the question is of the proxy/registrar accepts requests from its users from anywhere. I guess that is what you mean with no authentication, right? One bigger concern for the whole approach is: if the attacker knows about this cookie extension he will for sure not put an empty cookie in the Via header of the request. But how does the proxy of the victim handle requests without the cookie extension? To be backward compatible it would need to accept requests without the extension, but then the door is open for the attacker again. If the proxy of the victim does not care about backward compatibility (maybe because attack previntion is more important), wouldn't the need a way to tell the sender of the request that the cookie extension is required to successfully relay requests? So wouldn't we need a new value for the Required header, or would a new 4XX response already be enough. As I said I like the general idea. But I believe that the attack scenario which you describe in your draft should be a little bit more narrow then described. Best regards Nils Ohlmeier From hsinnrei@adobe.com Fri Feb 20 06:44:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2273A69CF for ; Fri, 20 Feb 2009 06:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[AWL=1.200, 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 ljd7zwOHQp4A for ; Fri, 20 Feb 2009 06:44:46 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id 93E5D3A6858 for ; Fri, 20 Feb 2009 06:44:45 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKSZ7B3+KKXv9D4tPqIH8G7QGj1PIMR10M@postini.com; Fri, 20 Feb 2009 06:45:01 PST Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1KEiiE0016922; Fri, 20 Feb 2009 06:44:44 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1KEihl8010906; Fri, 20 Feb 2009 06:44:43 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Fri, 20 Feb 2009 06:44:43 -0800 From: Henry Sinnreich To: Nils Ohlmeier , Theo Zourzouvillys Date: Fri, 20 Feb 2009 06:44:40 -0800 Thread-Topic: [Sip] draft-zourzouvillys-sip-via-cookie-00 Thread-Index: AcmTQCgu/NQ0dvYNTTmdNQ2u5rpcnwAKZpHt Message-ID: In-Reply-To: <499E7BF8.7000109@ohlmeier.org> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5C41DF8B712hsinnreiadobecom_" MIME-Version: 1.0 Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 14:44:49 -0000 --_000_C5C41DF8B712hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nils, >If the UA of the victim runs on a public IP without any "protection" >it might accept SIP requests from anywhere, although >I would call this a very bad UA implementation. This is correct. Why cannot the UA have adequate protection at the application layer, such a= s authenticating the caller? Making a massive DOS attack on one single UAs does not seem a "productive" = technique for spammers. And if one individual is a valuable target, such individuals have other com= munication means besides a sole SIP UA. Henry On 2/20/09 3:46 AM, "Nils Ohlmeier" wrote: If the UA of the victim runs on a public IP without any "protection" it might accept SIP requests from anywhere, although I would call this a very bad UA implementation. --_000_C5C41DF8B712hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 Nils,

>If the UA of the victim runs on a public IP without any "protectio= n"
>it might accept SIP requests from anywhere, although
>I would call this a very bad UA implementation.

This is correct.

Why cannot the UA have adequate protection at the application layer, such a= s authenticating the caller?

Making a massive DOS attack on one single UAs does not seem a “produc= tive” technique for spammers.
And if one individual is a valuable target, such individuals have other com= munication means besides a sole SIP UA.

Henry


On 2/20/09 3:46 AM, "Nils Ohlmeier" <lists@ohlmeier.org> wrote:

If the UA of the victim
runs on a public IP without any "protection" it might accept SIP<= BR> requests from anywhere, although I would call this a very bad UA
implementation.
--_000_C5C41DF8B712hsinnreiadobecom_-- From theo@crazygreek.co.uk Fri Feb 20 07:37:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6AC3A69CF for ; Fri, 20 Feb 2009 07:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 WxCJ1v8ph--n for ; Fri, 20 Feb 2009 07:37:05 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with SMTP id AF6773A6835 for ; Fri, 20 Feb 2009 07:37:04 -0800 (PST) Received: from source ([72.14.220.153]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ7OH5cUp47uhzH6aKgISFa4LXiKz3J3@postini.com; Fri, 20 Feb 2009 07:37:20 PST Received: by fg-out-1718.google.com with SMTP id l26so1602613fgb.33 for ; Fri, 20 Feb 2009 07:36:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.70.3 with SMTP id s3mr1143424fga.56.1235144211350; Fri, 20 Feb 2009 07:36:51 -0800 (PST) In-Reply-To: <499E7BF8.7000109@ohlmeier.org> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> <499E7BF8.7000109@ohlmeier.org> Date: Fri, 20 Feb 2009 15:36:51 +0000 Message-ID: <167dfb9b0902200736p2ccad1bcu68d59386dd84ef28@mail.gmail.com> From: Theo Zourzouvillys To: Nils Ohlmeier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:37:06 -0000 On Fri, Feb 20, 2009 at 9:46 AM, Nils Ohlmeier wrote: Hi Nils, Thanks for the feedback - i'll elaborate to make the issues you raised more clear in the next version of the document. > I think the whole "attack scenario" which is described in the draft works > only if the attacker uses the proxy/registrar of the victim as a relay. > Reason 1): because the attacker hopefully does not know which UDP port of > the victim is currently "open" to accept incoming UDP packets. And if their > is a NAT or firewall in between the UA it will hopefully only accept UDP > packets from the proxy/registrar. If the UA of the victim runs on a public > IP without any "protection" it might accept SIP requests from anywhere, > although I would call this a very bad UA implementation. A victim does not need to have an open UDP port; An attack can easily be launched against any IP address, even a non SIP related one. A device behind NAT on the end of a link additionally has no protection at an IP level, as the link would easily become saturated as a reflector starts sending failure response retransmits from a IST every time timerG fires. > Reason 2): when the UA of the victim registeres itself it provides a Contact > URI. I general I believe UA should only accept incoming requests from their > registrar IP and port which contains the Contact URI which they provided at > the registration. This prevents very easily that someone sends drive by > requests just with the AOR of the victim as R-URI to the UA of the victim. > If a registrar forwards requests to registered UAs with the AOR of the user > in the R-URI the registrar is broken in my opinion. as above - a victim does not need to be a SIP UA - it doesn't even need to talk SIP. The attacker may well be trying to attack a non SIP entity, for example a web, DNS, or mail server. On the flip side, a UA that "only accept"s requests from it's registrar if of course good practice, but is only a step in stopping SPIT, not denial of service (which this draft tries to tackle), unless the "only accept" is limited by routability. Note even NAT doesn't stop a denial of service attack being launched against the NAT gateway, causing it's connectivity to become saturated. This draft is specifically trying to stopping a SIP server transaction being used as an amplifying reflector in a (distributed) denial of service attack. The victim of the attack does not need to be a SIP endpoint (it doesn't even need to have any ports open!) > Now the question is of the proxy/registrar accepts requests from its users > from anywhere. I guess that is what you mean with no authentication, right? Yes - any SIP server (note a UAS or proxy are both servers for this) which allows an unauthenticated, untrusted user to create an invite server transaction (even for failure delivery) is vulnerable. > One bigger concern for the whole approach is: if the attacker knows about > this cookie extension he will for sure not put an empty cookie in the Via > header of the request. But how does the proxy of the victim handle requests > without the cookie extension? Any proxy that does wish to be used as an amplifier should reject requests without cookies with a stateless 4XX, or send a stateless 401/407 if knows it can authenticate it's user. Of course this is not going to be realistic from day 1, but this document is a start in finding solutions to some of the DOS problems we're currently susceptible to by putting a SIP server "on the net". Right now, there are a large number of SIP endpoints out there that will amplify a single UDP packet sent to them, and the initiator of the attack isn't even traceable! (i'm starting to sound like a scaremonger, so i'll stop now :)) > If the proxy of the victim does not care about backward compatibility (maybe > because attack previntion is more important), wouldn't the need a way to > tell the sender of the request that the cookie extension is required to > successfully relay requests? So wouldn't we need a new value for the > Required header, or would a new 4XX response already be enough. I did briefly consider an option tag but the problem is a SIP UA does not need to implement anything for it to potentially work - for example a proxy can implement it on behalf of a group of trusted users (for example, a corporate proxy or an outbound proxy that has authenticated the inbound request). There would additionally be no mechanism for recovery if the server refuses to process UDP requests without cookie support. The 4XX would provide a code that allows a machine to understand that it failed due to cookies (if it knew about, but didn't implement the extension) - and could for example try upgrading to TCP, [D]TLS etc. The reason phrase provides something descriptive for devices that don't understand it. For those that don't, it'll fall back to treating it like a 400. ~ Theo From theo@crazygreek.co.uk Fri Feb 20 07:40:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E0C3A6A26 for ; Fri, 20 Feb 2009 07:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.45 X-Spam-Level: X-Spam-Status: No, score=-4.45 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 NxN8qa0qLZvc for ; Fri, 20 Feb 2009 07:40:02 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with SMTP id 16E503A6B54 for ; Fri, 20 Feb 2009 07:40:02 -0800 (PST) Received: from source ([72.14.220.155]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ7O4FlWkc1LpLmBoH6KIhUhqhrhkq2o@postini.com; Fri, 20 Feb 2009 07:40:17 PST Received: by fg-out-1718.google.com with SMTP id l27so1332304fgb.32 for ; Fri, 20 Feb 2009 07:40:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.60.14 with SMTP id i14mr1144917fga.70.1235144415946; Fri, 20 Feb 2009 07:40:15 -0800 (PST) In-Reply-To: References: <499E7BF8.7000109@ohlmeier.org> Date: Fri, 20 Feb 2009 15:40:15 +0000 Message-ID: <167dfb9b0902200740q6f57c74eq24f5986160946ee4@mail.gmail.com> From: Theo Zourzouvillys To: Henry Sinnreich Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Nils Ohlmeier , SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:40:03 -0000 On Fri, Feb 20, 2009 at 2:44 PM, Henry Sinnreich wrote= : Hi Henry, > Making a massive DOS attack on one single UAs does not seem a =93producti= ve=94 > technique for spammers. The problem isn't trying to stop spammers at all, it's trying to stop SIP servers being used as DOS amplifiers. > And if one individual is a valuable target, such individuals have other > communication means besides a sole SIP UA. The victim does not need to be a SIP UA, it could be any IP address at all. ~ Theo From theo@crazygreek.co.uk Fri Feb 20 07:42:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B463A6B65 for ; Fri, 20 Feb 2009 07:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.445 X-Spam-Level: X-Spam-Status: No, score=-5.445 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JhoMhQv-tVYs for ; Fri, 20 Feb 2009 07:42:07 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with SMTP id CA8D43A6AC6 for ; Fri, 20 Feb 2009 07:42:06 -0800 (PST) Received: from source ([72.14.220.156]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ7PXdjmVamDoGnu+6AhmWxrCiQSYqFB@postini.com; Fri, 20 Feb 2009 07:42:22 PST Received: by fg-out-1718.google.com with SMTP id 19so1379898fgg.3 for ; Fri, 20 Feb 2009 07:42:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.29.8 with SMTP id c8mr1146465fgc.67.1235144540127; Fri, 20 Feb 2009 07:42:20 -0800 (PST) In-Reply-To: <167dfb9b0902200736p2ccad1bcu68d59386dd84ef28@mail.gmail.com> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> <499E7BF8.7000109@ohlmeier.org> <167dfb9b0902200736p2ccad1bcu68d59386dd84ef28@mail.gmail.com> Date: Fri, 20 Feb 2009 15:42:18 +0000 Message-ID: <167dfb9b0902200742n25f1ca6fg5dda048486555382@mail.gmail.com> From: Theo Zourzouvillys To: Nils Ohlmeier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:42:07 -0000 On Fri, Feb 20, 2009 at 3:36 PM, Theo Zourzouvillys wrote: > Any proxy that does wish to be used as an amplifier should reject > requests without cookies with a stateless 4XX, or send a stateless > 401/407 if knows it can authenticate it's user. I of course mean does NOT wish to be used, ahem :-) ~ Theo From hsinnrei@adobe.com Fri Feb 20 07:45:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC4F3A6AD2 for ; Fri, 20 Feb 2009 07:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 WcI2MDFdI7Jr for ; Fri, 20 Feb 2009 07:45:11 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id 737923A6991 for ; Fri, 20 Feb 2009 07:45:07 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKSZ7QCmmKTDfFLxT/xJKMiag0OEIx0L8I@postini.com; Fri, 20 Feb 2009 07:45:26 PST Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1KFjBE0021609; Fri, 20 Feb 2009 07:45:11 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1KFjAl7021594; Fri, 20 Feb 2009 07:45:10 -0800 (PST) Received: from excas02.corp.adobe.com (10.8.188.212) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 20 Feb 2009 07:45:10 -0800 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Fri, 20 Feb 2009 07:45:10 -0800 From: Henry Sinnreich To: Theo Zourzouvillys Date: Fri, 20 Feb 2009 07:45:08 -0800 Thread-Topic: [Sip] draft-zourzouvillys-sip-via-cookie-00 Thread-Index: AcmTcYxUd7d8bL5IT/W7+gr3q+vbcwAAKiUs Message-ID: In-Reply-To: <167dfb9b0902200740q6f57c74eq24f5986160946ee4@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5C42C24B724hsinnreiadobecom_" MIME-Version: 1.0 Cc: Nils Ohlmeier , SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:45:14 -0000 --_000_C5C42C24B724hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >it's trying to stop SIP servers being used as DOS amplifiers. If you take this viewpoint, then the fewer servers, the less vulnerability? Henry On 2/20/09 9:40 AM, "Theo Zourzouvillys" wrote: On Fri, Feb 20, 2009 at 2:44 PM, Henry Sinnreich wrote= : Hi Henry, > Making a massive DOS attack on one single UAs does not seem a "productive= " > technique for spammers. The problem isn't trying to stop spammers at all, it's trying to stop SIP servers being used as DOS amplifiers. > And if one individual is a valuable target, such individuals have other > communication means besides a sole SIP UA. The victim does not need to be a SIP UA, it could be any IP address at all. ~ Theo --_000_C5C42C24B724hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 >it's trying to stop SIP servers being used as DOS amplifiers.

If you take this viewpoint, then the fewer servers, the less vulnerability?=

Henry


On 2/20/09 9:40 AM, "Theo Zourzouvillys" <theo@crazygreek.co.uk> wrote:

On Fri, Feb 20, 2009 at 2:44 PM, Henry Sinn= reich <hsinnrei@adobe.com> wrote:<= BR>
Hi Henry,

> Making a massive DOS attack on one single UAs does not seem a “p= roductive”
> technique for spammers.

The problem isn't trying to stop spammers at all, it's trying to stop
SIP servers being used as DOS amplifiers.

> And if one individual is a valuable target, such individuals have othe= r
> communication means besides a sole SIP UA.

The victim does not need to be a SIP UA, it could be any IP address at all.=

 ~ Theo

--_000_C5C42C24B724hsinnreiadobecom_-- From michael@voip.co.uk Fri Feb 20 07:53:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301593A67DD for ; Fri, 20 Feb 2009 07:53:24 -0800 (PST) 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.310, 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 YFvjeytWtSZH for ; Fri, 20 Feb 2009 07:53:22 -0800 (PST) Received: from voip.co.uk (smtp.sov.voip.co.uk [80.249.108.49]) by core3.amsl.com (Postfix) with ESMTP id B5EC328C23D for ; Fri, 20 Feb 2009 07:53:22 -0800 (PST) Message-ID: <499ED1FE.9070002@voip.co.uk> Date: Fri, 20 Feb 2009 15:53:34 +0000 From: Michael Procter User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Nils Ohlmeier , SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:53:24 -0000 Henry Sinnreich wrote: > >it's trying to stop SIP servers being used as DOS amplifiers. > > If you take this viewpoint, then the fewer servers, the less > vulnerability? > > Henry In this context, "SIP server" means both proxies and UAs (at least, their UAS component). Eliminating B2BUAs (which I think is what you were getting at) sadly won't eliminate this attack. Regards, Michael From cnmjbm@gmail.com Fri Feb 20 08:41:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622163A6A5B for ; Fri, 20 Feb 2009 08:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=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 ETDTqJNKzxqW for ; Fri, 20 Feb 2009 08:41:20 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 886BF3A6B42 for ; Fri, 20 Feb 2009 08:41:20 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1218747wfd.31 for ; Fri, 20 Feb 2009 08:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:reply-to:from:to :cc:references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=D9XJy/Gb7ggOKv0bKOuKOFMHT0tzY798OmTW+G19NQw=; b=ZLKiy3RnaP3mpn9Fp7f9ijohCoaVH7sft95z+KkwBMaAjQXdRDT8gmoZ122dd/1pR6 IpAOebGZdYGmFz6MtkbaH78exZ0YNhuXD7x5Qs4mNfTjvvRnRgQkBiF8Ok35gXMRoNlZ kVu+y8LFBlw5u6PWUHy3xfgvVsqjYcRe0TDCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:reply-to:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=pLUcAH5COoe7BqmXcrd1qowpr2WUNb1Mig3pm1jzVbWq5stK+U6Lay7FjOpPw0Tau3 n+axOV//suAWiZbG4EpLuE9PcAxDye8ib6G5avMF20sPH58k6uZFeKw2SUzkqhGxEROx P5qAxP5T8hy1J1M/02wGWHGkkAvw5HV21wHIk= Received: by 10.142.136.16 with SMTP id j16mr488759wfd.184.1235148094707; Fri, 20 Feb 2009 08:41:34 -0800 (PST) Received: from fleapapa02 ([74.95.193.74]) by mx.google.com with ESMTPS id 20sm5700573wfi.32.2009.02.20.08.41.34 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 08:41:34 -0800 (PST) Message-ID: <003a01c9937a$16e1f4d0$020aa8c0@WTF.COM> From: "cow" To: "Nils Ohlmeier" References: <001101c992f7$527fbb90$840010ac@panpipi> <499E70CB.3000004@ohlmeier.org> Date: Fri, 20 Feb 2009 08:41:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: sip@ietf.org Subject: Re: [Sip] questions about usage of tel URI with a SIP UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cow List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 16:41:21 -0000 Hi, Nils. Thank you a lot for the comments. Before I ask new categories of questions on sip-implementors list, may i elaborate my question and could you clarify your comments a little more ? As i know of RFC 3455, the URIs returned in P-Associate-ID header of REGISTER 200 response are to be populated as Address-of-Record of the registered UA and are to be used in FROM headers of subsequent outward requests by the UA. Let's take these *pseudo* SIP msgs for example: => UA 'a' registers itself via its outbound proxy with this REGISTER request: REGISTER sip:domain To: aor_of_a From: aor_of_a (or, aor_of_3rd-party) Contact: LOCATION_uri_of_a => Registrar returns 200: 200 OK To: aor_of_a From: aor_of_a (or, aor_of_3rd-party) P-Associated-ID: paid1_of_a, paid2_of_a, ... (let's assume paid1_of_a='1-408-444-5555') => Later, UA 'b' calls UA 'b': INVITE tel:+1-408-444-5555 To: tel:+1-408-444-5555 From: aor_of_b My question is: doesn't this INVITE go to IMS core and be resolved to INVITE LOCATION_uri_of_a To: tel:+1-408-444-5555 From: aor_of_b before it can arrive at UA 'a' ???? That is, in my knowledge, once after location is looked up and resolved by a SIP proxy, the INVITE Request-URI should no more be a tel uri, am i correct? Please advise. Thanks. Cowby ----- Original Message ----- From: "Nils Ohlmeier" To: "Cowby" Cc: Sent: Friday, February 20, 2009 12:58 AM Subject: Re: [Sip] questions about usage of tel URI with a SIP UA > Hello, > > Am 20.02.2009 2:05 Uhr, schrieb Cowby: >> Q1: is it possible that a SIP UA can receive incoming requests with tel >> uri >> as the request-uri? > > In IMS yes. > >> Q2: if the answer to Q1 is yes, how does a SIP UA normally handle tel uri >> to >> match the UA itself? > > Take a look at the P-Associated-URI header. > >> For example, if a UA has a mailto:"sip:cowby@cows.com' as its IMS public >> identity and +1-408-555-6666 as it global phone number, >> >> Q1: is it possible that the UA's P-CSCF can route an INVITE >> tel:+1-408-555-6666 request to the UA? > > Yes, see above. > >> Q2: how can the UA match itself when it is configured as cowby@cows.com >> but >> know nothing of its phone number? > > See above as well. > > BTW such questions should be directed to the sip-implementors mailing list > instead (although I'm not sure if they discuss IMS as well). > > Best regards > Nils Ohlmeier From dean.willis@softarmor.com Fri Feb 20 12:28:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14E93A690E for ; Fri, 20 Feb 2009 12:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.572, 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 CSYs4uLPE9tE for ; Fri, 20 Feb 2009 12:28:28 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C68CD3A66B4 for ; Fri, 20 Feb 2009 12:28:28 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n1KKSYiE025792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Feb 2009 14:28:35 -0600 Message-Id: <407A0722-E620-4D2A-8915-D47E68C52EFA@softarmor.com> From: Dean Willis To: Michael Procter In-Reply-To: <499ED1FE.9070002@voip.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 14:28:28 -0600 References: <499ED1FE.9070002@voip.co.uk> X-Mailer: Apple Mail (2.930.3) Cc: Nils Ohlmeier , SIP WG , Henry Sinnreich Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:28:35 -0000 On Feb 20, 2009, at 9:53 AM, Michael Procter wrote: > Henry Sinnreich wrote: >>> it's trying to stop SIP servers being used as DOS amplifiers. >> >> If you take this viewpoint, then the fewer servers, the less >> vulnerability? >> >> Henry > > In this context, "SIP server" means both proxies and UAs (at least, > their UAS component). Eliminating B2BUAs (which I think is what you > were getting at) sadly won't eliminate this attack. > I believe Henry would also like to reduce proxies. I'm becoming more and more fond of this as a general design principle. Quite possibly, the only proxies we should have are ones that provide the outbound/ registrar/rendezvous function set. And that's just because we don't have those functions at a lower transport level. Other proxy functions (like application dispatch and delivery) may be pointless exercises in futility. A working HIP-like transport layer could eliminate the outbound/registrar/rendezvous functions. Most of the other "proxy" functions we've discussed are probably better as UA functions. Of course, that doesn't help with an attack mode that turns UAs into amplifiers . . . -- Dean From rsaragad@cisco.com Thu Feb 19 18:41:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318A03A6B0F for ; Thu, 19 Feb 2009 18:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=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 HzrotDIsAWm1 for ; Thu, 19 Feb 2009 18:41:41 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 8A1683A6B3D for ; Thu, 19 Feb 2009 18:41:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,238,1233532800"; d="scan'208";a="43680330" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 20 Feb 2009 02:41:52 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1K2fq1l015053; Fri, 20 Feb 2009 08:11:52 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1K2foSH004451; Fri, 20 Feb 2009 02:41:51 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Feb 2009 08:11:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2009 08:11:50 +0530 Message-ID: <12CEFA6955F85042B5462C204F685195088ED670@xmb-blr-415.apac.cisco.com> In-Reply-To: <200902191102.n1JB22BZ025710@boreas.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC4028 (1687) Thread-Index: AcmSgY8oU1OyVWWrSOedAukmrJQbvwAgu8IA References: <200902191102.n1JB22BZ025710@boreas.isi.edu> From: "Radha Krishna Saragadam (rsaragad)" To: "RFC Errata System" , , "Jonathan Rosenberg (jdrosen)" , , "Cullen Jennings (fluffy)" , , X-OriginalArrivalTime: 20 Feb 2009 02:41:51.0400 (UTC) FILETIME=[C8C0CA80:01C99304] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6710; t=1235097712; x=1235961712; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rsaragad@cisco.com; z=From:=20=22Radha=20Krishna=20Saragadam=20(rsaragad)=22=20< rsaragad@cisco.com> |Subject:=20RE=3A=20[Technical=20Errata=20Reported]=20RFC40 28=20(1687) |Sender:=20; bh=Ka/bO+H71KZH1sNI6TuYY+cLWIzJXv+iFoREpEmTpAY=; b=jtIyhNFY+Ca9WNh0vf1pdI/8bIzFnVfAN8onPl1+qfdb7nxzTJzRmc2PP/ p1LJVXj3Oanwtdhao2jg+ZV3tL7WUzvX3Snu8edq/5Ar4eVXJr0WZKwy9JJz vYImHEZ2ac; Authentication-Results: ind-dkim-2; header.From=rsaragad@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Mailman-Approved-At: Fri, 20 Feb 2009 12:40:32 -0800 Cc: sip@ietf.org Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1687) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 02:44:12 -0000 Correction in "Corrected Text" Section: 9 Original Text ------------- The UAS MUST NOT increase the value of the Session-Expires header field. Corrected Text -------------- If the request doesn't indicate support for the session timer but contains a session interval that is too small, the UAS cannot usefully reject the request,as this would result in a call failure. Rather, the UAS SHOULD increase the Session-Expires header field value to be equal to its minimum interval in the response. Regards S.Radha krishna -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Thursday, February 19, 2009 4:32 PM To: srd@cisco.com; Jonathan Rosenberg (jdrosen); jon.peterson@neustar.biz; Cullen Jennings (fluffy); dean.willis@softarmor.com; drage@alcatel-lucent.com Cc: Radha Krishna Saragadam (rsaragad); sip@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC4028 (1687) The following errata report has been submitted for RFC4028, "Session Timers in the Session Initiation Protocol (SIP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4028&eid=3D1687 -------------------------------------- Type: Technical Reported by: Radha krishna Saragadam Section: 9 Original Text ------------- The UAS MUST NOT increase the value of the Session-Expires header field. Corrected Text -------------- same as session 8.1 If the request doesn't indicate support for the session timer but contains a session interval that is too small, the UAS cannot usefully reject the request, as this would result in a call failure. Rather, the UAS SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the UAS SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The UAS MUST then increase the Session-Expires header field value to be equal to the value in the Min-SE header field Notes ----- ----- Forwarded Message ---- From: Radha krishna To: Brett Tate ; "sip-implementors@lists.cs.columbia.edu" Sent: Thursday, February 19, 2009 10:56:31 AM Subject: Re: [Sip-implementors] Sending 422 Thanks Brett, So I think same should be added for UAS If the request doesn't indicate support for the session timer but =20 contains a session interval that is too small, the proxy cannot usefully reject the request, as this would result in a call failure. Rather, the proxy SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the proxy SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The proxy MUST then increase the Session-Expires header field value to be equal to the value in the Min-SE header field, as described above. Regards S.Radha krishna ________________________________ From: Brett Tate To: Radha krishna ; "sip-implementors@lists.cs.columbia.edu" Sent: Wednesday, February 18, 2009 6:42:31 PM Subject: RE: [Sip-implementors] Sending 422 It looks like Section 9 may have forgotten to indicate the behavior when UAC timer support not indicated. Section 8.1 allows a proxy to increase the Session-Expires; I see no reason why the same cannot be done by the UAS. > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-=20 > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Radha krishna > Sent: Tuesday, February 17, 2009 9:48 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Sending 422 > > Hi > > Consider the following topology > UA1 ----- Call-stateful-proxy ------ UA2 > > UA1 does not support session timer, Make a call to UA2. Call- > stateful-proxy adds Session-Expires:100 header and forwards to UA2.=20 > UA2 minimum session expires is 900. But in this case INVITE will not=20 > contain > "support: timer". According section 9, UAS can reject with 422 only if > there is a timer tag in supported header > > > > If an incoming request contains a Supported header field with a value > 'timer' and a Session Expires header field, the UAS MAY reject the > INVITE request with a 422 (Session Interval Too Small) response if > the session interval in the Session-Expires header field is smaller > than the minimum interval defined by the UAS' local policy. When > sending the 422 response, the UAS MUST include a Min-SE header field > with the value of its minimum interval. This minimum interval MUST > NOT be lower than 90 seconds. > > > Also UAS cannot increase the session expires duration from RFC> The UAS MUST > NOT increase the value of the Session-Expires header field. > > > What should be the behavior of UAS here? > 1) accept the call with 100 seconds? > 2) Increase the duration to 900 seconds while sending 200 Ok? > Note: Session timer should not be turned-off > > Regards > S.Radha krishna > > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors =20 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC4028 (draft-ietf-sip-session-timer-15) -------------------------------------- Title : Session Timers in the Session Initiation Protocol (SIP) Publication Date : April 2005 Author(s) : S. Donovan, J. Rosenberg Category : PROPOSED STANDARD Source : Session Initiation Protocol Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From theo@crazygreek.co.uk Fri Feb 20 13:05:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233DE3A6A66 for ; Fri, 20 Feb 2009 13:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0hb5lL9MuCDj for ; Fri, 20 Feb 2009 13:05:18 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id 062543A67EA for ; Fri, 20 Feb 2009 13:05:17 -0800 (PST) Received: from source ([72.14.220.156]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ8bG6cpTiE86YqXuoPY7Ppm21mYl2ZU@postini.com; Fri, 20 Feb 2009 13:05:33 PST Received: by fg-out-1718.google.com with SMTP id l26so1699495fgb.33 for ; Fri, 20 Feb 2009 13:05:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.59.2 with SMTP id h2mr1304893fga.30.1235163930233; Fri, 20 Feb 2009 13:05:30 -0800 (PST) In-Reply-To: <407A0722-E620-4D2A-8915-D47E68C52EFA@softarmor.com> References: <499ED1FE.9070002@voip.co.uk> <407A0722-E620-4D2A-8915-D47E68C52EFA@softarmor.com> Date: Fri, 20 Feb 2009 21:05:30 +0000 Message-ID: <167dfb9b0902201305k3aa3d271k59f770218be98283@mail.gmail.com> From: Theo Zourzouvillys To: Dean Willis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Nils Ohlmeier , SIP WG , Henry Sinnreich Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:05:19 -0000 On Fri, Feb 20, 2009 at 8:28 PM, Dean Willis wrote: > Of course, that doesn't help with an attack mode that turns UAs into > amplifiers . . . Well, luckily UAs could more easily remain stateless when rejecting responses than proxies, as they don't need to worry about things like forking (be it parallel or serial - e.g due to next hop SRV processing), so should be able to commonly respond to failure responses statelessly. This specific attack only arises when a there can be a invite server transaction created directly by a UDP request that has not been authenticated, and doesn't contain a "via cookie" alas, every UA implementation i've played with to date has almost always been stateful for even failure responses sent over UDP that havn't required a large amount of processing (or any variance) to reach it, except for some very low level induced responses like malformed header fields. ~ Theo From dworley@nortel.com Fri Feb 20 14:23:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014773A69BF for ; Fri, 20 Feb 2009 14:23:55 -0800 (PST) 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=[AWL=0.000, 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 7e6IsxtoY5uN for ; Fri, 20 Feb 2009 14:23:54 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C9CF43A63EC for ; Fri, 20 Feb 2009 14:23:53 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1KMO5H07419; Fri, 20 Feb 2009 22:24:05 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 17:24:03 -0500 From: "Dale Worley" To: Theo Zourzouvillys In-Reply-To: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 20 Feb 2009 17:24:03 -0500 Message-Id: <1235168643.3712.65.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2009 22:24:03.0335 (UTC) FILETIME=[EF7B2170:01C993A9] Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 22:23:55 -0000 Some quasi-nits regarding the presentation, followed by more substantive observations: On page 3, you do an accounting for the level of amplification and total 22 responses for a spoofed INVITE. But of course, if the spoofed call can be directed to a UA that will answer (voicemail, anyone?), there can be far more than 22 RTP packets generated. On page 7, the process of resending a response that was initially rejected with a 4XX is discussed. This should be clarified by noting that the resent request is a further fork of the original request, which is much different than the resending operation that is done by a UAC in response to a 401/407 response. In particular, the CSeq is not incremented. In the discussion, the terms "the client" and "the server" are used, which would lead people to think of SIP elements in the normal way. But in this case, each input or output address/port/transport triple of an element functions separately: A cookie used to send from a triple can only be used to send from that triple, and similarly, the client must cache known valid cookies for each destination triple separately. The proposed syntax for cookie is described in the text as using "-" as a separator, but the BNF uses ":". "-" should be used, as ":" is invalid in a "token". The example shows a request being sent with a value-less cookie parameter, though the BNF immediately above does not allow such a parameter. More importantly, such a value-less parameter does nothing useful: If the client will accept requests without cookies, a request without the parameter will be accepted. If the client will not accept requests without cookies, a request without the parameter will elicit a 4XX response, which can be used to resend the request. In regard to reusing the branch parameters of the initial request in the resent request -- please do not do that. Implementations already depend on proper uniqueness of branch parameters. In particular, a client that indexes its transaction states by branch value may respond to the resent request with the response that was given to the initial request, viz., 4XX. In regard to client address triples: For security, the client must generate a cookie that is valid for the address to which the response will be sent. And validating the cookie requires that the address from which the request is sent matches the address within the cookie. Together, these require "symmetric signaling", that responses always go to the same address from which their requests came, or more exactly, the address from which the resent request will come. In any case, the interaction with the SIP rules in section 18.2.2 need to be enunciated more clearly: o Otherwise (for unreliable unicast transports), if the top Via has a "received" parameter, the response MUST be sent to the address in the "received" parameter, using the port indicated in the "sent-by" value, or using port 5060 if none is specified explicitly. If this fails, for example, elicits an ICMP "port unreachable" response, the procedures of Section 5 of [4] SHOULD be used to determine where to send the response. o Otherwise, if it is not receiver-tagged, the response MUST be sent to the address indicated by the "sent-by" value, using the procedures in Section 5 of [4]. As Shamik notes, the cookie needs to be used not only to validate that the request comes from the address contained in the cookie, but also to validate the requested "sent-by" value, the address to which the response to the later request is to be sent. Actually, the cookie isn't needed to validate where the request comes from, but only to validate where the response will be sent. This allows us to escape the requirement for symmetric signaling described above -- cookies are generated based on the *destination* of the 4XX, and are validated against the *response destination address* not the *request source address*. This still has the required security property -- the client can only obtain the cookie for a destination D if D cooperates in capturing the cookie and providing it to the client. This does render unusable the clause "If this fails...", because the client has to know absolutely what the response destination will be. (Or can the requester provide multiple cookies for multiple possible destinations?) Of course, this mechanism only give benefit if servers start enforcing cookies, which can't be done until clients implement them. But the mechanism can be phased in, in that client implementations can be deployed first. Dale From lists@ohlmeier.org Fri Feb 20 15:22:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D18A3A6B42 for ; Fri, 20 Feb 2009 15:22:20 -0800 (PST) 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 2c-1TJHE6M5a for ; Fri, 20 Feb 2009 15:22:18 -0800 (PST) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 332063A6AD4 for ; Fri, 20 Feb 2009 15:22:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 927707F82; Sat, 21 Feb 2009 00:22:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q4kLn88mK2C; Sat, 21 Feb 2009 00:22:30 +0100 (CET) Received: from Nils-MacBook-2.local (unknown [78.52.229.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bespin.rfc3261.net (Postfix) with ESMTPSA id 23D7A7F55; Sat, 21 Feb 2009 00:22:30 +0100 (CET) Message-ID: <499F3B30.6000104@ohlmeier.org> Date: Sat, 21 Feb 2009 00:22:24 +0100 From: Nils Ohlmeier User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Theo Zourzouvillys References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> <499E7BF8.7000109@ohlmeier.org> <167dfb9b0902200736p2ccad1bcu68d59386dd84ef28@mail.gmail.com> In-Reply-To: <167dfb9b0902200736p2ccad1bcu68d59386dd84ef28@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:22:20 -0000 Hi Theo, Am 20.02.2009 16:36 Uhr, schrieb Theo Zourzouvillys: > On Fri, Feb 20, 2009 at 9:46 AM, Nils Ohlmeier wrote: >> I think the whole "attack scenario" which is described in the draft works >> only if the attacker uses the proxy/registrar of the victim as a relay. >> Reason 1): because the attacker hopefully does not know which UDP port of >> the victim is currently "open" to accept incoming UDP packets. And if their >> is a NAT or firewall in between the UA it will hopefully only accept UDP >> packets from the proxy/registrar. If the UA of the victim runs on a public >> IP without any "protection" it might accept SIP requests from anywhere, >> although I would call this a very bad UA implementation. > > A victim does not need to have an open UDP port; An attack can easily > be launched against any IP address, even a non SIP related one. Yes, similar to the DNS server aplimifaction attacs which are going on right now. I think should you should spend an extra section on the scenario to seperate it from the pure SIP scenario. > A device behind NAT on the end of a link additionally has no > protection at an IP level, as the link would easily become saturated > as a reflector starts sending failure response retransmits from a IST > every time timerG fires. Ok, I fear a shortage of you draft caused some confusion here: IMHO you should differentiate between the attacker, the amplifier and the victim. I was referring here to a UAC behind a NAT being the amplifier. You seemed to refer to the real victim here. With this said I think it would be good if you seperate in your draft between UA aplimifers and proxy amplifiers, because they result in different traffic numbers if I'm not wrong. Thus my original though was and still is, that it is most likely easier to mis-use any SIP proxy as amplifier. But a proxy will most likely "only" re-send any error response 11 times to the victim. I still believe a UAC should be harder to mis-use as an amplifier (see original reasons 1 and 2). >> Reason 2): when the UA of the victim registeres itself it provides a Contact >> URI. I general I believe UA should only accept incoming requests from their >> registrar IP and port which contains the Contact URI which they provided at >> the registration. This prevents very easily that someone sends drive by >> requests just with the AOR of the victim as R-URI to the UA of the victim. >> If a registrar forwards requests to registered UAs with the AOR of the user >> in the R-URI the registrar is broken in my opinion. > > as above - a victim does not need to be a SIP UA - it doesn't even > need to talk SIP. The attacker may well be trying to attack a non SIP > entity, for example a web, DNS, or mail server. > > On the flip side, a UA that "only accept"s requests from it's > registrar if of course good practice, but is only a step in stopping > SPIT, not denial of service (which this draft tries to tackle), unless > the "only accept" is limited by routability. Note even NAT doesn't > stop a denial of service attack being launched against the NAT > gateway, causing it's connectivity to become saturated. See above. As a victim it makes for sure no difference under which criterias a SIP implementation (if it speeks SIP at all) accepts messages. But as an amplifier it might make a difference. E.g. if the UA rejects the spoofed INVITE with a 305 Use Proxy (although this reply is ambigious), the victim will receive only 11 replies within 32 seconds. But if the UA accepts the INVITE and starts to ring, and the user accepts... your worst case scenario comes into play. > This draft is specifically trying to stopping a SIP server transaction > being used as an amplifying reflector in a (distributed) denial of > service attack. The victim of the attack does not need to be a SIP > endpoint (it doesn't even need to have any ports open!) > >> Now the question is of the proxy/registrar accepts requests from its users >> from anywhere. I guess that is what you mean with no authentication, right? > > Yes - any SIP server (note a UAS or proxy are both servers for this) > which allows an unauthenticated, untrusted user to create an invite > server transaction (even for failure delivery) is vulnerable. Agreed. Although a failed server transaction results in a lot less harm then an accepted call. Maybe some calculations about the amount of bytes would be helpfull here. >> One bigger concern for the whole approach is: if the attacker knows about >> this cookie extension he will for sure not put an empty cookie in the Via >> header of the request. But how does the proxy of the victim handle requests >> without the cookie extension? > > Any proxy that does wish to be used as an amplifier should reject > requests without cookies with a stateless 4XX, or send a stateless > 401/407 if knows it can authenticate it's user. > > Of course this is not going to be realistic from day 1, but this > document is a start in finding solutions to some of the DOS problems > we're currently susceptible to by putting a SIP server "on the net". > > Right now, there are a large number of SIP endpoints out there that > will amplify a single UDP packet sent to them, and the initiator of > the attack isn't even traceable! Yep. Like with this DNS amplification attack here: http://isc.sans.org/diary.html?storyid=5713 (And that only uses the amplification of bytes from a 1:1 request:response transaction... SIP is worse.) > (i'm starting to sound like a scaremonger, so i'll stop now :)) > >> If the proxy of the victim does not care about backward compatibility (maybe >> because attack previntion is more important), wouldn't the need a way to >> tell the sender of the request that the cookie extension is required to >> successfully relay requests? So wouldn't we need a new value for the >> Required header, or would a new 4XX response already be enough. > > I did briefly consider an option tag but the problem is a SIP UA does > not need to implement anything for it to potentially work - for > example a proxy can implement it on behalf of a group of trusted users > (for example, a corporate proxy or an outbound proxy that has > authenticated the inbound request). > > There would additionally be no mechanism for recovery if the server > refuses to process UDP requests without cookie support. The 4XX would > provide a code that allows a machine to understand that it failed due > to cookies (if it knew about, but didn't implement the extension) - > and could for example try upgrading to TCP, [D]TLS etc. The reason > phrase provides something descriptive for devices that don't > understand it. For those that don't, it'll fall back to treating it > like a 400. Ok, accepted. Cheers Nils From theo@crazygreek.co.uk Fri Feb 20 15:34:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F743A68F8 for ; Fri, 20 Feb 2009 15:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.622 X-Spam-Level: X-Spam-Status: No, score=-5.622 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5SiDGfxo8CUf for ; Fri, 20 Feb 2009 15:34:48 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id 3546828C169 for ; Fri, 20 Feb 2009 15:34:45 -0800 (PST) Received: from source ([72.14.220.159]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ8+I6OyMQfDaYmK41hLHlMXwOBIyHJm@postini.com; Fri, 20 Feb 2009 15:35:00 PST Received: by fg-out-1718.google.com with SMTP id l27so1565012fgb.38 for ; Fri, 20 Feb 2009 15:34:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.52.6 with SMTP id z6mr1300864fgz.35.1235172899184; Fri, 20 Feb 2009 15:34:59 -0800 (PST) In-Reply-To: <1235168643.3712.65.camel@victoria-pingtel-com.us.nortel.com> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> <1235168643.3712.65.camel@victoria-pingtel-com.us.nortel.com> Date: Fri, 20 Feb 2009 23:34:59 +0000 Message-ID: <167dfb9b0902201534p43093516ybf436edb1b017afb@mail.gmail.com> From: Theo Zourzouvillys To: Dale Worley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:34:49 -0000 On Fri, Feb 20, 2009 at 10:24 PM, Dale Worley wrote: Hi Dale, Thank you very much for your feedback. I've integrated all your comments into my working -01 draft, with some additional comments here (i'll reply to your other thoughts separately): > On page 3, you do an accounting for the level of amplification and total > 22 responses for a spoofed INVITE. =A0But of course, if the spoofed call > can be directed to a UA that will answer (voicemail, anyone?), there can > be far more than 22 RTP packets generated. absolutely! i'll elaborate on this more in -01, although i'm trying to be careful not to imply that this particular draft is attempting to solve RTP sink or in-dialog route/contact verification and only "drive by shooting" you can do with UDP - i've started a draft that documents that side of things (and a proposed solution) and will try to submit a -00 over the weekend. > More importantly, such a value-less parameter does nothing > useful: =A0If the client will accept requests without cookies, a request > without the parameter will be accepted. =A0If the client will not accept > requests without cookies, a request without the parameter will elicit a > 4XX response, which can be used to resend the request. A server could behave differently when it receives a request without a cookie in it, for example require authentication, redirect the user statelessly to another transport, or something we've not thought of just yet :-) It's also useful for diagnostic purposes for deployment: how will we know when adoption is so widespread it would be safe to require support for it for a request to proceed? > In regard to reusing the branch parameters of the initial request in the > resent request -- please do not do that. agreed - i'd already removed from my current rev. It was about 4am when i wrote that, and didn't think it through to well :-) ~ Theo From theo@crazygreek.co.uk Fri Feb 20 16:06:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5C53A68AE for ; Fri, 20 Feb 2009 16:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.673 X-Spam-Level: X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 HkRibAeIlEp0 for ; Fri, 20 Feb 2009 16:06:40 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id 2C8943A6806 for ; Fri, 20 Feb 2009 16:06:40 -0800 (PST) Received: from source ([72.14.220.158]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ9FnXQuMbGXo4XgNcDRTgW8cU1Pp5Te@postini.com; Fri, 20 Feb 2009 16:06:55 PST Received: by fg-out-1718.google.com with SMTP id d23so1367207fga.18 for ; Fri, 20 Feb 2009 16:06:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.65.9 with SMTP id n9mr1372711fga.55.1235174812840; Fri, 20 Feb 2009 16:06:52 -0800 (PST) In-Reply-To: <499F3B30.6000104@ohlmeier.org> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> <499E7BF8.7000109@ohlmeier.org> <167dfb9b0902200736p2ccad1bcu68d59386dd84ef28@mail.gmail.com> <499F3B30.6000104@ohlmeier.org> Date: Sat, 21 Feb 2009 00:06:52 +0000 Message-ID: <167dfb9b0902201606v7651d694ub17a842dc68239c1@mail.gmail.com> From: Theo Zourzouvillys To: Nils Ohlmeier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:06:41 -0000 Hi Nils, On Fri, Feb 20, 2009 at 11:22 PM, Nils Ohlmeier wrote: > Yes, similar to the DNS server aplimifaction attacs which are going on right > now. I think should you should spend an extra section on the scenario to > seperate it from the pure SIP scenario. > > [snip] > > With this said I think it would be good if you seperate in your draft > between UA aplimifers and proxy amplifiers, because they result in different > traffic numbers if I'm not wrong. Will do. > Agreed. Although a failed server transaction results in a lot less harm then > an accepted call. although "lot less harm" is still "way more harm than any other commonly deployed publicly accessible UDP based service" :-) > Maybe some calculations about the amount of bytes would be helpfull here. sure. ~ Theo -- Theo Zourzouvillys Chief Technical Officer VoIP.co.uk From theo@crazygreek.co.uk Fri Feb 20 16:44:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8D83A6BB5 for ; Fri, 20 Feb 2009 16:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.411 X-Spam-Level: X-Spam-Status: No, score=-5.411 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=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 m5tb932pKbG6 for ; Fri, 20 Feb 2009 16:44:48 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with SMTP id 67F233A6895 for ; Fri, 20 Feb 2009 16:44:19 -0800 (PST) Received: from source ([72.14.220.155]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ9Ocg8/lbhwm/ovYJUVIEuj4wKgKy1R@postini.com; Fri, 20 Feb 2009 16:44:35 PST Received: by fg-out-1718.google.com with SMTP id 19so1497198fgg.3 for ; Fri, 20 Feb 2009 16:44:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.71.1 with SMTP id t1mr1396909fga.18.1235177073546; Fri, 20 Feb 2009 16:44:33 -0800 (PST) In-Reply-To: <1235168643.3712.65.camel@victoria-pingtel-com.us.nortel.com> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> <1235168643.3712.65.camel@victoria-pingtel-com.us.nortel.com> Date: Sat, 21 Feb 2009 00:44:33 +0000 Message-ID: <167dfb9b0902201644w229871a2n46c50962bf6a518e@mail.gmail.com> From: Theo Zourzouvillys To: Dale Worley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:44:49 -0000 Hi Dale, On Fri, Feb 20, 2009 at 10:24 PM, Dale Worley wrote: > Actually, the cookie isn't needed to validate where the request comes > from, but only to validate where the response will be sent. =A0This allow= s > us to escape the requirement for symmetric signaling described above -- > cookies are generated based on the *destination* of the 4XX, and are > validated against the *response destination address* not the *request > source address*. =A0This still has the required security property -- the > client can only obtain the cookie for a destination D if D cooperates in > capturing the cookie and providing it to the client. =A0This does render > unusable the clause "If this fails...", because the client has to know > absolutely what the response destination will be. This actually seems like a far better way, althoguh the original reasoning was to handle the (all be it pathological) case of different stacks running on the same IP address but a different port as visible by a proxy - perhaps for example due to (argh!) CGNAT e.g on most mobile networks (at least in the UK) , or a serviced office which does NAT to the same external IP for all it's hosts. saying that, i'm not too fussed either way, and would appreciate any thoughts on it... > (Or can the requester provide multiple cookies for multiple possible > destinations?) I did consider this previously, but can'y see any way of being able to handle the case where sent-by contains a host name which resolves to multiple SRV records with same priority, as the response could go to any of them (and each would need to be validated and get it's own token) before passing it to the client to include in the request. cookies would also need to have a minimum lifetime, so that a server knows how long those it's generated are valid, and the whole thing becomes horribly complex... :-) my thinking was along the lines of because the response is going to be UDP, a server that needs the redundancy can use anycast on the single IP / port to ensure to gets the response, even if a given proxy (or even data centre) dies. ~ theo From hsinnrei@adobe.com Fri Feb 20 18:14:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37AC23A6964 for ; Fri, 20 Feb 2009 18:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=0.861, 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 ip4tSEhxQV6e for ; Fri, 20 Feb 2009 18:14:23 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by core3.amsl.com (Postfix) with ESMTP id 5085C3A67FB for ; Fri, 20 Feb 2009 18:14:15 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKSZ9jg7H0seCXFheT1SOV4zAmdvFXY4nG@postini.com; Fri, 20 Feb 2009 18:14:38 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1L2EOE0019191; Fri, 20 Feb 2009 18:14:24 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1L2EMiq000693; Fri, 20 Feb 2009 18:14:22 -0800 (PST) Received: from excas03.corp.adobe.com (10.8.189.123) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 20 Feb 2009 18:14:22 -0800 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Fri, 20 Feb 2009 18:14:22 -0800 From: Henry Sinnreich To: Theo Zourzouvillys , Dean Willis Date: Fri, 20 Feb 2009 18:14:20 -0800 Thread-Topic: [Sip] draft-zourzouvillys-sip-via-cookie-00 Thread-Index: AcmTnvz9k5ONieymScyNzPE0nAQy3QAKx3c8 Message-ID: In-Reply-To: <167dfb9b0902201305k3aa3d271k59f770218be98283@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5C4BF9CB77Dhsinnreiadobecom_" MIME-Version: 1.0 Cc: Nils Ohlmeier , SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 02:14:32 -0000 --_000_C5C4BF9CB77Dhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please correct me, but these and previous other discussions on related topi= cs, such as forking, early media and race conditions seem to confirm the fa= ct that no formal and reliable routing protocol has been developed as yet t= o route between a larger number (more than 2 in the trapezoid model) of SIP= proxies and various (Oh so many) other feature and media servers. If there were a reliable routing protocol between all the SIP network eleme= nts these discussions would not take place for so long and there would be j= ust one RFC describing something like "The SIP Network Routing Protocol". A= nd some open source implementation to prove it. As is, every SIP network must be manually engineered, for every configurati= on instance and adding yet another new "network service" requires starting = all over again. Is this view embarrassingly na=EFve? It is only meant to defend the view SIP should be used just as a rendezvous= and session setup protocol. Henry On 2/20/09 3:05 PM, "Theo Zourzouvillys" wrote: On Fri, Feb 20, 2009 at 8:28 PM, Dean Willis wr= ote: > Of course, that doesn't help with an attack mode that turns UAs into > amplifiers . . . Well, luckily UAs could more easily remain stateless when rejecting responses than proxies, as they don't need to worry about things like forking (be it parallel or serial - e.g due to next hop SRV processing), so should be able to commonly respond to failure responses statelessly. This specific attack only arises when a there can be a invite server transaction created directly by a UDP request that has not been authenticated, and doesn't contain a "via cookie" alas, every UA implementation i've played with to date has almost always been stateful for even failure responses sent over UDP that havn't required a large amount of processing (or any variance) to reach it, except for some very low level induced responses like malformed header fields. ~ Theo --_000_C5C4BF9CB77Dhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 Please correct me, but these and previous other discussions on relate= d topics, such as forking, early media and race conditions seem to confirm = the fact that no formal and reliable routing protocol has been developed as= yet to route between a larger number (more than 2 in the trapezoid model) = of SIP proxies and various (Oh so many) other feature and media servers.
If there were a reliable routing protocol between all the SIP network eleme= nts these discussions would not take place for so long and there would be j= ust one RFC describing something like “The SIP Network Routing= Protocol”. And some open source implementation to prove it.

As is, every SIP network must be manually engineered, for every configurati= on instance and adding yet another new “network service” requir= es starting all over again.

Is this view embarrassingly naïve?
It is only meant to defend the view SIP should be used just as a rendezvous= and session setup protocol.

Henry


On 2/20/09 3:05 PM, "Theo Zourzouvillys" <theo@crazygreek.co.uk> wrote:

On Fri, Feb 20, 2009 at 8:28 PM, Dean Willi= s <dean.willis@softarmor.com&g= t; wrote:

> Of course, that doesn't help with an attack mode that turns UAs into > amplifiers . . .

Well, luckily UAs could more easily remain stateless when rejecting
responses than proxies, as they don't need to worry about things like
forking (be it parallel or serial - e.g due to next hop SRV
processing), so should be able to commonly respond to failure
responses statelessly.

This specific attack only arises when a there can be a invite server
transaction created directly by a UDP request that has not been
authenticated, and doesn't contain a "via cookie"

alas, every UA implementation i've played with to date has almost
always been stateful for even failure responses sent over UDP that
havn't required a large amount of processing (or any variance) to
reach it, except for some very low level induced responses like
malformed header fields.

 ~ Theo

--_000_C5C4BF9CB77Dhsinnreiadobecom_-- From mdolly@att.com Fri Feb 20 19:03:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297993A6885 for ; Fri, 20 Feb 2009 19:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 ufrfWUXszvZT for ; Fri, 20 Feb 2009 19:03:09 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 63A343A6800 for ; Fri, 20 Feb 2009 19:03:09 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1235185401!2263640!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 20933 invoked from network); 21 Feb 2009 03:03:22 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 21 Feb 2009 03:03:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1L33LEX003658; Fri, 20 Feb 2009 22:03:21 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1L33Ip8003643; Fri, 20 Feb 2009 22:03:18 -0500 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_01C993D0.F1C8BC49" Date: Fri, 20 Feb 2009 22:03:17 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01239004@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-zourzouvillys-sip-via-cookie-00 Thread-Index: AcmTnvz9k5ONieymScyNzPE0nAQy3QAKx3c8AAG1xtw= From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: lists@ohlmeier.org, sip@ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 03:03:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C993D0.F1C8BC49 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gaGF2ZSBhIG1lYW5pbmdmdWwgZGlzY3Vzc2lvbiwgeW91IG5lZWQgdG8gZGlzY3VzcyBhcmNo aXRlY3R1cmUuIEFuZCBzb3JyeSwgRS10LUUgaXMgd3JvbmcNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KRnJvbTogc2lwLWJvdW5jZXNAaWV0Zi5vcmcgDQpUbzogVGhlbyBa b3Vyem91dmlsbHlzIDsgRGVhbiBXaWxsaXMgDQpDYzogTmlscyBPaGxtZWllciA7IFNJUCBXRyAN ClNlbnQ6IEZyaSBGZWIgMjAgMjE6MTQ6MjAgMjAwOQ0KU3ViamVjdDogUmU6IFtTaXBdIGRyYWZ0 LXpvdXJ6b3V2aWxseXMtc2lwLXZpYS1jb29raWUtMDAgDQoNCg0KUGxlYXNlIGNvcnJlY3QgbWUs IGJ1dCB0aGVzZSBhbmQgcHJldmlvdXMgb3RoZXIgZGlzY3Vzc2lvbnMgb24gcmVsYXRlZCB0b3Bp Y3MsIHN1Y2ggYXMgZm9ya2luZywgZWFybHkgbWVkaWEgYW5kIHJhY2UgY29uZGl0aW9ucyBzZWVt IHRvIGNvbmZpcm0gdGhlIGZhY3QgdGhhdCBubyBmb3JtYWwgYW5kIHJlbGlhYmxlIHJvdXRpbmcg cHJvdG9jb2wgaGFzIGJlZW4gZGV2ZWxvcGVkIGFzIHlldCB0byByb3V0ZSBiZXR3ZWVuIGEgbGFy Z2VyIG51bWJlciAobW9yZSB0aGFuIDIgaW4gdGhlIHRyYXBlem9pZCBtb2RlbCkgb2YgU0lQIHBy b3hpZXMgYW5kIHZhcmlvdXMgKE9oIHNvIG1hbnkpIG90aGVyIGZlYXR1cmUgYW5kIG1lZGlhIHNl cnZlcnMuDQoNCklmIHRoZXJlIHdlcmUgYSByZWxpYWJsZSByb3V0aW5nIHByb3RvY29sIGJldHdl ZW4gYWxsIHRoZSBTSVAgbmV0d29yayBlbGVtZW50cyB0aGVzZSBkaXNjdXNzaW9ucyB3b3VsZCBu b3QgdGFrZSBwbGFjZSBmb3Igc28gbG9uZyBhbmQgdGhlcmUgd291bGQgYmUganVzdCBvbmUgUkZD IGRlc2NyaWJpbmcgc29tZXRoaW5nIGxpa2Ug4oCcVGhlIFNJUCBOZXR3b3JrIFJvdXRpbmcgUHJv dG9jb2zigJ0uIEFuZCBzb21lIG9wZW4gc291cmNlIGltcGxlbWVudGF0aW9uIHRvIHByb3ZlIGl0 Lg0KDQpBcyBpcywgZXZlcnkgU0lQIG5ldHdvcmsgbXVzdCBiZSBtYW51YWxseSBlbmdpbmVlcmVk LCBmb3IgZXZlcnkgY29uZmlndXJhdGlvbiBpbnN0YW5jZSBhbmQgYWRkaW5nIHlldCBhbm90aGVy IG5ldyDigJxuZXR3b3JrIHNlcnZpY2XigJ0gcmVxdWlyZXMgc3RhcnRpbmcgYWxsIG92ZXIgYWdh aW4uDQoNCklzIHRoaXMgdmlldyBlbWJhcnJhc3NpbmdseSBuYcOvdmU/IA0KSXQgaXMgb25seSBt ZWFudCB0byBkZWZlbmQgdGhlIHZpZXcgU0lQIHNob3VsZCBiZSB1c2VkIGp1c3QgYXMgYSByZW5k ZXp2b3VzIGFuZCBzZXNzaW9uIHNldHVwIHByb3RvY29sLg0KDQpIZW5yeSANCg0KDQpPbiAyLzIw LzA5IDM6MDUgUE0sICJUaGVvIFpvdXJ6b3V2aWxseXMiIDx0aGVvQGNyYXp5Z3JlZWsuY28udWs+ IHdyb3RlOg0KDQoNCg0KCU9uIEZyaSwgRmViIDIwLCAyMDA5IGF0IDg6MjggUE0sIERlYW4gV2ls bGlzIDxkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPiB3cm90ZToNCgkNCgk+IE9mIGNvdXJzZSwg dGhhdCBkb2Vzbid0IGhlbHAgd2l0aCBhbiBhdHRhY2sgbW9kZSB0aGF0IHR1cm5zIFVBcyBpbnRv DQoJPiBhbXBsaWZpZXJzIC4gLiAuDQoJDQoJV2VsbCwgbHVja2lseSBVQXMgY291bGQgbW9yZSBl YXNpbHkgcmVtYWluIHN0YXRlbGVzcyB3aGVuIHJlamVjdGluZw0KCXJlc3BvbnNlcyB0aGFuIHBy b3hpZXMsIGFzIHRoZXkgZG9uJ3QgbmVlZCB0byB3b3JyeSBhYm91dCB0aGluZ3MgbGlrZQ0KCWZv cmtpbmcgKGJlIGl0IHBhcmFsbGVsIG9yIHNlcmlhbCAtIGUuZyBkdWUgdG8gbmV4dCBob3AgU1JW DQoJcHJvY2Vzc2luZyksIHNvIHNob3VsZCBiZSBhYmxlIHRvIGNvbW1vbmx5IHJlc3BvbmQgdG8g ZmFpbHVyZQ0KCXJlc3BvbnNlcyBzdGF0ZWxlc3NseS4NCgkNCglUaGlzIHNwZWNpZmljIGF0dGFj ayBvbmx5IGFyaXNlcyB3aGVuIGEgdGhlcmUgY2FuIGJlIGEgaW52aXRlIHNlcnZlcg0KCXRyYW5z YWN0aW9uIGNyZWF0ZWQgZGlyZWN0bHkgYnkgYSBVRFAgcmVxdWVzdCB0aGF0IGhhcyBub3QgYmVl bg0KCWF1dGhlbnRpY2F0ZWQsIGFuZCBkb2Vzbid0IGNvbnRhaW4gYSAidmlhIGNvb2tpZSINCgkN CglhbGFzLCBldmVyeSBVQSBpbXBsZW1lbnRhdGlvbiBpJ3ZlIHBsYXllZCB3aXRoIHRvIGRhdGUg aGFzIGFsbW9zdA0KCWFsd2F5cyBiZWVuIHN0YXRlZnVsIGZvciBldmVuIGZhaWx1cmUgcmVzcG9u c2VzIHNlbnQgb3ZlciBVRFAgdGhhdA0KCWhhdm4ndCByZXF1aXJlZCBhIGxhcmdlIGFtb3VudCBv ZiBwcm9jZXNzaW5nIChvciBhbnkgdmFyaWFuY2UpIHRvDQoJcmVhY2ggaXQsIGV4Y2VwdCBmb3Ig c29tZSB2ZXJ5IGxvdyBsZXZlbCBpbmR1Y2VkIHJlc3BvbnNlcyBsaWtlDQoJbWFsZm9ybWVkIGhl YWRlciBmaWVsZHMuDQoJDQoJIH4gVGhlbw0KCQ0KCQ0KDQo= ------_=_NextPart_001_01C993D0.F1C8BC49 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5SZTogW1NpcF0gZHJhZnQtem91cnpvdXZpbGx5cy1zaXAt dmlhLWNvb2tpZS0wMDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT48cD48Zm9udCBzaXplPTIgY29s b3I9bmF2eSBmYWNlPUFyaWFsPg0KVG8gaGF2ZSBhIG1lYW5pbmdmdWwgZGlzY3Vzc2lvbiwgeW91 IG5lZWQgdG8gZGlzY3VzcyBhcmNoaXRlY3R1cmUuIEFuZCBzb3JyeSwgRS10LUUgaXMgIHdyb25n PC9mb250PjwvcD4NCjxwPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJp bmRleD0tMT4NCjxmb250IGZhY2U9VGFob21hIHNpemU9Mj4NCjxiPkZyb208L2I+OiBzaXAtYm91 bmNlc0BpZXRmLm9yZyA8c2lwLWJvdW5jZXNAaWV0Zi5vcmc+DTxicj48Yj5UbzwvYj46IFRoZW8g Wm91cnpvdXZpbGx5cyA8dGhlb0BjcmF6eWdyZWVrLmNvLnVrPjsgRGVhbiBXaWxsaXMgPGRlYW4u d2lsbGlzQHNvZnRhcm1vci5jb20+DTxicj48Yj5DYzwvYj46IE5pbHMgT2hsbWVpZXIgPGxpc3Rz QG9obG1laWVyLm9yZz47IFNJUCBXRyA8c2lwQGlldGYub3JnPg08YnI+PGI+U2VudDwvYj46IEZy aSBGZWIgMjAgMjE6MTQ6MjAgMjAwOTxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtTaXBdIGRyYWZ0 LXpvdXJ6b3V2aWxseXMtc2lwLXZpYS1jb29raWUtMDANPGJyPjwvZm9udD48L3A+DQoNCjxGT05U IEZBQ0U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOIFNUWUxFPSdm b250LXNpemU6MTRwdCc+UGxlYXNlIGNvcnJlY3QgbWUsIGJ1dCB0aGVzZSBhbmQgcHJldmlvdXMg b3RoZXIgZGlzY3Vzc2lvbnMgb24gcmVsYXRlZCB0b3BpY3MsIHN1Y2ggYXMgZm9ya2luZywgZWFy bHkgbWVkaWEgYW5kIHJhY2UgY29uZGl0aW9ucyBzZWVtIHRvIGNvbmZpcm0gdGhlIGZhY3QgdGhh dCBubyBmb3JtYWwgYW5kIHJlbGlhYmxlIHJvdXRpbmcgcHJvdG9jb2wgaGFzIGJlZW4gZGV2ZWxv cGVkIGFzIHlldCB0byByb3V0ZSBiZXR3ZWVuIGEgbGFyZ2VyIG51bWJlciAobW9yZSB0aGFuIDIg aW4gdGhlIHRyYXBlem9pZCBtb2RlbCkgb2YgU0lQIHByb3hpZXMgYW5kIHZhcmlvdXMgKE9oIHNv IG1hbnkpIG90aGVyIGZlYXR1cmUgYW5kIG1lZGlhIHNlcnZlcnMuPEJSPg0KPEJSPg0KSWYgdGhl cmUgd2VyZSBhIHJlbGlhYmxlIHJvdXRpbmcgcHJvdG9jb2wgYmV0d2VlbiBhbGwgdGhlIFNJUCBu ZXR3b3JrIGVsZW1lbnRzIHRoZXNlIGRpc2N1c3Npb25zIHdvdWxkIG5vdCB0YWtlIHBsYWNlIGZv ciBzbyBsb25nIGFuZCB0aGVyZSB3b3VsZCBiZSBqdXN0IDxJPm9uZSBSRkM8L0k+IGRlc2NyaWJp bmcgc29tZXRoaW5nIGxpa2UgJiM4MjIwO1RoZSBTSVAgTmV0d29yayBSb3V0aW5nIFByb3RvY29s JiM4MjIxOy4gQW5kIHNvbWUgb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb24gdG8gcHJvdmUgaXQu PEJSPg0KPEJSPg0KQXMgaXMsIGV2ZXJ5IFNJUCBuZXR3b3JrIG11c3QgYmUgbWFudWFsbHkgZW5n aW5lZXJlZCwgZm9yIGV2ZXJ5IGNvbmZpZ3VyYXRpb24gaW5zdGFuY2UgYW5kIGFkZGluZyB5ZXQg YW5vdGhlciBuZXcgJiM4MjIwO25ldHdvcmsgc2VydmljZSYjODIyMTsgcmVxdWlyZXMgc3RhcnRp bmcgYWxsIG92ZXIgYWdhaW4uPEJSPg0KPEJSPg0KSXMgdGhpcyB2aWV3IGVtYmFycmFzc2luZ2x5 IG5hJml1bWw7dmU/IDxCUj4NCkl0IGlzIG9ubHkgbWVhbnQgdG8gZGVmZW5kIHRoZSB2aWV3IFNJ UCBzaG91bGQgYmUgdXNlZCBqdXN0IGFzIGEgcmVuZGV6dm91cyBhbmQgc2Vzc2lvbiBzZXR1cCBw cm90b2NvbC48QlI+DQo8QlI+DQpIZW5yeSA8QlI+DQo8QlI+DQo8QlI+DQpPbiAyLzIwLzA5IDM6 MDUgUE0sICZxdW90O1RoZW8gWm91cnpvdXZpbGx5cyZxdW90OyAmbHQ7PGEgaHJlZj0idGhlb0Bj cmF6eWdyZWVrLmNvLnVrIj50aGVvQGNyYXp5Z3JlZWsuY28udWs8L2E+Jmd0OyB3cm90ZTo8QlI+ DQo8QlI+DQo8L1NQQU4+PC9GT05UPjxCTE9DS1FVT1RFPjxGT05UIEZBQ0U9IkNhbGlicmksIFZl cmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTRwdCc+T24g RnJpLCBGZWIgMjAsIDIwMDkgYXQgODoyOCBQTSwgRGVhbiBXaWxsaXMgJmx0OzxhIGhyZWY9ImRl YW4ud2lsbGlzQHNvZnRhcm1vci5jb20iPmRlYW4ud2lsbGlzQHNvZnRhcm1vci5jb208L2E+Jmd0 OyB3cm90ZTo8QlI+DQo8QlI+DQomZ3Q7IE9mIGNvdXJzZSwgdGhhdCBkb2Vzbid0IGhlbHAgd2l0 aCBhbiBhdHRhY2sgbW9kZSB0aGF0IHR1cm5zIFVBcyBpbnRvPEJSPg0KJmd0OyBhbXBsaWZpZXJz IC4gLiAuPEJSPg0KPEJSPg0KV2VsbCwgbHVja2lseSBVQXMgY291bGQgbW9yZSBlYXNpbHkgcmVt YWluIHN0YXRlbGVzcyB3aGVuIHJlamVjdGluZzxCUj4NCnJlc3BvbnNlcyB0aGFuIHByb3hpZXMs IGFzIHRoZXkgZG9uJ3QgbmVlZCB0byB3b3JyeSBhYm91dCB0aGluZ3MgbGlrZTxCUj4NCmZvcmtp bmcgKGJlIGl0IHBhcmFsbGVsIG9yIHNlcmlhbCAtIGUuZyBkdWUgdG8gbmV4dCBob3AgU1JWPEJS Pg0KcHJvY2Vzc2luZyksIHNvIHNob3VsZCBiZSBhYmxlIHRvIGNvbW1vbmx5IHJlc3BvbmQgdG8g ZmFpbHVyZTxCUj4NCnJlc3BvbnNlcyBzdGF0ZWxlc3NseS48QlI+DQo8QlI+DQpUaGlzIHNwZWNp ZmljIGF0dGFjayBvbmx5IGFyaXNlcyB3aGVuIGEgdGhlcmUgY2FuIGJlIGEgaW52aXRlIHNlcnZl cjxCUj4NCnRyYW5zYWN0aW9uIGNyZWF0ZWQgZGlyZWN0bHkgYnkgYSBVRFAgcmVxdWVzdCB0aGF0 IGhhcyBub3QgYmVlbjxCUj4NCmF1dGhlbnRpY2F0ZWQsIGFuZCBkb2Vzbid0IGNvbnRhaW4gYSAm cXVvdDt2aWEgY29va2llJnF1b3Q7PEJSPg0KPEJSPg0KYWxhcywgZXZlcnkgVUEgaW1wbGVtZW50 YXRpb24gaSd2ZSBwbGF5ZWQgd2l0aCB0byBkYXRlIGhhcyBhbG1vc3Q8QlI+DQphbHdheXMgYmVl biBzdGF0ZWZ1bCBmb3IgZXZlbiBmYWlsdXJlIHJlc3BvbnNlcyBzZW50IG92ZXIgVURQIHRoYXQ8 QlI+DQpoYXZuJ3QgcmVxdWlyZWQgYSBsYXJnZSBhbW91bnQgb2YgcHJvY2Vzc2luZyAob3IgYW55 IHZhcmlhbmNlKSB0bzxCUj4NCnJlYWNoIGl0LCBleGNlcHQgZm9yIHNvbWUgdmVyeSBsb3cgbGV2 ZWwgaW5kdWNlZCByZXNwb25zZXMgbGlrZTxCUj4NCm1hbGZvcm1lZCBoZWFkZXIgZmllbGRzLjxC Uj4NCjxCUj4NCiZuYnNwO34gVGhlbzxCUj4NCjxCUj4NCjwvU1BBTj48L0ZPTlQ+PC9CTE9DS1FV T1RFPg0KPC9CT0RZPg0KPC9IVE1MPg0KDQo= ------_=_NextPart_001_01C993D0.F1C8BC49-- From theo@crazygreek.co.uk Sat Feb 21 23:32:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B61F28C182 for ; Sat, 21 Feb 2009 23:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7IuzY3A7S-g2 for ; Sat, 21 Feb 2009 23:32:36 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with SMTP id 8E95A28C17F for ; Sat, 21 Feb 2009 23:32:35 -0800 (PST) Received: from source ([72.14.220.157]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSaD/opssvRoXXugjCp1OvNmkMHKlqKzc@postini.com; Sat, 21 Feb 2009 23:32:52 PST Received: by fg-out-1718.google.com with SMTP id e12so2129285fga.19 for ; Sat, 21 Feb 2009 23:32:49 -0800 (PST) MIME-Version: 1.0 Sender: theo@crazygreek.co.uk Received: by 10.86.74.4 with SMTP id w4mr2141676fga.22.1235287969572; Sat, 21 Feb 2009 23:32:49 -0800 (PST) Date: Sun, 22 Feb 2009 07:32:49 +0000 X-Google-Sender-Auth: f9a096d055ad2c17 Message-ID: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> From: Theo Zourzouvillys To: SIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 07:32:41 -0000 Hi, i've just submitted a -01 based on the feedback i've received. While we've all known about the issue forever, i've never sat down to work out how bad it really is. The results are pretty scary: "best" case scenario is a 1:10 amplification, and "worst" i can easily get a 1:350 amplification by writing a quick script. Additionally, out of every single vendor's implementation i looked at, i've not yet found 1 that isn't vulnerable to being used in an attack: phones, proxies, and SBCs can all be made to participate. i'm surprised we've not seen this in the wild yet. I've been recently scanning for publicly accessible SIP servers, and out of a /8 (16 million hosts) that i've got through so far, there have been 72,725 SIP servers that are responding on port 5060 UDP. that's a lot of amplifiers that can be used in this attack: and that's only 1/100th of the currently allocated RIR IPv4 address space. ~ Theo From theo@crazygreek.co.uk Sat Feb 21 23:48:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C44C3A68C6 for ; Sat, 21 Feb 2009 23:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.48 X-Spam-Level: X-Spam-Status: No, score=-4.48 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 bIUFHapb1MMZ for ; Sat, 21 Feb 2009 23:48:52 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with SMTP id 75EC33A6884 for ; Sat, 21 Feb 2009 23:48:52 -0800 (PST) Received: from source ([72.14.220.152]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSaEDdbj0TbY51q6le4I+EY2S3ZdPrO1m@postini.com; Sat, 21 Feb 2009 23:49:09 PST Received: by fg-out-1718.google.com with SMTP id 19so1462996fgg.2 for ; Sat, 21 Feb 2009 23:49:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.59.18 with SMTP id h18mr2134367fga.45.1235288948408; Sat, 21 Feb 2009 23:49:08 -0800 (PST) In-Reply-To: References: <167dfb9b0902201305k3aa3d271k59f770218be98283@mail.gmail.com> Date: Sun, 22 Feb 2009 07:49:08 +0000 Message-ID: <167dfb9b0902212349r653cc5cta79c7fd65ae4995c@mail.gmail.com> From: Theo Zourzouvillys To: Henry Sinnreich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nils Ohlmeier , SIP WG , Dean Willis Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 07:48:53 -0000 On Sat, Feb 21, 2009 at 2:14 AM, Henry Sinnreich wrote= : > Is this view embarrassingly na=EFve? Well, i'd prefer to stay out of a discussion on anything other than getting the issue at hand fixed, as it's a major problem *right* *now* for operators who have no choice but to implement SIP/2.0 at it is on the public internet. On the other hand, i'll happily engage in any discussion about anything at all in SF :-) (on that note, i'm going to be around SF/mountain view the whole of the week before the IETF if anyone else is and wants to meet up for drinks or food and general SIP chat - contact me offlist). ~ Theo From HKaplan@acmepacket.com Sun Feb 22 08:21:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70D73A6AAA for ; Sun, 22 Feb 2009 08:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=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 0WdRfar0LzO7 for ; Sun, 22 Feb 2009 08:21:10 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A18533A6783 for ; Sun, 22 Feb 2009 08:21:10 -0800 (PST) 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.291.1; Sun, 22 Feb 2009 11:20:04 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 22 Feb 2009 11:20:03 -0500 From: Hadriel Kaplan To: Theo Zourzouvillys , SIP WG Date: Sun, 22 Feb 2009 11:19:37 -0500 Thread-Topic: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) Thread-Index: AcmUv54nDorT4z5ySkOyA+3pwG0gDwAPXjcA Message-ID: References: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> In-Reply-To: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.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 Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 16:21:11 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of The= o > Zourzouvillys > Sent: Sunday, February 22, 2009 2:33 AM > > While we've all known about the issue forever, i've never sat down to > work out how bad it really is. > The results are pretty scary: "best" case scenario is a 1:10 > amplification, and "worst" i can easily get a 1:350 amplification by > writing a quick script. > > Additionally, out of every single vendor's implementation i looked at, > i've not yet found 1 that isn't vulnerable to being used in an attack: > phones, proxies, and SBCs can all be made to participate. I'm not debating your draft's premise, but that last statement is highly de= pendent on the system and deployment's configuration. For the remainder of= this I'll use the term "SBC", but as far as I know proxies can do this too= . SBCs can be and almost always are configured to only accept requests from r= egistered UA's. So let's say you guessed one or many of them correctly; bo= th their AoR's and guessed their full contact URI's (including username) an= d Via/Layer-3 IP:ports as well. In typical deployments the request will be= challenged, so the amplification is the 100 and 401/407 challenges, not a = full call's worth of 18x/200 and RTP. (And in practice there are some tric= ks the SBC can do to reduce actual amplification to 1:1, but it's rare to e= nable it - if amplification attacks are actually encountered, then this may= change) So the next issue is attack volume, and again it depends. SBCs can and oft= en do throttle the number of requests they'll accept in any time period fro= m any given UA. So they won't flood the target UA with bogus responses, be= cause they won't accept that many spoofed requests from it to begin with - = for some vendors they have hardware that will silently drop the excess. What will sometimes happen is the SBC will dynamically black-list a floodin= g UA, so that if you successfully spoof one you can knock it out of service= anyway, for a period of time. Of course this triggers traps to notify the= admins to look into it, but at least temporarily the damage is done. But t= hat's by design - if you're successfully spoofing another UA, then the best= an SBC can do is limit the impact of that to affect only the spoofed UA an= d not impact other users. The harder problem is SIP trunks, a la IP-PBX's. If they aren't a register= ing type of PBX, then their addresses are usually provisioned in the SBC's = in terms of ACLs; both layer-3 ACLs and layer-7, such that you'd still have= to spoof more than just IP:port. But it's a harder problem because it's e= asier to guess that stuff for an Enterprise than from a subscriber, and bec= ause they often aren't challenge-able. They're still usually throttled; an= d in theory potentially blacklisted, though that's less common to enable fo= r PBX connections. The only good side of it is the bigger the Enterprise, = the more likely the SIP trunk is over a VPN of some type, where the spoofed= requests would have to come in on that VPN to be processed. BTW, we do recommend to providers that they employ uRPF on their edge route= rs, and some can and do. Others don't have that ability or don't own the w= hole network, or don't want to take the performance impact of doing it on t= heir routers. (because many routers take a hit for uRPF) -hadriel From theo@crazygreek.co.uk Sun Feb 22 12:32:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3393A6823 for ; Sun, 22 Feb 2009 12:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pHbRpVvTCkDx for ; Sun, 22 Feb 2009 12:32:21 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with SMTP id E5B7C3A67FA for ; Sun, 22 Feb 2009 12:32:20 -0800 (PST) Received: from source ([72.14.220.155]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSaG2ZHuBWYBYhlls9HUPfJrEU2IsGH38@postini.com; Sun, 22 Feb 2009 12:32:38 PST Received: by fg-out-1718.google.com with SMTP id d23so1607354fga.18 for ; Sun, 22 Feb 2009 12:32:36 -0800 (PST) MIME-Version: 1.0 Sender: theo@crazygreek.co.uk Received: by 10.86.77.5 with SMTP id z5mr247032fga.3.1235334755781; Sun, 22 Feb 2009 12:32:35 -0800 (PST) In-Reply-To: References: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> Date: Sun, 22 Feb 2009 20:32:35 +0000 X-Google-Sender-Auth: fb2dded70d1d6d9b Message-ID: <167dfb9b0902221232m604d7969u7a880378d50fa6d7@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIP WG Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:32:22 -0000 On Sun, Feb 22, 2009 at 4:19 PM, Hadriel Kaplan wr= ote: > SBCs can be and almost always are configured to only accept requests from= registered UA's. What about an SBC that is configured at the edge of a network, for example the thing that is the target of the URIs placed into ENUM? Or service providers who want to accept calls from "the internet" through an SBC? These are vulnerable, are they not? ... i'm not worried about an amplification risk with a user that can be authenticaticated: the 401/407 can be sent statelessly, meaning only a very small amplification ratio and only 1:1 packets. (although note that most UAs and proxies i tested did not currently send them statelessly and instead created a IST for them along with them and fire timer G!) - i imagine a well designed SBC would perform differently, although i didn't happen to have a well designed SBC from a certain vendor available for testing, so couldn't say :-) >=A0In typical deployments the request will be challenged, so the amplifica= tion is the 100 and 401/407 challenges are there ever any reasons for an SBC to not send the 401/407 statelessly, and even send a 100? A 1:2 attack is still bad, albeit a far cry from the pathological case. > not a full call's worth of 18x/200 and RTP. bear in mind the via-cookie doesn't stop the in-dialog/rtp targeting, but it does mean that it's traceable, and thus "manageable" once a solution like via-cookie is in place. I think work needs to be done on that issue too, but it's no where near as risky as this issue is. > SBCs can and often do throttle the number of requests they'll accept in a= ny time period from any given UA. =A0So they won't flood the target UA with= bogus responses, because they won't accept that many spoofed requests from= it to begin with - for some vendors they have hardware that will silently = drop the excess. Having a single SIP element doing rate limiting doesn't matter though when there are 7.2 million SIP devices on the net [1]. If each one will allow a 1:10 amplification, that's all a botnet needs to make it 10 times more valuable. Hell, even a 1:2 amplification is worth it for them, especially as it's reflected. > What will sometimes happen is the SBC will dynamically black-list a flood= ing UA, so that if you successfully spoof one you can knock it out of servi= ce anyway, for a period of time. =A0Of course this triggers traps to notify= the admins to look into it, but at least temporarily the damage is done. B= ut that's by design - if you're successfully spoofing another UA, then the = best an SBC can do is limit the impact of that to affect only the spoofed U= A and not impact other users. ... cookies solves this particular attack though, doesn't it? (although authentication does as well in this scenario due to a nonce?), in the same way a syncookie does for the SYN flooding problems of decades gone by. > BTW, we do recommend to providers that they employ uRPF on their edge rou= ters, and some can and do. absolutely. over time we've got to the point where *most* UK SPs worth their salt are doing RPF, but .... >=A0Others don't have that ability or don't own the whole network, or don't= want to take the performance impact of doing it on their routers. (because= many routers take a hit for uRPF) It's partially loosing battle trying to get service providers to do it (~6 years years ago i went on a rampage to try and get UK ISPs to do it - some did, most didn't. thankfully most have since then, though), and while it is important (it makes bot nets lifes harder) in the global scheme of things, as you say many don't - and it only takes one to have a problem. Even if everyone did RPF at the access layer, it doesn't stop attackers. They just become service providers themself (this is what spammers have done as thigns got more difficult for them). You don't even need to inject a prefix into global routing tables: simply transmitting the packets is all it takes, and won't even be traceable. There are bunches of issues at IXs as well: there is no way ports can be L3 filtered there currently. The SIDR WG is trying to find solutions to some this, but it's a long way off becoming reality imo. ~ Theo 1 - completely random guess from my (72k * 100). From fluffy@cisco.com Sun Feb 22 13:43:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08F928C1D8 for ; Sun, 22 Feb 2009 13:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.69 X-Spam-Level: X-Spam-Status: No, score=-106.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvkUa4WoAd06 for ; Sun, 22 Feb 2009 13:43:06 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A5A6628C1C9 for ; Sun, 22 Feb 2009 13:43:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,251,1233532800"; d="scan'208";a="254637280" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Feb 2009 21:43:24 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1MLhOVr001099; Sun, 22 Feb 2009 13:43:24 -0800 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1MLhMrI000443; Sun, 22 Feb 2009 21:43:23 GMT From: Cullen Jennings To: Christer Holmberg In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 14:43:22 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=946; t=1235339004; x=1236203004; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20New=20version=20(-05)=20of=20th e=20199=20draft=20-=20ready=20for=20WGLC? |Sender:=20; bh=tTUPlzEaVbwC/eUsh24EWnla7SQQYqVp4GOJu8dTV0Y=; b=qnj45nYae6YWUIAvXeB7Z7nx4cVrvOXxrAofkf3g4PqR3dJD5iK6nbzw45 71A+FBa0zV6G8tceNWmpucJgufPAzHAMMv9uG+vsngbsGiTf858qdDhHxSsm PxV5q74m80TcQNZII5jqHnyglUkwj9zex8Hzux6Et4kz+OKS+wMig=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, Keith Drage , Dean Willis Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 21:43:07 -0000 I'm looking at this and it seems to me this is not yet a WG draft - A WGLC might be a bit premature. On Feb 19, 2009, at 4:12 AM, Christer Holmberg wrote: > > Hi, > > I've submitted a new version of draft-ietf-sip-199. I have done > changes and updates based on feedback and discussions (please let me > know if you think I've forgotten something), and I've also added > text to the security chapter. > > I propose that we start the WGLC process for the draft. > > The draft can also be found at: > > http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-05.txt > > Regards, > > Christer > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From brett@broadsoft.com Sun Feb 22 14:41:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA9C3A686C for ; Sun, 22 Feb 2009 14:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id borBhCsBsRcK for ; Sun, 22 Feb 2009 14:41:28 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 6F6063A683D for ; Sun, 22 Feb 2009 14:41:28 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 22 Feb 2009 14:41:45 -0800 From: Brett Tate To: Cullen Jennings Date: Sun, 22 Feb 2009 14:41:44 -0800 Thread-Topic: [Sip] New version (-05) of the 199 draft - ready for WGLC? Thread-Index: AcmVNphh06nekxqASg6xlZWn+mljhAAAOltA Message-ID: <9B2A061A1137254BBE4F4B2CD843646A0FEA81D107@mbx02.citservers.local> 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 Cc: "sip@ietf.org" Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 22:41:29 -0000 Cullen, What do you mean by "not yet a WG draft"? Didn't it become the WG draft Ma= y 2008 to address the WG chartered item: "Termination of early dialog prior= to final response"? =20 The status within the charter appears to indicate that the WGLC is already = "Done". :)=20 Other than maybe delaying until there are more implementations, is there a = reason to delay the WGLC? I doubt delaying the WGLC would get any of the n= on interested participants to provide comments; however a WGLC might finall= y get them to send comments other than indicate that they are not intereste= d in completing the draft unless it also solves HERFP. Thanks, Brett > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Sunday, February 22, 2009 4:43 PM > To: Christer Holmberg > Cc: sip@ietf.org; Keith Drage; Dean Willis > Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? >=20 >=20 > I'm looking at this and it seems to me this is not yet a WG draft - A > WGLC might be a bit premature. >=20 >=20 > On Feb 19, 2009, at 4:12 AM, Christer Holmberg wrote: >=20 > > > > Hi, > > > > I've submitted a new version of draft-ietf-sip-199. I have done > > changes and updates based on feedback and discussions (please let me > > know if you think I've forgotten something), and I've also added > > text to the security chapter. > > > > I propose that we start the WGLC process for the draft. > > > > The draft can also be found at: > > > > http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-05.txt > > > > Regards, > > > > Christer From mdolly@att.com Sun Feb 22 15:06:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B1528C0FD for ; Sun, 22 Feb 2009 15:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdi+e3eHZdCM for ; Sun, 22 Feb 2009 15:06:35 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id B2C1C3A69DD for ; Sun, 22 Feb 2009 15:06:35 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-15.tower-146.messagelabs.com!1235344011!13321694!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 9230 invoked from network); 22 Feb 2009 23:06:51 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 22 Feb 2009 23:06:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1MN6oiK029657 for ; Sun, 22 Feb 2009 18:06:50 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1MN6kSQ029639 for ; Sun, 22 Feb 2009 18:06:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 22 Feb 2009 18:06:45 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01239017@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version (-05) of the 199 draft - ready for WGLC? Thread-Index: AcmVNphh06nekxqASg6xlZWn+mljhAAAOltAAAKuh4s= From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: sip@ietf.org Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 23:06:36 -0000 V2Ugd291bGQgbGlrZSB0byBzZWUgdGhpcyBwcm9ncmVzcyBhcyB3ZWxsDQoNCi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IHNpcC1ib3VuY2VzQGlldGYub3JnIDxzaXAtYm91bmNl c0BpZXRmLm9yZz4NClRvOiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb20+DQpDYzog c2lwQGlldGYub3JnIDxzaXBAaWV0Zi5vcmc+DQpTZW50OiBTdW4gRmViIDIyIDE3OjQxOjQ0IDIw MDkNClN1YmplY3Q6IFJlOiBbU2lwXSBOZXcgdmVyc2lvbiAoLTA1KSBvZiB0aGUgMTk5IGRyYWZ0 IC0gcmVhZHkgZm9yIFdHTEM/DQoNCkN1bGxlbiwNCg0KV2hhdCBkbyB5b3UgbWVhbiBieSAibm90 IHlldCBhIFdHIGRyYWZ0Ij8gIERpZG4ndCBpdCBiZWNvbWUgdGhlIFdHIGRyYWZ0IE1heSAyMDA4 IHRvIGFkZHJlc3MgdGhlIFdHIGNoYXJ0ZXJlZCBpdGVtOiAiVGVybWluYXRpb24gb2YgZWFybHkg ZGlhbG9nIHByaW9yIHRvIGZpbmFsIHJlc3BvbnNlIj8gIA0KDQpUaGUgc3RhdHVzIHdpdGhpbiB0 aGUgY2hhcnRlciBhcHBlYXJzIHRvIGluZGljYXRlIHRoYXQgdGhlIFdHTEMgaXMgYWxyZWFkeSAi RG9uZSIuIDopIA0KDQpPdGhlciB0aGFuIG1heWJlIGRlbGF5aW5nIHVudGlsIHRoZXJlIGFyZSBt b3JlIGltcGxlbWVudGF0aW9ucywgaXMgdGhlcmUgYSByZWFzb24gdG8gZGVsYXkgdGhlIFdHTEM/ ICBJIGRvdWJ0IGRlbGF5aW5nIHRoZSBXR0xDIHdvdWxkIGdldCBhbnkgb2YgdGhlIG5vbiBpbnRl cmVzdGVkIHBhcnRpY2lwYW50cyB0byBwcm92aWRlIGNvbW1lbnRzOyBob3dldmVyIGEgV0dMQyBt aWdodCBmaW5hbGx5IGdldCB0aGVtIHRvIHNlbmQgY29tbWVudHMgb3RoZXIgdGhhbiBpbmRpY2F0 ZSB0aGF0IHRoZXkgYXJlIG5vdCBpbnRlcmVzdGVkIGluIGNvbXBsZXRpbmcgdGhlIGRyYWZ0IHVu bGVzcyBpdCBhbHNvIHNvbHZlcyBIRVJGUC4NCg0KVGhhbmtzLA0KQnJldHQNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnNpcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gQ3VsbGVuIEplbm5pbmdzDQo+ IFNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMjIsIDIwMDkgNDo0MyBQTQ0KPiBUbzogQ2hyaXN0ZXIg SG9sbWJlcmcNCj4gQ2M6IHNpcEBpZXRmLm9yZzsgS2VpdGggRHJhZ2U7IERlYW4gV2lsbGlzDQo+ IFN1YmplY3Q6IFJlOiBbU2lwXSBOZXcgdmVyc2lvbiAoLTA1KSBvZiB0aGUgMTk5IGRyYWZ0IC0g cmVhZHkgZm9yIFdHTEM/DQo+IA0KPiANCj4gSSdtIGxvb2tpbmcgYXQgdGhpcyBhbmQgaXQgc2Vl bXMgdG8gbWUgdGhpcyBpcyBub3QgeWV0IGEgV0cgZHJhZnQgLSBBDQo+IFdHTEMgbWlnaHQgYmUg YSBiaXQgcHJlbWF0dXJlLg0KPiANCj4gDQo+IE9uIEZlYiAxOSwgMjAwOSwgYXQgNDoxMiBBTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+IA0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBJJ3Zl IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtc2lwLTE5OS4gSSBoYXZlIGRv bmUNCj4gPiBjaGFuZ2VzIGFuZCB1cGRhdGVzIGJhc2VkIG9uIGZlZWRiYWNrIGFuZCBkaXNjdXNz aW9ucyAocGxlYXNlIGxldCBtZQ0KPiA+IGtub3cgaWYgeW91IHRoaW5rIEkndmUgZm9yZ290dGVu IHNvbWV0aGluZyksIGFuZCBJJ3ZlIGFsc28gYWRkZWQNCj4gPiB0ZXh0IHRvIHRoZSBzZWN1cml0 eSBjaGFwdGVyLg0KPiA+DQo+ID4gSSBwcm9wb3NlIHRoYXQgd2Ugc3RhcnQgdGhlIFdHTEMgcHJv Y2VzcyBmb3IgdGhlIGRyYWZ0Lg0KPiA+DQo+ID4gVGhlIGRyYWZ0IGNhbiBhbHNvIGJlIGZvdW5k IGF0Og0KPiA+DQo+ID4gaHR0cDovL3VzZXJzLnBpdWhhLm5ldC9jaG9sbWJlci9kcmFmdHMvZHJh ZnQtaWV0Zi1zaXAtMTk5LTA1LnR4dA0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IENocmlz dGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpT aXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cA0KVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3Rv Y29sDQpVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBv biBjdXJyZW50IHNpcA0KVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMg b24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0K From fluffy@cisco.com Sun Feb 22 15:55:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8163A6ADA for ; Sun, 22 Feb 2009 15:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.682 X-Spam-Level: X-Spam-Status: No, score=-106.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-XWvPVW+9Bf for ; Sun, 22 Feb 2009 15:55:07 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4DD733A67E3 for ; Sun, 22 Feb 2009 15:55:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,251,1233532800"; d="scan'208";a="254672552" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Feb 2009 23:55:24 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1MNtOkp021787; Sun, 22 Feb 2009 15:55:24 -0800 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.13.8) with ESMTP id n1MNtMm2008277; Sun, 22 Feb 2009 23:55:22 GMT From: Cullen Jennings To: Brett Tate In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A0FEA81D107@mbx02.citservers.local> Impp: xmpp:cullenfluffyjennings@jabber.org References: <9B2A061A1137254BBE4F4B2CD843646A0FEA81D107@mbx02.citservers.local> Message-Id: <6C00A189-7DE3-451D-8E28-20C9B5B284D4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 16:55:21 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2032; t=1235346924; x=1236210924; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20New=20version=20(-05)=20of=20th e=20199=20draft=20-=20ready=20for=20WGLC? |Sender:=20; bh=1H11HV3U5i6VYjkF+QTd/kXrnbm1898sHTqaHhcQwQc=; b=LPryfbrENjzwaAXT152cnPE1Dqpbjqu8cl46U136FYA7c9EP1nj0a2gHVP qmoFr7lkKUqKuLiADmSIKalzKD1jVIuMJH96kARH1j6/gG4WG4ydAb6wiVty Wolw4THZZ0; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "sip@ietf.org" Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 23:55:08 -0000 Brett, you are right - I just totally messed this one up and missed it when I went looking. My apologies - I was just trying to clean up too many emails too quickly. Please ignore my previous email and finish this WG draft really soon :-) Sorry, Cullen On Feb 22, 2009, at 3:41 PM, Brett Tate wrote: > Cullen, > > What do you mean by "not yet a WG draft"? Didn't it become the WG > draft May 2008 to address the WG chartered item: "Termination of > early dialog prior to final response"? > > The status within the charter appears to indicate that the WGLC is > already "Done". :) > > Other than maybe delaying until there are more implementations, is > there a reason to delay the WGLC? I doubt delaying the WGLC would > get any of the non interested participants to provide comments; > however a WGLC might finally get them to send comments other than > indicate that they are not interested in completing the draft unless > it also solves HERFP. > > Thanks, > Brett > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Cullen Jennings >> Sent: Sunday, February 22, 2009 4:43 PM >> To: Christer Holmberg >> Cc: sip@ietf.org; Keith Drage; Dean Willis >> Subject: Re: [Sip] New version (-05) of the 199 draft - ready for >> WGLC? >> >> >> I'm looking at this and it seems to me this is not yet a WG draft - A >> WGLC might be a bit premature. >> >> >> On Feb 19, 2009, at 4:12 AM, Christer Holmberg wrote: >> >>> >>> Hi, >>> >>> I've submitted a new version of draft-ietf-sip-199. I have done >>> changes and updates based on feedback and discussions (please let me >>> know if you think I've forgotten something), and I've also added >>> text to the security chapter. >>> >>> I propose that we start the WGLC process for the draft. >>> >>> The draft can also be found at: >>> >>> http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-05.txt >>> >>> Regards, >>> >>> Christer > From HKaplan@acmepacket.com Sun Feb 22 15:56:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020D63A6AFD for ; Sun, 22 Feb 2009 15:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIdZwxKOPLZM for ; Sun, 22 Feb 2009 15:56:43 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E520A3A67E3 for ; Sun, 22 Feb 2009 15:56:42 -0800 (PST) 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.291.1; Sun, 22 Feb 2009 18:55:38 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 22 Feb 2009 18:55:37 -0500 From: Hadriel Kaplan To: Theo Zourzouvillys Date: Sun, 22 Feb 2009 18:55:13 -0500 Thread-Topic: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) Thread-Index: AcmVLIUUztTXL6muSpuh+acz6edqGQAFQ5Vg Message-ID: References: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> <167dfb9b0902221232m604d7969u7a880378d50fa6d7@mail.gmail.com> In-Reply-To: <167dfb9b0902221232m604d7969u7a880378d50fa6d7@mail.gmail.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: SIP WG Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 23:56:44 -0000 > -----Original Message----- > From: theo@crazygreek.co.uk [mailto:theo@crazygreek.co.uk] On Behalf Of > Theo Zourzouvillys > Sent: Sunday, February 22, 2009 3:33 PM > > On Sun, Feb 22, 2009 at 4:19 PM, Hadriel Kaplan > wrote: > > > SBCs can be and almost always are configured to only accept requests > from registered UA's. > > What about an SBC that is configured at the edge of a network, for > example the thing that is the target of the URIs placed into ENUM? Yup, these are essentially the same as IP-PBX trunks. I don't know of many= that allow requests in from truly unknown sources, though - they usually k= now the remote devices in advance, even when ENUM is used - so if they want= ed to they could use IPSec or TLS if this became a problem. (some do today,= but many don't - it seems many peer over private connections anyway) > Or > service providers who want to accept calls from "the internet" through > an SBC? These are vulnerable, are they not? Yup, but for those we strongly recommend IPsec, TLS, or even just TCP, wher= e at least syncookies stops the trivial stuff. Essentially what you're pro= posing seems to me similar in concept to syncookies, but at the next layer = up. > are there ever any reasons for an SBC to not send the 401/407 > statelessly, and even send a 100? A 1:2 attack is still bad, albeit a > far cry from the pathological case. Nope there's no reason I know of, but it's rare to do that. Usually it's t= he registrar or some core device which sends the 401/407, so the SBC sends = a 100 to stop the UA from retransmitting. I have tried to convince people = to let the SBC do it, but it hasn't gotten that much interest. (despite the= fact it has more benefits than just this one issue) > Having a single SIP element doing rate limiting doesn't matter though > when there are 7.2 million SIP devices on the net [1]. If each one > will allow a 1:10 amplification, that's all a botnet needs to make it > 10 times more valuable. Hell, even a 1:2 amplification is worth it > for them, especially as it's reflected. Your point is that botnets can take advantage of the SBC's to amplify their= attacks on other UA's, right? But to do that they have to know the URI's/= IP:port's of the other UA's they want to attack indirectly, and at that poi= nt why bother attacking via the SBC - just attack the UA's directly, spoofi= ng other UA's, or spoofing the SBC's, or even not spoofing. I mean it's a = botnet, so you have enough resources to cause a resource exhaustion attack = on any UA's, and who cares if they can trace it? > ... cookies solves this particular attack though, doesn't it? > (although authentication does as well in this scenario due to a > nonce?), in the same way a syncookie does for the SYN flooding > problems of decades gone by. Yup, either cookie or auth would solve it, but my guess is we'd still want = to blacklist if it's more than a short-lived event. That's what happens no= w: you get some leeway for a short while, but eventually you get kicked out= for a longer period of time, because as far as we know you've got a broken= UA or someone's learned your info, and we can't let you affect the overall= network. -hadriel From dworley@nortel.com Sun Feb 22 17:38:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023AF3A6A8C for ; Sun, 22 Feb 2009 17:38:16 -0800 (PST) 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 jg1uwINl9B7T for ; Sun, 22 Feb 2009 17:38:14 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 832563A6B16 for ; Sun, 22 Feb 2009 17:38:14 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1N1cLk10272; Mon, 23 Feb 2009 01:38:21 GMT Received: from [47.141.31.182] ([47.141.31.182]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 20:38:21 -0500 From: "Dale Worley" To: sip-implementors , SIP Content-Type: multipart/mixed; boundary="=-3mF03Pv/jo5xPHQoFfJQ" Organization: Nortel Networks Date: Sun, 22 Feb 2009 20:38:20 -0500 Message-Id: <1235353100.13013.2.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) X-OriginalArrivalTime: 23 Feb 2009 01:38:21.0210 (UTC) FILETIME=[68F12FA0:01C99557] Subject: [Sip] [Fwd: New Version Notification for draft-worley-references-02] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 01:38:16 -0000 --=-3mF03Pv/jo5xPHQoFfJQ Content-Type: text/plain Content-Transfer-Encoding: 7bit --=-3mF03Pv/jo5xPHQoFfJQ Content-Disposition: inline Content-Description: Forwarded message - New Version Notification for draft-worley-references-02 Content-Type: message/rfc822 Received: from zcarhxs0.corp.nortel.com ([47.129.230.87]) by zrtphxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 20:24:43 -0500 Received: from zrtps0kk.us.nortel.com ([47.140.192.53]) by zcarhxs0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 20:24:41 -0500 Received: from ecarhev4.nortel.com (ecarhev4.nortelnetworks.com [47.248.0.46]) by zrtps0kk.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1N1Oef27074 for ; Mon, 23 Feb 2009 01:24:41 GMT Received: from mail.ietf.org (HELO mail.ietf.org) (64.170.98.32) by ecarhev4.nortel.com (qpsmtpd/0.43rc1) with ESMTP; Sun, 22 Feb 2009 20:24:40 -0500 Received: by core3.amsl.com (Postfix, from userid 30) id C36753A67B6; Sun, 22 Feb 2009 17:24:21 -0800 (PST) From: IETF I-D Submission Tool To: dworley@nortel.com Subject: New Version Notification for draft-worley-references-02 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090223012421.C36753A67B6@core3.amsl.com> Date: Sun, 22 Feb 2009 17:24:21 -0800 (PST) X-Spam-Check-By: ecarhev4.nortel.com X-Spam-Status: No, hits=0.0 required=7.0 tests= X-Spam-Level: * X-Virus-Checked: Checked by ClamAV on ecarhev4.nortel.com X-NTM-HELO: mail.ietf.org X-NTM-MAIL-FROM: wwwrun@core3.amsl.com X-NTM-RCPT-TO: X-NTM-PEER-INFO: [64.170.98.32] X-NTM-ID: 1235352280.208530000057@ecarhev4 Return-Path: wwwrun@core3.amsl.com X-OriginalArrivalTime: 23 Feb 2009 01:24:41.0924 (UTC) FILETIME=[809C1040:01C99555] Content-Transfer-Encoding: 7bit A new version of I-D, draft-worley-references-02.txt has been successfuly submitted by Dale Worley and posted to the IETF repository. Filename: draft-worley-references Revision: 02 Title: The References Header for SIP Creation_date: 2009-02-22 WG ID: Independent Submission Number_of_pages: 22 Abstract: This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. The IETF Secretariat. --=-3mF03Pv/jo5xPHQoFfJQ-- From drage@alcatel-lucent.com Sun Feb 22 23:29:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFDD28C0DC for ; Sun, 22 Feb 2009 23:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 OnDxh9JVmaYN for ; Sun, 22 Feb 2009 23:29:54 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 3A8C83A68F7 for ; Sun, 22 Feb 2009 23:29:53 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1N7U6h2003394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Feb 2009 08:30:06 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 23 Feb 2009 08:30:06 +0100 From: "DRAGE, Keith (Keith)" To: Shida Schubert Date: Mon, 23 Feb 2009 08:30:05 +0100 Thread-Topic: [Sip] Comment on sip-ua-privacy-05.txt Thread-Index: AcmSZxyEKbQ1ulqFTQaU6GMquIpnOgDHEZNQ Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A4C580@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <499A7A8A.1030201@voip.co.uk> <28B7C3AA2A7ABA4A841F11217ABE78D674A092EB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "sip@ietf.org" , "draft-ietf-sip-ua-privacy@tools.ietf.org" Subject: Re: [Sip] Comment on sip-ua-privacy-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 07:29:55 -0000 The issue is that while the user may be wanting to use a public GRUU, they = may not wish to announce their IMEI. Normally, no matter what privacy, IMEI= s are kept secret in 3GPP. You'll find procedures in the registration proxy in IMS to therefore obfusc= ate the IMEI when creating a public GRUU. And in 3GPP this was not directly= an invention of the protocol group - part of this came from the 3GPP secur= ity group. regards Keith=20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: Thursday, February 19, 2009 7:53 AM > To: DRAGE, Keith (Keith) > Cc: Michael Procter;=20 > draft-ietf-sip-ua-privacy@tools.ietf.org; sip@ietf.org > Subject: Re: [Sip] Comment on sip-ua-privacy-05.txt >=20 >=20 > Keith; >=20 > I just looked at outbound and gruu again, and AFAICT=20 > temp-gruu doesn't carry the instance-id unlike the pub-gruu=20 > which does. >=20 > With outbound the instance-id is only present in the=20 > REGISTER request when you are establishing the flow, and if=20 > temp-gruu is used, the only time instance-id will be visible=20 > when GRUU is used is also in the REGISTER request. >=20 > I may be blind but I can't seem to see the problem. >=20 > Regards > Shida >=20 > On 18-Feb-09, at 10:53 AM, DRAGE, Keith (Keith) wrote: >=20 > > There is a similar issue with the instance-id as used by=20 > outbound and=20 > > GRUU as well. In a mobile, this uses the IMEI which is not=20 > necessarily=20 > > meant to be revealed. > > > > 3GPP obfuscate the IMEI on generation of the GRUU. > > > > regards > > > > Keith > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]=20 > On Behalf Of=20 > >> Michael Procter > >> Sent: Tuesday, February 17, 2009 8:51 AM > >> To: draft-ietf-sip-ua-privacy@tools.ietf.org; sip@ietf.org > >> Subject: [Sip] Comment on sip-ua-privacy-05.txt > >> > >> Just a minor point: Is it worth adding (either in section > >> 4.1 or 6) that a temp-gruu might not be as anonymous as you might=20 > >> hope? An observer using RFC 3680 (reg-event) with gruu extensions=20 > >> would be able to correlate temp-gruus with AoRs and=20 > contacts, should=20 > >> they be so authorised. > >> > >> There is some text in RFC 3680 warning of the risks of=20 > reg-event, but=20 > >> that is probably of more direct interest to registrar authors. A=20 > >> reminder of the risk in this document might highlight it for UA=20 > >> authors, so that they can consider the wider implications. > >> > >> Best regards, > >> > >> Michael > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 > = From theo@crazygreek.co.uk Mon Feb 23 02:49:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAC23A69DB for ; Mon, 23 Feb 2009 02:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTKGjIQUeOZr for ; Mon, 23 Feb 2009 02:48:59 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with SMTP id C46943A69CB for ; Mon, 23 Feb 2009 02:48:58 -0800 (PST) Received: from source ([72.14.220.158]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSaJ/KzY4Tq5bT9FcUYZqLcAnFGizfz1n@postini.com; Mon, 23 Feb 2009 02:49:17 PST Received: by fg-out-1718.google.com with SMTP id 13so1976276fge.44 for ; Mon, 23 Feb 2009 02:49:14 -0800 (PST) MIME-Version: 1.0 Sender: theo@crazygreek.co.uk Received: by 10.86.29.8 with SMTP id c8mr2807382fgc.19.1235386154395; Mon, 23 Feb 2009 02:49:14 -0800 (PST) In-Reply-To: References: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> <167dfb9b0902221232m604d7969u7a880378d50fa6d7@mail.gmail.com> Date: Mon, 23 Feb 2009 10:49:14 +0000 X-Google-Sender-Auth: de70dc4409abb94c Message-ID: <167dfb9b0902230249u14daa4f6r54fd904f8fe2826f@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIP WG Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:49:00 -0000 On Sun, Feb 22, 2009 at 11:55 PM, Hadriel Kaplan w= rote: > Yup, these are essentially the same as IP-PBX trunks. =A0I don't know of = many that allow requests in from truly unknown sources, though - they usual= ly know the remote devices in advance, even when ENUM is used - so if they = wanted to they could use IPSec or TLS if this became a problem. (some do to= day, but many don't - it seems many peer over private connections anyway) I believe (hope!) that these are going to get more common! ... the driving reason behind me doing this was running through security issues for deployment of public gateways for the 4.4.e164.arpa go-live date on March 11th (at *last*). While i'd love the world to change to TCP/TLS overnight, i just don't see it happening ... just "cause UDP can be used for attacking 3rd parties" Even if SBCs may not be commonly deployed in that way, there are certainly millions of SIP devices that are. Think all the asterisk machines hosted on public IPs, for example. > Essentially what you're proposing seems to me similar in concept to synco= okies, but at the next layer up. yeah, it is - in fact probably why i subconsciously called them via cookies= :-) > Your point is that botnets can take advantage of the SBC's to amplify the= ir attacks on other UA's, right? No! Attacking UAs isn't really that much of a worry (as 401/407 can "fix" that, especially as UDP scales so well). It's that you can use SBCs to amplify attacks on anything you like. Botnets can take advantages of SIP elements to attack anything not just UAs. "anything" could be a DNS server, mail server, web server, or anything with routable IP just due to sheer number of PPS and throughput saturating links. > I mean it's a botnet, so you have enough resources to cause a resource ex= haustion attack on any UA's, and who cares if they can trace it? Because it's another layer of indirection as well as amplification. Indirection makes traceability harder, which means longer before machines initiating attacks get discovered. Amplification means networks hosting the zombies are less likely to notice initially. so it's a double fail for us :-) > Yup, either cookie or auth would solve it, but my guess is we'd still wan= t to blacklist if it's more than a short-lived event. =A0That's what happen= s now: you get some leeway for a short while, but eventually you get kicked= out for a longer period of time, because as far as we know you've got a br= oken UA or someone's learned your info, and we can't let you affect the ove= rall network. Lets say i have a 2mbit link at home. Given the 1:350 example, I could theoretically generate a 700mbit attack against anything i wanted. In the case of a botnet, they can use 4000 machines sending out a single 500 byte INVITE every second, which would result in the same thing. ~ Theo From eric.wangxr@gmail.com Mon Feb 23 07:18:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA223A6822 for ; Mon, 23 Feb 2009 07:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_83=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 nofRNxBktUzd for ; Mon, 23 Feb 2009 07:17:59 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id EB9873A6864 for ; Mon, 23 Feb 2009 07:16:29 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1848593rvb.49 for ; Mon, 23 Feb 2009 07:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=nUwbR+L2l8d91xjIJP1Y6v4WEELI1LgMN5fMStihL4U=; b=GRo/IU0HxB7ZmSgaVVLX79IZaDp+5CuLUha3WIme1XtQfKB+Dut03A+nLML+3I2lLS EozxfdiFmYWKm63D/wyFt1H43qt412UMIubTSMnf+ijUWzo27SvRcOI+E+FMhBPwtgNv FnWcsCf0+Vsq8CXiSq0NZYlcldWMYUWDwiLns= 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=xsRRXuPXBEVbXw+nHtv623vYrs80b8h/aqaahjFhNT2IcWLtcu5C9Wgkk34DwOvbgb SqTzRhkQvLd5v4170egD7iVXRigAy1UA0ClPSzCiGESyFqA6Hx0394enTCG8+MB5AiV7 WYZXKq2fleMMxnHJC2nyJc/maZMxmFFBFPV3o= MIME-Version: 1.0 Received: by 10.140.201.8 with SMTP id y8mr2081726rvf.126.1235402206895; Mon, 23 Feb 2009 07:16:46 -0800 (PST) Date: Mon, 23 Feb 2009 23:16:46 +0800 Message-ID: <898632750902230716i21e6206as383b4ddd2a0b1cf0@mail.gmail.com> From: Eric wang To: christer.holmberg@ericsson.com Content-Type: multipart/alternative; boundary=000e0cd2bd52b2610b0463977d94 Cc: sip@ietf.org Subject: [Sip] Questions about "draft-ietf-sip-199-05" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:18:01 -0000 --000e0cd2bd52b2610b0463977d94 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Christer, Glad to see that the draft starts its WGLC process.It's really useful. I still have some difficult in using IETF and cannot find the whole sorted comments about this draft, so i have some doubt about this draft. 1. "If a forking proxy receives a reliably sent 199 response for a dialog, for which the proxy has previously generated and sent a 199 response, the proxy MUST forward the 199 response." Does it describe the case below? Although P1 have sent a 199 response, P1 havs to forword the send reliably 199 too.Or is the first 199 mistaked for 18x? UAC P1 UAS_2 --- INVITE ------> --- INVITE (leg 2) -> <-- 199(leg 2) -- <-- 199 (leg 2) ----- <-- 199(leg 2) -- 2. "10. Usage with 100rel When a 199 Early Dialog Terminated provisional response is sent by a UAS, since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably even if the 100rel option tag [RFC3262] is present in the Require header of the associated request." I have seen a comment on this question,but still not understood about it . If the INVITE has a Require tag "Require: 100rel",does the UAS still use unreliable 199 response? If 199 is reliable, there is one more advantage. If the 199 arrives before the first 18x response, UAC can discard the first 199 and process it until UAC receives the first 18x response that has the same to-tag as 199, as the reliable 199 should be re-transmited until received PRACK. ps: Can anyone show me how to sort all comments of a topic by time? Regards, Eric.wang --000e0cd2bd52b2610b0463977d94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer,
    Glad to see that the draft starts its WGLC pro= cess.It's really useful.
 
    I still have some difficult in using IETF and canno= t find the whole sorted comments about this draft, so i have some doubt abo= ut this draft.
 
   1.   "If a fo= rking proxy receives a reliably sent 199 response for a

   = dialog, for which the proxy has previously generated and sent a 199<= /font>

   = response, the proxy MUST forward the 199 response."

<= /div>
     Does it describe the case below? Al= though P1 have sent a 199 response, P1 havs to  forword the send relia= bly 199 too.Or  is the  first 199 mistaked for 18x?
 
          UAC   = ;            P1 = ;            &n= bsp;    UAS_2   
       --- INVITE ------>
 &n= bsp;            = ;           --- INVITE (l= eg 2) ->
       <-- 199(leg 2) --
          =             &nb= sp;  <-- 199 (leg 2) -----
       = <-- 199(leg 2) --
 
   &nbs= p; 2.  "10.  Usage with 100rel=20

   <= span style=3D"COLOR: #993300">When a 199 Early Dial= og Terminated provisional response is sent by a

   = UAS, since the provisional response is only used for information

   = purpose, the UAS SHOULD send it unreliably even if the 100rel option=

   = tag [RFC3262] is present in the Require header of the associated

   = request."

  =

   I have seen a comment on this question,but st= ill not understood about it .

   If the INVITE has a Require tag "Require: 10= 0rel",does the UAS still use

   unreliable 199 response?

 

   If 199 is reliable, there is one more advantage. = If the 199 arrives before

   the first 18x response, UAC can discard the first= 199 and process it until

   UAC receives the first 18x response that has the = same to-tag as 199, as

   the reliable 199 should be re-transmite= d until  received PRACK.

  

  

 

   ps:

 

   Can anyone show me how to sort all comments = of a topic by time?

 

  

   Regards,

 

   Eric.wang

 

  =  

 

 

--000e0cd2bd52b2610b0463977d94-- From dean.willis@softarmor.com Mon Feb 23 07:43:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137113A6837 for ; Mon, 23 Feb 2009 07:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 0iK7DHJmOHgb for ; Mon, 23 Feb 2009 07:43:13 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0956D3A67CC for ; Mon, 23 Feb 2009 07:43:12 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n1NFhPOR015784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Feb 2009 09:43:28 -0600 Message-Id: <0CDC410E-1413-4D27-99CC-C872036415A6@softarmor.com> From: Dean Willis To: "DRAGE, Keith (Keith)" In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A4C580@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 09:43:19 -0600 References: <499A7A8A.1030201@voip.co.uk> <28B7C3AA2A7ABA4A841F11217ABE78D674A092EB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A4C580@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.930.3) Cc: "sip@ietf.org" , "draft-ietf-sip-ua-privacy@tools.ietf.org" Subject: Re: [Sip] Comment on sip-ua-privacy-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:43:14 -0000 On Feb 23, 2009, at 1:30 AM, DRAGE, Keith (Keith) wrote: > The issue is that while the user may be wanting to use a public > GRUU, they may not wish to announce their IMEI. Normally, no matter > what privacy, IMEIs are kept secret in 3GPP. > So it's rather like the distinction between appearing in public, and appearing naked in public ? One is acceptable for most, the other only for certain celebrities, or on just the right kind of beach . . . -- Dean From dean.willis@softarmor.com Mon Feb 23 08:16:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619A43A6A26 for ; Mon, 23 Feb 2009 08:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, 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 4RYWaSDO0E9E for ; Mon, 23 Feb 2009 08:16:57 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8526F3A6802 for ; Mon, 23 Feb 2009 08:16:57 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n1NGHBCX016003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 23 Feb 2009 10:17:15 -0600 Message-Id: <61918217-4476-4BFF-85BF-F07E6A1450C7@softarmor.com> From: Dean Willis To: "sip@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 10:17:06 -0600 X-Mailer: Apple Mail (2.930.3) Subject: [Sip] Usable version of xml2rfc posted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:16:58 -0000 The debate around RFC 5378 has resulted in a delay on getting a version of xml2rfc out that will produce text suitable for submission. Cullen has apparently hacked a workaround, and we expect a "production" version in a few days. Please get those drafts revised and submitted. Cullen says: > The XML2RFC folks are busy producing a good version of xml2rfc that > deals with the new license statements. However in the meantime I > have a hacked up version that does seem to work at least some of the > time. > > You can find it at > http://svn.resiprocate.org/rep/ietf-drafts/xml2rfc/1.34pre2-fluffy/xml2rfc.tcl > > Hopefully this will soon be obsoleted when the real xml2rfc tool > gets updated. > > If you are trying to do a draft that has pre 5378 text in it, you > can set the ipr attribute in the element to > ipr="pre5378Trust200902" and it will produce a txt file that id > submission tool will accept. > > Example xml at http://www.ietf.org/internet-drafts/draft-jennings-http-srv-01.xml > and resulting txt file at > http://www.ietf.org/internet-drafts/draft-jennings-http-srv-01.txt > From dean.willis@softarmor.com Mon Feb 23 08:32:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FEF3A6A6E for ; Mon, 23 Feb 2009 08:32:58 -0800 (PST) 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 87GLZL3XlzGv for ; Mon, 23 Feb 2009 08:32:57 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 041B53A6802 for ; Mon, 23 Feb 2009 08:32:56 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n1NGXD9a016130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 23 Feb 2009 10:33:14 -0600 Message-Id: <571C036B-1243-4271-B827-D8F6D57BABCC@softarmor.com> From: Dean Willis To: "sip@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 10:33:07 -0600 X-Mailer: Apple Mail (2.930.3) Subject: [Sip] SSLstrip: Implications for SIPS and our imaginary padlock icon? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:32:58 -0000 I've often railed about how using "sips:" doesn't really prove anything to the user, since the connection is not end-to-end and downstream elements might be lying about what they are doing. Apparently a similar attack is possible on https, when augmented with a (very) little social engineering. I'm pretty sure this trick would fool me occasionally, and my mother wouldn't stand a chance. See: http://www.forbes.com/2009/02/18/black-hat-hackers-technology-security_0218_blackhat.html A poignant quote: > The fundamental lesson of his encryption-stripping attack, says > Marlinspike, is that the protections on the Web's "secure" pages are > really just as weak as any page that can impersonate that security. > "The real answer is to encrypt everything," Marlinspike says. "When > you have a secure protocol that depends on an insecure protocol, > that's a problem." So, what are the implications for the SIP world? -- Dean From theo@crazygreek.co.uk Mon Feb 23 09:44:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FB73A67DD for ; Mon, 23 Feb 2009 09:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QbgnzU4+7buQ for ; Mon, 23 Feb 2009 09:44:51 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id 65F7F3A6B00 for ; Mon, 23 Feb 2009 09:44:50 -0800 (PST) Received: from source ([209.85.218.180]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSaLgnxgxRqbzrK4KSpl1hOg9rmhNFkXv@postini.com; Mon, 23 Feb 2009 09:45:09 PST Received: by bwz28 with SMTP id 28so5427657bwz.14 for ; Mon, 23 Feb 2009 09:45:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.181.60.14 with SMTP id n14mr1602673bkk.79.1235411101818; Mon, 23 Feb 2009 09:45:01 -0800 (PST) In-Reply-To: <571C036B-1243-4271-B827-D8F6D57BABCC@softarmor.com> References: <571C036B-1243-4271-B827-D8F6D57BABCC@softarmor.com> Date: Mon, 23 Feb 2009 17:45:01 +0000 Message-ID: <167dfb9b0902230945n1d4cac9bya975d62c242751c1@mail.gmail.com> From: Theo Zourzouvillys To: Dean Willis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org WG" Subject: Re: [Sip] SSLstrip: Implications for SIPS and our imaginary padlock icon? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:44:52 -0000 On Mon, Feb 23, 2009 at 4:33 PM, Dean Willis wrote: > So, what are the implications for the SIP world? Well, for starters vendors need to make sure any UI that represents "this call is secure" display can't be subject to the favicon.ico trick some browsers have. think: Call-Info: ;purpose=icon SIP UIs also need to ensure that they can't fall for other display-name tricks, i.e: From: "HSBC Bank" ;tag=xxx (it would appear the phone on my desk will indeed fall for something like this) The SSLstrip attack relies on a MITM being able to modify a HTTP response *before* getting to the HTTPS page (i.e, rewriting the links a user would normally click, such as "My Account"). A parallel to this attack in SIP is if a SIPS URI is first learnt through a non TLS requests, which upgrades to TLS and uses a UI hack like the one above, or even redirect to a sips URI hosted on the attackers server (resulting in a padlock, all be it the wrong one), which then forwarded the call to le bank. again, this is partially a UI design issue, and we need to ensure that UAC vendors display who the certificate has been issued to [1] as well at the identty of the remote endpoint. Luckily for us, the same sort of attack will be far harder in SIP once DNSSEC is in place (if it ever is :)) in the end to end model, as we use NAPTR for indicating the transport, this there is no risk of rewriting the response, as it will come through TLS even when non sips call in a "secured" domain; HTTPS doesn't have this. a User typing in "mymanager@hsbc.co.uk" will - at least in the end to end model - result in a NAPTR RRset for hsbc.co.uk's SRV records and only TLS transports (assuming a bank was sensible and only has TLS transports), which results in another (secured by DNSSEC) SRV lookup lookup for their proxies, which then is sent via TLS to them. The worry comes when a user types "sip:mymanager@hsbc.co.uk" which goes over TCP/UDP (non TLS) to a service provider, which then could return a 302 to sips:mymanager@hsbc.co.uk, as then we fall into the same trap as the SSLstrip MITM attack. In other words, a SIP call initiated over a non TLS transport can never be "upgraded" (via, for example, a 3xx) to TLS without being subject to this (albeit lack of user-awareness/UI design) attack. ~ Theo 1 - Although this has some issues too, obviously. -- Theo Zourzouvillys Chief Technical Officer VoIP.co.uk Sent from: Bicester Oxfordshire United Kingdom. From dworley@nortel.com Mon Feb 23 13:17:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E888B3A68A6 for ; Mon, 23 Feb 2009 13:17:29 -0800 (PST) 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=[AWL=0.000, 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 18gH6tOouIou for ; Mon, 23 Feb 2009 13:17:29 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D3F5C3A6833 for ; Mon, 23 Feb 2009 13:17:28 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1NLHgE24686; Mon, 23 Feb 2009 21:17:43 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 16:17:41 -0500 From: "Dale Worley" To: Theo Zourzouvillys In-Reply-To: <167dfb9b0902230249u14daa4f6r54fd904f8fe2826f@mail.gmail.com> References: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> <167dfb9b0902221232m604d7969u7a880378d50fa6d7@mail.gmail.com> <167dfb9b0902230249u14daa4f6r54fd904f8fe2826f@mail.gmail.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 23 Feb 2009 16:17:41 -0500 Message-Id: <1235423861.6505.53.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2009 21:17:41.0525 (UTC) FILETIME=[29606450:01C995FC] Cc: SIP WG Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:17:30 -0000 On Mon, 2009-02-23 at 10:49 +0000, Theo Zourzouvillys wrote: > On Sun, Feb 22, 2009 at 11:55 PM, Hadriel Kaplan wrote: > > > Yup, these are essentially the same as IP-PBX trunks. I don't know > of many that allow requests in from truly unknown sources, though - > they usually know the remote devices in advance, even when ENUM is > used - so if they wanted to they could use IPSec or TLS if this became > a problem. (some do today, but many don't - it seems many peer over > private connections anyway) > > I believe (hope!) that these are going to get more common! Yes, Hadriel, you're thinking in a rather PSTN way. Suppose I change a few words in your sentence: "I don't know of many Web servers that allow requests in from truly unknown sources." In the Pingtel days, our gateway SBC would accept SIP calls from anywhere across the great Internet. Our current IT administration is a bit more backward. But we'll convince them eventually! Dale From dworley@nortel.com Mon Feb 23 13:18:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7CEA3A6A72 for ; Mon, 23 Feb 2009 13:18:51 -0800 (PST) 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=[AWL=0.000, 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 uWbm7mCuPAWf for ; Mon, 23 Feb 2009 13:18:50 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A498C28C0D6 for ; Mon, 23 Feb 2009 13:18:50 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1NLJ6E25066; Mon, 23 Feb 2009 21:19:06 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 16:19:06 -0500 From: "Dale Worley" To: Theo Zourzouvillys In-Reply-To: <167dfb9b0902201534p43093516ybf436edb1b017afb@mail.gmail.com> References: <167dfb9b0902192020v4925c9a0r3c6c8089c73008b7@mail.gmail.com> <1235168643.3712.65.camel@victoria-pingtel-com.us.nortel.com> <167dfb9b0902201534p43093516ybf436edb1b017afb@mail.gmail.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 23 Feb 2009 16:19:06 -0500 Message-Id: <1235423946.6505.55.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2009 21:19:06.0621 (UTC) FILETIME=[5C1902D0:01C995FC] Cc: SIP WG Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:18:51 -0000 On Fri, 2009-02-20 at 23:34 +0000, Theo Zourzouvillys wrote: > > More importantly, such a value-less parameter does nothing > > useful: If the client will accept requests without cookies, a request > > without the parameter will be accepted. If the client will not accept > > requests without cookies, a request without the parameter will elicit a > > 4XX response, which can be used to resend the request. > > A server could behave differently when it receives a request without a > cookie in it, for example require authentication, redirect the user > statelessly to another transport, or something we've not thought of > just yet :-) "A server may choose to apply additional security mechanisms to a request without a cookie parameter." > It's also useful for diagnostic purposes for deployment: how will we > know when adoption is so widespread it would be safe to require > support for it for a request to proceed? Good point. It would help if you added these points to the draft. Dale From dworley@nortel.com Mon Feb 23 13:37:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6FE28C15A for ; Mon, 23 Feb 2009 13:37:17 -0800 (PST) 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=[AWL=0.000, 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 UWBIDTHHJb6Y for ; Mon, 23 Feb 2009 13:37:16 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4FEE83A67E6 for ; Mon, 23 Feb 2009 13:37:16 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1NLbWE29086 for ; Mon, 23 Feb 2009 21:37:32 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 16:37:29 -0500 From: "Dale Worley" To: SIP Content-Type: text/plain Organization: Nortel Networks Date: Mon, 23 Feb 2009 16:37:28 -0500 Message-Id: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2009 21:37:29.0384 (UTC) FILETIME=[ED654A80:01C995FE] Subject: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:37:17 -0000 I've been considering the following idea for a diagnostic tool, and I'd like to get some feedback on it. The goal is to be able to trace the progress of a SIP request through the network, including seeing the forking structure. We first need to pick a provisional response codes. It appears that "170" is not currently used. This response code is also used as an option-tag for this feature. The processing is that whenever a SIP element receives a request that contains "Supported: 170", the element will immediately (in addition to anything else that it would do with the request) send a 170 response upstream, containing the request as its body (media type message/sipfrag). Dale From john.elwell@siemens.com Mon Feb 23 14:08:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D06C28C228 for ; Mon, 23 Feb 2009 14:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 eBvheNWIIwaU for ; Mon, 23 Feb 2009 14:08:18 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3AE6828C198 for ; Mon, 23 Feb 2009 14:08:18 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KFJ00E56HI8KV@siemenscomms.co.uk> for sip@ietf.org; Mon, 23 Feb 2009 22:08:32 +0000 (GMT) Date: Mon, 23 Feb 2009 22:08:29 +0000 From: "Elwell, John" In-reply-to: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> To: Dale Worley , SIP Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00191A2C2@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Diagnostic idea Thread-Index: AcmV/vZbOff7HjkkR2Wg5xGgWDKkzwAAyFXQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:08:19 -0000 Dale, History-Info can provide some information, depending of course whether all proxies forward it and add to it as it goes downstream, that the UAS sends it back, and that all proxies forward it upstream in the response. It doesn't give you all the information you would get from your idea, of course. Both mechanisms would suffer from border elements that strip things out for topology hiding or other reasons. On the detail, I believe 170 would establish an early dialog - is this desirable, and if not is it avoidable?=20 John=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Dale Worley > Sent: 23 February 2009 21:37 > To: SIP > Subject: [Sip] Diagnostic idea >=20 > I've been considering the following idea for a diagnostic=20 > tool, and I'd > like to get some feedback on it. >=20 > The goal is to be able to trace the progress of a SIP request through > the network, including seeing the forking structure. We first need to > pick a provisional response codes. It appears that "170" is not > currently used. This response code is also used as an option-tag for > this feature. The processing is that whenever a SIP element=20 > receives a > request that contains "Supported: 170", the element will=20 > immediately (in > addition to anything else that it would do with the request)=20 > send a 170 > response upstream, containing the request as its body (media type > message/sipfrag). >=20 > Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From HKaplan@acmepacket.com Mon Feb 23 15:35:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FCF3A6A88 for ; Mon, 23 Feb 2009 15:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Qk3cKtaV5U8V for ; Mon, 23 Feb 2009 15:35:34 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 02F5E3A68FE for ; Mon, 23 Feb 2009 15:35:33 -0800 (PST) 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.291.1; Mon, 23 Feb 2009 18:34:28 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 23 Feb 2009 18:34:28 -0500 From: Hadriel Kaplan To: Dale Worley , Theo Zourzouvillys Date: Mon, 23 Feb 2009 18:34:26 -0500 Thread-Topic: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) Thread-Index: AcmV/AjH9ujHk51gSdWF4sLZjJ3ZEwADIO0Q Message-ID: References: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> <167dfb9b0902221232m604d7969u7a880378d50fa6d7@mail.gmail.com> <167dfb9b0902230249u14daa4f6r54fd904f8fe2826f@mail.gmail.com> <1235423861.6505.53.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1235423861.6505.53.camel@victoria-pingtel-com.us.nortel.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: SIP WG Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 23:35:34 -0000 > -----Original Message----- > From: Dale Worley [mailto:dworley@nortel.com] > Sent: Monday, February 23, 2009 4:18 PM > > On Mon, 2009-02-23 at 10:49 +0000, Theo Zourzouvillys wrote: > > On Sun, Feb 22, 2009 at 11:55 PM, Hadriel Kaplan > wrote: > > > > > Yup, these are essentially the same as IP-PBX trunks. I don't know > > of many that allow requests in from truly unknown sources, though - > > they usually know the remote devices in advance, even when ENUM is > > used - so if they wanted to they could use IPSec or TLS if this became > > a problem. (some do today, but many don't - it seems many peer over > > private connections anyway) > > > > I believe (hope!) that these are going to get more common! > > Yes, Hadriel, you're thinking in a rather PSTN way. No I'm not. I'm merely indicating what I believe the common scenarios are = as I see them today. It has no relation to how my neurons interact. -hadriel From lakshmi@multitech.co.in Mon Feb 23 20:52:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5213A6982 for ; Mon, 23 Feb 2009 20:52:23 -0800 (PST) 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 JRl3rSb4A7Gv for ; Mon, 23 Feb 2009 20:52:22 -0800 (PST) Received: from multitech.co.in (mtssgway1.multitech.co.in [125.63.78.4]) by core3.amsl.com (Postfix) with ESMTP id 3F0B03A6960 for ; Mon, 23 Feb 2009 20:52:21 -0800 (PST) Received: from [192.168.53.142] ([192.168.53.142])(authenticated)by multitech.co.in with ESMTP id n1O4nXWT011432for ; Tue, 24 Feb 2009 10:19:33 +0530 Message-ID: <49A37E40.6030408@multitech.co.in> Date: Tue, 24 Feb 2009 10:27:36 +0530 From: lakshmi User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Synonym: Copied by Synonym (http://www.modulo.ro/synonym) to: archive Subject: [Sip] Handling MESSAGE with in dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 04:52:23 -0000 Hi, We are enhancing SIP stack with MESSAGE method. According to the MESSAGE method spec 3428, handling MESSAGE receive/send outside the dialog is clear. But 3428 is not clear in handling MESSAGE within the session. We are not clear about the constraints like on which states MESSAGE events like receive/send MESSAGE must be allowed. Kindly clarify how to handle MESSAGE with in session/dialog. Regards, -Lakshmi From drage@alcatel-lucent.com Tue Feb 24 02:56:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE8B3A6A90 for ; Tue, 24 Feb 2009 02:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_45=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 ZZq17e+vhJEU for ; Tue, 24 Feb 2009 02:56:26 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 021AC3A69AC for ; Tue, 24 Feb 2009 02:56:25 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1OAuevV020971 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 24 Feb 2009 11:56:43 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 24 Feb 2009 11:56:40 +0100 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Tue, 24 Feb 2009 11:56:38 +0100 Thread-Topic: Notes of identity conference call held 17th Feb 2009 Thread-Index: AcmWbpFaMkmuXi42R7ahNyzhqn8fYQ== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A4CA5D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [Sip] Notes of identity conference call held 17th Feb 2009 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 10:56:28 -0000 Attached find the notes of the last conference call of the interested parti= es on progressing the identity issues in SIP, held on 17th Feb 2009. Expect= a revised version of draft-ietf-sip-e2e-identity-important shortly. If anyone is interested in joining these discussions, send me a mail and I = will include you in the details for the next call - we currently expect one= more before the IETF meeting. regards Keith ---------------------------------------------------------------------------= --- Present: Keith Drage Hannes Tschofenig Dan Wing John Elwell Dan York >From the previous meeting notes: > Ihe call came up with some areas where the document should be revised=20 > and John would attempt to capture those suggestions in a revised=20 > version of the document. Target date for new version of the document=20 > was 10th February so it could be discussed on our next call on 17th=20 > February. John made a plea for input to the draft in the form of words=20 > targetted at the draft. So far John had not issued the revised version (draft-ietf-sip-e2e-identity= -important) as he had not yet had sufficient input for the revised version.= A reminder on the mail list shortly before the call had produced some idea= s. John presented the changes he had made so far to the draft, which had not y= et been circulated. John had added a table at the end of the use cases part of the document as = requested in the last call. The conclusion had also been split into a concl= usion for email style identities and one for E164 style identities, also as= requested in the last call. A statement would also be added that end-to-en= d identity is not achievable where the PSTN is involved. John commented that he had received comments from David Schartz relating to= better trying to assign permitted operations on URIs to definitions of "co= nvert", "translate" and "normalise". "translate" was understood to include = adding a country code or conversion to alias. "normalise" was understood to= include e.g. addition or deletion of whitespace. There was a requirement from the previous call to go into a greater detail = of what could or could not be changed (posted 17 Feb 2009). This level of d= etail was thought to be what Jon Peterson had been requesting. The remainde= r of the call was spent reviewing the list that John had already posted to = the participants. Hadrial had responded to this mail and his comments from = this mail and prior mails were included in that review. It was noted that H= adriel had not yet conducted a full review of this text, merely suggested t= hat some previous mails also addressed these issues. It was agreed that the focus was on fields signed by RFC 4474. This combined text is reproduced below (with interpolated discussion from t= he conference call): > From last week's call, there was an action on all of us: > "There was agreement that we should analyse in more detail specific=20 > header fields and body types, and the impact of SBCs on the identity=20 > characteristics of those elements. This will need to go into detail on=20 > the contents, for example, rather than a blanket change of a URI to a=20 > different URI, what is the impact of changing a URI to say an alias of=20 > that URI, or adding a "+" where one currently does not exist. Hadriel=20 > generally called these changes "protocol repair"." >=20 > In the absence of any other contributions, I will try to kick this=20 > off. I don't known whether this was the sort of thing expected. >=20 > Only those fields signed by RFC 4474 are considered. >=20 > addr-spec of From header field: > - Changing the host part means that the recipient loses information=20 > about the domain the request originated in. > - Changing a non-E.164-based user-info part, or changing an=20 > E.164-based user-info part in ways not covered below, means that the=20 > recipient loses information about the particular user within the=20 > domain. > - Changing digits within an E.164-based user part so to give a=20 > different generally accepted form of an E.164 number does not in=20 > principle remove the identification properties of From, although it=20 > could cause difficulties with URI matching at the destination. In=20 > generally, changing to a fully qualified, canonical form is less=20 > problematic than other changes (e.g., adding a "+" to an international=20 > number, removing dial string digits such as "00", adding country code. > - Adding or removing user=3Dphone. In theory shouldn't be done, but in=20 > practice it normally does not remove the identification properties of=20 > From, since a the same user-part with/without user=3Dphone generally=20 > does identify different users. There is a need to cover the cases of changes from E164 based to email styl= e addresses and vice versa. It was suggested that we could benefit here from David Schwartz's comments = on categorising changes.=20 *** Does this constitute the same terminology from Jonathan's RAI area docu= ment on numbering. It was also suggested that we should avoid the document getting into a disc= ussion of when is an E.164 number not an E.164 number.=20 > - Adding or removing other URI parameters. TODO. >=20 SIP URI parameters have different characteristics to tel URI parameters in = a number of ways and may need to be treated separately. > addr-spec of To header field: > - Not needed for identifying caller > - For identifying original callee, considerations are similar to those=20 > for From > - In particular, a change of To when a call is forwarded would destroy=20 > the identification properties of To. >=20 Changing the To header field will break the RFC 4474 signature. It was poin= ted out that independent of this, we should not be changing the To header f= ield anyway, as doing so breaks the purpose of the To header field as defin= ed in RFC 3261. > call-id of Call-Id header field: > - This does not impact the identity characteristics of a request. >=20 > digit of CSeq header field: > - This does not impact the identity characteristics of a request. [JRE] Although Call-Id and CSeq were apparently included in the signature f= or replay protection purposes, it is not clear that this would work. There = are cases related to forking, redirection and retransmission over UDP trans= port where the verifier could legitimately receive repeated requests with t= he same Call-Id and CSeq values, perhaps with different values in the Reque= st-URI. >=20 > method of CSeq header field: > - This does not impact the identity characteristics of a request. It=20 > seems very unlikely that an SBC would modify this field. >=20 > Date header field: > - This does not impact the identity characteristics of a request,=20 > although it is essential to provisions for preventing replay attacks. >=20 > addr-spec of Contact header field: > - Substitution of the SBC's own contact URI does not impact the=20 > identity characteristics of a request. [JRE] A man-in-the-middle can pervert the routing of subsequent mid-dialog = requests by manipulating Record-Route rather than Contact, so signing the C= ontact header field has limited value in this respect. It may have some val= ue for subsequent out-of-dialog requests (e.g., where the Contact URI is us= ed in the Request-URI of a REFER request. In such cases, any B2BUA that mod= ifies the Contact URI would need an algorithmic or stateful means of perfor= ming reverse modification even after the original dialog has terminated. It= is not clear whether this works in practice. Note that one reason for changing the contact URI is to replace IP addresse= s, the use of which is bad practice anyway. > - Changes to the original contact URI without substitution of the=20 > SBC's own contact URI is likely to be harmful for other reasons. >=20 Some discussion is required of Contact header field parameters, e.g. the GR= UU Contact header field parameter is the real identity for getting back to = the user. > Body parts other than SDP: > - This does not impact the identity characteristics of a request,=20 > although it certainly has other implications. > Unclear whether this happens in practice. >=20 > SDP: > - Reformatting (e.g., addition or removal of whitespace).=20 > This does not impact the identity characteristics of a request. > - IP address in c-line / port in m-line. This impacts the identity=20 > characteristics of a request to the extent that it no longer=20 > identifies binds the sink of media to the user identified in From. > However, SRTP with an appropriate key management system should achieve=20 > that and a lot more. The RTP case is insecure anyway. > - a=3Dfingerprint line. This prevents the binding of SRTP to signalling=20 > and the user identified by the From URI. > - removal of m-lines and their attributes. This does not impact the=20 > identity characteristics of a request It os imderstood that the RTP case is insecure anyway. It was commented tha= t Jon Peterson does not want the identity to be dependent on SRTP. Dan Wing= commented that even if SRTP is not secure, then identity is still useful e= ven with RTP. We are frequently interested in who is calling and not necess= sarily worried that some third party may have inserted an advert in the med= ia stream. > - Changing m-line transport, e.g., from SAVP to AVP. This does not=20 > impact the identity characteristics of a request, but constitutes a=20 > bid-down attack. > - Removal of a=3Dtcap, a=3Dpcfg lines. Again this could constitute a=20 > bid-down attack. >=20 > There are lots more things in SDP that could be changed. I won't go=20 > into that now. I first need some feedback on whether this is going in=20 > the right direction, and also advice on what in practice is likely to=20 > be changed for good reason at SBCs. >=20 The document should cover the change of IP address.=20 There was also discussion of the of the change from AVPF to AVP, and the po= tential impact of the use of capability negotiation to enable this. Suggest= ed that feedback should be at the same level as the AVP. Changing SDP is not necessarily bad or harmful. It was understood that the = area directors wanted to sign the SDP because IETF does not necesssarily un= derstand what might be used in the future in the SDP. Therefore we sign the= SDP except all those things we allow to change. > Although many of the fields can be changed without impacting the=20 > identity characteristics of a request, the reason they are signed in=20 > RFC 4474 is to do with providing a measure of integrity protection on=20 > important parts of the message that are not expected to change. The=20 > more of these we remove from the signature, the less integrity=20 > protection we have (and in some case less playback protection). So we=20 > need some sort of balance between allowing reasonable changes by SBCs=20 > while still giving a reasonable measure of integrity and playback=20 > protection. We also have to take into account that some requests do=20 > not relate to media and do not contain SDP (e.g., MESSAGE, SUBSCRIBE,=20 > NOTIFY), and therefore reducing the amount of signed information will=20 > impact the integrity and playback protection of these requests more=20 > than requests such as INVITE. There was a discussion of other information that also should be discussed. = The following were suggested: - Geolocation and any associated PIDF LO body. - SAML assertion. Both would be signed by the XML signature. The document being produced needs to make sure we clearly identify what we = discussed and excluded from the discussion. There is a need to justify what= is left is the complete list that merits discussion, and that nothing has = therefore been missed. This was the last of the currently scheduled calls. It was agreed to have a= further call on Tuesday 3rd March 2009 at 7:00 a.m. Pacific time. ---------------------------------------------------------------------------= --- regards Keith= From ekr@networkresonance.com Tue Feb 24 08:00:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABFF3A6B00 for ; Tue, 24 Feb 2009 08:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 82ptl0CbSN-A for ; Tue, 24 Feb 2009 08:00:26 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id A13DF3A6A8D for ; Tue, 24 Feb 2009 08:00:26 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id AA6CB50822; Tue, 24 Feb 2009 08:23:30 -0800 (PST) Date: Tue, 24 Feb 2009 08:23:30 -0800 From: Eric Rescorla To: Dean Willis In-Reply-To: <571C036B-1243-4271-B827-D8F6D57BABCC@softarmor.com> References: <571C036B-1243-4271-B827-D8F6D57BABCC@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090224162330.AA6CB50822@romeo.rtfm.com> Cc: "sip@ietf.org WG" Subject: Re: [Sip] SSLstrip: Implications for SIPS and our imaginary padlock icon? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:00:27 -0000 At Mon, 23 Feb 2009 10:33:07 -0600, Dean Willis wrote: > > > I've often railed about how using "sips:" doesn't really prove > anything to the user, since the connection is not end-to-end and > downstream elements might be lying about what they are doing. > > Apparently a similar attack is possible on https, when augmented with > a (very) little social engineering. I'm pretty sure this trick would > fool me occasionally, and my mother wouldn't stand a chance. > > > > See: > > http://www.forbes.com/2009/02/18/black-hat-hackers-technology-security_0218_blackhat.html > > > > A poignant quote: > > > The fundamental lesson of his encryption-stripping attack, says > > Marlinspike, is that the protections on the Web's "secure" pages are > > really just as weak as any page that can impersonate that security. > > "The real answer is to encrypt everything," Marlinspike says. "When > > you have a secure protocol that depends on an insecure protocol, > > that's a problem." > > > So, what are the implications for the SIP world? Uh, none? This is the whole reason why you need to start with secure references and not allow opportunistic upgrade. -Ekr From rjsparks@nostrum.com Tue Feb 24 08:02:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9D83A6B02 for ; Tue, 24 Feb 2009 08:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cIvZ5P9A2T1l for ; Tue, 24 Feb 2009 08:02:45 -0800 (PST) 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 D38293A6AFF for ; Tue, 24 Feb 2009 08:02:44 -0800 (PST) Received: from dn3-232.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 n1OG31K7076352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Feb 2009 10:03:01 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Dale Worley In-Reply-To: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 10:03:00 -0600 References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9040/Tue Feb 24 05:12:28 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:02:46 -0000 Won't this run into exactly the same response-size obstacle that the previous diagnostics work tripped up on? It might help to spend some time trying to find some other pattern than trying to use responses for moving the information you're trying to capture around. Source-routed requests in the opposite direction? (using content indirection?) Subscribe/Notify? Maybe something else... RjS On Feb 23, 2009, at 3:37 PM, Dale Worley wrote: > I've been considering the following idea for a diagnostic tool, and > I'd > like to get some feedback on it. > > The goal is to be able to trace the progress of a SIP request through > the network, including seeing the forking structure. We first need to > pick a provisional response codes. It appears that "170" is not > currently used. This response code is also used as an option-tag for > this feature. The processing is that whenever a SIP element > receives a > request that contains "Supported: 170", the element will immediately > (in > addition to anything else that it would do with the request) send a > 170 > response upstream, containing the request as its body (media type > message/sipfrag). > > Dale > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From dean.willis@softarmor.com Tue Feb 24 08:33:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25513A6B22 for ; Tue, 24 Feb 2009 08:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 O+yrnq-ldjJ1 for ; Tue, 24 Feb 2009 08:33:38 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EAE7C3A6B16 for ; Tue, 24 Feb 2009 08:33:37 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n1OGXtXW026099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Feb 2009 10:33:56 -0600 Message-Id: From: Dean Willis To: Dale Worley In-Reply-To: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 10:33:49 -0600 References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:33:38 -0000 On Feb 23, 2009, at 3:37 PM, Dale Worley wrote: > I've been considering the following idea for a diagnostic tool, and > I'd > like to get some feedback on it. > > The goal is to be able to trace the progress of a SIP request through > the network, including seeing the forking structure. We first need to > pick a provisional response codes. It appears that "170" is not > currently used. This response code is also used as an option-tag for > this feature. The processing is that whenever a SIP element > receives a > request that contains "Supported: 170", the element will immediately > (in > addition to anything else that it would do with the request) send a > 170 > response upstream, containing the request as its body (media type > message/sipfrag). Your idea has merit. I believe Jiri Kuthan was working on something like this a few years ago. I've also previously suggested a similar provisional response to inform the UAC about retargeting being done by a proxy. In addition to debugging, this helps avoid the unanticipated respondent problem. -- Dean From dean.willis@softarmor.com Tue Feb 24 08:36:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710673A6B31 for ; Tue, 24 Feb 2009 08:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 JP9Wnlje-EY7 for ; Tue, 24 Feb 2009 08:36:35 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 976743A6B28 for ; Tue, 24 Feb 2009 08:36:35 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n1OGarAH026114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Feb 2009 10:36:54 -0600 Message-Id: <6DEB3F32-D0B7-4716-94A5-E8DFB9D52C9D@softarmor.com> From: Dean Willis To: Robert Sparks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 10:36:47 -0600 References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:36:36 -0000 On Feb 24, 2009, at 10:03 AM, Robert Sparks wrote: > Won't this run into exactly the same response-size obstacle that the > previous diagnostics work tripped up on? > It might help to spend some time trying to find some other pattern > than trying to use responses for moving the information you're > trying to capture around. > Source-routed requests in the opposite direction? (using content > indirection?) Subscribe/Notify? Maybe something else... True. Do we really need the whole message, or just enough information to identify the message and its context, and possibly describe what the proxy is doing in response to the message? For example, what about returning a response that contains little more than the minimum plus a copy of the H-I header that would have been added? -- Dean From ekr@networkresonance.com Tue Feb 24 08:58:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23BC53A6956 for ; Tue, 24 Feb 2009 08:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 7GUsU2HOMF2J for ; Tue, 24 Feb 2009 08:58:26 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id DC1853A6874 for ; Tue, 24 Feb 2009 08:58:26 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9552C50822; Tue, 24 Feb 2009 09:21:34 -0800 (PST) Date: Tue, 24 Feb 2009 09:21:34 -0800 From: Eric Rescorla To: "DRAGE, Keith (Keith)" In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A4CA5D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <28B7C3AA2A7ABA4A841F11217ABE78D674A4CA5D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090224172134.9552C50822@romeo.rtfm.com> Cc: "sip@ietf.org" Subject: Re: [Sip] Notes of identity conference call held 17th Feb 2009 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:58:28 -0000 At Tue, 24 Feb 2009 11:56:38 +0100, DRAGE, Keith (Keith) wrote: > > Attached find the notes of the last conference call of the > interested parties on progressing the identity issues in SIP, held > on 17th Feb 2009. Expect a revised version of > draft-ietf-sip-e2e-identity-important shortly. draft-IETF...? Did this get made a WG document when I wasn't paying attention? -Ekr From adam@nostrum.com Tue Feb 24 09:12:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA7F3A6B28 for ; Tue, 24 Feb 2009 09:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axUSwJ4s3dy7 for ; Tue, 24 Feb 2009 09:12:02 -0800 (PST) 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 EE9EA3A6B39 for ; Tue, 24 Feb 2009 09:12:01 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n1OHCIb0081909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 11:12:19 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <49A42A72.8000006@nostrum.com> Date: Tue, 24 Feb 2009 11:12:18 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: SIP WG , draft-zourzouvillys-sip-via-cookie@tools.ietf.org 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) X-Virus-Scanned: ClamAV 0.94.2/9040/Tue Feb 24 05:12:28 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] draft-zourzouvillys-sip-via-cookie X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:12:03 -0000 Theo: Thanks for pulling this draft together. I certainly admire the problem you're trying to solve, and you've done a very good job of summarizing it and its effects. I have one fundamental point about the proposed mechanism, and a suggestion for further analysis. The fundamental point is based on your observation that this attack can be effective when the victim is a non-SIP endpoint, simply because the incoming SIP messages can saturate their link. (I'll add to that that the attack can wreak havoc on a deployed non-SIP service by intentionally targeting that service's port). With this fact in mind, It's not clear to me how the proposed extension overcomes the described problem. To wit: 1. The attacker sends a request to the amplifiers, with a spoofed source IP. 2. Each of the amplifiers, which are compliant to this specification, sends the new 4XX defined by this document to the victim's IP address. It contains a cookie. 3. Of course, the victim (not having a SIP client running on that port) doesn't respond (at least, not with a SIP message). The attacker, wanting his attack to succeed, has craftily chosen a port he knows to be open (probably by first portscanning the victim). As a consequence, the victim does not send any ICMP error to the amplifiers. 4. Because they didn't get an ACK, 500 ms later, each of the amplifiers sends another 4XX response. 5. This continues according to the response retransmission rules of RFC 3261 until all 11 responses have been sent. So the 11-to-1 amplification attack doesn't appear to be fixed by this mechanism, assuming the attacker makes a rather modest attempt to succeed. Presuming this can be remedied (and I have no immediate suggestions for doing so), I would recommend you consider the interaction between your proposal and forking. Analyze it in the context of the HERFP issues, and make sure forking doesn't cause unintended behavior when interacting with your mechanism. Also, consider longer proxy chains. For example: Note that a 4XX response MUST trigger an ACK to be sent as per normal SIP processing rules. The generated ACK MUST contain the cookie parameter copied from the 4XX response. Keeping in mind that ACK messages triggered by non-2XX responses are hop-by-hop, this falls down when you have a proxy between the UAC and the server sending the 4XX. The intervening proxy may not implement this extension, so you can't rely on it doing anything special with the ACK (unless you define a Proxy-Require, which pretty much renders the extension undeployable). /a From drage@alcatel-lucent.com Tue Feb 24 09:40:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACC63A6B5D for ; Tue, 24 Feb 2009 09:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 hfTDI-Vpk08W for ; Tue, 24 Feb 2009 09:40:37 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 36D413A6A6F for ; Tue, 24 Feb 2009 09:40:36 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1OHerZw031803 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Feb 2009 18:40:54 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 24 Feb 2009 18:40:53 +0100 From: "DRAGE, Keith (Keith)" To: Eric Rescorla Date: Tue, 24 Feb 2009 18:40:51 +0100 Thread-Topic: [Sip] Notes of identity conference call held 17th Feb 2009 Thread-Index: AcmWoT971H8HczpLSi62wmL+kdGAWQABYviA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A8C474@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <28B7C3AA2A7ABA4A841F11217ABE78D674A4CA5D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20090224172134.9552C50822@romeo.rtfm.com> In-Reply-To: <20090224172134.9552C50822@romeo.rtfm.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sip@ietf.org" Subject: Re: [Sip] Notes of identity conference call held 17th Feb 2009 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:40:38 -0000 No, just me suffering from advanced jet lag having flown back into the UK o= ver the weekend. It is of course draft-elwell-sip-e2e-identity-important that you will be ex= pecting a revised version of.=20 regards Keith > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: Tuesday, February 24, 2009 5:22 PM > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] Notes of identity conference call held=20 > 17th Feb 2009 >=20 > At Tue, 24 Feb 2009 11:56:38 +0100, > DRAGE, Keith (Keith) wrote: > >=20 > > Attached find the notes of the last conference call of the=20 > interested=20 > > parties on progressing the identity issues in SIP, held on 17th Feb=20 > > 2009. Expect a revised version of=20 > > draft-ietf-sip-e2e-identity-important shortly. >=20 > draft-IETF...? >=20 > Did this get made a WG document when I wasn't paying attention? >=20 > -Ekr > = From theo@crazygreek.co.uk Tue Feb 24 10:20:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0843C28C171 for ; Tue, 24 Feb 2009 10:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.612 X-Spam-Level: X-Spam-Status: No, score=-5.612 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wQy9jfYcd1AE for ; Tue, 24 Feb 2009 10:20:15 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with SMTP id 1CA453A6826 for ; Tue, 24 Feb 2009 10:20:15 -0800 (PST) Received: from source ([72.14.220.158]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSaQ6cvJSCchjt6nb4XLVRwfFA5znwy5n@postini.com; Tue, 24 Feb 2009 10:20:35 PST Received: by fg-out-1718.google.com with SMTP id l26so125522fgb.31 for ; Tue, 24 Feb 2009 10:20:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.95.8 with SMTP id s8mr22370fgb.28.1235499625944; Tue, 24 Feb 2009 10:20:25 -0800 (PST) In-Reply-To: <49A42A72.8000006@nostrum.com> References: <49A42A72.8000006@nostrum.com> Date: Tue, 24 Feb 2009 18:20:25 +0000 Message-ID: <167dfb9b0902241020p735a304av60063dd664a241c8@mail.gmail.com> From: Theo Zourzouvillys To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIP WG , draft-zourzouvillys-sip-via-cookie@tools.ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:20:17 -0000 On Tue, Feb 24, 2009 at 5:12 PM, Adam Roach wrote: Hi Adam, Thank you for the feedback; > With this fact in mind, It's not clear to me how the > proposed extension overcomes the described problem. To wit: > > *snip* > > =A05. This continues according to the response retransmission rules of > =A0 =A0 RFC 3261 until all 11 responses have been sent. > > So the 11-to-1 amplification attack doesn't appear to be fixed by this > mechanism, assuming the attacker makes a rather modest attempt to succeed= . The key here is that the 4XX response to a request without a cookie is sent by the next hop statelessly, and doesn't cause a server transaction to be created (and thus no re-transmits); as per 4.3, para 4: If a request is received from an IP address that could be spoofable (i.e, any request received from the general internet), and that request is going to have a server transaction created for it, and the top via field contains a cookie parameter, then the server SHOULD generate a new cookie for this source and generates a 4XX response, and place the cookie value into the cookie parameter of the top via field before sending the response statelessly. I'll update this in the working draft to also include: ... and MUST NOT create a server transaction for the request. This implie= s that a server implementing this draft MUST NOT send a 100 response before sending the 4XX. does this satisfy your concern? > Presuming this can be remedied (and I have no immediate suggestions for > doing so), I would recommend you consider the interaction between your > proposal and forking. Analyze it in the context of the HERFP issues, and > make sure forking doesn't cause unintended behavior when interacting with > your mechanism. Because of the hop-by-hop semantics, i can't see any issues that could be caused with the cookie as any 4XX response is just re-transmitted with the cookie, or if the client doesn't support it and the server requires it then it will just be treated like a 400 response - although i'll have more of a think about any issues it could cause in case there are any unintended side effects. > Also, consider longer proxy chains. For example: > > =A0Note that a 4XX response MUST trigger an ACK to be sent as per normal > =A0SIP processing rules. =A0The generated ACK MUST contain the cookie > =A0parameter copied from the 4XX response. > > Keeping in mind that ACK messages triggered by non-2XX responses are > hop-by-hop, this falls down when you have a proxy between the UAC and the > server sending the 4XX. The intervening proxy may not implement this > extension, so you can't rely on it doing anything special with the ACK > (unless you define a Proxy-Require, which pretty much renders the extensi= on > undeployable). In the case a previous hop doesn't support this draft, then the server sending the 4XX would know that the client didn't support the cookie anyway, because the request's top via header didn't contain an empty "cookie" parameter. Although the copying-to-the-ACK is not there for any reason other than diagnostic purposes right now - although arguably the server sending the 4XX can also set the To tag to contain any data it wanted to store so could be removed. ~ Theo From scott.lawrence@nortel.com Tue Feb 24 10:30:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2275928C145 for ; Tue, 24 Feb 2009 10:30:48 -0800 (PST) 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 NOzmdP8Rw6U9 for ; Tue, 24 Feb 2009 10:30:47 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0344128C168 for ; Tue, 24 Feb 2009 10:30:46 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1OIV3m10471; Tue, 24 Feb 2009 18:31:03 GMT Received: from [127.0.0.1] ([47.16.91.121]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 13:30:50 -0500 From: "Scott Lawrence" To: Nils Ohlmeier In-Reply-To: References: <07953AE2-F02A-4E6D-82F5-6730383B44FF@edvina.net> <1230910444.3835.1.camel@victoria-pingtel-com.us.nortel.com> <5D6CB5AC-3ADF-4294-89E9-2FA197545865@edvina.net> <1230913633.3835.29.camel@victoria-pingtel-com.us.nortel.com> <2DC20D47-8F42-486A-9D18-AE6A6FA86001@edvina.net> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 24 Feb 2009 13:30:48 -0500 Message-Id: <1235500248.6652.84.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 (2.24.4-1.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2009 18:30:50.0308 (UTC) FILETIME=[04A3A840:01C996AE] Cc: IETF SIP List , Johansson Olle E Subject: Re: [Sip] Implementing SHA digest auth (new topic) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:30:48 -0000 On Tue, 2009-01-06 at 15:33 +0100, Nils Ohlmeier wrote: > > > But I think if we take that road we should consider some mechanism which > allows UAC and UAS to advertise and agree (?) on the most preferred > algorithm for the authentication. And I guess it should be mandatory that > this mechanism prevents that an attacker can modify the message exchange > in a way that the weakest algorithm is chosen (which is the case with > current proposed solution). The mechanism exists. When it sends the challenge, the server sends a qop parameter whose value is the list of methods it supports, and when the client sends authentication, the qop parameter indicates which method it used. All that is needed is to define new qop token values and how they map to a new hash algorithm. From adam@nostrum.com Tue Feb 24 13:29:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A9A3A6809 for ; Tue, 24 Feb 2009 13:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeNHZN1OLamo for ; Tue, 24 Feb 2009 13:29:35 -0800 (PST) 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 F0FCD3A67E6 for ; Tue, 24 Feb 2009 13:29:34 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n1OLTk8Q016412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 15:29:46 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <49A466CA.9040303@nostrum.com> Date: Tue, 24 Feb 2009 15:29:46 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Theo Zourzouvillys References: <49A42A72.8000006@nostrum.com> <167dfb9b0902241020p735a304av60063dd664a241c8@mail.gmail.com> In-Reply-To: <167dfb9b0902241020p735a304av60063dd664a241c8@mail.gmail.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) X-Virus-Scanned: ClamAV 0.94.2/9041/Tue Feb 24 10:21:07 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP WG , draft-zourzouvillys-sip-via-cookie@tools.ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:29:36 -0000 Theo Zourzouvillys wrote: > On Tue, Feb 24, 2009 at 5:12 PM, Adam Roach wrote: > > Hi Adam, > > Thank you for the feedback; > > >> With this fact in mind, It's not clear to me how the >> proposed extension overcomes the described problem. To wit: >> >> *snip* >> >> 5. This continues according to the response retransmission rules of >> RFC 3261 until all 11 responses have been sent. >> >> So the 11-to-1 amplification attack doesn't appear to be fixed by this >> mechanism, assuming the attacker makes a rather modest attempt to succeed. >> > > The key here is that the 4XX response to a request without a cookie is > sent by the next hop statelessly, and doesn't cause a server > transaction to be created (and thus no re-transmits); as per 4.3, para > 4: > > If a request is received from an IP address that could be spoofable > (i.e, any request received from the general internet), and that > request is going to have a server transaction created for it, and the > top via field contains a cookie parameter, then the server SHOULD > generate a new cookie for this source and generates a 4XX response, > and place the cookie value into the cookie parameter of the top via > field before sending the response statelessly. > Ah -- "statelessly" means something very different to you than it does to me. I think you need to explicitly call out that you're proposing a modification to the basic INVITE transaction model defined in RFC 3261 for this new response. This, combined with prohibiting provisional responses, would seem to have the desired effect. >> Also, consider longer proxy chains. For example: >> >> Note that a 4XX response MUST trigger an ACK to be sent as per normal >> SIP processing rules. The generated ACK MUST contain the cookie >> parameter copied from the 4XX response. >> >> Keeping in mind that ACK messages triggered by non-2XX responses are >> hop-by-hop, this falls down when you have a proxy between the UAC and the >> server sending the 4XX. The intervening proxy may not implement this >> extension, so you can't rely on it doing anything special with the ACK >> (unless you define a Proxy-Require, which pretty much renders the extension >> undeployable). >> > > In the case a previous hop doesn't support this draft, then the server > sending the 4XX would know that the client didn't support the cookie > anyway, because the request's top via header didn't contain an empty > "cookie" parameter. Although the copying-to-the-ACK is not there for > any reason other than diagnostic purposes right now - although > arguably the server sending the 4XX can also set the To tag to contain > any data it wanted to store so could be removed. > It sounds like you're currently setting this up so that it can't work transitively -- that is, if you have a chain of proxies, some of them compliant to this behavior, others that aren't, then any proxy past a non-compliant one can't check return routability. That seems like an artificial limitation. If you had some other way of indicating support by a client that could be checked by every proxy in the chain, then you could perform routability checks all the way back to the client regardless of intervening older proxies. /a From dwing@cisco.com Tue Feb 24 13:43:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BDE428C0F5 for ; Tue, 24 Feb 2009 13:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4StlISwvQyU for ; Tue, 24 Feb 2009 13:43:03 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4FFD83A69E5 for ; Tue, 24 Feb 2009 13:43:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,261,1233532800"; d="scan'208";a="146841451" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2009 21:43:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1OLhMpZ007872; Tue, 24 Feb 2009 13:43:22 -0800 Received: from dwingwxp01 (dhcp-128-107-163-55.cisco.com [128.107.163.55]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1OLhM6k022074; Tue, 24 Feb 2009 21:43:22 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'DRAGE, Keith \(Keith\)'" References: <28B7C3AA2A7ABA4A841F11217ABE78D674A4CA5D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <20090224172134.9552C50822@romeo.rtfm.com> Date: Tue, 24 Feb 2009 13:43:23 -0800 Message-ID: <016f01c996c8$ead282e0$37a36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <20090224172134.9552C50822@romeo.rtfm.com> Thread-Index: AcmWoS5z9vh0jvRQSsKJaP1r++7xUwAJ3MxA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=632; t=1235511803; x=1236375803; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Notes=20of=20identity=20confere nce=20call=20held=2017th=20Feb=202009 |Sender:=20; bh=c2SUZ0dSkc1hBOEiTvFNeQ+QBVGJhHsu73fNf3RZYw8=; b=rl+RCpz63Cfldk6LS1+TM+uvCJ7nbwl/WkuqFbDKp0X4ISbaRC3gWlZJH1 LaYk4EZdNLrxFOHVQ6qfwhHefXc59wt1zv4TvG/ARYMF6E4gAAblJXln8wCV RUY8odl/3W7r/DGHJIVFX/jcRsDgcsLZs1eXz/bTflHxRNLyXOVEc=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Notes of identity conference call held 17th Feb 2009 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:43:04 -0000 > > Attached find the notes of the last conference call of the > > interested parties on progressing the identity issues in SIP, held > > on 17th Feb 2009. Expect a revised version of > > draft-ietf-sip-e2e-identity-important shortly. > > draft-IETF...? > > Did this get made a WG document when I wasn't paying attention? Ekr, Keith clarified that he made a mistake with the document name. But your surprise that this could have become a WG document leads me to feel that you believe end to end identity is not imporatnt. Is my feeling correct, and that you believe end to end identity is not important? -d From theo@crazygreek.co.uk Tue Feb 24 13:58:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CAC3A6A11 for ; Tue, 24 Feb 2009 13:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Vw6MjM1Fwsbi for ; Tue, 24 Feb 2009 13:58:03 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with SMTP id D44843A67E6 for ; Tue, 24 Feb 2009 13:58:02 -0800 (PST) Received: from source ([209.85.220.176]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSaRteqF5+bj3rDSazi71JkDBT5cDFUCl@postini.com; Tue, 24 Feb 2009 13:58:23 PST Received: by mail-fx0-f176.google.com with SMTP id 24so3395601fxm.20 for ; Tue, 24 Feb 2009 13:58:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.72.15 with SMTP id u15mr20927fga.8.1235512698141; Tue, 24 Feb 2009 13:58:18 -0800 (PST) In-Reply-To: <49A466CA.9040303@nostrum.com> References: <49A42A72.8000006@nostrum.com> <167dfb9b0902241020p735a304av60063dd664a241c8@mail.gmail.com> <49A466CA.9040303@nostrum.com> Date: Tue, 24 Feb 2009 21:58:18 +0000 Message-ID: <167dfb9b0902241358h52f4e2e2wed5f24b01a27f582@mail.gmail.com> From: Theo Zourzouvillys To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP WG , draft-zourzouvillys-sip-via-cookie@tools.ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:58:04 -0000 On Tue, Feb 24, 2009 at 9:29 PM, Adam Roach wrote: > Ah -- "statelessly" means something very different to you than it does to > me. I think you need to explicitly call out that you're proposing a > modification to the basic INVITE transaction model defined in RFC 3261 for > this new response. will do > It sounds like you're currently setting this up so that it can't work > transitively -- that is, if you have a chain of proxies, some of them > compliant to this behavior, others that aren't, then any proxy past a > non-compliant one can't check return routability. That seems like an > artificial limitation. If you had some other way of indicating support by a > client that could be checked by every proxy in the chain, then you could > perform routability checks all the way back to the client regardless of > intervening older proxies. While I did initially consider this problem, and indeed came up with a potential solution in the form of a new authentication scheme or a header that the client then used to insert in it's own via header, HERFP as well as multi-hop authentication just seemed to make any solution i could come up with very complex compared to this method - which while it has it's downsides in terms of backward compatibility, the beauty is in it's simplicity and that it should hopefully not be a burden for stacks to add with no change outside of the transaction/transport layer. ~ Theo From shida@ntt-at.com Tue Feb 24 21:59:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA21A3A6AC9 for ; Tue, 24 Feb 2009 21:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rnet-pLPA74 for ; Tue, 24 Feb 2009 21:59:20 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.225.11]) by core3.amsl.com (Postfix) with SMTP id C0BD73A659B for ; Tue, 24 Feb 2009 21:59:20 -0800 (PST) Received: (qmail 6546 invoked from network); 25 Feb 2009 06:18:28 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway16.websitewelcome.com with SMTP; 25 Feb 2009 06:18:28 -0000 Received: from fl1-119-242-13-244.tky.mesh.ad.jp ([119.242.13.244]:57858 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LcCny-00066V-Jc; Tue, 24 Feb 2009 23:59:38 -0600 Message-Id: <6FB93C6A-C6C0-48FB-89DB-D7A1F127E53C@ntt-at.com> From: Shida Schubert To: "Drage, Keith (Keith)" In-Reply-To: <0CDC410E-1413-4D27-99CC-C872036415A6@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 14:59:36 +0900 References: <499A7A8A.1030201@voip.co.uk> <28B7C3AA2A7ABA4A841F11217ABE78D674A092EB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A4C580@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <0CDC410E-1413-4D27-99CC-C872036415A6@softarmor.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: "sip@ietf.org List" , draft-ietf-sip-ua-privacy@tools.ietf.org Subject: Re: [Sip] Comment on sip-ua-privacy-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 05:59:21 -0000 Keith; So what consideration should be noted in the draft with regards to IMEI? I am reading that IMEI is never revealed, whether it's a public or temp GRUU, that sounds like a non-privacy concern. And if it's not a privacy threat I don't know what type of text be added.. I am probably missing your point, but I think I need a bit of guidance here.. Thanks Shida On 24-Feb-09, at 12:43 AM, Dean Willis wrote: > > On Feb 23, 2009, at 1:30 AM, DRAGE, Keith (Keith) wrote: > >> The issue is that while the user may be wanting to use a public >> GRUU, they may not wish to announce their IMEI. Normally, no matter >> what privacy, IMEIs are kept secret in 3GPP. >> > > So it's rather like the distinction between appearing in public, and > appearing naked in public ? One is acceptable for most, the other > only for certain celebrities, or on just the right kind of beach . . . > > -- > Dean > > From michael@voip.co.uk Tue Feb 24 23:27:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7193A6B6A for ; Tue, 24 Feb 2009 23:27:32 -0800 (PST) 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.232, 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 AQNw5fjS8gxw for ; Tue, 24 Feb 2009 23:27:31 -0800 (PST) Received: from voip.co.uk (smtp.sov.voip.co.uk [80.249.108.49]) by core3.amsl.com (Postfix) with ESMTP id C79923A686C for ; Tue, 24 Feb 2009 23:27:31 -0800 (PST) Message-ID: <49A4F2EE.4000100@voip.co.uk> Date: Wed, 25 Feb 2009 07:27:42 +0000 From: Michael Procter User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Adam Roach References: <49A42A72.8000006@nostrum.com> <167dfb9b0902241020p735a304av60063dd664a241c8@mail.gmail.com> <49A466CA.9040303@nostrum.com> In-Reply-To: <49A466CA.9040303@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP WG , draft-zourzouvillys-sip-via-cookie@tools.ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 07:27:32 -0000 Hi Adam, Adam Roach wrote: > Ah -- "statelessly" means something very different to you than it does > to me. I think you need to explicitly call out that you're proposing a > modification to the basic INVITE transaction model defined in RFC 3261 > for this new response. > > This, combined with prohibiting provisional responses, would seem to > have the desired effect. I don't think there is any proposed modification. The response should be sent according to the rules of RFC 3261 section 8.2.7. Amongst other things, this specifically prohibits provisional responses. I think the draft should explicitly mention this section. Regards, Michael From adam@nostrum.com Wed Feb 25 07:00:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462663A6AF3 for ; Wed, 25 Feb 2009 07:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaGs7agqq-1K for ; Wed, 25 Feb 2009 07:00:57 -0800 (PST) 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 2D8523A6AED for ; Wed, 25 Feb 2009 07:00:56 -0800 (PST) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n1PF12TC094963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 09:01:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <49A55D2E.5090509@nostrum.com> Date: Wed, 25 Feb 2009 09:01:02 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Michael Procter References: <49A42A72.8000006@nostrum.com> <167dfb9b0902241020p735a304av60063dd664a241c8@mail.gmail.com> <49A466CA.9040303@nostrum.com> <49A4F2EE.4000100@voip.co.uk> In-Reply-To: <49A4F2EE.4000100@voip.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9047/Wed Feb 25 04:59:41 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP WG , draft-zourzouvillys-sip-via-cookie@tools.ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:00:58 -0000 Michael Procter wrote: > Hi Adam, > > Adam Roach wrote: > >> Ah -- "statelessly" means something very different to you than it does >> to me. I think you need to explicitly call out that you're proposing a >> modification to the basic INVITE transaction model defined in RFC 3261 >> for this new response. >> >> This, combined with prohibiting provisional responses, would seem to >> have the desired effect. >> > > I don't think there is any proposed modification. The response should > be sent according to the rules of RFC 3261 section 8.2.7. Wow -- I had completely forgotten about 8.2.7. > Amongst other > things, this specifically prohibits provisional responses. > > I think the draft should explicitly mention this section. > Yes, that would be a significant improvement. I think you'll also want to give the cookie the same properties as 8.2.7 describes for to-tags. /a From john.elwell@siemens.com Wed Feb 25 12:21:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7942A28C2AF for ; Wed, 25 Feb 2009 12:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 nZ+5eC8v7w8t for ; Wed, 25 Feb 2009 12:20:59 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 57A723A699E for ; Wed, 25 Feb 2009 12:20:58 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KFN00H6T1VFO0@siemenscomms.co.uk> for sip@ietf.org; Wed, 25 Feb 2009 20:21:15 +0000 (GMT) Date: Wed, 25 Feb 2009 20:21:13 +0000 From: "Elwell, John" To: SIP Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00194CA23@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: draft-elwell-sip-e2e-identity-important-03 Thread-Index: AcmXhpp9WWY1JA9DSG6oPLcT325i4Q== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] draft-elwell-sip-e2e-identity-important-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 20:21:00 -0000 The posted draft contains a number of additions compared with 02, as discussed within an informal group during the last few weeks: - identifier modifications classified as conversion, translation or normalisation (section 4); - tabular summary of examples (section 5); - analysis of changes to SIP requests by B2BUAs (section 8); - extension to conclusions (section 9); - a start at requirements (section 10). http://www.ietf.org/internet-drafts/draft-elwell-sip-e2e-identity-import ant-03.txt John From dworley@nortel.com Wed Feb 25 13:36:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136483A6BA3 for ; Wed, 25 Feb 2009 13:36:05 -0800 (PST) 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=[AWL=0.000, 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 4b0g6Msk+5kl for ; Wed, 25 Feb 2009 13:36:04 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 05BF43A6B99 for ; Wed, 25 Feb 2009 13:36:03 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n1PLVx326778; Wed, 25 Feb 2009 21:31:59 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 16:36:11 -0500 From: "Dale Worley" To: Michael Procter In-Reply-To: <49A4F2EE.4000100@voip.co.uk> References: <49A42A72.8000006@nostrum.com> <167dfb9b0902241020p735a304av60063dd664a241c8@mail.gmail.com> <49A466CA.9040303@nostrum.com> <49A4F2EE.4000100@voip.co.uk> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Feb 2009 16:36:10 -0500 Message-Id: <1235597770.3774.60.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2009 21:36:11.0531 (UTC) FILETIME=[13D15DB0:01C99791] Cc: SIP WG , Adam Roach , draft-zourzouvillys-sip-via-cookie@tools.ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 21:36:05 -0000 On Wed, 2009-02-25 at 07:27 +0000, Michael Procter wrote: > Adam Roach wrote: > > Ah -- "statelessly" means something very different to you than it does > > to me. I think you need to explicitly call out that you're proposing a > > modification to the basic INVITE transaction model defined in RFC 3261 > > for this new response. > > > > This, combined with prohibiting provisional responses, would seem to > > have the desired effect. > > I don't think there is any proposed modification. The response should > be sent according to the rules of RFC 3261 section 8.2.7. Amongst other > things, this specifically prohibits provisional responses. > > I think the draft should explicitly mention this section. And more importantly, according to 8.2.7, the recipient of an INVITE does *not* resend a 4xx response if it doesn't receive an ACK. At first read, this seems to violate the 3-way-handshake model of the INVITE transaction, but it doesn't -- If the 4xx got lost, the UAC will send it again, prompting the UAS to send an identical 4xx response. If the ACK gets lost, the UAS doesn't care. Dale From dworley@nortel.com Wed Feb 25 13:39:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8813A6AA7 for ; Wed, 25 Feb 2009 13:39:02 -0800 (PST) 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=[AWL=0.000, 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 4lLJ4NT3Qwo2 for ; Wed, 25 Feb 2009 13:38:58 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 39A0C3A68BC for ; Wed, 25 Feb 2009 13:38:58 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1PLd9026131; Wed, 25 Feb 2009 21:39:09 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 16:39:09 -0500 From: "Dale Worley" To: Adam Roach In-Reply-To: <49A55D2E.5090509@nostrum.com> References: <49A42A72.8000006@nostrum.com> <167dfb9b0902241020p735a304av60063dd664a241c8@mail.gmail.com> <49A466CA.9040303@nostrum.com> <49A4F2EE.4000100@voip.co.uk> <49A55D2E.5090509@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Feb 2009 16:39:08 -0500 Message-Id: <1235597948.3774.64.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2009 21:39:09.0410 (UTC) FILETIME=[7DD78C20:01C99791] Cc: SIP WG , draft-zourzouvillys-sip-via-cookie@tools.ietf.org Subject: Re: [Sip] draft-zourzouvillys-sip-via-cookie X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 21:39:02 -0000 On Wed, 2009-02-25 at 09:01 -0600, Adam Roach wrote: > Wow -- I had completely forgotten about 8.2.7. > > > Amongst other > > things, this specifically prohibits provisional responses. > > > > I think the draft should explicitly mention this section. > > > > > Yes, that would be a significant improvement. I think you'll also want > to give the cookie the same properties as 8.2.7 describes for to-tags. Hmmm... Oddly, you can't do that, because the cookies should depend on the time. But the cookie mechanism quasi-satisfies 8.2.7, because multiple sends of an INVITE will receive multiple responses with different cookies, but all of the cookies are "equivalent", in that any one of them can be chosen for successful future use. Dale From dworley@nortel.com Wed Feb 25 14:03:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29613A68DA for ; Wed, 25 Feb 2009 14:03:56 -0800 (PST) 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=[AWL=0.000, 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 z-3QUQrJ-BnH for ; Wed, 25 Feb 2009 14:03:55 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 860023A6814 for ; Wed, 25 Feb 2009 14:03:55 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n1PLxx302509 for ; Wed, 25 Feb 2009 21:59:59 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 17:04:10 -0500 From: "Dale Worley" To: SIP In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00191A2C2@GBNTHT12009MSX.gb002.siemens.net> References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00191A2C2@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Feb 2009 17:04:10 -0500 Message-Id: <1235599450.3774.84.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2009 22:04:10.0761 (UTC) FILETIME=[FCB78790:01C99794] Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:03:56 -0000 On Mon, 2009-02-23 at 22:08 +0000, Elwell, John wrote: > History-Info can provide some information, depending of course whether > all proxies forward it and add to it as it goes downstream, that the UAS > sends it back, and that all proxies forward it upstream in the response. Yes, if every element implements History-Info fully, you get even better information than a flock of 170's. But I originated this with the idea of inserting it into the sipX stack, and it would take less work to implement 170 than History-Info. There's also the interesting idea of collating the History-Info values from a bunch of 170's. > Both mechanisms would suffer from border elements that strip > things out for topology hiding or other reasons. Yes. And if I go forward with this idea, I would need to show that topology hiding could be done easily and sensibly. One case that would be nice to handle well is that if the UAC's and UAS's organizational networks did not want to topology-hide but the transit carrier did -- you'd like to be able to have the transit carrier hide its topology without hiding what happens in the endpoint networks. > On the detail, I believe 170 would establish an early dialog - is this > desirable, and if not is it avoidable? It would establish an early dialog, and it's not avoidable, other than for the fact that any element that understands 170's knows that there will be no further messages in the early dialog. I'm not sure if it causes any problems. I haven't thought through the interaction with 100rel, though. I think the way to handle that would be to postulate that the 170 came from an internal UAS that did not implement 100rel. On Tue, 2009-02-24 at 10:03 -0600, Robert Sparks wrote: > Won't this run into exactly the same response-size obstacle that the > previous diagnostics work tripped up on? I've mostly assumed that it would be used in an enterprise network, and not worried about message size. sipX has been implementing draft-ietf-sip-hop-limit-diagnostics for years, and we haven't seen any problems. Although in the case of a provisional response, its loss isn't much of a problem. > It might help to spend some time trying to find some other pattern > than trying to use responses for moving the information you're trying > to capture around. > Source-routed requests in the opposite direction? (using content > indirection?) Subscribe/Notify? Maybe something else... Yes, that would help, though it's not clear what mechanism could be as simple as a provisional response. On Tue, 2009-02-24 at 10:36 -0600, Dean Willis wrote: > Do we really need the whole message, or just enough information to > identify the message and its context, and possibly describe what the > proxy is doing in response to the message? > > For example, what about returning a response that contains little more > than the minimum plus a copy of the H-I header that would have been > added? A good point. Though it's hard to explicitly rule out any particular header from being returned, given that in some particular case, the proxies' transformations of that header is the interesting question. On Tue, 2009-02-24 at 10:33 -0600, Dean Willis wrote: > Your idea has merit. I believe Jiri Kuthan was working on something > like this a few years ago. http://tools.ietf.org/html/draft-kuthan-sipping-diag-00 -- Thanks, I'll have to look at it. > I've also previously suggested a similar provisional response to > inform the UAC about retargeting being done by a proxy. In addition to > debugging, this helps avoid the unanticipated respondent problem. Which suggests the possibility of sending 170's based not on the receipt of a request, but on *sending* a copy of the request downstream. The effect would not be much different, but it would require implementing 170 only in proxies. It would also be helpful if the 170 carried the sending and receiving address/port/transport triples, in addition to the usual request-URI. Dale From christer.holmberg@ericsson.com Thu Feb 26 04:27:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29513A694A for ; Thu, 26 Feb 2009 04:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.36 X-Spam-Level: X-Spam-Status: No, score=-5.36 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_83=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 0zQxT1g8hoKx for ; Thu, 26 Feb 2009 04:27:58 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C30203A6924 for ; Thu, 26 Feb 2009 04:27:57 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4AC5621E33; Thu, 26 Feb 2009 13:24:21 +0100 (CET) X-AuditID: c1b4fb3c-ad80abb000001b43-2b-49a689f5fb20 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3ADA920CBE; Thu, 26 Feb 2009 13:24:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 13:24:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Feb 2009 13:24:20 +0100 Message-ID: In-Reply-To: <898632750902230716i21e6206as383b4ddd2a0b1cf0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions about "draft-ietf-sip-199-05" thread-index: AcmVyb/MrI2Ho63XT0iQGBtA1jb/RQCQhZxw References: <898632750902230716i21e6206as383b4ddd2a0b1cf0@mail.gmail.com> From: "Christer Holmberg" To: "Eric wang" X-OriginalArrivalTime: 26 Feb 2009 12:24:20.0931 (UTC) FILETIME=[26C68130:01C9980D] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Questions about "draft-ietf-sip-199-05" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 12:27:59 -0000 Hi,=20 >Glad to see that the draft starts its WGLC process. Well, that is what I requested at least :) >I still have some difficult in using IETF and cannot find the whole sorted comments about this draft, so i have some doubt about this draft. >=20 > 1. "If a forking proxy receives a reliably sent 199 response for a dialog, for which the proxy has previously generated and sent a 199 response, the proxy MUST forward the 199 response." > > Does it describe the case below? Although P1 have sent a 199 response, P1 havs to forword the send reliably 199 too.Or is the first 199 mistaked for 18x? >=20 > UAC P1 UAS_2 =20 > --- INVITE ------> > --- INVITE (leg 2) -> > <-- 199(leg 2) -- > <-- 199 (leg 2) ----- > <-- 199(leg 2) -- =20 I think it shall be 199, as currently written. >2. "10. Usage with 100rel=20 > > When a 199 Early Dialog Terminated provisional response is sent by a UAS, since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably even if the 100rel=20 > option tag [RFC3262] is present in the Require header of the associated request." > > =20 >I have seen a comment on this question,but still not understood about it. If the INVITE has a Require tag "Require: 100rel",does the UAS still use unreliable 199 response? That is the recommendation, yes. The reasons is that we want to keep 199 as "lightweight" as possible, without requireing re-transmissions and PRACKs. >If 199 is reliable, there is one more advantage. If the 199 arrives before the first 18x response, UAC can discard the first 199 and process it until UAC receives the first 18x response that has the same=20 >to-tag as 199, as the reliable 199 should be re-transmited until received PRACK. If the INVITE contains "Require: 100rel", the first 18x must also be sent reliably. And, I don't think the UAS is allowed to send another reliable response until the first one is acknowledged, so I don't think a reliable 199 would reach the UAC before the first reliable 18x. >Can anyone show me how to sort all comments of a topic by time? Unless it can be done by sorting the e-mails by subject it is kinda difficult. Regards, Christer =20 =20 =20 From eric.wangxr@gmail.com Thu Feb 26 06:37:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939C228C2D1 for ; Thu, 26 Feb 2009 06:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[AWL=1.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=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 JAdZ8vLdu9nO for ; Thu, 26 Feb 2009 06:37:09 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 8426028C2CF for ; Thu, 26 Feb 2009 06:37:08 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so517404rvb.49 for ; Thu, 26 Feb 2009 06:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Mm5gIdqXmnoEkfuP4CWPidpQuPCKd8BqdoHUir4nPH8=; b=thpbgaJKXgskqHmD5s7NOlK0IDO6LyZmu4IkKtu/DszSYvsLHx4+oodQcfpagnVrrU to6rK1GEeMr62+SMhRSYmtkzNigpuHRivY4LCs8k/5K4xxMy8uZDjnwR1RN6MQMfWmaK 6V3g30zDV8JuFOl/SEaRmYieWnXaTHM4Uj0Ig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NrBdaFvCqlEG6ElrYuoTAkQnzFIiKfiWoUD+eFu9k9SFjNjD89ogWUR5NiKjJ1umZc AEoSDvlIYkrNXZz5o+V7b/ZfQ6fExumeBykyWmCe4of6qL38cfKWA7dYIPgcYpinv8kU /BCVD6+IiZ8NLOX5btVnm65C0pox1D2rDSUBI= MIME-Version: 1.0 Received: by 10.140.140.3 with SMTP id n3mr683266rvd.111.1235659050331; Thu, 26 Feb 2009 06:37:30 -0800 (PST) In-Reply-To: References: <898632750902230716i21e6206as383b4ddd2a0b1cf0@mail.gmail.com> Date: Thu, 26 Feb 2009 22:37:30 +0800 Message-ID: <898632750902260637s16915ec0id9e2f573e1654ea8@mail.gmail.com> From: Eric wang To: Christer Holmberg Content-Type: multipart/alternative; boundary=000e0cd24b9ec22e7f0463d34a79 Cc: sip@ietf.org Subject: Re: [Sip] Questions about "draft-ietf-sip-199-05" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 14:37:10 -0000 --000e0cd24b9ec22e7f0463d34a79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Christer, Thanks for replying. Comments are maked with [Eric] below. 3ks. >Glad to see that the draft starts its WGLC process. Well, that is what I requested at least :) >I still have some difficult in using IETF and cannot find the whole sorted comments about this draft, so i have some doubt about this draft. > > 1. "If a forking proxy receives a reliably sent 199 response for a dialog, for which the proxy has previously generated and sent a 199 response, the proxy MUST forward the 199 response." > > Does it describe the case below? Although P1 have sent a 199 response, P1 havs to forword the send reliably 199 too.Or is the first 199 mistaked for 18x? > > UAC P1 UAS_2 > --- INVITE ------> > --- INVITE (leg 2) -> > <-- 199(leg 2) -- > <-- 199 (leg 2) ----- > <-- 199(leg 2) -- I think it shall be 199, as currently written. [Eric]: If this is 199, then Is there a special purpose to send two 199 in the same dialog? I think that one 199 is enough. And the first 199 may be reliable too, that will make it a little difficult to send the second 199. >2. "10. Usage with 100rel > > When a 199 Early Dialog Terminated provisional response is sent by a UAS, since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably even if the 100rel > option tag [RFC3262] is present in the Require header of the associated request." > > >I have seen a comment on this question,but still not understood about it. If the INVITE has a Require tag "Require: 100rel",does the UAS still use unreliable 199 response? That is the recommendation, yes. The reasons is that we want to keep 199 as "lightweight" as possible, without requireing re-transmissions and PRACKs. [Eric]: But reliable 199 have more advantage, and It is worth to use the reliable 199,I think. >If 199 is reliable, there is one more advantage. If the 199 arrives before the first 18x response, UAC can discard the first 199 and process it until UAC receives the first 18x response that has the same >to-tag as 199, as the reliable 199 should be re-transmited until received PRACK. If the INVITE contains "Require: 100rel", the first 18x must also be sent reliably. And, I don't think the UAS is allowed to send another reliable response until the first one is acknowledged, so I don't think a reliable 199 would reach the UAC before the first reliable 18x. [Eric]: Surely the UAS is allowed to send another reliable response until the first one is acknowledged, but reliable 199 will be useful if the first 18x is unreliable, or the first 18x has been acknwledged. It's another case different from the above one whose INVITE contains "require: 100rel". >Can anyone show me how to sort all comments of a topic by time? Unless it can be done by sorting the e-mails by subject it is kinda difficult. Regards, Christer Regards, Eric.wang --000e0cd24b9ec22e7f0463d34a79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer,
=A0=A0 Thanks for replying.
=A0=A0 Comments are maked with [Eric] below. 3ks.

>Glad to s= ee that the draft starts its WGLC process.

Well, that is what I requ= ested at least :)

>I still have some difficult in using IETF and = cannot find the whole
sorted comments about this draft, so i have some doubt about this draft.>
>=A0=A0 1.=A0=A0 "If a forking proxy receives a reliably s= ent 199 response for a
dialog, for which the proxy has previously genera= ted and sent a 199
response, the proxy MUST forward the 199 response."
>
>=A0= =A0=A0=A0 Does it describe the case below? Although P1 have sent a 199
r= esponse, P1 havs to=A0=A0forword the send reliably 199 too.Or=A0=A0is thefirst 199 mistaked for 18x?
>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0UAC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 P1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0UAS_2<= br>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0--- INVITE ------>
>=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 --- INVITE (leg 2) ->
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= <-- 199(leg 2) --
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <-- 199 (leg 2) -----
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0<-- 199(leg 2) --

I think= it shall be 199, as currently written.
=A0
[Eric]:=A0If=A0 this is 199, then=A0Is there= =A0a special purpose to send two 199 in the=A0same dialog?
I think that one 199 is enough.
And=A0 the first 199 may be reliable too, that= will make it a little difficult to send the second 199.
=A0

>2.=A0=A0"10.=A0=A0Usage with 100rel
>
>=A0=A0= When a 199 Early Dialog Terminated provisional response is sent by a
UA= S, since the provisional response is only used for information
purpose, = the UAS SHOULD send it unreliably even if the 100rel
>=A0=A0 option tag [RFC3262] is present in the Require header of the
= associated request."
>
>
>I have seen a comment on t= his question,but still not understood about
it. If the INVITE has a Requ= ire tag "Require: 100rel",does the UAS still
use unreliable 199 response?

That is the recommendation, yes. The re= asons is that we want to keep 199
as "lightweight" as possible= , without requireing re-transmissions and
PRACKs.
=A0
[Eric]: But reliable 199 have more advantage, = and It is worth to use the reliable 199,I think.

>If 199 i= s reliable, there is one more advantage. If the 199 arrives
before the f= irst 18x response, UAC can discard the first 199 and process
it until UAC receives the first 18x response that has the same
>to-ta= g as 199, as the reliable 199 should be re-transmited until
received PRA= CK.

If the INVITE contains "Require: 100rel", the first 18= x must also be
sent reliably. And, I don't think the UAS is allowed to send anotherreliable response until the first one is acknowledged, so I don't thin= k
a reliable 199 would reach the UAC before the first reliable 18x.
=A0
[Eric]: Surely the UAS is allowed to send anot= her reliable response until the first one is acknowledged, but reliable 199= will be useful if the first 18x is unreliable, or
the first 18x has been acknwledged.
It's another case different from the above= one=A0 whose INVITE contains "require: 100rel".


>Can anyone show me how to sort all comments of a topic by = time?

Unless it can be done by sorting the e-mails by subject it is = kinda
difficult.

Regards,

Christer


Regards,

Eric.wang







=A0
--000e0cd24b9ec22e7f0463d34a79-- From christer.holmberg@ericsson.com Thu Feb 26 11:03:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4FF3A6822 for ; Thu, 26 Feb 2009 11:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.372 X-Spam-Level: X-Spam-Status: No, score=-5.372 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_83=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 6RvbL7VuiRb8 for ; Thu, 26 Feb 2009 11:03:46 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9CCB63A6818 for ; Thu, 26 Feb 2009 11:03:45 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 39B2720E43; Thu, 26 Feb 2009 20:04:06 +0100 (CET) X-AuditID: c1b4fb3c-aa804bb000001b43-21-49a6e7a6bb7d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0E59420496; Thu, 26 Feb 2009 20:04:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 20:04:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Feb 2009 20:04:03 +0100 Message-ID: In-Reply-To: <898632750902260637s16915ec0id9e2f573e1654ea8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions about "draft-ietf-sip-199-05" thread-index: AcmYH8VB+iJ8tH7QTZelKlPMyfF/JgAJFD7w References: <898632750902230716i21e6206as383b4ddd2a0b1cf0@mail.gmail.com> <898632750902260637s16915ec0id9e2f573e1654ea8@mail.gmail.com> From: "Christer Holmberg" To: "Eric wang" X-OriginalArrivalTime: 26 Feb 2009 19:04:06.0196 (UTC) FILETIME=[FF1B7F40:01C99844] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Questions about "draft-ietf-sip-199-05" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:03:46 -0000 Hi, >I still have some difficult in using IETF and cannot find the whole sorted comments about this draft, so i have some doubt about this draft. > > 1. "If a forking proxy receives a reliably sent 199 response for a dialog, for which the proxy has previously generated and sent a 199 response, the proxy MUST forward the 199 response." > > Does it describe the case below? Although P1 have sent a 199 response, P1 havs to forword the send reliably 199 too.Or is the first 199 mistaked for 18x? > > UAC P1 UAS_2 > --- INVITE ------> > --- INVITE (leg 2) -> > <-- 199(leg 2) -- > <-- 199 (leg 2) ----- > <-- 199(leg 2) -- >I think it shall be 199, as currently written. >=20 >[Eric]: If this is 199, then Is there a special purpose to send two 199 in the same dialog? >I think that one 199 is enough. >And the first 199 may be reliable too, that will make it a little difficult to send the second 199. =20 The second 199 could include information which is to be forwarded to the UAC. >2. "10. Usage with 100rel > > When a 199 Early Dialog Terminated provisional response is sent by a UAS, since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably even if the 100rel > option tag [RFC3262] is present in the Require header of the associated request." > > >I have seen a comment on this question,but still not understood about >it. If the INVITE has a Require tag "Require: 100rel",does the UAS still >use unreliable 199 response? > >That is the recommendation, yes. The reasons is that we want to keep 199 >as "lightweight" as possible, without requireing re-transmissions and >PRACKs. >=20 >[Eric]: But reliable 199 have more advantage, and It is worth to use the reliable 199,I think. I don't know what that advantage would be, compared to having to send PRACKs etc. This has been discussed quite much, so I would really need some good justification to change it now. Also, the draft doesn't forbid you to send the 199 reliably. It's only a SHOULD. >If 199 is reliable, there is one more advantage. If the 199 arrives >before the first 18x response, UAC can discard the first 199 and process >it until UAC receives the first 18x response that has the same >to-tag as 199, as the reliable 199 should be re-transmited until >received PRACK. > >If the INVITE contains "Require: 100rel", the first 18x must also be >sent reliably. And, I don't think the UAS is allowed to send another >reliable response until the first one is acknowledged, so I don't think >a reliable 199 would reach the UAC before the first reliable 18x. >=20 >[Eric]: Surely the UAS is allowed to send another reliable response until the first one is acknowledged, If I remember correctly, the FIRST reliable response must be acknowleded before the next reliable response is sent. But, we can double check in the PRACK spec. >but reliable 199 will be useful if the first 18x is unreliable, or the first 18x has been acknwledged. It's another case different from the above one whose INVITE contains "require: 100rel". If 100rel is required the 18x cannot be unreliable. Regards, Christer =20 From drage@alcatel-lucent.com Thu Feb 26 16:07:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60F53A6847 for ; Thu, 26 Feb 2009 16:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 VZv5bB0VqcRg for ; Thu, 26 Feb 2009 16:07:10 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id A83123A67D7 for ; Thu, 26 Feb 2009 16:07:08 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1R07Toj004931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 27 Feb 2009 01:07:29 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 27 Feb 2009 01:07:29 +0100 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Fri, 27 Feb 2009 01:07:28 +0100 Thread-Topic: Initial Version I-D Submission Deadline Extended to March 4, 2009 Thread-Index: AcmYSLzWIyUWaGUBQf+DoDeCONGxTwABfVFg Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A8CB09@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [Sip] FW: Initial Version I-D Submission Deadline Extended to March 4, 2009 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 00:07:11 -0000 (As WG chair) For information of the WG see below. Please however try and make the existing deadline if you can, as the deadli= nes are set to give people time to read the documents and make comments on = them. Particularly for new author documents, we expect to see discussion on= the list identifying issues for discussion, and there are no automatic fir= st time agenda slots! Therefore the two extra days you take may be the two = days discussion that would have given you an agenda slot! When submitting documents, please do take note of the new IPR requirements.= In particular make sure that:=20 - if your company rather than you controls the IPR of your work, that they = are aware of the new submission rules in RFC 5378. - if you incorporate material from other authors, that those authors should= be in accordance with the copyright submission statements that you are mak= ing. regards Keith -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behal= f Of Alexa Morris Sent: Thursday, February 26, 2009 7:28 PM To: ietf-announce@ietf.org; ietf@ietf.org; wgchairs@ietf.org Subject: Initial Version I-D Submission Deadline Extended to March 4, 2009 The IESG has extended the deadline for initial version (00) submissions of = Internet Drafts by 2 days (48 hours). The new deadline is March 4, 2009 at = 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) and the extension is for IE= TF 74 only. The deadline has been extended due to the copyright legend tex= t alternative being recently finalized, approved and implemented. Please note that the date for updated I-D versions has NOT been extended, a= nd is still March 9, 2009. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting= and Event Planning www.amsl.com From poplarbird@gmail.com Thu Feb 26 16:10:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE403A68AC for ; Thu, 26 Feb 2009 16:10:41 -0800 (PST) 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 xjkF09iAhzAf for ; Thu, 26 Feb 2009 16:10:40 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 8626B3A67D7 for ; Thu, 26 Feb 2009 16:10:40 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1131455qwe.31 for ; Thu, 26 Feb 2009 16:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:mime-version:content-type:x-mailer:x-mimeole:thread-index; bh=sXH5lY4WNaMs/Sr+y7TgX1czWTnj8WkasaWWc+EBGI0=; b=h5BGzsg8y2VlzMO2OnSoL5p4fW+I60mJAfAYRILe9ElJAWESxxh9y9zLAXqhKAdJaB XZmtIhTuSuXotNDm0sc4vGX+CG89nUCY1e+oVysMCcE5ncLsmywXJTBchXnG5B9jJZB6 7NPf4BQlBgWODNjFfKlWvXUtWtZ7qsRZYZ6Zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type:x-mailer :x-mimeole:thread-index; b=lClPKG4djcpLIBbsGeZiS2CKUKPok3HiY+TTSBcEvy9mifR8RW93enu78CfcGcgbLp qYjzOY7PJNdzbbOC0F+gWGhZ9NR+yvpTP8d3qOrI4r5V1SGkQGpbna4G4+CJepffQv3F oDH1/1Ej8L3PtZQ+ewtd663d/SyLDf+bg+ZPQ= Received: by 10.224.60.138 with SMTP id p10mr3205622qah.235.1235693462246; Thu, 26 Feb 2009 16:11:02 -0800 (PST) Received: from 61rdjuanpc1 (codian-syd-gw.aspac.customer.alter.net [210.80.189.46]) by mx.google.com with ESMTPS id 30sm1787045yxk.22.2009.02.26.16.11.00 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 16:11:01 -0800 (PST) Message-ID: <49a72f95.9e03be0a.0caf.ffffe479@mx.google.com> From: "poplarbird" To: Date: Fri, 27 Feb 2009 11:10:57 +1100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C998CC.12B79020" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 thread-index: AcmYb9zwR3gdTKorSyiRhZl//xxh2A== Subject: [Sip] Questions about the status of dual video feature in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 00:10:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C998CC.12B79020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, I am currently working on the interworking between SIP and H323. I had difficult in finding the status of SIP supporting dual video (e.g. H.239 from a H.323 endpoint). Are there any drafts or standards working on it? Also with the text chatting in a SIP call, if anyone can give me the RFC number that would be great. Thanks, Yang ------=_NextPart_000_001B_01C998CC.12B79020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I am currently working on the interworking = between SIP and H323.

 

I had difficult in finding the status of SIP supporting dual video (e.g. H.239 from a H.323 = endpoint).

Are there any drafts or standards working on = it?

 

Also with the text chatting in a SIP call, if = anyone can give me the RFC number that would be = great.

 

Thanks,

Yang

------=_NextPart_000_001B_01C998CC.12B79020-- From wang.libo@zte.com.cn Thu Feb 26 17:07:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A7A3A68C1 for ; Thu, 26 Feb 2009 17:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.262 X-Spam-Level: X-Spam-Status: No, score=-90.262 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, 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 AllUan0i8WEu for ; Thu, 26 Feb 2009 17:07:26 -0800 (PST) Received: from mail.zte.com.cn (mail.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 5DCCE3A67B4 for ; Thu, 26 Feb 2009 17:07:23 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 33096.4710279052; Fri, 27 Feb 2009 09:28:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n1R16Twl093861; Fri, 27 Feb 2009 09:06:31 +0800 (CST) (envelope-from wang.libo@zte.com.cn) In-Reply-To: To: "Christer Holmberg" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 Message-ID: From: wang.libo@zte.com.cn Date: Fri, 27 Feb 2009 09:06:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-02-27 09:06:26, Serialize complete at 2009-02-27 09:06:26 Content-Type: multipart/alternative; boundary="=_alternative 0006147F4825756A_=" X-MAIL: mse1.zte.com.cn n1R16Twl093861 Cc: sip@ietf.org Subject: [Sip] =?gb2312?b?tPC4tDogUkU6IFF1ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0?= =?gb2312?b?Zi1zaXAtMTk5LTA1Ig==?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:07:28 -0000 This is a multipart message in MIME format. --=_alternative 0006147F4825756A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkFuZCB0aGVyZSBzdGlsbCB0d28gcXVlc3Rpb25zIGxlZnQuDQoNCjEuICBJcyB0aGUg MTk5IHNob3VsZCBiZSByZWxpYWJsZSBvciB1bnJlbGlhYmxlPw0KICAgIEkgdGhpbmsgdGhhdCAx OTkgc2hvdWxkIGJlIHJlbGlhYmxlIGlmIHBvc3NpYmxlLg0KDQoNCiAgIEZpcnN0LCBJZiBhIGNs aWVudCByZWNlaXZlcyBhbiB1bnJlbGlhYmxlIDE5OSByZXNwb25zZSBvbiBhIGRpYWxvZyANCndo aWNoIGhhcw0KICAgbm90IHByZXZpb3VzbHkgYmVlbiBjcmVhdGVkICh0aGlzIGNhbiBoYXBwZW4g aWYgYSAxOTkgcmVzcG9uc2UNCiAgIHJlYWNoZXMgdGhlIGNsaWVudCBiZWZvcmUgYSAxOHggcmVz cG9uc2UpIHRoZSBjbGllbnQgU0hBTEwgZGlzY2FyZA0KICAgdGhlIDE5OSByZXNwb25zZXMuDQoN CiAgIFRoZSBmaWd1cmUgYmVsb3cgc2hvd3MgYW4gZXhhbXBsZS5UaGUgMTgwIGlzIHNlbnQgZmly c3QgYnV0IGFycml2ZXMgDQpsYXRlciB0aGFuIDE5OS4NCklmIHRoZSAxOTkgaXMgcmVsaWFibGUs IHRoZSBwcm94eSBzaG91bGQgcmV0cmFuc21pdCAxOTkgKHN0ZXAgNCksYW5kIHRoZW4gDQp0aGUg cmV0cmFuc21pdHRlZA0KMTk5IHdpbGwgYmUgYWNjZXB0ZWQgYnkgVUFDLGFuZCB0aGUgZWFybHkg ZGlhbG9nIHdpbGwgYmUgdGVtaW5hdGVkLg0KDQpVQUMgICAgICAgICAgICAgUA0KICAgMS4gSU5W SVRFDQotLS0tLS0tLS0tLS0tLS0+DQogICAgICAgICAgMi4gMTgwDQo8LS0tLS0gXC8tLS0tLS0t DQogICAgICAgL1wgMy4gMTk5DQo8LS0tLS0vICBcLS0tLS0tDQogICAgICAgICAgNC4gMTk5KHJl dHJhbnNtaXR0ZWQpDQo8LS0tLS0tLS0tLS0tLS0tDQoNCiAgIHNlY29uZCwgQWNjb3JkaW5nIHRv IHByYWN0aWNhbCB1c2UsIDE5OSBjYW4gYmUgaW50ZW5kZWQgdG8gdGVtaW5hdGUgb25lIA0KZWFy bHkgZGlhbG9nIGFuZCByZWxlYXNlIA0KcmVzb3VyY2VzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3Bl Y2lmaWMgZWFybHkgZGlhbG9nLCBzbyB0aGUgY29zdCBzcGVudCBvbiANCnJlbGlhYmxlIDE5OSBp cyB3b3J0aHkuDQpJZiB0aGUgMTk5IGNhbm5vdCBiZSBzZW50IHJlbGlhYmxlLHRoZW4gd2Ugc2hv dWxkIHNlbmQgaXQgdW5yZWxpYWJsZS4NCiANCjIuIEluIHlvdXIgbGFzdCBsZXR0ZXIsIHlvdSBz YWlkICJ0aGUgc2Vjb25kIDE5OSBjb3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIA0Kd2hpY2ggaXMg dG8gYmUgZm9yd2FyZGVkIHRvIHRoZQ0KVUFDIiwgdGhlbiBkbyB5b3UgbWVhbiwgdGhlIGVhcmx5 IGRpYWxvZyBpcyBzdGlsbCBhbGl2ZSBhZnRlciB0aGUgZmlyc3QgDQoxOTkgaXMgYWNjZXB0ZWQ/ DQoNCg0KQWxzbywgSW4gbXkgbGFzdCBsZXR0ZXIsIEkgbWlzcyBhICJOT1QiIGJ5IG1pc3Rha2Uu IA0KSXQgc2hvdWxkIGJlIA0KW0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBpcyBOT1QgYWxsb3dlZCB0 byBzZW5kIGFub3RoZXIgcmVsaWFibGUgcmVzcG9uc2UNCnVudGlsIHRoZSBmaXJzdCBvbmUgaXMg YWNrbm93bGVkZ2VkLi4uDQoNClJlZ2FyZHMsDQpFcmljIHdhbmcNCg0KDQoNCg0KDQoiQ2hyaXN0 ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IA0KMjAwOS0wMi0y NyAwMzowNA0KDQrK1bz+yMsNCiJFcmljIHdhbmciIDxlcmljLndhbmd4ckBnbWFpbC5jb20+DQqz rcvNDQo8c2lwQGlldGYub3JnPiwgPHdhbmcubGlib0B6dGUuY29tLmNuPg0K1vfM4g0KUkU6IFF1 ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0Zi1zaXAtMTk5LTA1Ig0KDQoNCg0KDQoNCg0KSGksDQoN Cj5JIHN0aWxsIGhhdmUgc29tZSBkaWZmaWN1bHQgaW4gdXNpbmcgSUVURiBhbmQgY2Fubm90IGZp bmQgdGhlIHdob2xlDQpzb3J0ZWQgY29tbWVudHMgYWJvdXQgdGhpcyBkcmFmdCwgc28gaSBoYXZl IHNvbWUgZG91YnQgYWJvdXQgdGhpcyBkcmFmdC4NCj4NCj4gICAxLiAgICJJZiBhIGZvcmtpbmcg cHJveHkgcmVjZWl2ZXMgYSByZWxpYWJseSBzZW50IDE5OSByZXNwb25zZSBmb3IgYQ0KZGlhbG9n LCBmb3Igd2hpY2ggdGhlIHByb3h5IGhhcyBwcmV2aW91c2x5IGdlbmVyYXRlZCBhbmQgc2VudCBh IDE5OQ0KcmVzcG9uc2UsIHRoZSBwcm94eSBNVVNUIGZvcndhcmQgdGhlIDE5OSByZXNwb25zZS4i DQo+DQo+ICAgICBEb2VzIGl0IGRlc2NyaWJlIHRoZSBjYXNlIGJlbG93PyBBbHRob3VnaCBQMSBo YXZlIHNlbnQgYSAxOTkNCnJlc3BvbnNlLCBQMSBoYXZzIHRvICBmb3J3b3JkIHRoZSBzZW5kIHJl bGlhYmx5IDE5OSB0b28uT3IgIGlzIHRoZQ0KZmlyc3QgMTk5IG1pc3Rha2VkIGZvciAxOHg/DQo+ DQo+ICAgICAgICAgIFVBQyAgICAgICAgICAgICAgIFAxICAgICAgICAgICAgICAgICAgVUFTXzIN Cj4gICAgICAgICAgICAtLS0gSU5WSVRFIC0tLS0tLT4NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tLSBJTlZJVEUgKGxlZyAyKSAtPg0KPiAgICAgICAgICAgIDwtLSAxOTkobGVnIDIp IC0tDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0gMTk5IChsZWcgMikgLS0tLS0N Cj4gICAgICAgICAgICA8LS0gMTk5KGxlZyAyKSAtLQ0KDQo+SSB0aGluayBpdCBzaGFsbCBiZSAx OTksIGFzIGN1cnJlbnRseSB3cml0dGVuLg0KPiANCj5bRXJpY106IElmICB0aGlzIGlzIDE5OSwg dGhlbiBJcyB0aGVyZSBhIHNwZWNpYWwgcHVycG9zZSB0byBzZW5kIHR3bw0KMTk5IGluIHRoZSBz YW1lIGRpYWxvZz8NCj5JIHRoaW5rIHRoYXQgb25lIDE5OSBpcyBlbm91Z2guDQo+QW5kICB0aGUg Zmlyc3QgMTk5IG1heSBiZSByZWxpYWJsZSB0b28sIHRoYXQgd2lsbCBtYWtlIGl0IGEgbGl0dGxl DQpkaWZmaWN1bHQgdG8gc2VuZCB0aGUgc2Vjb25kIDE5OS4NCiANClRoZSBzZWNvbmQgMTk5IGNv dWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gd2hpY2ggaXMgdG8gYmUgZm9yd2FyZGVkIHRvIHRoZQ0K VUFDLg0KDQoNCj4yLiAgIjEwLiAgVXNhZ2Ugd2l0aCAxMDByZWwNCj4NCj4gICBXaGVuIGEgMTk5 IEVhcmx5IERpYWxvZyBUZXJtaW5hdGVkIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGlzIHNlbnQgYnkg YQ0KVUFTLCBzaW5jZSB0aGUgcHJvdmlzaW9uYWwgcmVzcG9uc2UgaXMgb25seSB1c2VkIGZvciBp bmZvcm1hdGlvbg0KcHVycG9zZSwgdGhlIFVBUyBTSE9VTEQgc2VuZCBpdCB1bnJlbGlhYmx5IGV2 ZW4gaWYgdGhlIDEwMHJlbA0KPiAgIG9wdGlvbiB0YWcgW1JGQzMyNjJdIGlzIHByZXNlbnQgaW4g dGhlIFJlcXVpcmUgaGVhZGVyIG9mIHRoZQ0KYXNzb2NpYXRlZCByZXF1ZXN0LiINCj4NCj4NCj5J IGhhdmUgc2VlbiBhIGNvbW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQgc3RpbGwgbm90IHVuZGVy c3Rvb2QgYWJvdXQNCj5pdC4gSWYgdGhlIElOVklURSBoYXMgYSBSZXF1aXJlIHRhZyAiUmVxdWly ZTogMTAwcmVsIixkb2VzIHRoZSBVQVMNCnN0aWxsDQo+dXNlIHVucmVsaWFibGUgMTk5IHJlc3Bv bnNlPw0KPg0KPlRoYXQgaXMgdGhlIHJlY29tbWVuZGF0aW9uLCB5ZXMuIFRoZSByZWFzb25zIGlz IHRoYXQgd2Ugd2FudCB0byBrZWVwDQoxOTkNCj5hcyAibGlnaHR3ZWlnaHQiIGFzIHBvc3NpYmxl LCB3aXRob3V0IHJlcXVpcmVpbmcgcmUtdHJhbnNtaXNzaW9ucyBhbmQNCj5QUkFDS3MuDQo+IA0K PltFcmljXTogQnV0IHJlbGlhYmxlIDE5OSBoYXZlIG1vcmUgYWR2YW50YWdlLCBhbmQgSXQgaXMg d29ydGggdG8gdXNlDQp0aGUgcmVsaWFibGUgMTk5LEkgdGhpbmsuDQoNCkkgZG9uJ3Qga25vdyB3 aGF0IHRoYXQgYWR2YW50YWdlIHdvdWxkIGJlLCBjb21wYXJlZCB0byBoYXZpbmcgdG8gc2VuZA0K UFJBQ0tzIGV0Yy4gVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgcXVpdGUgbXVjaCwgc28gSSB3b3Vs ZCByZWFsbHkgbmVlZA0Kc29tZSBnb29kIGp1c3RpZmljYXRpb24gdG8gY2hhbmdlIGl0IG5vdy4N Cg0KQWxzbywgdGhlIGRyYWZ0IGRvZXNuJ3QgZm9yYmlkIHlvdSB0byBzZW5kIHRoZSAxOTkgcmVs aWFibHkuIEl0J3Mgb25seSBhDQpTSE9VTEQuDQoNCg0KPklmIDE5OSBpcyByZWxpYWJsZSwgdGhl cmUgaXMgb25lIG1vcmUgYWR2YW50YWdlLiBJZiB0aGUgMTk5IGFycml2ZXMNCj5iZWZvcmUgdGhl IGZpcnN0IDE4eCByZXNwb25zZSwgVUFDIGNhbiBkaXNjYXJkIHRoZSBmaXJzdCAxOTkgYW5kDQpw cm9jZXNzDQo+aXQgdW50aWwgVUFDIHJlY2VpdmVzIHRoZSBmaXJzdCAxOHggcmVzcG9uc2UgdGhh dCBoYXMgdGhlIHNhbWUNCj50by10YWcgYXMgMTk5LCBhcyB0aGUgcmVsaWFibGUgMTk5IHNob3Vs ZCBiZSByZS10cmFuc21pdGVkIHVudGlsDQo+cmVjZWl2ZWQgUFJBQ0suDQo+DQo+SWYgdGhlIElO VklURSBjb250YWlucyAiUmVxdWlyZTogMTAwcmVsIiwgdGhlIGZpcnN0IDE4eCBtdXN0IGFsc28g YmUNCj5zZW50IHJlbGlhYmx5LiBBbmQsIEkgZG9uJ3QgdGhpbmsgdGhlIFVBUyBpcyBhbGxvd2Vk IHRvIHNlbmQgYW5vdGhlcg0KPnJlbGlhYmxlIHJlc3BvbnNlIHVudGlsIHRoZSBmaXJzdCBvbmUg aXMgYWNrbm93bGVkZ2VkLCBzbyBJIGRvbid0IHRoaW5rDQo+YSByZWxpYWJsZSAxOTkgd291bGQg cmVhY2ggdGhlIFVBQyBiZWZvcmUgdGhlIGZpcnN0IHJlbGlhYmxlIDE4eC4NCj4gDQo+W0VyaWNd OiBTdXJlbHkgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlciByZWxpYWJsZSByZXNw b25zZQ0KdW50aWwgdGhlIGZpcnN0IG9uZSBpcyBhY2tub3dsZWRnZWQsDQoNCklmIEkgcmVtZW1i ZXIgY29ycmVjdGx5LCB0aGUgRklSU1QgcmVsaWFibGUgcmVzcG9uc2UgbXVzdCBiZSBhY2tub3ds ZWRlZA0KYmVmb3JlIHRoZSBuZXh0IHJlbGlhYmxlIHJlc3BvbnNlIGlzIHNlbnQuIEJ1dCwgd2Ug Y2FuIGRvdWJsZSBjaGVjayBpbg0KdGhlIFBSQUNLIHNwZWMuDQoNCj5idXQgcmVsaWFibGUgMTk5 IHdpbGwgYmUgdXNlZnVsIGlmIHRoZSBmaXJzdCAxOHggaXMgdW5yZWxpYWJsZSwgb3IgdGhlDQpm aXJzdCAxOHggaGFzIGJlZW4gYWNrbndsZWRnZWQuIEl0J3MgYW5vdGhlciBjYXNlIGRpZmZlcmVu dCBmcm9tIHRoZQ0KYWJvdmUgb25lICB3aG9zZSBJTlZJVEUgY29udGFpbnMgInJlcXVpcmU6IDEw MHJlbCIuDQoNCklmIDEwMHJlbCBpcyByZXF1aXJlZCB0aGUgMTh4IGNhbm5vdCBiZSB1bnJlbGlh YmxlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KDQogDQoNCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5v dCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlv biB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4N Cg== --=_alternative 0006147F4825756A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIHRoZXJlIHN0aWxsIHR3byBxdWVz dGlvbnMgbGVmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjEuICZuYnNwO0lzIHRoZSAxOTkgc2hvdWxkIGJlIHJlbGlhYmxlDQpvciB1bnJlbGlhYmxl PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyBJIHRoaW5rIHRoYXQgMTk5IHNob3VsZA0KYmUgcmVsaWFibGUgaWYgcG9zc2libGUuPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7Rmlyc3QsIDwvZm9udD48Zm9udCBzaXplPTI+SWYNCmEgY2xpZW50IHJlY2VpdmVzIGFu IHVucmVsaWFibGUgMTk5IHJlc3BvbnNlIG9uIGEgZGlhbG9nIHdoaWNoIGhhczwvZm9udD4NCjxi cj48Zm9udCBzaXplPTI+Jm5ic3A7Jm5ic3A7IG5vdCBwcmV2aW91c2x5IGJlZW4gY3JlYXRlZCAo dGhpcyBjYW4gaGFwcGVuDQppZiBhIDE5OSByZXNwb25zZTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTI+Jm5ic3A7Jm5ic3A7IHJlYWNoZXMgdGhlIGNsaWVudCBiZWZvcmUgYSAxOHggcmVzcG9uc2Up DQp0aGUgY2xpZW50IFNIQUxMIGRpc2NhcmQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNw OyZuYnNwOyB0aGUgMTk5IHJlc3BvbnNlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y PiZuYnNwOyAmbmJzcDtUaGUgZmlndXJlIGJlbG93IHNob3dzIGFuIGV4YW1wbGUuVGhlIDE4MA0K aXMgc2VudCBmaXJzdCBidXQgYXJyaXZlcyBsYXRlciB0aGFuIDE5OS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yPklmIHRoZSAxOTkgaXMgcmVsaWFibGUsIHRoZSBwcm94eSBzaG91bGQgcmV0cmFu c21pdCAxOTkNCihzdGVwIDQpLGFuZCB0aGVuIHRoZSByZXRyYW5zbWl0dGVkPC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mj4xOTkgd2lsbCBiZSBhY2NlcHRlZCBieSBVQUMsYW5kIHRoZSBlYXJseSBk aWFsb2cgd2lsbA0KYmUgdGVtaW5hdGVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+ VUFDICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsxLiBJTlZJVEU8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yPi0tLS0tLS0tLS0tLS0tLSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMi4gMTgwPC9mb250Pg0KPGJyPjxmb250IHNp emU9Mj4mbHQ7LS0tLS0gXC8tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvXCAzLiAxOTk8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZsdDstLS0tLS8gJm5ic3A7XC0tLS0t LTwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA0LiAxOTkocmV0cmFuc21pdHRlZCk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZsdDst LS0tLS0tLS0tLS0tLS08L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJz cDtzZWNvbmQsIEFjY29yZGluZyB0byBwcmFjdGljYWwgdXNlLCAxOTkgY2FuDQpiZSBpbnRlbmRl ZCB0byB0ZW1pbmF0ZSBvbmUgZWFybHkgZGlhbG9nIGFuZCByZWxlYXNlIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+cmVzb3VyY2VzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3BlY2lmaWMgZWFybHkg ZGlhbG9nLCBzbw0KdGhlIGNvc3Qgc3BlbnQgb24gcmVsaWFibGUgMTk5IGlzIHdvcnRoeS48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPklmIHRoZSAxOTkgY2Fubm90IGJlIHNlbnQgcmVsaWFibGUs dGhlbiB3ZSBzaG91bGQgc2VuZA0KaXQgdW5yZWxpYWJsZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjIuIDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPkluIHlvdXIgbGFzdA0K bGV0dGVyLCB5b3Ugc2FpZCAmcXVvdDt0aGUgc2Vjb25kIDE5OSBjb3VsZCBpbmNsdWRlIGluZm9y bWF0aW9uIHdoaWNoIGlzDQp0byBiZSBmb3J3YXJkZWQgdG8gdGhlPGJyPg0KVUFDJnF1b3Q7LCB0 aGVuIGRvIHlvdSBtZWFuLCB0aGUgZWFybHkgZGlhbG9nIGlzIHN0aWxsIGFsaXZlIGFmdGVyIHRo ZQ0KZmlyc3QgMTk5IGlzIGFjY2VwdGVkPzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+QWxzbywgSW4gbXkgbGFzdCBsZXR0ZXIsIEkgbWlzcyBhICZxdW90O05P VCZxdW90Ow0KYnkgbWlzdGFrZS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5J dCBzaG91bGQgYmUgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bRXJpY106IFN1 cmVseSB0aGUgVUFTIGlzIDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9cmVkPk5P VDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTI+DQphbGxvd2VkIHRvIHNlbmQgYW5vdGhlciBy ZWxpYWJsZSByZXNwb25zZTxicj4NCnVudGlsIHRoZSBmaXJzdCBvbmUgaXMgYWNrbm93bGVkZ2Vk Li4uPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Fcmlj IHdhbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+JnF1b3Q7Q2hyaXN0ZXIgSG9sbWJlcmcmcXVvdDsNCiZsdDtjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wMi0yNyAwMzowNDwvZm9udD4NCjx0ZCB3aWR0aD03MyU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtFcmljIHdhbmcmcXVvdDsg Jmx0O2VyaWMud2FuZ3hyQGdtYWlsLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtzaXBA aWV0Zi5vcmcmZ3Q7LCAmbHQ7d2FuZy5saWJvQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SRTogUXVlc3Rpb25zIGFib3V0ICZxdW90O2RyYWZ0LWlldGYtc2lwLTE5OS0wNSZxdW90 OzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+SGksPGJyPg0KPGJyPg0KJmd0O0kgc3RpbGwgaGF2ZSBzb21lIGRpZmZpY3VsdCBpbiB1c2lu ZyBJRVRGIGFuZCBjYW5ub3QgZmluZCB0aGUgd2hvbGU8YnI+DQpzb3J0ZWQgY29tbWVudHMgYWJv dXQgdGhpcyBkcmFmdCwgc28gaSBoYXZlIHNvbWUgZG91YnQgYWJvdXQgdGhpcyBkcmFmdC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgMS4gJm5ic3A7ICZxdW90O0lmIGEgZm9ya2luZyBwcm94 eSByZWNlaXZlcyBhIHJlbGlhYmx5IHNlbnQNCjE5OSByZXNwb25zZSBmb3IgYTxicj4NCmRpYWxv ZywgZm9yIHdoaWNoIHRoZSBwcm94eSBoYXMgcHJldmlvdXNseSBnZW5lcmF0ZWQgYW5kIHNlbnQg YSAxOTk8YnI+DQpyZXNwb25zZSwgdGhlIHByb3h5IE1VU1QgZm9yd2FyZCB0aGUgMTk5IHJlc3Bv bnNlLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgRG9lcyBpdCBkZXNj cmliZSB0aGUgY2FzZSBiZWxvdz8gQWx0aG91Z2ggUDEgaGF2ZSBzZW50DQphIDE5OTxicj4NCnJl c3BvbnNlLCBQMSBoYXZzIHRvICZuYnNwO2ZvcndvcmQgdGhlIHNlbmQgcmVsaWFibHkgMTk5IHRv by5PciAmbmJzcDtpcw0KdGhlPGJyPg0KZmlyc3QgMTk5IG1pc3Rha2VkIGZvciAxOHg/PGJyPg0K Jmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1VBQyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFAxICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO1VB U18yPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0t LSBJTlZJVEUgLS0tLS0tJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLS0tIElOVklURSAobGVnIDIpIC0mZ3Q7PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDstLSAxOTkobGVnIDIpIC0tPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0g MTk5IChsZWcgMikgLS0tLS08YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmx0Oy0tIDE5OShsZWcgMikgLS08YnI+DQo8YnI+DQomZ3Q7SSB0aGluayBp dCBzaGFsbCBiZSAxOTksIGFzIGN1cnJlbnRseSB3cml0dGVuLjxicj4NCiZndDsgPGJyPg0KJmd0 O1tFcmljXTogSWYgJm5ic3A7dGhpcyBpcyAxOTksIHRoZW4gSXMgdGhlcmUgYSBzcGVjaWFsIHB1 cnBvc2UgdG8gc2VuZA0KdHdvPGJyPg0KMTk5IGluIHRoZSBzYW1lIGRpYWxvZz88YnI+DQomZ3Q7 SSB0aGluayB0aGF0IG9uZSAxOTkgaXMgZW5vdWdoLjxicj4NCiZndDtBbmQgJm5ic3A7dGhlIGZp cnN0IDE5OSBtYXkgYmUgcmVsaWFibGUgdG9vLCB0aGF0IHdpbGwgbWFrZSBpdCBhIGxpdHRsZTxi cj4NCmRpZmZpY3VsdCB0byBzZW5kIHRoZSBzZWNvbmQgMTk5Ljxicj4NCiA8YnI+DQpUaGUgc2Vj b25kIDE5OSBjb3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIHdoaWNoIGlzIHRvIGJlIGZvcndhcmRl ZCB0byB0aGU8YnI+DQpVQUMuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OzIuICZuYnNwOyZxdW90OzEw LiAmbmJzcDtVc2FnZSB3aXRoIDEwMHJlbDxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyBXaGVu IGEgMTk5IEVhcmx5IERpYWxvZyBUZXJtaW5hdGVkIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGlzDQpz ZW50IGJ5IGE8YnI+DQpVQVMsIHNpbmNlIHRoZSBwcm92aXNpb25hbCByZXNwb25zZSBpcyBvbmx5 IHVzZWQgZm9yIGluZm9ybWF0aW9uPGJyPg0KcHVycG9zZSwgdGhlIFVBUyBTSE9VTEQgc2VuZCBp dCB1bnJlbGlhYmx5IGV2ZW4gaWYgdGhlIDEwMHJlbDxicj4NCiZndDsgJm5ic3A7IG9wdGlvbiB0 YWcgW1JGQzMyNjJdIGlzIHByZXNlbnQgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIG9mIHRoZTxicj4N CmFzc29jaWF0ZWQgcmVxdWVzdC4mcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtJ IGhhdmUgc2VlbiBhIGNvbW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQgc3RpbGwgbm90IHVuZGVy c3Rvb2QgYWJvdXQ8YnI+DQomZ3Q7aXQuIElmIHRoZSBJTlZJVEUgaGFzIGEgUmVxdWlyZSB0YWcg JnF1b3Q7UmVxdWlyZTogMTAwcmVsJnF1b3Q7LGRvZXMNCnRoZSBVQVM8YnI+DQpzdGlsbDxicj4N CiZndDt1c2UgdW5yZWxpYWJsZSAxOTkgcmVzcG9uc2U/PGJyPg0KJmd0Ozxicj4NCiZndDtUaGF0 IGlzIHRoZSByZWNvbW1lbmRhdGlvbiwgeWVzLiBUaGUgcmVhc29ucyBpcyB0aGF0IHdlIHdhbnQg dG8ga2VlcDxicj4NCjE5OTxicj4NCiZndDthcyAmcXVvdDtsaWdodHdlaWdodCZxdW90OyBhcyBw b3NzaWJsZSwgd2l0aG91dCByZXF1aXJlaW5nIHJlLXRyYW5zbWlzc2lvbnMNCmFuZDxicj4NCiZn dDtQUkFDS3MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7W0VyaWNdOiBCdXQgcmVsaWFibGUgMTk5IGhh dmUgbW9yZSBhZHZhbnRhZ2UsIGFuZCBJdCBpcyB3b3J0aCB0byB1c2U8YnI+DQp0aGUgcmVsaWFi bGUgMTk5LEkgdGhpbmsuPGJyPg0KPGJyPg0KSSBkb24ndCBrbm93IHdoYXQgdGhhdCBhZHZhbnRh Z2Ugd291bGQgYmUsIGNvbXBhcmVkIHRvIGhhdmluZyB0byBzZW5kPGJyPg0KUFJBQ0tzIGV0Yy4g VGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgcXVpdGUgbXVjaCwgc28gSSB3b3VsZCByZWFsbHkgbmVl ZDxicj4NCnNvbWUgZ29vZCBqdXN0aWZpY2F0aW9uIHRvIGNoYW5nZSBpdCBub3cuPGJyPg0KPGJy Pg0KQWxzbywgdGhlIGRyYWZ0IGRvZXNuJ3QgZm9yYmlkIHlvdSB0byBzZW5kIHRoZSAxOTkgcmVs aWFibHkuIEl0J3Mgb25seQ0KYTxicj4NClNIT1VMRC48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7SWYg MTk5IGlzIHJlbGlhYmxlLCB0aGVyZSBpcyBvbmUgbW9yZSBhZHZhbnRhZ2UuIElmIHRoZSAxOTkg YXJyaXZlczxicj4NCiZndDtiZWZvcmUgdGhlIGZpcnN0IDE4eCByZXNwb25zZSwgVUFDIGNhbiBk aXNjYXJkIHRoZSBmaXJzdCAxOTkgYW5kPGJyPg0KcHJvY2Vzczxicj4NCiZndDtpdCB1bnRpbCBV QUMgcmVjZWl2ZXMgdGhlIGZpcnN0IDE4eCByZXNwb25zZSB0aGF0IGhhcyB0aGUgc2FtZTxicj4N CiZndDt0by10YWcgYXMgMTk5LCBhcyB0aGUgcmVsaWFibGUgMTk5IHNob3VsZCBiZSByZS10cmFu c21pdGVkIHVudGlsPGJyPg0KJmd0O3JlY2VpdmVkIFBSQUNLLjxicj4NCiZndDs8YnI+DQomZ3Q7 SWYgdGhlIElOVklURSBjb250YWlucyAmcXVvdDtSZXF1aXJlOiAxMDByZWwmcXVvdDssIHRoZSBm aXJzdCAxOHggbXVzdA0KYWxzbyBiZTxicj4NCiZndDtzZW50IHJlbGlhYmx5LiBBbmQsIEkgZG9u J3QgdGhpbmsgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlcjxicj4NCiZndDtyZWxp YWJsZSByZXNwb25zZSB1bnRpbCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZCwgc28gSSBk b24ndCB0aGluazxicj4NCiZndDthIHJlbGlhYmxlIDE5OSB3b3VsZCByZWFjaCB0aGUgVUFDIGJl Zm9yZSB0aGUgZmlyc3QgcmVsaWFibGUgMTh4Ljxicj4NCiZndDsgPGJyPg0KJmd0O1tFcmljXTog U3VyZWx5IHRoZSBVQVMgaXMgYWxsb3dlZCB0byBzZW5kIGFub3RoZXIgcmVsaWFibGUgcmVzcG9u c2U8YnI+DQp1bnRpbCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZCw8YnI+DQo8YnI+DQpJ ZiBJIHJlbWVtYmVyIGNvcnJlY3RseSwgdGhlIEZJUlNUIHJlbGlhYmxlIHJlc3BvbnNlIG11c3Qg YmUgYWNrbm93bGVkZWQ8YnI+DQpiZWZvcmUgdGhlIG5leHQgcmVsaWFibGUgcmVzcG9uc2UgaXMg c2VudC4gQnV0LCB3ZSBjYW4gZG91YmxlIGNoZWNrIGluPGJyPg0KdGhlIFBSQUNLIHNwZWMuPGJy Pg0KPGJyPg0KJmd0O2J1dCByZWxpYWJsZSAxOTkgd2lsbCBiZSB1c2VmdWwgaWYgdGhlIGZpcnN0 IDE4eCBpcyB1bnJlbGlhYmxlLCBvcg0KdGhlPGJyPg0KZmlyc3QgMTh4IGhhcyBiZWVuIGFja253 bGVkZ2VkLiBJdCdzIGFub3RoZXIgY2FzZSBkaWZmZXJlbnQgZnJvbSB0aGU8YnI+DQphYm92ZSBv bmUgJm5ic3A7d2hvc2UgSU5WSVRFIGNvbnRhaW5zICZxdW90O3JlcXVpcmU6IDEwMHJlbCZxdW90 Oy48YnI+DQo8YnI+DQpJZiAxMDByZWwgaXMgcmVxdWlyZWQgdGhlIDE4eCBjYW5ub3QgYmUgdW5y ZWxpYWJsZS48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KIDxicj4NCjwvZm9udD48L3R0 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 0006147F4825756A_=-- From pkyzivat@cisco.com Thu Feb 26 17:56:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9972E28C26A for ; Thu, 26 Feb 2009 17:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.196 X-Spam-Level: * X-Spam-Status: No, score=1.196 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INMvrkOmrfhk for ; Thu, 26 Feb 2009 17:56:09 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E48AE28C26F for ; Thu, 26 Feb 2009 17:56:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,273,1233532800"; d="scan'208";a="38617905" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2009 01:56:30 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1R1uUA4020884; Thu, 26 Feb 2009 20:56:30 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1R1uUr2012980; Fri, 27 Feb 2009 01:56:30 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 20:56:30 -0500 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 20:56:29 -0500 Message-ID: <49A7484B.3060407@cisco.com> Date: Thu, 26 Feb 2009 20:56:27 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: wang.libo@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Feb 2009 01:56:30.0003 (UTC) FILETIME=[9B90D030:01C9987E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7384; t=1235699790; x=1236563790; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20=3D?GB2312?B?tPC4tDogUkU6IFF1ZX N0aW9ucyBhYm91dCAiZHJhZnQt?=3D=0A=20=3D?GB2312?B?aWV0Zi1zaXA tMTk5LTA1Ig=3D=3D?=3D |Sender:=20 |To:=20wang.libo@zte.com.cn; bh=5BFmCjGz0rSCag4zW01VBARVOJfuTzMEJ5lI8E/L0tQ=; b=TyWDnlTr8TJvw9U/qE9bvpsYKItuUVIPsxjDvmnAygrk+k4NRDWa/j7i87 U91vXG0VuZOlLYMqF1wTdsG8rcvnkgvYgoIZzteLtL4tIAYkGIx0md1LPgmI mm9vo14X/M; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, Christer Holmberg Subject: Re: [Sip] =?gb2312?b?tPC4tDogUkU6IFF1ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0?= =?gb2312?b?Zi1zaXAtMTk5LTA1Ig==?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:56:15 -0000 *allowing* (much less *requiring*) the 199 to be reliable introduces nasty problems. The 199 is only an optimization, so having it be unreliable is ok IMO. The problem is that if a proxy sends the 199, then the recipient of the PRACK should be the proxy. But the PRACK is an in-dialog message, so it must be addressed to the Contact of the UAS. If the proxy sends a reliable 199, and the PRACK is addressed to the UAS, the UAS will be very surprised, since it has not send a reliable provisional, and is so not expecting a PRACK. In fact, it has sent a final response, has presumably already received the ACK, and so is expecting nothing. Very ugly. Paul wang.libo@zte.com.cn wrote: > > Hi, > > And there still two questions left. > > 1. Is the 199 should be reliable or unreliable? > I think that 199 should be reliable if possible. > > > First, If a client receives an unreliable 199 response on a dialog > which has > not previously been created (this can happen if a 199 response > reaches the client before a 18x response) the client SHALL discard > the 199 responses. > > The figure below shows an example.The 180 is sent first but arrives > later than 199. > If the 199 is reliable, the proxy should retransmit 199 (step 4),and > then the retransmitted > 199 will be accepted by UAC,and the early dialog will be teminated. > > UAC P > 1. INVITE > ---------------> > 2. 180 > <----- \/------- > /\ 3. 199 > <-----/ \------ > 4. 199(retransmitted) > <--------------- > > second, According to practical use, 199 can be intended to teminate > one early dialog and release > resources associated with the specific early dialog, so the cost spent > on reliable 199 is worthy. > If the 199 cannot be sent reliable,then we should send it unreliable. > > 2. In your last letter, you said "the second 199 could include > information which is to be forwarded to the > UAC", then do you mean, the early dialog is still alive after the first > 199 is accepted? > > > Also, In my last letter, I miss a "NOT" by mistake. > It should be > [Eric]: Surely the UAS is NOT allowed to send another reliable response > until the first one is acknowledged... > > Regards, > Eric wang > > > > > *"Christer Holmberg" * > > 2009-02-27 03:04 > > > ÊÕ¼þÈË > "Eric wang" > ³­ËÍ > , > Ö÷Ìâ > RE: Questions about "draft-ietf-sip-199-05" > > > > > > > > > Hi, > > >I still have some difficult in using IETF and cannot find the whole > sorted comments about this draft, so i have some doubt about this draft. > > > > 1. "If a forking proxy receives a reliably sent 199 response for a > dialog, for which the proxy has previously generated and sent a 199 > response, the proxy MUST forward the 199 response." > > > > Does it describe the case below? Although P1 have sent a 199 > response, P1 havs to forword the send reliably 199 too.Or is the > first 199 mistaked for 18x? > > > > UAC P1 UAS_2 > > --- INVITE ------> > > --- INVITE (leg 2) -> > > <-- 199(leg 2) -- > > <-- 199 (leg 2) ----- > > <-- 199(leg 2) -- > > >I think it shall be 199, as currently written. > > > >[Eric]: If this is 199, then Is there a special purpose to send two > 199 in the same dialog? > >I think that one 199 is enough. > >And the first 199 may be reliable too, that will make it a little > difficult to send the second 199. > > The second 199 could include information which is to be forwarded to the > UAC. > > > >2. "10. Usage with 100rel > > > > When a 199 Early Dialog Terminated provisional response is sent by a > UAS, since the provisional response is only used for information > purpose, the UAS SHOULD send it unreliably even if the 100rel > > option tag [RFC3262] is present in the Require header of the > associated request." > > > > > >I have seen a comment on this question,but still not understood about > >it. If the INVITE has a Require tag "Require: 100rel",does the UAS > still > >use unreliable 199 response? > > > >That is the recommendation, yes. The reasons is that we want to keep > 199 > >as "lightweight" as possible, without requireing re-transmissions and > >PRACKs. > > > >[Eric]: But reliable 199 have more advantage, and It is worth to use > the reliable 199,I think. > > I don't know what that advantage would be, compared to having to send > PRACKs etc. This has been discussed quite much, so I would really need > some good justification to change it now. > > Also, the draft doesn't forbid you to send the 199 reliably. It's only a > SHOULD. > > > >If 199 is reliable, there is one more advantage. If the 199 arrives > >before the first 18x response, UAC can discard the first 199 and > process > >it until UAC receives the first 18x response that has the same > >to-tag as 199, as the reliable 199 should be re-transmited until > >received PRACK. > > > >If the INVITE contains "Require: 100rel", the first 18x must also be > >sent reliably. And, I don't think the UAS is allowed to send another > >reliable response until the first one is acknowledged, so I don't think > >a reliable 199 would reach the UAC before the first reliable 18x. > > > >[Eric]: Surely the UAS is allowed to send another reliable response > until the first one is acknowledged, > > If I remember correctly, the FIRST reliable response must be acknowleded > before the next reliable response is sent. But, we can double check in > the PRACK spec. > > >but reliable 199 will be useful if the first 18x is unreliable, or the > first 18x has been acknwledged. It's another case different from the > above one whose INVITE contains "require: 100rel". > > If 100rel is required the 18x cannot be unreliable. > > Regards, > > Christer > > > > > > > > > > > -------------------------------------------------------- > 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From wang.libo@zte.com.cn Thu Feb 26 20:38:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD46528C282 for ; Thu, 26 Feb 2009 20:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.223 X-Spam-Level: X-Spam-Status: No, score=-90.223 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, 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 34nEbXO0MnJ0 for ; Thu, 26 Feb 2009 20:38:10 -0800 (PST) Received: from mail.zte.com.cn (mail2.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id E557C28C271 for ; Thu, 26 Feb 2009 20:38:06 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 33096.4528220857; Fri, 27 Feb 2009 12:59:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n1R4cWhj061363; Fri, 27 Feb 2009 12:38:32 +0800 (CST) (envelope-from wang.libo@zte.com.cn) In-Reply-To: <49A7484B.3060407@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 Message-ID: From: wang.libo@zte.com.cn Date: Fri, 27 Feb 2009 12:38:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-02-27 12:38:24, Serialize complete at 2009-02-27 12:38:24 Content-Type: multipart/alternative; boundary="=_alternative 00197C714825756A_=" X-MAIL: mse1.zte.com.cn n1R4cWhj061363 Cc: sip@ietf.org, Christer Holmberg Subject: [Sip] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiBSRTogUXVlc3Rpb25zIGFib3V0?= =?gb2312?b?ICJkcmFmdC1pZXRmLXNpcC0xOTktMDUi?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 04:38:12 -0000 This is a multipart message in MIME format. --=_alternative 00197C714825756A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQogDQogICBQcmFjdGljYWxseSwgd2hlbiBDYWxsIGZvcndhcmQgYW5kIGZvcmsgYXJlIHVz ZWQgaW4gdGhlIHNhbWUgc3lzdGVtLCANCnRoZXJlIGFyZSANCmxvdHMgb2YgZWFybHkgZGlhbG9n cyB0aGF0IHNob3VsZCBiZSBlbGltaW5hdGVkIGJ5IDE5OSBleGlzdGVkLg0KU28gSSB0aGluayB0 aGF0IGl0J3MgdXNlZnVsIHRvIGxldCAxOTkgcmVsaWFibGUuIA0KICAgQW5kIHdlIGp1c3QgYWRk ZWQgZm9yay1zZXJ2aWNlIHRvIG91ciBzeXN0ZW0gLGFuZCBmaW5kIDE5OSBpcyByZWFsbHkgDQp1 c2VmdWwsIGFuZA0KaWYgdGhlIDE5OSBpcyBtaXNzaW5nLCBwcm9ibGVtcyB3aWxsIGhhcHBlbi4N Cg0KDQogICBJdCBzb3VuZHMgZ29vZCB0aGF0IHRoZXJlIGlzIGEgd2F5IHRvIHByZXZlbnQgUFJB Q0sgYWRkcmVzc2VkIHRvIA0KVUFTLGJ1dCBpIGRvbid0IGtub3cNCmhvdyB0byBkbyBub3cuDQog DQpwczoNCiAgIFJGQzMyNjEgMTYuNyBSZXNwb25zZSBQcm9jZXNzaW5nIA0KICAgICAgICBTaW5j ZSBhIHByb3h5IG1heSBub3QgaW5zZXJ0IGEgdGFnIGludG8gdGhlIFRvIGhlYWRlciBmaWVsZCBv Zg0KICAgICAgICAgYSAxeHggcmVzcG9uc2UgdG8gYSByZXF1ZXN0IHRoYXQgZGlkIG5vdCBjb250 YWluIG9uZSwgaXQgY2Fubm90DQogICAgICAgICBpc3N1ZSBub24tMTAwIHByb3Zpc2lvbmFsIHJl c3BvbnNlcyBvbiBpdHMgb3duLg0KDQoNCkVyaWMNCg0KDQoNCg0KDQpQYXVsIEt5eml2YXQgPHBr eXppdmF0QGNpc2NvLmNvbT4gDQoyMDA5LTAyLTI3IDA5OjU2DQoNCsrVvP7Iyw0Kd2FuZy5saWJv QHp0ZS5jb20uY24NCrOty80NCkNocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+LCBzaXBAaWV0Zi5vcmcNCtb3zOINClJlOiBbU2lwXSC08Li0OiBSRTogUXVl c3Rpb25zIGFib3V0ICJkcmFmdC1pZXRmLXNpcC0xOTktMDUiDQoNCg0KDQoNCg0KDQoqYWxsb3dp bmcqIChtdWNoIGxlc3MgKnJlcXVpcmluZyopIHRoZSAxOTkgdG8gYmUgcmVsaWFibGUgaW50cm9k dWNlcw0KbmFzdHkgcHJvYmxlbXMuIFRoZSAxOTkgaXMgb25seSBhbiBvcHRpbWl6YXRpb24sIHNv IGhhdmluZyBpdCBiZQ0KdW5yZWxpYWJsZSBpcyBvayBJTU8uDQoNClRoZSBwcm9ibGVtIGlzIHRo YXQgaWYgYSBwcm94eSBzZW5kcyB0aGUgMTk5LCB0aGVuIHRoZSByZWNpcGllbnQgb2YgdGhlDQpQ UkFDSyBzaG91bGQgYmUgdGhlIHByb3h5LiBCdXQgdGhlIFBSQUNLIGlzIGFuIGluLWRpYWxvZyBt ZXNzYWdlLCBzbyBpdA0KbXVzdCBiZSBhZGRyZXNzZWQgdG8gdGhlIENvbnRhY3Qgb2YgdGhlIFVB Uy4NCg0KSWYgdGhlIHByb3h5IHNlbmRzIGEgcmVsaWFibGUgMTk5LCBhbmQgdGhlIFBSQUNLIGlz IGFkZHJlc3NlZCB0byB0aGUNClVBUywgdGhlIFVBUyB3aWxsIGJlIHZlcnkgc3VycHJpc2VkLCBz aW5jZSBpdCBoYXMgbm90IHNlbmQgYSByZWxpYWJsZQ0KcHJvdmlzaW9uYWwsIGFuZCBpcyBzbyBu b3QgZXhwZWN0aW5nIGEgUFJBQ0suIEluIGZhY3QsIGl0IGhhcyBzZW50IGENCmZpbmFsIHJlc3Bv bnNlLCBoYXMgcHJlc3VtYWJseSBhbHJlYWR5IHJlY2VpdmVkIHRoZSBBQ0ssIGFuZCBzbyBpcw0K ZXhwZWN0aW5nIG5vdGhpbmcuDQoNClZlcnkgdWdseS4NCg0KICAgICAgICAgICAgICAgICBQYXVs DQoNCndhbmcubGlib0B6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPiBBbmQgdGhl cmUgc3RpbGwgdHdvIHF1ZXN0aW9ucyBsZWZ0Lg0KPiANCj4gMS4gIElzIHRoZSAxOTkgc2hvdWxk IGJlIHJlbGlhYmxlIG9yIHVucmVsaWFibGU/DQo+ICAgICBJIHRoaW5rIHRoYXQgMTk5IHNob3Vs ZCBiZSByZWxpYWJsZSBpZiBwb3NzaWJsZS4NCj4gDQo+IA0KPiAgICBGaXJzdCwgSWYgYSBjbGll bnQgcmVjZWl2ZXMgYW4gdW5yZWxpYWJsZSAxOTkgcmVzcG9uc2Ugb24gYSBkaWFsb2cgDQo+IHdo aWNoIGhhcw0KPiAgICBub3QgcHJldmlvdXNseSBiZWVuIGNyZWF0ZWQgKHRoaXMgY2FuIGhhcHBl biBpZiBhIDE5OSByZXNwb25zZQ0KPiAgICByZWFjaGVzIHRoZSBjbGllbnQgYmVmb3JlIGEgMTh4 IHJlc3BvbnNlKSB0aGUgY2xpZW50IFNIQUxMIGRpc2NhcmQNCj4gICAgdGhlIDE5OSByZXNwb25z ZXMuDQo+IA0KPiAgICBUaGUgZmlndXJlIGJlbG93IHNob3dzIGFuIGV4YW1wbGUuVGhlIDE4MCBp cyBzZW50IGZpcnN0IGJ1dCBhcnJpdmVzIA0KPiBsYXRlciB0aGFuIDE5OS4NCj4gSWYgdGhlIDE5 OSBpcyByZWxpYWJsZSwgdGhlIHByb3h5IHNob3VsZCByZXRyYW5zbWl0IDE5OSAoc3RlcCA0KSxh bmQgDQo+IHRoZW4gdGhlIHJldHJhbnNtaXR0ZWQNCj4gMTk5IHdpbGwgYmUgYWNjZXB0ZWQgYnkg VUFDLGFuZCB0aGUgZWFybHkgZGlhbG9nIHdpbGwgYmUgdGVtaW5hdGVkLg0KPiANCj4gVUFDICAg ICAgICAgICAgIFANCj4gICAgMS4gSU5WSVRFDQo+IC0tLS0tLS0tLS0tLS0tLT4NCj4gICAgICAg ICAgIDIuIDE4MA0KPiA8LS0tLS0gXC8tLS0tLS0tDQo+ICAgICAgICAvXCAzLiAxOTkNCj4gPC0t LS0tLyAgXC0tLS0tLQ0KPiAgICAgICAgICAgNC4gMTk5KHJldHJhbnNtaXR0ZWQpDQo+IDwtLS0t LS0tLS0tLS0tLS0NCj4gDQo+ICAgIHNlY29uZCwgQWNjb3JkaW5nIHRvIHByYWN0aWNhbCB1c2Us IDE5OSBjYW4gYmUgaW50ZW5kZWQgdG8gdGVtaW5hdGUgDQo+IG9uZSBlYXJseSBkaWFsb2cgYW5k IHJlbGVhc2UNCj4gcmVzb3VyY2VzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3BlY2lmaWMgZWFybHkg ZGlhbG9nLCBzbyB0aGUgY29zdCBzcGVudCANCj4gb24gcmVsaWFibGUgMTk5IGlzIHdvcnRoeS4N Cj4gSWYgdGhlIDE5OSBjYW5ub3QgYmUgc2VudCByZWxpYWJsZSx0aGVuIHdlIHNob3VsZCBzZW5k IGl0IHVucmVsaWFibGUuDQo+IA0KPiAyLiBJbiB5b3VyIGxhc3QgbGV0dGVyLCB5b3Ugc2FpZCAi dGhlIHNlY29uZCAxOTkgY291bGQgaW5jbHVkZSANCj4gaW5mb3JtYXRpb24gd2hpY2ggaXMgdG8g YmUgZm9yd2FyZGVkIHRvIHRoZQ0KPiBVQUMiLCB0aGVuIGRvIHlvdSBtZWFuLCB0aGUgZWFybHkg ZGlhbG9nIGlzIHN0aWxsIGFsaXZlIGFmdGVyIHRoZSBmaXJzdCANCj4gMTk5IGlzIGFjY2VwdGVk Pw0KPiANCj4gDQo+IEFsc28sIEluIG15IGxhc3QgbGV0dGVyLCBJIG1pc3MgYSAiTk9UIiBieSBt aXN0YWtlLg0KPiBJdCBzaG91bGQgYmUNCj4gW0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBpcyBOT1Qg YWxsb3dlZCB0byBzZW5kIGFub3RoZXIgcmVsaWFibGUgcmVzcG9uc2UNCj4gdW50aWwgdGhlIGZp cnN0IG9uZSBpcyBhY2tub3dsZWRnZWQuLi4NCj4gDQo+IFJlZ2FyZHMsDQo+IEVyaWMgd2FuZw0K PiANCj4gDQo+IA0KPiANCj4gKiJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4qDQo+IA0KPiAyMDA5LTAyLTI3IDAzOjA0DQo+IA0KPiANCj4gytW8/sjL DQo+ICAgICAgICAgICAgICAgICJFcmljIHdhbmciIDxlcmljLndhbmd4ckBnbWFpbC5jb20+DQo+ ILOty80NCj4gICAgICAgICAgICAgICAgPHNpcEBpZXRmLm9yZz4sIDx3YW5nLmxpYm9AenRlLmNv bS5jbj4NCj4g1vfM4g0KPiAgICAgICAgICAgICAgICBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFm dC1pZXRmLXNpcC0xOTktMDUiDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gSGks DQo+IA0KPiAgPkkgc3RpbGwgaGF2ZSBzb21lIGRpZmZpY3VsdCBpbiB1c2luZyBJRVRGIGFuZCBj YW5ub3QgZmluZCB0aGUgd2hvbGUNCj4gc29ydGVkIGNvbW1lbnRzIGFib3V0IHRoaXMgZHJhZnQs IHNvIGkgaGF2ZSBzb21lIGRvdWJ0IGFib3V0IHRoaXMgZHJhZnQuDQo+ICA+DQo+ICA+ICAgMS4g ICAiSWYgYSBmb3JraW5nIHByb3h5IHJlY2VpdmVzIGEgcmVsaWFibHkgc2VudCAxOTkgcmVzcG9u c2UgZm9yIA0KYQ0KPiBkaWFsb2csIGZvciB3aGljaCB0aGUgcHJveHkgaGFzIHByZXZpb3VzbHkg Z2VuZXJhdGVkIGFuZCBzZW50IGEgMTk5DQo+IHJlc3BvbnNlLCB0aGUgcHJveHkgTVVTVCBmb3J3 YXJkIHRoZSAxOTkgcmVzcG9uc2UuIg0KPiAgPg0KPiAgPiAgICAgRG9lcyBpdCBkZXNjcmliZSB0 aGUgY2FzZSBiZWxvdz8gQWx0aG91Z2ggUDEgaGF2ZSBzZW50IGEgMTk5DQo+IHJlc3BvbnNlLCBQ MSBoYXZzIHRvICBmb3J3b3JkIHRoZSBzZW5kIHJlbGlhYmx5IDE5OSB0b28uT3IgIGlzIHRoZQ0K PiBmaXJzdCAxOTkgbWlzdGFrZWQgZm9yIDE4eD8NCj4gID4NCj4gID4gICAgICAgICAgVUFDICAg ICAgICAgICAgICAgUDEgICAgICAgICAgICAgICAgICBVQVNfMg0KPiAgPiAgICAgICAgICAgIC0t LSBJTlZJVEUgLS0tLS0tPg0KPiAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tIElO VklURSAobGVnIDIpIC0+DQo+ICA+ICAgICAgICAgICAgPC0tIDE5OShsZWcgMikgLS0NCj4gID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLSAxOTkgKGxlZyAyKSAtLS0tLQ0KPiAgPiAg ICAgICAgICAgIDwtLSAxOTkobGVnIDIpIC0tDQo+IA0KPiAgPkkgdGhpbmsgaXQgc2hhbGwgYmUg MTk5LCBhcyBjdXJyZW50bHkgd3JpdHRlbi4NCj4gID4NCj4gID5bRXJpY106IElmICB0aGlzIGlz IDE5OSwgdGhlbiBJcyB0aGVyZSBhIHNwZWNpYWwgcHVycG9zZSB0byBzZW5kIHR3bw0KPiAxOTkg aW4gdGhlIHNhbWUgZGlhbG9nPw0KPiAgPkkgdGhpbmsgdGhhdCBvbmUgMTk5IGlzIGVub3VnaC4N Cj4gID5BbmQgIHRoZSBmaXJzdCAxOTkgbWF5IGJlIHJlbGlhYmxlIHRvbywgdGhhdCB3aWxsIG1h a2UgaXQgYSBsaXR0bGUNCj4gZGlmZmljdWx0IHRvIHNlbmQgdGhlIHNlY29uZCAxOTkuDQo+IA0K PiBUaGUgc2Vjb25kIDE5OSBjb3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIHdoaWNoIGlzIHRvIGJl IGZvcndhcmRlZCB0byB0aGUNCj4gVUFDLg0KPiANCj4gDQo+ICA+Mi4gICIxMC4gIFVzYWdlIHdp dGggMTAwcmVsDQo+ICA+DQo+ICA+ICAgV2hlbiBhIDE5OSBFYXJseSBEaWFsb2cgVGVybWluYXRl ZCBwcm92aXNpb25hbCByZXNwb25zZSBpcyBzZW50IGJ5IA0KYQ0KPiBVQVMsIHNpbmNlIHRoZSBw cm92aXNpb25hbCByZXNwb25zZSBpcyBvbmx5IHVzZWQgZm9yIGluZm9ybWF0aW9uDQo+IHB1cnBv c2UsIHRoZSBVQVMgU0hPVUxEIHNlbmQgaXQgdW5yZWxpYWJseSBldmVuIGlmIHRoZSAxMDByZWwN Cj4gID4gICBvcHRpb24gdGFnIFtSRkMzMjYyXSBpcyBwcmVzZW50IGluIHRoZSBSZXF1aXJlIGhl YWRlciBvZiB0aGUNCj4gYXNzb2NpYXRlZCByZXF1ZXN0LiINCj4gID4NCj4gID4NCj4gID5JIGhh dmUgc2VlbiBhIGNvbW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQgc3RpbGwgbm90IHVuZGVyc3Rv b2QgYWJvdXQNCj4gID5pdC4gSWYgdGhlIElOVklURSBoYXMgYSBSZXF1aXJlIHRhZyAiUmVxdWly ZTogMTAwcmVsIixkb2VzIHRoZSBVQVMNCj4gc3RpbGwNCj4gID51c2UgdW5yZWxpYWJsZSAxOTkg cmVzcG9uc2U/DQo+ICA+DQo+ICA+VGhhdCBpcyB0aGUgcmVjb21tZW5kYXRpb24sIHllcy4gVGhl IHJlYXNvbnMgaXMgdGhhdCB3ZSB3YW50IHRvIGtlZXANCj4gMTk5DQo+ICA+YXMgImxpZ2h0d2Vp Z2h0IiBhcyBwb3NzaWJsZSwgd2l0aG91dCByZXF1aXJlaW5nIHJlLXRyYW5zbWlzc2lvbnMgYW5k DQo+ICA+UFJBQ0tzLg0KPiAgPg0KPiAgPltFcmljXTogQnV0IHJlbGlhYmxlIDE5OSBoYXZlIG1v cmUgYWR2YW50YWdlLCBhbmQgSXQgaXMgd29ydGggdG8gdXNlDQo+IHRoZSByZWxpYWJsZSAxOTks SSB0aGluay4NCj4gDQo+IEkgZG9uJ3Qga25vdyB3aGF0IHRoYXQgYWR2YW50YWdlIHdvdWxkIGJl LCBjb21wYXJlZCB0byBoYXZpbmcgdG8gc2VuZA0KPiBQUkFDS3MgZXRjLiBUaGlzIGhhcyBiZWVu IGRpc2N1c3NlZCBxdWl0ZSBtdWNoLCBzbyBJIHdvdWxkIHJlYWxseSBuZWVkDQo+IHNvbWUgZ29v ZCBqdXN0aWZpY2F0aW9uIHRvIGNoYW5nZSBpdCBub3cuDQo+IA0KPiBBbHNvLCB0aGUgZHJhZnQg ZG9lc24ndCBmb3JiaWQgeW91IHRvIHNlbmQgdGhlIDE5OSByZWxpYWJseS4gSXQncyBvbmx5IGEN Cj4gU0hPVUxELg0KPiANCj4gDQo+ICA+SWYgMTk5IGlzIHJlbGlhYmxlLCB0aGVyZSBpcyBvbmUg bW9yZSBhZHZhbnRhZ2UuIElmIHRoZSAxOTkgYXJyaXZlcw0KPiAgPmJlZm9yZSB0aGUgZmlyc3Qg MTh4IHJlc3BvbnNlLCBVQUMgY2FuIGRpc2NhcmQgdGhlIGZpcnN0IDE5OSBhbmQNCj4gcHJvY2Vz cw0KPiAgPml0IHVudGlsIFVBQyByZWNlaXZlcyB0aGUgZmlyc3QgMTh4IHJlc3BvbnNlIHRoYXQg aGFzIHRoZSBzYW1lDQo+ICA+dG8tdGFnIGFzIDE5OSwgYXMgdGhlIHJlbGlhYmxlIDE5OSBzaG91 bGQgYmUgcmUtdHJhbnNtaXRlZCB1bnRpbA0KPiAgPnJlY2VpdmVkIFBSQUNLLg0KPiAgPg0KPiAg PklmIHRoZSBJTlZJVEUgY29udGFpbnMgIlJlcXVpcmU6IDEwMHJlbCIsIHRoZSBmaXJzdCAxOHgg bXVzdCBhbHNvIGJlDQo+ICA+c2VudCByZWxpYWJseS4gQW5kLCBJIGRvbid0IHRoaW5rIHRoZSBV QVMgaXMgYWxsb3dlZCB0byBzZW5kIGFub3RoZXINCj4gID5yZWxpYWJsZSByZXNwb25zZSB1bnRp bCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZCwgc28gSSBkb24ndCANCnRoaW5rDQo+ICA+ YSByZWxpYWJsZSAxOTkgd291bGQgcmVhY2ggdGhlIFVBQyBiZWZvcmUgdGhlIGZpcnN0IHJlbGlh YmxlIDE4eC4NCj4gID4NCj4gID5bRXJpY106IFN1cmVseSB0aGUgVUFTIGlzIGFsbG93ZWQgdG8g c2VuZCBhbm90aGVyIHJlbGlhYmxlIHJlc3BvbnNlDQo+IHVudGlsIHRoZSBmaXJzdCBvbmUgaXMg YWNrbm93bGVkZ2VkLA0KPiANCj4gSWYgSSByZW1lbWJlciBjb3JyZWN0bHksIHRoZSBGSVJTVCBy ZWxpYWJsZSByZXNwb25zZSBtdXN0IGJlIGFja25vd2xlZGVkDQo+IGJlZm9yZSB0aGUgbmV4dCBy ZWxpYWJsZSByZXNwb25zZSBpcyBzZW50LiBCdXQsIHdlIGNhbiBkb3VibGUgY2hlY2sgaW4NCj4g dGhlIFBSQUNLIHNwZWMuDQo+IA0KPiAgPmJ1dCByZWxpYWJsZSAxOTkgd2lsbCBiZSB1c2VmdWwg aWYgdGhlIGZpcnN0IDE4eCBpcyB1bnJlbGlhYmxlLCBvciB0aGUNCj4gZmlyc3QgMTh4IGhhcyBi ZWVuIGFja253bGVkZ2VkLiBJdCdzIGFub3RoZXIgY2FzZSBkaWZmZXJlbnQgZnJvbSB0aGUNCj4g YWJvdmUgb25lICB3aG9zZSBJTlZJVEUgY29udGFpbnMgInJlcXVpcmU6IDEwMHJlbCIuDQo+IA0K PiBJZiAxMDByZWwgaXMgcmVxdWlyZWQgdGhlIDE4eCBjYW5ub3QgYmUgdW5yZWxpYWJsZS4NCj4g DQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgDQppcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gDQppcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQo+IFRoaXMgZW1haWwgYW5k IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIHRoZXkgYXJlIA0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIA0Kb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIA0Kb2YgdGhlIGlu ZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KPiANCj4gDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXANCj4gVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhl IGNvcmUgU0lQIFByb3RvY29sDQo+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVk dSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQo+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZv ciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90 IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9u IHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2lu YXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2Ug YXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00197C714825756A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1ByYWN0aWNhbGx5LCB3aGVuIENhbGwN CmZvcndhcmQgYW5kIGZvcmsgYXJlIHVzZWQgaW4gdGhlIHNhbWUgc3lzdGVtLCB0aGVyZSBhcmUg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5sb3RzIG9mIGVhcmx5 IGRpYWxvZ3MgdGhhdCBzaG91bGQgYmUNCmVsaW1pbmF0ZWQgYnkgMTk5IGV4aXN0ZWQuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TbyBJIHRoaW5rIHRoYXQgaXQn cyB1c2VmdWwgdG8gbGV0IDE5OQ0KcmVsaWFibGUuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0FuZCB3ZSBqdXN0IGFkZGVkIGZvcmstc2Vy dmljZQ0KdG8gb3VyIHN5c3RlbSAsYW5kIGZpbmQgMTk5IGlzIHJlYWxseSB1c2VmdWwsIGFuZDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aWYgdGhlIDE5OSBpcyBt aXNzaW5nLCBwcm9ibGVtcyB3aWxsDQpoYXBwZW4uPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7SXQgc291bmRzIGdvb2Qg dGhhdCB0aGVyZQ0KaXMgYSB3YXkgdG8gcHJldmVudCBQUkFDSyBhZGRyZXNzZWQgdG8gVUFTLGJ1 dCBpIGRvbid0IGtub3c8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PmhvdyB0byBkbyBub3cuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5wczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDtSRkMzMjYxIDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwMjA0MSBmYWNlPSJDb3Vy aWVyIE5ldyI+PGI+MTYuNw0KUmVzcG9uc2UgUHJvY2Vzc2luZzwvYj48L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTaW5jZSBhDQpwcm94eSBtYXkg bm90IGluc2VydCBhIHRhZyBpbnRvIHRoZSBUbyBoZWFkZXIgZmllbGQgb2Y8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDthDQoxeHggcmVzcG9uc2UgdG8gYSByZXF1ZXN0IHRoYXQgZGlkIG5vdCBjb250YWlu IG9uZSwgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPml0 DQpjYW5ub3Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtpc3N1ZSBub24tMTAwIHBy b3Zpc2lvbmFsIHJlc3BvbnNlcyBvbiBpdHMgb3duLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RXJpYzwvZm9udD4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5QYXVsIEt5eml2YXQg Jmx0O3BreXppdmF0QGNpc2NvLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wMi0yNyAwOTo1NjwvZm9udD4NCjx0ZCB3aWR0aD03MyU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj53YW5nLmxpYm9AenRlLmNvbS5jbjwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSZndDssDQpzaXBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3 zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBb U2lwXSC08Li0OiBSRTogUXVlc3Rpb25zIGFib3V0DQomcXVvdDtkcmFmdC1pZXRmLXNpcC0xOTkt MDUmcXVvdDs8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiphbGxvd2luZyogKG11Y2ggbGVzcyAqcmVxdWlyaW5nKikgdGhlIDE5OSB0byBi ZSByZWxpYWJsZQ0KaW50cm9kdWNlczxicj4NCm5hc3R5IHByb2JsZW1zLiBUaGUgMTk5IGlzIG9u bHkgYW4gb3B0aW1pemF0aW9uLCBzbyBoYXZpbmcgaXQgYmU8YnI+DQp1bnJlbGlhYmxlIGlzIG9r IElNTy48YnI+DQo8YnI+DQpUaGUgcHJvYmxlbSBpcyB0aGF0IGlmIGEgcHJveHkgc2VuZHMgdGhl IDE5OSwgdGhlbiB0aGUgcmVjaXBpZW50IG9mIHRoZTxicj4NClBSQUNLIHNob3VsZCBiZSB0aGUg cHJveHkuIEJ1dCB0aGUgUFJBQ0sgaXMgYW4gaW4tZGlhbG9nIG1lc3NhZ2UsIHNvIGl0PGJyPg0K bXVzdCBiZSBhZGRyZXNzZWQgdG8gdGhlIENvbnRhY3Qgb2YgdGhlIFVBUy48YnI+DQo8YnI+DQpJ ZiB0aGUgcHJveHkgc2VuZHMgYSByZWxpYWJsZSAxOTksIGFuZCB0aGUgUFJBQ0sgaXMgYWRkcmVz c2VkIHRvIHRoZTxicj4NClVBUywgdGhlIFVBUyB3aWxsIGJlIHZlcnkgc3VycHJpc2VkLCBzaW5j ZSBpdCBoYXMgbm90IHNlbmQgYSByZWxpYWJsZTxicj4NCnByb3Zpc2lvbmFsLCBhbmQgaXMgc28g bm90IGV4cGVjdGluZyBhIFBSQUNLLiBJbiBmYWN0LCBpdCBoYXMgc2VudCBhPGJyPg0KZmluYWwg cmVzcG9uc2UsIGhhcyBwcmVzdW1hYmx5IGFscmVhZHkgcmVjZWl2ZWQgdGhlIEFDSywgYW5kIHNv IGlzPGJyPg0KZXhwZWN0aW5nIG5vdGhpbmcuPGJyPg0KPGJyPg0KVmVyeSB1Z2x5Ljxicj4NCjxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQpQYXVsPGJyPg0KPGJyPg0Kd2FuZy5saWJvQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbmQgdGhlcmUgc3RpbGwgdHdv IHF1ZXN0aW9ucyBsZWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAxLiAmbmJzcDtJcyB0aGUgMTk5 IHNob3VsZCBiZSByZWxpYWJsZSBvciB1bnJlbGlhYmxlPzxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyBJIHRoaW5rIHRoYXQgMTk5IHNob3VsZCBiZSByZWxpYWJsZSBpZiBwb3NzaWJsZS48YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Rmlyc3QsIElmIGEgY2xpZW50 IHJlY2VpdmVzIGFuIHVucmVsaWFibGUgMTk5IHJlc3BvbnNlDQpvbiBhIGRpYWxvZyA8YnI+DQom Z3Q7IHdoaWNoIGhhczxicj4NCiZndDsgJm5ic3A7ICZuYnNwO25vdCBwcmV2aW91c2x5IGJlZW4g Y3JlYXRlZCAodGhpcyBjYW4gaGFwcGVuIGlmIGEgMTk5DQpyZXNwb25zZTxicj4NCiZndDsgJm5i c3A7ICZuYnNwO3JlYWNoZXMgdGhlIGNsaWVudCBiZWZvcmUgYSAxOHggcmVzcG9uc2UpIHRoZSBj bGllbnQNClNIQUxMIGRpc2NhcmQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0aGUgMTk5IHJlc3Bv bnNlcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1RoZSBmaWd1cmUgYmVsb3cg c2hvd3MgYW4gZXhhbXBsZS5UaGUgMTgwIGlzIHNlbnQgZmlyc3QNCmJ1dCBhcnJpdmVzIDxicj4N CiZndDsgbGF0ZXIgdGhhbiAxOTkuPGJyPg0KJmd0OyBJZiB0aGUgMTk5IGlzIHJlbGlhYmxlLCB0 aGUgcHJveHkgc2hvdWxkIHJldHJhbnNtaXQgMTk5IChzdGVwIDQpLGFuZA0KPGJyPg0KJmd0OyB0 aGVuIHRoZSByZXRyYW5zbWl0dGVkPGJyPg0KJmd0OyAxOTkgd2lsbCBiZSBhY2NlcHRlZCBieSBV QUMsYW5kIHRoZSBlYXJseSBkaWFsb2cgd2lsbCBiZSB0ZW1pbmF0ZWQuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFVBQyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7MS4gSU5WSVRFPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0m Z3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIuIDE4MDxi cj4NCiZndDsgJmx0Oy0tLS0tIFwvLS0tLS0tLTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7L1wgMy4gMTk5PGJyPg0KJmd0OyAmbHQ7LS0tLS0vICZuYnNwO1wtLS0tLS08YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNC4gMTk5KHJldHJhbnNt aXR0ZWQpPGJyPg0KJmd0OyAmbHQ7LS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDtzZWNvbmQsIEFjY29yZGluZyB0byBwcmFjdGljYWwgdXNlLCAxOTkgY2Fu IGJlIGludGVuZGVkDQp0byB0ZW1pbmF0ZSA8YnI+DQomZ3Q7IG9uZSBlYXJseSBkaWFsb2cgYW5k IHJlbGVhc2U8YnI+DQomZ3Q7IHJlc291cmNlcyBhc3NvY2lhdGVkIHdpdGggdGhlIHNwZWNpZmlj IGVhcmx5IGRpYWxvZywgc28gdGhlIGNvc3Qgc3BlbnQNCjxicj4NCiZndDsgb24gcmVsaWFibGUg MTk5IGlzIHdvcnRoeS48YnI+DQomZ3Q7IElmIHRoZSAxOTkgY2Fubm90IGJlIHNlbnQgcmVsaWFi bGUsdGhlbiB3ZSBzaG91bGQgc2VuZCBpdCB1bnJlbGlhYmxlLjxicj4NCiZndDsgJm5ic3A7PGJy Pg0KJmd0OyAyLiBJbiB5b3VyIGxhc3QgbGV0dGVyLCB5b3Ugc2FpZCAmcXVvdDt0aGUgc2Vjb25k IDE5OSBjb3VsZCBpbmNsdWRlDQo8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIHdoaWNoIGlzIHRvIGJl IGZvcndhcmRlZCB0byB0aGU8YnI+DQomZ3Q7IFVBQyZxdW90OywgdGhlbiBkbyB5b3UgbWVhbiwg dGhlIGVhcmx5IGRpYWxvZyBpcyBzdGlsbCBhbGl2ZSBhZnRlcg0KdGhlIGZpcnN0IDxicj4NCiZn dDsgMTk5IGlzIGFjY2VwdGVkPzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsc28s IEluIG15IGxhc3QgbGV0dGVyLCBJIG1pc3MgYSAmcXVvdDtOT1QmcXVvdDsgYnkgbWlzdGFrZS48 YnI+DQomZ3Q7IEl0IHNob3VsZCBiZTxicj4NCiZndDsgW0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBp cyBOT1QgYWxsb3dlZCB0byBzZW5kIGFub3RoZXIgcmVsaWFibGUgcmVzcG9uc2U8YnI+DQomZ3Q7 IHVudGlsIHRoZSBmaXJzdCBvbmUgaXMgYWNrbm93bGVkZ2VkLi4uPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBFcmljIHdhbmc8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKiZxdW90O0NocmlzdGVyIEhvbG1iZXJnJnF1 b3Q7ICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7Kjxicj4NCiZndDsgPGJy Pg0KJmd0OyAyMDA5LTAyLTI3IDAzOjA0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0K Jmd0OyDK1bz+yMs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7RXJpYw0Kd2FuZyZxdW90OyAmbHQ7ZXJp Yy53YW5neHJAZ21haWwuY29tJmd0Ozxicj4NCiZndDsgs63LzTxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 c2lwQGlldGYub3JnJmd0OywNCiZsdDt3YW5nLmxpYm9AenRlLmNvbS5jbiZndDs8YnI+DQomZ3Q7 INb3zOI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkU6DQpRdWVzdGlvbnMgYWJvdXQgJnF1b3Q7ZHJhZnQtaWV0 Zi1zaXAtMTk5LTA1JnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBIaSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7Jmd0O0kgc3RpbGwgaGF2ZSBz b21lIGRpZmZpY3VsdCBpbiB1c2luZyBJRVRGIGFuZCBjYW5ub3QgZmluZA0KdGhlIHdob2xlPGJy Pg0KJmd0OyBzb3J0ZWQgY29tbWVudHMgYWJvdXQgdGhpcyBkcmFmdCwgc28gaSBoYXZlIHNvbWUg ZG91YnQgYWJvdXQgdGhpcw0KZHJhZnQuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAm bmJzcDsmZ3Q7ICZuYnNwOyAxLiAmbmJzcDsgJnF1b3Q7SWYgYSBmb3JraW5nIHByb3h5IHJlY2Vp dmVzIGEgcmVsaWFibHkNCnNlbnQgMTk5IHJlc3BvbnNlIGZvciBhPGJyPg0KJmd0OyBkaWFsb2cs IGZvciB3aGljaCB0aGUgcHJveHkgaGFzIHByZXZpb3VzbHkgZ2VuZXJhdGVkIGFuZCBzZW50IGEg MTk5PGJyPg0KJmd0OyByZXNwb25zZSwgdGhlIHByb3h5IE1VU1QgZm9yd2FyZCB0aGUgMTk5IHJl c3BvbnNlLiZxdW90Ozxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyAm bmJzcDsgJm5ic3A7IERvZXMgaXQgZGVzY3JpYmUgdGhlIGNhc2UgYmVsb3c/IEFsdGhvdWdoDQpQ MSBoYXZlIHNlbnQgYSAxOTk8YnI+DQomZ3Q7IHJlc3BvbnNlLCBQMSBoYXZzIHRvICZuYnNwO2Zv cndvcmQgdGhlIHNlbmQgcmVsaWFibHkgMTk5IHRvby5PciAmbmJzcDtpcw0KdGhlPGJyPg0KJmd0 OyBmaXJzdCAxOTkgbWlzdGFrZWQgZm9yIDE4eD88YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQom Z3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1VBQyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFAxICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO1VB U18yPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7LS0tIElOVklURSAtLS0tLS0mZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tLSBJTlZJVEUgKGxlZyAyKSAt Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZsdDstLSAxOTkobGVnDQoyKSAtLTxicj4NCiZndDsgJm5ic3A7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0gMTk5IChsZWcgMikg LS0tLS08YnI+DQomZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7LS0gMTk5KGxlZw0KMikgLS08YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5i c3A7Jmd0O0kgdGhpbmsgaXQgc2hhbGwgYmUgMTk5LCBhcyBjdXJyZW50bHkgd3JpdHRlbi48YnI+ DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDtbRXJpY106IElmICZuYnNwO3Ro aXMgaXMgMTk5LCB0aGVuIElzIHRoZXJlIGEgc3BlY2lhbCBwdXJwb3NlDQp0byBzZW5kIHR3bzxi cj4NCiZndDsgMTk5IGluIHRoZSBzYW1lIGRpYWxvZz88YnI+DQomZ3Q7ICZuYnNwOyZndDtJIHRo aW5rIHRoYXQgb25lIDE5OSBpcyBlbm91Z2guPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7QW5kICZuYnNw O3RoZSBmaXJzdCAxOTkgbWF5IGJlIHJlbGlhYmxlIHRvbywgdGhhdCB3aWxsIG1ha2UNCml0IGEg bGl0dGxlPGJyPg0KJmd0OyBkaWZmaWN1bHQgdG8gc2VuZCB0aGUgc2Vjb25kIDE5OS48YnI+DQom Z3Q7IDxicj4NCiZndDsgVGhlIHNlY29uZCAxOTkgY291bGQgaW5jbHVkZSBpbmZvcm1hdGlvbiB3 aGljaCBpcyB0byBiZSBmb3J3YXJkZWQNCnRvIHRoZTxicj4NCiZndDsgVUFDLjxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyZndDsyLiAmbmJzcDsmcXVvdDsxMC4gJm5ic3A7 VXNhZ2Ugd2l0aCAxMDByZWw8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZn dDsgJm5ic3A7IFdoZW4gYSAxOTkgRWFybHkgRGlhbG9nIFRlcm1pbmF0ZWQgcHJvdmlzaW9uYWwg cmVzcG9uc2UNCmlzIHNlbnQgYnkgYTxicj4NCiZndDsgVUFTLCBzaW5jZSB0aGUgcHJvdmlzaW9u YWwgcmVzcG9uc2UgaXMgb25seSB1c2VkIGZvciBpbmZvcm1hdGlvbjxicj4NCiZndDsgcHVycG9z ZSwgdGhlIFVBUyBTSE9VTEQgc2VuZCBpdCB1bnJlbGlhYmx5IGV2ZW4gaWYgdGhlIDEwMHJlbDxi cj4NCiZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgb3B0aW9uIHRhZyBbUkZDMzI2Ml0gaXMgcHJlc2Vu dCBpbiB0aGUgUmVxdWlyZSBoZWFkZXINCm9mIHRoZTxicj4NCiZndDsgYXNzb2NpYXRlZCByZXF1 ZXN0LiZxdW90Ozxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4N CiZndDsgJm5ic3A7Jmd0O0kgaGF2ZSBzZWVuIGEgY29tbWVudCBvbiB0aGlzIHF1ZXN0aW9uLGJ1 dCBzdGlsbCBub3QgdW5kZXJzdG9vZA0KYWJvdXQ8YnI+DQomZ3Q7ICZuYnNwOyZndDtpdC4gSWYg dGhlIElOVklURSBoYXMgYSBSZXF1aXJlIHRhZyAmcXVvdDtSZXF1aXJlOiAxMDByZWwmcXVvdDss ZG9lcw0KdGhlIFVBUzxicj4NCiZndDsgc3RpbGw8YnI+DQomZ3Q7ICZuYnNwOyZndDt1c2UgdW5y ZWxpYWJsZSAxOTkgcmVzcG9uc2U/PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJz cDsmZ3Q7VGhhdCBpcyB0aGUgcmVjb21tZW5kYXRpb24sIHllcy4gVGhlIHJlYXNvbnMgaXMgdGhh dCB3ZQ0Kd2FudCB0byBrZWVwPGJyPg0KJmd0OyAxOTk8YnI+DQomZ3Q7ICZuYnNwOyZndDthcyAm cXVvdDtsaWdodHdlaWdodCZxdW90OyBhcyBwb3NzaWJsZSwgd2l0aG91dCByZXF1aXJlaW5nDQpy ZS10cmFuc21pc3Npb25zIGFuZDxicj4NCiZndDsgJm5ic3A7Jmd0O1BSQUNLcy48YnI+DQomZ3Q7 ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDtbRXJpY106IEJ1dCByZWxpYWJsZSAxOTkg aGF2ZSBtb3JlIGFkdmFudGFnZSwgYW5kIEl0IGlzDQp3b3J0aCB0byB1c2U8YnI+DQomZ3Q7IHRo ZSByZWxpYWJsZSAxOTksSSB0aGluay48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBkb24ndCBrbm93 IHdoYXQgdGhhdCBhZHZhbnRhZ2Ugd291bGQgYmUsIGNvbXBhcmVkIHRvIGhhdmluZyB0byBzZW5k PGJyPg0KJmd0OyBQUkFDS3MgZXRjLiBUaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBxdWl0ZSBtdWNo LCBzbyBJIHdvdWxkIHJlYWxseQ0KbmVlZDxicj4NCiZndDsgc29tZSBnb29kIGp1c3RpZmljYXRp b24gdG8gY2hhbmdlIGl0IG5vdy48YnI+DQomZ3Q7IDxicj4NCiZndDsgQWxzbywgdGhlIGRyYWZ0 IGRvZXNuJ3QgZm9yYmlkIHlvdSB0byBzZW5kIHRoZSAxOTkgcmVsaWFibHkuIEl0J3MNCm9ubHkg YTxicj4NCiZndDsgU0hPVUxELjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNw OyZndDtJZiAxOTkgaXMgcmVsaWFibGUsIHRoZXJlIGlzIG9uZSBtb3JlIGFkdmFudGFnZS4gSWYg dGhlDQoxOTkgYXJyaXZlczxicj4NCiZndDsgJm5ic3A7Jmd0O2JlZm9yZSB0aGUgZmlyc3QgMTh4 IHJlc3BvbnNlLCBVQUMgY2FuIGRpc2NhcmQgdGhlIGZpcnN0DQoxOTkgYW5kPGJyPg0KJmd0OyBw cm9jZXNzPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7aXQgdW50aWwgVUFDIHJlY2VpdmVzIHRoZSBmaXJz dCAxOHggcmVzcG9uc2UgdGhhdCBoYXMgdGhlDQpzYW1lPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7dG8t dGFnIGFzIDE5OSwgYXMgdGhlIHJlbGlhYmxlIDE5OSBzaG91bGQgYmUgcmUtdHJhbnNtaXRlZA0K dW50aWw8YnI+DQomZ3Q7ICZuYnNwOyZndDtyZWNlaXZlZCBQUkFDSy48YnI+DQomZ3Q7ICZuYnNw OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDtJZiB0aGUgSU5WSVRFIGNvbnRhaW5zICZxdW90O1Jl cXVpcmU6IDEwMHJlbCZxdW90OywgdGhlDQpmaXJzdCAxOHggbXVzdCBhbHNvIGJlPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7c2VudCByZWxpYWJseS4gQW5kLCBJIGRvbid0IHRoaW5rIHRoZSBVQVMgaXMg YWxsb3dlZCB0bw0Kc2VuZCBhbm90aGVyPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7cmVsaWFibGUgcmVz cG9uc2UgdW50aWwgdGhlIGZpcnN0IG9uZSBpcyBhY2tub3dsZWRnZWQsIHNvDQpJIGRvbid0IHRo aW5rPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7YSByZWxpYWJsZSAxOTkgd291bGQgcmVhY2ggdGhlIFVB QyBiZWZvcmUgdGhlIGZpcnN0IHJlbGlhYmxlDQoxOHguPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7W0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNl bmQgYW5vdGhlciByZWxpYWJsZQ0KcmVzcG9uc2U8YnI+DQomZ3Q7IHVudGlsIHRoZSBmaXJzdCBv bmUgaXMgYWNrbm93bGVkZ2VkLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBJIHJlbWVtYmVyIGNv cnJlY3RseSwgdGhlIEZJUlNUIHJlbGlhYmxlIHJlc3BvbnNlIG11c3QgYmUgYWNrbm93bGVkZWQ8 YnI+DQomZ3Q7IGJlZm9yZSB0aGUgbmV4dCByZWxpYWJsZSByZXNwb25zZSBpcyBzZW50LiBCdXQs IHdlIGNhbiBkb3VibGUgY2hlY2sNCmluPGJyPg0KJmd0OyB0aGUgUFJBQ0sgc3BlYy48YnI+DQom Z3Q7IDxicj4NCiZndDsgJm5ic3A7Jmd0O2J1dCByZWxpYWJsZSAxOTkgd2lsbCBiZSB1c2VmdWwg aWYgdGhlIGZpcnN0IDE4eCBpcyB1bnJlbGlhYmxlLA0Kb3IgdGhlPGJyPg0KJmd0OyBmaXJzdCAx OHggaGFzIGJlZW4gYWNrbndsZWRnZWQuIEl0J3MgYW5vdGhlciBjYXNlIGRpZmZlcmVudCBmcm9t IHRoZTxicj4NCiZndDsgYWJvdmUgb25lICZuYnNwO3dob3NlIElOVklURSBjb250YWlucyAmcXVv dDtyZXF1aXJlOiAxMDByZWwmcXVvdDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIDEwMHJlbCBp cyByZXF1aXJlZCB0aGUgMTh4IGNhbm5vdCBiZSB1bnJlbGlhYmxlLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBDaHJpc3Rlcjxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzDQptYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8NCm90aGVycy48YnI+DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kDQppbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUN CmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVh c2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yDQpvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIu PGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtDQpzeXN0ZW0uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBTaXAgbWFpbGluZyBs aXN0ICZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwPGJyPg0K Jmd0OyBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJv dG9jb2w8YnI+DQomZ3Q7IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3Ig cXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwPGJyPg0KJmd0OyBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBm b3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwPGJyPg0KPC9mb250 PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3Vy aXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJv cGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZu YnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlk ZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5i c3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQm bmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5i c3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkm bmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5i c3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJz cDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJz cDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJz cDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90 aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2Fn ZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVl biZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZu YnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00197C714825756A_=-- From christer.holmberg@ericsson.com Thu Feb 26 22:01:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8313A68FB for ; Thu, 26 Feb 2009 22:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.575 X-Spam-Level: X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtmrlPFKDf+c for ; Thu, 26 Feb 2009 22:01:08 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AFD433A672F for ; Thu, 26 Feb 2009 22:01:07 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C2F42208C4; Fri, 27 Feb 2009 07:01:27 +0100 (CET) X-AuditID: c1b4fb3c-ab806bb000001b43-f5-49a781b76126 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 92E21204BF; Fri, 27 Feb 2009 07:01:27 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 07:01:27 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Feb 2009 07:01:26 +0100 Message-ID: In-Reply-To: <49A7484B.3060407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?UTF-8?B?W1NpcF0g562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJk?= =?UTF-8?B?cmFmdC1pZXRmLXNpcC0xOTktMDUi?= Thread-Index: AcmYfp3luFlv4GuJSHSd1G/HjP6+2AAIZHMQ References: <49A7484B.3060407@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 27 Feb 2009 06:01:27.0412 (UTC) FILETIME=[D3E77340:01C998A0] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] =?utf-8?b?562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1p?= =?utf-8?q?etf-sip-199-05=22?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 06:01:09 -0000 DQpIaSBQYXVsLCANCg0KPiphbGxvd2luZyogKG11Y2ggbGVzcyAqcmVxdWlyaW5nKikgdGhlIDE5 OSB0byBiZSByZWxpYWJsZSBpbnRyb2R1Y2VzIG5hc3R5IHByb2JsZW1zLiBUaGUgMTk5IGlzIG9u bHkgYW4gb3B0aW1pemF0aW9uLCBzbyBoYXZpbmcgaXQgYmUgdW5yZWxpYWJsZSBpcyBvayBJTU8u DQo+DQo+VGhlIHByb2JsZW0gaXMgdGhhdCBpZiBhIHByb3h5IHNlbmRzIHRoZSAxOTksIHRoZW4g dGhlIHJlY2lwaWVudCBvZiB0aGUgUFJBQ0sgc2hvdWxkIGJlIHRoZSBwcm94eS4gQnV0IHRoZSBQ UkFDSyBpcyBhbiBpbi1kaWFsb2cgbWVzc2FnZSwgc28gaXQgbXVzdCBiZSBhZGRyZXNzZWQgdG8g dGhlIENvbnRhY3Qgb2YgdGhlIFVBUy4NCj4NCj5JZiB0aGUgcHJveHkgc2VuZHMgYSByZWxpYWJs ZSAxOTksIGFuZCB0aGUgUFJBQ0sgaXMgYWRkcmVzc2VkIHRvIHRoZSBVQVMsIHRoZSBVQVMgd2ls bCBiZSB2ZXJ5IHN1cnByaXNlZCwgc2luY2UgaXQgaGFzIG5vdCBzZW5kIGEgcmVsaWFibGUgcHJv dmlzaW9uYWwsIGFuZCBpcyBzbyBub3QgZXhwZWN0aW5nIGEgUFJBQ0suIEluIGZhY3QsIGl0IGhh cyANCj5zZW50IGEgZmluYWwgcmVzcG9uc2UsIGhhcyBwcmVzdW1hYmx5IGFscmVhZHkgcmVjZWl2 ZWQgdGhlIEFDSywgYW5kIHNvIGlzIGV4cGVjdGluZyBub3RoaW5nLg0KPg0KPlZlcnkgdWdseS4N Cg0KSnVzdCB0byBjbGFyaWZ5LCBhIHByb3h5IE1VU1QgTk9UIHNlbmQgaXQgcmVsaWFibHkuIFRo ZSB0ZXh0IGluIGNoYXB0ZXIgMTAgc2F5czoNCg0KIldoZW4gYSBmb3JraW5nIHByb3h5IGdlbmVy YXRlcyBhIDE5OSByZXNwb25zZSwgdGhlIHJlc3BvbnNlIE1VU1QgTk9UIGJlIHNlbnQgcmVsaWFi bHkuIg0KDQpUaGUgcmVhc29uIGlzLCBhcyBQYXVsIGluZGljYXRlZCwgdGhhdCB0aGUgcHJveHkg d291bGQgbmVlZCB0byB0ZXJtaW5hdGUgdGhlIFBSQUNLLg0KDQpBIFVBUyBpcyBhbGxvd2VkIHRv IHNlbmQgMTk5IHJlbGlhYmx5LCBidXQgdGhlIHRleCBzYXlzIHRoYXQgaXQgU0hPVUxEIGJlIHNl bnQgdW5yZWxpYWJseS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQp3YW5nLmxpYm9AenRl LmNvbS5jbiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gQW5kIHRoZXJlIHN0aWxsIHR3byBxdWVz dGlvbnMgbGVmdC4NCj4gDQo+IDEuICBJcyB0aGUgMTk5IHNob3VsZCBiZSByZWxpYWJsZSBvciB1 bnJlbGlhYmxlPw0KPiAgICAgSSB0aGluayB0aGF0IDE5OSBzaG91bGQgYmUgcmVsaWFibGUgaWYg cG9zc2libGUuDQo+IA0KPiANCj4gICAgRmlyc3QsIElmIGEgY2xpZW50IHJlY2VpdmVzIGFuIHVu cmVsaWFibGUgMTk5IHJlc3BvbnNlIG9uIGEgZGlhbG9nIA0KPiB3aGljaCBoYXMNCj4gICAgbm90 IHByZXZpb3VzbHkgYmVlbiBjcmVhdGVkICh0aGlzIGNhbiBoYXBwZW4gaWYgYSAxOTkgcmVzcG9u c2UNCj4gICAgcmVhY2hlcyB0aGUgY2xpZW50IGJlZm9yZSBhIDE4eCByZXNwb25zZSkgdGhlIGNs aWVudCBTSEFMTCBkaXNjYXJkDQo+ICAgIHRoZSAxOTkgcmVzcG9uc2VzLg0KPiANCj4gICAgVGhl IGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlLlRoZSAxODAgaXMgc2VudCBmaXJzdCBidXQg YXJyaXZlcyANCj4gbGF0ZXIgdGhhbiAxOTkuDQo+IElmIHRoZSAxOTkgaXMgcmVsaWFibGUsIHRo ZSBwcm94eSBzaG91bGQgcmV0cmFuc21pdCAxOTkgKHN0ZXAgNCksYW5kIA0KPiB0aGVuIHRoZSBy ZXRyYW5zbWl0dGVkDQo+IDE5OSB3aWxsIGJlIGFjY2VwdGVkIGJ5IFVBQyxhbmQgdGhlIGVhcmx5 IGRpYWxvZyB3aWxsIGJlIHRlbWluYXRlZC4NCj4gDQo+IFVBQyAgICAgICAgICAgICBQDQo+ICAg IDEuIElOVklURQ0KPiAtLS0tLS0tLS0tLS0tLS0+DQo+ICAgICAgICAgICAyLiAxODANCj4gPC0t LS0tIFwvLS0tLS0tLQ0KPiAgICAgICAgL1wgMy4gMTk5DQo+IDwtLS0tLS8gIFwtLS0tLS0NCj4g ICAgICAgICAgIDQuIDE5OShyZXRyYW5zbWl0dGVkKQ0KPiA8LS0tLS0tLS0tLS0tLS0tDQo+IA0K PiAgICBzZWNvbmQsIEFjY29yZGluZyB0byBwcmFjdGljYWwgdXNlLCAxOTkgY2FuIGJlIGludGVu ZGVkIHRvIHRlbWluYXRlIA0KPiBvbmUgZWFybHkgZGlhbG9nIGFuZCByZWxlYXNlIHJlc291cmNl cyBhc3NvY2lhdGVkIHdpdGggdGhlIHNwZWNpZmljIA0KPiBlYXJseSBkaWFsb2csIHNvIHRoZSBj b3N0IHNwZW50IG9uIHJlbGlhYmxlIDE5OSBpcyB3b3J0aHkuDQo+IElmIHRoZSAxOTkgY2Fubm90 IGJlIHNlbnQgcmVsaWFibGUsdGhlbiB3ZSBzaG91bGQgc2VuZCBpdCB1bnJlbGlhYmxlLg0KPiAg DQo+IDIuIEluIHlvdXIgbGFzdCBsZXR0ZXIsIHlvdSBzYWlkICJ0aGUgc2Vjb25kIDE5OSBjb3Vs ZCBpbmNsdWRlIA0KPiBpbmZvcm1hdGlvbiB3aGljaCBpcyB0byBiZSBmb3J3YXJkZWQgdG8gdGhl IFVBQyIsIHRoZW4gZG8geW91IG1lYW4sIA0KPiB0aGUgZWFybHkgZGlhbG9nIGlzIHN0aWxsIGFs aXZlIGFmdGVyIHRoZSBmaXJzdA0KPiAxOTkgaXMgYWNjZXB0ZWQ/DQo+IA0KPiANCj4gQWxzbywg SW4gbXkgbGFzdCBsZXR0ZXIsIEkgbWlzcyBhICJOT1QiIGJ5IG1pc3Rha2UuDQo+IEl0IHNob3Vs ZCBiZQ0KPiBbRXJpY106IFN1cmVseSB0aGUgVUFTIGlzIE5PVCBhbGxvd2VkIHRvIHNlbmQgYW5v dGhlciByZWxpYWJsZSANCj4gcmVzcG9uc2UgdW50aWwgdGhlIGZpcnN0IG9uZSBpcyBhY2tub3ds ZWRnZWQuLi4NCj4gDQo+IFJlZ2FyZHMsDQo+IEVyaWMgd2FuZw0KPiANCj4gDQo+IA0KPiANCj4g KiJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4qDQo+ IA0KPiAyMDA5LTAyLTI3IDAzOjA0DQo+IA0KPiAJDQo+IOaUtuS7tuS6ug0KPiAJIkVyaWMgd2Fu ZyIgPGVyaWMud2FuZ3hyQGdtYWlsLmNvbT4NCj4g5oqE6YCBDQo+IAk8c2lwQGlldGYub3JnPiwg PHdhbmcubGlib0B6dGUuY29tLmNuPg0KPiDkuLvpopgNCj4gCVJFOiBRdWVzdGlvbnMgYWJvdXQg ImRyYWZ0LWlldGYtc2lwLTE5OS0wNSINCj4gDQo+IA0KPiAJDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gSGksDQo+IA0KPiAgPkkgc3RpbGwgaGF2ZSBzb21lIGRpZmZpY3VsdCBpbiB1c2luZyBJRVRG IGFuZCBjYW5ub3QgZmluZCB0aGUgd2hvbGUgDQo+IHNvcnRlZCBjb21tZW50cyBhYm91dCB0aGlz IGRyYWZ0LCBzbyBpIGhhdmUgc29tZSBkb3VidCBhYm91dCB0aGlzIGRyYWZ0Lg0KPiAgPg0KPiAg PiAgIDEuICAgIklmIGEgZm9ya2luZyBwcm94eSByZWNlaXZlcyBhIHJlbGlhYmx5IHNlbnQgMTk5 IHJlc3BvbnNlIGZvciBhDQo+IGRpYWxvZywgZm9yIHdoaWNoIHRoZSBwcm94eSBoYXMgcHJldmlv dXNseSBnZW5lcmF0ZWQgYW5kIHNlbnQgYSAxOTkgDQo+IHJlc3BvbnNlLCB0aGUgcHJveHkgTVVT VCBmb3J3YXJkIHRoZSAxOTkgcmVzcG9uc2UuIg0KPiAgPg0KPiAgPiAgICAgRG9lcyBpdCBkZXNj cmliZSB0aGUgY2FzZSBiZWxvdz8gQWx0aG91Z2ggUDEgaGF2ZSBzZW50IGEgMTk5DQo+IHJlc3Bv bnNlLCBQMSBoYXZzIHRvICBmb3J3b3JkIHRoZSBzZW5kIHJlbGlhYmx5IDE5OSB0b28uT3IgIGlz IHRoZSANCj4gZmlyc3QgMTk5IG1pc3Rha2VkIGZvciAxOHg/DQo+ICA+DQo+ICA+ICAgICAgICAg IFVBQyAgICAgICAgICAgICAgIFAxICAgICAgICAgICAgICAgICAgVUFTXzINCj4gID4gICAgICAg ICAgICAtLS0gSU5WSVRFIC0tLS0tLT4NCj4gID4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tLSBJTlZJVEUgKGxlZyAyKSAtPg0KPiAgPiAgICAgICAgICAgIDwtLSAxOTkobGVnIDIpIC0t DQo+ICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0gMTk5IChsZWcgMikgLS0tLS0N Cj4gID4gICAgICAgICAgICA8LS0gMTk5KGxlZyAyKSAtLQ0KPiANCj4gID5JIHRoaW5rIGl0IHNo YWxsIGJlIDE5OSwgYXMgY3VycmVudGx5IHdyaXR0ZW4uDQo+ICA+DQo+ICA+W0VyaWNdOiBJZiAg dGhpcyBpcyAxOTksIHRoZW4gSXMgdGhlcmUgYSBzcGVjaWFsIHB1cnBvc2UgdG8gc2VuZCB0d28N Cj4gMTk5IGluIHRoZSBzYW1lIGRpYWxvZz8NCj4gID5JIHRoaW5rIHRoYXQgb25lIDE5OSBpcyBl bm91Z2guDQo+ICA+QW5kICB0aGUgZmlyc3QgMTk5IG1heSBiZSByZWxpYWJsZSB0b28sIHRoYXQg d2lsbCBtYWtlIGl0IGEgbGl0dGxlIA0KPiBkaWZmaWN1bHQgdG8gc2VuZCB0aGUgc2Vjb25kIDE5 OS4NCj4gDQo+IFRoZSBzZWNvbmQgMTk5IGNvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gd2hpY2gg aXMgdG8gYmUgZm9yd2FyZGVkIHRvIA0KPiB0aGUgVUFDLg0KPiANCj4gDQo+ICA+Mi4gICIxMC4g IFVzYWdlIHdpdGggMTAwcmVsDQo+ICA+DQo+ICA+ICAgV2hlbiBhIDE5OSBFYXJseSBEaWFsb2cg VGVybWluYXRlZCBwcm92aXNpb25hbCByZXNwb25zZSBpcyBzZW50IGJ5IGENCj4gVUFTLCBzaW5j ZSB0aGUgcHJvdmlzaW9uYWwgcmVzcG9uc2UgaXMgb25seSB1c2VkIGZvciBpbmZvcm1hdGlvbiAN Cj4gcHVycG9zZSwgdGhlIFVBUyBTSE9VTEQgc2VuZCBpdCB1bnJlbGlhYmx5IGV2ZW4gaWYgdGhl IDEwMHJlbA0KPiAgPiAgIG9wdGlvbiB0YWcgW1JGQzMyNjJdIGlzIHByZXNlbnQgaW4gdGhlIFJl cXVpcmUgaGVhZGVyIG9mIHRoZQ0KPiBhc3NvY2lhdGVkIHJlcXVlc3QuIg0KPiAgPg0KPiAgPg0K PiAgPkkgaGF2ZSBzZWVuIGEgY29tbWVudCBvbiB0aGlzIHF1ZXN0aW9uLGJ1dCBzdGlsbCBub3Qg dW5kZXJzdG9vZCANCj4gYWJvdXQgID5pdC4gSWYgdGhlIElOVklURSBoYXMgYSBSZXF1aXJlIHRh ZyAiUmVxdWlyZTogMTAwcmVsIixkb2VzIHRoZSANCj4gVUFTIHN0aWxsICA+dXNlIHVucmVsaWFi bGUgMTk5IHJlc3BvbnNlPw0KPiAgPg0KPiAgPlRoYXQgaXMgdGhlIHJlY29tbWVuZGF0aW9uLCB5 ZXMuIFRoZSByZWFzb25zIGlzIHRoYXQgd2Ugd2FudCB0byBrZWVwDQo+IDE5OQ0KPiAgPmFzICJs aWdodHdlaWdodCIgYXMgcG9zc2libGUsIHdpdGhvdXQgcmVxdWlyZWluZyByZS10cmFuc21pc3Np b25zIA0KPiBhbmQgID5QUkFDS3MuDQo+ICA+DQo+ICA+W0VyaWNdOiBCdXQgcmVsaWFibGUgMTk5 IGhhdmUgbW9yZSBhZHZhbnRhZ2UsIGFuZCBJdCBpcyB3b3J0aCB0byB1c2UgDQo+IHRoZSByZWxp YWJsZSAxOTksSSB0aGluay4NCj4gDQo+IEkgZG9uJ3Qga25vdyB3aGF0IHRoYXQgYWR2YW50YWdl IHdvdWxkIGJlLCBjb21wYXJlZCB0byBoYXZpbmcgdG8gc2VuZCANCj4gUFJBQ0tzIGV0Yy4gVGhp cyBoYXMgYmVlbiBkaXNjdXNzZWQgcXVpdGUgbXVjaCwgc28gSSB3b3VsZCByZWFsbHkgbmVlZCAN Cj4gc29tZSBnb29kIGp1c3RpZmljYXRpb24gdG8gY2hhbmdlIGl0IG5vdy4NCj4gDQo+IEFsc28s IHRoZSBkcmFmdCBkb2Vzbid0IGZvcmJpZCB5b3UgdG8gc2VuZCB0aGUgMTk5IHJlbGlhYmx5LiBJ dCdzIG9ubHkgDQo+IGEgU0hPVUxELg0KPiANCj4gDQo+ICA+SWYgMTk5IGlzIHJlbGlhYmxlLCB0 aGVyZSBpcyBvbmUgbW9yZSBhZHZhbnRhZ2UuIElmIHRoZSAxOTkgYXJyaXZlcyAgDQo+ID5iZWZv cmUgdGhlIGZpcnN0IDE4eCByZXNwb25zZSwgVUFDIGNhbiBkaXNjYXJkIHRoZSBmaXJzdCAxOTkg YW5kIA0KPiBwcm9jZXNzICA+aXQgdW50aWwgVUFDIHJlY2VpdmVzIHRoZSBmaXJzdCAxOHggcmVz cG9uc2UgdGhhdCBoYXMgdGhlIA0KPiBzYW1lICA+dG8tdGFnIGFzIDE5OSwgYXMgdGhlIHJlbGlh YmxlIDE5OSBzaG91bGQgYmUgcmUtdHJhbnNtaXRlZCANCj4gdW50aWwgID5yZWNlaXZlZCBQUkFD Sy4NCj4gID4NCj4gID5JZiB0aGUgSU5WSVRFIGNvbnRhaW5zICJSZXF1aXJlOiAxMDByZWwiLCB0 aGUgZmlyc3QgMTh4IG11c3QgYWxzbyBiZSAgDQo+ID5zZW50IHJlbGlhYmx5LiBBbmQsIEkgZG9u J3QgdGhpbmsgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlciAgDQo+ID5yZWxpYWJs ZSByZXNwb25zZSB1bnRpbCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZCwgc28gSSBkb24n dCANCj4gdGhpbmsgID5hIHJlbGlhYmxlIDE5OSB3b3VsZCByZWFjaCB0aGUgVUFDIGJlZm9yZSB0 aGUgZmlyc3QgcmVsaWFibGUgMTh4Lg0KPiAgPg0KPiAgPltFcmljXTogU3VyZWx5IHRoZSBVQVMg aXMgYWxsb3dlZCB0byBzZW5kIGFub3RoZXIgcmVsaWFibGUgcmVzcG9uc2UgDQo+IHVudGlsIHRo ZSBmaXJzdCBvbmUgaXMgYWNrbm93bGVkZ2VkLA0KPiANCj4gSWYgSSByZW1lbWJlciBjb3JyZWN0 bHksIHRoZSBGSVJTVCByZWxpYWJsZSByZXNwb25zZSBtdXN0IGJlIA0KPiBhY2tub3dsZWRlZCBi ZWZvcmUgdGhlIG5leHQgcmVsaWFibGUgcmVzcG9uc2UgaXMgc2VudC4gQnV0LCB3ZSBjYW4gDQo+ IGRvdWJsZSBjaGVjayBpbiB0aGUgUFJBQ0sgc3BlYy4NCj4gDQo+ICA+YnV0IHJlbGlhYmxlIDE5 OSB3aWxsIGJlIHVzZWZ1bCBpZiB0aGUgZmlyc3QgMTh4IGlzIHVucmVsaWFibGUsIG9yIA0KPiB0 aGUgZmlyc3QgMTh4IGhhcyBiZWVuIGFja253bGVkZ2VkLiBJdCdzIGFub3RoZXIgY2FzZSBkaWZm ZXJlbnQgZnJvbSANCj4gdGhlIGFib3ZlIG9uZSAgd2hvc2UgSU5WSVRFIGNvbnRhaW5zICJyZXF1 aXJlOiAxMDByZWwiLg0KPiANCj4gSWYgMTAwcmVsIGlzIHJlcXVpcmVkIHRoZSAxOHggY2Fubm90 IGJlIHVucmVsaWFibGUuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1 cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNv bGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29t bXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9i bGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNj bG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4gVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCj4gDQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IC0tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcA0KPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBv ZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wgVXNlIA0KPiBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVt YmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwIFVzZSANCj4gc2lwcGluZ0BpZXRm Lm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQo= From christer.holmberg@ericsson.com Thu Feb 26 22:13:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDBEB3A672F for ; Thu, 26 Feb 2009 22:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.586 X-Spam-Level: X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXfhCyugtGeJ for ; Thu, 26 Feb 2009 22:13:01 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AF3E33A6994 for ; Thu, 26 Feb 2009 22:13:00 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0EE2B203F6; Fri, 27 Feb 2009 07:13:21 +0100 (CET) X-AuditID: c1b4fb3e-ad09cbb0000023da-7b-49a784802f96 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC5E120109; Fri, 27 Feb 2009 07:13:20 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 07:13:20 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C998A2.7CC06068" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Feb 2009 07:13:20 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?UTF-8?B?W1NpcF0g562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJk?= =?UTF-8?B?cmFmdC1pZXRmLXNpcC0xOTktMDUi?= Thread-Index: AcmYd9eHfEBBuPtpR2qwatwP0WBoRQAKS24g References: From: "Christer Holmberg" To: X-OriginalArrivalTime: 27 Feb 2009 06:13:20.0743 (UTC) FILETIME=[7D151F70:01C998A2] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] =?utf-8?b?562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1p?= =?utf-8?q?etf-sip-199-05=22?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 06:13:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C998A2.7CC06068 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IHNpcC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86c2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB3 YW5nLmxpYm9AenRlLmNvbS5jbg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNywgMjAwOSAzOjA2 IEFNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBzaXBAaWV0Zi5vcmcNClN1YmplY3Q6IFtT aXBdIOetlOWkjTogUkU6IFF1ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0Zi1zaXAtMTk5LTA1Ig0K DQoNCg0KSGksIA0KDQo+IDEuICBJcyB0aGUgMTk5IHNob3VsZCBiZSByZWxpYWJsZSBvciB1bnJl bGlhYmxlPyAgDQogDQpTSE9VTEQgYmUgdW5yZWxpYWJsZSAoaWYgc2VudCBmcm9tIGEgVUFTKS4N CiANCj5JIHRoaW5rIHRoYXQgMTk5IHNob3VsZCBiZSByZWxpYWJsZSBpZiBwb3NzaWJsZS4gIA0K Pg0KPkZpcnN0LCBJZiBhIGNsaWVudCByZWNlaXZlcyBhbiB1bnJlbGlhYmxlIDE5OSByZXNwb25z ZSBvbiBhIGRpYWxvZyB3aGljaCBoYXMgDQo+bm90IHByZXZpb3VzbHkgYmVlbiBjcmVhdGVkICh0 aGlzIGNhbiBoYXBwZW4gaWYgYSAxOTkgcmVzcG9uc2UgDQo+cmVhY2hlcyB0aGUgY2xpZW50IGJl Zm9yZSBhIDE4eCByZXNwb25zZSkgdGhlIGNsaWVudCBTSEFMTCBkaXNjYXJkIA0KPnRoZSAxOTkg cmVzcG9uc2VzLiANCj4gDQo+VGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlLlRoZSAx ODAgaXMgc2VudCBmaXJzdCBidXQgYXJyaXZlcyBsYXRlciB0aGFuIDE5OS4gDQo+SWYgdGhlIDE5 OSBpcyByZWxpYWJsZSwgdGhlIHByb3h5IHNob3VsZCByZXRyYW5zbWl0IDE5OSAoc3RlcCA0KSxh bmQgdGhlbiB0aGUgcmV0cmFuc21pdHRlZCANCj4xOTkgd2lsbCBiZSBhY2NlcHRlZCBieSBVQUMs YW5kIHRoZSBlYXJseSBkaWFsb2cgd2lsbCBiZSB0ZW1pbmF0ZWQuIA0KPiANCj5VQUMgICAgICAg ICAgICAgUCANCj4xLiBJTlZJVEUgDQo+LS0tLS0tLS0tLS0tLS0tPiANCj4gICAgICAgICAgIDIu IDE4MCANCj48LS0tLS0gXC8tLS0tLS0tIA0KPiAgICAgICAgL1wgMy4gMTk5IA0KPjwtLS0tLS8g IFwtLS0tLS0gDQo+ICAgICAgICAgICA0LiAxOTkocmV0cmFuc21pdHRlZCkgDQo+PC0tLS0tLS0t LS0tLS0tLSAgDQogDQpJbiBteSBvcGluaW9uIGl0IHdvdWxkIGJlIG11Y2ggd2lzZXIgdG8gc2Vu ZCB0aGUgMTgwIHJlbGFpYmx5IGluIHRoaXMgY2FzZSwgYW5kIHRoZW4gc2VuZCAxOTkgb25jZSB0 aGUgMTgwIGhhcyBiZWVuIGFja25vd2xlZGdlZC4NCg0KPnNlY29uZCwgQWNjb3JkaW5nIHRvIHBy YWN0aWNhbCB1c2UsIDE5OSBjYW4gYmUgaW50ZW5kZWQgdG8gdGVtaW5hdGUgb25lIGVhcmx5IGRp YWxvZyBhbmQgcmVsZWFzZSANCj5yZXNvdXJjZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBzcGVjaWZp YyBlYXJseSBkaWFsb2csIHNvIHRoZSBjb3N0IHNwZW50IG9uIHJlbGlhYmxlIDE5OSBpcyB3b3J0 aHkuIA0KPklmIHRoZSAxOTkgY2Fubm90IGJlIHNlbnQgcmVsaWFibGUsdGhlbiB3ZSBzaG91bGQg c2VuZCBpdCB1bnJlbGlhYmxlLiAgDQo+ICAgDQo+Mi4gSW4geW91ciBsYXN0IGxldHRlciwgeW91 IHNhaWQgInRoZSBzZWNvbmQgMTk5IGNvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gd2hpY2ggaXMg dG8gYmUgZm9yd2FyZGVkIHRvIHRoZSBVQUMiLCB0aGVuIGRvIHlvdSBtZWFuLCB0aGUgZWFybHkg ZGlhbG9nIGlzIHN0aWxsIGFsaXZlIGFmdGVyIHRoZSBmaXJzdCAxOTkgaXMgYWNjZXB0ZWQ/ICAN CiANCk5vLiBCdXQgdGhlcmUgaGFzIGJlZW4gZGlzY3Vzc2lvbnMgdG8gZS5nLiBpbmNsdWRlIHRo ZSBlcnJvciByZXNwb25zZSB3aGljaCB0cmlnZ2VyZWQgdGhlIDE5OSwgc28gdGhhdCB0aGUgVUFD IGdldHMgbW9yZSBpbmZvcm1hdGlvbiBvbiBXSFkgdGhlIGVhcmx5IGRpYWxvZyB3YXMgdGVybWlu YXRlZC4NCiANClJlZ2FyZHMsDQogDQpDaHJpc3Rlcg0KIA0KDQogDQogDQogDQoNCg0KDQoiQ2hy aXN0ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IA0KDQoyMDA5 LTAyLTI3IDAzOjA0IA0KDQrmlLbku7bkuroNCiJFcmljIHdhbmciIDxlcmljLndhbmd4ckBnbWFp bC5jb20+IA0K5oqE6YCBDQo8c2lwQGlldGYub3JnPiwgPHdhbmcubGlib0B6dGUuY29tLmNuPiAN CuS4u+mimA0KUkU6IFF1ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0Zi1zaXAtMTk5LTA1Ig0KDQoJ DQoNCg0KDQoNCkhpLA0KDQo+SSBzdGlsbCBoYXZlIHNvbWUgZGlmZmljdWx0IGluIHVzaW5nIElF VEYgYW5kIGNhbm5vdCBmaW5kIHRoZSB3aG9sZQ0Kc29ydGVkIGNvbW1lbnRzIGFib3V0IHRoaXMg ZHJhZnQsIHNvIGkgaGF2ZSBzb21lIGRvdWJ0IGFib3V0IHRoaXMgZHJhZnQuDQo+DQo+ICAgMS4g ICAiSWYgYSBmb3JraW5nIHByb3h5IHJlY2VpdmVzIGEgcmVsaWFibHkgc2VudCAxOTkgcmVzcG9u c2UgZm9yIGENCmRpYWxvZywgZm9yIHdoaWNoIHRoZSBwcm94eSBoYXMgcHJldmlvdXNseSBnZW5l cmF0ZWQgYW5kIHNlbnQgYSAxOTkNCnJlc3BvbnNlLCB0aGUgcHJveHkgTVVTVCBmb3J3YXJkIHRo ZSAxOTkgcmVzcG9uc2UuIg0KPg0KPiAgICAgRG9lcyBpdCBkZXNjcmliZSB0aGUgY2FzZSBiZWxv dz8gQWx0aG91Z2ggUDEgaGF2ZSBzZW50IGEgMTk5DQpyZXNwb25zZSwgUDEgaGF2cyB0byAgZm9y d29yZCB0aGUgc2VuZCByZWxpYWJseSAxOTkgdG9vLk9yICBpcyB0aGUNCmZpcnN0IDE5OSBtaXN0 YWtlZCBmb3IgMTh4Pw0KPg0KPiAgICAgICAgICBVQUMgICAgICAgICAgICAgICBQMSAgICAgICAg ICAgICAgICAgIFVBU18yDQo+ICAgICAgICAgICAgLS0tIElOVklURSAtLS0tLS0+DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLS0gSU5WSVRFIChsZWcgMikgLT4NCj4gICAgICAgICAg ICA8LS0gMTk5KGxlZyAyKSAtLQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tIDE5 OSAobGVnIDIpIC0tLS0tDQo+ICAgICAgICAgICAgPC0tIDE5OShsZWcgMikgLS0NCg0KPkkgdGhp bmsgaXQgc2hhbGwgYmUgMTk5LCBhcyBjdXJyZW50bHkgd3JpdHRlbi4NCj4gDQo+W0VyaWNdOiBJ ZiAgdGhpcyBpcyAxOTksIHRoZW4gSXMgdGhlcmUgYSBzcGVjaWFsIHB1cnBvc2UgdG8gc2VuZCB0 d28NCjE5OSBpbiB0aGUgc2FtZSBkaWFsb2c/DQo+SSB0aGluayB0aGF0IG9uZSAxOTkgaXMgZW5v dWdoLg0KPkFuZCAgdGhlIGZpcnN0IDE5OSBtYXkgYmUgcmVsaWFibGUgdG9vLCB0aGF0IHdpbGwg bWFrZSBpdCBhIGxpdHRsZQ0KZGlmZmljdWx0IHRvIHNlbmQgdGhlIHNlY29uZCAxOTkuDQoNClRo ZSBzZWNvbmQgMTk5IGNvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gd2hpY2ggaXMgdG8gYmUgZm9y d2FyZGVkIHRvIHRoZQ0KVUFDLg0KDQoNCj4yLiAgIjEwLiAgVXNhZ2Ugd2l0aCAxMDByZWwNCj4N Cj4gICBXaGVuIGEgMTk5IEVhcmx5IERpYWxvZyBUZXJtaW5hdGVkIHByb3Zpc2lvbmFsIHJlc3Bv bnNlIGlzIHNlbnQgYnkgYQ0KVUFTLCBzaW5jZSB0aGUgcHJvdmlzaW9uYWwgcmVzcG9uc2UgaXMg b25seSB1c2VkIGZvciBpbmZvcm1hdGlvbg0KcHVycG9zZSwgdGhlIFVBUyBTSE9VTEQgc2VuZCBp dCB1bnJlbGlhYmx5IGV2ZW4gaWYgdGhlIDEwMHJlbA0KPiAgIG9wdGlvbiB0YWcgW1JGQzMyNjJd IGlzIHByZXNlbnQgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIG9mIHRoZQ0KYXNzb2NpYXRlZCByZXF1 ZXN0LiINCj4NCj4NCj5JIGhhdmUgc2VlbiBhIGNvbW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQg c3RpbGwgbm90IHVuZGVyc3Rvb2QgYWJvdXQNCj5pdC4gSWYgdGhlIElOVklURSBoYXMgYSBSZXF1 aXJlIHRhZyAiUmVxdWlyZTogMTAwcmVsIixkb2VzIHRoZSBVQVMNCnN0aWxsDQo+dXNlIHVucmVs aWFibGUgMTk5IHJlc3BvbnNlPw0KPg0KPlRoYXQgaXMgdGhlIHJlY29tbWVuZGF0aW9uLCB5ZXMu IFRoZSByZWFzb25zIGlzIHRoYXQgd2Ugd2FudCB0byBrZWVwDQoxOTkNCj5hcyAibGlnaHR3ZWln aHQiIGFzIHBvc3NpYmxlLCB3aXRob3V0IHJlcXVpcmVpbmcgcmUtdHJhbnNtaXNzaW9ucyBhbmQN Cj5QUkFDS3MuDQo+IA0KPltFcmljXTogQnV0IHJlbGlhYmxlIDE5OSBoYXZlIG1vcmUgYWR2YW50 YWdlLCBhbmQgSXQgaXMgd29ydGggdG8gdXNlDQp0aGUgcmVsaWFibGUgMTk5LEkgdGhpbmsuDQoN CkkgZG9uJ3Qga25vdyB3aGF0IHRoYXQgYWR2YW50YWdlIHdvdWxkIGJlLCBjb21wYXJlZCB0byBo YXZpbmcgdG8gc2VuZA0KUFJBQ0tzIGV0Yy4gVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgcXVpdGUg bXVjaCwgc28gSSB3b3VsZCByZWFsbHkgbmVlZA0Kc29tZSBnb29kIGp1c3RpZmljYXRpb24gdG8g Y2hhbmdlIGl0IG5vdy4NCg0KQWxzbywgdGhlIGRyYWZ0IGRvZXNuJ3QgZm9yYmlkIHlvdSB0byBz ZW5kIHRoZSAxOTkgcmVsaWFibHkuIEl0J3Mgb25seSBhDQpTSE9VTEQuDQoNCg0KPklmIDE5OSBp cyByZWxpYWJsZSwgdGhlcmUgaXMgb25lIG1vcmUgYWR2YW50YWdlLiBJZiB0aGUgMTk5IGFycml2 ZXMNCj5iZWZvcmUgdGhlIGZpcnN0IDE4eCByZXNwb25zZSwgVUFDIGNhbiBkaXNjYXJkIHRoZSBm aXJzdCAxOTkgYW5kDQpwcm9jZXNzDQo+aXQgdW50aWwgVUFDIHJlY2VpdmVzIHRoZSBmaXJzdCAx OHggcmVzcG9uc2UgdGhhdCBoYXMgdGhlIHNhbWUNCj50by10YWcgYXMgMTk5LCBhcyB0aGUgcmVs aWFibGUgMTk5IHNob3VsZCBiZSByZS10cmFuc21pdGVkIHVudGlsDQo+cmVjZWl2ZWQgUFJBQ0su DQo+DQo+SWYgdGhlIElOVklURSBjb250YWlucyAiUmVxdWlyZTogMTAwcmVsIiwgdGhlIGZpcnN0 IDE4eCBtdXN0IGFsc28gYmUNCj5zZW50IHJlbGlhYmx5LiBBbmQsIEkgZG9uJ3QgdGhpbmsgdGhl IFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlcg0KPnJlbGlhYmxlIHJlc3BvbnNlIHVudGls IHRoZSBmaXJzdCBvbmUgaXMgYWNrbm93bGVkZ2VkLCBzbyBJIGRvbid0IHRoaW5rDQo+YSByZWxp YWJsZSAxOTkgd291bGQgcmVhY2ggdGhlIFVBQyBiZWZvcmUgdGhlIGZpcnN0IHJlbGlhYmxlIDE4 eC4NCj4gDQo+W0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhl ciByZWxpYWJsZSByZXNwb25zZQ0KdW50aWwgdGhlIGZpcnN0IG9uZSBpcyBhY2tub3dsZWRnZWQs DQoNCklmIEkgcmVtZW1iZXIgY29ycmVjdGx5LCB0aGUgRklSU1QgcmVsaWFibGUgcmVzcG9uc2Ug bXVzdCBiZSBhY2tub3dsZWRlZA0KYmVmb3JlIHRoZSBuZXh0IHJlbGlhYmxlIHJlc3BvbnNlIGlz IHNlbnQuIEJ1dCwgd2UgY2FuIGRvdWJsZSBjaGVjayBpbg0KdGhlIFBSQUNLIHNwZWMuDQoNCj5i dXQgcmVsaWFibGUgMTk5IHdpbGwgYmUgdXNlZnVsIGlmIHRoZSBmaXJzdCAxOHggaXMgdW5yZWxp YWJsZSwgb3IgdGhlDQpmaXJzdCAxOHggaGFzIGJlZW4gYWNrbndsZWRnZWQuIEl0J3MgYW5vdGhl ciBjYXNlIGRpZmZlcmVudCBmcm9tIHRoZQ0KYWJvdmUgb25lICB3aG9zZSBJTlZJVEUgY29udGFp bnMgInJlcXVpcmU6IDEwMHJlbCIuDQoNCklmIDEwMHJlbCBpcyByZXF1aXJlZCB0aGUgMTh4IGNh bm5vdCBiZSB1bnJlbGlhYmxlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFs LiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVj eSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNt aXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVz c2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3Rp ZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1l c3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1T cGFtIHN5c3RlbS4NCg== ------_=_NextPart_001_01C998A2.7CC06068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjM3OTAuNDQyNiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1B cmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpLDwvRk9OVD48L1NQQU4+PC9ESVY+PEJSPg0K PERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249 bGVmdD4NCjxIUiB0YWJJbmRleD0tMT4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9t OjwvQj4gc2lwLWJvdW5jZXNAaWV0Zi5vcmcgDQpbbWFpbHRvOnNpcC1ib3VuY2VzQGlldGYub3Jn XSA8Qj5PbiBCZWhhbGYgT2YgDQo8L0I+d2FuZy5saWJvQHp0ZS5jb20uY248QlI+PEI+U2VudDo8 L0I+IEZyaWRheSwgRmVicnVhcnkgMjcsIDIwMDkgMzowNiANCkFNPEJSPjxCPlRvOjwvQj4gQ2hy aXN0ZXIgSG9sbWJlcmc8QlI+PEI+Q2M6PC9CPiBzaXBAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8 L0I+IA0KW1NpcF0g562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1pZXRmLXNpcC0x OTktMDUiPEJSPjwvRk9OVD48QlI+PC9ESVY+DQo8RElWPjwvRElWPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAw MGZmIHNpemU9Mj48L0ZPTlQ+DQo8RElWPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PkhpLDwvRk9OVD4mbmJzcDs8QlI+PEJSPjxGT05UIA0KZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+ PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQg DQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiZndDs8L0ZPTlQ+ Jm5ic3A7PC9GT05UPjwvU1BBTj4xLiANCiZuYnNwO0lzIHRoZSAxOTkgc2hvdWxkIGJlIHJlbGlh YmxlIG9yIHVucmVsaWFibGU/PC9GT05UPjwvRk9OVD4mbmJzcDs8U1BBTiANCmNsYXNzPTIxMTUw MDIwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+Jm5i c3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3MDIy MDA5PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5TSE9VTEQgDQpiZSB1bnJlbGlhYmxlIChp ZiBzZW50IGZyb20gYSBVQVMpLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNz PTIxMTUwMDIwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXpl PTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9O VCBzaXplPTI+PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05UIA0KY29sb3I9IzAw MDBmZj4mZ3Q7PC9GT05UPjwvU1BBTj5JIHRoaW5rIHRoYXQgMTk5IHNob3VsZCBiZSByZWxpYWJs ZSBpZiANCnBvc3NpYmxlLjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PFNQQU4gY2xhc3M9MjExNTAwMjA2 LTI3MDIyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJzcDs8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZndDs8L0ZPTlQ+PC9TUEFO PjxCUj48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiANCmNsYXNzPTIxMTUwMDIw Ni0yNzAyMjAwOT48Rk9OVCBjb2xvcj0jMDAwMGZmPiZndDs8L0ZPTlQ+PC9TUEFOPkZpcnN0LCA8 L0ZPTlQ+SWYgDQphIGNsaWVudCByZWNlaXZlcyBhbiB1bnJlbGlhYmxlIDE5OSByZXNwb25zZSBv biBhIGRpYWxvZyB3aGljaCANCmhhczwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgc2l6ZT0yPjxTUEFO IGNsYXNzPTIxMTUwMDIwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBm Zj4mZ3Q7PC9GT05UPjwvU1BBTj5ub3QgcHJldmlvdXNseSBiZWVuIGNyZWF0ZWQgKHRoaXMgY2Fu IGhhcHBlbiBpZiANCmEgMTk5IHJlc3BvbnNlPC9GT05UPiZuYnNwOzxCUj48Rk9OVCBzaXplPTI+ PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05UIA0KZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmPiZndDs8L0ZPTlQ+PC9TUEFOPnJlYWNoZXMgdGhlIGNsaWVudCBiZWZvcmUgYSAxOHgg DQpyZXNwb25zZSkgdGhlIGNsaWVudCBTSEFMTCBkaXNjYXJkPC9GT05UPiZuYnNwOzxCUj48Rk9O VCBzaXplPTI+PFNQQU4gDQpjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmPiZndDs8L0ZPTlQ+PC9TUEFOPnRoZSANCjE5OSByZXNwb25zZXMuPC9G T05UPiZuYnNwOzxCUj48U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1B cmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZndDsmbmJzcDs8L0ZPTlQ+PC9TUEFOPjxCUj48 Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmPiZndDs8L0ZPTlQ+PC9TUEFOPlRoZSANCmZpZ3VyZSBiZWxvdyBz aG93cyBhbiBleGFtcGxlLlRoZSAxODAgaXMgc2VudCBmaXJzdCBidXQgYXJyaXZlcyBsYXRlciB0 aGFuIA0KMTk5LjwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTIxMTUw MDIwNi0yNzAyMjAwOT48Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDAgDQpzaXplPTM+Jmd0OzwvRk9OVD48L0ZP TlQ+PC9TUEFOPklmIHRoZSAxOTkgaXMgcmVsaWFibGUsIHRoZSBwcm94eSBzaG91bGQgDQpyZXRy YW5zbWl0IDE5OSAoc3RlcCA0KSxhbmQgdGhlbiB0aGUgcmV0cmFuc21pdHRlZDwvRk9OVD4mbmJz cDs8QlI+PEZPTlQgDQpzaXplPTI+PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIg Y29sb3I9IzAwMDAwMCBzaXplPTM+Jmd0OzwvRk9OVD48L0ZPTlQ+PC9TUEFOPjE5OSB3aWxsIGJl IA0KYWNjZXB0ZWQgYnkgVUFDLGFuZCB0aGUgZWFybHkgZGlhbG9nIHdpbGwgYmUgdGVtaW5hdGVk LjwvRk9OVD4mbmJzcDs8QlI+PFNQQU4gDQpjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZndDsmbmJzcDs8L0ZPTlQ+PC9TUEFO PjxCUj48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPiZndDs8L0ZPTlQ+PC9TUEFOPlVBQyANCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFA8L0ZPTlQ+Jm5ic3A7PEJSPjxGT05U IHNpemU9Mj48U1BBTiANCmNsYXNzPTIxMTUwMDIwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAw MDAgc2l6ZT0zPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj4xLiANCklOVklURTwvRk9OVD4mbmJz cDs8QlI+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTIxMTUwMDIwNi0yNzAyMjAwOT48Rk9OVCAN CmZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNv bG9yPSMwMDAwMDAgDQpzaXplPTM+Jmd0OzwvRk9OVD48L0ZPTlQ+PC9TUEFOPi0tLS0tLS0tLS0t LS0tLSZndDs8L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIA0Kc2l6ZT0yPjxTUEFOIGNsYXNzPTIxMTUw MDIwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDAgDQpzaXplPTM+Jmd0OzwvRk9OVD4mbmJz cDs8L0ZPTlQ+PC9TUEFOPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCjIuIDE4MDwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgc2l6ZT0yPjxTUEFO IGNsYXNzPTIxMTUwMDIwNi0yNzAyMjAwOT48Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9IzAwMDBm Zj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDAgDQpzaXplPTM+Jmd0 OzwvRk9OVD48L0ZPTlQ+PC9TUEFOPiZsdDstLS0tLSBcLy0tLS0tLS08L0ZPTlQ+Jm5ic3A7PEJS PjxGT05UIA0KZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3 MDIyMDA5PjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IGNvbG9yPSMwMDAwMDAgDQpzaXplPTM+Jmd0OzwvRk9OVD4mbmJzcDs8L0ZPTlQ+PC9TUEFOPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9cIA0KMy4gMTk5PC9GT05U PjwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQpj bGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIA0KY29sb3I9IzAwMDAwMCBzaXplPTM+Jmd0OzwvRk9OVD48L0ZPTlQ+ PC9TUEFOPiZsdDstLS0tLS8gDQombmJzcDtcLS0tLS0tPC9GT05UPjwvRk9OVD4mbmJzcDs8QlI+ PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZj48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9 IzAwMDAwMCANCnNpemU9Mz4mZ3Q7PC9GT05UPiZuYnNwOzwvRk9OVD48L1NQQU4+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KNC4gMTk5KHJl dHJhbnNtaXR0ZWQpPC9GT05UPiZuYnNwOzxCUj48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz0y MTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPjxGT05UIA0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwIA0Kc2l6ZT0zPiZndDs8L0ZPTlQ+ PC9GT05UPjwvU1BBTj4mbHQ7LS0tLS0tLS0tLS0tLS0tPC9GT05UPiZuYnNwOzxTUEFOIA0KY2xh c3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNp emU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yMTE1MDAy MDYtMjcwMjIwMDk+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yMTE1MDAy MDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5JbiBteSAN Cm9waW5pb24gaXQgd291bGQgYmUgbXVjaCB3aXNlciB0byBzZW5kIHRoZSAxODAgcmVsYWlibHkg aW4gdGhpcyBjYXNlLCBhbmQgdGhlbiANCnNlbmQgMTk5IG9uY2UgdGhlIDE4MCBoYXMgYmVlbiBh Y2tub3dsZWRnZWQuPC9GT05UPjwvU1BBTj48L0RJVj48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9 IzAwMDBmZiBzaXplPTI+PC9GT05UPg0KPERJVj48QlI+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNz PTIxMTUwMDIwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZj4mZ3Q7 PC9GT05UPjwvU1BBTj5zZWNvbmQsIEFjY29yZGluZyB0byBwcmFjdGljYWwgdXNlLCAxOTkgY2Fu IGJlIA0KaW50ZW5kZWQgdG8gdGVtaW5hdGUgb25lIGVhcmx5IGRpYWxvZyBhbmQgcmVsZWFzZSZu YnNwOzwvRk9OVD48QlI+PEZPTlQgDQpzaXplPTI+PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3MDIy MDA5PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48Rk9OVCANCmZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IzAwMDAwMD4mZ3Q7PC9GT05UPjwvRk9OVD48L1NQQU4+cmVzb3VyY2Vz IA0KYXNzb2NpYXRlZCB3aXRoIHRoZSBzcGVjaWZpYyBlYXJseSBkaWFsb2csIHNvIHRoZSBjb3N0 IHNwZW50IG9uIHJlbGlhYmxlIDE5OSBpcyANCndvcnRoeS48L0ZPTlQ+Jm5ic3A7PEJSPjxGT05U IHNpemU9Mj48U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgDQpmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAw IA0Kc2l6ZT0zPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj5JZiB0aGUgMTk5IGNhbm5vdCBiZSBz ZW50IHJlbGlhYmxlLHRoZW4gd2UgDQpzaG91bGQgc2VuZCBpdCB1bnJlbGlhYmxlLjwvRk9OVD4m bmJzcDs8U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgDQpmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTIxMTUwMDIwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg DQpzaXplPTI+Jmd0OzwvRk9OVD48L1NQQU4+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+ PFNQQU4gDQpjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+Jm5ic3A7PC9TUEFOPiZuYnNwOyZuYnNw OzwvRk9OVD48L0ZPTlQ+PEJSPjxGT05UIA0KZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4g Y2xhc3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpjb2xv cj0jMDAwMDAwPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj4yLiA8L0ZPTlQ+PC9GT05UPjxUVD48 Rk9OVCBzaXplPTI+SW4geW91ciANCmxhc3QgbGV0dGVyLCB5b3Ugc2FpZCAidGhlIHNlY29uZCAx OTkgY291bGQgaW5jbHVkZSBpbmZvcm1hdGlvbiB3aGljaCBpcyB0byBiZSANCmZvcndhcmRlZCB0 byB0aGU8U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCmNv bG9yPSMwMDAwZmY+Jm5ic3A7PC9GT05UPjwvU1BBTj5VQUMiLCB0aGVuIGRvIHlvdSBtZWFuLCB0 aGUgZWFybHkgZGlhbG9nIGlzIA0Kc3RpbGwgYWxpdmUgYWZ0ZXIgdGhlIGZpcnN0IDE5OSBpcyBh Y2NlcHRlZD88L0ZPTlQ+PC9UVD4mbmJzcDs8U1BBTiANCmNsYXNzPTIxMTUwMDIwNi0yNzAyMjAw OT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+Jm5ic3A7PC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj5Oby4gDQpCdXQgdGhlcmUgaGFzIGJlZW4gZGlzY3Vzc2lvbnMg dG8gZS5nLiBpbmNsdWRlIHRoZSBlcnJvciByZXNwb25zZSB3aGljaCANCnRyaWdnZXJlZCB0aGUg MTk5LCBzbyB0aGF0IHRoZSBVQUMgZ2V0cyBtb3JlIGluZm9ybWF0aW9uIG9uJm5ic3A7V0hZIHRo ZSBlYXJseSANCmRpYWxvZyB3YXMgdGVybWluYXRlZC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+Jm5ic3A7PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz0yMTE1MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0Kc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MjExNTAwMjA2LTI3MDIyMDA5PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAN CnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yMTE1 MDAyMDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPkNo cmlzdGVyPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjExNTAwMjA2LTI3 MDIyMDA5PiZuYnNwOzwvU1BBTj48QlI+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxCUj48QlI+PEJSPjwvRElWPg0KPFRBQkxFIHdpZHRoPSIxMDAlIj4NCiAgPFRCT0RZPg0KICA8 VFIgdkFsaWduPXRvcD4NCiAgICA8VEQgd2lkdGg9IjI2JSI+PEZPTlQgZmFjZT1zYW5zLXNlcmlm IHNpemU9MT48Qj4iQ2hyaXN0ZXIgSG9sbWJlcmciIA0KICAgICAgJmx0O2NocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbSZndDs8L0I+IDwvRk9OVD4NCiAgICAgIDxQPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTE+MjAwOS0wMi0yNyAwMzowNDwvRk9OVD4gPC9QPg0KICAgIDxURCB3aWR0 aD0iNzMlIj4NCiAgICAgIDxUQUJMRSB3aWR0aD0iMTAwJSI+DQogICAgICAgIDxUQk9EWT4NCiAg ICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgPFREPg0KICAgICAgICAgICAgPERJViBh bGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPuaUtuS7tuS6ujwvRk9OVD48 L0RJVj4NCiAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4iRXJpYyB3 YW5nIiANCiAgICAgICAgICAgICZsdDtlcmljLndhbmd4ckBnbWFpbC5jb20mZ3Q7PC9GT05UPiAN CiAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgPFREPg0KICAgICAgICAgICAgPERJ ViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPuaKhOmAgTwvRk9OVD48 L0RJVj4NCiAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4mbHQ7c2lw QGlldGYub3JnJmd0OywgDQogICAgICAgICAgICAmbHQ7d2FuZy5saWJvQHp0ZS5jb20uY24mZ3Q7 PC9GT05UPiANCiAgICAgICAgPFRSIHZBbGlnbj10b3A+DQogICAgICAgICAgPFREPg0KICAgICAg ICAgICAgPERJViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPuS4u+mi mDwvRk9OVD48L0RJVj4NCiAgICAgICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9 MT5SRTogUXVlc3Rpb25zIGFib3V0IA0KICAgICAgICAgICAgImRyYWZ0LWlldGYtc2lwLTE5OS0w NSI8L0ZPTlQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPg0KICAgICAgPFRBQkxFPg0KICAgICAg ICA8VEJPRFk+DQogICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgIDxURD4NCiAgICAg ICAgICA8VEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxC Uj48QlI+PEJSPjxUVD48Rk9OVCANCnNpemU9Mj5IaSw8QlI+PEJSPiZndDtJIHN0aWxsIGhhdmUg c29tZSBkaWZmaWN1bHQgaW4gdXNpbmcgSUVURiBhbmQgY2Fubm90IGZpbmQgDQp0aGUgd2hvbGU8 QlI+c29ydGVkIGNvbW1lbnRzIGFib3V0IHRoaXMgZHJhZnQsIHNvIGkgaGF2ZSBzb21lIGRvdWJ0 IGFib3V0IHRoaXMgDQpkcmFmdC48QlI+Jmd0OzxCUj4mZ3Q7ICZuYnNwOyAxLiAmbmJzcDsgIklm IGEgZm9ya2luZyBwcm94eSByZWNlaXZlcyBhIHJlbGlhYmx5IA0Kc2VudCAxOTkgcmVzcG9uc2Ug Zm9yIGE8QlI+ZGlhbG9nLCBmb3Igd2hpY2ggdGhlIHByb3h5IGhhcyBwcmV2aW91c2x5IGdlbmVy YXRlZCANCmFuZCBzZW50IGEgMTk5PEJSPnJlc3BvbnNlLCB0aGUgcHJveHkgTVVTVCBmb3J3YXJk IHRoZSAxOTkgDQpyZXNwb25zZS4iPEJSPiZndDs8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7IERvZXMg aXQgZGVzY3JpYmUgdGhlIGNhc2UgYmVsb3c/IA0KQWx0aG91Z2ggUDEgaGF2ZSBzZW50IGEgMTk5 PEJSPnJlc3BvbnNlLCBQMSBoYXZzIHRvICZuYnNwO2ZvcndvcmQgdGhlIHNlbmQgDQpyZWxpYWJs eSAxOTkgdG9vLk9yICZuYnNwO2lzIHRoZTxCUj5maXJzdCAxOTkgbWlzdGFrZWQgZm9yIDE4eD88 QlI+Jmd0OzxCUj4mZ3Q7IA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1VBQyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiZuYnNwOyBQMSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KJm5i c3A7VUFTXzI8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Oy0tLSBJTlZJVEUgDQotLS0tLS0mZ3Q7PEJSPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IC0tLSBJTlZJVEUgKGxlZyAyKSAtJmd0OzxCUj4mZ3Q7IA0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7LS0gMTk5KGxlZyAyKSAt LTxCUj4mZ3Q7ICZuYnNwOyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsgJm5ic3A7ICZs dDstLSAxOTkgKGxlZyAyKSAtLS0tLTxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyANCiZuYnNwOyAmbmJzcDsmbHQ7LS0gMTk5KGxlZyAyKSAtLTxCUj48QlI+Jmd0O0kgdGhpbmsg aXQgc2hhbGwgYmUgMTk5LCBhcyANCmN1cnJlbnRseSB3cml0dGVuLjxCUj4mZ3Q7IDxCUj4mZ3Q7 W0VyaWNdOiBJZiAmbmJzcDt0aGlzIGlzIDE5OSwgdGhlbiBJcyB0aGVyZSBhIA0Kc3BlY2lhbCBw dXJwb3NlIHRvIHNlbmQgdHdvPEJSPjE5OSBpbiB0aGUgc2FtZSBkaWFsb2c/PEJSPiZndDtJIHRo aW5rIHRoYXQgb25lIA0KMTk5IGlzIGVub3VnaC48QlI+Jmd0O0FuZCAmbmJzcDt0aGUgZmlyc3Qg MTk5IG1heSBiZSByZWxpYWJsZSB0b28sIHRoYXQgd2lsbCANCm1ha2UgaXQgYSBsaXR0bGU8QlI+ ZGlmZmljdWx0IHRvIHNlbmQgdGhlIHNlY29uZCAxOTkuPEJSPjxCUj5UaGUgc2Vjb25kIDE5OSAN CmNvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gd2hpY2ggaXMgdG8gYmUgZm9yd2FyZGVkIHRvIA0K dGhlPEJSPlVBQy48QlI+PEJSPjxCUj4mZ3Q7Mi4gJm5ic3A7IjEwLiAmbmJzcDtVc2FnZSB3aXRo IDEwMHJlbDxCUj4mZ3Q7PEJSPiZndDsgDQombmJzcDsgV2hlbiBhIDE5OSBFYXJseSBEaWFsb2cg VGVybWluYXRlZCBwcm92aXNpb25hbCByZXNwb25zZSBpcyBzZW50IGJ5IA0KYTxCUj5VQVMsIHNp bmNlIHRoZSBwcm92aXNpb25hbCByZXNwb25zZSBpcyBvbmx5IHVzZWQgZm9yIA0KaW5mb3JtYXRp b248QlI+cHVycG9zZSwgdGhlIFVBUyBTSE9VTEQgc2VuZCBpdCB1bnJlbGlhYmx5IGV2ZW4gaWYg dGhlIA0KMTAwcmVsPEJSPiZndDsgJm5ic3A7IG9wdGlvbiB0YWcgW1JGQzMyNjJdIGlzIHByZXNl bnQgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIG9mIA0KdGhlPEJSPmFzc29jaWF0ZWQgcmVxdWVzdC4i PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7SSBoYXZlIHNlZW4gYSBjb21tZW50IG9uIHRoaXMgDQpx dWVzdGlvbixidXQgc3RpbGwgbm90IHVuZGVyc3Rvb2QgYWJvdXQ8QlI+Jmd0O2l0LiBJZiB0aGUg SU5WSVRFIGhhcyBhIFJlcXVpcmUgDQp0YWcgIlJlcXVpcmU6IDEwMHJlbCIsZG9lcyB0aGUgVUFT PEJSPnN0aWxsPEJSPiZndDt1c2UgdW5yZWxpYWJsZSAxOTkgDQpyZXNwb25zZT88QlI+Jmd0OzxC Uj4mZ3Q7VGhhdCBpcyB0aGUgcmVjb21tZW5kYXRpb24sIHllcy4gVGhlIHJlYXNvbnMgaXMgdGhh dCB3ZSANCndhbnQgdG8ga2VlcDxCUj4xOTk8QlI+Jmd0O2FzICJsaWdodHdlaWdodCIgYXMgcG9z c2libGUsIHdpdGhvdXQgcmVxdWlyZWluZyANCnJlLXRyYW5zbWlzc2lvbnMgYW5kPEJSPiZndDtQ UkFDS3MuPEJSPiZndDsgPEJSPiZndDtbRXJpY106IEJ1dCByZWxpYWJsZSAxOTkgDQpoYXZlIG1v cmUgYWR2YW50YWdlLCBhbmQgSXQgaXMgd29ydGggdG8gdXNlPEJSPnRoZSByZWxpYWJsZSAxOTks SSANCnRoaW5rLjxCUj48QlI+SSBkb24ndCBrbm93IHdoYXQgdGhhdCBhZHZhbnRhZ2Ugd291bGQg YmUsIGNvbXBhcmVkIHRvIGhhdmluZyB0byANCnNlbmQ8QlI+UFJBQ0tzIGV0Yy4gVGhpcyBoYXMg YmVlbiBkaXNjdXNzZWQgcXVpdGUgbXVjaCwgc28gSSB3b3VsZCByZWFsbHkgDQpuZWVkPEJSPnNv bWUgZ29vZCBqdXN0aWZpY2F0aW9uIHRvIGNoYW5nZSBpdCBub3cuPEJSPjxCUj5BbHNvLCB0aGUg ZHJhZnQgZG9lc24ndCANCmZvcmJpZCB5b3UgdG8gc2VuZCB0aGUgMTk5IHJlbGlhYmx5LiBJdCdz IG9ubHkgYTxCUj5TSE9VTEQuPEJSPjxCUj48QlI+Jmd0O0lmIA0KMTk5IGlzIHJlbGlhYmxlLCB0 aGVyZSBpcyBvbmUgbW9yZSBhZHZhbnRhZ2UuIElmIHRoZSAxOTkgYXJyaXZlczxCUj4mZ3Q7YmVm b3JlIA0KdGhlIGZpcnN0IDE4eCByZXNwb25zZSwgVUFDIGNhbiBkaXNjYXJkIHRoZSBmaXJzdCAx OTkgYW5kPEJSPnByb2Nlc3M8QlI+Jmd0O2l0IA0KdW50aWwgVUFDIHJlY2VpdmVzIHRoZSBmaXJz dCAxOHggcmVzcG9uc2UgdGhhdCBoYXMgdGhlIHNhbWU8QlI+Jmd0O3RvLXRhZyBhcyANCjE5OSwg YXMgdGhlIHJlbGlhYmxlIDE5OSBzaG91bGQgYmUgcmUtdHJhbnNtaXRlZCB1bnRpbDxCUj4mZ3Q7 cmVjZWl2ZWQgDQpQUkFDSy48QlI+Jmd0OzxCUj4mZ3Q7SWYgdGhlIElOVklURSBjb250YWlucyAi UmVxdWlyZTogMTAwcmVsIiwgdGhlIGZpcnN0IDE4eCANCm11c3QgYWxzbyBiZTxCUj4mZ3Q7c2Vu dCByZWxpYWJseS4gQW5kLCBJIGRvbid0IHRoaW5rIHRoZSBVQVMgaXMgYWxsb3dlZCB0byBzZW5k IA0KYW5vdGhlcjxCUj4mZ3Q7cmVsaWFibGUgcmVzcG9uc2UgdW50aWwgdGhlIGZpcnN0IG9uZSBp cyBhY2tub3dsZWRnZWQsIHNvIEkgZG9uJ3QgDQp0aGluazxCUj4mZ3Q7YSByZWxpYWJsZSAxOTkg d291bGQgcmVhY2ggdGhlIFVBQyBiZWZvcmUgdGhlIGZpcnN0IHJlbGlhYmxlIA0KMTh4LjxCUj4m Z3Q7IDxCUj4mZ3Q7W0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5v dGhlciByZWxpYWJsZSANCnJlc3BvbnNlPEJSPnVudGlsIHRoZSBmaXJzdCBvbmUgaXMgYWNrbm93 bGVkZ2VkLDxCUj48QlI+SWYgSSByZW1lbWJlciBjb3JyZWN0bHksIA0KdGhlIEZJUlNUIHJlbGlh YmxlIHJlc3BvbnNlIG11c3QgYmUgYWNrbm93bGVkZWQ8QlI+YmVmb3JlIHRoZSBuZXh0IHJlbGlh YmxlIA0KcmVzcG9uc2UgaXMgc2VudC4gQnV0LCB3ZSBjYW4gZG91YmxlIGNoZWNrIGluPEJSPnRo ZSBQUkFDSyBzcGVjLjxCUj48QlI+Jmd0O2J1dCANCnJlbGlhYmxlIDE5OSB3aWxsIGJlIHVzZWZ1 bCBpZiB0aGUgZmlyc3QgMTh4IGlzIHVucmVsaWFibGUsIG9yIHRoZTxCUj5maXJzdCAxOHggDQpo YXMgYmVlbiBhY2tud2xlZGdlZC4gSXQncyBhbm90aGVyIGNhc2UgZGlmZmVyZW50IGZyb20gdGhl PEJSPmFib3ZlIG9uZSANCiZuYnNwO3dob3NlIElOVklURSBjb250YWlucyAicmVxdWlyZTogMTAw cmVsIi48QlI+PEJSPklmIDEwMHJlbCBpcyByZXF1aXJlZCB0aGUgDQoxOHggY2Fubm90IGJlIA0K dW5yZWxpYWJsZS48QlI+PEJSPlJlZ2FyZHMsPEJSPjxCUj5DaHJpc3RlcjxCUj48QlI+PEJSPjxC Uj48QlI+PEJSPjxCUj48QlI+PEJSPjwvRk9OVD48L1RUPjxCUj48QlI+PFBSRT4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7 SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZv cm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtp cyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIn cyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRp b24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQm bmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4m bmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5i c3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0 aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2Vt YWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dp dGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVu ZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20m bmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7 aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJv ciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNz ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVz c2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNl cyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNw O3N5c3RlbS4NCjwvUFJFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C998A2.7CC06068-- From christer.holmberg@ericsson.com Thu Feb 26 22:23:01 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72FF13A688E for ; Thu, 26 Feb 2009 22:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.155 X-Spam-Level: X-Spam-Status: No, score=-5.155 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWKFcP7tAqf9 for ; Thu, 26 Feb 2009 22:22:59 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2563C3A67F3 for ; Thu, 26 Feb 2009 22:22:43 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 41C53203C5; Fri, 27 Feb 2009 07:23:04 +0100 (CET) X-AuditID: c1b4fb3e-ab899bb0000023da-cd-49a786c887df Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1A21120275; Fri, 27 Feb 2009 07:23:04 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 07:23:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C998A3.D7D171BC" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Feb 2009 07:23:02 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?UTF-8?B?UmU6IFtTaXBdIOetlOWkjTogUkU6IFF1ZXN0aW9ucyBhYm91?= =?UTF-8?B?dCAiZHJhZnQtaWV0Zi1zaXAtMTk5LTA1Ig==?= Thread-Index: AcmYlT4TwOktR8qZQ9CJaVFVOalgwgADb+5g References: <49A7484B.3060407@cisco.com> From: "Christer Holmberg" To: , "Paul Kyzivat" X-OriginalArrivalTime: 27 Feb 2009 06:23:02.0842 (UTC) FILETIME=[D80A61A0:01C998A3] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] =?utf-8?b?562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1p?= =?utf-8?q?etf-sip-199-05=22?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 06:23:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C998A3.D7D171BC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQogIA0KPlByYWN0aWNhbGx5LCB3aGVuIENhbGwgZm9yd2FyZCBhbmQgZm9yayBhcmUgdXNl ZCBpbiB0aGUgc2FtZSBzeXN0ZW0sIHRoZXJlIGFyZSANCj5sb3RzIG9mIGVhcmx5IGRpYWxvZ3Mg dGhhdCBzaG91bGQgYmUgZWxpbWluYXRlZCBieSAxOTkgZXhpc3RlZC4gDQo+U28gSSB0aGluayB0 aGF0IGl0J3MgdXNlZnVsIHRvIGxldCAxOTkgcmVsaWFibGUuIA0KPkFuZCB3ZSBqdXN0IGFkZGVk IGZvcmstc2VydmljZSB0byBvdXIgc3lzdGVtICxhbmQgZmluZCAxOTkgaXMgcmVhbGx5IHVzZWZ1 bCwgYW5kIA0KPmlmIHRoZSAxOTkgaXMgbWlzc2luZywgcHJvYmxlbXMgd2lsbCBoYXBwZW4uICAN CiANCkknbSBnbGFkIHlvdSB0aGluayAxOTkgaXMgdXNlZnVsIDopDQogDQpCdXQsIGlmIGEgcHJv eHkgd291bGQgaGF2ZSB0byB0ZXJtaW5hdGUgUFJBQ0tzIGV0YyBpdCB3b3VsZCBub3QgYmUgYSBw cm94eSBhbnltb3JlIC0gaXQgd291bGQgYmUgYSBCMkJVQS4NCiANClNvLCBpZiB5b3UgcmVhbGx5 IHdhbnQgeW91ciBuZXR3b3JrIHRvIHNlbmQgMTk5IHJlbGlhYmx5LCBJIGd1ZXNzIHlvdSBjb3Vs ZCB1c2UgYSBCMkJVQSBpbnN0ZWFkIG9mIGEgcHJveHkuDQoNCj5JdCBzb3VuZHMgZ29vZCB0aGF0 IHRoZXJlIGlzIGEgd2F5IHRvIHByZXZlbnQgUFJBQ0sgYWRkcmVzc2VkIHRvIFVBUyxidXQgaSBk b24ndCBrbm93ICBob3cgdG8gZG8gbm93LiANCiANClRoZSBvbmx5IHdheSB0byBwcmV2ZW50IGl0 IGlzIGJ5IHRoZSBwcm94eSBub3Qgc2VuZGluZyB0aGUgMTk5IHJlbGFpYmxlLiAgDQogICAgDQo+ cHM6IA0KPlJGQzMyNjEgMTYuNyBSZXNwb25zZSBQcm9jZXNzaW5nIA0KPlNpbmNlIGEgcHJveHkg bWF5IG5vdCBpbnNlcnQgYSB0YWcgaW50byB0aGUgVG8gaGVhZGVyIGZpZWxkIG9mIA0KPmEgMXh4 IHJlc3BvbnNlIHRvIGEgcmVxdWVzdCB0aGF0IGRpZCBub3QgY29udGFpbiBvbmUsIGl0IGNhbm5v dCANCj5pc3N1ZSBub24tMTAwIHByb3Zpc2lvbmFsIHJlc3BvbnNlcyBvbiBpdHMgb3duLiAgDQog DQpZZXMsIGJ1dCBJIHdlIGhhdmUgYWdyZWVkIHRoYXQgYSBwcm94eSBpcyBhbGxvd2VkIHRvIHNl bmQgMTk5Lg0KIA0KQnV0LCB0aGUgcHJveHkgaXMgbm90IGdvaW5nIHRvIGdlbmVyYXRlIG5ldyBU byBoZWFkZXIgdGFnIHZhbHVlcyBmb3IgdGhlIDE5OS4gSXQgd2lsbCB1c2Ugd2hhdGV2ZXIgdGFn cyB0aGF0IGhhdmUgYWxyZWFkeSBiZWVuIGNyZWF0ZWQgZm9yIHRoZSBlYXJseSBkaWFsb2dzLiAN CiANClJlZ2FyZHMsDQogDQpDaHJpc3Rlcg0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KDQoq YWxsb3dpbmcqIChtdWNoIGxlc3MgKnJlcXVpcmluZyopIHRoZSAxOTkgdG8gYmUgcmVsaWFibGUg aW50cm9kdWNlcw0KbmFzdHkgcHJvYmxlbXMuIFRoZSAxOTkgaXMgb25seSBhbiBvcHRpbWl6YXRp b24sIHNvIGhhdmluZyBpdCBiZQ0KdW5yZWxpYWJsZSBpcyBvayBJTU8uDQoNClRoZSBwcm9ibGVt IGlzIHRoYXQgaWYgYSBwcm94eSBzZW5kcyB0aGUgMTk5LCB0aGVuIHRoZSByZWNpcGllbnQgb2Yg dGhlDQpQUkFDSyBzaG91bGQgYmUgdGhlIHByb3h5LiBCdXQgdGhlIFBSQUNLIGlzIGFuIGluLWRp YWxvZyBtZXNzYWdlLCBzbyBpdA0KbXVzdCBiZSBhZGRyZXNzZWQgdG8gdGhlIENvbnRhY3Qgb2Yg dGhlIFVBUy4NCg0KSWYgdGhlIHByb3h5IHNlbmRzIGEgcmVsaWFibGUgMTk5LCBhbmQgdGhlIFBS QUNLIGlzIGFkZHJlc3NlZCB0byB0aGUNClVBUywgdGhlIFVBUyB3aWxsIGJlIHZlcnkgc3VycHJp c2VkLCBzaW5jZSBpdCBoYXMgbm90IHNlbmQgYSByZWxpYWJsZQ0KcHJvdmlzaW9uYWwsIGFuZCBp cyBzbyBub3QgZXhwZWN0aW5nIGEgUFJBQ0suIEluIGZhY3QsIGl0IGhhcyBzZW50IGENCmZpbmFs IHJlc3BvbnNlLCBoYXMgcHJlc3VtYWJseSBhbHJlYWR5IHJlY2VpdmVkIHRoZSBBQ0ssIGFuZCBz byBpcw0KZXhwZWN0aW5nIG5vdGhpbmcuDQoNClZlcnkgdWdseS4NCg0KICAgICAgICAgICAgICAg IFBhdWwNCg0Kd2FuZy5saWJvQHp0ZS5jb20uY24gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IEFu ZCB0aGVyZSBzdGlsbCB0d28gcXVlc3Rpb25zIGxlZnQuDQo+IA0KPiAxLiAgSXMgdGhlIDE5OSBz aG91bGQgYmUgcmVsaWFibGUgb3IgdW5yZWxpYWJsZT8NCj4gICAgIEkgdGhpbmsgdGhhdCAxOTkg c2hvdWxkIGJlIHJlbGlhYmxlIGlmIHBvc3NpYmxlLg0KPiANCj4gDQo+ICAgIEZpcnN0LCBJZiBh IGNsaWVudCByZWNlaXZlcyBhbiB1bnJlbGlhYmxlIDE5OSByZXNwb25zZSBvbiBhIGRpYWxvZyAN Cj4gd2hpY2ggaGFzDQo+ICAgIG5vdCBwcmV2aW91c2x5IGJlZW4gY3JlYXRlZCAodGhpcyBjYW4g aGFwcGVuIGlmIGEgMTk5IHJlc3BvbnNlDQo+ICAgIHJlYWNoZXMgdGhlIGNsaWVudCBiZWZvcmUg YSAxOHggcmVzcG9uc2UpIHRoZSBjbGllbnQgU0hBTEwgZGlzY2FyZA0KPiAgICB0aGUgMTk5IHJl c3BvbnNlcy4NCj4gDQo+ICAgIFRoZSBmaWd1cmUgYmVsb3cgc2hvd3MgYW4gZXhhbXBsZS5UaGUg MTgwIGlzIHNlbnQgZmlyc3QgYnV0IGFycml2ZXMgDQo+IGxhdGVyIHRoYW4gMTk5Lg0KPiBJZiB0 aGUgMTk5IGlzIHJlbGlhYmxlLCB0aGUgcHJveHkgc2hvdWxkIHJldHJhbnNtaXQgMTk5IChzdGVw IDQpLGFuZCANCj4gdGhlbiB0aGUgcmV0cmFuc21pdHRlZA0KPiAxOTkgd2lsbCBiZSBhY2NlcHRl ZCBieSBVQUMsYW5kIHRoZSBlYXJseSBkaWFsb2cgd2lsbCBiZSB0ZW1pbmF0ZWQuDQo+IA0KPiBV QUMgICAgICAgICAgICAgUA0KPiAgICAxLiBJTlZJVEUNCj4gLS0tLS0tLS0tLS0tLS0tPg0KPiAg ICAgICAgICAgMi4gMTgwDQo+IDwtLS0tLSBcLy0tLS0tLS0NCj4gICAgICAgIC9cIDMuIDE5OQ0K PiA8LS0tLS0vICBcLS0tLS0tDQo+ICAgICAgICAgICA0LiAxOTkocmV0cmFuc21pdHRlZCkNCj4g PC0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gICAgc2Vjb25kLCBBY2NvcmRpbmcgdG8gcHJhY3RpY2Fs IHVzZSwgMTk5IGNhbiBiZSBpbnRlbmRlZCB0byB0ZW1pbmF0ZSANCj4gb25lIGVhcmx5IGRpYWxv ZyBhbmQgcmVsZWFzZQ0KPiByZXNvdXJjZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBzcGVjaWZpYyBl YXJseSBkaWFsb2csIHNvIHRoZSBjb3N0IHNwZW50IA0KPiBvbiByZWxpYWJsZSAxOTkgaXMgd29y dGh5Lg0KPiBJZiB0aGUgMTk5IGNhbm5vdCBiZSBzZW50IHJlbGlhYmxlLHRoZW4gd2Ugc2hvdWxk IHNlbmQgaXQgdW5yZWxpYWJsZS4NCj4gIA0KPiAyLiBJbiB5b3VyIGxhc3QgbGV0dGVyLCB5b3Ug c2FpZCAidGhlIHNlY29uZCAxOTkgY291bGQgaW5jbHVkZSANCj4gaW5mb3JtYXRpb24gd2hpY2gg aXMgdG8gYmUgZm9yd2FyZGVkIHRvIHRoZQ0KPiBVQUMiLCB0aGVuIGRvIHlvdSBtZWFuLCB0aGUg ZWFybHkgZGlhbG9nIGlzIHN0aWxsIGFsaXZlIGFmdGVyIHRoZSBmaXJzdCANCj4gMTk5IGlzIGFj Y2VwdGVkPw0KPiANCj4gDQo+IEFsc28sIEluIG15IGxhc3QgbGV0dGVyLCBJIG1pc3MgYSAiTk9U IiBieSBtaXN0YWtlLg0KPiBJdCBzaG91bGQgYmUNCj4gW0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBp cyBOT1QgYWxsb3dlZCB0byBzZW5kIGFub3RoZXIgcmVsaWFibGUgcmVzcG9uc2UNCj4gdW50aWwg dGhlIGZpcnN0IG9uZSBpcyBhY2tub3dsZWRnZWQuLi4NCj4gDQo+IFJlZ2FyZHMsDQo+IEVyaWMg d2FuZw0KPiANCj4gDQo+IA0KPiANCj4gKiJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4qDQo+IA0KPiAyMDA5LTAyLTI3IDAzOjA0DQo+IA0KPiAgICAg ICAgICAgICAgICAgIA0KPiDmlLbku7bkuroNCj4gICAgICAgICAgICAgICAgICAiRXJpYyB3YW5n IiA8ZXJpYy53YW5neHJAZ21haWwuY29tPg0KPiDmioTpgIENCj4gICAgICAgICAgICAgICAgICA8 c2lwQGlldGYub3JnPiwgPHdhbmcubGlib0B6dGUuY29tLmNuPg0KPiDkuLvpopgNCj4gICAgICAg ICAgICAgICAgICBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1pZXRmLXNpcC0xOTktMDUiDQo+ IA0KPiANCj4gICAgICAgICAgICAgICAgICANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBIaSwNCj4g DQo+ICA+SSBzdGlsbCBoYXZlIHNvbWUgZGlmZmljdWx0IGluIHVzaW5nIElFVEYgYW5kIGNhbm5v dCBmaW5kIHRoZSB3aG9sZQ0KPiBzb3J0ZWQgY29tbWVudHMgYWJvdXQgdGhpcyBkcmFmdCwgc28g aSBoYXZlIHNvbWUgZG91YnQgYWJvdXQgdGhpcyBkcmFmdC4NCj4gID4NCj4gID4gICAxLiAgICJJ ZiBhIGZvcmtpbmcgcHJveHkgcmVjZWl2ZXMgYSByZWxpYWJseSBzZW50IDE5OSByZXNwb25zZSBm b3IgYQ0KPiBkaWFsb2csIGZvciB3aGljaCB0aGUgcHJveHkgaGFzIHByZXZpb3VzbHkgZ2VuZXJh dGVkIGFuZCBzZW50IGEgMTk5DQo+IHJlc3BvbnNlLCB0aGUgcHJveHkgTVVTVCBmb3J3YXJkIHRo ZSAxOTkgcmVzcG9uc2UuIg0KPiAgPg0KPiAgPiAgICAgRG9lcyBpdCBkZXNjcmliZSB0aGUgY2Fz ZSBiZWxvdz8gQWx0aG91Z2ggUDEgaGF2ZSBzZW50IGEgMTk5DQo+IHJlc3BvbnNlLCBQMSBoYXZz IHRvICBmb3J3b3JkIHRoZSBzZW5kIHJlbGlhYmx5IDE5OSB0b28uT3IgIGlzIHRoZQ0KPiBmaXJz dCAxOTkgbWlzdGFrZWQgZm9yIDE4eD8NCj4gID4NCj4gID4gICAgICAgICAgVUFDICAgICAgICAg ICAgICAgUDEgICAgICAgICAgICAgICAgICBVQVNfMg0KPiAgPiAgICAgICAgICAgIC0tLSBJTlZJ VEUgLS0tLS0tPg0KPiAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tIElOVklURSAo bGVnIDIpIC0+DQo+ICA+ICAgICAgICAgICAgPC0tIDE5OShsZWcgMikgLS0NCj4gID4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDwtLSAxOTkgKGxlZyAyKSAtLS0tLQ0KPiAgPiAgICAgICAg ICAgIDwtLSAxOTkobGVnIDIpIC0tDQo+IA0KPiAgPkkgdGhpbmsgaXQgc2hhbGwgYmUgMTk5LCBh cyBjdXJyZW50bHkgd3JpdHRlbi4NCj4gID4NCj4gID5bRXJpY106IElmICB0aGlzIGlzIDE5OSwg dGhlbiBJcyB0aGVyZSBhIHNwZWNpYWwgcHVycG9zZSB0byBzZW5kIHR3bw0KPiAxOTkgaW4gdGhl IHNhbWUgZGlhbG9nPw0KPiAgPkkgdGhpbmsgdGhhdCBvbmUgMTk5IGlzIGVub3VnaC4NCj4gID5B bmQgIHRoZSBmaXJzdCAxOTkgbWF5IGJlIHJlbGlhYmxlIHRvbywgdGhhdCB3aWxsIG1ha2UgaXQg YSBsaXR0bGUNCj4gZGlmZmljdWx0IHRvIHNlbmQgdGhlIHNlY29uZCAxOTkuDQo+IA0KPiBUaGUg c2Vjb25kIDE5OSBjb3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIHdoaWNoIGlzIHRvIGJlIGZvcndh cmRlZCB0byB0aGUNCj4gVUFDLg0KPiANCj4gDQo+ICA+Mi4gICIxMC4gIFVzYWdlIHdpdGggMTAw cmVsDQo+ICA+DQo+ICA+ICAgV2hlbiBhIDE5OSBFYXJseSBEaWFsb2cgVGVybWluYXRlZCBwcm92 aXNpb25hbCByZXNwb25zZSBpcyBzZW50IGJ5IGENCj4gVUFTLCBzaW5jZSB0aGUgcHJvdmlzaW9u YWwgcmVzcG9uc2UgaXMgb25seSB1c2VkIGZvciBpbmZvcm1hdGlvbg0KPiBwdXJwb3NlLCB0aGUg VUFTIFNIT1VMRCBzZW5kIGl0IHVucmVsaWFibHkgZXZlbiBpZiB0aGUgMTAwcmVsDQo+ICA+ICAg b3B0aW9uIHRhZyBbUkZDMzI2Ml0gaXMgcHJlc2VudCBpbiB0aGUgUmVxdWlyZSBoZWFkZXIgb2Yg dGhlDQo+IGFzc29jaWF0ZWQgcmVxdWVzdC4iDQo+ICA+DQo+ICA+DQo+ICA+SSBoYXZlIHNlZW4g YSBjb21tZW50IG9uIHRoaXMgcXVlc3Rpb24sYnV0IHN0aWxsIG5vdCB1bmRlcnN0b29kIGFib3V0 DQo+ICA+aXQuIElmIHRoZSBJTlZJVEUgaGFzIGEgUmVxdWlyZSB0YWcgIlJlcXVpcmU6IDEwMHJl bCIsZG9lcyB0aGUgVUFTDQo+IHN0aWxsDQo+ICA+dXNlIHVucmVsaWFibGUgMTk5IHJlc3BvbnNl Pw0KPiAgPg0KPiAgPlRoYXQgaXMgdGhlIHJlY29tbWVuZGF0aW9uLCB5ZXMuIFRoZSByZWFzb25z IGlzIHRoYXQgd2Ugd2FudCB0byBrZWVwDQo+IDE5OQ0KPiAgPmFzICJsaWdodHdlaWdodCIgYXMg cG9zc2libGUsIHdpdGhvdXQgcmVxdWlyZWluZyByZS10cmFuc21pc3Npb25zIGFuZA0KPiAgPlBS QUNLcy4NCj4gID4NCj4gID5bRXJpY106IEJ1dCByZWxpYWJsZSAxOTkgaGF2ZSBtb3JlIGFkdmFu dGFnZSwgYW5kIEl0IGlzIHdvcnRoIHRvIHVzZQ0KPiB0aGUgcmVsaWFibGUgMTk5LEkgdGhpbmsu DQo+IA0KPiBJIGRvbid0IGtub3cgd2hhdCB0aGF0IGFkdmFudGFnZSB3b3VsZCBiZSwgY29tcGFy ZWQgdG8gaGF2aW5nIHRvIHNlbmQNCj4gUFJBQ0tzIGV0Yy4gVGhpcyBoYXMgYmVlbiBkaXNjdXNz ZWQgcXVpdGUgbXVjaCwgc28gSSB3b3VsZCByZWFsbHkgbmVlZA0KPiBzb21lIGdvb2QganVzdGlm aWNhdGlvbiB0byBjaGFuZ2UgaXQgbm93Lg0KPiANCj4gQWxzbywgdGhlIGRyYWZ0IGRvZXNuJ3Qg Zm9yYmlkIHlvdSB0byBzZW5kIHRoZSAxOTkgcmVsaWFibHkuIEl0J3Mgb25seSBhDQo+IFNIT1VM RC4NCj4gDQo+IA0KPiAgPklmIDE5OSBpcyByZWxpYWJsZSwgdGhlcmUgaXMgb25lIG1vcmUgYWR2 YW50YWdlLiBJZiB0aGUgMTk5IGFycml2ZXMNCj4gID5iZWZvcmUgdGhlIGZpcnN0IDE4eCByZXNw b25zZSwgVUFDIGNhbiBkaXNjYXJkIHRoZSBmaXJzdCAxOTkgYW5kDQo+IHByb2Nlc3MNCj4gID5p dCB1bnRpbCBVQUMgcmVjZWl2ZXMgdGhlIGZpcnN0IDE4eCByZXNwb25zZSB0aGF0IGhhcyB0aGUg c2FtZQ0KPiAgPnRvLXRhZyBhcyAxOTksIGFzIHRoZSByZWxpYWJsZSAxOTkgc2hvdWxkIGJlIHJl LXRyYW5zbWl0ZWQgdW50aWwNCj4gID5yZWNlaXZlZCBQUkFDSy4NCj4gID4NCj4gID5JZiB0aGUg SU5WSVRFIGNvbnRhaW5zICJSZXF1aXJlOiAxMDByZWwiLCB0aGUgZmlyc3QgMTh4IG11c3QgYWxz byBiZQ0KPiAgPnNlbnQgcmVsaWFibHkuIEFuZCwgSSBkb24ndCB0aGluayB0aGUgVUFTIGlzIGFs bG93ZWQgdG8gc2VuZCBhbm90aGVyDQo+ICA+cmVsaWFibGUgcmVzcG9uc2UgdW50aWwgdGhlIGZp cnN0IG9uZSBpcyBhY2tub3dsZWRnZWQsIHNvIEkgZG9uJ3QgdGhpbmsNCj4gID5hIHJlbGlhYmxl IDE5OSB3b3VsZCByZWFjaCB0aGUgVUFDIGJlZm9yZSB0aGUgZmlyc3QgcmVsaWFibGUgMTh4Lg0K PiAgPg0KPiAgPltFcmljXTogU3VyZWx5IHRoZSBVQVMgaXMgYWxsb3dlZCB0byBzZW5kIGFub3Ro ZXIgcmVsaWFibGUgcmVzcG9uc2UNCj4gdW50aWwgdGhlIGZpcnN0IG9uZSBpcyBhY2tub3dsZWRn ZWQsDQo+IA0KPiBJZiBJIHJlbWVtYmVyIGNvcnJlY3RseSwgdGhlIEZJUlNUIHJlbGlhYmxlIHJl c3BvbnNlIG11c3QgYmUgYWNrbm93bGVkZWQNCj4gYmVmb3JlIHRoZSBuZXh0IHJlbGlhYmxlIHJl c3BvbnNlIGlzIHNlbnQuIEJ1dCwgd2UgY2FuIGRvdWJsZSBjaGVjayBpbg0KPiB0aGUgUFJBQ0sg c3BlYy4NCj4gDQo+ICA+YnV0IHJlbGlhYmxlIDE5OSB3aWxsIGJlIHVzZWZ1bCBpZiB0aGUgZmly c3QgMTh4IGlzIHVucmVsaWFibGUsIG9yIHRoZQ0KPiBmaXJzdCAxOHggaGFzIGJlZW4gYWNrbnds ZWRnZWQuIEl0J3MgYW5vdGhlciBjYXNlIGRpZmZlcmVudCBmcm9tIHRoZQ0KPiBhYm92ZSBvbmUg IHdob3NlIElOVklURSBjb250YWlucyAicmVxdWlyZTogMTAwcmVsIi4NCj4gDQo+IElmIDEwMHJl bCBpcyByZXF1aXJlZCB0aGUgMTh4IGNhbm5vdCBiZSB1bnJlbGlhYmxlLg0KPiANCj4gUmVnYXJk cywNCj4gDQo+IENocmlzdGVyDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQo+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCj4gVGhpcyBt ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt U3BhbSBzeXN0ZW0uDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTaXAgbWFpbGluZyBsaXN0 ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KPiBUaGlzIGxpc3Qg aXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCj4gVXNlIHNp cC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBz aXANCj4gVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFw cGxpY2F0aW9uIG9mIHNpcA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K ------_=_NextPart_001_01C998A3.D7D171BC Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjM3OTAuNDQyNiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz02ODU1NjE2MDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1B cmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+Jm5ic3A7Jm5ic3A7PC9GT05UPjxCUj48Rk9O VCBmYWNlPUFyaWFsPjxGT05UIA0Kc2l6ZT0yPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAw OT48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIA0KY29sb3I9IzAwMDAwMD4mZ3Q7PC9GT05UPjwv Rk9OVD48L1NQQU4+UHJhY3RpY2FsbHksIHdoZW4gQ2FsbCBmb3J3YXJkIGFuZCBmb3JrIA0KYXJl IHVzZWQgaW4gdGhlIHNhbWUgc3lzdGVtLCB0aGVyZSBhcmUmbmJzcDs8L0ZPTlQ+PC9GT05UPjxC Uj48Rk9OVCANCmZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0y NzAyMjAwOT48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIA0KY29sb3I9IzAwMDAwMD4mZ3Q7PC9G T05UPjwvRk9OVD48L1NQQU4+bG90cyBvZiBlYXJseSBkaWFsb2dzIHRoYXQgc2hvdWxkIGJlIA0K ZWxpbWluYXRlZCBieSAxOTkgZXhpc3RlZC48L0ZPTlQ+PC9GT05UPiZuYnNwOzxCUj48Rk9OVCBm YWNlPUFyaWFsPjxGT05UIA0Kc2l6ZT0yPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48 Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIGZhY2U9IiIgDQpjb2xvcj0jMDAwMDAwIHNpemU9Mz4m Z3Q7PC9GT05UPjwvRk9OVD48L1NQQU4+U28gSSB0aGluayB0aGF0IGl0J3MgdXNlZnVsIHRvIGxl dCANCjE5OSByZWxpYWJsZS4mbmJzcDs8L0ZPTlQ+PC9GT05UPjxCUj48Rk9OVCBmYWNlPUFyaWFs PjxGT05UIHNpemU9Mj48U1BBTiANCmNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48Rk9OVCBjb2xv cj0jMDAwMGZmPjxGT05UIA0KY29sb3I9IzAwMDAwMD4mZ3Q7PC9GT05UPjwvRk9OVD48L1NQQU4+ QW5kIHdlIGp1c3QgYWRkZWQgZm9yay1zZXJ2aWNlIHRvIG91ciANCnN5c3RlbSAsYW5kIGZpbmQg MTk5IGlzIHJlYWxseSB1c2VmdWwsIGFuZDwvRk9OVD48L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIA0K ZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9Njg1NTYxNjA2LTI3MDIyMDA5PjxG T05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpmYWNlPSIiIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiZn dDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj5pZiB0aGUgMTk5IGlzIG1pc3NpbmcsIA0KcHJvYmxlbXMg d2lsbCBoYXBwZW4uPC9GT05UPjwvRk9OVD4mbmJzcDs8U1BBTiBjbGFzcz02ODU1NjE2MDYtMjcw MjIwMDk+PEZPTlQgDQpmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOzwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48L1NQ QU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkknbSANCmdsYWQgeW91IHRoaW5rIDE5 OSBpcyB1c2VmdWwgOik8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz02ODU1 NjE2MDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAy MjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkJ1dCwgDQppZiBhIHBy b3h5IHdvdWxkIGhhdmUgdG8gdGVybWluYXRlIFBSQUNLcyBldGMgaXQgd291bGQgbm90IGJlIGEg cHJveHkgYW55bW9yZSAtIA0KaXQgd291bGQgYmUgYSBCMkJVQS48L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz02ODU1NjE2MDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPlNvLCBpZiANCnlvdSByZWFsbHkgd2FudCB5b3VyIG5ldHdvcmsgdG8gc2VuZCAx OTkgcmVsaWFibHksIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSBhIEIyQlVBIA0KaW5zdGVhZCBvZiBh IHByb3h5LjwvRk9OVD48L1NQQU4+PC9ESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IA0Kc2l6ZT0yPjwvRk9OVD4NCjxESVY+PEJSPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0y PjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48Rk9OVCANCmNvbG9yPSMwMDAwZmY+Jmd0 OzwvRk9OVD48L1NQQU4+SXQgc291bmRzIGdvb2QgdGhhdCB0aGVyZSBpcyBhIHdheSB0byBwcmV2 ZW50IA0KUFJBQ0sgYWRkcmVzc2VkIHRvIFVBUyxidXQgaSBkb24ndCBrbm93PFNQQU4gY2xhc3M9 Njg1NTYxNjA2LTI3MDIyMDA5PjxGT05UIA0KY29sb3I9IzAwMDBmZj4mbmJzcDsgPC9GT05UPjwv U1BBTj5ob3cgdG8gZG8gbm93LjxTUEFOIA0KY2xhc3M9Njg1NTYxNjA2LTI3MDIyMDA5PjxGT05U IA0KY29sb3I9IzAwMDBmZj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9Njg1NTYx NjA2LTI3MDIyMDA5PjwvU1BBTj48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz02ODU1NjE2MDYtMjcwMjIwMDk+ PEZPTlQgDQpjb2xvcj0jMDAwMGZmPlRoZSBvbmx5IHdheSB0byBwcmV2ZW50IGl0IGlzIGJ5IHRo ZSBwcm94eSBub3Qgc2VuZGluZyB0aGUgDQoxOTkmbmJzcDtyZWxhaWJsZS48L0ZPTlQ+Jm5ic3A7 PC9TUEFOPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIA0KZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj4mbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIGZhY2U9QXJpYWw+ PEZPTlQgDQpzaXplPTI+PFNQQU4gY2xhc3M9Njg1NTYxNjA2LTI3MDIyMDA5PjxGT05UIGNvbG9y PSMwMDAwZmY+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDAgDQpz aXplPTM+Jmd0OzwvRk9OVD48L0ZPTlQ+PC9TUEFOPnBzOjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PEJS PjxGT05UIHNpemU9Mj48Rk9OVCANCmZhY2U9QXJpYWw+PFNQQU4gY2xhc3M9Njg1NTYxNjA2LTI3 MDIyMDA5PjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj5SRkMzMjYxIA0K PC9GT05UPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBjb2xvcj0jMDAyMDQxPjxCPjE2LjcgUmVz cG9uc2UgDQpQcm9jZXNzaW5nPC9CPjwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWY+Jm5ic3A7 PC9GT05UPjwvRk9OVD48QlI+PEZPTlQgDQpmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiBj bGFzcz02ODU1NjE2MDYtMjcwMjIwMDk+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCANCmNvbG9y PSMwMDAwMDA+Jmd0OzwvRk9OVD48L0ZPTlQ+PC9TUEFOPlNpbmNlIGEgcHJveHkgbWF5IG5vdCBp bnNlcnQgYSB0YWcgaW50byANCnRoZSBUbyBoZWFkZXIgZmllbGQgb2Y8L0ZPTlQ+PC9GT05UPiZu YnNwOzxCUj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0Kc2l6ZT0yPjxTUEFOIGNsYXNzPTY4NTU2 MTYwNi0yNzAyMjAwOT48Rk9OVCBjb2xvcj0jMDAwMGZmPiZndDs8L0ZPTlQ+PC9TUEFOPmEgDQox eHggcmVzcG9uc2UgdG8gYSByZXF1ZXN0IHRoYXQgZGlkIG5vdCBjb250YWluIG9uZSwgPEZPTlQg Y29sb3I9Ymx1ZT5pdCANCmNhbm5vdDwvRk9OVD48L0ZPTlQ+PC9GT05UPiZuYnNwOzxCUj48Rk9O VCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpzaXplPTI+PFNQQU4gY2xh c3M9Njg1NTYxNjA2LTI3MDIyMDA5PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9 IzAwMDAwMCANCnNpemU9Mz4mZ3Q7PC9GT05UPjwvU1BBTj5pc3N1ZSBub24tMTAwIHByb3Zpc2lv bmFsIHJlc3BvbnNlcyBvbiBpdHMgDQpvd24uPC9GT05UPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PFNQ QU4gY2xhc3M9Njg1NTYxNjA2LTI3MDIyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAw MGZmIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz02 ODU1NjE2MDYtMjcwMjIwMDk+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz02 ODU1NjE2MDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5Z ZXMsIA0KYnV0IEkmbmJzcDt3ZSBoYXZlIGFncmVlZCB0aGF0IGEgcHJveHkgaXMgYWxsb3dlZCB0 byBzZW5kIA0KMTk5LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2 MTYwNi0yNzAyMjAwOT48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2 MTYwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkJ1dCwg DQp0aGUgcHJveHkgaXMgbm90IGdvaW5nIHRvIGdlbmVyYXRlIG5ldyBUbyBoZWFkZXIgdGFnIHZh bHVlcyBmb3IgdGhlIDE5OS4gSXQgd2lsbCANCnVzZSB3aGF0ZXZlciB0YWdzIHRoYXQgaGF2ZSBh bHJlYWR5Jm5ic3A7YmVlbiBjcmVhdGVkIGZvciB0aGUmbmJzcDtlYXJseSANCmRpYWxvZ3MuPC9G T05UPiZuYnNwOzwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Njg1NTYxNjA2LTI3MDIy MDA5PjwvU1BBTj48U1BBTiBjbGFzcz02ODU1NjE2MDYtMjcwMjIwMDk+PEZPTlQgDQpmYWNlPUFy aWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW PjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgDQpzaXplPTI+UmVnYXJkcyw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz02ODU1NjE2MDYtMjcwMjIwMDk+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBj bGFzcz02ODU1NjE2MDYtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K c2l6ZT0yPkNocmlzdGVyPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Njg1 NTYxNjA2LTI3MDIyMDA5PiZuYnNwOzwvU1BBTj48QlI+PFNQQU4gDQpjbGFzcz02ODU1NjE2MDYt MjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNwOzwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTY4NTU2MTYwNi0yNzAyMjAwOT4m bmJzcDs8L1NQQU4+PEJSPjxCUj48VFQ+PEZPTlQgDQpzaXplPTI+KmFsbG93aW5nKiAobXVjaCBs ZXNzICpyZXF1aXJpbmcqKSB0aGUgMTk5IHRvIGJlIHJlbGlhYmxlIA0KaW50cm9kdWNlczxCUj5u YXN0eSBwcm9ibGVtcy4gVGhlIDE5OSBpcyBvbmx5IGFuIG9wdGltaXphdGlvbiwgc28gaGF2aW5n IGl0IA0KYmU8QlI+dW5yZWxpYWJsZSBpcyBvayBJTU8uPEJSPjxCUj5UaGUgcHJvYmxlbSBpcyB0 aGF0IGlmIGEgcHJveHkgc2VuZHMgdGhlIDE5OSwgDQp0aGVuIHRoZSByZWNpcGllbnQgb2YgdGhl PEJSPlBSQUNLIHNob3VsZCBiZSB0aGUgcHJveHkuIEJ1dCB0aGUgUFJBQ0sgaXMgYW4gDQppbi1k aWFsb2cgbWVzc2FnZSwgc28gaXQ8QlI+bXVzdCBiZSBhZGRyZXNzZWQgdG8gdGhlIENvbnRhY3Qg b2YgdGhlIA0KVUFTLjxCUj48QlI+SWYgdGhlIHByb3h5IHNlbmRzIGEgcmVsaWFibGUgMTk5LCBh bmQgdGhlIFBSQUNLIGlzIGFkZHJlc3NlZCB0byANCnRoZTxCUj5VQVMsIHRoZSBVQVMgd2lsbCBi ZSB2ZXJ5IHN1cnByaXNlZCwgc2luY2UgaXQgaGFzIG5vdCBzZW5kIGEgDQpyZWxpYWJsZTxCUj5w cm92aXNpb25hbCwgYW5kIGlzIHNvIG5vdCBleHBlY3RpbmcgYSBQUkFDSy4gSW4gZmFjdCwgaXQg aGFzIHNlbnQgDQphPEJSPmZpbmFsIHJlc3BvbnNlLCBoYXMgcHJlc3VtYWJseSBhbHJlYWR5IHJl Y2VpdmVkIHRoZSBBQ0ssIGFuZCBzbyANCmlzPEJSPmV4cGVjdGluZyBub3RoaW5nLjxCUj48QlI+ VmVyeSB1Z2x5LjxCUj48QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFBhdWw8QlI+PEJSPndhbmcubGlib0B6dGUuY29tLmNuIHdyb3Rl OjxCUj4mZ3Q7IA0KPEJSPiZndDsgSGksPEJSPiZndDsgPEJSPiZndDsgQW5kIHRoZXJlIHN0aWxs IHR3byBxdWVzdGlvbnMgbGVmdC48QlI+Jmd0OyANCjxCUj4mZ3Q7IDEuICZuYnNwO0lzIHRoZSAx OTkgc2hvdWxkIGJlIHJlbGlhYmxlIG9yIHVucmVsaWFibGU/PEJSPiZndDsgJm5ic3A7IA0KJm5i c3A7IEkgdGhpbmsgdGhhdCAxOTkgc2hvdWxkIGJlIHJlbGlhYmxlIGlmIHBvc3NpYmxlLjxCUj4m Z3Q7IDxCUj4mZ3Q7IA0KPEJSPiZndDsgJm5ic3A7ICZuYnNwO0ZpcnN0LCBJZiBhIGNsaWVudCBy ZWNlaXZlcyBhbiB1bnJlbGlhYmxlIDE5OSByZXNwb25zZSBvbiANCmEgZGlhbG9nIDxCUj4mZ3Q7 IHdoaWNoIGhhczxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDtub3QgcHJldmlvdXNseSBiZWVuIGNyZWF0 ZWQgDQoodGhpcyBjYW4gaGFwcGVuIGlmIGEgMTk5IHJlc3BvbnNlPEJSPiZndDsgJm5ic3A7ICZu YnNwO3JlYWNoZXMgdGhlIGNsaWVudCANCmJlZm9yZSBhIDE4eCByZXNwb25zZSkgdGhlIGNsaWVu dCBTSEFMTCBkaXNjYXJkPEJSPiZndDsgJm5ic3A7ICZuYnNwO3RoZSAxOTkgDQpyZXNwb25zZXMu PEJSPiZndDsgPEJSPiZndDsgJm5ic3A7ICZuYnNwO1RoZSBmaWd1cmUgYmVsb3cgc2hvd3MgYW4g ZXhhbXBsZS5UaGUgDQoxODAgaXMgc2VudCBmaXJzdCBidXQgYXJyaXZlcyA8QlI+Jmd0OyBsYXRl ciB0aGFuIDE5OS48QlI+Jmd0OyBJZiB0aGUgMTk5IGlzIA0KcmVsaWFibGUsIHRoZSBwcm94eSBz aG91bGQgcmV0cmFuc21pdCAxOTkgKHN0ZXAgNCksYW5kIDxCUj4mZ3Q7IHRoZW4gdGhlIA0KcmV0 cmFuc21pdHRlZDxCUj4mZ3Q7IDE5OSB3aWxsIGJlIGFjY2VwdGVkIGJ5IFVBQyxhbmQgdGhlIGVh cmx5IGRpYWxvZyB3aWxsIGJlIA0KdGVtaW5hdGVkLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFVBQyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANClA8QlI+Jmd0OyAmbmJzcDsg Jm5ic3A7MS4gSU5WSVRFPEJSPiZndDsgLS0tLS0tLS0tLS0tLS0tJmd0OzxCUj4mZ3Q7ICZuYnNw OyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyLiAxODA8QlI+Jmd0OyAmbHQ7LS0tLS0g XC8tLS0tLS0tPEJSPiZndDsgJm5ic3A7IA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsvXCAzLiAxOTk8 QlI+Jmd0OyAmbHQ7LS0tLS0vICZuYnNwO1wtLS0tLS08QlI+Jmd0OyAmbmJzcDsgDQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgNC4gMTk5KHJldHJhbnNtaXR0ZWQpPEJSPiZndDsgDQombHQ7 LS0tLS0tLS0tLS0tLS0tPEJSPiZndDsgPEJSPiZndDsgJm5ic3A7ICZuYnNwO3NlY29uZCwgQWNj b3JkaW5nIHRvIHByYWN0aWNhbCANCnVzZSwgMTk5IGNhbiBiZSBpbnRlbmRlZCB0byB0ZW1pbmF0 ZSA8QlI+Jmd0OyBvbmUgZWFybHkgZGlhbG9nIGFuZCANCnJlbGVhc2U8QlI+Jmd0OyByZXNvdXJj ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBzcGVjaWZpYyBlYXJseSBkaWFsb2csIHNvIHRoZSBjb3N0 IA0Kc3BlbnQgPEJSPiZndDsgb24gcmVsaWFibGUgMTk5IGlzIHdvcnRoeS48QlI+Jmd0OyBJZiB0 aGUgMTk5IGNhbm5vdCBiZSBzZW50IA0KcmVsaWFibGUsdGhlbiB3ZSBzaG91bGQgc2VuZCBpdCB1 bnJlbGlhYmxlLjxCUj4mZ3Q7ICZuYnNwOzxCUj4mZ3Q7IDIuIEluIHlvdXIgDQpsYXN0IGxldHRl ciwgeW91IHNhaWQgInRoZSBzZWNvbmQgMTk5IGNvdWxkIGluY2x1ZGUgPEJSPiZndDsgaW5mb3Jt YXRpb24gd2hpY2ggDQppcyB0byBiZSBmb3J3YXJkZWQgdG8gdGhlPEJSPiZndDsgVUFDIiwgdGhl biBkbyB5b3UgbWVhbiwgdGhlIGVhcmx5IGRpYWxvZyBpcyANCnN0aWxsIGFsaXZlIGFmdGVyIHRo ZSBmaXJzdCA8QlI+Jmd0OyAxOTkgaXMgYWNjZXB0ZWQ/PEJSPiZndDsgPEJSPiZndDsgPEJSPiZn dDsgDQpBbHNvLCBJbiBteSBsYXN0IGxldHRlciwgSSBtaXNzIGEgIk5PVCIgYnkgbWlzdGFrZS48 QlI+Jmd0OyBJdCBzaG91bGQgYmU8QlI+Jmd0OyANCltFcmljXTogU3VyZWx5IHRoZSBVQVMgaXMg Tk9UIGFsbG93ZWQgdG8gc2VuZCBhbm90aGVyIHJlbGlhYmxlIHJlc3BvbnNlPEJSPiZndDsgDQp1 bnRpbCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZC4uLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFJl Z2FyZHMsPEJSPiZndDsgRXJpYyANCndhbmc8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+ Jmd0OyA8QlI+Jmd0OyAqIkNocmlzdGVyIEhvbG1iZXJnIiANCiZsdDtjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20mZ3Q7KjxCUj4mZ3Q7IDxCUj4mZ3Q7IDIwMDktMDItMjcgDQowMzowNDxC Uj4mZ3Q7IDxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgDQombmJzcDs8QlI+Jmd0OyDmlLbku7bkuro8QlI+Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsgJm5ic3A7 IkVyaWMgd2FuZyIgJmx0O2VyaWMud2FuZ3hyQGdtYWlsLmNvbSZndDs8QlI+Jmd0OyDmioTpgIE8 QlI+Jmd0OyAmbmJzcDsgDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0O3NpcEBpZXRmLm9yZyZndDssIA0KJmx0O3dhbmcubGlib0B6dGUu Y29tLmNuJmd0OzxCUj4mZ3Q7IOS4u+mimDxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRTogUXVlc3Rpb25zIGFi b3V0IA0KImRyYWZ0LWlldGYtc2lwLTE5OS0wNSI8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgDQo8QlI+ Jmd0OyBIaSw8QlI+Jmd0OyA8QlI+Jmd0OyAmbmJzcDsmZ3Q7SSBzdGlsbCBoYXZlIHNvbWUgZGlm ZmljdWx0IGluIHVzaW5nIA0KSUVURiBhbmQgY2Fubm90IGZpbmQgdGhlIHdob2xlPEJSPiZndDsg c29ydGVkIGNvbW1lbnRzIGFib3V0IHRoaXMgZHJhZnQsIHNvIGkgDQpoYXZlIHNvbWUgZG91YnQg YWJvdXQgdGhpcyBkcmFmdC48QlI+Jmd0OyAmbmJzcDsmZ3Q7PEJSPiZndDsgJm5ic3A7Jmd0OyAm bmJzcDsgDQoxLiAmbmJzcDsgIklmIGEgZm9ya2luZyBwcm94eSByZWNlaXZlcyBhIHJlbGlhYmx5 IHNlbnQgMTk5IHJlc3BvbnNlIGZvciANCmE8QlI+Jmd0OyBkaWFsb2csIGZvciB3aGljaCB0aGUg cHJveHkgaGFzIHByZXZpb3VzbHkgZ2VuZXJhdGVkIGFuZCBzZW50IGEgDQoxOTk8QlI+Jmd0OyBy ZXNwb25zZSwgdGhlIHByb3h5IE1VU1QgZm9yd2FyZCB0aGUgMTk5IHJlc3BvbnNlLiI8QlI+Jmd0 OyANCiZuYnNwOyZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgRG9lcyBpdCBk ZXNjcmliZSB0aGUgY2FzZSBiZWxvdz8gDQpBbHRob3VnaCBQMSBoYXZlIHNlbnQgYSAxOTk8QlI+ Jmd0OyByZXNwb25zZSwgUDEgaGF2cyB0byAmbmJzcDtmb3J3b3JkIHRoZSBzZW5kIA0KcmVsaWFi bHkgMTk5IHRvby5PciAmbmJzcDtpcyB0aGU8QlI+Jmd0OyBmaXJzdCAxOTkgbWlzdGFrZWQgZm9y IDE4eD88QlI+Jmd0OyANCiZuYnNwOyZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtVQUMgJm5ic3A7IA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUDEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1VBU18yPEJSPiZndDsgJm5ic3A7Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsgJm5ic3A7LS0tIElOVklURSAtLS0t LS0mZ3Q7PEJSPiZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgLS0tIA0KSU5WSVRFIChsZWcgMikgLSZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsmbHQ7LS0gMTk5KGxl ZyAyKSAtLTxCUj4mZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZsdDstLSAxOTkgKGxlZyANCjIpIC0tLS0tPEJSPiZndDsgJm5ic3A7Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDstLSANCjE5OShs ZWcgMikgLS08QlI+Jmd0OyA8QlI+Jmd0OyAmbmJzcDsmZ3Q7SSB0aGluayBpdCBzaGFsbCBiZSAx OTksIGFzIGN1cnJlbnRseSANCndyaXR0ZW4uPEJSPiZndDsgJm5ic3A7Jmd0OzxCUj4mZ3Q7ICZu YnNwOyZndDtbRXJpY106IElmICZuYnNwO3RoaXMgaXMgMTk5LCB0aGVuIA0KSXMgdGhlcmUgYSBz cGVjaWFsIHB1cnBvc2UgdG8gc2VuZCB0d288QlI+Jmd0OyAxOTkgaW4gdGhlIHNhbWUgZGlhbG9n PzxCUj4mZ3Q7IA0KJm5ic3A7Jmd0O0kgdGhpbmsgdGhhdCBvbmUgMTk5IGlzIGVub3VnaC48QlI+ Jmd0OyAmbmJzcDsmZ3Q7QW5kICZuYnNwO3RoZSBmaXJzdCANCjE5OSBtYXkgYmUgcmVsaWFibGUg dG9vLCB0aGF0IHdpbGwgbWFrZSBpdCBhIGxpdHRsZTxCUj4mZ3Q7IGRpZmZpY3VsdCB0byBzZW5k IA0KdGhlIHNlY29uZCAxOTkuPEJSPiZndDsgPEJSPiZndDsgVGhlIHNlY29uZCAxOTkgY291bGQg aW5jbHVkZSBpbmZvcm1hdGlvbiB3aGljaCANCmlzIHRvIGJlIGZvcndhcmRlZCB0byB0aGU8QlI+ Jmd0OyBVQUMuPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgJm5ic3A7Jmd0OzIuIA0KJm5ic3A7 IjEwLiAmbmJzcDtVc2FnZSB3aXRoIDEwMHJlbDxCUj4mZ3Q7ICZuYnNwOyZndDs8QlI+Jmd0OyAm bmJzcDsmZ3Q7ICZuYnNwOyANCldoZW4gYSAxOTkgRWFybHkgRGlhbG9nIFRlcm1pbmF0ZWQgcHJv dmlzaW9uYWwgcmVzcG9uc2UgaXMgc2VudCBieSBhPEJSPiZndDsgDQpVQVMsIHNpbmNlIHRoZSBw cm92aXNpb25hbCByZXNwb25zZSBpcyBvbmx5IHVzZWQgZm9yIGluZm9ybWF0aW9uPEJSPiZndDsg DQpwdXJwb3NlLCB0aGUgVUFTIFNIT1VMRCBzZW5kIGl0IHVucmVsaWFibHkgZXZlbiBpZiB0aGUg MTAwcmVsPEJSPiZndDsgJm5ic3A7Jmd0OyANCiZuYnNwOyBvcHRpb24gdGFnIFtSRkMzMjYyXSBp cyBwcmVzZW50IGluIHRoZSBSZXF1aXJlIGhlYWRlciBvZiB0aGU8QlI+Jmd0OyANCmFzc29jaWF0 ZWQgcmVxdWVzdC4iPEJSPiZndDsgJm5ic3A7Jmd0OzxCUj4mZ3Q7ICZuYnNwOyZndDs8QlI+Jmd0 OyAmbmJzcDsmZ3Q7SSANCmhhdmUgc2VlbiBhIGNvbW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQg c3RpbGwgbm90IHVuZGVyc3Rvb2QgYWJvdXQ8QlI+Jmd0OyANCiZuYnNwOyZndDtpdC4gSWYgdGhl IElOVklURSBoYXMgYSBSZXF1aXJlIHRhZyAiUmVxdWlyZTogMTAwcmVsIixkb2VzIHRoZSANClVB UzxCUj4mZ3Q7IHN0aWxsPEJSPiZndDsgJm5ic3A7Jmd0O3VzZSB1bnJlbGlhYmxlIDE5OSByZXNw b25zZT88QlI+Jmd0OyANCiZuYnNwOyZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7VGhhdCBpcyB0aGUg cmVjb21tZW5kYXRpb24sIHllcy4gVGhlIHJlYXNvbnMgaXMgDQp0aGF0IHdlIHdhbnQgdG8ga2Vl cDxCUj4mZ3Q7IDE5OTxCUj4mZ3Q7ICZuYnNwOyZndDthcyAibGlnaHR3ZWlnaHQiIGFzIHBvc3Np YmxlLCANCndpdGhvdXQgcmVxdWlyZWluZyByZS10cmFuc21pc3Npb25zIGFuZDxCUj4mZ3Q7ICZu YnNwOyZndDtQUkFDS3MuPEJSPiZndDsgDQombmJzcDsmZ3Q7PEJSPiZndDsgJm5ic3A7Jmd0O1tF cmljXTogQnV0IHJlbGlhYmxlIDE5OSBoYXZlIG1vcmUgYWR2YW50YWdlLCBhbmQgDQpJdCBpcyB3 b3J0aCB0byB1c2U8QlI+Jmd0OyB0aGUgcmVsaWFibGUgMTk5LEkgdGhpbmsuPEJSPiZndDsgPEJS PiZndDsgSSBkb24ndCANCmtub3cgd2hhdCB0aGF0IGFkdmFudGFnZSB3b3VsZCBiZSwgY29tcGFy ZWQgdG8gaGF2aW5nIHRvIHNlbmQ8QlI+Jmd0OyBQUkFDS3MgDQpldGMuIFRoaXMgaGFzIGJlZW4g ZGlzY3Vzc2VkIHF1aXRlIG11Y2gsIHNvIEkgd291bGQgcmVhbGx5IG5lZWQ8QlI+Jmd0OyBzb21l IA0KZ29vZCBqdXN0aWZpY2F0aW9uIHRvIGNoYW5nZSBpdCBub3cuPEJSPiZndDsgPEJSPiZndDsg QWxzbywgdGhlIGRyYWZ0IGRvZXNuJ3QgDQpmb3JiaWQgeW91IHRvIHNlbmQgdGhlIDE5OSByZWxp YWJseS4gSXQncyBvbmx5IGE8QlI+Jmd0OyBTSE9VTEQuPEJSPiZndDsgDQo8QlI+Jmd0OyA8QlI+ Jmd0OyAmbmJzcDsmZ3Q7SWYgMTk5IGlzIHJlbGlhYmxlLCB0aGVyZSBpcyBvbmUgbW9yZSBhZHZh bnRhZ2UuIElmIA0KdGhlIDE5OSBhcnJpdmVzPEJSPiZndDsgJm5ic3A7Jmd0O2JlZm9yZSB0aGUg Zmlyc3QgMTh4IHJlc3BvbnNlLCBVQUMgY2FuIGRpc2NhcmQgDQp0aGUgZmlyc3QgMTk5IGFuZDxC Uj4mZ3Q7IHByb2Nlc3M8QlI+Jmd0OyAmbmJzcDsmZ3Q7aXQgdW50aWwgVUFDIHJlY2VpdmVzIHRo ZSANCmZpcnN0IDE4eCByZXNwb25zZSB0aGF0IGhhcyB0aGUgc2FtZTxCUj4mZ3Q7ICZuYnNwOyZn dDt0by10YWcgYXMgMTk5LCBhcyB0aGUgDQpyZWxpYWJsZSAxOTkgc2hvdWxkIGJlIHJlLXRyYW5z bWl0ZWQgdW50aWw8QlI+Jmd0OyAmbmJzcDsmZ3Q7cmVjZWl2ZWQgDQpQUkFDSy48QlI+Jmd0OyAm bmJzcDsmZ3Q7PEJSPiZndDsgJm5ic3A7Jmd0O0lmIHRoZSBJTlZJVEUgY29udGFpbnMgIlJlcXVp cmU6IA0KMTAwcmVsIiwgdGhlIGZpcnN0IDE4eCBtdXN0IGFsc28gYmU8QlI+Jmd0OyAmbmJzcDsm Z3Q7c2VudCByZWxpYWJseS4gQW5kLCBJIA0KZG9uJ3QgdGhpbmsgdGhlIFVBUyBpcyBhbGxvd2Vk IHRvIHNlbmQgYW5vdGhlcjxCUj4mZ3Q7ICZuYnNwOyZndDtyZWxpYWJsZSANCnJlc3BvbnNlIHVu dGlsIHRoZSBmaXJzdCBvbmUgaXMgYWNrbm93bGVkZ2VkLCBzbyBJIGRvbid0IHRoaW5rPEJSPiZn dDsgDQombmJzcDsmZ3Q7YSByZWxpYWJsZSAxOTkgd291bGQgcmVhY2ggdGhlIFVBQyBiZWZvcmUg dGhlIGZpcnN0IHJlbGlhYmxlIA0KMTh4LjxCUj4mZ3Q7ICZuYnNwOyZndDs8QlI+Jmd0OyAmbmJz cDsmZ3Q7W0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIA0Kc2VuZCBhbm90aGVy IHJlbGlhYmxlIHJlc3BvbnNlPEJSPiZndDsgdW50aWwgdGhlIGZpcnN0IG9uZSBpcyANCmFja25v d2xlZGdlZCw8QlI+Jmd0OyA8QlI+Jmd0OyBJZiBJIHJlbWVtYmVyIGNvcnJlY3RseSwgdGhlIEZJ UlNUIHJlbGlhYmxlIA0KcmVzcG9uc2UgbXVzdCBiZSBhY2tub3dsZWRlZDxCUj4mZ3Q7IGJlZm9y ZSB0aGUgbmV4dCByZWxpYWJsZSByZXNwb25zZSBpcyBzZW50LiANCkJ1dCwgd2UgY2FuIGRvdWJs ZSBjaGVjayBpbjxCUj4mZ3Q7IHRoZSBQUkFDSyBzcGVjLjxCUj4mZ3Q7IDxCUj4mZ3Q7IA0KJm5i c3A7Jmd0O2J1dCByZWxpYWJsZSAxOTkgd2lsbCBiZSB1c2VmdWwgaWYgdGhlIGZpcnN0IDE4eCBp cyB1bnJlbGlhYmxlLCBvciANCnRoZTxCUj4mZ3Q7IGZpcnN0IDE4eCBoYXMgYmVlbiBhY2tud2xl ZGdlZC4gSXQncyBhbm90aGVyIGNhc2UgZGlmZmVyZW50IGZyb20gDQp0aGU8QlI+Jmd0OyBhYm92 ZSBvbmUgJm5ic3A7d2hvc2UgSU5WSVRFIGNvbnRhaW5zICJyZXF1aXJlOiAxMDByZWwiLjxCUj4m Z3Q7IA0KPEJSPiZndDsgSWYgMTAwcmVsIGlzIHJlcXVpcmVkIHRoZSAxOHggY2Fubm90IGJlIHVu cmVsaWFibGUuPEJSPiZndDsgPEJSPiZndDsgDQpSZWdhcmRzLDxCUj4mZ3Q7IDxCUj4mZ3Q7IENo cmlzdGVyPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgDQo8QlI+ Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyANCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPiZn dDsgWlRFIEluZm9ybWF0aW9uIA0KU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgDQp0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgDQpuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kg YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIA0KdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0byBvdGhlcnMuPEJSPiZndDsgVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVz IA0KdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5 IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgDQppbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIA0KdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuPEJSPiZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVuIA0Kc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+ Jmd0OyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4mZ3Q7IA0KPEJSPiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBTaXAgbWFpbGluZyANCmxp c3QgJm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXA8QlI+Jmd0 OyBUaGlzIGxpc3QgaXMgZm9yIA0KTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90 b2NvbDxCUj4mZ3Q7IFVzZSANCnNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBx dWVzdGlvbnMgb24gY3VycmVudCBzaXA8QlI+Jmd0OyBVc2UgDQpzaXBwaW5nQGlldGYub3JnIGZv ciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiANCnNpcDxCUj48L0ZPTlQ+ PC9UVD48QlI+PEJSPjwvRElWPjxQUkU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJp dHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQm bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9w ZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5i c3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRl bnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJz cDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZu YnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJz cDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24m bmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZu YnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJz cDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2Zv ciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNw O29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNw O2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNw O3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3Rp ZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdl LiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVu Jm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5i c3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L1BSRT48L0JPRFk+ PC9IVE1MPg0K ------_=_NextPart_001_01C998A3.D7D171BC-- From eric.wangxr@gmail.com Fri Feb 27 02:48:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545143A6803 for ; Fri, 27 Feb 2009 02:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.359 X-Spam-Level: *** X-Spam-Status: No, score=3.359 tagged_above=-999 required=5 tests=[AWL=-2.022, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFx0eIpcTggl for ; Fri, 27 Feb 2009 02:48:57 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 59F573A6868 for ; Fri, 27 Feb 2009 02:48:54 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so943023rvb.49 for ; Fri, 27 Feb 2009 02:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rDH5qZkkyEjGkuLJLCGNvm3nZWTtISp3ANmXx0H0P9c=; b=xor26hYii4gHObijY9PEbA5LFMoanlxsWHwx5359KE/eEAa2AEolZvo4Q2QAHbjbKD 1A5V7Xoo0lqv4DhptlOYnZJnJdZ132uJZZLEwBH8DmuSRrzERhzMHyNZ0AX1eXwTCEbt PypIgHtQ1NwIsfDWiVuhsnS0sWztqlcqTrLhI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jPvlStqpTotr+AV0CYoPT/WliLTpMACcSCvXRwGM+lHeKRL7dFXOrEs0LYiZ3E0HAC vfRfhptuhpVqcISpXG/QpugSc490iWBOY4Ytg/vfoSC3OjXm3VzD/xTFQWUOsD6EC8LC fW4sL7uwkPny3IZTc2wvGmq+weBvgECBmITUE= MIME-Version: 1.0 Received: by 10.140.163.12 with SMTP id l12mr1154320rve.178.1235731756826; Fri, 27 Feb 2009 02:49:16 -0800 (PST) In-Reply-To: References: <49A7484B.3060407@cisco.com> Date: Fri, 27 Feb 2009 18:49:16 +0800 Message-ID: <898632750902270249o3213670au6823cc4ab6180c8c@mail.gmail.com> From: Eric wang To: Christer Holmberg Content-Type: multipart/alternative; boundary=000e0cd2e25867418b0463e438bd Cc: sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] =?gb2312?b?tPC4tDogUkU6IFF1ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0?= =?gb2312?b?Zi1zaXAtMTk5LTA1Ig==?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:48:59 -0000 --000e0cd2e25867418b0463e438bd Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, If the UAC requires 100rel ,then what should the proxy do if it receives a no-2xx final response after forking? Regards, Eric 2009/2/27, Christer Holmberg : > > Hi, > > >Practically, when Call forward and fork are used in the same system, > there are > >lots of early dialogs that should be eliminated by 199 existed. > >So I think that it's useful to let 199 reliable. > >And we just added fork-service to our system ,and find 199 is really > useful, and > >if the 199 is missing, problems will happen. > > I'm glad you think 199 is useful :) > > But, if a proxy would have to terminate PRACKs etc it would not be a prox= y > anymore - it would be a B2BUA. > > So, if you really want your network to send 199 reliably, I guess you cou= ld > use a B2BUA instead of a proxy. > > >It sounds good that there is a way to prevent PRACK addressed to UAS,but > i don't know how to do now. > > The only way to prevent it is by the proxy not sending the 199 relaible. > > >ps: > >RFC3261 *16.7 Response Processing* > >Since a proxy may not insert a tag into the To header field of > >a 1xx response to a request that did not contain one, it cannot > >issue non-100 provisional responses on its own. > > Yes, but I we have agreed that a proxy is allowed to send 199. > > But, the proxy is not going to generate new To header tag values for the > 199. It will use whatever tags that have already been created for the ear= ly > dialogs. > > Regards, > > Christer > > > > > > > > > > > *allowing* (much less *requiring*) the 199 to be reliable introduces > nasty problems. The 199 is only an optimization, so having it be > unreliable is ok IMO. > > The problem is that if a proxy sends the 199, then the recipient of the > PRACK should be the proxy. But the PRACK is an in-dialog message, so it > must be addressed to the Contact of the UAS. > > If the proxy sends a reliable 199, and the PRACK is addressed to the > UAS, the UAS will be very surprised, since it has not send a reliable > provisional, and is so not expecting a PRACK. In fact, it has sent a > final response, has presumably already received the ACK, and so is > expecting nothing. > > Very ugly. > > Paul > > wang.libo@zte.com.cn wrote: > > > > Hi, > > > > And there still two questions left. > > > > 1. Is the 199 should be reliable or unreliable? > > I think that 199 should be reliable if possible. > > > > > > First, If a client receives an unreliable 199 response on a dialog > > which has > > not previously been created (this can happen if a 199 response > > reaches the client before a 18x response) the client SHALL discard > > the 199 responses. > > > > The figure below shows an example.The 180 is sent first but arrives > > later than 199. > > If the 199 is reliable, the proxy should retransmit 199 (step 4),and > > then the retransmitted > > 199 will be accepted by UAC,and the early dialog will be teminated. > > > > UAC P > > 1. INVITE > > ---------------> > > 2. 180 > > <----- \/------- > > /\ 3. 199 > > <-----/ \------ > > 4. 199(retransmitted) > > <--------------- > > > > second, According to practical use, 199 can be intended to teminate > > one early dialog and release > > resources associated with the specific early dialog, so the cost spent > > on reliable 199 is worthy. > > If the 199 cannot be sent reliable,then we should send it unreliable. > > > > 2. In your last letter, you said "the second 199 could include > > information which is to be forwarded to the > > UAC", then do you mean, the early dialog is still alive after the first > > 199 is accepted? > > > > > > Also, In my last letter, I miss a "NOT" by mistake. > > It should be > > [Eric]: Surely the UAS is NOT allowed to send another reliable response > > until the first one is acknowledged... > > > > Regards, > > Eric wang > > > > > > > > > > *"Christer Holmberg" * > > > > 2009-02-27 03:04 > > > > > > =CA=D5=BC=FE=C8=CB > > "Eric wang" > > =B3=AD=CB=CD > > , > > =D6=F7=CC=E2 > > RE: Questions about "draft-ietf-sip-199-05" > > > > > > > > > > > > > > > > > > Hi, > > > > >I still have some difficult in using IETF and cannot find the whole > > sorted comments about this draft, so i have some doubt about this draft= . > > > > > > 1. "If a forking proxy receives a reliably sent 199 response for= a > > dialog, for which the proxy has previously generated and sent a 199 > > response, the proxy MUST forward the 199 response." > > > > > > Does it describe the case below? Although P1 have sent a 199 > > response, P1 havs to forword the send reliably 199 too.Or is the > > first 199 mistaked for 18x? > > > > > > UAC P1 UAS_2 > > > --- INVITE ------> > > > --- INVITE (leg 2) -> > > > <-- 199(leg 2) -- > > > <-- 199 (leg 2) ----- > > > <-- 199(leg 2) -- > > > > >I think it shall be 199, as currently written. > > > > > >[Eric]: If this is 199, then Is there a special purpose to send two > > 199 in the same dialog? > > >I think that one 199 is enough. > > >And the first 199 may be reliable too, that will make it a little > > difficult to send the second 199. > > > > The second 199 could include information which is to be forwarded to th= e > > UAC. > > > > > > >2. "10. Usage with 100rel > > > > > > When a 199 Early Dialog Terminated provisional response is sent by= a > > UAS, since the provisional response is only used for information > > purpose, the UAS SHOULD send it unreliably even if the 100rel > > > option tag [RFC3262] is present in the Require header of the > > associated request." > > > > > > > > >I have seen a comment on this question,but still not understood about > > >it. If the INVITE has a Require tag "Require: 100rel",does the UAS > > still > > >use unreliable 199 response? > > > > > >That is the recommendation, yes. The reasons is that we want to keep > > 199 > > >as "lightweight" as possible, without requireing re-transmissions and > > >PRACKs. > > > > > >[Eric]: But reliable 199 have more advantage, and It is worth to use > > the reliable 199,I think. > > > > I don't know what that advantage would be, compared to having to send > > PRACKs etc. This has been discussed quite much, so I would really need > > some good justification to change it now. > > > > Also, the draft doesn't forbid you to send the 199 reliably. It's only = a > > SHOULD. > > > > > > >If 199 is reliable, there is one more advantage. If the 199 arrives > > >before the first 18x response, UAC can discard the first 199 and > > process > > >it until UAC receives the first 18x response that has the same > > >to-tag as 199, as the reliable 199 should be re-transmited until > > >received PRACK. > > > > > >If the INVITE contains "Require: 100rel", the first 18x must also be > > >sent reliably. And, I don't think the UAS is allowed to send another > > >reliable response until the first one is acknowledged, so I don't thi= nk > > >a reliable 199 would reach the UAC before the first reliable 18x. > > > > > >[Eric]: Surely the UAS is allowed to send another reliable response > > until the first one is acknowledged, > > > > If I remember correctly, the FIRST reliable response must be acknowlede= d > > before the next reliable response is sent. But, we can double check in > > the PRACK spec. > > > > >but reliable 199 will be useful if the first 18x is unreliable, or th= e > > first 18x has been acknwledged. It's another case different from the > > above one whose INVITE contains "require: 100rel". > > > > If 100rel is required the 18x cannot be unreliable. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > 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 an= d > are not permitted to disclose the contents of this communication to other= s. > > 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. > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s 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 intende= d 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 individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --000e0cd2e25867418b0463e438bd Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
hi,
 
   If the UAC requires 100rel ,then what should the proxy do= if it receives a no-2xx
final response after forking?
 
Regards,
Eric


 
2009/2/27, Christer Holmberg <christer.holmberg@ericsson.com>:
Hi,
  
>Practically, when Call forward and fork are= used in the same system, there are 
>lots of early dialogs that should= be eliminated by 199 existed. 
= >So I think that it's useful t= o let 199 reliable. 
>And we just added fork-service to= our system ,and find 199 is really useful, and 
>if the 199 is m= issing, problems will happen.  
 
I'm glad y= ou think 199 is useful :)
=  
But, if a prox= y would have to terminate PRACKs etc it would not be a proxy anymore - it w= ould be a B2BUA.
=  
So, if you rea= lly want your network to send 199 reliably, I guess you could use a B2BUA i= nstead of a proxy.

>It sounds good that there is a way to prevent PRACK add= ressed to UAS,but i don't know  how to do now. <= /font>
 = ;
Th= e only way to prevent it is by the proxy not sending the 199 relaible.=   
    
>ps: 
<= font color=3D"#0000ff">>RFC3261 16.7 Response Processing 
>Since a proxy may not insert a ta= g into the To header field of 
<= font size=3D"2">>a 1xx respo= nse to a request that did not contain one, it cannot 
>issu= e non-100 provisional responses on its own.  
 
Yes, but I&nbs= p;we have agreed that a proxy is allowed to send 199.
 
But, the proxy= is not going to generate new To header tag values for the 199. It will use= whatever tags that have already been created for the early dialo= gs. 
&= nbsp;
Regards,
 
Christer
 
 
 
 
 
 
 
 
 

*allowing* (much less = *requiring*) the 199 to be reliable introduces
nasty problems. The 199 i= s only an optimization, so having it be
unreliable is ok IMO.

The= problem is that if a proxy sends the 199, then the recipient of the
PRACK should be the proxy. But the PRACK is an in-dialog message, so it
= must be addressed to the Contact of the UAS.

If the proxy sends a re= liable 199, and the PRACK is addressed to the
UAS, the UAS will be very = surprised, since it has not send a reliable
provisional, and is so not expecting a PRACK. In fact, it has sent a
fin= al response, has presumably already received the ACK, and so is
expectin= g nothing.

Very ugly.

          &nbs= p;     Paul

wang.l= ibo@zte.com.cn wrote:
>
> Hi,
>
> And there still two questions left.
&= gt;
> 1.  Is the 199 should be reliable or unreliable?
> =     I think that 199 should be reliable if possible.
>
= >
>    First, If a client receives an unreliable 199 re= sponse on a dialog
> which has
>    not previously been created (this can h= appen if a 199 response
>    reaches the client before a 18= x response) the client SHALL discard
>    the 199 responses= .
>
>    The figure below shows an example.The 180 i= s sent first but arrives
> later than 199.
> If the 199 is reliable, the proxy should retra= nsmit 199 (step 4),and
> then the retransmitted
> 199 will be = accepted by UAC,and the early dialog will be teminated.
>
> UA= C             P
>    1. INVITE
> --------------->
>   &nbs= p;       2. 180
> <----- \/-------
>   &= nbsp;    /\ 3. 199
> <-----/  \------
>  = ;         4. 199(retransmitted)
> <-----------= ----
>
>    second, According to practical use, 199 can be i= ntended to teminate
> one early dialog and release
> resources= associated with the specific early dialog, so the cost spent
> on r= eliable 199 is worthy.
> If the 199 cannot be sent reliable,then we should send it unreliable.<= br>>  
> 2. In your last letter, you said "the second 19= 9 could include
> information which is to be forwarded to the
>= ; UAC", then do you mean, the early dialog is still alive after the fi= rst
> 199 is accepted?
>
>
> Also, In my last letter, I = miss a "NOT" by mistake.
> It should be
> [Eric]: Sur= ely the UAS is NOT allowed to send another reliable response
> until = the first one is acknowledged...
>
> Regards,
> Eric wang
>
>
>
>=
> *"Christer Holmberg" <christer.holmberg@ericsson.com>*
>
> 2009-02-27 03:04
>
>        =          
> =CA=D5=BC=FE=C8=CB
> &nbs= p;                "Eric wang&q= uot; <eric.wangxr@gmail.com>
> =B3=AD=CB=CD
>               =    <sip@ietf.org>, <= wang.libo@zte.com.cn>
> =D6=F7=CC=E2
>               =    RE: Questions about "draft-ietf-sip-199-05"
> =
>
>                 &= nbsp;
>
>
>
>
>
> Hi,
>
= >  >I still have some difficult in using IETF and cannot find th= e whole
> sorted comments about this draft, so i have some doubt about this draf= t.
>  >
>  >   1.   "If a forkin= g proxy receives a reliably sent 199 response for a
> dialog, for whi= ch the proxy has previously generated and sent a 199
> response, the proxy MUST forward the 199 response."
>  = ;>
>  >     Does it describe the case below? Alt= hough P1 have sent a 199
> response, P1 havs to  forword the sen= d reliably 199 too.Or  is the
> first 199 mistaked for 18x?
>  >
>  > &nbs= p;        UAC            =   P1                  UA= S_2
>  >            --- INVITE = ------>
>  >             &nb= sp;               --- INVITE (leg 2) -&g= t;
>  >            <-- 199(leg 2) = --
>  >               &nbs= p;             <-- 199 (leg 2) -----
&g= t;  >            <-- 199(leg 2) --=
>
>  >I think it shall be 199, as currently written.<= br> >  >
>  >[Eric]: If  this is 199, then Is the= re a special purpose to send two
> 199 in the same dialog?
> &n= bsp;>I think that one 199 is enough.
>  >And  the fir= st 199 may be reliable too, that will make it a little
> difficult to send the second 199.
>
> The second 199 coul= d include information which is to be forwarded to the
> UAC.
> =
>
>  >2.  "10.  Usage with 100rel
&= gt;  >
>  >   When a 199 Early Dialog Terminated provisional respo= nse is sent by a
> UAS, since the provisional response is only used f= or information
> purpose, the UAS SHOULD send it unreliably even if t= he 100rel
>  >   option tag [RFC3262] is present in the Require heade= r of the
> associated request."
>  >
>  = ;>
>  >I have seen a comment on this question,but still no= t understood about
>  >it. If the INVITE has a Require tag "Require: 100rel&qu= ot;,does the UAS
> still
>  >use unreliable 199 respons= e?
>  >
>  >That is the recommendation, yes. Th= e reasons is that we want to keep
> 199
>  >as "lightweight" as possible, without = requireing re-transmissions and
>  >PRACKs.
>  >= ;
>  >[Eric]: But reliable 199 have more advantage, and It is= worth to use
> the reliable 199,I think.
>
> I don't know what that = advantage would be, compared to having to send
> PRACKs etc. This has= been discussed quite much, so I would really need
> some good justif= ication to change it now.
>
> Also, the draft doesn't forbid you to send the 199 reliab= ly. It's only a
> SHOULD.
>
>
>  >If = 199 is reliable, there is one more advantage. If the 199 arrives
> &n= bsp;>before the first 18x response, UAC can discard the first 199 and > process
>  >it until UAC receives the first 18x response= that has the same
>  >to-tag as 199, as the reliable 199 sho= uld be re-transmited until
>  >received PRACK.
>  = >
>  >If the INVITE contains "Require: 100rel", = the first 18x must also be
>  >sent reliably. And, I don't think the UAS is allowed to = send another
>  >reliable response until the first one is ack= nowledged, so I don't think
>  >a reliable 199 would reac= h the UAC before the first reliable 18x.
>  >
>  >[Eric]: Surely the UAS is allowed to send= another reliable response
> until the first one is acknowledged,
= >
> If I remember correctly, the FIRST reliable response must be = acknowleded
> before the next reliable response is sent. But, we can double check in=
> the PRACK spec.
>
>  >but reliable 199 will b= e useful if the first 18x is unreliable, or the
> first 18x has been = acknwledged. It's another case different from the
> above one  whose INVITE contains "require: 100rel".
= >
> If 100rel is required the 18x cannot be unreliable.
> <= br>> Regards,
>
> Christer
>
>
>
&g= t;
>
>
>
>
>
>
> ----------------= ----------------------------------------
> ZTE Information Security N= otice: The information contained in this mail is solely property of the sen= der's organization. This mail communication is confidential. Recipients= named above are obligated to maintain secrecy and are not permitted to dis= close the contents of this communication to others.
> This email and any files transmitted with it are confidential and inte= nded solely for the use of the individual or entity to whom they are addres= sed. 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 indivi= dual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam sy= stem.
>
>
> -------------------------------------------= -----------------------------
>
> ____________________________= ___________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is f= or NEW development of the core SIP Protocol
> Use sip-implemen= tors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the= application of sip


 
--------------------------------------=
------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

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

--000e0cd2e25867418b0463e438bd-- From christer.holmberg@ericsson.com Fri Feb 27 03:00:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A70128B56A for ; Fri, 27 Feb 2009 03:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.164 X-Spam-Level: X-Spam-Status: No, score=-5.164 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxXIPT4GkoSq for ; Fri, 27 Feb 2009 03:00:17 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7606B3A6AC6 for ; Fri, 27 Feb 2009 03:00:16 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 80AAF203FE; Fri, 27 Feb 2009 12:00:37 +0100 (CET) X-AuditID: c1b4fb3c-af00dbb000001b43-30-49a7c7d5b7cb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4568320B29; Fri, 27 Feb 2009 12:00:37 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 12:00:36 +0100 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_01C998CA.9E576D16" Date: Fri, 27 Feb 2009 12:00:36 +0100 Message-ID: In-Reply-To: <898632750902270249o3213670au6823cc4ab6180c8c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?UTF-8?B?W1NpcF0g562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJk?= =?UTF-8?B?cmFmdC1pZXRmLXNpcC0xOTktMDUi?= Thread-Index: AcmYyQxA9SxPK8fqRdGMgu5QJzvKrgAAW5aw References: <49A7484B.3060407@cisco.com> <898632750902270249o3213670au6823cc4ab6180c8c@mail.gmail.com> From: "Christer Holmberg" To: "Eric wang" X-OriginalArrivalTime: 27 Feb 2009 11:00:36.0921 (UTC) FILETIME=[9EA52A90:01C998CA] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] =?utf-8?b?562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1p?= =?utf-8?q?etf-sip-199-05=22?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:00:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C998CA.9E576D16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQogDQo+SWYgdGhlIFVBQyByZXF1aXJlcyAxMDByZWwgLHRoZW4gd2hhdCBzaG91bGQgdGhl IHByb3h5IGRvIGlmIGl0IHJlY2VpdmVzIGEgbm8tMnh4ICAgZmluYWwgcmVzcG9uc2UgYWZ0ZXIg Zm9ya2luZz8gDQogDQpUaGUgcHJveHkgc2hvdWxkIHNlbmQgMTk5IHVucmVsaWFibHkuDQogDQpS ZWdhcmRzLA0KIA0KQ2hyaXN0ZXIgDQogDQoNCg0KIA0KMjAwOS8yLzI3LCBDaHJpc3RlciBIb2xt YmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjogDQoNCgkNCglIaSwNCgkgIA0K CT5QcmFjdGljYWxseSwgd2hlbiBDYWxsIGZvcndhcmQgYW5kIGZvcmsgYXJlIHVzZWQgaW4gdGhl IHNhbWUgc3lzdGVtLCB0aGVyZSBhcmUgDQoJPmxvdHMgb2YgZWFybHkgZGlhbG9ncyB0aGF0IHNo b3VsZCBiZSBlbGltaW5hdGVkIGJ5IDE5OSBleGlzdGVkLiANCgk+U28gSSB0aGluayB0aGF0IGl0 J3MgdXNlZnVsIHRvIGxldCAxOTkgcmVsaWFibGUuIA0KCT5BbmQgd2UganVzdCBhZGRlZCBmb3Jr LXNlcnZpY2UgdG8gb3VyIHN5c3RlbSAsYW5kIGZpbmQgMTk5IGlzIHJlYWxseSB1c2VmdWwsIGFu ZCANCgk+aWYgdGhlIDE5OSBpcyBtaXNzaW5nLCBwcm9ibGVtcyB3aWxsIGhhcHBlbi4gIA0KCSAN CglJJ20gZ2xhZCB5b3UgdGhpbmsgMTk5IGlzIHVzZWZ1bCA6KQ0KCSANCglCdXQsIGlmIGEgcHJv eHkgd291bGQgaGF2ZSB0byB0ZXJtaW5hdGUgUFJBQ0tzIGV0YyBpdCB3b3VsZCBub3QgYmUgYSBw cm94eSBhbnltb3JlIC0gaXQgd291bGQgYmUgYSBCMkJVQS4NCgkgDQoJU28sIGlmIHlvdSByZWFs bHkgd2FudCB5b3VyIG5ldHdvcmsgdG8gc2VuZCAxOTkgcmVsaWFibHksIEkgZ3Vlc3MgeW91IGNv dWxkIHVzZSBhIEIyQlVBIGluc3RlYWQgb2YgYSBwcm94eS4NCgkNCg0KCT5JdCBzb3VuZHMgZ29v ZCB0aGF0IHRoZXJlIGlzIGEgd2F5IHRvIHByZXZlbnQgUFJBQ0sgYWRkcmVzc2VkIHRvIFVBUyxi dXQgaSBkb24ndCBrbm93ICBob3cgdG8gZG8gbm93LiANCgkgDQoJVGhlIG9ubHkgd2F5IHRvIHBy ZXZlbnQgaXQgaXMgYnkgdGhlIHByb3h5IG5vdCBzZW5kaW5nIHRoZSAxOTkgcmVsYWlibGUuICAN CgkgICAgDQoJPnBzOiANCgk+UkZDMzI2MSAxNi43IFJlc3BvbnNlIFByb2Nlc3NpbmcgDQoJPlNp bmNlIGEgcHJveHkgbWF5IG5vdCBpbnNlcnQgYSB0YWcgaW50byB0aGUgVG8gaGVhZGVyIGZpZWxk IG9mIA0KCT5hIDF4eCByZXNwb25zZSB0byBhIHJlcXVlc3QgdGhhdCBkaWQgbm90IGNvbnRhaW4g b25lLCBpdCBjYW5ub3QgDQoJPmlzc3VlIG5vbi0xMDAgcHJvdmlzaW9uYWwgcmVzcG9uc2VzIG9u IGl0cyBvd24uICANCgkgDQoJWWVzLCBidXQgSSB3ZSBoYXZlIGFncmVlZCB0aGF0IGEgcHJveHkg aXMgYWxsb3dlZCB0byBzZW5kIDE5OS4NCgkgDQoJQnV0LCB0aGUgcHJveHkgaXMgbm90IGdvaW5n IHRvIGdlbmVyYXRlIG5ldyBUbyBoZWFkZXIgdGFnIHZhbHVlcyBmb3IgdGhlIDE5OS4gSXQgd2ls bCB1c2Ugd2hhdGV2ZXIgdGFncyB0aGF0IGhhdmUgYWxyZWFkeSBiZWVuIGNyZWF0ZWQgZm9yIHRo ZSBlYXJseSBkaWFsb2dzLiANCgkgDQoJUmVnYXJkcywNCgkgDQoJDQoJQ2hyaXN0ZXINCgkNCgkN CgkgDQoJIA0KCSANCgkgDQoJIA0KCSANCgkgDQoJDQoJDQoJKmFsbG93aW5nKiAobXVjaCBsZXNz ICpyZXF1aXJpbmcqKSB0aGUgMTk5IHRvIGJlIHJlbGlhYmxlIGludHJvZHVjZXMNCgluYXN0eSBw cm9ibGVtcy4gVGhlIDE5OSBpcyBvbmx5IGFuIG9wdGltaXphdGlvbiwgc28gaGF2aW5nIGl0IGJl DQoJdW5yZWxpYWJsZSBpcyBvayBJTU8uDQoJDQoJVGhlIHByb2JsZW0gaXMgdGhhdCBpZiBhIHBy b3h5IHNlbmRzIHRoZSAxOTksIHRoZW4gdGhlIHJlY2lwaWVudCBvZiB0aGUNCglQUkFDSyBzaG91 bGQgYmUgdGhlIHByb3h5LiBCdXQgdGhlIFBSQUNLIGlzIGFuIGluLWRpYWxvZyBtZXNzYWdlLCBz byBpdA0KCW11c3QgYmUgYWRkcmVzc2VkIHRvIHRoZSBDb250YWN0IG9mIHRoZSBVQVMuDQoJDQoJ SWYgdGhlIHByb3h5IHNlbmRzIGEgcmVsaWFibGUgMTk5LCBhbmQgdGhlIFBSQUNLIGlzIGFkZHJl c3NlZCB0byB0aGUNCglVQVMsIHRoZSBVQVMgd2lsbCBiZSB2ZXJ5IHN1cnByaXNlZCwgc2luY2Ug aXQgaGFzIG5vdCBzZW5kIGEgcmVsaWFibGUNCglwcm92aXNpb25hbCwgYW5kIGlzIHNvIG5vdCBl eHBlY3RpbmcgYSBQUkFDSy4gSW4gZmFjdCwgaXQgaGFzIHNlbnQgYQ0KCWZpbmFsIHJlc3BvbnNl LCBoYXMgcHJlc3VtYWJseSBhbHJlYWR5IHJlY2VpdmVkIHRoZSBBQ0ssIGFuZCBzbyBpcw0KCWV4 cGVjdGluZyBub3RoaW5nLg0KCQ0KCVZlcnkgdWdseS4NCgkNCgkgICAgICAgICAgICAgICAgUGF1 bA0KCQ0KCXdhbmcubGlib0B6dGUuY29tLmNuIHdyb3RlOg0KCT4gDQoJPiBIaSwNCgk+IA0KCT4g QW5kIHRoZXJlIHN0aWxsIHR3byBxdWVzdGlvbnMgbGVmdC4NCgk+IA0KCT4gMS4gIElzIHRoZSAx OTkgc2hvdWxkIGJlIHJlbGlhYmxlIG9yIHVucmVsaWFibGU/DQoJPiAgICAgSSB0aGluayB0aGF0 IDE5OSBzaG91bGQgYmUgcmVsaWFibGUgaWYgcG9zc2libGUuDQoJPiANCgk+IA0KCT4gICAgRmly c3QsIElmIGEgY2xpZW50IHJlY2VpdmVzIGFuIHVucmVsaWFibGUgMTk5IHJlc3BvbnNlIG9uIGEg ZGlhbG9nIA0KCT4gd2hpY2ggaGFzDQoJPiAgICBub3QgcHJldmlvdXNseSBiZWVuIGNyZWF0ZWQg KHRoaXMgY2FuIGhhcHBlbiBpZiBhIDE5OSByZXNwb25zZQ0KCT4gICAgcmVhY2hlcyB0aGUgY2xp ZW50IGJlZm9yZSBhIDE4eCByZXNwb25zZSkgdGhlIGNsaWVudCBTSEFMTCBkaXNjYXJkDQoJPiAg ICB0aGUgMTk5IHJlc3BvbnNlcy4NCgk+IA0KCT4gICAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBh biBleGFtcGxlLlRoZSAxODAgaXMgc2VudCBmaXJzdCBidXQgYXJyaXZlcyANCgk+IGxhdGVyIHRo YW4gMTk5Lg0KCT4gSWYgdGhlIDE5OSBpcyByZWxpYWJsZSwgdGhlIHByb3h5IHNob3VsZCByZXRy YW5zbWl0IDE5OSAoc3RlcCA0KSxhbmQgDQoJPiB0aGVuIHRoZSByZXRyYW5zbWl0dGVkDQoJPiAx OTkgd2lsbCBiZSBhY2NlcHRlZCBieSBVQUMsYW5kIHRoZSBlYXJseSBkaWFsb2cgd2lsbCBiZSB0 ZW1pbmF0ZWQuDQoJPiANCgk+IFVBQyAgICAgICAgICAgICBQDQoJPiAgICAxLiBJTlZJVEUNCgk+ IC0tLS0tLS0tLS0tLS0tLT4NCgk+ICAgICAgICAgICAyLiAxODANCgk+IDwtLS0tLSBcLy0tLS0t LS0NCgk+ICAgICAgICAvXCAzLiAxOTkNCgk+IDwtLS0tLS8gIFwtLS0tLS0NCgk+ICAgICAgICAg ICA0LiAxOTkocmV0cmFuc21pdHRlZCkNCgk+IDwtLS0tLS0tLS0tLS0tLS0NCgk+IA0KCT4gICAg c2Vjb25kLCBBY2NvcmRpbmcgdG8gcHJhY3RpY2FsIHVzZSwgMTk5IGNhbiBiZSBpbnRlbmRlZCB0 byB0ZW1pbmF0ZSANCgk+IG9uZSBlYXJseSBkaWFsb2cgYW5kIHJlbGVhc2UNCgk+IHJlc291cmNl cyBhc3NvY2lhdGVkIHdpdGggdGhlIHNwZWNpZmljIGVhcmx5IGRpYWxvZywgc28gdGhlIGNvc3Qg c3BlbnQgDQoJPiBvbiByZWxpYWJsZSAxOTkgaXMgd29ydGh5Lg0KCT4gSWYgdGhlIDE5OSBjYW5u b3QgYmUgc2VudCByZWxpYWJsZSx0aGVuIHdlIHNob3VsZCBzZW5kIGl0IHVucmVsaWFibGUuDQoJ PiAgDQoJPiAyLiBJbiB5b3VyIGxhc3QgbGV0dGVyLCB5b3Ugc2FpZCAidGhlIHNlY29uZCAxOTkg Y291bGQgaW5jbHVkZSANCgk+IGluZm9ybWF0aW9uIHdoaWNoIGlzIHRvIGJlIGZvcndhcmRlZCB0 byB0aGUNCgk+IFVBQyIsIHRoZW4gZG8geW91IG1lYW4sIHRoZSBlYXJseSBkaWFsb2cgaXMgc3Rp bGwgYWxpdmUgYWZ0ZXIgdGhlIGZpcnN0IA0KCT4gMTk5IGlzIGFjY2VwdGVkPw0KCT4gDQoJPiAN Cgk+IEFsc28sIEluIG15IGxhc3QgbGV0dGVyLCBJIG1pc3MgYSAiTk9UIiBieSBtaXN0YWtlLg0K CT4gSXQgc2hvdWxkIGJlDQoJPiBbRXJpY106IFN1cmVseSB0aGUgVUFTIGlzIE5PVCBhbGxvd2Vk IHRvIHNlbmQgYW5vdGhlciByZWxpYWJsZSByZXNwb25zZQ0KCT4gdW50aWwgdGhlIGZpcnN0IG9u ZSBpcyBhY2tub3dsZWRnZWQuLi4NCgk+IA0KCT4gUmVnYXJkcywNCgk+IEVyaWMgd2FuZw0KCT4g DQoJPiANCgk+IA0KCT4gDQoJPiAqIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPioNCgk+IA0KCT4gMjAwOS0wMi0yNyAwMzowNA0KCT4gDQoJPiAgICAg ICAgICAgICAgICAgIA0KCT4g5pS25Lu25Lq6DQoJPiAgICAgICAgICAgICAgICAgICJFcmljIHdh bmciIDxlcmljLndhbmd4ckBnbWFpbC5jb20+DQoJPiDmioTpgIENCgk+ICAgICAgICAgICAgICAg ICAgPHNpcEBpZXRmLm9yZz4sIDx3YW5nLmxpYm9AenRlLmNvbS5jbj4NCgk+IOS4u+mimA0KCT4g ICAgICAgICAgICAgICAgICBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1pZXRmLXNpcC0xOTkt MDUiDQoJPiANCgk+IA0KCT4gICAgICAgICAgICAgICAgICANCgk+IA0KCT4gDQoJPiANCgk+IA0K CT4gDQoJPiBIaSwNCgk+IA0KCT4gID5JIHN0aWxsIGhhdmUgc29tZSBkaWZmaWN1bHQgaW4gdXNp bmcgSUVURiBhbmQgY2Fubm90IGZpbmQgdGhlIHdob2xlDQoJPiBzb3J0ZWQgY29tbWVudHMgYWJv dXQgdGhpcyBkcmFmdCwgc28gaSBoYXZlIHNvbWUgZG91YnQgYWJvdXQgdGhpcyBkcmFmdC4NCgk+ ICA+DQoJPiAgPiAgIDEuICAgIklmIGEgZm9ya2luZyBwcm94eSByZWNlaXZlcyBhIHJlbGlhYmx5 IHNlbnQgMTk5IHJlc3BvbnNlIGZvciBhDQoJPiBkaWFsb2csIGZvciB3aGljaCB0aGUgcHJveHkg aGFzIHByZXZpb3VzbHkgZ2VuZXJhdGVkIGFuZCBzZW50IGEgMTk5DQoJPiByZXNwb25zZSwgdGhl IHByb3h5IE1VU1QgZm9yd2FyZCB0aGUgMTk5IHJlc3BvbnNlLiINCgk+ICA+DQoJPiAgPiAgICAg RG9lcyBpdCBkZXNjcmliZSB0aGUgY2FzZSBiZWxvdz8gQWx0aG91Z2ggUDEgaGF2ZSBzZW50IGEg MTk5DQoJPiByZXNwb25zZSwgUDEgaGF2cyB0byAgZm9yd29yZCB0aGUgc2VuZCByZWxpYWJseSAx OTkgdG9vLk9yICBpcyB0aGUNCgk+IGZpcnN0IDE5OSBtaXN0YWtlZCBmb3IgMTh4Pw0KCT4gID4N Cgk+ICA+ICAgICAgICAgIFVBQyAgICAgICAgICAgICAgIFAxICAgICAgICAgICAgICAgICAgVUFT XzINCgk+ICA+ICAgICAgICAgICAgLS0tIElOVklURSAtLS0tLS0+DQoJPiAgPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0tIElOVklURSAobGVnIDIpIC0+DQoJPiAgPiAgICAgICAgICAg IDwtLSAxOTkobGVnIDIpIC0tDQoJPiAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0t IDE5OSAobGVnIDIpIC0tLS0tDQoJPiAgPiAgICAgICAgICAgIDwtLSAxOTkobGVnIDIpIC0tDQoJ PiANCgk+ICA+SSB0aGluayBpdCBzaGFsbCBiZSAxOTksIGFzIGN1cnJlbnRseSB3cml0dGVuLg0K CT4gID4NCgk+ICA+W0VyaWNdOiBJZiAgdGhpcyBpcyAxOTksIHRoZW4gSXMgdGhlcmUgYSBzcGVj aWFsIHB1cnBvc2UgdG8gc2VuZCB0d28NCgk+IDE5OSBpbiB0aGUgc2FtZSBkaWFsb2c/DQoJPiAg PkkgdGhpbmsgdGhhdCBvbmUgMTk5IGlzIGVub3VnaC4NCgk+ICA+QW5kICB0aGUgZmlyc3QgMTk5 IG1heSBiZSByZWxpYWJsZSB0b28sIHRoYXQgd2lsbCBtYWtlIGl0IGEgbGl0dGxlDQoJPiBkaWZm aWN1bHQgdG8gc2VuZCB0aGUgc2Vjb25kIDE5OS4NCgk+IA0KCT4gVGhlIHNlY29uZCAxOTkgY291 bGQgaW5jbHVkZSBpbmZvcm1hdGlvbiB3aGljaCBpcyB0byBiZSBmb3J3YXJkZWQgdG8gdGhlDQoJ PiBVQUMuDQoJPiANCgk+IA0KCT4gID4yLiAgIjEwLiAgVXNhZ2Ugd2l0aCAxMDByZWwNCgk+ICA+ DQoJPiAgPiAgIFdoZW4gYSAxOTkgRWFybHkgRGlhbG9nIFRlcm1pbmF0ZWQgcHJvdmlzaW9uYWwg cmVzcG9uc2UgaXMgc2VudCBieSBhDQoJPiBVQVMsIHNpbmNlIHRoZSBwcm92aXNpb25hbCByZXNw b25zZSBpcyBvbmx5IHVzZWQgZm9yIGluZm9ybWF0aW9uDQoJPiBwdXJwb3NlLCB0aGUgVUFTIFNI T1VMRCBzZW5kIGl0IHVucmVsaWFibHkgZXZlbiBpZiB0aGUgMTAwcmVsDQoJPiAgPiAgIG9wdGlv biB0YWcgW1JGQzMyNjJdIGlzIHByZXNlbnQgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIG9mIHRoZQ0K CT4gYXNzb2NpYXRlZCByZXF1ZXN0LiINCgk+ICA+DQoJPiAgPg0KCT4gID5JIGhhdmUgc2VlbiBh IGNvbW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQgc3RpbGwgbm90IHVuZGVyc3Rvb2QgYWJvdXQN Cgk+ICA+aXQuIElmIHRoZSBJTlZJVEUgaGFzIGEgUmVxdWlyZSB0YWcgIlJlcXVpcmU6IDEwMHJl bCIsZG9lcyB0aGUgVUFTDQoJPiBzdGlsbA0KCT4gID51c2UgdW5yZWxpYWJsZSAxOTkgcmVzcG9u c2U/DQoJPiAgPg0KCT4gID5UaGF0IGlzIHRoZSByZWNvbW1lbmRhdGlvbiwgeWVzLiBUaGUgcmVh c29ucyBpcyB0aGF0IHdlIHdhbnQgdG8ga2VlcA0KCT4gMTk5DQoJPiAgPmFzICJsaWdodHdlaWdo dCIgYXMgcG9zc2libGUsIHdpdGhvdXQgcmVxdWlyZWluZyByZS10cmFuc21pc3Npb25zIGFuZA0K CT4gID5QUkFDS3MuDQoJPiAgPg0KCT4gID5bRXJpY106IEJ1dCByZWxpYWJsZSAxOTkgaGF2ZSBt b3JlIGFkdmFudGFnZSwgYW5kIEl0IGlzIHdvcnRoIHRvIHVzZQ0KCT4gdGhlIHJlbGlhYmxlIDE5 OSxJIHRoaW5rLg0KCT4gDQoJPiBJIGRvbid0IGtub3cgd2hhdCB0aGF0IGFkdmFudGFnZSB3b3Vs ZCBiZSwgY29tcGFyZWQgdG8gaGF2aW5nIHRvIHNlbmQNCgk+IFBSQUNLcyBldGMuIFRoaXMgaGFz IGJlZW4gZGlzY3Vzc2VkIHF1aXRlIG11Y2gsIHNvIEkgd291bGQgcmVhbGx5IG5lZWQNCgk+IHNv bWUgZ29vZCBqdXN0aWZpY2F0aW9uIHRvIGNoYW5nZSBpdCBub3cuDQoJPiANCgk+IEFsc28sIHRo ZSBkcmFmdCBkb2Vzbid0IGZvcmJpZCB5b3UgdG8gc2VuZCB0aGUgMTk5IHJlbGlhYmx5LiBJdCdz IG9ubHkgYQ0KCT4gU0hPVUxELg0KCT4gDQoJPiANCgk+ICA+SWYgMTk5IGlzIHJlbGlhYmxlLCB0 aGVyZSBpcyBvbmUgbW9yZSBhZHZhbnRhZ2UuIElmIHRoZSAxOTkgYXJyaXZlcw0KCT4gID5iZWZv cmUgdGhlIGZpcnN0IDE4eCByZXNwb25zZSwgVUFDIGNhbiBkaXNjYXJkIHRoZSBmaXJzdCAxOTkg YW5kDQoJPiBwcm9jZXNzDQoJPiAgPml0IHVudGlsIFVBQyByZWNlaXZlcyB0aGUgZmlyc3QgMTh4 IHJlc3BvbnNlIHRoYXQgaGFzIHRoZSBzYW1lDQoJPiAgPnRvLXRhZyBhcyAxOTksIGFzIHRoZSBy ZWxpYWJsZSAxOTkgc2hvdWxkIGJlIHJlLXRyYW5zbWl0ZWQgdW50aWwNCgk+ICA+cmVjZWl2ZWQg UFJBQ0suDQoJPiAgPg0KCT4gID5JZiB0aGUgSU5WSVRFIGNvbnRhaW5zICJSZXF1aXJlOiAxMDBy ZWwiLCB0aGUgZmlyc3QgMTh4IG11c3QgYWxzbyBiZQ0KCT4gID5zZW50IHJlbGlhYmx5LiBBbmQs IEkgZG9uJ3QgdGhpbmsgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlcg0KCT4gID5y ZWxpYWJsZSByZXNwb25zZSB1bnRpbCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZCwgc28g SSBkb24ndCB0aGluaw0KCT4gID5hIHJlbGlhYmxlIDE5OSB3b3VsZCByZWFjaCB0aGUgVUFDIGJl Zm9yZSB0aGUgZmlyc3QgcmVsaWFibGUgMTh4Lg0KCT4gID4NCgk+ICA+W0VyaWNdOiBTdXJlbHkg dGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlciByZWxpYWJsZSByZXNwb25zZQ0KCT4g dW50aWwgdGhlIGZpcnN0IG9uZSBpcyBhY2tub3dsZWRnZWQsDQoJPiANCgk+IElmIEkgcmVtZW1i ZXIgY29ycmVjdGx5LCB0aGUgRklSU1QgcmVsaWFibGUgcmVzcG9uc2UgbXVzdCBiZSBhY2tub3ds ZWRlZA0KCT4gYmVmb3JlIHRoZSBuZXh0IHJlbGlhYmxlIHJlc3BvbnNlIGlzIHNlbnQuIEJ1dCwg d2UgY2FuIGRvdWJsZSBjaGVjayBpbg0KCT4gdGhlIFBSQUNLIHNwZWMuDQoJPiANCgk+ICA+YnV0 IHJlbGlhYmxlIDE5OSB3aWxsIGJlIHVzZWZ1bCBpZiB0aGUgZmlyc3QgMTh4IGlzIHVucmVsaWFi bGUsIG9yIHRoZQ0KCT4gZmlyc3QgMTh4IGhhcyBiZWVuIGFja253bGVkZ2VkLiBJdCdzIGFub3Ro ZXIgY2FzZSBkaWZmZXJlbnQgZnJvbSB0aGUNCgk+IGFib3ZlIG9uZSAgd2hvc2UgSU5WSVRFIGNv bnRhaW5zICJyZXF1aXJlOiAxMDByZWwiLg0KCT4gDQoJPiBJZiAxMDByZWwgaXMgcmVxdWlyZWQg dGhlIDE4eCBjYW5ub3QgYmUgdW5yZWxpYWJsZS4NCgk+IA0KCT4gUmVnYXJkcywNCgk+IA0KCT4g Q2hyaXN0ZXINCgk+IA0KCT4gDQoJPiANCgk+IA0KCT4gDQoJPiANCgk+IA0KCT4gDQoJPiANCgk+ IA0KCT4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCgk+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NCgk+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCgk+IFRo aXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBB bnRpLVNwYW0gc3lzdGVtLg0KCT4gDQoJPiANCgk+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCT4gDQoJPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4gU2lwIG1h aWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCgk+ IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2Nv bA0KCT4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMg b24gY3VycmVudCBzaXANCgk+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1l bnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCgkNCgkNCgkgDQoJLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBt YWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3Zl IGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMu DQoJVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KCVRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KCQ0KDQoJX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTaXAgbWFpbGlu ZyBsaXN0ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCVRoaXMg bGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KCVVz ZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJl bnQgc2lwDQoJVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhl IGFwcGxpY2F0aW9uIG9mIHNpcA0KCQ0KDQoNCg== ------_=_NextPart_001_01C998CA.9E576D16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjM3OTAuNDQyNiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NDgzNjU5MTAtMjcwMjIwMDk+PEZPTlQgZmFjZT1B cmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz00NDgzNjU5MTAtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZndDs8L0ZPTlQ+PC9TUEFOPklmIHRoZSBVQUMgcmVxdWly ZXMgMTAwcmVsICx0aGVuIHdoYXQgc2hvdWxkIHRoZSBwcm94eSANCmRvIGlmIGl0IHJlY2VpdmVz IGEgbm8tMnh4PFNQQU4gY2xhc3M9NDQ4MzY1OTEwLTI3MDIyMDA5PjxGT05UIGZhY2U9QXJpYWwg DQpjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJzcDsgJm5ic3A7PC9GT05UPjwvU1BBTj5maW5hbCBy ZXNwb25zZSBhZnRlciANCmZvcmtpbmc/PFNQQU4gY2xhc3M9NDQ4MzY1OTEwLTI3MDIyMDA5PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFO PjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00NDgzNjU5MTAtMjcwMjIwMDk+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8 RElWPjxTUEFOIGNsYXNzPTQ0ODM2NTkxMC0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPlRoZSANCnByb3h5Jm5ic3A7c2hvdWxkIHNlbmQgMTk5IHVucmVsaWFi bHkuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDQ4MzY1OTEwLTI3MDIy MDA5PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00NDgzNjU5MTAtMjcwMjIwMDk+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPjwvU1BBTj48 L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDQ4MzY1OTEwLTI3MDIyMDA5PjxGT05UIGZhY2U9QXJp YWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz00NDgzNjU5MTAtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0Kc2l6ZT0yPkNocmlzdGVyPC9GT05UPiZuYnNwOzwvU1BBTj48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjxCUj48 QlI+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPWdtYWlsX3F1b3RlPjIwMDkvMi8yNywg Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxBIA0KaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9BPiZndDs6PC9T UEFOPiANCg0KPEJMT0NLUVVPVEUgY2xhc3M9Z21haWxfcXVvdGUgDQpzdHlsZT0iUEFERElORy1M RUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFw eCBzb2xpZCI+DQogIDxESVY+PFNQQU4gY2xhc3M9cT4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+SGksPC9G T05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPiZu YnNwOyZuYnNwOzwvRk9OVD48QlI+PEZPTlQgDQogIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxT UEFOPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQogIGNvbG9yPSMwMDAwMDA+Jmd0OzwvRk9O VD48L0ZPTlQ+PC9TUEFOPlByYWN0aWNhbGx5LCB3aGVuIENhbGwgZm9yd2FyZCBhbmQgZm9yayAN CiAgYXJlIHVzZWQgaW4gdGhlIHNhbWUgc3lzdGVtLCB0aGVyZSBhcmUmbmJzcDs8L0ZPTlQ+PC9G T05UPjxCUj48Rk9OVCANCiAgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4+PEZPTlQgY29s b3I9IzAwMDBmZj48Rk9OVCANCiAgY29sb3I9IzAwMDAwMD4mZ3Q7PC9GT05UPjwvRk9OVD48L1NQ QU4+bG90cyBvZiBlYXJseSBkaWFsb2dzIHRoYXQgc2hvdWxkIGJlIA0KICBlbGltaW5hdGVkIGJ5 IDE5OSBleGlzdGVkLjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIGZhY2U9QXJpYWw+PEZP TlQgDQogIHNpemU9Mj48U1BBTj48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIGZhY2U9IiIgY29s b3I9IzAwMDAwMCANCiAgc2l6ZT0zPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj5TbyBJIHRoaW5r IHRoYXQgaXQncyB1c2VmdWwgdG8gbGV0IDE5OSANCiAgcmVsaWFibGUuJm5ic3A7PC9GT05UPjwv Rk9OVD48QlI+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4+PEZPTlQgDQogIGNv bG9yPSMwMDAwZmY+PEZPTlQgY29sb3I9IzAwMDAwMD4mZ3Q7PC9GT05UPjwvRk9OVD48L1NQQU4+ QW5kIHdlIGp1c3QgYWRkZWQgDQogIGZvcmstc2VydmljZSB0byBvdXIgc3lzdGVtICxhbmQgZmlu ZCAxOTkgaXMgcmVhbGx5IHVzZWZ1bCwgDQogIGFuZDwvRk9OVD48L0ZPTlQ+Jm5ic3A7PEJSPjxG T05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOPjxGT05UIA0KICBjb2xvcj0jMDAwMGZm PjxGT05UIGZhY2U9IiIgY29sb3I9IzAwMDAwMCBzaXplPTM+Jmd0OzwvRk9OVD48L0ZPTlQ+PC9T UEFOPmlmIA0KICB0aGUgMTk5IGlzIG1pc3NpbmcsIHByb2JsZW1zIHdpbGwgaGFwcGVuLjwvRk9O VD48L0ZPTlQ+Jm5ic3A7PFNQQU4+PEZPTlQgDQogIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBz aXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTj48L1NQQU4+Jm5i c3A7PC9ESVY+PC9TUEFOPg0KICA8RElWPjxTUEFOPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiBzaXplPTI+SSdtIGdsYWQgeW91IHRoaW5rIDE5OSBpcyANCiAgdXNlZnVsIDopPC9GT05U PjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5CdXQsIGlmIGEgcHJveHkgd291bGQgaGF2 ZSB0byANCiAgdGVybWluYXRlIFBSQUNLcyBldGMgaXQgd291bGQgbm90IGJlIGEgcHJveHkgYW55 bW9yZSAtIGl0IHdvdWxkIGJlIGEgDQogIEIyQlVBLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxE SVY+PFNQQU4+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9T UEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiBzaXplPTI+U28sIGlmIHlvdSByZWFsbHkgd2FudCB5b3VyIA0KICBuZXR3b3JrIHRvIHNl bmQgMTk5IHJlbGlhYmx5LCBJIGd1ZXNzIHlvdSBjb3VsZCB1c2UgYSBCMkJVQSBpbnN0ZWFkIG9m IGEgDQogIHByb3h5LjwvRk9OVD48L1NQQU4+PC9ESVY+PFNQQU4gY2xhc3M9cT48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+DQogIDxESVY+PEJSPjxGT05U IGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOPjxGT05UIA0KICBjb2xvcj0jMDAwMGZmPiZn dDs8L0ZPTlQ+PC9TUEFOPkl0IHNvdW5kcyBnb29kIHRoYXQgdGhlcmUgaXMgYSB3YXkgdG8gcHJl dmVudCANCiAgUFJBQ0sgYWRkcmVzc2VkIHRvIFVBUyxidXQgaSBkb24ndCBrbm93PFNQQU4+PEZP TlQgY29sb3I9IzAwMDBmZj4mbmJzcDsgDQogIDwvRk9OVD48L1NQQU4+aG93IHRvIGRvIG5vdy48 U1BBTj48Rk9OVCANCiAgY29sb3I9IzAwMDBmZj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48 L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgc2l6ZT0yPjxT UEFOPjwvU1BBTj48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElWPjwvU1BBTj4NCiAgPERJVj48Rk9O VCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTj48Rk9OVCBjb2xvcj0jMDAwMGZmPlRoZSBv bmx5IHdheSB0byANCiAgcHJldmVudCBpdCBpcyBieSB0aGUgcHJveHkgbm90IHNlbmRpbmcgdGhl IA0KICAxOTkmbmJzcDtyZWxhaWJsZS48L0ZPTlQ+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0ZPTlQ+ Jm5ic3A7PFNQQU4gDQogIGNsYXNzPXE+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCiAgc2l6 ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCANCiAgc2l6ZT0yPjxTUEFOPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwIA0KICBzaXplPTM+Jmd0OzwvRk9OVD48L0ZPTlQ+ PC9TUEFOPnBzOjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIHNpemU9Mj48Rk9OVCANCiAg ZmFjZT1BcmlhbD48U1BBTj48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgDQogIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BB Tj5SRkMzMjYxIDwvRk9OVD48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciIGNvbG9yPSMwMDIw NDE+PEI+MTYuNyBSZXNwb25zZSBQcm9jZXNzaW5nPC9CPjwvRk9OVD48Rk9OVCANCiAgZmFjZT1z YW5zLXNlcmlmPiZuYnNwOzwvRk9OVD48L0ZPTlQ+PEJSPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQg DQogIHNpemU9Mj48U1BBTj48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIA0KICBjb2xvcj0jMDAw MDAwPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj5TaW5jZSBhIHByb3h5IG1heSBub3QgaW5zZXJ0 IGEgdGFnIGludG8gDQogIHRoZSBUbyBoZWFkZXIgZmllbGQgb2Y8L0ZPTlQ+PC9GT05UPiZuYnNw OzxCUj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICBzaXplPTI+PFNQQU4+PEZPTlQgY29sb3I9 IzAwMDBmZj4mZ3Q7PC9GT05UPjwvU1BBTj5hIDF4eCByZXNwb25zZSB0byBhIHJlcXVlc3QgDQog IHRoYXQgZGlkIG5vdCBjb250YWluIG9uZSwgPEZPTlQgY29sb3I9Ymx1ZT5pdCANCiAgY2Fubm90 PC9GT05UPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQog IGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0yPjxTUEFOPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgY29sb3I9IzAwMDAwMCANCiAgc2l6ZT0zPiZndDs8L0ZPTlQ+PC9TUEFOPmlzc3VlIG5v bi0xMDAgcHJvdmlzaW9uYWwgcmVzcG9uc2VzIG9uIGl0cyANCiAgb3duLjwvRk9OVD48L0ZPTlQ+ PC9GT05UPiZuYnNwOzxTUEFOPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6 ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOPjwvU1BB Tj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPlllcywgYnV0IEkmbmJzcDt3ZSBoYXZlIA0KICBhZ3JlZWQgdGhhdCBhIHByb3h5 IGlzIGFsbG93ZWQgdG8gc2VuZCAxOTkuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BB Tj48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIHNpemU9Mj5CdXQsIHRoZSBwcm94eSBpcyBub3QgZ29pbmcgDQogIHRvIGdlbmVy YXRlIG5ldyBUbyBoZWFkZXIgdGFnIHZhbHVlcyBmb3IgdGhlIDE5OS4gSXQgd2lsbCB1c2Ugd2hh dGV2ZXIgdGFncyANCiAgdGhhdCBoYXZlIGFscmVhZHkmbmJzcDtiZWVuIGNyZWF0ZWQgZm9yIHRo ZSZuYnNwO2Vhcmx5IA0KICBkaWFsb2dzLjwvRk9OVD4mbmJzcDs8L1NQQU4+PC9ESVY+DQogIDxE SVY+PFNQQU4+PC9TUEFOPjxTUEFOPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAg c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5SZWdhcmRzLDwvRk9OVD48L1NQQU4+PC9ESVY+ DQogIDxESVY+PFNQQU4+PC9TUEFOPiZuYnNwOzwvRElWPjxTUEFOIGNsYXNzPXNnPg0KICA8RElW PjxTUEFOPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPkNocmlzdGVy PC9GT05UPjwvU1BBTj48L0RJVj48L1NQQU4+DQogIDxESVY+PFNQQU4gY2xhc3M9ZSBpZD1xXzEx ZmI2Njc4YjE2NjExMmJfOD4NCiAgPERJVj48U1BBTj48L1NQQU4+PEJSPjxTUEFOPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9E SVY+DQogIDxESVY+PFNQQU4+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOPjwvU1BB Tj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTj48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+ PFNQQU4+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCiAgPERJVj48U1BBTj48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4+PC9TUEFO PjxCUj48QlI+PFRUPjxGT05UIHNpemU9Mj4qYWxsb3dpbmcqIChtdWNoIGxlc3MgKnJlcXVpcmlu ZyopIA0KICB0aGUgMTk5IHRvIGJlIHJlbGlhYmxlIGludHJvZHVjZXM8QlI+bmFzdHkgcHJvYmxl bXMuIFRoZSAxOTkgaXMgb25seSBhbiANCiAgb3B0aW1pemF0aW9uLCBzbyBoYXZpbmcgaXQgYmU8 QlI+dW5yZWxpYWJsZSBpcyBvayBJTU8uPEJSPjxCUj5UaGUgcHJvYmxlbSBpcyANCiAgdGhhdCBp ZiBhIHByb3h5IHNlbmRzIHRoZSAxOTksIHRoZW4gdGhlIHJlY2lwaWVudCBvZiB0aGU8QlI+UFJB Q0sgc2hvdWxkIGJlIA0KICB0aGUgcHJveHkuIEJ1dCB0aGUgUFJBQ0sgaXMgYW4gaW4tZGlhbG9n IG1lc3NhZ2UsIHNvIGl0PEJSPm11c3QgYmUgYWRkcmVzc2VkIA0KICB0byB0aGUgQ29udGFjdCBv ZiB0aGUgVUFTLjxCUj48QlI+SWYgdGhlIHByb3h5IHNlbmRzIGEgcmVsaWFibGUgMTk5LCBhbmQg dGhlIA0KICBQUkFDSyBpcyBhZGRyZXNzZWQgdG8gdGhlPEJSPlVBUywgdGhlIFVBUyB3aWxsIGJl IHZlcnkgc3VycHJpc2VkLCBzaW5jZSBpdCBoYXMgDQogIG5vdCBzZW5kIGEgcmVsaWFibGU8QlI+ cHJvdmlzaW9uYWwsIGFuZCBpcyBzbyBub3QgZXhwZWN0aW5nIGEgUFJBQ0suIEluIGZhY3QsIA0K ICBpdCBoYXMgc2VudCBhPEJSPmZpbmFsIHJlc3BvbnNlLCBoYXMgcHJlc3VtYWJseSBhbHJlYWR5 IHJlY2VpdmVkIHRoZSBBQ0ssIGFuZCANCiAgc28gaXM8QlI+ZXhwZWN0aW5nIG5vdGhpbmcuPEJS PjxCUj5WZXJ5IHVnbHkuPEJSPjxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYXVsPEJSPjxCUj48QSANCiAgb25jbGljaz0icmV0 dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIA0KICBocmVmPSJtYWls dG86d2FuZy5saWJvQHp0ZS5jb20uY24iIHRhcmdldD1fYmxhbms+d2FuZy5saWJvQHp0ZS5jb20u Y248L0E+IA0KICB3cm90ZTo8QlI+Jmd0OyA8QlI+Jmd0OyBIaSw8QlI+Jmd0OyA8QlI+Jmd0OyBB bmQgdGhlcmUgc3RpbGwgdHdvIHF1ZXN0aW9ucyANCiAgbGVmdC48QlI+Jmd0OyA8QlI+Jmd0OyAx LiAmbmJzcDtJcyB0aGUgMTk5IHNob3VsZCBiZSByZWxpYWJsZSBvciANCiAgdW5yZWxpYWJsZT88 QlI+Jmd0OyAmbmJzcDsgJm5ic3A7IEkgdGhpbmsgdGhhdCAxOTkgc2hvdWxkIGJlIHJlbGlhYmxl IGlmIA0KICBwb3NzaWJsZS48QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7 Rmlyc3QsIElmIGEgY2xpZW50IHJlY2VpdmVzIA0KICBhbiB1bnJlbGlhYmxlIDE5OSByZXNwb25z ZSBvbiBhIGRpYWxvZyA8QlI+Jmd0OyB3aGljaCBoYXM8QlI+Jmd0OyAmbmJzcDsgDQogICZuYnNw O25vdCBwcmV2aW91c2x5IGJlZW4gY3JlYXRlZCAodGhpcyBjYW4gaGFwcGVuIGlmIGEgMTk5IHJl c3BvbnNlPEJSPiZndDsgDQogICZuYnNwOyAmbmJzcDtyZWFjaGVzIHRoZSBjbGllbnQgYmVmb3Jl IGEgMTh4IHJlc3BvbnNlKSB0aGUgY2xpZW50IFNIQUxMIA0KICBkaXNjYXJkPEJSPiZndDsgJm5i c3A7ICZuYnNwO3RoZSAxOTkgcmVzcG9uc2VzLjxCUj4mZ3Q7IDxCUj4mZ3Q7ICZuYnNwOyANCiAg Jm5ic3A7VGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlLlRoZSAxODAgaXMgc2VudCBm aXJzdCBidXQgYXJyaXZlcyANCiAgPEJSPiZndDsgbGF0ZXIgdGhhbiAxOTkuPEJSPiZndDsgSWYg dGhlIDE5OSBpcyByZWxpYWJsZSwgdGhlIHByb3h5IHNob3VsZCANCiAgcmV0cmFuc21pdCAxOTkg KHN0ZXAgNCksYW5kIDxCUj4mZ3Q7IHRoZW4gdGhlIHJldHJhbnNtaXR0ZWQ8QlI+Jmd0OyAxOTkg d2lsbCANCiAgYmUgYWNjZXB0ZWQgYnkgVUFDLGFuZCB0aGUgZWFybHkgZGlhbG9nIHdpbGwgYmUg dGVtaW5hdGVkLjxCUj4mZ3Q7IDxCUj4mZ3Q7IA0KICBVQUMgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUDxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDsxLiANCiAgSU5WSVRF PEJSPiZndDsgLS0tLS0tLS0tLS0tLS0tJmd0OzxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgDQogIDIuIDE4MDxCUj4mZ3Q7ICZsdDstLS0tLSBcLy0tLS0tLS08QlI+ Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvXCAzLiANCiAgMTk5PEJSPiZndDsgJmx0 Oy0tLS0tLyAmbmJzcDtcLS0tLS0tPEJSPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IA0KICAmbmJzcDsgNC4gMTk5KHJldHJhbnNtaXR0ZWQpPEJSPiZndDsgJmx0Oy0tLS0tLS0tLS0t LS0tLTxCUj4mZ3Q7IDxCUj4mZ3Q7IA0KICAmbmJzcDsgJm5ic3A7c2Vjb25kLCBBY2NvcmRpbmcg dG8gcHJhY3RpY2FsIHVzZSwgMTk5IGNhbiBiZSBpbnRlbmRlZCB0byANCiAgdGVtaW5hdGUgPEJS PiZndDsgb25lIGVhcmx5IGRpYWxvZyBhbmQgcmVsZWFzZTxCUj4mZ3Q7IHJlc291cmNlcyBhc3Nv Y2lhdGVkIA0KICB3aXRoIHRoZSBzcGVjaWZpYyBlYXJseSBkaWFsb2csIHNvIHRoZSBjb3N0IHNw ZW50IDxCUj4mZ3Q7IG9uIHJlbGlhYmxlIDE5OSBpcyANCiAgd29ydGh5LjxCUj4mZ3Q7IElmIHRo ZSAxOTkgY2Fubm90IGJlIHNlbnQgcmVsaWFibGUsdGhlbiB3ZSBzaG91bGQgc2VuZCBpdCANCiAg dW5yZWxpYWJsZS48QlI+Jmd0OyAmbmJzcDs8QlI+Jmd0OyAyLiBJbiB5b3VyIGxhc3QgbGV0dGVy LCB5b3Ugc2FpZCAidGhlIA0KICBzZWNvbmQgMTk5IGNvdWxkIGluY2x1ZGUgPEJSPiZndDsgaW5m b3JtYXRpb24gd2hpY2ggaXMgdG8gYmUgZm9yd2FyZGVkIHRvIA0KICB0aGU8QlI+Jmd0OyBVQUMi LCB0aGVuIGRvIHlvdSBtZWFuLCB0aGUgZWFybHkgZGlhbG9nIGlzIHN0aWxsIGFsaXZlIGFmdGVy IHRoZSANCiAgZmlyc3QgPEJSPiZndDsgMTk5IGlzIGFjY2VwdGVkPzxCUj4mZ3Q7IDxCUj4mZ3Q7 IDxCUj4mZ3Q7IEFsc28sIEluIG15IGxhc3QgDQogIGxldHRlciwgSSBtaXNzIGEgIk5PVCIgYnkg bWlzdGFrZS48QlI+Jmd0OyBJdCBzaG91bGQgYmU8QlI+Jmd0OyBbRXJpY106IFN1cmVseSANCiAg dGhlIFVBUyBpcyBOT1QgYWxsb3dlZCB0byBzZW5kIGFub3RoZXIgcmVsaWFibGUgcmVzcG9uc2U8 QlI+Jmd0OyB1bnRpbCB0aGUgDQogIGZpcnN0IG9uZSBpcyBhY2tub3dsZWRnZWQuLi48QlI+Jmd0 OyA8QlI+Jmd0OyBSZWdhcmRzLDxCUj4mZ3Q7IEVyaWMgDQogIHdhbmc8QlI+Jmd0OyA8QlI+Jmd0 OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyAqIkNocmlzdGVyIEhvbG1iZXJnIiAmbHQ7PEEg DQogIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp IiANCiAgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgDQogIHRh cmdldD1fYmxhbms+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9BPiZndDsqPEJSPiZn dDsgPEJSPiZndDsgDQogIDIwMDktMDItMjcgMDM6MDQ8QlI+Jmd0OyA8QlI+Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgJm5ic3A7ICZuYnNwOyAmbmJz cDs8QlI+Jmd0OyDmlLbku7bkuro8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IA0KICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsiRXJpYyB3YW5nIiAmbHQ7PEEg DQogIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp IiANCiAgaHJlZj0ibWFpbHRvOmVyaWMud2FuZ3hyQGdtYWlsLmNvbSIgDQogIHRhcmdldD1fYmxh bms+ZXJpYy53YW5neHJAZ21haWwuY29tPC9BPiZndDs8QlI+Jmd0OyDmioTpgIE8QlI+Jmd0OyAm bmJzcDsgJm5ic3A7IA0KICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7PEEgDQogIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIiANCiAgaHJlZj0ibWFpbHRvOnNpcEBpZXRmLm9yZyIgdGFyZ2V0PV9i bGFuaz5zaXBAaWV0Zi5vcmc8L0E+Jmd0OywgJmx0OzxBIA0KICBvbmNsaWNrPSJyZXR1cm4gdG9w LmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgDQogIGhyZWY9Im1haWx0bzp3YW5n LmxpYm9AenRlLmNvbS5jbiIgDQogIHRhcmdldD1fYmxhbms+d2FuZy5saWJvQHp0ZS5jb20uY248 L0E+Jmd0OzxCUj4mZ3Q7IOS4u+mimDxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDsgDQogICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JFOiBRdWVzdGlvbnMgYWJv dXQgDQogICJkcmFmdC1pZXRmLXNpcC0xOTktMDUiPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgDQog IDxCUj4mZ3Q7IEhpLDxCUj4mZ3Q7IDxCUj4mZ3Q7ICZuYnNwOyZndDtJIHN0aWxsIGhhdmUgc29t ZSBkaWZmaWN1bHQgaW4gdXNpbmcgDQogIElFVEYgYW5kIGNhbm5vdCBmaW5kIHRoZSB3aG9sZTxC Uj4mZ3Q7IHNvcnRlZCBjb21tZW50cyBhYm91dCB0aGlzIGRyYWZ0LCBzbyBpIA0KICBoYXZlIHNv bWUgZG91YnQgYWJvdXQgdGhpcyBkcmFmdC48QlI+Jmd0OyAmbmJzcDsmZ3Q7PEJSPiZndDsgJm5i c3A7Jmd0OyAmbmJzcDsgDQogIDEuICZuYnNwOyAiSWYgYSBmb3JraW5nIHByb3h5IHJlY2VpdmVz IGEgcmVsaWFibHkgc2VudCAxOTkgcmVzcG9uc2UgZm9yIA0KICBhPEJSPiZndDsgZGlhbG9nLCBm b3Igd2hpY2ggdGhlIHByb3h5IGhhcyBwcmV2aW91c2x5IGdlbmVyYXRlZCBhbmQgc2VudCBhIA0K ICAxOTk8QlI+Jmd0OyByZXNwb25zZSwgdGhlIHByb3h5IE1VU1QgZm9yd2FyZCB0aGUgMTk5IHJl c3BvbnNlLiI8QlI+Jmd0OyANCiAgJm5ic3A7Jmd0OzxCUj4mZ3Q7ICZuYnNwOyZndDsgJm5ic3A7 ICZuYnNwOyBEb2VzIGl0IGRlc2NyaWJlIHRoZSBjYXNlIGJlbG93PyANCiAgQWx0aG91Z2ggUDEg aGF2ZSBzZW50IGEgMTk5PEJSPiZndDsgcmVzcG9uc2UsIFAxIGhhdnMgdG8gJm5ic3A7Zm9yd29y ZCB0aGUgDQogIHNlbmQgcmVsaWFibHkgMTk5IHRvby5PciAmbmJzcDtpcyB0aGU8QlI+Jmd0OyBm aXJzdCAxOTkgbWlzdGFrZWQgZm9yIA0KICAxOHg/PEJSPiZndDsgJm5ic3A7Jmd0OzxCUj4mZ3Q7 ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAmbmJzcDtVQUMgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFAxICZuYnNwOyAm bmJzcDsgDQogICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1VBU18yPEJSPiZndDsgJm5ic3A7Jmd0OyANCiAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDstLS0gSU5WSVRFIC0tLS0tLSZndDs8QlI+Jmd0OyANCiAgJm5ic3A7Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyANCiAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLS0gSU5WSVRF IChsZWcgMikgLSZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7IA0KICAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDstLSAxOTkobGVnIDIpIC0tPEJSPiZndDsgDQogICZu YnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgDQogICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0 Oy0tIDE5OSAobGVnIDIpIC0tLS0tPEJSPiZndDsgJm5ic3A7Jmd0OyANCiAgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7LS0gMTk5KGxlZyAyKSAtLTxCUj4mZ3Q7 IDxCUj4mZ3Q7IA0KICAmbmJzcDsmZ3Q7SSB0aGluayBpdCBzaGFsbCBiZSAxOTksIGFzIGN1cnJl bnRseSB3cml0dGVuLjxCUj4mZ3Q7IA0KICAmbmJzcDsmZ3Q7PEJSPiZndDsgJm5ic3A7Jmd0O1tF cmljXTogSWYgJm5ic3A7dGhpcyBpcyAxOTksIHRoZW4gSXMgdGhlcmUgYSANCiAgc3BlY2lhbCBw dXJwb3NlIHRvIHNlbmQgdHdvPEJSPiZndDsgMTk5IGluIHRoZSBzYW1lIGRpYWxvZz88QlI+Jmd0 OyANCiAgJm5ic3A7Jmd0O0kgdGhpbmsgdGhhdCBvbmUgMTk5IGlzIGVub3VnaC48QlI+Jmd0OyAm bmJzcDsmZ3Q7QW5kICZuYnNwO3RoZSANCiAgZmlyc3QgMTk5IG1heSBiZSByZWxpYWJsZSB0b28s IHRoYXQgd2lsbCBtYWtlIGl0IGEgbGl0dGxlPEJSPiZndDsgZGlmZmljdWx0IHRvIA0KICBzZW5k IHRoZSBzZWNvbmQgMTk5LjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBzZWNvbmQgMTk5IGNvdWxkIGlu Y2x1ZGUgaW5mb3JtYXRpb24gDQogIHdoaWNoIGlzIHRvIGJlIGZvcndhcmRlZCB0byB0aGU8QlI+ Jmd0OyBVQUMuPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgDQogICZuYnNwOyZndDsyLiAmbmJz cDsiMTAuICZuYnNwO1VzYWdlIHdpdGggMTAwcmVsPEJSPiZndDsgJm5ic3A7Jmd0OzxCUj4mZ3Q7 IA0KICAmbmJzcDsmZ3Q7ICZuYnNwOyBXaGVuIGEgMTk5IEVhcmx5IERpYWxvZyBUZXJtaW5hdGVk IHByb3Zpc2lvbmFsIHJlc3BvbnNlIGlzIA0KICBzZW50IGJ5IGE8QlI+Jmd0OyBVQVMsIHNpbmNl IHRoZSBwcm92aXNpb25hbCByZXNwb25zZSBpcyBvbmx5IHVzZWQgZm9yIA0KICBpbmZvcm1hdGlv bjxCUj4mZ3Q7IHB1cnBvc2UsIHRoZSBVQVMgU0hPVUxEIHNlbmQgaXQgdW5yZWxpYWJseSBldmVu IGlmIHRoZSANCiAgMTAwcmVsPEJSPiZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgb3B0aW9uIHRhZyBb UkZDMzI2Ml0gaXMgcHJlc2VudCBpbiB0aGUgDQogIFJlcXVpcmUgaGVhZGVyIG9mIHRoZTxCUj4m Z3Q7IGFzc29jaWF0ZWQgcmVxdWVzdC4iPEJSPiZndDsgJm5ic3A7Jmd0OzxCUj4mZ3Q7IA0KICAm bmJzcDsmZ3Q7PEJSPiZndDsgJm5ic3A7Jmd0O0kgaGF2ZSBzZWVuIGEgY29tbWVudCBvbiB0aGlz IHF1ZXN0aW9uLGJ1dCBzdGlsbCANCiAgbm90IHVuZGVyc3Rvb2QgYWJvdXQ8QlI+Jmd0OyAmbmJz cDsmZ3Q7aXQuIElmIHRoZSBJTlZJVEUgaGFzIGEgUmVxdWlyZSB0YWcgDQogICJSZXF1aXJlOiAx MDByZWwiLGRvZXMgdGhlIFVBUzxCUj4mZ3Q7IHN0aWxsPEJSPiZndDsgJm5ic3A7Jmd0O3VzZSB1 bnJlbGlhYmxlIA0KICAxOTkgcmVzcG9uc2U/PEJSPiZndDsgJm5ic3A7Jmd0OzxCUj4mZ3Q7ICZu YnNwOyZndDtUaGF0IGlzIHRoZSByZWNvbW1lbmRhdGlvbiwgDQogIHllcy4gVGhlIHJlYXNvbnMg aXMgdGhhdCB3ZSB3YW50IHRvIGtlZXA8QlI+Jmd0OyAxOTk8QlI+Jmd0OyAmbmJzcDsmZ3Q7YXMg DQogICJsaWdodHdlaWdodCIgYXMgcG9zc2libGUsIHdpdGhvdXQgcmVxdWlyZWluZyByZS10cmFu c21pc3Npb25zIGFuZDxCUj4mZ3Q7IA0KICAmbmJzcDsmZ3Q7UFJBQ0tzLjxCUj4mZ3Q7ICZuYnNw OyZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7W0VyaWNdOiBCdXQgcmVsaWFibGUgDQogIDE5OSBoYXZl IG1vcmUgYWR2YW50YWdlLCBhbmQgSXQgaXMgd29ydGggdG8gdXNlPEJSPiZndDsgdGhlIHJlbGlh YmxlIDE5OSxJIA0KICB0aGluay48QlI+Jmd0OyA8QlI+Jmd0OyBJIGRvbid0IGtub3cgd2hhdCB0 aGF0IGFkdmFudGFnZSB3b3VsZCBiZSwgY29tcGFyZWQgdG8gDQogIGhhdmluZyB0byBzZW5kPEJS PiZndDsgUFJBQ0tzIGV0Yy4gVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgcXVpdGUgbXVjaCwgc28g SSANCiAgd291bGQgcmVhbGx5IG5lZWQ8QlI+Jmd0OyBzb21lIGdvb2QganVzdGlmaWNhdGlvbiB0 byBjaGFuZ2UgaXQgbm93LjxCUj4mZ3Q7IA0KICA8QlI+Jmd0OyBBbHNvLCB0aGUgZHJhZnQgZG9l c24ndCBmb3JiaWQgeW91IHRvIHNlbmQgdGhlIDE5OSByZWxpYWJseS4gSXQncyANCiAgb25seSBh PEJSPiZndDsgU0hPVUxELjxCUj4mZ3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7ICZuYnNwOyZndDtJZiAx OTkgaXMgcmVsaWFibGUsIA0KICB0aGVyZSBpcyBvbmUgbW9yZSBhZHZhbnRhZ2UuIElmIHRoZSAx OTkgYXJyaXZlczxCUj4mZ3Q7ICZuYnNwOyZndDtiZWZvcmUgdGhlIA0KICBmaXJzdCAxOHggcmVz cG9uc2UsIFVBQyBjYW4gZGlzY2FyZCB0aGUgZmlyc3QgMTk5IGFuZDxCUj4mZ3Q7IHByb2Nlc3M8 QlI+Jmd0OyANCiAgJm5ic3A7Jmd0O2l0IHVudGlsIFVBQyByZWNlaXZlcyB0aGUgZmlyc3QgMTh4 IHJlc3BvbnNlIHRoYXQgaGFzIHRoZSANCiAgc2FtZTxCUj4mZ3Q7ICZuYnNwOyZndDt0by10YWcg YXMgMTk5LCBhcyB0aGUgcmVsaWFibGUgMTk5IHNob3VsZCBiZSANCiAgcmUtdHJhbnNtaXRlZCB1 bnRpbDxCUj4mZ3Q7ICZuYnNwOyZndDtyZWNlaXZlZCBQUkFDSy48QlI+Jmd0OyANCiAgJm5ic3A7 Jmd0OzxCUj4mZ3Q7ICZuYnNwOyZndDtJZiB0aGUgSU5WSVRFIGNvbnRhaW5zICJSZXF1aXJlOiAx MDByZWwiLCB0aGUgDQogIGZpcnN0IDE4eCBtdXN0IGFsc28gYmU8QlI+Jmd0OyAmbmJzcDsmZ3Q7 c2VudCByZWxpYWJseS4gQW5kLCBJIGRvbid0IHRoaW5rIHRoZSANCiAgVUFTIGlzIGFsbG93ZWQg dG8gc2VuZCBhbm90aGVyPEJSPiZndDsgJm5ic3A7Jmd0O3JlbGlhYmxlIHJlc3BvbnNlIHVudGls IHRoZSANCiAgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZCwgc28gSSBkb24ndCB0aGluazxCUj4m Z3Q7ICZuYnNwOyZndDthIHJlbGlhYmxlIDE5OSANCiAgd291bGQgcmVhY2ggdGhlIFVBQyBiZWZv cmUgdGhlIGZpcnN0IHJlbGlhYmxlIDE4eC48QlI+Jmd0OyAmbmJzcDsmZ3Q7PEJSPiZndDsgDQog ICZuYnNwOyZndDtbRXJpY106IFN1cmVseSB0aGUgVUFTIGlzIGFsbG93ZWQgdG8gc2VuZCBhbm90 aGVyIHJlbGlhYmxlIA0KICByZXNwb25zZTxCUj4mZ3Q7IHVudGlsIHRoZSBmaXJzdCBvbmUgaXMg YWNrbm93bGVkZ2VkLDxCUj4mZ3Q7IDxCUj4mZ3Q7IElmIEkgDQogIHJlbWVtYmVyIGNvcnJlY3Rs eSwgdGhlIEZJUlNUIHJlbGlhYmxlIHJlc3BvbnNlIG11c3QgYmUgYWNrbm93bGVkZWQ8QlI+Jmd0 OyANCiAgYmVmb3JlIHRoZSBuZXh0IHJlbGlhYmxlIHJlc3BvbnNlIGlzIHNlbnQuIEJ1dCwgd2Ug Y2FuIGRvdWJsZSBjaGVjayBpbjxCUj4mZ3Q7IA0KICB0aGUgUFJBQ0sgc3BlYy48QlI+Jmd0OyA8 QlI+Jmd0OyAmbmJzcDsmZ3Q7YnV0IHJlbGlhYmxlIDE5OSB3aWxsIGJlIHVzZWZ1bCBpZiANCiAg dGhlIGZpcnN0IDE4eCBpcyB1bnJlbGlhYmxlLCBvciB0aGU8QlI+Jmd0OyBmaXJzdCAxOHggaGFz IGJlZW4gYWNrbndsZWRnZWQuIA0KICBJdCdzIGFub3RoZXIgY2FzZSBkaWZmZXJlbnQgZnJvbSB0 aGU8QlI+Jmd0OyBhYm92ZSBvbmUgJm5ic3A7d2hvc2UgSU5WSVRFIA0KICBjb250YWlucyAicmVx dWlyZTogMTAwcmVsIi48QlI+Jmd0OyA8QlI+Jmd0OyBJZiAxMDByZWwgaXMgcmVxdWlyZWQgdGhl IDE4eCANCiAgY2Fubm90IGJlIHVucmVsaWFibGUuPEJSPiZndDsgPEJSPiZndDsgUmVnYXJkcyw8 QlI+Jmd0OyA8QlI+Jmd0OyANCiAgQ2hyaXN0ZXI8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8 QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyANCiAgPEJSPiZndDsgPEJSPiZndDsg PEJSPiZndDsgPEJSPiZndDsgDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPiZndDsgWlRFIA0KICBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVs eSANCiAgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgDQogIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBh cmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSANCiAgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0KICBv dGhlcnMuPEJSPiZndDsgVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCANCiAgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSANCiAgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIA0KICBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGlu IHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgDQogIHRoZSBpbmRpdmlkdWFsIHNlbmRlci48QlI+ Jmd0OyBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgDQogIFNw YW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgDQog IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxCUj4mZ3Q7IA0KICA8QlI+Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7IFNpcCBtYWlsaW5nIA0KICBsaXN0 ICZuYnNwOzxBIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50 LHRoaXMpIiANCiAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXAiIA0KICB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwPC9BPjxCUj4mZ3Q7IFRoaXMgbGlzdCANCiAgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBv ZiB0aGUgY29yZSBTSVAgUHJvdG9jb2w8QlI+Jmd0OyBVc2UgPEEgDQogIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiANCiAgaHJlZj0ibWFpbHRv OnNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IiANCiAgdGFyZ2V0PV9ibGFuaz5zaXAt aW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdTwvQT4gZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50 IA0KICBzaXA8QlI+Jmd0OyBVc2UgPEEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGlu ayh3aW5kb3csZXZlbnQsdGhpcykiIA0KICBocmVmPSJtYWlsdG86c2lwcGluZ0BpZXRmLm9yZyIg dGFyZ2V0PV9ibGFuaz5zaXBwaW5nQGlldGYub3JnPC9BPiBmb3IgbmV3IA0KICBkZXZlbG9wbWVu dHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcDxCUj48L0ZPTlQ+PC9UVD48QlI+PEJSPiZuYnNw OzwvRElWPjxQUkU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3Rp Y2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNw O21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7 UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQm bmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNw O25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtj b250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNw O290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5i c3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRp YWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZu YnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50 aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4m bmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtl bWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUm bmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZu YnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZu YnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5l ZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDta VEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L1BSRT48L1NQQU4+PC9ESVY+PC9ESVY+ PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPlNp cCANCiAgbWFpbGluZyBsaXN0ICZuYnNwOzxBIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4 dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiANCiAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXAiIA0KICB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwPC9BPjxCUj5UaGlzIGxpc3QgaXMgDQogIGZvciBORVcg ZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sPEJSPlVzZSA8QSANCiAgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIA0KICBocmVm PSJtYWlsdG86c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUiPnNpcC1pbXBsZW1lbnRv cnNAY3MuY29sdW1iaWEuZWR1PC9BPiANCiAgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcDxC Uj5Vc2UgPEEgDQogIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2 ZW50LHRoaXMpIiANCiAgaHJlZj0ibWFpbHRvOnNpcHBpbmdAaWV0Zi5vcmciPnNpcHBpbmdAaWV0 Zi5vcmc8L0E+IGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIA0KICB0aGUgYXBwbGljYXRpb24gb2Yg c2lwPEJSPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C998CA.9E576D16-- From eric.wangxr@gmail.com Fri Feb 27 03:10:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421A03A6AFD for ; Fri, 27 Feb 2009 03:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.026 X-Spam-Level: **** X-Spam-Status: No, score=4.026 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxjUF4J3vATL for ; Fri, 27 Feb 2009 03:10:07 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 2E25C3A6AE9 for ; Fri, 27 Feb 2009 03:10:07 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so949831rvb.49 for ; Fri, 27 Feb 2009 03:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C8KV8z2EQ0291HlCv7mCMBp+Xx2pzr8G6hd1ke0la1o=; b=a6yh43n64M3u22eKC7/EBZm9iv38vumI3dz5PSrRj68Tw2148njoRdFIi3cuxuJYYM SWnd6zSGmDBqiwgVhV5SOLy3M9/u/pUdqK5jS7cRQVaM/l5xoDtlPAXFQE1ctmDm32ML HfxIEox+at2QnmwzwC+ypwNFwdzPQFgH/RwqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=C9fp1/G/olDyowZ2GZKzovV50JFazHnc3HdNSDaE/VmM+ZI5hHgSvjCR2b7Nb00Ou5 Q5eys2AI1ZDPeJFulD2Q7nnZyS7oz1cAJbHjritMjJm8IPtIqr1punlc8RPgeuDmhloI kKD9bJbZSpcKzJ3rF48KAeXKGAmei73Ohh7Rc= MIME-Version: 1.0 Received: by 10.141.145.11 with SMTP id x11mr1157849rvn.236.1235733029531; Fri, 27 Feb 2009 03:10:29 -0800 (PST) In-Reply-To: References: <49A7484B.3060407@cisco.com> <898632750902270249o3213670au6823cc4ab6180c8c@mail.gmail.com> Date: Fri, 27 Feb 2009 19:10:29 +0800 Message-ID: <898632750902270310k72308b9au7645d26cfc2d7de8@mail.gmail.com> From: Eric wang To: Christer Holmberg Content-Type: multipart/alternative; boundary=000e0cd2959c4332450463e4849b Cc: sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] =?gb2312?b?tPC4tDogUkU6IFF1ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0?= =?gb2312?b?Zi1zaXAtMTk5LTA1Ig==?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:10:09 -0000 --000e0cd2959c4332450463e4849b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, I don't think the 199 can be sent unreliably if UAC require 100rel. As in RFC3262, It says. The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel. Regards, Eric 2009/2/27, Christer Holmberg : > > Hi, > > >If the UAC requires 100rel ,then what should the proxy do if it receives > a no-2xx final response after forking? > > The proxy should send 199 unreliably. > > Regards, > > Christer > > > > > 2009/2/27, Christer Holmberg : >> >> Hi, >> >> >Practically, when Call forward and fork are used in the same system, >> there are >> >lots of early dialogs that should be eliminated by 199 existed. >> >So I think that it's useful to let 199 reliable. >> >And we just added fork-service to our system ,and find 199 is really >> useful, and >> >if the 199 is missing, problems will happen. >> >> I'm glad you think 199 is useful :) >> >> But, if a proxy would have to terminate PRACKs etc it would not be a pro= xy >> anymore - it would be a B2BUA. >> >> So, if you really want your network to send 199 reliably, I guess you >> could use a B2BUA instead of a proxy. >> >> >It sounds good that there is a way to prevent PRACK addressed to UAS,bu= t >> i don't know how to do now. >> >> The only way to prevent it is by the proxy not sending the 199 relaible. >> >> >> >ps: >> >RFC3261 *16.7 Response Processing* >> >Since a proxy may not insert a tag into the To header field of >> >a 1xx response to a request that did not contain one, it cannot >> >issue non-100 provisional responses on its own. >> >> Yes, but I we have agreed that a proxy is allowed to send 199. >> >> But, the proxy is not going to generate new To header tag values for the >> 199. It will use whatever tags that have already been created for the ea= rly >> dialogs. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> >> >> *allowing* (much less *requiring*) the 199 to be reliable introduces >> nasty problems. The 199 is only an optimization, so having it be >> unreliable is ok IMO. >> >> The problem is that if a proxy sends the 199, then the recipient of the >> PRACK should be the proxy. But the PRACK is an in-dialog message, so it >> must be addressed to the Contact of the UAS. >> >> If the proxy sends a reliable 199, and the PRACK is addressed to the >> UAS, the UAS will be very surprised, since it has not send a reliable >> provisional, and is so not expecting a PRACK. In fact, it has sent a >> final response, has presumably already received the ACK, and so is >> expecting nothing. >> >> Very ugly. >> >> Paul >> >> wang.libo@zte.com.cn wrote: >> > >> > Hi, >> > >> > And there still two questions left. >> > >> > 1. Is the 199 should be reliable or unreliable? >> > I think that 199 should be reliable if possible. >> > >> > >> > First, If a client receives an unreliable 199 response on a dialog >> > which has >> > not previously been created (this can happen if a 199 response >> > reaches the client before a 18x response) the client SHALL discard >> > the 199 responses. >> > >> > The figure below shows an example.The 180 is sent first but arrives >> > later than 199. >> > If the 199 is reliable, the proxy should retransmit 199 (step 4),and >> > then the retransmitted >> > 199 will be accepted by UAC,and the early dialog will be teminated. >> > >> > UAC P >> > 1. INVITE >> > ---------------> >> > 2. 180 >> > <----- \/------- >> > /\ 3. 199 >> > <-----/ \------ >> > 4. 199(retransmitted) >> > <--------------- >> > >> > second, According to practical use, 199 can be intended to teminate >> > one early dialog and release >> > resources associated with the specific early dialog, so the cost spent >> > on reliable 199 is worthy. >> > If the 199 cannot be sent reliable,then we should send it unreliable. >> > >> > 2. In your last letter, you said "the second 199 could include >> > information which is to be forwarded to the >> > UAC", then do you mean, the early dialog is still alive after the firs= t >> > 199 is accepted? >> > >> > >> > Also, In my last letter, I miss a "NOT" by mistake. >> > It should be >> > [Eric]: Surely the UAS is NOT allowed to send another reliable respons= e >> > until the first one is acknowledged... >> > >> > Regards, >> > Eric wang >> > >> > >> > >> > >> > *"Christer Holmberg" * >> > >> > 2009-02-27 03:04 >> > >> > >> > =CA=D5=BC=FE=C8=CB >> > "Eric wang" >> > =B3=AD=CB=CD >> > , >> > =D6=F7=CC=E2 >> > RE: Questions about "draft-ietf-sip-199-05" >> > >> > >> > >> > >> > >> > >> > >> > >> > Hi, >> > >> > >I still have some difficult in using IETF and cannot find the whole >> > sorted comments about this draft, so i have some doubt about this draf= t. >> > > >> > > 1. "If a forking proxy receives a reliably sent 199 response fo= r >> a >> > dialog, for which the proxy has previously generated and sent a 199 >> > response, the proxy MUST forward the 199 response." >> > > >> > > Does it describe the case below? Although P1 have sent a 199 >> > response, P1 havs to forword the send reliably 199 too.Or is the >> > first 199 mistaked for 18x? >> > > >> > > UAC P1 UAS_2 >> > > --- INVITE ------> >> > > --- INVITE (leg 2) -> >> > > <-- 199(leg 2) -- >> > > <-- 199 (leg 2) ----- >> > > <-- 199(leg 2) -- >> > >> > >I think it shall be 199, as currently written. >> > > >> > >[Eric]: If this is 199, then Is there a special purpose to send two >> > 199 in the same dialog? >> > >I think that one 199 is enough. >> > >And the first 199 may be reliable too, that will make it a little >> > difficult to send the second 199. >> > >> > The second 199 could include information which is to be forwarded to t= he >> > UAC. >> > >> > >> > >2. "10. Usage with 100rel >> > > >> > > When a 199 Early Dialog Terminated provisional response is sent b= y >> a >> > UAS, since the provisional response is only used for information >> > purpose, the UAS SHOULD send it unreliably even if the 100rel >> > > option tag [RFC3262] is present in the Require header of the >> > associated request." >> > > >> > > >> > >I have seen a comment on this question,but still not understood abou= t >> > >it. If the INVITE has a Require tag "Require: 100rel",does the UAS >> > still >> > >use unreliable 199 response? >> > > >> > >That is the recommendation, yes. The reasons is that we want to keep >> > 199 >> > >as "lightweight" as possible, without requireing re-transmissions an= d >> > >PRACKs. >> > > >> > >[Eric]: But reliable 199 have more advantage, and It is worth to use >> > the reliable 199,I think. >> > >> > I don't know what that advantage would be, compared to having to send >> > PRACKs etc. This has been discussed quite much, so I would really need >> > some good justification to change it now. >> > >> > Also, the draft doesn't forbid you to send the 199 reliably. It's only= a >> > SHOULD. >> > >> > >> > >If 199 is reliable, there is one more advantage. If the 199 arrives >> > >before the first 18x response, UAC can discard the first 199 and >> > process >> > >it until UAC receives the first 18x response that has the same >> > >to-tag as 199, as the reliable 199 should be re-transmited until >> > >received PRACK. >> > > >> > >If the INVITE contains "Require: 100rel", the first 18x must also be >> > >sent reliably. And, I don't think the UAS is allowed to send another >> > >reliable response until the first one is acknowledged, so I don't >> think >> > >a reliable 199 would reach the UAC before the first reliable 18x. >> > > >> > >[Eric]: Surely the UAS is allowed to send another reliable response >> > until the first one is acknowledged, >> > >> > If I remember correctly, the FIRST reliable response must be acknowled= ed >> > before the next reliable response is sent. But, we can double check in >> > the PRACK spec. >> > >> > >but reliable 199 will be useful if the first 18x is unreliable, or t= he >> > first 18x has been acknwledged. It's another case different from the >> > above one whose INVITE contains "require: 100rel". >> > >> > If 100rel is required the 18x cannot be unreliable. >> > >> > Regards, >> > >> > Christer >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > -------------------------------------------------------- >> > ZTE Information Security Notice: The information contained in this mai= l >> is solely property of the sender's organization. This mail communication= is >> confidential. Recipients named above are obligated to maintain secrecy a= nd >> are not permitted to disclose the contents of this communication to othe= rs. >> > 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. >> > >> > >> > ----------------------------------------------------------------------= -- >> > >> > _______________________________________________ >> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> >> >> >> >> -------------------------------------------------------- >> 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 intend= ed solely for the use of the individual or entity to whom they are addresse= d. 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 individu= al sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam syst= em. >> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > --000e0cd2959c4332450463e4849b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
hi,
 
 I don't think the 199 can be sent unreliably if UAC require = 100rel.
As in RFC3262, It says.
  
 The UAS MUST send any non-100 provisional response reliably if t= he
   initial request contained a Require header field with th= e option tag
   100rel.  If the UAS is unwilling to do so= , it MUST reject the initial
   request with a 420 (Bad Extension) and include an Unsupported = header
   field containing the option tag 100rel.

Regar= ds,
Eric
 
 
2009/2/27, Christer Holmberg <christer.holmberg@ericsson.com>:
Hi,
 
>If the UAC requires 100rel ,then what should the proxy do if it receive= s a no-2xx  &n= bsp;final response after forking? 
=  
The proxy = ;should send 199 unreliably.
=  
Regards,
=  
Christer 
 


 = ;
2009/2/27, Christer Holmberg <christer.holmberg@ericsson.com= >:=20
Hi,
  
>Practically, when Call forward and fork are= used in the same system, there are 
>lots of early dialogs that should= be eliminated by 199 existed. 
= >So I think that it's useful t= o let 199 reliable. 
>And we just added fork-service to= our system ,and find 199 is really useful, and 
>if the 199 is m= issing, problems will happen.  
 
I'm glad y= ou think 199 is useful :)
=  
But, if a prox= y would have to terminate PRACKs etc it would not be a proxy anymore - it w= ould be a B2BUA.
=  
So, if you rea= lly want your network to send 199 reliably, I guess you could use a B2BUA i= nstead of a proxy.

>It sounds good that there is a way to prevent PRACK add= ressed to UAS,but i don't know  how to do now. <= /font>
 = ;
Th= e only way to prevent it is by the proxy not sending the 199 relaible.=   
    
>ps: 
<= font color=3D"#0000ff">>RFC3261 16.7 Response Processing 
>Since a proxy may not insert a ta= g into the To header field of 
<= font size=3D"2">>a 1xx respo= nse to a request that did not contain one, it cannot 
>issu= e non-100 provisional responses on its own.  
 
Yes, but I&nbs= p;we have agreed that a proxy is allowed to send 199.
 
But, the proxy= is not going to generate new To header tag values for the 199. It will use= whatever tags that have already been created for the early dialo= gs. 
<= /font> 
Regards,
 
Christer

 
 
 
 
 
 
 


*allowing* (much less *requi= ring*) the 199 to be reliable introduces
nasty problems. The 199 is only= an optimization, so having it be
unreliable is ok IMO.

The probl= em is that if a proxy sends the 199, then the recipient of the
PRACK should be the proxy. But the PRACK is an in-dialog message, so it
= must be addressed to the Contact of the UAS.

If the proxy sends a re= liable 199, and the PRACK is addressed to the
UAS, the UAS will be very = surprised, since it has not send a reliable
provisional, and is so not expecting a PRACK. In fact, it has sent a
fin= al response, has presumably already received the ACK, and so is
expectin= g nothing.

Very ugly.

          &nbs= p;     Paul

wang.l= ibo@zte.com.cn wrote:
>
> Hi,
>
> And there still two questions left.
&= gt;
> 1.  Is the 199 should be reliable or unreliable?
> =     I think that 199 should be reliable if possible.
>
= >
>    First, If a client receives an unreliable 199 re= sponse on a dialog
> which has
>    not previously been created (this can h= appen if a 199 response
>    reaches the client before a 18= x response) the client SHALL discard
>    the 199 responses= .
>
>    The figure below shows an example.The 180 i= s sent first but arrives
> later than 199.
> If the 199 is reliable, the proxy should retra= nsmit 199 (step 4),and
> then the retransmitted
> 199 will be = accepted by UAC,and the early dialog will be teminated.
>
> UA= C             P
>    1. INVITE
> --------------->
>   &nbs= p;       2. 180
> <----- \/-------
>   &= nbsp;    /\ 3. 199
> <-----/  \------
>  = ;         4. 199(retransmitted)
> <-----------= ----
>
>    second, According to practical use, 199 can be i= ntended to teminate
> one early dialog and release
> resources= associated with the specific early dialog, so the cost spent
> on r= eliable 199 is worthy.
> If the 199 cannot be sent reliable,then we should send it unreliable.<= br>>  
> 2. In your last letter, you said "the second 19= 9 could include
> information which is to be forwarded to the
>= ; UAC", then do you mean, the early dialog is still alive after the fi= rst
> 199 is accepted?
>
>
> Also, In my last letter, I = miss a "NOT" by mistake.
> It should be
> [Eric]: Sur= ely the UAS is NOT allowed to send another reliable response
> until = the first one is acknowledged...
>
> Regards,
> Eric wang
>
>
>
>=
> *"Christer Holmberg" <christer.holmberg@ericsson.com>*
>
> 2009-02-27 03:04
>
>        =          
> =CA=D5=BC=FE=C8=CB
> &nbs= p;                "Eric wang&q= uot; <eric.wangxr@gmail.com>
> =B3=AD=CB=CD
>               =    <sip@ietf.org>, <= wang.libo@zte.com.cn>
> =D6=F7=CC=E2
>               =    RE: Questions about "draft-ietf-sip-199-05"
> =
>
>                 &= nbsp;
>
>
>
>
>
> Hi,
>
= >  >I still have some difficult in using IETF and cannot find th= e whole
> sorted comments about this draft, so i have some doubt about this draf= t.
>  >
>  >   1.   "If a forkin= g proxy receives a reliably sent 199 response for a
> dialog, for whi= ch the proxy has previously generated and sent a 199
> response, the proxy MUST forward the 199 response."
>  = ;>
>  >     Does it describe the case below? Alt= hough P1 have sent a 199
> response, P1 havs to  forword the sen= d reliably 199 too.Or  is the
> first 199 mistaked for 18x?
>  >
>  > &nbs= p;        UAC            =   P1                  UA= S_2
>  >            --- INVITE = ------>
>  >             &nb= sp;               --- INVITE (leg 2) -&g= t;
>  >            <-- 199(leg 2) = --
>  >               &nbs= p;             <-- 199 (leg 2) -----
&g= t;  >            <-- 199(leg 2) --=
>
>  >I think it shall be 199, as currently written.<= br> >  >
>  >[Eric]: If  this is 199, then Is the= re a special purpose to send two
> 199 in the same dialog?
> &n= bsp;>I think that one 199 is enough.
>  >And  the fir= st 199 may be reliable too, that will make it a little
> difficult to send the second 199.
>
> The second 199 coul= d include information which is to be forwarded to the
> UAC.
> =
>
>  >2.  "10.  Usage with 100rel
&= gt;  >
>  >   When a 199 Early Dialog Terminated provisional respo= nse is sent by a
> UAS, since the provisional response is only used f= or information
> purpose, the UAS SHOULD send it unreliably even if t= he 100rel
>  >   option tag [RFC3262] is present in the Require heade= r of the
> associated request."
>  >
>  = ;>
>  >I have seen a comment on this question,but still no= t understood about
>  >it. If the INVITE has a Require tag "Require: 100rel&qu= ot;,does the UAS
> still
>  >use unreliable 199 respons= e?
>  >
>  >That is the recommendation, yes. Th= e reasons is that we want to keep
> 199
>  >as "lightweight" as possible, without = requireing re-transmissions and
>  >PRACKs.
>  >= ;
>  >[Eric]: But reliable 199 have more advantage, and It is= worth to use
> the reliable 199,I think.
>
> I don't know what that = advantage would be, compared to having to send
> PRACKs etc. This has= been discussed quite much, so I would really need
> some good justif= ication to change it now.
>
> Also, the draft doesn't forbid you to send the 199 reliab= ly. It's only a
> SHOULD.
>
>
>  >If = 199 is reliable, there is one more advantage. If the 199 arrives
> &n= bsp;>before the first 18x response, UAC can discard the first 199 and > process
>  >it until UAC receives the first 18x response= that has the same
>  >to-tag as 199, as the reliable 199 sho= uld be re-transmited until
>  >received PRACK.
>  = >
>  >If the INVITE contains "Require: 100rel", = the first 18x must also be
>  >sent reliably. And, I don't think the UAS is allowed to = send another
>  >reliable response until the first one is ack= nowledged, so I don't think
>  >a reliable 199 would reac= h the UAC before the first reliable 18x.
>  >
>  >[Eric]: Surely the UAS is allowed to send= another reliable response
> until the first one is acknowledged,
= >
> If I remember correctly, the FIRST reliable response must be = acknowleded
> before the next reliable response is sent. But, we can double check in=
> the PRACK spec.
>
>  >but reliable 199 will b= e useful if the first 18x is unreliable, or the
> first 18x has been = acknwledged. It's another case different from the
> above one  whose INVITE contains "require: 100rel".
= >
> If 100rel is required the 18x cannot be unreliable.
> <= br>> Regards,
>
> Christer
>
>
>
&g= t;
>
>
>
>
>
>
> ----------------= ----------------------------------------
> ZTE Information Security N= otice: The information contained in this mail is solely property of the sen= der's organization. This mail communication is confidential. Recipients= named above are obligated to maintain secrecy and are not permitted to dis= close the contents of this communication to others.
> This email and any files transmitted with it are confidential and inte= nded solely for the use of the individual or entity to whom they are addres= sed. 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 indivi= dual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam sy= stem.
>
>
> -------------------------------------------= -----------------------------
>
> ____________________________= ___________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is f= or NEW development of the core SIP Protocol
> Use sip-implemen= tors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the= application of sip


 
--------------------------------------=
------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

______________________________________________= _
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu<= /a> for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip


--000e0cd2959c4332450463e4849b-- From christer.holmberg@ericsson.com Fri Feb 27 03:21:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A96828C200 for ; Fri, 27 Feb 2009 03:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.163 X-Spam-Level: X-Spam-Status: No, score=-5.163 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhkQtdev6anZ for ; Fri, 27 Feb 2009 03:21:21 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 362CD28C16C for ; Fri, 27 Feb 2009 03:21:20 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5EA542122B; Fri, 27 Feb 2009 12:21:41 +0100 (CET) X-AuditID: c1b4fb3e-b00a2bb0000023da-a2-49a7ccc59b56 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 087DF20B9E; Fri, 27 Feb 2009 12:21:41 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 12:21:40 +0100 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_01C998CD.8F390166" Date: Fri, 27 Feb 2009 12:21:39 +0100 Message-ID: In-Reply-To: <898632750902270310k72308b9au7645d26cfc2d7de8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?UTF-8?B?W1NpcF0g562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJk?= =?UTF-8?B?cmFmdC1pZXRmLXNpcC0xOTktMDUi?= Thread-Index: AcmYzATO+ofCSLGqSXec4qXlENVCAQAAFhgw References: <49A7484B.3060407@cisco.com> <898632750902270249o3213670au6823cc4ab6180c8c@mail.gmail.com> <898632750902270310k72308b9au7645d26cfc2d7de8@mail.gmail.com> From: "Christer Holmberg" To: "Eric wang" X-OriginalArrivalTime: 27 Feb 2009 11:21:40.0724 (UTC) FILETIME=[8FEE3340:01C998CD] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] =?utf-8?b?562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1p?= =?utf-8?q?etf-sip-199-05=22?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:21:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C998CD.8F390166 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQo+SSBkb24ndCB0aGluayB0aGUgMTk5IGNhbiBiZSBzZW50IHVucmVsaWFibHkgaWYgVUFD IHJlcXVpcmUgMTAwcmVsLg0KPkFzIGluIFJGQzMyNjIsIEl0IHNheXMuDQo+ICAgDQo+VGhlIFVB UyBNVVNUIHNlbmQgYW55IG5vbi0xMDAgcHJvdmlzaW9uYWwgcmVzcG9uc2UgcmVsaWFibHkgaWYg dGhlDQo+ICAgIGluaXRpYWwgcmVxdWVzdCBjb250YWluZWQgYSBSZXF1aXJlIGhlYWRlciBmaWVs ZCB3aXRoIHRoZSBvcHRpb24gdGFnDQo+ICAgIDEwMHJlbC4gIElmIHRoZSBVQVMgaXMgdW53aWxs aW5nIHRvIGRvIHNvLCBpdCBNVVNUIHJlamVjdCB0aGUgaW5pdGlhbA0KPiAgICByZXF1ZXN0IHdp dGggYSA0MjAgKEJhZCBFeHRlbnNpb24pIGFuZCBpbmNsdWRlIGFuIFVuc3VwcG9ydGVkIGhlYWRl cg0KPiAgICBmaWVsZCBjb250YWluaW5nIHRoZSBvcHRpb24gdGFnIDEwMHJlbC4gDQogDQpUaGlz IGhhcyBiZWVuIGRpc2N1c3NlZCwgYW5kIHRoZSBwcm9wb3NlZCBvdXRjb21lIHdhcyB0byBhbGxv dyAxOTkgdG8gYmUgc2VudCB1bnJlbGlhYmx5IGV2ZW4gaWYgMTAwcmVsIGlzIHJlcXVpcmVkLg0K IA0KUmVnYXJkcywNCiANCkNocmlzdGVyDQogDQogDQogDQogDQogDQoyMDA5LzIvMjcsIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OiANCg0KCQ0KCUhp LA0KCSANCgk+SWYgdGhlIFVBQyByZXF1aXJlcyAxMDByZWwgLHRoZW4gd2hhdCBzaG91bGQgdGhl IHByb3h5IGRvIGlmIGl0IHJlY2VpdmVzIGEgbm8tMnh4ICAgZmluYWwgcmVzcG9uc2UgYWZ0ZXIg Zm9ya2luZz8gDQoJIA0KCVRoZSBwcm94eSBzaG91bGQgc2VuZCAxOTkgdW5yZWxpYWJseS4NCgkg DQoJUmVnYXJkcywNCgkgDQoJDQoJQ2hyaXN0ZXIgDQoJDQoJIA0KCQ0KCQ0KCSANCgkyMDA5LzIv MjcsIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OiAN Cg0KCQkNCgkJSGksDQoJCSAgDQoJCT5QcmFjdGljYWxseSwgd2hlbiBDYWxsIGZvcndhcmQgYW5k IGZvcmsgYXJlIHVzZWQgaW4gdGhlIHNhbWUgc3lzdGVtLCB0aGVyZSBhcmUgDQoJCT5sb3RzIG9m IGVhcmx5IGRpYWxvZ3MgdGhhdCBzaG91bGQgYmUgZWxpbWluYXRlZCBieSAxOTkgZXhpc3RlZC4g DQoJCT5TbyBJIHRoaW5rIHRoYXQgaXQncyB1c2VmdWwgdG8gbGV0IDE5OSByZWxpYWJsZS4gDQoJ CT5BbmQgd2UganVzdCBhZGRlZCBmb3JrLXNlcnZpY2UgdG8gb3VyIHN5c3RlbSAsYW5kIGZpbmQg MTk5IGlzIHJlYWxseSB1c2VmdWwsIGFuZCANCgkJPmlmIHRoZSAxOTkgaXMgbWlzc2luZywgcHJv YmxlbXMgd2lsbCBoYXBwZW4uICANCgkJIA0KCQlJJ20gZ2xhZCB5b3UgdGhpbmsgMTk5IGlzIHVz ZWZ1bCA6KQ0KCQkgDQoJCUJ1dCwgaWYgYSBwcm94eSB3b3VsZCBoYXZlIHRvIHRlcm1pbmF0ZSBQ UkFDS3MgZXRjIGl0IHdvdWxkIG5vdCBiZSBhIHByb3h5IGFueW1vcmUgLSBpdCB3b3VsZCBiZSBh IEIyQlVBLg0KCQkgDQoJCVNvLCBpZiB5b3UgcmVhbGx5IHdhbnQgeW91ciBuZXR3b3JrIHRvIHNl bmQgMTk5IHJlbGlhYmx5LCBJIGd1ZXNzIHlvdSBjb3VsZCB1c2UgYSBCMkJVQSBpbnN0ZWFkIG9m IGEgcHJveHkuDQoJCQ0KDQoJCT5JdCBzb3VuZHMgZ29vZCB0aGF0IHRoZXJlIGlzIGEgd2F5IHRv IHByZXZlbnQgUFJBQ0sgYWRkcmVzc2VkIHRvIFVBUyxidXQgaSBkb24ndCBrbm93ICBob3cgdG8g ZG8gbm93LiANCgkJIA0KCQlUaGUgb25seSB3YXkgdG8gcHJldmVudCBpdCBpcyBieSB0aGUgcHJv eHkgbm90IHNlbmRpbmcgdGhlIDE5OSByZWxhaWJsZS4gIA0KCQkgICAgDQoJCT5wczogDQoJCT5S RkMzMjYxIDE2LjcgUmVzcG9uc2UgUHJvY2Vzc2luZyANCgkJPlNpbmNlIGEgcHJveHkgbWF5IG5v dCBpbnNlcnQgYSB0YWcgaW50byB0aGUgVG8gaGVhZGVyIGZpZWxkIG9mIA0KCQk+YSAxeHggcmVz cG9uc2UgdG8gYSByZXF1ZXN0IHRoYXQgZGlkIG5vdCBjb250YWluIG9uZSwgaXQgY2Fubm90IA0K CQk+aXNzdWUgbm9uLTEwMCBwcm92aXNpb25hbCByZXNwb25zZXMgb24gaXRzIG93bi4gIA0KCQkg DQoJCVllcywgYnV0IEkgd2UgaGF2ZSBhZ3JlZWQgdGhhdCBhIHByb3h5IGlzIGFsbG93ZWQgdG8g c2VuZCAxOTkuDQoJCSANCgkJQnV0LCB0aGUgcHJveHkgaXMgbm90IGdvaW5nIHRvIGdlbmVyYXRl IG5ldyBUbyBoZWFkZXIgdGFnIHZhbHVlcyBmb3IgdGhlIDE5OS4gSXQgd2lsbCB1c2Ugd2hhdGV2 ZXIgdGFncyB0aGF0IGhhdmUgYWxyZWFkeSBiZWVuIGNyZWF0ZWQgZm9yIHRoZSBlYXJseSBkaWFs b2dzLiANCgkJIA0KCQlSZWdhcmRzLA0KCQkgDQoJCQ0KCQlDaHJpc3Rlcg0KCQkNCgkJDQoJCSAN CgkJIA0KCQkgDQoJCSANCgkJIA0KCQkgDQoJCSANCgkJDQoJCQ0KCQkqYWxsb3dpbmcqIChtdWNo IGxlc3MgKnJlcXVpcmluZyopIHRoZSAxOTkgdG8gYmUgcmVsaWFibGUgaW50cm9kdWNlcw0KCQlu YXN0eSBwcm9ibGVtcy4gVGhlIDE5OSBpcyBvbmx5IGFuIG9wdGltaXphdGlvbiwgc28gaGF2aW5n IGl0IGJlDQoJCXVucmVsaWFibGUgaXMgb2sgSU1PLg0KCQkNCgkJVGhlIHByb2JsZW0gaXMgdGhh dCBpZiBhIHByb3h5IHNlbmRzIHRoZSAxOTksIHRoZW4gdGhlIHJlY2lwaWVudCBvZiB0aGUNCgkJ UFJBQ0sgc2hvdWxkIGJlIHRoZSBwcm94eS4gQnV0IHRoZSBQUkFDSyBpcyBhbiBpbi1kaWFsb2cg bWVzc2FnZSwgc28gaXQNCgkJbXVzdCBiZSBhZGRyZXNzZWQgdG8gdGhlIENvbnRhY3Qgb2YgdGhl IFVBUy4NCgkJDQoJCUlmIHRoZSBwcm94eSBzZW5kcyBhIHJlbGlhYmxlIDE5OSwgYW5kIHRoZSBQ UkFDSyBpcyBhZGRyZXNzZWQgdG8gdGhlDQoJCVVBUywgdGhlIFVBUyB3aWxsIGJlIHZlcnkgc3Vy cHJpc2VkLCBzaW5jZSBpdCBoYXMgbm90IHNlbmQgYSByZWxpYWJsZQ0KCQlwcm92aXNpb25hbCwg YW5kIGlzIHNvIG5vdCBleHBlY3RpbmcgYSBQUkFDSy4gSW4gZmFjdCwgaXQgaGFzIHNlbnQgYQ0K CQlmaW5hbCByZXNwb25zZSwgaGFzIHByZXN1bWFibHkgYWxyZWFkeSByZWNlaXZlZCB0aGUgQUNL LCBhbmQgc28gaXMNCgkJZXhwZWN0aW5nIG5vdGhpbmcuDQoJCQ0KCQlWZXJ5IHVnbHkuDQoJCQ0K CQkgICAgICAgICAgICAgICAgUGF1bA0KCQkNCgkJd2FuZy5saWJvQHp0ZS5jb20uY24gd3JvdGU6 DQoJCT4gDQoJCT4gSGksDQoJCT4gDQoJCT4gQW5kIHRoZXJlIHN0aWxsIHR3byBxdWVzdGlvbnMg bGVmdC4NCgkJPiANCgkJPiAxLiAgSXMgdGhlIDE5OSBzaG91bGQgYmUgcmVsaWFibGUgb3IgdW5y ZWxpYWJsZT8NCgkJPiAgICAgSSB0aGluayB0aGF0IDE5OSBzaG91bGQgYmUgcmVsaWFibGUgaWYg cG9zc2libGUuDQoJCT4gDQoJCT4gDQoJCT4gICAgRmlyc3QsIElmIGEgY2xpZW50IHJlY2VpdmVz IGFuIHVucmVsaWFibGUgMTk5IHJlc3BvbnNlIG9uIGEgZGlhbG9nIA0KCQk+IHdoaWNoIGhhcw0K CQk+ICAgIG5vdCBwcmV2aW91c2x5IGJlZW4gY3JlYXRlZCAodGhpcyBjYW4gaGFwcGVuIGlmIGEg MTk5IHJlc3BvbnNlDQoJCT4gICAgcmVhY2hlcyB0aGUgY2xpZW50IGJlZm9yZSBhIDE4eCByZXNw b25zZSkgdGhlIGNsaWVudCBTSEFMTCBkaXNjYXJkDQoJCT4gICAgdGhlIDE5OSByZXNwb25zZXMu DQoJCT4gDQoJCT4gICAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlLlRoZSAxODAg aXMgc2VudCBmaXJzdCBidXQgYXJyaXZlcyANCgkJPiBsYXRlciB0aGFuIDE5OS4NCgkJPiBJZiB0 aGUgMTk5IGlzIHJlbGlhYmxlLCB0aGUgcHJveHkgc2hvdWxkIHJldHJhbnNtaXQgMTk5IChzdGVw IDQpLGFuZCANCgkJPiB0aGVuIHRoZSByZXRyYW5zbWl0dGVkDQoJCT4gMTk5IHdpbGwgYmUgYWNj ZXB0ZWQgYnkgVUFDLGFuZCB0aGUgZWFybHkgZGlhbG9nIHdpbGwgYmUgdGVtaW5hdGVkLg0KCQk+ IA0KCQk+IFVBQyAgICAgICAgICAgICBQDQoJCT4gICAgMS4gSU5WSVRFDQoJCT4gLS0tLS0tLS0t LS0tLS0tPg0KCQk+ICAgICAgICAgICAyLiAxODANCgkJPiA8LS0tLS0gXC8tLS0tLS0tDQoJCT4g ICAgICAgIC9cIDMuIDE5OQ0KCQk+IDwtLS0tLS8gIFwtLS0tLS0NCgkJPiAgICAgICAgICAgNC4g MTk5KHJldHJhbnNtaXR0ZWQpDQoJCT4gPC0tLS0tLS0tLS0tLS0tLQ0KCQk+IA0KCQk+ICAgIHNl Y29uZCwgQWNjb3JkaW5nIHRvIHByYWN0aWNhbCB1c2UsIDE5OSBjYW4gYmUgaW50ZW5kZWQgdG8g dGVtaW5hdGUgDQoJCT4gb25lIGVhcmx5IGRpYWxvZyBhbmQgcmVsZWFzZQ0KCQk+IHJlc291cmNl cyBhc3NvY2lhdGVkIHdpdGggdGhlIHNwZWNpZmljIGVhcmx5IGRpYWxvZywgc28gdGhlIGNvc3Qg c3BlbnQgDQoJCT4gb24gcmVsaWFibGUgMTk5IGlzIHdvcnRoeS4NCgkJPiBJZiB0aGUgMTk5IGNh bm5vdCBiZSBzZW50IHJlbGlhYmxlLHRoZW4gd2Ugc2hvdWxkIHNlbmQgaXQgdW5yZWxpYWJsZS4N CgkJPiAgDQoJCT4gMi4gSW4geW91ciBsYXN0IGxldHRlciwgeW91IHNhaWQgInRoZSBzZWNvbmQg MTk5IGNvdWxkIGluY2x1ZGUgDQoJCT4gaW5mb3JtYXRpb24gd2hpY2ggaXMgdG8gYmUgZm9yd2Fy ZGVkIHRvIHRoZQ0KCQk+IFVBQyIsIHRoZW4gZG8geW91IG1lYW4sIHRoZSBlYXJseSBkaWFsb2cg aXMgc3RpbGwgYWxpdmUgYWZ0ZXIgdGhlIGZpcnN0IA0KCQk+IDE5OSBpcyBhY2NlcHRlZD8NCgkJ PiANCgkJPiANCgkJPiBBbHNvLCBJbiBteSBsYXN0IGxldHRlciwgSSBtaXNzIGEgIk5PVCIgYnkg bWlzdGFrZS4NCgkJPiBJdCBzaG91bGQgYmUNCgkJPiBbRXJpY106IFN1cmVseSB0aGUgVUFTIGlz IE5PVCBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlciByZWxpYWJsZSByZXNwb25zZQ0KCQk+IHVudGls IHRoZSBmaXJzdCBvbmUgaXMgYWNrbm93bGVkZ2VkLi4uDQoJCT4gDQoJCT4gUmVnYXJkcywNCgkJ PiBFcmljIHdhbmcNCgkJPiANCgkJPiANCgkJPiANCgkJPiANCgkJPiAqIkNocmlzdGVyIEhvbG1i ZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPioNCgkJPiANCgkJPiAyMDA5LTAy LTI3IDAzOjA0DQoJCT4gDQoJCT4gICAgICAgICAgICAgICAgICANCgkJPiDmlLbku7bkuroNCgkJ PiAgICAgICAgICAgICAgICAgICJFcmljIHdhbmciIDxlcmljLndhbmd4ckBnbWFpbC5jb20+DQoJ CT4g5oqE6YCBDQoJCT4gICAgICAgICAgICAgICAgICA8c2lwQGlldGYub3JnPiwgPHdhbmcubGli b0B6dGUuY29tLmNuPg0KCQk+IOS4u+mimA0KCQk+ICAgICAgICAgICAgICAgICAgUkU6IFF1ZXN0 aW9ucyBhYm91dCAiZHJhZnQtaWV0Zi1zaXAtMTk5LTA1Ig0KCQk+IA0KCQk+IA0KCQk+ICAgICAg ICAgICAgICAgICAgDQoJCT4gDQoJCT4gDQoJCT4gDQoJCT4gDQoJCT4gDQoJCT4gSGksDQoJCT4g DQoJCT4gID5JIHN0aWxsIGhhdmUgc29tZSBkaWZmaWN1bHQgaW4gdXNpbmcgSUVURiBhbmQgY2Fu bm90IGZpbmQgdGhlIHdob2xlDQoJCT4gc29ydGVkIGNvbW1lbnRzIGFib3V0IHRoaXMgZHJhZnQs IHNvIGkgaGF2ZSBzb21lIGRvdWJ0IGFib3V0IHRoaXMgZHJhZnQuDQoJCT4gID4NCgkJPiAgPiAg IDEuICAgIklmIGEgZm9ya2luZyBwcm94eSByZWNlaXZlcyBhIHJlbGlhYmx5IHNlbnQgMTk5IHJl c3BvbnNlIGZvciBhDQoJCT4gZGlhbG9nLCBmb3Igd2hpY2ggdGhlIHByb3h5IGhhcyBwcmV2aW91 c2x5IGdlbmVyYXRlZCBhbmQgc2VudCBhIDE5OQ0KCQk+IHJlc3BvbnNlLCB0aGUgcHJveHkgTVVT VCBmb3J3YXJkIHRoZSAxOTkgcmVzcG9uc2UuIg0KCQk+ICA+DQoJCT4gID4gICAgIERvZXMgaXQg ZGVzY3JpYmUgdGhlIGNhc2UgYmVsb3c/IEFsdGhvdWdoIFAxIGhhdmUgc2VudCBhIDE5OQ0KCQk+ IHJlc3BvbnNlLCBQMSBoYXZzIHRvICBmb3J3b3JkIHRoZSBzZW5kIHJlbGlhYmx5IDE5OSB0b28u T3IgIGlzIHRoZQ0KCQk+IGZpcnN0IDE5OSBtaXN0YWtlZCBmb3IgMTh4Pw0KCQk+ICA+DQoJCT4g ID4gICAgICAgICAgVUFDICAgICAgICAgICAgICAgUDEgICAgICAgICAgICAgICAgICBVQVNfMg0K CQk+ICA+ICAgICAgICAgICAgLS0tIElOVklURSAtLS0tLS0+DQoJCT4gID4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tLSBJTlZJVEUgKGxlZyAyKSAtPg0KCQk+ICA+ICAgICAgICAgICAg PC0tIDE5OShsZWcgMikgLS0NCgkJPiAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0t IDE5OSAobGVnIDIpIC0tLS0tDQoJCT4gID4gICAgICAgICAgICA8LS0gMTk5KGxlZyAyKSAtLQ0K CQk+IA0KCQk+ICA+SSB0aGluayBpdCBzaGFsbCBiZSAxOTksIGFzIGN1cnJlbnRseSB3cml0dGVu Lg0KCQk+ICA+DQoJCT4gID5bRXJpY106IElmICB0aGlzIGlzIDE5OSwgdGhlbiBJcyB0aGVyZSBh IHNwZWNpYWwgcHVycG9zZSB0byBzZW5kIHR3bw0KCQk+IDE5OSBpbiB0aGUgc2FtZSBkaWFsb2c/ DQoJCT4gID5JIHRoaW5rIHRoYXQgb25lIDE5OSBpcyBlbm91Z2guDQoJCT4gID5BbmQgIHRoZSBm aXJzdCAxOTkgbWF5IGJlIHJlbGlhYmxlIHRvbywgdGhhdCB3aWxsIG1ha2UgaXQgYSBsaXR0bGUN CgkJPiBkaWZmaWN1bHQgdG8gc2VuZCB0aGUgc2Vjb25kIDE5OS4NCgkJPiANCgkJPiBUaGUgc2Vj b25kIDE5OSBjb3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIHdoaWNoIGlzIHRvIGJlIGZvcndhcmRl ZCB0byB0aGUNCgkJPiBVQUMuDQoJCT4gDQoJCT4gDQoJCT4gID4yLiAgIjEwLiAgVXNhZ2Ugd2l0 aCAxMDByZWwNCgkJPiAgPg0KCQk+ICA+ICAgV2hlbiBhIDE5OSBFYXJseSBEaWFsb2cgVGVybWlu YXRlZCBwcm92aXNpb25hbCByZXNwb25zZSBpcyBzZW50IGJ5IGENCgkJPiBVQVMsIHNpbmNlIHRo ZSBwcm92aXNpb25hbCByZXNwb25zZSBpcyBvbmx5IHVzZWQgZm9yIGluZm9ybWF0aW9uDQoJCT4g cHVycG9zZSwgdGhlIFVBUyBTSE9VTEQgc2VuZCBpdCB1bnJlbGlhYmx5IGV2ZW4gaWYgdGhlIDEw MHJlbA0KCQk+ICA+ICAgb3B0aW9uIHRhZyBbUkZDMzI2Ml0gaXMgcHJlc2VudCBpbiB0aGUgUmVx dWlyZSBoZWFkZXIgb2YgdGhlDQoJCT4gYXNzb2NpYXRlZCByZXF1ZXN0LiINCgkJPiAgPg0KCQk+ ICA+DQoJCT4gID5JIGhhdmUgc2VlbiBhIGNvbW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQgc3Rp bGwgbm90IHVuZGVyc3Rvb2QgYWJvdXQNCgkJPiAgPml0LiBJZiB0aGUgSU5WSVRFIGhhcyBhIFJl cXVpcmUgdGFnICJSZXF1aXJlOiAxMDByZWwiLGRvZXMgdGhlIFVBUw0KCQk+IHN0aWxsDQoJCT4g ID51c2UgdW5yZWxpYWJsZSAxOTkgcmVzcG9uc2U/DQoJCT4gID4NCgkJPiAgPlRoYXQgaXMgdGhl IHJlY29tbWVuZGF0aW9uLCB5ZXMuIFRoZSByZWFzb25zIGlzIHRoYXQgd2Ugd2FudCB0byBrZWVw DQoJCT4gMTk5DQoJCT4gID5hcyAibGlnaHR3ZWlnaHQiIGFzIHBvc3NpYmxlLCB3aXRob3V0IHJl cXVpcmVpbmcgcmUtdHJhbnNtaXNzaW9ucyBhbmQNCgkJPiAgPlBSQUNLcy4NCgkJPiAgPg0KCQk+ ICA+W0VyaWNdOiBCdXQgcmVsaWFibGUgMTk5IGhhdmUgbW9yZSBhZHZhbnRhZ2UsIGFuZCBJdCBp cyB3b3J0aCB0byB1c2UNCgkJPiB0aGUgcmVsaWFibGUgMTk5LEkgdGhpbmsuDQoJCT4gDQoJCT4g SSBkb24ndCBrbm93IHdoYXQgdGhhdCBhZHZhbnRhZ2Ugd291bGQgYmUsIGNvbXBhcmVkIHRvIGhh dmluZyB0byBzZW5kDQoJCT4gUFJBQ0tzIGV0Yy4gVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgcXVp dGUgbXVjaCwgc28gSSB3b3VsZCByZWFsbHkgbmVlZA0KCQk+IHNvbWUgZ29vZCBqdXN0aWZpY2F0 aW9uIHRvIGNoYW5nZSBpdCBub3cuDQoJCT4gDQoJCT4gQWxzbywgdGhlIGRyYWZ0IGRvZXNuJ3Qg Zm9yYmlkIHlvdSB0byBzZW5kIHRoZSAxOTkgcmVsaWFibHkuIEl0J3Mgb25seSBhDQoJCT4gU0hP VUxELg0KCQk+IA0KCQk+IA0KCQk+ICA+SWYgMTk5IGlzIHJlbGlhYmxlLCB0aGVyZSBpcyBvbmUg bW9yZSBhZHZhbnRhZ2UuIElmIHRoZSAxOTkgYXJyaXZlcw0KCQk+ICA+YmVmb3JlIHRoZSBmaXJz dCAxOHggcmVzcG9uc2UsIFVBQyBjYW4gZGlzY2FyZCB0aGUgZmlyc3QgMTk5IGFuZA0KCQk+IHBy b2Nlc3MNCgkJPiAgPml0IHVudGlsIFVBQyByZWNlaXZlcyB0aGUgZmlyc3QgMTh4IHJlc3BvbnNl IHRoYXQgaGFzIHRoZSBzYW1lDQoJCT4gID50by10YWcgYXMgMTk5LCBhcyB0aGUgcmVsaWFibGUg MTk5IHNob3VsZCBiZSByZS10cmFuc21pdGVkIHVudGlsDQoJCT4gID5yZWNlaXZlZCBQUkFDSy4N CgkJPiAgPg0KCQk+ICA+SWYgdGhlIElOVklURSBjb250YWlucyAiUmVxdWlyZTogMTAwcmVsIiwg dGhlIGZpcnN0IDE4eCBtdXN0IGFsc28gYmUNCgkJPiAgPnNlbnQgcmVsaWFibHkuIEFuZCwgSSBk b24ndCB0aGluayB0aGUgVUFTIGlzIGFsbG93ZWQgdG8gc2VuZCBhbm90aGVyDQoJCT4gID5yZWxp YWJsZSByZXNwb25zZSB1bnRpbCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZCwgc28gSSBk b24ndCB0aGluaw0KCQk+ICA+YSByZWxpYWJsZSAxOTkgd291bGQgcmVhY2ggdGhlIFVBQyBiZWZv cmUgdGhlIGZpcnN0IHJlbGlhYmxlIDE4eC4NCgkJPiAgPg0KCQk+ICA+W0VyaWNdOiBTdXJlbHkg dGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlciByZWxpYWJsZSByZXNwb25zZQ0KCQk+ IHVudGlsIHRoZSBmaXJzdCBvbmUgaXMgYWNrbm93bGVkZ2VkLA0KCQk+IA0KCQk+IElmIEkgcmVt ZW1iZXIgY29ycmVjdGx5LCB0aGUgRklSU1QgcmVsaWFibGUgcmVzcG9uc2UgbXVzdCBiZSBhY2tu b3dsZWRlZA0KCQk+IGJlZm9yZSB0aGUgbmV4dCByZWxpYWJsZSByZXNwb25zZSBpcyBzZW50LiBC dXQsIHdlIGNhbiBkb3VibGUgY2hlY2sgaW4NCgkJPiB0aGUgUFJBQ0sgc3BlYy4NCgkJPiANCgkJ PiAgPmJ1dCByZWxpYWJsZSAxOTkgd2lsbCBiZSB1c2VmdWwgaWYgdGhlIGZpcnN0IDE4eCBpcyB1 bnJlbGlhYmxlLCBvciB0aGUNCgkJPiBmaXJzdCAxOHggaGFzIGJlZW4gYWNrbndsZWRnZWQuIEl0 J3MgYW5vdGhlciBjYXNlIGRpZmZlcmVudCBmcm9tIHRoZQ0KCQk+IGFib3ZlIG9uZSAgd2hvc2Ug SU5WSVRFIGNvbnRhaW5zICJyZXF1aXJlOiAxMDByZWwiLg0KCQk+IA0KCQk+IElmIDEwMHJlbCBp cyByZXF1aXJlZCB0aGUgMTh4IGNhbm5vdCBiZSB1bnJlbGlhYmxlLg0KCQk+IA0KCQk+IFJlZ2Fy ZHMsDQoJCT4gDQoJCT4gQ2hyaXN0ZXINCgkJPiANCgkJPiANCgkJPiANCgkJPiANCgkJPiANCgkJ PiANCgkJPiANCgkJPiANCgkJPiANCgkJPiANCgkJPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCQk+IFpURSBJbmZvcm1hdGlvbiBTZWN1 cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNv bGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29t bXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9i bGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNj bG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCgkJPiBU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoJCT4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQoJCT4gDQoJCT4g DQoJCT4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJCT4gDQoJCT4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCgkJPiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCQk+IFRoaXMgbGlzdCBpcyBmb3IgTkVX IGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KCQk+IFVzZSBzaXAtaW1wbGVt ZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQoJCT4g VXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0 aW9uIG9mIHNpcA0KCQkNCgkJDQoJCSANCgkJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgkJWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0 aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVk IHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KCQlUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFu eSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZp ZHVhbCBzZW5kZXIuDQoJCVRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2Vz IGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KCQkNCg0KCQlfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCQlTaXAgbWFpbGluZyBsaXN0ICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCQlUaGlzIGxpc3QgaXMg Zm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCgkJVXNlIHNpcC1p bXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXAN CgkJVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxp Y2F0aW9uIG9mIHNpcA0KCQkNCg0KDQoNCg== ------_=_NextPart_001_01C998CD.8F390166 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjM3OTAuNDQyNiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wOTMwNjEzMTEtMjcwMjIwMDk+PEZPTlQgZmFjZT1B cmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW PiA8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MDkzMDYxMzExLTI3MDIyMDA5PjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj4mZ3Q7PC9GT05UPjwvU1BBTj5JIGRvbid0IHRo aW5rIHRoZSAxOTkgY2FuIGJlIHNlbnQgdW5yZWxpYWJseSBpZiBVQUMgDQpyZXF1aXJlIDEwMHJl bC48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MDkzMDYxMzExLTI3MDIyMDA5PjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj4mZ3Q7PC9GT05UPjwvU1BBTj5BcyZuYnNwO2lu IFJGQzMyNjIsIEl0IHNheXMuPC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTA5MzA2MTMxMS0yNzAy MjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+Jmd0OyZuYnNwOzwv Rk9OVD48L1NQQU4+Jm5ic3A7Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTA5MzA2MTMx MS0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+Jmd0Ozwv Rk9OVD48L1NQQU4+VGhlIFVBUyBNVVNUIHNlbmQgYW55IG5vbi0xMDAgcHJvdmlzaW9uYWwgcmVz cG9uc2UgDQpyZWxpYWJseSBpZiB0aGU8QlI+PFNQQU4gY2xhc3M9MDkzMDYxMzExLTI3MDIyMDA5 PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48Rk9OVCBmYWNlPSIiIGNv bG9yPSMwMDAwMDAgDQpzaXplPTM+Jmd0OzwvRk9OVD4mbmJzcDs8L0ZPTlQ+PC9TUEFOPiZuYnNw OyZuYnNwOyBpbml0aWFsIHJlcXVlc3QgY29udGFpbmVkIGEgDQpSZXF1aXJlIGhlYWRlciBmaWVs ZCB3aXRoIHRoZSBvcHRpb24gdGFnPEJSPjxTUEFOIGNsYXNzPTA5MzA2MTMxMS0yNzAyMjAwOT48 Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PEZPTlQgZmFjZT0iIiBjb2xv cj0jMDAwMDAwIA0Kc2l6ZT0zPiZndDs8L0ZPTlQ+Jm5ic3A7PC9GT05UPjwvU1BBTj4mbmJzcDsm bmJzcDsgMTAwcmVsLiZuYnNwOyBJZiB0aGUgVUFTIGlzIA0KdW53aWxsaW5nIHRvIGRvIHNvLCBp dCBNVVNUIHJlamVjdCB0aGUgaW5pdGlhbDxCUj48U1BBTiANCmNsYXNzPTA5MzA2MTMxMS0yNzAy MjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxGT05UIGZhY2U9IiIg DQpjb2xvcj0jMDAwMDAwIHNpemU9Mz4mZ3Q7PC9GT05UPiZuYnNwOzwvRk9OVD48L1NQQU4+Jm5i c3A7Jm5ic3A7IHJlcXVlc3Qgd2l0aCBhIA0KNDIwIChCYWQgRXh0ZW5zaW9uKSBhbmQgaW5jbHVk ZSBhbiBVbnN1cHBvcnRlZCBoZWFkZXI8QlI+PFNQQU4gDQpjbGFzcz0wOTMwNjEzMTEtMjcwMjIw MDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48Rk9OVCBmYWNlPSIiIA0K Y29sb3I9IzAwMDAwMCBzaXplPTM+Jmd0OzwvRk9OVD4mbmJzcDs8L0ZPTlQ+PC9TUEFOPiZuYnNw OyZuYnNwOyBmaWVsZCANCmNvbnRhaW5pbmcgdGhlIG9wdGlvbiB0YWcgMTAwcmVsLjxTUEFOIGNs YXNzPTA5MzA2MTMxMS0yNzAyMjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBz aXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MDkzMDYx MzExLTI3MDIyMDA5PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZP TlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0wOTMwNjEzMTEtMjcwMjIw MDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPlRoaXMmbmJzcDtoYXMg YmVlbiZuYnNwO2Rpc2N1c3NlZCwgYW5kIHRoZSBwcm9wb3NlZCBvdXRjb21lIHdhcyB0byBhbGxv dyANCjE5OSB0byBiZSBzZW50IHVucmVsaWFibHkgZXZlbiBpZiAxMDByZWwgaXMgcmVxdWlyZWQu PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MDkzMDYxMzExLTI3MDIyMDA5 PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0wOTMwNjEzMTEtMjcwMjIwMDk+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPjwvU1BBTj48L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9MDkzMDYxMzExLTI3MDIyMDA5PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48 U1BBTiBjbGFzcz0wOTMwNjEzMTEtMjcwMjIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIA0Kc2l6ZT0yPkNocmlzdGVyPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xh c3M9MDkzMDYxMzExLTI3MDIyMDA5PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNp emU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9Z21haWxfcXVvdGU+MjAwOS8yLzI3LCBD aHJpc3RlciBIb2xtYmVyZyAmbHQ7PEEgDQpocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L0E+Jmd0Ozo8L1NQ QU4+IA0KDQo8QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCnN0eWxlPSJQQURESU5HLUxF RlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4 IHNvbGlkIj4NCiAgPERJVj48U1BBTiBjbGFzcz1xPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj5IaSw8L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+Jmd0OzwvRk9OVD48L1NQQU4+SWYgdGhlIFVBQyANCiAgcmVx dWlyZXMgMTAwcmVsICx0aGVuIHdoYXQgc2hvdWxkIHRoZSBwcm94eSBkbyBpZiBpdCByZWNlaXZl cyBhIA0KICBuby0yeHg8U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PiZuYnNwOyANCiAgJm5ic3A7PC9GT05UPjwvU1BBTj5maW5hbCByZXNwb25zZSBhZnRlciBmb3Jr aW5nPzxTUEFOPjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNw OzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj48L1NQQU4+DQog IDxESVY+PFNQQU4+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGUgcHJv eHkmbmJzcDtzaG91bGQgc2VuZCANCiAgMTk5IHVucmVsaWFibHkuPC9GT05UPjwvU1BBTj48L0RJ Vj4NCiAgPERJVj48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj5SZWdhcmRzLDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+ PFNQQU4+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj48U1BBTiBjbGFzcz1zZz4NCiAgPERJVj48U1BBTj48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj5DaHJpc3RlcjwvRk9OVD4mbmJzcDs8L1NQ QU4+PC9ESVY+PC9TUEFOPg0KICA8RElWPjxTUEFOIGNsYXNzPWUgaWQ9cV8xMWZiNzY0OWUyYjcz OGQzXzQ+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj48L0ZPTlQ+PEJSPjxCUj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz1nbWFp bF9xdW90ZT4yMDA5LzIvMjcsIENocmlzdGVyIEhvbG1iZXJnICZsdDs8QSANCiAgb25jbGljaz0i cmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIA0KICBocmVmPSJt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiANCiAgdGFyZ2V0PV9ibGFuaz5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L0E+Jmd0Ozo8L1NQQU4+IA0KICA8QkxPQ0tR VU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCiAgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJH SU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPg0KICAg IDxESVY+PFNQQU4+DQogICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgIHNpemU9Mj5IaSw8L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICAgIDxESVY+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj4mbmJzcDsmbmJzcDs8L0ZP TlQ+PEJSPjxGT05UIA0KICAgIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOPjxGT05UIGNv bG9yPSMwMDAwZmY+PEZPTlQgDQogICAgY29sb3I9IzAwMDAwMD4mZ3Q7PC9GT05UPjwvRk9OVD48 L1NQQU4+UHJhY3RpY2FsbHksIHdoZW4gQ2FsbCBmb3J3YXJkIGFuZCANCiAgICBmb3JrIGFyZSB1 c2VkIGluIHRoZSBzYW1lIHN5c3RlbSwgdGhlcmUgYXJlJm5ic3A7PC9GT05UPjwvRk9OVD48QlI+ PEZPTlQgDQogICAgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4+PEZPTlQgY29sb3I9IzAw MDBmZj48Rk9OVCANCiAgICBjb2xvcj0jMDAwMDAwPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj5s b3RzIG9mIGVhcmx5IGRpYWxvZ3MgdGhhdCBzaG91bGQgYmUgDQogICAgZWxpbWluYXRlZCBieSAx OTkgZXhpc3RlZC48L0ZPTlQ+PC9GT05UPiZuYnNwOzxCUj48Rk9OVCBmYWNlPUFyaWFsPjxGT05U IA0KICAgIHNpemU9Mj48U1BBTj48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIGZhY2U9IiIgY29s b3I9IzAwMDAwMCANCiAgICBzaXplPTM+Jmd0OzwvRk9OVD48L0ZPTlQ+PC9TUEFOPlNvIEkgdGhp bmsgdGhhdCBpdCdzIHVzZWZ1bCB0byBsZXQgMTk5IA0KICAgIHJlbGlhYmxlLiZuYnNwOzwvRk9O VD48L0ZPTlQ+PEJSPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOPjxGT05UIA0K ICAgIGNvbG9yPSMwMDAwZmY+PEZPTlQgY29sb3I9IzAwMDAwMD4mZ3Q7PC9GT05UPjwvRk9OVD48 L1NQQU4+QW5kIHdlIGp1c3QgYWRkZWQgDQogICAgZm9yay1zZXJ2aWNlIHRvIG91ciBzeXN0ZW0g LGFuZCBmaW5kIDE5OSBpcyByZWFsbHkgdXNlZnVsLCANCiAgICBhbmQ8L0ZPTlQ+PC9GT05UPiZu YnNwOzxCUj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTj48Rk9OVCANCiAgICBj b2xvcj0jMDAwMGZmPjxGT05UIGZhY2U9IiIgY29sb3I9IzAwMDAwMCBzaXplPTM+Jmd0OzwvRk9O VD48L0ZPTlQ+PC9TUEFOPmlmIA0KICAgIHRoZSAxOTkgaXMgbWlzc2luZywgcHJvYmxlbXMgd2ls bCBoYXBwZW4uPC9GT05UPjwvRk9OVD4mbmJzcDs8U1BBTj48Rk9OVCANCiAgICBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJ Vj48U1BBTj48L1NQQU4+Jm5ic3A7PC9ESVY+PC9TUEFOPg0KICAgIDxESVY+PFNQQU4+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5JJ20gZ2xhZCB5b3UgdGhpbmsgMTk5IGlz IA0KICAgIHVzZWZ1bCA6KTwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTj48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9E SVY+DQogICAgPERJVj48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PkJ1dCwgaWYgYSBwcm94eSB3b3VsZCBoYXZlIA0KICAgIHRvIHRlcm1pbmF0ZSBQUkFDS3MgZXRj IGl0IHdvdWxkIG5vdCBiZSBhIHByb3h5IGFueW1vcmUgLSBpdCB3b3VsZCBiZSBhIA0KICAgIEIy QlVBLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTj48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJ Vj48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPlNvLCBpZiB5b3Ug cmVhbGx5IHdhbnQgeW91ciANCiAgICBuZXR3b3JrIHRvIHNlbmQgMTk5IHJlbGlhYmx5LCBJIGd1 ZXNzIHlvdSBjb3VsZCB1c2UgYSBCMkJVQSBpbnN0ZWFkIG9mIGEgDQogICAgcHJveHkuPC9GT05U PjwvU1BBTj48L0RJVj48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXpl PTI+PC9GT05UPg0KICAgIDxESVY+PEJSPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxT UEFOPjxGT05UIA0KICAgIGNvbG9yPSMwMDAwZmY+Jmd0OzwvRk9OVD48L1NQQU4+SXQgc291bmRz IGdvb2QgdGhhdCB0aGVyZSBpcyBhIHdheSB0byANCiAgICBwcmV2ZW50IFBSQUNLIGFkZHJlc3Nl ZCB0byBVQVMsYnV0IGkgZG9uJ3Qga25vdzxTUEFOPjxGT05UIA0KICAgIGNvbG9yPSMwMDAwZmY+ Jm5ic3A7IDwvRk9OVD48L1NQQU4+aG93IHRvIGRvIG5vdy48U1BBTj48Rk9OVCANCiAgICBjb2xv cj0jMDAwMGZmPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgICA8 RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQogICAgc2l6ZT0yPjxTUEFOPjwvU1BBTj48L0ZP TlQ+PC9GT05UPiZuYnNwOzwvRElWPjwvU1BBTj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWw+ PEZPTlQgc2l6ZT0yPjxTUEFOPjxGT05UIGNvbG9yPSMwMDAwZmY+VGhlIG9ubHkgd2F5IHRvIA0K ICAgIHByZXZlbnQgaXQgaXMgYnkgdGhlIHByb3h5IG5vdCBzZW5kaW5nIHRoZSANCiAgICAxOTkm bmJzcDtyZWxhaWJsZS48L0ZPTlQ+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PFNQ QU4+PEJSPjxGT05UIA0KICAgIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7PC9GT05UPiZuYnNwOzxCUj48Rk9OVCANCiAgICBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48 U1BBTj48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIA0KICAgIGZhY2U9IlRpbWVzIE5ldyBSb21h biIgY29sb3I9IzAwMDAwMCANCiAgICBzaXplPTM+Jmd0OzwvRk9OVD48L0ZPTlQ+PC9TUEFOPnBz OjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PEJSPjxGT05UIA0KICAgIHNpemU9Mj48Rk9OVCBmYWNlPUFy aWFsPjxTUEFOPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQogICAgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBjb2xvcj0jMDAwMDAwIHNpemU9Mz4mZ3Q7PC9GT05UPjwvRk9OVD48L1NQQU4+UkZD MzI2MSANCiAgICA8L0ZPTlQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIGNvbG9yPSMwMDIwNDE+ PEI+MTYuNyBSZXNwb25zZSANCiAgICBQcm9jZXNzaW5nPC9CPjwvRk9OVD48Rk9OVCBmYWNlPXNh bnMtc2VyaWY+Jm5ic3A7PC9GT05UPjwvRk9OVD48QlI+PEZPTlQgDQogICAgZmFjZT1BcmlhbD48 Rk9OVCBzaXplPTI+PFNQQU4+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCANCiAgICBjb2xvcj0j MDAwMDAwPiZndDs8L0ZPTlQ+PC9GT05UPjwvU1BBTj5TaW5jZSBhIHByb3h5IG1heSBub3QgaW5z ZXJ0IGEgdGFnIA0KICAgIGludG8gdGhlIFRvIGhlYWRlciBmaWVsZCBvZjwvRk9OVD48L0ZPTlQ+ Jm5ic3A7PEJSPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQogICAgc2l6ZT0yPjxTUEFOPjxGT05U IGNvbG9yPSMwMDAwZmY+Jmd0OzwvRk9OVD48L1NQQU4+YSAxeHggcmVzcG9uc2UgdG8gYSANCiAg ICByZXF1ZXN0IHRoYXQgZGlkIG5vdCBjb250YWluIG9uZSwgPEZPTlQgY29sb3I9Ymx1ZT5pdCAN CiAgICBjYW5ub3Q8L0ZPTlQ+PC9GT05UPjwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgZmFjZT1Bcmlh bD48Rk9OVCANCiAgICBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj48U1BBTj48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDAgDQogICAgc2l6ZT0zPiZndDs8L0ZPTlQ+ PC9TUEFOPmlzc3VlIG5vbi0xMDAgcHJvdmlzaW9uYWwgcmVzcG9uc2VzIG9uIGl0cyANCiAgICBv d24uPC9GT05UPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PFNQQU4+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIA0KICAgIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0RJVj4N CiAgICA8RElWPjxTUEFOPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+WWVzLCBidXQgSSZuYnNwO3dlIGhhdmUg DQogICAgYWdyZWVkIHRoYXQgYSBwcm94eSBpcyBhbGxvd2VkIHRvIHNlbmQgMTk5LjwvRk9OVD48 L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTj48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJ Vj48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkJ1dCwgdGhlIHBy b3h5IGlzIG5vdCBnb2luZyANCiAgICB0byBnZW5lcmF0ZSBuZXcgVG8gaGVhZGVyIHRhZyB2YWx1 ZXMgZm9yIHRoZSAxOTkuIEl0IHdpbGwgdXNlIHdoYXRldmVyIHRhZ3MgDQogICAgdGhhdCBoYXZl IGFscmVhZHkmbmJzcDtiZWVuIGNyZWF0ZWQgZm9yIHRoZSZuYnNwO2Vhcmx5IA0KICAgIGRpYWxv Z3MuPC9GT05UPiZuYnNwOzwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFOPjwvU1BBTj48U1BB Tj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgc2l6ZT0yPjwvRk9OVD48L1NQ QU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgDQpzaXplPTI+UmVnYXJkcyw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQ QU4+PC9TUEFOPiZuYnNwOzwvRElWPjxTUEFOPg0KICAgIDxESVY+PFNQQU4+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgIHNpemU9Mj5DaHJpc3RlcjwvRk9OVD48L1NQQU4+PC9E SVY+PC9TUEFOPg0KICAgIDxESVY+PFNQQU4+DQogICAgPERJVj48U1BBTj48L1NQQU4+PEJSPjxT UEFOPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICBzaXplPTI+Jm5ic3A7PC9G T05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFOPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAg ICA8RElWPjxTUEFOPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOPjwvU1BBTj4m bmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElW PjxTUEFOPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOPjwvU1BBTj4mbmJzcDs8 L0RJVj4NCiAgICA8RElWPjxTUEFOPjwvU1BBTj48QlI+PEJSPjxUVD48Rk9OVCBzaXplPTI+KmFs bG93aW5nKiAobXVjaCBsZXNzIA0KICAgICpyZXF1aXJpbmcqKSB0aGUgMTk5IHRvIGJlIHJlbGlh YmxlIGludHJvZHVjZXM8QlI+bmFzdHkgcHJvYmxlbXMuIFRoZSAxOTkgaXMgDQogICAgb25seSBh biBvcHRpbWl6YXRpb24sIHNvIGhhdmluZyBpdCBiZTxCUj51bnJlbGlhYmxlIGlzIG9rIElNTy48 QlI+PEJSPlRoZSANCiAgICBwcm9ibGVtIGlzIHRoYXQgaWYgYSBwcm94eSBzZW5kcyB0aGUgMTk5 LCB0aGVuIHRoZSByZWNpcGllbnQgb2YgdGhlPEJSPlBSQUNLIA0KICAgIHNob3VsZCBiZSB0aGUg cHJveHkuIEJ1dCB0aGUgUFJBQ0sgaXMgYW4gaW4tZGlhbG9nIG1lc3NhZ2UsIHNvIGl0PEJSPm11 c3QgYmUgDQogICAgYWRkcmVzc2VkIHRvIHRoZSBDb250YWN0IG9mIHRoZSBVQVMuPEJSPjxCUj5J ZiB0aGUgcHJveHkgc2VuZHMgYSByZWxpYWJsZSANCiAgICAxOTksIGFuZCB0aGUgUFJBQ0sgaXMg YWRkcmVzc2VkIHRvIHRoZTxCUj5VQVMsIHRoZSBVQVMgd2lsbCBiZSB2ZXJ5IA0KICAgIHN1cnBy aXNlZCwgc2luY2UgaXQgaGFzIG5vdCBzZW5kIGEgcmVsaWFibGU8QlI+cHJvdmlzaW9uYWwsIGFu ZCBpcyBzbyBub3QgDQogICAgZXhwZWN0aW5nIGEgUFJBQ0suIEluIGZhY3QsIGl0IGhhcyBzZW50 IGE8QlI+ZmluYWwgcmVzcG9uc2UsIGhhcyBwcmVzdW1hYmx5IA0KICAgIGFscmVhZHkgcmVjZWl2 ZWQgdGhlIEFDSywgYW5kIHNvIGlzPEJSPmV4cGVjdGluZyBub3RoaW5nLjxCUj48QlI+VmVyeSAN CiAgICB1Z2x5LjxCUj48QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyANCiAgICBQYXVsPEJSPjxCUj48QSBvbmNsaWNrPSJyZXR1cm4gdG9w LmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgDQogICAgaHJlZj0ibWFpbHRvOndh bmcubGlib0B6dGUuY29tLmNuIiB0YXJnZXQ9X2JsYW5rPndhbmcubGlib0B6dGUuY29tLmNuPC9B PiANCiAgICB3cm90ZTo8QlI+Jmd0OyA8QlI+Jmd0OyBIaSw8QlI+Jmd0OyA8QlI+Jmd0OyBBbmQg dGhlcmUgc3RpbGwgdHdvIHF1ZXN0aW9ucyANCiAgICBsZWZ0LjxCUj4mZ3Q7IDxCUj4mZ3Q7IDEu ICZuYnNwO0lzIHRoZSAxOTkgc2hvdWxkIGJlIHJlbGlhYmxlIG9yIA0KICAgIHVucmVsaWFibGU/ PEJSPiZndDsgJm5ic3A7ICZuYnNwOyBJIHRoaW5rIHRoYXQgMTk5IHNob3VsZCBiZSByZWxpYWJs ZSBpZiANCiAgICBwb3NzaWJsZS48QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyAmbmJzcDsgJm5i c3A7Rmlyc3QsIElmIGEgY2xpZW50IHJlY2VpdmVzIA0KICAgIGFuIHVucmVsaWFibGUgMTk5IHJl c3BvbnNlIG9uIGEgZGlhbG9nIDxCUj4mZ3Q7IHdoaWNoIGhhczxCUj4mZ3Q7ICZuYnNwOyANCiAg ICAmbmJzcDtub3QgcHJldmlvdXNseSBiZWVuIGNyZWF0ZWQgKHRoaXMgY2FuIGhhcHBlbiBpZiBh IDE5OSByZXNwb25zZTxCUj4mZ3Q7IA0KICAgICZuYnNwOyAmbmJzcDtyZWFjaGVzIHRoZSBjbGll bnQgYmVmb3JlIGEgMTh4IHJlc3BvbnNlKSB0aGUgY2xpZW50IFNIQUxMIA0KICAgIGRpc2NhcmQ8 QlI+Jmd0OyAmbmJzcDsgJm5ic3A7dGhlIDE5OSByZXNwb25zZXMuPEJSPiZndDsgPEJSPiZndDsg Jm5ic3A7IA0KICAgICZuYnNwO1RoZSBmaWd1cmUgYmVsb3cgc2hvd3MgYW4gZXhhbXBsZS5UaGUg MTgwIGlzIHNlbnQgZmlyc3QgYnV0IGFycml2ZXMgDQogICAgPEJSPiZndDsgbGF0ZXIgdGhhbiAx OTkuPEJSPiZndDsgSWYgdGhlIDE5OSBpcyByZWxpYWJsZSwgdGhlIHByb3h5IHNob3VsZCANCiAg ICByZXRyYW5zbWl0IDE5OSAoc3RlcCA0KSxhbmQgPEJSPiZndDsgdGhlbiB0aGUgcmV0cmFuc21p dHRlZDxCUj4mZ3Q7IDE5OSB3aWxsIA0KICAgIGJlIGFjY2VwdGVkIGJ5IFVBQyxhbmQgdGhlIGVh cmx5IGRpYWxvZyB3aWxsIGJlIHRlbWluYXRlZC48QlI+Jmd0OyA8QlI+Jmd0OyANCiAgICBVQUMg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUDxCUj4mZ3Q7ICZuYnNw OyAmbmJzcDsxLiANCiAgICBJTlZJVEU8QlI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0mZ3Q7PEJSPiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAgICZuYnNwOyAyLiAxODA8QlI+Jmd0 OyAmbHQ7LS0tLS0gXC8tLS0tLS0tPEJSPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQogICAg Jm5ic3A7L1wgMy4gMTk5PEJSPiZndDsgJmx0Oy0tLS0tLyAmbmJzcDtcLS0tLS0tPEJSPiZndDsg Jm5ic3A7ICZuYnNwOyANCiAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyA0LiAxOTkocmV0cmFuc21p dHRlZCk8QlI+Jmd0OyANCiAgICAmbHQ7LS0tLS0tLS0tLS0tLS0tPEJSPiZndDsgPEJSPiZndDsg Jm5ic3A7ICZuYnNwO3NlY29uZCwgQWNjb3JkaW5nIHRvIA0KICAgIHByYWN0aWNhbCB1c2UsIDE5 OSBjYW4gYmUgaW50ZW5kZWQgdG8gdGVtaW5hdGUgPEJSPiZndDsgb25lIGVhcmx5IGRpYWxvZyBh bmQgDQogICAgcmVsZWFzZTxCUj4mZ3Q7IHJlc291cmNlcyBhc3NvY2lhdGVkIHdpdGggdGhlIHNw ZWNpZmljIGVhcmx5IGRpYWxvZywgc28gdGhlIA0KICAgIGNvc3Qgc3BlbnQgPEJSPiZndDsgb24g cmVsaWFibGUgMTk5IGlzIHdvcnRoeS48QlI+Jmd0OyBJZiB0aGUgMTk5IGNhbm5vdCBiZSANCiAg ICBzZW50IHJlbGlhYmxlLHRoZW4gd2Ugc2hvdWxkIHNlbmQgaXQgdW5yZWxpYWJsZS48QlI+Jmd0 OyAmbmJzcDs8QlI+Jmd0OyAyLiANCiAgICBJbiB5b3VyIGxhc3QgbGV0dGVyLCB5b3Ugc2FpZCAi dGhlIHNlY29uZCAxOTkgY291bGQgaW5jbHVkZSA8QlI+Jmd0OyANCiAgICBpbmZvcm1hdGlvbiB3 aGljaCBpcyB0byBiZSBmb3J3YXJkZWQgdG8gdGhlPEJSPiZndDsgVUFDIiwgdGhlbiBkbyB5b3Ug bWVhbiwgDQogICAgdGhlIGVhcmx5IGRpYWxvZyBpcyBzdGlsbCBhbGl2ZSBhZnRlciB0aGUgZmly c3QgPEJSPiZndDsgMTk5IGlzIA0KICAgIGFjY2VwdGVkPzxCUj4mZ3Q7IDxCUj4mZ3Q7IDxCUj4m Z3Q7IEFsc28sIEluIG15IGxhc3QgbGV0dGVyLCBJIG1pc3MgYSAiTk9UIiANCiAgICBieSBtaXN0 YWtlLjxCUj4mZ3Q7IEl0IHNob3VsZCBiZTxCUj4mZ3Q7IFtFcmljXTogU3VyZWx5IHRoZSBVQVMg aXMgTk9UIA0KICAgIGFsbG93ZWQgdG8gc2VuZCBhbm90aGVyIHJlbGlhYmxlIHJlc3BvbnNlPEJS PiZndDsgdW50aWwgdGhlIGZpcnN0IG9uZSBpcyANCiAgICBhY2tub3dsZWRnZWQuLi48QlI+Jmd0 OyA8QlI+Jmd0OyBSZWdhcmRzLDxCUj4mZ3Q7IEVyaWMgd2FuZzxCUj4mZ3Q7IDxCUj4mZ3Q7IA0K ICAgIDxCUj4mZ3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7ICoiQ2hyaXN0ZXIgSG9sbWJlcmciICZsdDs8 QSANCiAgICBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0 aGlzKSIgDQogICAgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIg DQogICAgdGFyZ2V0PV9ibGFuaz5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L0E+Jmd0 Oyo8QlI+Jmd0OyA8QlI+Jmd0OyANCiAgICAyMDA5LTAyLTI3IDAzOjA0PEJSPiZndDsgPEJSPiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQogICAgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8QlI+Jmd0OyDmlLbku7bkuro8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IA0KICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyJFcmlj IHdhbmciICZsdDs8QSANCiAgICBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdp bmRvdyxldmVudCx0aGlzKSIgDQogICAgaHJlZj0ibWFpbHRvOmVyaWMud2FuZ3hyQGdtYWlsLmNv bSIgDQogICAgdGFyZ2V0PV9ibGFuaz5lcmljLndhbmd4ckBnbWFpbC5jb208L0E+Jmd0OzxCUj4m Z3Q7IOaKhOmAgTxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDsgDQogICAgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxBIA0KICAgIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiANCiAgICBocmVmPSJtYWls dG86c2lwQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPnNpcEBpZXRmLm9yZzwvQT4mZ3Q7LCAmbHQ7 PEEgDQogICAgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQs dGhpcykiIA0KICAgIGhyZWY9Im1haWx0bzp3YW5nLmxpYm9AenRlLmNvbS5jbiIgDQogICAgdGFy Z2V0PV9ibGFuaz53YW5nLmxpYm9AenRlLmNvbS5jbjwvQT4mZ3Q7PEJSPiZndDsg5Li76aKYPEJS PiZndDsgJm5ic3A7ICZuYnNwOyANCiAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtSRTogUXVlc3Rpb25zIGFib3V0IA0KICAgICJkcmFmdC1pZXRmLXNp cC0xOTktMDUiPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg DQogICAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8QlI+Jmd0OyA8 QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyANCiAgICA8QlI+Jmd0OyA8QlI+Jmd0OyBIaSw8QlI+ Jmd0OyA8QlI+Jmd0OyAmbmJzcDsmZ3Q7SSBzdGlsbCBoYXZlIHNvbWUgZGlmZmljdWx0IA0KICAg IGluIHVzaW5nIElFVEYgYW5kIGNhbm5vdCBmaW5kIHRoZSB3aG9sZTxCUj4mZ3Q7IHNvcnRlZCBj b21tZW50cyBhYm91dCB0aGlzIA0KICAgIGRyYWZ0LCBzbyBpIGhhdmUgc29tZSBkb3VidCBhYm91 dCB0aGlzIGRyYWZ0LjxCUj4mZ3Q7ICZuYnNwOyZndDs8QlI+Jmd0OyANCiAgICAmbmJzcDsmZ3Q7 ICZuYnNwOyAxLiAmbmJzcDsgIklmIGEgZm9ya2luZyBwcm94eSByZWNlaXZlcyBhIHJlbGlhYmx5 IHNlbnQgMTk5IA0KICAgIHJlc3BvbnNlIGZvciBhPEJSPiZndDsgZGlhbG9nLCBmb3Igd2hpY2gg dGhlIHByb3h5IGhhcyBwcmV2aW91c2x5IGdlbmVyYXRlZCANCiAgICBhbmQgc2VudCBhIDE5OTxC Uj4mZ3Q7IHJlc3BvbnNlLCB0aGUgcHJveHkgTVVTVCBmb3J3YXJkIHRoZSAxOTkgDQogICAgcmVz cG9uc2UuIjxCUj4mZ3Q7ICZuYnNwOyZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJz cDsgRG9lcyBpdCANCiAgICBkZXNjcmliZSB0aGUgY2FzZSBiZWxvdz8gQWx0aG91Z2ggUDEgaGF2 ZSBzZW50IGEgMTk5PEJSPiZndDsgcmVzcG9uc2UsIFAxIA0KICAgIGhhdnMgdG8gJm5ic3A7Zm9y d29yZCB0aGUgc2VuZCByZWxpYWJseSAxOTkgdG9vLk9yICZuYnNwO2lzIHRoZTxCUj4mZ3Q7IA0K ICAgIGZpcnN0IDE5OSBtaXN0YWtlZCBmb3IgMTh4PzxCUj4mZ3Q7ICZuYnNwOyZndDs8QlI+Jmd0 OyAmbmJzcDsmZ3Q7ICZuYnNwOyANCiAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtVQUMg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQogICAgJm5ic3A7IFAx ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg DQogICAgJm5ic3A7VUFTXzI8QlI+Jmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS0tIA0KICAgIElOVklURSAtLS0tLS0mZ3Q7PEJSPiZndDsg Jm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAgICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IC0tLSBJTlZJVEUgDQogICAgKGxlZyAyKSAtJmd0OzxCUj4mZ3Q7ICZuYnNwOyZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgICAmbmJzcDsmbHQ7LS0gMTk5KGxlZyAy KSAtLTxCUj4mZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAg ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbHQ7LS0gDQogICAgMTk5IChsZWcgMikgLS0tLS08QlI+Jmd0OyAmbmJz cDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQogICAgJm5ic3A7Jmx0 Oy0tIDE5OShsZWcgMikgLS08QlI+Jmd0OyA8QlI+Jmd0OyAmbmJzcDsmZ3Q7SSB0aGluayBpdCBz aGFsbCBiZSANCiAgICAxOTksIGFzIGN1cnJlbnRseSB3cml0dGVuLjxCUj4mZ3Q7ICZuYnNwOyZn dDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7W0VyaWNdOiBJZiANCiAgICAmbmJzcDt0aGlzIGlzIDE5OSwg dGhlbiBJcyB0aGVyZSBhIHNwZWNpYWwgcHVycG9zZSB0byBzZW5kIHR3bzxCUj4mZ3Q7IDE5OSAN CiAgICBpbiB0aGUgc2FtZSBkaWFsb2c/PEJSPiZndDsgJm5ic3A7Jmd0O0kgdGhpbmsgdGhhdCBv bmUgMTk5IGlzIA0KICAgIGVub3VnaC48QlI+Jmd0OyAmbmJzcDsmZ3Q7QW5kICZuYnNwO3RoZSBm aXJzdCAxOTkgbWF5IGJlIHJlbGlhYmxlIHRvbywgdGhhdCANCiAgICB3aWxsIG1ha2UgaXQgYSBs aXR0bGU8QlI+Jmd0OyBkaWZmaWN1bHQgdG8gc2VuZCB0aGUgc2Vjb25kIDE5OS48QlI+Jmd0OyAN CiAgICA8QlI+Jmd0OyBUaGUgc2Vjb25kIDE5OSBjb3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIHdo aWNoIGlzIHRvIGJlIGZvcndhcmRlZCANCiAgICB0byB0aGU8QlI+Jmd0OyBVQUMuPEJSPiZndDsg PEJSPiZndDsgPEJSPiZndDsgJm5ic3A7Jmd0OzIuICZuYnNwOyIxMC4gDQogICAgJm5ic3A7VXNh Z2Ugd2l0aCAxMDByZWw8QlI+Jmd0OyAmbmJzcDsmZ3Q7PEJSPiZndDsgJm5ic3A7Jmd0OyAmbmJz cDsgV2hlbiBhIA0KICAgIDE5OSBFYXJseSBEaWFsb2cgVGVybWluYXRlZCBwcm92aXNpb25hbCBy ZXNwb25zZSBpcyBzZW50IGJ5IGE8QlI+Jmd0OyBVQVMsIA0KICAgIHNpbmNlIHRoZSBwcm92aXNp b25hbCByZXNwb25zZSBpcyBvbmx5IHVzZWQgZm9yIGluZm9ybWF0aW9uPEJSPiZndDsgcHVycG9z ZSwgDQogICAgdGhlIFVBUyBTSE9VTEQgc2VuZCBpdCB1bnJlbGlhYmx5IGV2ZW4gaWYgdGhlIDEw MHJlbDxCUj4mZ3Q7ICZuYnNwOyZndDsgDQogICAgJm5ic3A7IG9wdGlvbiB0YWcgW1JGQzMyNjJd IGlzIHByZXNlbnQgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIG9mIHRoZTxCUj4mZ3Q7IA0KICAgIGFz c29jaWF0ZWQgcmVxdWVzdC4iPEJSPiZndDsgJm5ic3A7Jmd0OzxCUj4mZ3Q7ICZuYnNwOyZndDs8 QlI+Jmd0OyANCiAgICAmbmJzcDsmZ3Q7SSBoYXZlIHNlZW4gYSBjb21tZW50IG9uIHRoaXMgcXVl c3Rpb24sYnV0IHN0aWxsIG5vdCB1bmRlcnN0b29kIA0KICAgIGFib3V0PEJSPiZndDsgJm5ic3A7 Jmd0O2l0LiBJZiB0aGUgSU5WSVRFIGhhcyBhIFJlcXVpcmUgdGFnICJSZXF1aXJlOiANCiAgICAx MDByZWwiLGRvZXMgdGhlIFVBUzxCUj4mZ3Q7IHN0aWxsPEJSPiZndDsgJm5ic3A7Jmd0O3VzZSB1 bnJlbGlhYmxlIDE5OSANCiAgICByZXNwb25zZT88QlI+Jmd0OyAmbmJzcDsmZ3Q7PEJSPiZndDsg Jm5ic3A7Jmd0O1RoYXQgaXMgdGhlIHJlY29tbWVuZGF0aW9uLCANCiAgICB5ZXMuIFRoZSByZWFz b25zIGlzIHRoYXQgd2Ugd2FudCB0byBrZWVwPEJSPiZndDsgMTk5PEJSPiZndDsgJm5ic3A7Jmd0 O2FzIA0KICAgICJsaWdodHdlaWdodCIgYXMgcG9zc2libGUsIHdpdGhvdXQgcmVxdWlyZWluZyBy ZS10cmFuc21pc3Npb25zIGFuZDxCUj4mZ3Q7IA0KICAgICZuYnNwOyZndDtQUkFDS3MuPEJSPiZn dDsgJm5ic3A7Jmd0OzxCUj4mZ3Q7ICZuYnNwOyZndDtbRXJpY106IEJ1dCByZWxpYWJsZSANCiAg ICAxOTkgaGF2ZSBtb3JlIGFkdmFudGFnZSwgYW5kIEl0IGlzIHdvcnRoIHRvIHVzZTxCUj4mZ3Q7 IHRoZSByZWxpYWJsZSAxOTksSSANCiAgICB0aGluay48QlI+Jmd0OyA8QlI+Jmd0OyBJIGRvbid0 IGtub3cgd2hhdCB0aGF0IGFkdmFudGFnZSB3b3VsZCBiZSwgY29tcGFyZWQgDQogICAgdG8gaGF2 aW5nIHRvIHNlbmQ8QlI+Jmd0OyBQUkFDS3MgZXRjLiBUaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBx dWl0ZSBtdWNoLCBzbyANCiAgICBJIHdvdWxkIHJlYWxseSBuZWVkPEJSPiZndDsgc29tZSBnb29k IGp1c3RpZmljYXRpb24gdG8gY2hhbmdlIGl0IA0KICAgIG5vdy48QlI+Jmd0OyA8QlI+Jmd0OyBB bHNvLCB0aGUgZHJhZnQgZG9lc24ndCBmb3JiaWQgeW91IHRvIHNlbmQgdGhlIDE5OSANCiAgICBy ZWxpYWJseS4gSXQncyBvbmx5IGE8QlI+Jmd0OyBTSE9VTEQuPEJSPiZndDsgPEJSPiZndDsgPEJS PiZndDsgJm5ic3A7Jmd0O0lmIA0KICAgIDE5OSBpcyByZWxpYWJsZSwgdGhlcmUgaXMgb25lIG1v cmUgYWR2YW50YWdlLiBJZiB0aGUgMTk5IGFycml2ZXM8QlI+Jmd0OyANCiAgICAmbmJzcDsmZ3Q7 YmVmb3JlIHRoZSBmaXJzdCAxOHggcmVzcG9uc2UsIFVBQyBjYW4gZGlzY2FyZCB0aGUgZmlyc3Qg MTk5IA0KICAgIGFuZDxCUj4mZ3Q7IHByb2Nlc3M8QlI+Jmd0OyAmbmJzcDsmZ3Q7aXQgdW50aWwg VUFDIHJlY2VpdmVzIHRoZSBmaXJzdCAxOHggDQogICAgcmVzcG9uc2UgdGhhdCBoYXMgdGhlIHNh bWU8QlI+Jmd0OyAmbmJzcDsmZ3Q7dG8tdGFnIGFzIDE5OSwgYXMgdGhlIHJlbGlhYmxlIA0KICAg IDE5OSBzaG91bGQgYmUgcmUtdHJhbnNtaXRlZCB1bnRpbDxCUj4mZ3Q7ICZuYnNwOyZndDtyZWNl aXZlZCBQUkFDSy48QlI+Jmd0OyANCiAgICAmbmJzcDsmZ3Q7PEJSPiZndDsgJm5ic3A7Jmd0O0lm IHRoZSBJTlZJVEUgY29udGFpbnMgIlJlcXVpcmU6IDEwMHJlbCIsIHRoZSANCiAgICBmaXJzdCAx OHggbXVzdCBhbHNvIGJlPEJSPiZndDsgJm5ic3A7Jmd0O3NlbnQgcmVsaWFibHkuIEFuZCwgSSBk b24ndCB0aGluayANCiAgICB0aGUgVUFTIGlzIGFsbG93ZWQgdG8gc2VuZCBhbm90aGVyPEJSPiZn dDsgJm5ic3A7Jmd0O3JlbGlhYmxlIHJlc3BvbnNlIHVudGlsIA0KICAgIHRoZSBmaXJzdCBvbmUg aXMgYWNrbm93bGVkZ2VkLCBzbyBJIGRvbid0IHRoaW5rPEJSPiZndDsgJm5ic3A7Jmd0O2EgcmVs aWFibGUgDQogICAgMTk5IHdvdWxkIHJlYWNoIHRoZSBVQUMgYmVmb3JlIHRoZSBmaXJzdCByZWxp YWJsZSAxOHguPEJSPiZndDsgDQogICAgJm5ic3A7Jmd0OzxCUj4mZ3Q7ICZuYnNwOyZndDtbRXJp Y106IFN1cmVseSB0aGUgVUFTIGlzIGFsbG93ZWQgdG8gc2VuZCANCiAgICBhbm90aGVyIHJlbGlh YmxlIHJlc3BvbnNlPEJSPiZndDsgdW50aWwgdGhlIGZpcnN0IG9uZSBpcyANCiAgICBhY2tub3ds ZWRnZWQsPEJSPiZndDsgPEJSPiZndDsgSWYgSSByZW1lbWJlciBjb3JyZWN0bHksIHRoZSBGSVJT VCByZWxpYWJsZSANCiAgICByZXNwb25zZSBtdXN0IGJlIGFja25vd2xlZGVkPEJSPiZndDsgYmVm b3JlIHRoZSBuZXh0IHJlbGlhYmxlIHJlc3BvbnNlIGlzIA0KICAgIHNlbnQuIEJ1dCwgd2UgY2Fu IGRvdWJsZSBjaGVjayBpbjxCUj4mZ3Q7IHRoZSBQUkFDSyBzcGVjLjxCUj4mZ3Q7IDxCUj4mZ3Q7 IA0KICAgICZuYnNwOyZndDtidXQgcmVsaWFibGUgMTk5IHdpbGwgYmUgdXNlZnVsIGlmIHRoZSBm aXJzdCAxOHggaXMgdW5yZWxpYWJsZSwgb3IgDQogICAgdGhlPEJSPiZndDsgZmlyc3QgMTh4IGhh cyBiZWVuIGFja253bGVkZ2VkLiBJdCdzIGFub3RoZXIgY2FzZSBkaWZmZXJlbnQgZnJvbSANCiAg ICB0aGU8QlI+Jmd0OyBhYm92ZSBvbmUgJm5ic3A7d2hvc2UgSU5WSVRFIGNvbnRhaW5zICJyZXF1 aXJlOiAxMDByZWwiLjxCUj4mZ3Q7IA0KICAgIDxCUj4mZ3Q7IElmIDEwMHJlbCBpcyByZXF1aXJl ZCB0aGUgMTh4IGNhbm5vdCBiZSB1bnJlbGlhYmxlLjxCUj4mZ3Q7IA0KICAgIDxCUj4mZ3Q7IFJl Z2FyZHMsPEJSPiZndDsgPEJSPiZndDsgQ2hyaXN0ZXI8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0 OyANCiAgICA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+ Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4mZ3Q7IFpURSANCiAgICBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIA0KICAgIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCiAgICBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCiAgICBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIA0KICAgIG90aGVycy48QlI+Jmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMg dHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgDQogICAgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIA0KICAgIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSANCiAgICBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2Uu IEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIA0KICAgIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuPEJSPiZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgDQogICAgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPEJS PiZndDsgPEJSPiZndDsgPEJSPiZndDsgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPiZndDsgDQog ICAgPEJSPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188QlI+Jmd0OyBTaXAgbWFpbGluZyANCiAgICBsaXN0ICZuYnNwOzxBIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiANCiAgICBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcCIgDQogICAgdGFyZ2V0PV9ibGFu az5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcDwvQT48QlI+Jmd0OyBU aGlzIA0KICAgIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJv dG9jb2w8QlI+Jmd0OyBVc2UgPEEgDQogICAgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0 TGluayh3aW5kb3csZXZlbnQsdGhpcykiIA0KICAgIGhyZWY9Im1haWx0bzpzaXAtaW1wbGVtZW50 b3JzQGNzLmNvbHVtYmlhLmVkdSIgDQogICAgdGFyZ2V0PV9ibGFuaz5zaXAtaW1wbGVtZW50b3Jz QGNzLmNvbHVtYmlhLmVkdTwvQT4gZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IA0KICAgIHNpcDxC Uj4mZ3Q7IFVzZSA8QSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSIgDQogICAgaHJlZj0ibWFpbHRvOnNpcHBpbmdAaWV0Zi5vcmciIHRhcmdldD1f Ymxhbms+c2lwcGluZ0BpZXRmLm9yZzwvQT4gZm9yIG5ldyANCiAgICBkZXZlbG9wbWVudHMgb24g dGhlIGFwcGxpY2F0aW9uIG9mIHNpcDxCUj48L0ZPTlQ+PC9UVD48QlI+PEJSPiZuYnNwOzwvRElW PjxQUkU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5i c3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBp ZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0 byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZu YnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50 cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVy cy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJh bnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJz cDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3Vz ZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5i c3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJ ZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZu YnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtv cmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3Zp ZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2Fy ZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVy Lg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNw O2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJz cDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L1BSRT48L1NQQU4+PC9ESVY+PC9ESVY+PEJSPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPlNpcCANCiAg ICBtYWlsaW5nIGxpc3QgJm5ic3A7PEEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGlu ayh3aW5kb3csZXZlbnQsdGhpcykiIA0KICAgIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwIiANCiAgICB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwPC9BPjxCUj5UaGlzIGxpc3QgaXMgDQogICAgZm9yIE5F VyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2w8QlI+VXNlIDxBIA0KICAgIG9u Y2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiANCiAg ICBocmVmPSJtYWlsdG86c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUiIA0KICAgIHRh cmdldD1fYmxhbms+c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHU8L0E+IGZvciBxdWVz dGlvbnMgb24gY3VycmVudCANCiAgICBzaXA8QlI+VXNlIDxBIG9uY2xpY2s9InJldHVybiB0b3Au anMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiANCiAgICBocmVmPSJtYWlsdG86c2lw cGluZ0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz5zaXBwaW5nQGlldGYub3JnPC9BPiBmb3IgbmV3 IA0KICAgIGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2YgDQogIHNpcDxCUj48L0JM T0NLUVVPVEU+PC9ESVY+PEJSPjwvU1BBTj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+ PEJSPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C998CD.8F390166-- From eric.wangxr@gmail.com Fri Feb 27 03:35:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A053928C200 for ; Fri, 27 Feb 2009 03:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAx5BxmFAUH2 for ; Fri, 27 Feb 2009 03:35:42 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 2AD8928C163 for ; Fri, 27 Feb 2009 03:35:42 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so956772ana.4 for ; Fri, 27 Feb 2009 03:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:content-language:thread-index; bh=RO8LJ82UN52f9InkNfGiEbFtIWeMDlYOzPCruIh1Mm0=; b=d7pGJj6HD2V9koH5bAhl7DRzA/0wocpOGyloJVeSis9xoQcHsr+71er3Qo9ySN18SJ i2p4/oV7ivwyjjeZ6R6TiMnlcfE2PsrK8M9KJlWXMoCOVXsEcFqT4Y6QvAdRrIeBFfX6 ABVDKKTXGI6pfCLd8kZuUSIc97LP/m8G1R260= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:content-language:thread-index; b=I+L9XH4TM6IYEY+9vrF59eLTJnKJIu9oiVfGjdyI931TFCtka6HyTlCHk5SmJyMtNU lWTIqqAzoPiaMWZ/iUcypjMvdrbW5yBR5Htioz1QeGC56CEnaklIC9pMXxhX4YqZcPJX T5ACA+5bWrvjbbskM9fQuNIl/4mrbuV7qdryU= Received: by 10.110.109.19 with SMTP id h19mr3531759tic.16.1235734562749; Fri, 27 Feb 2009 03:36:02 -0800 (PST) Received: from EricXr ([121.229.139.177]) by mx.google.com with ESMTPS id u8sm750537tia.30.2009.02.27.03.35.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 03:36:01 -0800 (PST) From: "Eric.wang" To: "'Christer Holmberg'" References: <49A7484B.3060407@cisco.com> <898632750902270249o3213670au6823cc4ab6180c8c@mail.gmail.com> <898632750902270310k72308b9au7645d26cfc2d7de8@mail.gmail.com> In-Reply-To: Date: Fri, 27 Feb 2009 19:35:35 +0800 Message-ID: <49a7d021.08486e0a.1eb0.ffffbafc@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018C_01C99912.91C86420" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AcmYzATO+ofCSLGqSXec4qXlENVCAQAAFhgwAACxHxA= Cc: sip@ietf.org, 'Paul Kyzivat' Subject: [Sip] =?utf-8?b?562U5aSNOiAg562U5aSNOiBSRTogUXVlc3Rpb25zIGFib3V0?= =?utf-8?q?_=22draft-ietf-sip-199-05=22?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:35:44 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ ------=_NextPart_000_018C_01C99912.91C86420 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Christer, =20 It seems I=E2=80=99d better review all your comments firstJ. =20 Thank you for answering my question. =20 Best regards, Eric =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Christer Holmberg = [mailto:christer.holmberg@ericsson.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B42=E6=9C=8827=E6=97=A5 = 19:22 =E6=94=B6=E4=BB=B6=E4=BA=BA: Eric wang =E6=8A=84=E9=80=81: wang.libo@zte.com.cn; Paul Kyzivat; sip@ietf.org =E4=B8=BB=E9=A2=98: RE: [Sip] =E7=AD=94=E5=A4=8D: RE: Questions about = "draft-ietf-sip-199-05" =20 Hi, >I don't think the 199 can be sent unreliably if UAC require 100rel. >As in RFC3262, It says. > =20 >The UAS MUST send any non-100 provisional response reliably if the > initial request contained a Require header field with the option = tag > 100rel. If the UAS is unwilling to do so, it MUST reject the = initial > request with a 420 (Bad Extension) and include an Unsupported = header > field containing the option tag 100rel.=20 =20 This has been discussed, and the proposed outcome was to allow 199 to be = sent unreliably even if 100rel is required. =20 Regards, =20 Christer =20 =20 =20 =20 =20 2009/2/27, Christer Holmberg :=20 Hi, =20 >If the UAC requires 100rel ,then what should the proxy do if it = receives a no-2xx final response after forking?=20 =20 The proxy should send 199 unreliably. =20 Regards, =20 Christer=20 =20 =20 2009/2/27, Christer Holmberg :=20 Hi, =20 >Practically, when Call forward and fork are used in the same system, = there are=20 >lots of early dialogs that should be eliminated by 199 existed.=20 >So I think that it's useful to let 199 reliable.=20 >And we just added fork-service to our system ,and find 199 is really = useful, and=20 >if the 199 is missing, problems will happen. =20 =20 I'm glad you think 199 is useful :) =20 But, if a proxy would have to terminate PRACKs etc it would not be a = proxy anymore - it would be a B2BUA. =20 So, if you really want your network to send 199 reliably, I guess you = could use a B2BUA instead of a proxy. >It sounds good that there is a way to prevent PRACK addressed to = UAS,but i don't know how to do now.=20 =20 The only way to prevent it is by the proxy not sending the 199 relaible. = =20 =20 >ps:=20 >RFC3261 16.7 Response Processing=20 >Since a proxy may not insert a tag into the To header field of=20 >a 1xx response to a request that did not contain one, it cannot=20 >issue non-100 provisional responses on its own. =20 =20 Yes, but I we have agreed that a proxy is allowed to send 199. =20 But, the proxy is not going to generate new To header tag values for the = 199. It will use whatever tags that have already been created for the = early dialogs.=20 =20 Regards, =20 Christer =20 =20 =20 =20 =20 =20 =20 *allowing* (much less *requiring*) the 199 to be reliable introduces nasty problems. The 199 is only an optimization, so having it be unreliable is ok IMO. The problem is that if a proxy sends the 199, then the recipient of the PRACK should be the proxy. But the PRACK is an in-dialog message, so it must be addressed to the Contact of the UAS. If the proxy sends a reliable 199, and the PRACK is addressed to the UAS, the UAS will be very surprised, since it has not send a reliable provisional, and is so not expecting a PRACK. In fact, it has sent a final response, has presumably already received the ACK, and so is expecting nothing. Very ugly. Paul wang.libo@zte.com.cn wrote: >=20 > Hi, >=20 > And there still two questions left. >=20 > 1. Is the 199 should be reliable or unreliable? > I think that 199 should be reliable if possible. >=20 >=20 > First, If a client receives an unreliable 199 response on a dialog=20 > which has > not previously been created (this can happen if a 199 response > reaches the client before a 18x response) the client SHALL discard > the 199 responses. >=20 > The figure below shows an example.The 180 is sent first but arrives = > later than 199. > If the 199 is reliable, the proxy should retransmit 199 (step 4),and=20 > then the retransmitted > 199 will be accepted by UAC,and the early dialog will be teminated. >=20 > UAC P > 1. INVITE > ---------------> > 2. 180 > <----- \/------- > /\ 3. 199 > <-----/ \------ > 4. 199(retransmitted) > <--------------- >=20 > second, According to practical use, 199 can be intended to teminate = > one early dialog and release > resources associated with the specific early dialog, so the cost spent = > on reliable 199 is worthy. > If the 199 cannot be sent reliable,then we should send it unreliable. > =20 > 2. In your last letter, you said "the second 199 could include=20 > information which is to be forwarded to the > UAC", then do you mean, the early dialog is still alive after the = first=20 > 199 is accepted? >=20 >=20 > Also, In my last letter, I miss a "NOT" by mistake. > It should be > [Eric]: Surely the UAS is NOT allowed to send another reliable = response > until the first one is acknowledged... >=20 > Regards, > Eric wang >=20 >=20 >=20 >=20 > *"Christer Holmberg" * >=20 > 2009-02-27 03:04 >=20 > =20 > =E6=94=B6=E4=BB=B6=E4=BA=BA > "Eric wang" > =E6=8A=84=E9=80=81 > , > =E4=B8=BB=E9=A2=98 > RE: Questions about "draft-ietf-sip-199-05" >=20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > Hi, >=20 > >I still have some difficult in using IETF and cannot find the whole > sorted comments about this draft, so i have some doubt about this = draft. > > > > 1. "If a forking proxy receives a reliably sent 199 response = for a > dialog, for which the proxy has previously generated and sent a 199 > response, the proxy MUST forward the 199 response." > > > > Does it describe the case below? Although P1 have sent a 199 > response, P1 havs to forword the send reliably 199 too.Or is the > first 199 mistaked for 18x? > > > > UAC P1 UAS_2 > > --- INVITE ------> > > --- INVITE (leg 2) -> > > <-- 199(leg 2) -- > > <-- 199 (leg 2) ----- > > <-- 199(leg 2) -- >=20 > >I think it shall be 199, as currently written. > > > >[Eric]: If this is 199, then Is there a special purpose to send two > 199 in the same dialog? > >I think that one 199 is enough. > >And the first 199 may be reliable too, that will make it a little > difficult to send the second 199. >=20 > The second 199 could include information which is to be forwarded to = the > UAC. >=20 >=20 > >2. "10. Usage with 100rel > > > > When a 199 Early Dialog Terminated provisional response is sent = by a > UAS, since the provisional response is only used for information > purpose, the UAS SHOULD send it unreliably even if the 100rel > > option tag [RFC3262] is present in the Require header of the > associated request." > > > > > >I have seen a comment on this question,but still not understood = about > >it. If the INVITE has a Require tag "Require: 100rel",does the UAS > still > >use unreliable 199 response? > > > >That is the recommendation, yes. The reasons is that we want to keep > 199 > >as "lightweight" as possible, without requireing re-transmissions = and > >PRACKs. > > > >[Eric]: But reliable 199 have more advantage, and It is worth to use > the reliable 199,I think. >=20 > I don't know what that advantage would be, compared to having to send > PRACKs etc. This has been discussed quite much, so I would really need > some good justification to change it now. >=20 > Also, the draft doesn't forbid you to send the 199 reliably. It's only = a > SHOULD. >=20 >=20 > >If 199 is reliable, there is one more advantage. If the 199 arrives > >before the first 18x response, UAC can discard the first 199 and > process > >it until UAC receives the first 18x response that has the same > >to-tag as 199, as the reliable 199 should be re-transmited until > >received PRACK. > > > >If the INVITE contains "Require: 100rel", the first 18x must also be > >sent reliably. And, I don't think the UAS is allowed to send another > >reliable response until the first one is acknowledged, so I don't = think > >a reliable 199 would reach the UAC before the first reliable 18x. > > > >[Eric]: Surely the UAS is allowed to send another reliable response > until the first one is acknowledged, >=20 > If I remember correctly, the FIRST reliable response must be = acknowleded > before the next reliable response is sent. But, we can double check in > the PRACK spec. >=20 > >but reliable 199 will be useful if the first 18x is unreliable, or = the > first 18x has been acknwledged. It's another case different from the > above one whose INVITE contains "require: 100rel". >=20 > If 100rel is required the 18x cannot be unreliable. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=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. >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip =20 -------------------------------------------------------- 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. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =20 ------=_NextPart_000_018C_01C99912.91C86420 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Christer,

 

=C2=A0=C2=A0 It seems I=E2=80=99d better review all your = comments firstJ.

=C2=A0

=C2=A0=C2=A0 Thank you for answering my = question.

 

Best regards,

Eric

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B42=E6=9C=8827=E6=97=A5 19:22
=E6=94=B6=E4=BB=B6=E4=BA=BA: Eric wang
=E6=8A=84=E9=80=81: wang.libo@zte.com.cn; Paul Kyzivat; sip@ietf.org
=E4=B8=BB=E9=A2=98: RE: [Sip] =E7=AD=94=E5=A4=8D: RE: Questions about = "draft-ietf-sip-199-05"

 

Hi,

>I don't think the 199 can be = sent unreliably if UAC require 100rel.

>As in RFC3262, It = says.

>   

>The UAS MUST send any non-100 provisional response reliably if the
>&n= bsp;   initial request contained a Require header = field with the option tag
>&n= bsp;   100rel.  If the UAS is unwilling to do = so, it MUST reject the initial
>&n= bsp;   request with a 420 (Bad Extension) and include = an Unsupported header
>&n= bsp;   field containing the option tag = 100rel.&n= bsp;

 

This has been discussed, and the proposed outcome = was to allow 199 to be sent unreliably even if 100rel is required.

 

Regards,

 

Christer

 

 

 

 

 

2009/2/27, Christer Holmberg <christer.holmberg@ericsson= .com>:

Hi,

 

>If the UAC requires 100rel = ,then what should the proxy do if it receives a no-2xx&n= bsp;  final response after = forking?&n= bsp;

 

The proxy should send 199 unreliably.

 

Regards,

 

Christer 

 



 

2009/2/27, Christer Holmberg <christer.holmberg@ericsson.com>:

Hi,

  <= /span>
>Practically, when Call forward and fork are used = in the same system, there are 
>lots of early dialogs that should be eliminated by = 199 existed. 
>So I think that it's useful to let 199 reliable. 
>And we just added fork-service to our system ,and = find 199 is really useful, and 
>if the 199 is missing, problems will happen. &n= bsp;

 

I'm glad you think 199 is useful :)

 

But, if a proxy would have to terminate PRACKs etc it would = not be a proxy anymore - it would be a B2BUA.

 

So, if you really want your network to send 199 reliably, I = guess you could use a B2BUA instead of a proxy.


>It sounds good that there is a way to prevent = PRACK addressed to UAS,but i don't know  = how to do now. 

 

The only way to prevent it is by the proxy not sending the 199 relaible.  
  &= nbsp; 
>ps: 
>RFC3261 16.7 Response = Processing =
>Since a proxy may not insert a tag into the To = header field of 
>a 1xx response to a request that did not contain = one, it cannot 
>issue non-100 provisional responses on = its own.  

 

Yes, but I we have agreed that a proxy is allowed to = send 199.

 

But, the proxy is not going to generate new To header tag = values for the 199. It will use whatever tags that have already been = created for the early dialogs. 

 

Regards,

 

Christer


 

 

 

 

 

 

 



*allowing* = (much less *requiring*) the 199 to be reliable introduces
nasty problems. The 199 is only an optimization, so having it = be
unreliable is ok IMO.

The problem is that if a proxy sends the 199, then the recipient of = the
PRACK should be the proxy. But the PRACK is an in-dialog message, so = it
must be addressed to the Contact of the UAS.

If the proxy sends a reliable 199, and the PRACK is addressed to = the
UAS, the UAS will be very surprised, since it has not send a = reliable
provisional, and is so not expecting a PRACK. In fact, it has sent = a
final response, has presumably already received the ACK, and so = is
expecting nothing.

Very ugly.

                = Paul

wang.libo@zte.com.cn wrote:
>
> Hi,
>
> And there still two questions left.
>
> 1.  Is the 199 should be reliable or unreliable?
>     I think that 199 should be reliable if = possible.
>
>
>    First, If a client receives an unreliable 199 = response on a dialog
> which has
>    not previously been created (this can happen if a = 199 response
>    reaches the client before a 18x response) the = client SHALL discard
>    the 199 responses.
>
>    The figure below shows an example.The 180 is sent = first but arrives
> later than 199.
> If the 199 is reliable, the proxy should retransmit 199 (step = 4),and
> then the retransmitted
> 199 will be accepted by UAC,and the early dialog will be = teminated.
>
> UAC             P
>    1. INVITE
> --------------->
>           2. 180
> <----- \/-------
>        /\ 3. 199
> <-----/  \------
>           4. = 199(retransmitted)
> <---------------
>
>    second, According to practical use, 199 can be = intended to teminate
> one early dialog and release
> resources associated with the specific early dialog, so the = cost spent
> on reliable 199 is worthy.
> If the 199 cannot be sent reliable,then we should send it = unreliable.
>  
> 2. In your last letter, you said "the second 199 could = include
> information which is to be forwarded to the
> UAC", then do you mean, the early dialog is still alive = after the first
> 199 is accepted?
>
>
> Also, In my last letter, I miss a "NOT" by = mistake.
> It should be
> [Eric]: Surely the UAS is NOT allowed to send another reliable response
> until the first one is acknowledged...
>
> Regards,
> Eric wang
>
>
>
>
> *"Christer Holmberg" <christer.holmberg@ericsson.com>*
>
> 2009-02-27 03:04
>
>                 =  
> =E6=94=B6=E4=BB=B6=E4=BA=BA
>                  "Eric wang" <eric.wangxr@gmail.com>
> =E6=8A=84=E9=80=81
>                 =  <sip@ietf.org>, = <wang.libo@zte.com.cn>
> =E4=B8=BB=E9=A2=98
>                 =  RE: Questions about "draft-ietf-sip-199-05"
>
>
>                 =  
>
>
>
>
>
> Hi,
>
>  >I still have some difficult in using IETF and cannot = find the whole
> sorted comments about this draft, so i have some doubt about = this draft.
>  >
>  >   1.   "If a forking proxy receives a reliably sent 199 response for a
> dialog, for which the proxy has previously generated and sent a = 199
> response, the proxy MUST forward the 199 = response."
>  >
>  >     Does it describe the case below? = Although P1 have sent a 199
> response, P1 havs to  forword the send reliably 199 too.Or  is the
> first 199 mistaked for 18x?
>  >
>  >          UAC     =           P1             =      UAS_2
>  >            --- INVITE ------>
>  >               =               --- INVITE (leg 2) = ->
>  >            <-- = 199(leg 2) --
>  >               =               <-- 199 (leg 2) = -----
>  >            <-- = 199(leg 2) --
>
>  >I think it shall be 199, as currently = written.
>  >
>  >[Eric]: If  this is 199, then Is there a special purpose to send two
> 199 in the same dialog?
>  >I think that one 199 is enough.
>  >And  the first 199 may be reliable too, that = will make it a little
> difficult to send the second 199.
>
> The second 199 could include information which is to be = forwarded to the
> UAC.
>
>
>  >2.  "10.  Usage with 100rel
>  >
>  >   When a 199 Early Dialog Terminated = provisional response is sent by a
> UAS, since the provisional response is only used for = information
> purpose, the UAS SHOULD send it unreliably even if the = 100rel
>  >   option tag [RFC3262] is present in the = Require header of the
> associated request."
>  >
>  >
>  >I have seen a comment on this question,but still not understood about
>  >it. If the INVITE has a Require tag "Require: 100rel",does the UAS
> still
>  >use unreliable 199 response?
>  >
>  >That is the recommendation, yes. The reasons is that = we want to keep
> 199
>  >as "lightweight" as possible, without = requireing re-transmissions and
>  >PRACKs.
>  >
>  >[Eric]: But reliable 199 have more advantage, and It = is worth to use
> the reliable 199,I think.
>
> I don't know what that advantage would be, compared to having = to send
> PRACKs etc. This has been discussed quite much, so I would = really need
> some good justification to change it now.
>
> Also, the draft doesn't forbid you to send the 199 reliably. = It's only a
> SHOULD.
>
>
>  >If 199 is reliable, there is one more advantage. If = the 199 arrives
>  >before the first 18x response, UAC can discard the = first 199 and
> process
>  >it until UAC receives the first 18x response that has = the same
>  >to-tag as 199, as the reliable 199 should be = re-transmited until
>  >received PRACK.
>  >
>  >If the INVITE contains "Require: 100rel", = the first 18x must also be
>  >sent reliably. And, I don't think the UAS is allowed = to send another
>  >reliable response until the first one is = acknowledged, so I don't think
>  >a reliable 199 would reach the UAC before the first = reliable 18x.
>  >
>  >[Eric]: Surely the UAS is allowed to send another = reliable response
> until the first one is acknowledged,
>
> If I remember correctly, the FIRST reliable response must be acknowleded
> before the next reliable response is sent. But, we can double = check in
> the PRACK spec.
>
>  >but reliable 199 will be useful if the first 18x is unreliable, or the
> first 18x has been acknwledged. It's another case different = from the
> above one  whose INVITE contains "require: = 100rel".
>
> If 100rel is required the 18x cannot be unreliable.
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
> = --------------------------------------------------------
> 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.
>
>
> ------------------------------------------------------------------------<= /tt>
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP = Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


 

--------------------------------------------------------
ZTE Information Security Notice: The&nbs=
p;information contained in this mail is sol=
ely property of the sender's organization. =
This mail communication is confidential. Recipie=
nts named above are obligated to maintain&n=
bsp;secrecy and are not permitted to disclo=
se the contents of this communication to&nb=
sp;others.
This email and any files transmitte=
d with it are confidential and intended&nbs=
p;solely for the use of the individual =
;or entity to whom they are addressed. =
;If you have received this email in er=
ror please notify the originator of the&nbs=
p;message. Any views expressed in this mess=
age are those of the individual sender.
This message has been scanned for&n=
bsp;viruses and Spam by ZTE Anti-Spam syste=
m.


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



 

------=_NextPart_000_018C_01C99912.91C86420-- From ian.elz@ericsson.com Fri Feb 27 05:40:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5EA23A69AD for ; Fri, 27 Feb 2009 05:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45, 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 Cy3XIFj5a+VC for ; Fri, 27 Feb 2009 05:40:47 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A08B63A694E for ; Fri, 27 Feb 2009 05:40:46 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 86F9D21D52; Fri, 27 Feb 2009 14:38:02 +0100 (CET) X-AuditID: c1b4fb3e-ae89fbb0000023da-7d-49a7ecba41d9 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 34E8E2142E; Fri, 27 Feb 2009 14:38:02 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 14:38:01 +0100 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_01C998E0.9C0F860C" Date: Fri, 27 Feb 2009 14:39:29 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip]??: RE: Questions about "draft-ietf-sip-199-05" thread-index: AcmY4NB5+fRfK7z0SE6ZbyoemxXYEA== References: <49A7484B.3060407@cisco.com> From: "Ian Elz" To: "Christer Holmberg" , , "Paul Kyzivat" X-OriginalArrivalTime: 27 Feb 2009 13:38:01.0845 (UTC) FILETIME=[9C423250:01C998E0] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] ??: RE: Questions about "draft-ietf-sip-199-05" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:40:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C998E0.9C0F860C Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Christer, =20 The B2BUA should only send the 199 reliably if the Contact header has = been mapped in the B2BUA. =20 If the B2BUA has not mapped the Contact then you have a similar problem = to that of the proxy.=20 =20 The B2BUA could of course intercept the PRACK and send the 200 OK even = though the PRACK was addressed to the Contact provided in the initial = response to the INVITE. =20 To use Paul=A1=AFs words =A8C =A1=B0ugly=A1=B1. =20 Ian Elz ________________________________ From: Christer Holmberg=20 Sent: 27 February 2009 06:23 To: wang.libo@zte.com.cn; Paul Kyzivat Cc: sip@ietf.org Subject: Re: [Sip]??: RE: Questions about "draft-ietf-sip-199-05" =20 Hi, =20 >Practically, when Call forward and fork are used in the same system, = there are=20 >lots of early dialogs that should be eliminated by 199 existed.=20 >So I think that it's useful to let 199 reliable.=20 >And we just added fork-service to our system ,and find 199 is really = useful, and=20 >if the 199 is missing, problems will happen. =20 =20 I'm glad you think 199 is useful :) =20 But, if a proxy would have to terminate PRACKs etc it would not be a = proxy anymore - it would be a B2BUA. =20 So, if you really want your network to send 199 reliably, I guess you = could use a B2BUA instead of a proxy. >It sounds good that there is a way to prevent PRACK addressed to = UAS,but i don't know how to do now.=20 =20 The only way to prevent it is by the proxy not sending the 199 relaible. = =20 =20 >ps:=20 >RFC3261 16.7 Response Processing=20 >Since a proxy may not insert a tag into the To header field of=20 >a 1xx response to a request that did not contain one, it cannot=20 >issue non-100 provisional responses on its own. =20 =20 Yes, but I we have agreed that a proxy is allowed to send 199. =20 But, the proxy is not going to generate new To header tag values for the = 199. It will use whatever tags that have already been created for the = early dialogs.=20 =20 Regards, =20 Christer =20 =20 =20 =20 =20 =20 =20 =20 =20 *allowing* (much less *requiring*) the 199 to be reliable introduces nasty problems. The 199 is only an optimization, so having it be unreliable is ok IMO. The problem is that if a proxy sends the 199, then the recipient of the PRACK should be the proxy. But the PRACK is an in-dialog message, so it must be addressed to the Contact of the UAS. If the proxy sends a reliable 199, and the PRACK is addressed to the UAS, the UAS will be very surprised, since it has not send a reliable provisional, and is so not expecting a PRACK. In fact, it has sent a final response, has presumably already received the ACK, and so is expecting nothing. Very ugly. Paul wang.libo@zte.com.cn wrote: >=20 > Hi, >=20 > And there still two questions left. >=20 > 1. Is the 199 should be reliable or unreliable? > I think that 199 should be reliable if possible. >=20 >=20 > First, If a client receives an unreliable 199 response on a dialog=20 > which has > not previously been created (this can happen if a 199 response > reaches the client before a 18x response) the client SHALL discard > the 199 responses. >=20 > The figure below shows an example.The 180 is sent first but arrives = > later than 199. > If the 199 is reliable, the proxy should retransmit 199 (step 4),and=20 > then the retransmitted > 199 will be accepted by UAC,and the early dialog will be teminated. >=20 > UAC P > 1. INVITE > ---------------> > 2. 180 > <----- \/------- > /\ 3. 199 > <-----/ \------ > 4. 199(retransmitted) > <--------------- >=20 > second, According to practical use, 199 can be intended to teminate = > one early dialog and release > resources associated with the specific early dialog, so the cost spent = > on reliable 199 is worthy. > If the 199 cannot be sent reliable,then we should send it unreliable. > =20 > 2. In your last letter, you said "the second 199 could include=20 > information which is to be forwarded to the > UAC", then do you mean, the early dialog is still alive after the = first=20 > 199 is accepted? >=20 >=20 > Also, In my last letter, I miss a "NOT" by mistake. > It should be > [Eric]: Surely the UAS is NOT allowed to send another reliable = response > until the first one is acknowledged... >=20 > Regards, > Eric wang >=20 >=20 >=20 >=20 > *"Christer Holmberg" * >=20 > 2009-02-27 03:04 >=20 > =20 > =CA=D5=BC=FE=C8=CB > "Eric wang" > =B3=AD=CB=CD > , > =D6=F7=CC=E2 > RE: Questions about "draft-ietf-sip-199-05" >=20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > Hi, >=20 > >I still have some difficult in using IETF and cannot find the whole > sorted comments about this draft, so i have some doubt about this = draft. > > > > 1. "If a forking proxy receives a reliably sent 199 response = for a > dialog, for which the proxy has previously generated and sent a 199 > response, the proxy MUST forward the 199 response." > > > > Does it describe the case below? Although P1 have sent a 199 > response, P1 havs to forword the send reliably 199 too.Or is the > first 199 mistaked for 18x? > > > > UAC P1 UAS_2 > > --- INVITE ------> > > --- INVITE (leg 2) -> > > <-- 199(leg 2) -- > > <-- 199 (leg 2) ----- > > <-- 199(leg 2) -- >=20 > >I think it shall be 199, as currently written. > > > >[Eric]: If this is 199, then Is there a special purpose to send two > 199 in the same dialog? > >I think that one 199 is enough. > >And the first 199 may be reliable too, that will make it a little > difficult to send the second 199. >=20 > The second 199 could include information which is to be forwarded to = the > UAC. >=20 >=20 > >2. "10. Usage with 100rel > > > > When a 199 Early Dialog Terminated provisional response is sent = by a > UAS, since the provisional response is only used for information > purpose, the UAS SHOULD send it unreliably even if the 100rel > > option tag [RFC3262] is present in the Require header of the > associated request." > > > > > >I have seen a comment on this question,but still not understood = about > >it. If the INVITE has a Require tag "Require: 100rel",does the UAS > still > >use unreliable 199 response? > > > >That is the recommendation, yes. The reasons is that we want to keep > 199 > >as "lightweight" as possible, without requireing re-transmissions = and > >PRACKs. > > > >[Eric]: But reliable 199 have more advantage, and It is worth to use > the reliable 199,I think. >=20 > I don't know what that advantage would be, compared to having to send > PRACKs etc. This has been discussed quite much, so I would really need > some good justification to change it now. >=20 > Also, the draft doesn't forbid you to send the 199 reliably. It's only = a > SHOULD. >=20 >=20 > >If 199 is reliable, there is one more advantage. If the 199 arrives > >before the first 18x response, UAC can discard the first 199 and > process > >it until UAC receives the first 18x response that has the same > >to-tag as 199, as the reliable 199 should be re-transmited until > >received PRACK. > > > >If the INVITE contains "Require: 100rel", the first 18x must also be > >sent reliably. And, I don't think the UAS is allowed to send another > >reliable response until the first one is acknowledged, so I don't = think > >a reliable 199 would reach the UAC before the first reliable 18x. > > > >[Eric]: Surely the UAS is allowed to send another reliable response > until the first one is acknowledged, >=20 > If I remember correctly, the FIRST reliable response must be = acknowleded > before the next reliable response is sent. But, we can double check in > the PRACK spec. >=20 > >but reliable 199 will be useful if the first 18x is unreliable, or = the > first 18x has been acknwledged. It's another case different from the > above one whose INVITE contains "require: 100rel". >=20 > If 100rel is required the 18x cannot be unreliable. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=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. >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -------------------------------------------------------- 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. ------_=_NextPart_001_01C998E0.9C0F860C Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Christer,

 

The B2BUA should only send the 199 reliably if the Contact header has been mapped in the = B2BUA.

 

If the B2BUA has not mapped the = Contact then you have a similar problem to that of the proxy. =

 

The B2BUA could of course intercept = the PRACK and send the 200 OK even though the PRACK was addressed to the = Contact provided in the initial response to the = INVITE.

 

To use Paul=A1=AFs words =A8C = =A1=B0ugly=A1=B1.

 

Ian Elz

From: Christer Holmberg
Sent: 27 February 2009 = 06:23
To: wang.libo@zte.com.cn; = Paul Kyzivat
Cc: sip@ietf.org
Subject: Re: [Sip]??: RE: Questions about = "draft-ietf-sip-199-05"

 

Hi,=

  
>Practically, when Call = forward and fork are used in the same system, there are 
>lots of early dialogs that = should be eliminated by 199 existed. 
>So I think that it's useful to let 199 reliable. 
>And we just added = fork-service to our system ,and find 199 is really useful, and 
>if the 199 is missing, problems will happen.  

 

I'm glad you think 199 is useful :)

 

But, if a proxy would have to terminate PRACKs etc it would not be a proxy = anymore - it would be a B2BUA.

 

So, if you really want your network to send 199 reliably, I guess you could use = a B2BUA instead of a proxy.


>It sounds good that there = is a way to prevent PRACK addressed to UAS,but i don't know  how to do now. 

 

The only way to prevent it is by the proxy not sending the = 199 relaible.       
>ps: 
>RFC3261 = 16.7 Response Processing  >Since a proxy may not = insert a tag into the To header field of 
>a 1xx response to a request = that did not contain one, it = cannot 
>issue non-100 provisional responses on its = own.  

 

Yes, but I we have agreed that a proxy is allowed to send = 199.

 

But, the proxy is not going to generate new To header tag values for the 199. It = will use whatever tags that have already been created for the early dialogs. 

 

Regards,

 

Christer

 
 

 

 

 

 

 

 

 

*allowing* (much less *requiring*) the 199 to be reliable = introduces
nasty problems. The 199 is only an = optimization, so having it be
unreliable is ok IMO.

The problem is that if a proxy sends the = 199, then the recipient of the
PRACK should be the proxy. But the PRACK = is an in-dialog message, so it
must be addressed to the Contact of the = UAS.

If the proxy sends a reliable 199, and = the PRACK is addressed to the
UAS, the UAS will be very surprised, = since it has not send a reliable
provisional, and is so not expecting a = PRACK. In fact, it has sent a
final response, has presumably already = received the ACK, and so is
expecting nothing.

Very ugly.

            =     Paul

wang.libo@zte.com.cn = wrote:
>
> Hi,
>
> And there still two questions = left.
>
> 1.  Is the 199 should be = reliable or unreliable?
>     I think that 199 = should be reliable if possible.
>
>
>    First, If a client = receives an unreliable 199 response on a dialog
> which has
>    not previously been = created (this can happen if a 199 response
>    reaches the client = before a 18x response) the client SHALL discard
>    the 199 = responses.
>
>    The figure below shows = an example.The 180 is sent first but arrives
> later than 199.
> If the 199 is reliable, the proxy = should retransmit 199 (step 4),and
> then the = retransmitted
> 199 will be accepted by UAC,and the = early dialog will be teminated.
>
> UAC         =     P
>    1. = INVITE
> --------------->
>           = 2. 180
> <----- \/-------
>        /\ 3. = 199
> <-----/ =  \------
>           = 4. 199(retransmitted)
> <---------------
>
>    second, According to = practical use, 199 can be intended to teminate
> one early dialog and = release
> resources associated with the = specific early dialog, so the cost spent
> on reliable 199 is = worthy.
> If the 199 cannot be sent = reliable,then we should send it unreliable.
>  
> 2. In your last letter, you said = "the second 199 could include
> information which is to be forwarded = to the
> UAC", then do you mean, the = early dialog is still alive after the first
> 199 is accepted?
>
>
> Also, In my last letter, I miss a "NOT" by mistake.
> It should be
> [Eric]: Surely the UAS is NOT = allowed to send another reliable response
> until the first one is = acknowledged...
>
> Regards,
> Eric wang
>
>
>
>
> *"Christer Holmberg" = <christer.holmberg@ericsson.com>*
>
> 2009-02-27 03:04
>
>           =        
> =CA=D5=BC=FE=C8=CB
>           =        "Eric wang" = <eric.wangxr@gmail.com>
> =B3=AD=CB=CD
>           =        <sip@ietf.org>, = <wang.libo@zte.com.cn>
> =D6=F7=CC=E2
>           =        RE: Questions about = "draft-ietf-sip-199-05"
>
>
>           =        
>
>
>
>
>
> Hi,
>
>  >I still have some = difficult in using IETF and cannot find the whole
> sorted comments about this draft, so = i have some doubt about this draft.
>  >
>  >   1.   "If = a forking proxy receives a reliably sent 199 response for a
> dialog, for which the proxy has = previously generated and sent a 199
> response, the proxy MUST forward the = 199 response."
>  >
>  >     Does it = describe the case below? Although P1 have sent a 199
> response, P1 havs to  forword = the send reliably 199 too.Or  is the
> first 199 mistaked for = 18x?
>  >
>  >       =    UAC               P1   =                UAS_2
>  >       =      --- INVITE ------>
>  >       =                       --- = INVITE (leg 2) ->
>  >       =      <-- 199(leg 2) --
>  >       =                       <-- = 199 (leg 2) -----
>  >       =      <-- 199(leg 2) --
>
>  >I think it shall be 199, = as currently written.
>  >
>  >[Eric]: If  this is = 199, then Is there a special purpose to send two
> 199 in the same = dialog?
>  >I think that one 199 is = enough.
>  >And  the first 199 = may be reliable too, that will make it a little
> difficult to send the second = 199.
>
> The second 199 could include = information which is to be forwarded to the
> UAC.
>
>
>  >2.  "10. =  Usage with 100rel
>  >
>  >   When a 199 Early = Dialog Terminated provisional response is sent by a
> UAS, since the provisional response = is only used for information
> purpose, the UAS SHOULD send it = unreliably even if the 100rel
>  >   option tag = [RFC3262] is present in the Require header of the
> associated = request."
>  >
>  >
>  >I have seen a comment on = this question,but still not understood about
>  >it. If the INVITE has a = Require tag "Require: 100rel",does the UAS
> still
>  >use unreliable 199 = response?
>  >
>  >That is the = recommendation, yes. The reasons is that we want to keep
> 199
>  >as "lightweight" = as possible, without requireing re-transmissions and
>  >PRACKs.
>  >
>  >[Eric]: But reliable 199 = have more advantage, and It is worth to use
> the reliable 199,I = think.
>
> I don't know what that advantage = would be, compared to having to send
> PRACKs etc. This has been discussed = quite much, so I would really need
> some good justification to change it = now.
>
> Also, the draft doesn't forbid you = to send the 199 reliably. It's only a
> SHOULD.
>
>
>  >If 199 is reliable, there = is one more advantage. If the 199 arrives
>  >before the first 18x = response, UAC can discard the first 199 and
> process
>  >it until UAC receives the = first 18x response that has the same
>  >to-tag as 199, as the = reliable 199 should be re-transmited until
>  >received = PRACK.
>  >
>  >If the INVITE contains "Require: 100rel", the first 18x must also be
>  >sent reliably. And, I = don't think the UAS is allowed to send another
>  >reliable response until = the first one is acknowledged, so I don't think
>  >a reliable 199 would reach = the UAC before the first reliable 18x.
>  >
>  >[Eric]: Surely the UAS is = allowed to send another reliable response
> until the first one is = acknowledged,
>
> If I remember correctly, the FIRST = reliable response must be acknowleded
> before the next reliable response is = sent. But, we can double check in
> the PRACK spec.
>
>  >but reliable 199 will be = useful if the first 18x is unreliable, or the
> first 18x has been acknwledged. It's = another case different from the
> above one  whose INVITE = contains "require: 100rel".
>
> If 100rel is required the 18x cannot = be unreliable.
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
> --------------------------------------------------------
> 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.
>
>
> = ------------------------------------------------------------------------<= /font>
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of = the core SIP Protocol
> Use sip-implementors@cs.columbia.edu = for questions on current sip
> Use sipping@ietf.org for new = developments on the application of sip

----------------------------------------------=
----------
ZTE Information Security Notice=
: The information contained in this mail&nb=
sp;is solely property of the sender's organ=
ization. This mail communication is confidential=
. Recipients named above are obligated to&n=
bsp;maintain secrecy and are not permitted =
to disclose the contents of this communicat=
ion to others.
This email and any files&n=
bsp;transmitted with it are confidential and&nbs=
p;intended solely for the use of the i=
ndividual or entity to whom they are a=
ddressed. If you have received this email&n=
bsp;in error please notify the originator o=
f the message. Any views expressed in =
this message are those of the individual&nb=
sp;sender.
This message has been scan=
ned for viruses and Spam by ZTE Anti-S=
pam system.
------_=_NextPart_001_01C998E0.9C0F860C-- From alan@sipstation.com Fri Feb 27 08:46:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCCD3A6AD0 for ; Fri, 27 Feb 2009 08:46:53 -0800 (PST) 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 fBZIdlG-F8Fv for ; Fri, 27 Feb 2009 08:46:52 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id C36123A6A10 for ; Fri, 27 Feb 2009 08:46:52 -0800 (PST) Received: from 71-81-68-141.dhcp.stls.mo.charter.com ([71.81.68.141] helo=alan-johnstons-powerbook-g4-17.local) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ld5rm-000F9W-LR; Fri, 27 Feb 2009 16:47:14 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.68.141 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19VXOEzDgVwN8pUsYFJesxMi4HSgSKcUF0= Message-ID: <49A81910.4030604@sipstation.com> Date: Fri, 27 Feb 2009 10:47:12 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: poplarbird References: <49a72f95.9e03be0a.0caf.ffffe479@mx.google.com> In-Reply-To: <49a72f95.9e03be0a.0caf.ffffe479@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] Questions about the status of dual video feature in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 16:46:53 -0000 Hi Yang, Based on a little reading on H.239, it sounds like it is a conference feature set, which would be implemented using SIP, RTP, various SDP extensions for media labeling and grouping, and XCON protocols such as BFCP for floor control and possibly CCMP for conference control. As such, you won't find one document that describes all these protocols, and most of the action happens outside of SIP. If you have trouble finding some of these protocols, let me know. Also, discussion on this would probably be most productive on the XCON list. Thanks, Alan poplarbird wrote: > > Hi All, > > > > I am currently working on the interworking between SIP and H323. > > > > I had difficult in finding the status of SIP supporting dual video > (e.g. H.239 from a H.323 endpoint). > > Are there any drafts or standards working on it? > > > > Also with the text chatting in a SIP call, if anyone can give me the > RFC number that would be great. > > > > Thanks, > > Yang > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From christer.holmberg@ericsson.com Fri Feb 27 11:53:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EBF3A67B1 for ; Fri, 27 Feb 2009 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=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 OzyU-ClVTWR3 for ; Fri, 27 Feb 2009 11:53:27 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5D3963A682C for ; Fri, 27 Feb 2009 11:53:27 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n1RJrB6c017838; Fri, 27 Feb 2009 13:53:39 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 13:51:32 -0600 Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 13:51:31 -0600 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 20:51:10 +0100 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_01C99914.BAED86AA" Date: Fri, 27 Feb 2009 20:51:07 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip]??: RE: Questions about "draft-ietf-sip-199-05" Thread-Index: AcmY4NB5+fRfK7z0SE6ZbyoemxXYEAAM5P8g References: <49A7484B.3060407@cisco.com> From: "Christer Holmberg" To: "Ian Elz" , , "Paul Kyzivat" X-OriginalArrivalTime: 27 Feb 2009 19:51:10.0485 (UTC) FILETIME=[BCED8C50:01C99914] Cc: sip@ietf.org Subject: Re: [Sip] ??: RE: Questions about "draft-ietf-sip-199-05" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:53:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99914.BAED86AA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNCiANCg0KPlRoZSBCMkJVQSBzaG91bGQgb25seSBzZW5kIHRoZSAxOTkgcmVsaWFibHkg aWYgdGhlIENvbnRhY3QgaGVhZGVyIGhhcyBiZWVuIG1hcHBlZCBpbiB0aGUgQjJCVUEuDQoNCj4g DQoNCj5JZiB0aGUgQjJCVUEgaGFzIG5vdCBtYXBwZWQgdGhlIENvbnRhY3QgdGhlbiB5b3UgaGF2 ZSBhIHNpbWlsYXIgcHJvYmxlbSB0byB0aGF0IG9mIHRoZSBwcm94eS4gIA0KDQogDQoNClllcywg SSBndWVzcyBJIGNvdWxkIGhhdmUgY2xhcmlmaWVkIHRoYXQuIE15IHBvaW50IHdhcyB0aGF0IGlm IHlvdSBkbyB3YW50IGEgbmV0d29yayBlbnRpdHkgdG8gc2VuZCB0aGUgMTk5IHJlbGlhYmx5IGl0 IGhhcyB0byBiZSBhIEIyQlVBLiANCg0KIA0KDQo+VGhlIEIyQlVBIGNvdWxkIG9mIGNvdXJzZSBp bnRlcmNlcHQgdGhlIFBSQUNLIGFuZCBzZW5kIHRoZSAyMDAgT0sgZXZlbiB0aG91Z2ggdGhlIFBS QUNLIHdhcyBhZGRyZXNzZWQgdG8gdGhlIENvbnRhY3QgcHJvdmlkZWQgaW4gdGhlIGluaXRpYWwg cmVzcG9uc2UgdG8gdGhlIElOVklURS4gDQoNCiANCg0KU3VyZSwgYnV0IEkgdGhpbmsgdGhlIG91 dGNvbWUgb2YgdGhlIGRpc2N1c3NvbnMgaGFzIGJlZW4gdGhhdCB3ZSBkb24ndCB3YW50IHRvIGRv IHRoYXQuDQoNCiANCg0KQW5kLCBhdCB0aGUgZW5kIG9mIHRoZSBkYXkgcGVvcGxlIGNhbiBpbXBs ZW1lbnQgd2hhdGV2ZXIgdGhleSB3YW50IDopDQoNCiANCg0KUmVnYXJkcywNCg0KIA0KDQpDaHJp c3Rlcg0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IENo cmlzdGVyIEhvbG1iZXJnIA0KU2VudDogMjcgRmVicnVhcnkgMjAwOSAwNjoyMw0KVG86IHdhbmcu bGlib0B6dGUuY29tLmNuOyBQYXVsIEt5eml2YXQNCkNjOiBzaXBAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbU2lwXT8/OiBSRTogUXVlc3Rpb25zIGFib3V0ICJkcmFmdC1pZXRmLXNpcC0xOTktMDUi DQoNCiANCg0KSGksDQoNCiAgDQo+UHJhY3RpY2FsbHksIHdoZW4gQ2FsbCBmb3J3YXJkIGFuZCBm b3JrIGFyZSB1c2VkIGluIHRoZSBzYW1lIHN5c3RlbSwgdGhlcmUgYXJlIA0KPmxvdHMgb2YgZWFy bHkgZGlhbG9ncyB0aGF0IHNob3VsZCBiZSBlbGltaW5hdGVkIGJ5IDE5OSBleGlzdGVkLiANCj5T byBJIHRoaW5rIHRoYXQgaXQncyB1c2VmdWwgdG8gbGV0IDE5OSByZWxpYWJsZS4gDQo+QW5kIHdl IGp1c3QgYWRkZWQgZm9yay1zZXJ2aWNlIHRvIG91ciBzeXN0ZW0gLGFuZCBmaW5kIDE5OSBpcyBy ZWFsbHkgdXNlZnVsLCBhbmQgDQo+aWYgdGhlIDE5OSBpcyBtaXNzaW5nLCBwcm9ibGVtcyB3aWxs IGhhcHBlbi4gIA0KDQogDQoNCkknbSBnbGFkIHlvdSB0aGluayAxOTkgaXMgdXNlZnVsIDopDQoN CiANCg0KQnV0LCBpZiBhIHByb3h5IHdvdWxkIGhhdmUgdG8gdGVybWluYXRlIFBSQUNLcyBldGMg aXQgd291bGQgbm90IGJlIGEgcHJveHkgYW55bW9yZSAtIGl0IHdvdWxkIGJlIGEgQjJCVUEuDQoN CiANCg0KU28sIGlmIHlvdSByZWFsbHkgd2FudCB5b3VyIG5ldHdvcmsgdG8gc2VuZCAxOTkgcmVs aWFibHksIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSBhIEIyQlVBIGluc3RlYWQgb2YgYSBwcm94eS4N Cg0KDQo+SXQgc291bmRzIGdvb2QgdGhhdCB0aGVyZSBpcyBhIHdheSB0byBwcmV2ZW50IFBSQUNL IGFkZHJlc3NlZCB0byBVQVMsYnV0IGkgZG9uJ3Qga25vdyAgaG93IHRvIGRvIG5vdy4gDQoNCiAN Cg0KVGhlIG9ubHkgd2F5IHRvIHByZXZlbnQgaXQgaXMgYnkgdGhlIHByb3h5IG5vdCBzZW5kaW5n IHRoZSAxOTkgcmVsYWlibGUuICANCiAgICANCj5wczogDQo+UkZDMzI2MSAxNi43IFJlc3BvbnNl IFByb2Nlc3NpbmcgDQo+U2luY2UgYSBwcm94eSBtYXkgbm90IGluc2VydCBhIHRhZyBpbnRvIHRo ZSBUbyBoZWFkZXIgZmllbGQgb2YgDQo+YSAxeHggcmVzcG9uc2UgdG8gYSByZXF1ZXN0IHRoYXQg ZGlkIG5vdCBjb250YWluIG9uZSwgaXQgY2Fubm90IA0KPmlzc3VlIG5vbi0xMDAgcHJvdmlzaW9u YWwgcmVzcG9uc2VzIG9uIGl0cyBvd24uICANCg0KIA0KDQpZZXMsIGJ1dCBJIHdlIGhhdmUgYWdy ZWVkIHRoYXQgYSBwcm94eSBpcyBhbGxvd2VkIHRvIHNlbmQgMTk5Lg0KDQogDQoNCkJ1dCwgdGhl IHByb3h5IGlzIG5vdCBnb2luZyB0byBnZW5lcmF0ZSBuZXcgVG8gaGVhZGVyIHRhZyB2YWx1ZXMg Zm9yIHRoZSAxOTkuIEl0IHdpbGwgdXNlIHdoYXRldmVyIHRhZ3MgdGhhdCBoYXZlIGFscmVhZHkg YmVlbiBjcmVhdGVkIGZvciB0aGUgZWFybHkgZGlhbG9ncy4gDQoNCiANCg0KUmVnYXJkcywNCg0K IA0KDQpDaHJpc3Rlcg0KDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQogDQoNCiANCg0KDQoN CiphbGxvd2luZyogKG11Y2ggbGVzcyAqcmVxdWlyaW5nKikgdGhlIDE5OSB0byBiZSByZWxpYWJs ZSBpbnRyb2R1Y2VzDQpuYXN0eSBwcm9ibGVtcy4gVGhlIDE5OSBpcyBvbmx5IGFuIG9wdGltaXph dGlvbiwgc28gaGF2aW5nIGl0IGJlDQp1bnJlbGlhYmxlIGlzIG9rIElNTy4NCg0KVGhlIHByb2Js ZW0gaXMgdGhhdCBpZiBhIHByb3h5IHNlbmRzIHRoZSAxOTksIHRoZW4gdGhlIHJlY2lwaWVudCBv ZiB0aGUNClBSQUNLIHNob3VsZCBiZSB0aGUgcHJveHkuIEJ1dCB0aGUgUFJBQ0sgaXMgYW4gaW4t ZGlhbG9nIG1lc3NhZ2UsIHNvIGl0DQptdXN0IGJlIGFkZHJlc3NlZCB0byB0aGUgQ29udGFjdCBv ZiB0aGUgVUFTLg0KDQpJZiB0aGUgcHJveHkgc2VuZHMgYSByZWxpYWJsZSAxOTksIGFuZCB0aGUg UFJBQ0sgaXMgYWRkcmVzc2VkIHRvIHRoZQ0KVUFTLCB0aGUgVUFTIHdpbGwgYmUgdmVyeSBzdXJw cmlzZWQsIHNpbmNlIGl0IGhhcyBub3Qgc2VuZCBhIHJlbGlhYmxlDQpwcm92aXNpb25hbCwgYW5k IGlzIHNvIG5vdCBleHBlY3RpbmcgYSBQUkFDSy4gSW4gZmFjdCwgaXQgaGFzIHNlbnQgYQ0KZmlu YWwgcmVzcG9uc2UsIGhhcyBwcmVzdW1hYmx5IGFscmVhZHkgcmVjZWl2ZWQgdGhlIEFDSywgYW5k IHNvIGlzDQpleHBlY3Rpbmcgbm90aGluZy4NCg0KVmVyeSB1Z2x5Lg0KDQogICAgICAgICAgICAg ICAgUGF1bA0KDQp3YW5nLmxpYm9AenRlLmNvbS5jbiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4g QW5kIHRoZXJlIHN0aWxsIHR3byBxdWVzdGlvbnMgbGVmdC4NCj4gDQo+IDEuICBJcyB0aGUgMTk5 IHNob3VsZCBiZSByZWxpYWJsZSBvciB1bnJlbGlhYmxlPw0KPiAgICAgSSB0aGluayB0aGF0IDE5 OSBzaG91bGQgYmUgcmVsaWFibGUgaWYgcG9zc2libGUuDQo+IA0KPiANCj4gICAgRmlyc3QsIElm IGEgY2xpZW50IHJlY2VpdmVzIGFuIHVucmVsaWFibGUgMTk5IHJlc3BvbnNlIG9uIGEgZGlhbG9n IA0KPiB3aGljaCBoYXMNCj4gICAgbm90IHByZXZpb3VzbHkgYmVlbiBjcmVhdGVkICh0aGlzIGNh biBoYXBwZW4gaWYgYSAxOTkgcmVzcG9uc2UNCj4gICAgcmVhY2hlcyB0aGUgY2xpZW50IGJlZm9y ZSBhIDE4eCByZXNwb25zZSkgdGhlIGNsaWVudCBTSEFMTCBkaXNjYXJkDQo+ICAgIHRoZSAxOTkg cmVzcG9uc2VzLg0KPiANCj4gICAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlLlRo ZSAxODAgaXMgc2VudCBmaXJzdCBidXQgYXJyaXZlcyANCj4gbGF0ZXIgdGhhbiAxOTkuDQo+IElm IHRoZSAxOTkgaXMgcmVsaWFibGUsIHRoZSBwcm94eSBzaG91bGQgcmV0cmFuc21pdCAxOTkgKHN0 ZXAgNCksYW5kIA0KPiB0aGVuIHRoZSByZXRyYW5zbWl0dGVkDQo+IDE5OSB3aWxsIGJlIGFjY2Vw dGVkIGJ5IFVBQyxhbmQgdGhlIGVhcmx5IGRpYWxvZyB3aWxsIGJlIHRlbWluYXRlZC4NCj4gDQo+ IFVBQyAgICAgICAgICAgICBQDQo+ICAgIDEuIElOVklURQ0KPiAtLS0tLS0tLS0tLS0tLS0+DQo+ ICAgICAgICAgICAyLiAxODANCj4gPC0tLS0tIFwvLS0tLS0tLQ0KPiAgICAgICAgL1wgMy4gMTk5 DQo+IDwtLS0tLS8gIFwtLS0tLS0NCj4gICAgICAgICAgIDQuIDE5OShyZXRyYW5zbWl0dGVkKQ0K PiA8LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAgICBzZWNvbmQsIEFjY29yZGluZyB0byBwcmFjdGlj YWwgdXNlLCAxOTkgY2FuIGJlIGludGVuZGVkIHRvIHRlbWluYXRlIA0KPiBvbmUgZWFybHkgZGlh bG9nIGFuZCByZWxlYXNlDQo+IHJlc291cmNlcyBhc3NvY2lhdGVkIHdpdGggdGhlIHNwZWNpZmlj IGVhcmx5IGRpYWxvZywgc28gdGhlIGNvc3Qgc3BlbnQgDQo+IG9uIHJlbGlhYmxlIDE5OSBpcyB3 b3J0aHkuDQo+IElmIHRoZSAxOTkgY2Fubm90IGJlIHNlbnQgcmVsaWFibGUsdGhlbiB3ZSBzaG91 bGQgc2VuZCBpdCB1bnJlbGlhYmxlLg0KPiAgDQo+IDIuIEluIHlvdXIgbGFzdCBsZXR0ZXIsIHlv dSBzYWlkICJ0aGUgc2Vjb25kIDE5OSBjb3VsZCBpbmNsdWRlIA0KPiBpbmZvcm1hdGlvbiB3aGlj aCBpcyB0byBiZSBmb3J3YXJkZWQgdG8gdGhlDQo+IFVBQyIsIHRoZW4gZG8geW91IG1lYW4sIHRo ZSBlYXJseSBkaWFsb2cgaXMgc3RpbGwgYWxpdmUgYWZ0ZXIgdGhlIGZpcnN0IA0KPiAxOTkgaXMg YWNjZXB0ZWQ/DQo+IA0KPiANCj4gQWxzbywgSW4gbXkgbGFzdCBsZXR0ZXIsIEkgbWlzcyBhICJO T1QiIGJ5IG1pc3Rha2UuDQo+IEl0IHNob3VsZCBiZQ0KPiBbRXJpY106IFN1cmVseSB0aGUgVUFT IGlzIE5PVCBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlciByZWxpYWJsZSByZXNwb25zZQ0KPiB1bnRp bCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZC4uLg0KPiANCj4gUmVnYXJkcywNCj4gRXJp YyB3YW5nDQo+IA0KPiANCj4gDQo+IA0KPiAqIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPioNCj4gDQo+IDIwMDktMDItMjcgMDM6MDQNCj4gDQo+ICAg ICAgICAgICAgICAgICAgDQo+IOaUtuS7tuS6ug0KPiAgICAgICAgICAgICAgICAgICJFcmljIHdh bmciIDxlcmljLndhbmd4ckBnbWFpbC5jb20+DQo+IOaKhOmAgQ0KPiAgICAgICAgICAgICAgICAg IDxzaXBAaWV0Zi5vcmc+LCA8d2FuZy5saWJvQHp0ZS5jb20uY24+DQo+IOS4u+mimA0KPiAgICAg ICAgICAgICAgICAgIFJFOiBRdWVzdGlvbnMgYWJvdXQgImRyYWZ0LWlldGYtc2lwLTE5OS0wNSIN Cj4gDQo+IA0KPiAgICAgICAgICAgICAgICAgIA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEhpLA0K PiANCj4gID5JIHN0aWxsIGhhdmUgc29tZSBkaWZmaWN1bHQgaW4gdXNpbmcgSUVURiBhbmQgY2Fu bm90IGZpbmQgdGhlIHdob2xlDQo+IHNvcnRlZCBjb21tZW50cyBhYm91dCB0aGlzIGRyYWZ0LCBz byBpIGhhdmUgc29tZSBkb3VidCBhYm91dCB0aGlzIGRyYWZ0Lg0KPiAgPg0KPiAgPiAgIDEuICAg IklmIGEgZm9ya2luZyBwcm94eSByZWNlaXZlcyBhIHJlbGlhYmx5IHNlbnQgMTk5IHJlc3BvbnNl IGZvciBhDQo+IGRpYWxvZywgZm9yIHdoaWNoIHRoZSBwcm94eSBoYXMgcHJldmlvdXNseSBnZW5l cmF0ZWQgYW5kIHNlbnQgYSAxOTkNCj4gcmVzcG9uc2UsIHRoZSBwcm94eSBNVVNUIGZvcndhcmQg dGhlIDE5OSByZXNwb25zZS4iDQo+ICA+DQo+ICA+ICAgICBEb2VzIGl0IGRlc2NyaWJlIHRoZSBj YXNlIGJlbG93PyBBbHRob3VnaCBQMSBoYXZlIHNlbnQgYSAxOTkNCj4gcmVzcG9uc2UsIFAxIGhh dnMgdG8gIGZvcndvcmQgdGhlIHNlbmQgcmVsaWFibHkgMTk5IHRvby5PciAgaXMgdGhlDQo+IGZp cnN0IDE5OSBtaXN0YWtlZCBmb3IgMTh4Pw0KPiAgPg0KPiAgPiAgICAgICAgICBVQUMgICAgICAg ICAgICAgICBQMSAgICAgICAgICAgICAgICAgIFVBU18yDQo+ICA+ICAgICAgICAgICAgLS0tIElO VklURSAtLS0tLS0+DQo+ICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0gSU5WSVRF IChsZWcgMikgLT4NCj4gID4gICAgICAgICAgICA8LS0gMTk5KGxlZyAyKSAtLQ0KPiAgPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC0tIDE5OSAobGVnIDIpIC0tLS0tDQo+ICA+ICAgICAg ICAgICAgPC0tIDE5OShsZWcgMikgLS0NCj4gDQo+ICA+SSB0aGluayBpdCBzaGFsbCBiZSAxOTks IGFzIGN1cnJlbnRseSB3cml0dGVuLg0KPiAgPg0KPiAgPltFcmljXTogSWYgIHRoaXMgaXMgMTk5 LCB0aGVuIElzIHRoZXJlIGEgc3BlY2lhbCBwdXJwb3NlIHRvIHNlbmQgdHdvDQo+IDE5OSBpbiB0 aGUgc2FtZSBkaWFsb2c/DQo+ICA+SSB0aGluayB0aGF0IG9uZSAxOTkgaXMgZW5vdWdoLg0KPiAg PkFuZCAgdGhlIGZpcnN0IDE5OSBtYXkgYmUgcmVsaWFibGUgdG9vLCB0aGF0IHdpbGwgbWFrZSBp dCBhIGxpdHRsZQ0KPiBkaWZmaWN1bHQgdG8gc2VuZCB0aGUgc2Vjb25kIDE5OS4NCj4gDQo+IFRo ZSBzZWNvbmQgMTk5IGNvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gd2hpY2ggaXMgdG8gYmUgZm9y d2FyZGVkIHRvIHRoZQ0KPiBVQUMuDQo+IA0KPiANCj4gID4yLiAgIjEwLiAgVXNhZ2Ugd2l0aCAx MDByZWwNCj4gID4NCj4gID4gICBXaGVuIGEgMTk5IEVhcmx5IERpYWxvZyBUZXJtaW5hdGVkIHBy b3Zpc2lvbmFsIHJlc3BvbnNlIGlzIHNlbnQgYnkgYQ0KPiBVQVMsIHNpbmNlIHRoZSBwcm92aXNp b25hbCByZXNwb25zZSBpcyBvbmx5IHVzZWQgZm9yIGluZm9ybWF0aW9uDQo+IHB1cnBvc2UsIHRo ZSBVQVMgU0hPVUxEIHNlbmQgaXQgdW5yZWxpYWJseSBldmVuIGlmIHRoZSAxMDByZWwNCj4gID4g ICBvcHRpb24gdGFnIFtSRkMzMjYyXSBpcyBwcmVzZW50IGluIHRoZSBSZXF1aXJlIGhlYWRlciBv ZiB0aGUNCj4gYXNzb2NpYXRlZCByZXF1ZXN0LiINCj4gID4NCj4gID4NCj4gID5JIGhhdmUgc2Vl biBhIGNvbW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQgc3RpbGwgbm90IHVuZGVyc3Rvb2QgYWJv dXQNCj4gID5pdC4gSWYgdGhlIElOVklURSBoYXMgYSBSZXF1aXJlIHRhZyAiUmVxdWlyZTogMTAw cmVsIixkb2VzIHRoZSBVQVMNCj4gc3RpbGwNCj4gID51c2UgdW5yZWxpYWJsZSAxOTkgcmVzcG9u c2U/DQo+ICA+DQo+ICA+VGhhdCBpcyB0aGUgcmVjb21tZW5kYXRpb24sIHllcy4gVGhlIHJlYXNv bnMgaXMgdGhhdCB3ZSB3YW50IHRvIGtlZXANCj4gMTk5DQo+ICA+YXMgImxpZ2h0d2VpZ2h0IiBh cyBwb3NzaWJsZSwgd2l0aG91dCByZXF1aXJlaW5nIHJlLXRyYW5zbWlzc2lvbnMgYW5kDQo+ICA+ UFJBQ0tzLg0KPiAgPg0KPiAgPltFcmljXTogQnV0IHJlbGlhYmxlIDE5OSBoYXZlIG1vcmUgYWR2 YW50YWdlLCBhbmQgSXQgaXMgd29ydGggdG8gdXNlDQo+IHRoZSByZWxpYWJsZSAxOTksSSB0aGlu ay4NCj4gDQo+IEkgZG9uJ3Qga25vdyB3aGF0IHRoYXQgYWR2YW50YWdlIHdvdWxkIGJlLCBjb21w YXJlZCB0byBoYXZpbmcgdG8gc2VuZA0KPiBQUkFDS3MgZXRjLiBUaGlzIGhhcyBiZWVuIGRpc2N1 c3NlZCBxdWl0ZSBtdWNoLCBzbyBJIHdvdWxkIHJlYWxseSBuZWVkDQo+IHNvbWUgZ29vZCBqdXN0 aWZpY2F0aW9uIHRvIGNoYW5nZSBpdCBub3cuDQo+IA0KPiBBbHNvLCB0aGUgZHJhZnQgZG9lc24n dCBmb3JiaWQgeW91IHRvIHNlbmQgdGhlIDE5OSByZWxpYWJseS4gSXQncyBvbmx5IGENCj4gU0hP VUxELg0KPiANCj4gDQo+ICA+SWYgMTk5IGlzIHJlbGlhYmxlLCB0aGVyZSBpcyBvbmUgbW9yZSBh ZHZhbnRhZ2UuIElmIHRoZSAxOTkgYXJyaXZlcw0KPiAgPmJlZm9yZSB0aGUgZmlyc3QgMTh4IHJl c3BvbnNlLCBVQUMgY2FuIGRpc2NhcmQgdGhlIGZpcnN0IDE5OSBhbmQNCj4gcHJvY2Vzcw0KPiAg Pml0IHVudGlsIFVBQyByZWNlaXZlcyB0aGUgZmlyc3QgMTh4IHJlc3BvbnNlIHRoYXQgaGFzIHRo ZSBzYW1lDQo+ICA+dG8tdGFnIGFzIDE5OSwgYXMgdGhlIHJlbGlhYmxlIDE5OSBzaG91bGQgYmUg cmUtdHJhbnNtaXRlZCB1bnRpbA0KPiAgPnJlY2VpdmVkIFBSQUNLLg0KPiAgPg0KPiAgPklmIHRo ZSBJTlZJVEUgY29udGFpbnMgIlJlcXVpcmU6IDEwMHJlbCIsIHRoZSBmaXJzdCAxOHggbXVzdCBh bHNvIGJlDQo+ICA+c2VudCByZWxpYWJseS4gQW5kLCBJIGRvbid0IHRoaW5rIHRoZSBVQVMgaXMg YWxsb3dlZCB0byBzZW5kIGFub3RoZXINCj4gID5yZWxpYWJsZSByZXNwb25zZSB1bnRpbCB0aGUg Zmlyc3Qgb25lIGlzIGFja25vd2xlZGdlZCwgc28gSSBkb24ndCB0aGluaw0KPiAgPmEgcmVsaWFi bGUgMTk5IHdvdWxkIHJlYWNoIHRoZSBVQUMgYmVmb3JlIHRoZSBmaXJzdCByZWxpYWJsZSAxOHgu DQo+ICA+DQo+ICA+W0VyaWNdOiBTdXJlbHkgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5v dGhlciByZWxpYWJsZSByZXNwb25zZQ0KPiB1bnRpbCB0aGUgZmlyc3Qgb25lIGlzIGFja25vd2xl ZGdlZCwNCj4gDQo+IElmIEkgcmVtZW1iZXIgY29ycmVjdGx5LCB0aGUgRklSU1QgcmVsaWFibGUg cmVzcG9uc2UgbXVzdCBiZSBhY2tub3dsZWRlZA0KPiBiZWZvcmUgdGhlIG5leHQgcmVsaWFibGUg cmVzcG9uc2UgaXMgc2VudC4gQnV0LCB3ZSBjYW4gZG91YmxlIGNoZWNrIGluDQo+IHRoZSBQUkFD SyBzcGVjLg0KPiANCj4gID5idXQgcmVsaWFibGUgMTk5IHdpbGwgYmUgdXNlZnVsIGlmIHRoZSBm aXJzdCAxOHggaXMgdW5yZWxpYWJsZSwgb3IgdGhlDQo+IGZpcnN0IDE4eCBoYXMgYmVlbiBhY2tu d2xlZGdlZC4gSXQncyBhbm90aGVyIGNhc2UgZGlmZmVyZW50IGZyb20gdGhlDQo+IGFib3ZlIG9u ZSAgd2hvc2UgSU5WSVRFIGNvbnRhaW5zICJyZXF1aXJlOiAxMDByZWwiLg0KPiANCj4gSWYgMTAw cmVsIGlzIHJlcXVpcmVkIHRoZSAxOHggY2Fubm90IGJlIHVucmVsaWFibGUuDQo+IA0KPiBSZWdh cmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJl c3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90 aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGlu IHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlz IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50 aS1TcGFtIHN5c3RlbS4NCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNpcCBtYWlsaW5nIGxp c3QgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQo+IFRoaXMgbGlz dCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KPiBVc2Ug c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50 IHNpcA0KPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUg YXBwbGljYXRpb24gb2Ygc2lwDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3Bl cnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9u IGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBj b250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= ------_=_NextPart_001_01C99914.BAED86AA Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zOnYgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm8gPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHht bG5zOncgPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpz dDEgPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFE Pg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFy c2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjM3OTAuNDQyNiIgbmFtZT1H RU5FUkFUT1I+PCEtLVtpZiAhbXNvXT4NCjxTVFlMRT52XDoqIHsNCglCRUhBVklPUjogdXJsKCNk ZWZhdWx0I1ZNTCkNCn0NCm9cOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0K d1w6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQouc2hhcGUgew0KCUJFSEFW SU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPjxvOlNtYXJ0 VGFnVHlwZSBuYW1lPSJQZXJzb25OYW1lIiANCm5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48L286U21hcnRUYWdUeXBlPjwhLS1baWYgIW1z b10+DQo8U1RZTEU+c3QxXDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I2llb291aSkNCn0N CjwvU1RZTEU+DQo8IVtlbmRpZl0tLT4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250LWZhbWls eTogTVMgTWluY2hvOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFNpbVN1bjsNCn0N CkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBUYWhvbWE7DQp9DQpAZm9udC1mYWNlIHsNCglm b250LWZhbWlseTogQE1TIE1pbmNobzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA U2ltU3VuOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7DQp9DQpA cGFnZSBTZWN0aW9uMSB7c2l6ZTogNjEyLjBwdCA3OTIuMHB0OyBtYXJnaW46IDcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpMSS5N c29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1G QU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpESVYuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6 IDEycHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFu Ig0KfQ0KSDQgew0KCUZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDE0cHQ7IE1BUkdJTjog MTJwdCAwY20gM3B0IDEyNy41NXB0OyBURVhULUlOREVOVDogLTY1LjJwdDsgRk9OVC1GQU1JTFk6 ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tbGlzdDogbDAgbGV2ZWw0IGxmbzMNCn0NCkg1IHsNCglG T05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6IDExcHQ7IE1BUkdJTjogMTJwdCAwY20gM3B0 OyBURVhULUlOREVOVDogMGNtOyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1saXN0OiBsMCBsZXZl bDYgbGZvMw0KfQ0KSDYgew0KCUZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogMTFwdDsg TUFSR0lOOiAxMnB0IDBjbSAzcHQgMjkxLjRwdDsgVEVYVC1JTkRFTlQ6IC0xOS44cHQ7IExJTkUt SEVJR0hUOiAxMnB0OyBGT05ULVNUWUxFOiBpdGFsaWM7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3 IFJvbWFuIjsgbXNvLWxpc3Q6IGwxIGxldmVsMSBsZm80DQp9DQpQLk1zb0JvZHlUZXh0IHsNCglG T05ULVNJWkU6IDExcHQ7IE1BUkdJTjogMTJwdCAwY20gMHB0IDEyNy42cHQ7IExJTkUtSEVJR0hU OiAxOHB0OyBGT05ULUZBTUlMWTogQXJpYWw7IFRFWFQtQUxJR046IGp1c3RpZnkNCn0NCkxJLk1z b0JvZHlUZXh0IHsNCglGT05ULVNJWkU6IDExcHQ7IE1BUkdJTjogMTJwdCAwY20gMHB0IDEyNy42 cHQ7IExJTkUtSEVJR0hUOiAxOHB0OyBGT05ULUZBTUlMWTogQXJpYWw7IFRFWFQtQUxJR046IGp1 c3RpZnkNCn0NCkRJVi5Nc29Cb2R5VGV4dCB7DQoJRk9OVC1TSVpFOiAxMXB0OyBNQVJHSU46IDEy cHQgMGNtIDBwdCAxMjcuNnB0OyBMSU5FLUhFSUdIVDogMThwdDsgRk9OVC1GQU1JTFk6IEFyaWFs OyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURF Q09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVy cGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xs b3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClAg ew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOLUxFRlQ6IDBjbTsgTUFSR0lOLVJJR0hUOiAwY207 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRv OyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8NCn0NClBSRSB7DQoJRk9OVC1TSVpFOiAxMHB0 OyBNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIkNvdXJpZXIgTmV3Ig0KfQ0KVFQg ew0KCUZPTlQtRkFNSUxZOiAiQ291cmllciBOZXciDQp9DQpTUEFOLkVtYWlsU3R5bGUyMCB7DQoJ Q09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFs LXJlcGx5DQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQpPTCB7DQoJTUFS R0lOLUJPVFRPTTogMGNtDQp9DQpVTCB7DQoJTUFSR0lOLUJPVFRPTTogMGNtDQp9DQo8L1NUWUxF Pg0KPC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1VUyB2TGluaz1wdXJwbGUgbGluaz1ibHVlPg0KPERJ ViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9 Mj48U1BBTiANCmNsYXNzPTA3MzQyNDgxOS0yNzAyMjAwOT5IaSw8L1NQQU4+PC9GT05UPjwvRElW Pg0KPERJViBjbGFzcz1TZWN0aW9uMT4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9G T05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xvcj1uYXZ5PjxTUEFOIA0Kc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PFNQ QU4gDQpjbGFzcz0wNzM0MjQ4MTktMjcwMjIwMDk+PEZPTlQgY29sb3I9IzAwMDBmZj4mZ3Q7PC9G T05UPjwvU1BBTj5UaGUgQjJCVUEgc2hvdWxkIA0Kb25seSBzZW5kIHRoZSAxOTkgcmVsaWFibHkg aWYgdGhlIENvbnRhY3QgaGVhZGVyIGhhcyBiZWVuIG1hcHBlZCBpbiB0aGUgDQpCMkJVQS48bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGNvbG9y PW5hdnk+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1G QU1JTFk6IEFyaWFsIj48bzpwPjxTUEFOIA0KY2xhc3M9MDczNDI0ODE5LTI3MDIyMDA5PjxGT05U IA0KY29sb3I9IzAwMDBmZj4mZ3Q7PC9GT05UPjwvU1BBTj4mbmJzcDs8L286cD48L1NQQU4+PC9G T05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xvcj1uYXZ5PjxTUEFOIA0Kc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PFNQ QU4gDQpjbGFzcz0wNzM0MjQ4MTktMjcwMjIwMDk+PEZPTlQgY29sb3I9IzAwMDBmZj4mZ3Q7PC9G T05UPjwvU1BBTj5JZiB0aGUgQjJCVUEgaGFzIA0Kbm90IG1hcHBlZCB0aGUgQ29udGFjdCB0aGVu IHlvdSBoYXZlIGEgc2ltaWxhciBwcm9ibGVtIHRvIHRoYXQgb2YgdGhlIA0KcHJveHkuJm5ic3A7 PEZPTlQgY29sb3I9IzAwMDBmZj48U1BBTiANCmNsYXNzPTA3MzQyNDgxOS0yNzAyMjAwOT4mbmJz cDs8L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGNvbG9yPW5hdnk+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2 eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48Rk9OVCANCmNvbG9yPSMwMDAwZmY+PFNQQU4gDQpjbGFz cz0wNzM0MjQ4MTktMjcwMjIwMDk+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPiZuYnNwOzwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xvcj1uYXZ5PjxTUEFOIA0Kc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZPTlQgDQpj b2xvcj0jMDAwMGZmPjxTUEFOIGNsYXNzPTA3MzQyNDgxOS0yNzAyMjAwOT5ZZXMsIEkgZ3Vlc3Mg SSBjb3VsZCBoYXZlIGNsYXJpZmllZCANCnRoYXQuIE15IHBvaW50IHdhcyB0aGF0IGlmIHlvdSBk byB3YW50Jm5ic3A7YSBuZXR3b3JrIGVudGl0eSB0byBzZW5kIHRoZSAxOTkgDQpyZWxpYWJseSBp dCBoYXMgdG8gYmUgYSBCMkJVQS4mbmJzcDs8L1NQQU4+PG86cD48L286cD48L0ZPTlQ+PC9TUEFO PjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1u YXZ5IHNpemU9Mj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBG T05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgY29sb3I9bmF2eT48U1BBTiANCnN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxTUEFOIA0KY2xhc3M9 MDczNDI0ODE5LTI3MDIyMDA5PjxGT05UIGNvbG9yPSMwMDAwZmY+Jmd0OzwvRk9OVD48L1NQQU4+ VGhlIEIyQlVBIGNvdWxkIA0Kb2YgY291cnNlIGludGVyY2VwdCB0aGUgUFJBQ0sgYW5kIHNlbmQg dGhlIDIwMCBPSyBldmVuIHRob3VnaCB0aGUgUFJBQ0sgd2FzIA0KYWRkcmVzc2VkIHRvIHRoZSBD b250YWN0IHByb3ZpZGVkIGluIHRoZSBpbml0aWFsIHJlc3BvbnNlIHRvIHRoZSBJTlZJVEUuPEZP TlQgDQpjb2xvcj0jMDAwMGZmPjxTUEFOIA0KY2xhc3M9MDczNDI0ODE5LTI3MDIyMDA5PiZuYnNw OzwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgY29sb3I9bmF2eT48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5 OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KY29sb3I9IzAwMDBmZj48U1BBTiANCmNsYXNz PTA3MzQyNDgxOS0yNzAyMjAwOT48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGNvbG9yPW5hdnk+PFNQQU4gDQpzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48Rk9OVCANCmNv bG9yPSMwMDAwZmY+PFNQQU4gY2xhc3M9MDczNDI0ODE5LTI3MDIyMDA5PlN1cmUsIGJ1dCBJIHRo aW5rIHRoZSBvdXRjb21lIG9mIA0KdGhlIGRpc2N1c3NvbnMgaGFzIGJlZW4gdGhhdCB3ZSBkb24n dCB3YW50IHRvIGRvIA0KdGhhdC48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGNvbG9yPW5hdnk+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48Rk9OVCANCmNvbG9yPSMw MDAwZmY+PFNQQU4gDQpjbGFzcz0wNzM0MjQ4MTktMjcwMjIwMDk+PC9TUEFOPjwvRk9OVD48L1NQ QU4+PC9GT05UPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xvcj1uYXZ5 PjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPjxTUEFOIGNsYXNzPTA3MzQyNDgxOS0yNzAy MjAwOT5BbmQsIGF0Jm5ic3A7dGhlIGVuZCBvZiB0aGUgDQpkYXkmbmJzcDtwZW9wbGUgY2FuIGlt cGxlbWVudCB3aGF0ZXZlciB0aGV5IHdhbnQgDQo6KTwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRk9O VD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgY29sb3I9bmF2eT48U1BBTiANCnN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05U IA0KY29sb3I9IzAwMDBmZj48U1BBTiANCmNsYXNzPTA3MzQyNDgxOS0yNzAyMjAwOT48L1NQQU4+ PC9GT05UPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGNvbG9yPW5hdnk+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj48Rk9OVCANCmNvbG9yPSMwMDAwZmY+PFNQQU4gDQpjbGFzcz0w NzM0MjQ4MTktMjcwMjIwMDk+UmVnYXJkcyw8L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGNvbG9yPW5hdnk+PFNQQU4gDQpzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48Rk9OVCANCmNv bG9yPSMwMDAwZmY+PFNQQU4gDQpjbGFzcz0wNzM0MjQ4MTktMjcwMjIwMDk+PC9TUEFOPjwvRk9O VD48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xv cj1uYXZ5PjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQt RkFNSUxZOiBBcmlhbCI+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPjxTUEFOIA0KY2xhc3M9MDczNDI0 ODE5LTI3MDIyMDA5PkNocmlzdGVyPC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvUD4NCjxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBjb2xvcj1uYXZ5PjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZPTlQgDQpjb2xvcj0j MDAwMGZmPjxTUEFOIA0KY2xhc3M9MDczNDI0ODE5LTI3MDIyMDA5PiZuYnNwOzwvU1BBTj48bzpw PjwvbzpwPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvUD4NCjxESVY+DQo8RElWIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQ7IFRFWFQtQUxJR046IGNlbnRlciIgDQphbGln bj1jZW50ZXI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTJwdCI+DQo8SFIgdGFiSW5kZXg9LTEgYWxpZ249Y2VudGVyIHdpZHRoPSIx MDAlIiBTSVpFPTI+DQo8L1NQQU4+PC9GT05UPjwvRElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEI+PEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFO IA0Kc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBUYWhvbWEiPkZyb206PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQpmYWNlPVRhaG9tYSBzaXpl PTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+IA0K PHN0MTpQZXJzb25OYW1lIHc6c3Q9Im9uIj5DaHJpc3RlciBIb2xtYmVyZzwvc3QxOlBlcnNvbk5h bWU+IDxCUj48Qj48U1BBTiANCnN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U2VudDo8L1NQQU4+ PC9CPiAyNyBGZWJydWFyeSAyMDA5IDA2OjIzPEJSPjxCPjxTUEFOIA0Kc3R5bGU9IkZPTlQtV0VJ R0hUOiBib2xkIj5Ubzo8L1NQQU4+PC9CPiB3YW5nLmxpYm9AenRlLmNvbS5jbjsgUGF1bCANCkt5 eml2YXQ8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DYzo8L1NQQU4+PC9C PiANCnNpcEBpZXRmLm9yZzxCUj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlN1 YmplY3Q6PC9TUEFOPjwvQj4gUmU6IA0KW1NpcF0/PzogUkU6IFF1ZXN0aW9ucyBhYm91dCANCiJk cmFmdC1pZXRmLXNpcC0xOTktMDUiPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4N CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSANCnNp emU9Mj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZB TUlMWTogQXJpYWwiPkhpLDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQo8RElWPg0KPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDs8L1NQQU4+PC9GT05UPjxCUj48Rk9OVCANCmZhY2U9 QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPiZndDs8L1NQQU4+PC9GT05UPjxGT05U IA0KZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IEFyaWFsIj5QcmFjdGljYWxseSwgDQp3aGVuIENhbGwgZm9yd2FyZCBhbmQgZm9yayBh cmUgdXNlZCBpbiB0aGUgc2FtZSBzeXN0ZW0sIHRoZXJlIA0KYXJlJm5ic3A7PC9TUEFOPjwvRk9O VD48QlI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jmd0Ozwv U1BBTj48L0ZPTlQ+PEZPTlQgDQpmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPmxvdHMgb2YgDQplYXJseSBkaWFsb2dzIHRo YXQgc2hvdWxkIGJlIGVsaW1pbmF0ZWQgYnkgMTk5IA0KZXhpc3RlZC48L1NQQU4+PC9GT05UPiZu YnNwOzxCUj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrPjxTUEFOIA0Kc3R5bGU9IkNPTE9S OiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mZ3Q7PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNl PUFyaWFsIA0Kc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+U28gSSB0aGluayB0aGF0IGl0J3MgDQp1c2VmdWwgdG8gbGV0IDE5OSByZWxpYWJs ZS4mbmJzcDs8L1NQQU4+PC9GT05UPjxCUj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIA0K c2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05U LUZBTUlMWTogQXJpYWwiPiZndDs8L1NQQU4+PC9GT05UPjxGT05UIA0KZmFjZT1BcmlhbCBzaXpl PTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5BbmQg d2UganVzdCANCmFkZGVkIGZvcmstc2VydmljZSB0byBvdXIgc3lzdGVtICxhbmQgZmluZCAxOTkg aXMgcmVhbGx5IHVzZWZ1bCwgDQphbmQ8L1NQQU4+PC9GT05UPiZuYnNwOzxCUj48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPWJsYWNrPjxTUEFOIA0Kc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1GQU1J TFk6IEFyaWFsIj4mZ3Q7PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjxT UEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+aWYgdGhlIDE5 OSBpcyBtaXNzaW5nLCANCnByb2JsZW1zIHdpbGwgaGFwcGVuLjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIA0Kc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7PC9TUEFO PjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0K c2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIA0Kc2l6ZT0yPjxT UEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJp YWwiPkknbSBnbGFkIA0KeW91IHRoaW5rIDE5OSBpcyB1c2VmdWwgOik8L1NQQU4+PC9GT05UPjxv OnA+PC9vOnA+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+PFNQ QU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05U PjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZU OiAzNnB0Ij48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgDQpzaXplPTI+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QnV0LCBp ZiBhIA0KcHJveHkgd291bGQgaGF2ZSB0byB0ZXJtaW5hdGUgUFJBQ0tzIGV0YyBpdCB3b3VsZCBu b3QgYmUgYSBwcm94eSBhbnltb3JlIC0gaXQgDQp3b3VsZCBiZSBhIEIyQlVBLjwvU1BBTj48L0ZP TlQ+PG86cD48L286cD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCnNpemU9 Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO LUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSANCnNpemU9Mj48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5T bywgaWYgeW91IA0KcmVhbGx5IHdhbnQgeW91ciBuZXR3b3JrIHRvIHNlbmQgMTk5IHJlbGlhYmx5 LCBJIGd1ZXNzIHlvdSBjb3VsZCB1c2UgYSBCMkJVQSANCmluc3RlYWQgb2YgYSBwcm94eS48L1NQ QU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg DQpzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEJSPjwvU1BBTj48L0ZPTlQ+ PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jmd0OzwvU1BBTj48 L0ZPTlQ+PEZPTlQgDQpmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkl0IHNvdW5kcyANCmdvb2QgdGhhdCB0aGVyZSBpcyBh IHdheSB0byBwcmV2ZW50IFBSQUNLIGFkZHJlc3NlZCB0byBVQVMsYnV0IGkgZG9uJ3Qga25vdzxG T05UIA0KY29sb3I9Ymx1ZT48U1BBTiBzdHlsZT0iQ09MT1I6IGJsdWUiPiZuYnNwOyA8L1NQQU4+ PC9GT05UPmhvdyB0byBkbyBub3cuPEZPTlQgDQpjb2xvcj1ibHVlPjxTUEFOIA0Kc3R5bGU9IkNP TE9SOiBibHVlIj4mbmJzcDs8L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48 L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDog MzZwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCnNpemU9Mz48U1BBTiBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElW Pg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSANCnNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGUgb25seSANCndheSB0 byBwcmV2ZW50IGl0IGlzIGJ5IHRoZSBwcm94eSBub3Qgc2VuZGluZyB0aGUgDQoxOTkmbmJzcDty ZWxhaWJsZS48L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0Kc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8L1NQQU4+PC9G T05UPiZuYnNwOzxCUj48Rk9OVCANCmZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gDQpzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7PC9TUEFOPjwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgDQpjb2xvcj1ibGFjaz48U1BBTiBz dHlsZT0iQ09MT1I6IGJsYWNrIj4mZ3Q7PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIA0K c2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFs Ij5wczo8L1NQQU4+PC9GT05UPiZuYnNwOzxCUj48Rk9OVCANCmNvbG9yPWJsYWNrPjxTUEFOIHN0 eWxlPSJDT0xPUjogYmxhY2siPiZndDs8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgDQpz aXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5S RkMzMjYxIA0KPC9TUEFOPjwvRk9OVD48Qj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgY29sb3I9 IzAwMjA0MSBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0la RTogMTBwdDsgQ09MT1I6ICMwMDIwNDE7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4xNi43 IA0KUmVzcG9uc2UgUHJvY2Vzc2luZzwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48QlI+PEZPTlQgDQpmYWNlPUFyaWFsIGNv bG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBi bGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mZ3Q7PC9TUEFOPjwvRk9OVD48Rk9OVCANCmZhY2U9 QXJpYWwgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBB cmlhbCI+U2luY2UgYSANCnByb3h5IG1heSBub3QgaW5zZXJ0IGEgdGFnIGludG8gdGhlIFRvIGhl YWRlciBmaWVsZCANCm9mPC9TUEFOPjwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBi bHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPiZndDs8L1NQQU4+PC9GT05UPjxGT05UIA0KZmFjZT1B cmlhbCBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFy aWFsIj5hIDF4eCANCnJlc3BvbnNlIHRvIGEgcmVxdWVzdCB0aGF0IGRpZCBub3QgY29udGFpbiBv bmUsIDxGT05UIGNvbG9yPWJsdWU+PFNQQU4gDQpzdHlsZT0iQ09MT1I6IGJsdWUiPml0IGNhbm5v dDwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgDQpjb2xvcj1ibGFj az48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrIj4mZ3Q7PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNl PUFyaWFsIA0KY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5pc3N1ZSBub24tMTAwIA0KcHJvdmlz aW9uYWwgcmVzcG9uc2VzIG9uIGl0cyBvd24uPC9TUEFOPjwvRk9OVD4mbmJzcDs8Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPWJsdWUgDQpzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxv OnA+PC9vOnA+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+PFNQ QU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05U PjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZU OiAzNnB0Ij48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgDQpzaXplPTI+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+WWVzLCBi dXQgDQpJJm5ic3A7d2UgaGF2ZSBhZ3JlZWQgdGhhdCBhIHByb3h5IGlzIGFsbG93ZWQgdG8gc2Vu ZCANCjE5OS48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgDQpzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7 PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJs dWUgDQpzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZP TlQtRkFNSUxZOiBBcmlhbCI+QnV0LCB0aGUgDQpwcm94eSBpcyBub3QgZ29pbmcgdG8gZ2VuZXJh dGUgbmV3IFRvIGhlYWRlciB0YWcgdmFsdWVzIGZvciB0aGUgMTk5LiBJdCB3aWxsIHVzZSANCndo YXRldmVyIHRhZ3MgdGhhdCBoYXZlIGFscmVhZHkmbmJzcDtiZWVuIGNyZWF0ZWQgZm9yIHRoZSZu YnNwO2Vhcmx5IA0KZGlhbG9ncy48L1NQQU4+PC9GT05UPiZuYnNwOzxvOnA+PC9vOnA+PC9QPjwv RElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQi PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSANCnNpemU9Mj48U1BBTiANCnN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNwOzwvU1BB Tj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIA0K c2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQt RkFNSUxZOiBBcmlhbCI+UmVnYXJkcyw8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElW Pg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCjxESVY+ DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPWJsdWUgDQpzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5DaHJpc3RlcjwvU1BBTj48L0ZPTlQ+ PG86cD48L286cD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCnNpemU9Mz48 U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48QlI+PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNl PUFyaWFsIA0KY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxv OnA+PC9vOnA+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+PFNQ QU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05U PjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZU OiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0Kc2l6ZT0zPjxTUEFOIHN0eWxl PSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9E SVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCnNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KPERJ Vj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCjxESVY+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIA0Kc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiANCnNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCAN CnN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0OyBNQVJHSU4tTEVGVDogMzZwdDsgTUFSR0lOLVJJ R0hUOiAwY207IG1zby1tYXJnaW4tdG9wLWFsdDogMGNtIj48Rk9OVCANCmZhY2U9IlRpbWVzIE5l dyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEJSPjxCUj48 L1NQQU4+PC9GT05UPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQpzaXplPTI+PFNQQU4g c3R5bGU9IkZPTlQtU0laRTogMTBwdCI+KmFsbG93aW5nKiAobXVjaCBsZXNzICpyZXF1aXJpbmcq KSB0aGUgMTk5IA0KdG8gYmUgcmVsaWFibGUgaW50cm9kdWNlczwvU1BBTj48L0ZPTlQ+PC9UVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQpzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJD b3VyaWVyIE5ldyI+bmFzdHkgcHJvYmxlbXMuIFRoZSAxOTkgaXMgb25seSBhbiBvcHRpbWl6YXRp b24sIHNvIGhhdmluZyBpdCANCmJlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+dW5yZWxpYWJsZSBpcyBvayANCklNTy48L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+VGhlIHByb2JsZW0gaXMgdGhhdCBpZiBhIA0KcHJveHkg c2VuZHMgdGhlIDE5OSwgdGhlbiB0aGUgcmVjaXBpZW50IG9mIHRoZTwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+UFJBQ0sgc2hvdWxkIGJlIHRoZSBwcm94eS4g QnV0IHRoZSBQUkFDSyBpcyBhbiBpbi1kaWFsb2cgDQptZXNzYWdlLCBzbyBpdDwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPm11c3QgYmUgYWRkcmVzc2VkIHRvIA0K dGhlIENvbnRhY3Qgb2YgdGhlIFVBUy48L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+SWYgdGhlIA0KcHJveHkgc2VuZHMgYSByZWxpYWJsZSAxOTksIGFuZCB0 aGUgUFJBQ0sgaXMgYWRkcmVzc2VkIHRvIA0KdGhlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+VUFTLCB0aGUgVUFTIHdpbGwgYmUgdmVyeSANCnN1cnByaXNlZCwg c2luY2UgaXQgaGFzIG5vdCBzZW5kIGEgcmVsaWFibGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05U IA0KZmFjZT0iQ291cmllciBOZXciPnByb3Zpc2lvbmFsLCBhbmQgaXMgc28gbm90IGV4cGVjdGlu ZyBhIFBSQUNLLiBJbiBmYWN0LCBpdCBoYXMgDQpzZW50IGE8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5maW5hbCByZXNwb25zZSwgaGFzIA0KcHJlc3VtYWJseSBh bHJlYWR5IHJlY2VpdmVkIHRoZSBBQ0ssIGFuZCBzbyBpczwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+ZXhwZWN0aW5nIG5vdGhpbmcuPC9GT05UPjwvVFQ+PEJS PjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+VmVyeSB1Z2x5LjwvRk9OVD48L1RU PjxCUj48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQpQYXVsPC9GT05UPjwvVFQ+ PEJSPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPndhbmcubGlib0B6dGUuY29tLmNu IA0Kd3JvdGU6PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyANCjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgSGks PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgQW5kIA0KdGhlcmUg c3RpbGwgdHdvIHF1ZXN0aW9ucyBsZWZ0LjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0i Q291cmllciBOZXciPiZndDsgDQo8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7IDEuICZuYnNwO0lzIHRoZSAxOTkgc2hvdWxkIGJlIA0KcmVsaWFibGUgb3Ig dW5yZWxpYWJsZT88L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZuYnNwOyANCiZuYnNwOyBJIHRoaW5rIHRoYXQgMTk5IHNob3VsZCBiZSByZWxpYWJsZSBp ZiBwb3NzaWJsZS48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXci PiZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAN CjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7 ICZuYnNwO0ZpcnN0LCBJZiBhIA0KY2xpZW50IHJlY2VpdmVzIGFuIHVucmVsaWFibGUgMTk5IHJl c3BvbnNlIG9uIGEgZGlhbG9nIDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyB3aGljaCBoYXM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0i Q291cmllciBOZXciPiZndDsgJm5ic3A7ICZuYnNwO25vdCBwcmV2aW91c2x5IGJlZW4gY3JlYXRl ZCAodGhpcyBjYW4gDQpoYXBwZW4gaWYgYSAxOTkgcmVzcG9uc2U8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyANCiZuYnNwO3JlYWNoZXMgdGhl IGNsaWVudCBiZWZvcmUgYSAxOHggcmVzcG9uc2UpIHRoZSBjbGllbnQgU0hBTEwgDQpkaXNjYXJk PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsg Jm5ic3A7dGhlIDE5OSANCnJlc3BvbnNlcy48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyAmbmJzcDsgJm5ic3A7VGhlIGZpZ3VyZSBiZWxvdyANCnNob3dzIGFuIGV4 YW1wbGUuVGhlIDE4MCBpcyBzZW50IGZpcnN0IGJ1dCBhcnJpdmVzIDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBsYXRlciB0aGFuIDE5OS48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgSWYgdGhlIDE5OSBp cyByZWxpYWJsZSwgdGhlIHByb3h5IHNob3VsZCByZXRyYW5zbWl0IDE5OSANCihzdGVwIDQpLGFu ZCA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IHRoZW4g dGhlIA0KcmV0cmFuc21pdHRlZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgMTk5IHdpbGwgYmUgDQphY2NlcHRlZCBieSBVQUMsYW5kIHRoZSBlYXJseSBk aWFsb2cgd2lsbCBiZSB0ZW1pbmF0ZWQuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgVUFDIA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgUDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAm bmJzcDsgJm5ic3A7MS4gSU5WSVRFPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7IC0tLS0tLS0tLS0tLS0tLSZndDs8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAyLiANCjE4MDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJmx0Oy0tLS0tIA0KXC8tLS0tLS0tPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiZuYnNwOy9cIDMu IDE5OTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJmx0 Oy0tLS0tLyANCiZuYnNwO1wtLS0tLS08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsgJm5ic3A7ICZuYnNwOyA0LiAx OTkocmV0cmFuc21pdHRlZCk8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmll ciBOZXciPiZndDsgJmx0Oy0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg DQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyANCiZuYnNwO3NlY29uZCwgQWNjb3JkaW5nIHRvIHBy YWN0aWNhbCB1c2UsIDE5OSBjYW4gYmUgaW50ZW5kZWQgdG8gdGVtaW5hdGUgDQo8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IG9uZSBlYXJseSBkaWFsb2cg YW5kIA0KcmVsZWFzZTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXci PiZndDsgcmVzb3VyY2VzIGFzc29jaWF0ZWQgDQp3aXRoIHRoZSBzcGVjaWZpYyBlYXJseSBkaWFs b2csIHNvIHRoZSBjb3N0IHNwZW50IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyBvbiByZWxpYWJsZSAxOTkgaXMgd29ydGh5LjwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBJZiB0aGUgMTk5IGNhbm5vdCBi ZSBzZW50IHJlbGlhYmxlLHRoZW4gd2Ugc2hvdWxkIHNlbmQgDQppdCB1bnJlbGlhYmxlLjwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQombmJzcDs8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDIuIEluIHlvdXIg bGFzdCBsZXR0ZXIsIA0KeW91IHNhaWQgInRoZSBzZWNvbmQgMTk5IGNvdWxkIGluY2x1ZGUgPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IGluZm9ybWF0 aW9uIHdoaWNoIGlzIHRvIGJlIGZvcndhcmRlZCB0byANCnRoZTwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgVUFDIiwgdGhlbiBkbyB5b3UgbWVhbiwgdGhl IA0KZWFybHkgZGlhbG9nIGlzIHN0aWxsIGFsaXZlIGFmdGVyIHRoZSBmaXJzdCA8L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgMTk5IGlzIGFjY2VwdGVk PzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KPC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBBbHNvLCBJbiBteSBsYXN0 IGxldHRlciwgSSANCm1pc3MgYSAiTk9UIiBieSBtaXN0YWtlLjwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgSXQgDQpzaG91bGQgYmU8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFtFcmljXTogU3VyZWx5IHRoZSAN ClVBUyBpcyBOT1QgYWxsb3dlZCB0byBzZW5kIGFub3RoZXIgcmVsaWFibGUgcmVzcG9uc2U8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgdW50aWwgdGhl IGZpcnN0IG9uZSBpcyANCmFja25vd2xlZGdlZC4uLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPiZndDsgDQo8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KUmVnYXJkcyw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IEVyaWMgDQp3YW5nPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFj ZT0iQ291cmllciBOZXciPiZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyANCjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICoiPHN0MTpQZXJzb25OYW1lIHc6c3Q9Im9uIj5DaHJpc3RlciANCkhvbG1iZXJnPC9zdDE6 UGVyc29uTmFtZT4iIA0KJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDsqPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQoyMDA5LTAyLTI3IDAz OjA0PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCjwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZPTlQ+ PC9UVD48L1NQQU4+PC9GT05UPjxUVD48Rk9OVCBmYWNlPSJNUyBNaW5jaG8iIA0Kc2l6ZT0yPjxT UEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdNUyBNaW5jaG8nIj7m lLbku7bkuro8L1NQQU4+PC9GT05UPjwvVFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyIgc2l6 ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVy IE5ldyciPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KJm5ic3A7IkVy aWMgd2FuZyIgJmx0O2VyaWMud2FuZ3hyQGdtYWlsLmNvbSZndDs8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9GT05UPjwvVFQ+PC9TUEFOPjwvRk9O VD48VFQ+PEZPTlQgZmFjZT0iTVMgTWluY2hvIiANCnNpemU9Mj48U1BBTiANCnN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnTVMgTWluY2hvJyI+5oqE6YCBPC9TUEFOPjwvRk9O VD48L1RUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCnN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48QlI+PFRUPjxGT05U IA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiZuYnNwOyZsdDtzaXBAaWV0Zi5vcmcmZ3Q7LCAN CiZsdDt3YW5nLmxpYm9AenRlLmNvbS5jbiZndDs8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KPC9GT05UPjwvVFQ+PC9TUEFOPjwvRk9OVD48VFQ+PEZP TlQgZmFjZT0iTVMgTWluY2hvIiBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogJ01TIE1pbmNobyciPuS4uzwvU1BBTj48L0ZPTlQ+PC9UVD48VFQ+PEZP TlQgDQpmYWNlPVNpbVN1biBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogU2ltU3VuIj7popg8L1NQQU4+PC9GT05UPjwvVFQ+PEZPTlQgDQpmYWNlPSJD b3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6ICdDb3VyaWVyIE5ldyciPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IA0KJm5ic3A7UkU6IFF1ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0Zi1zaXAtMTk5LTA1Ijwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQo8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7IA0KPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyBIaSw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBO ZXciPiZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyANCiZuYnNwOyZndDtJIHN0aWxsIGhhdmUgc29tZSBkaWZmaWN1bHQgaW4gdXNpbmcgSUVURiBh bmQgY2Fubm90IGZpbmQgdGhlIA0Kd2hvbGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7IHNvcnRlZCBjb21tZW50cyBhYm91dCANCnRoaXMgZHJhZnQsIHNv IGkgaGF2ZSBzb21lIGRvdWJ0IGFib3V0IHRoaXMgZHJhZnQuPC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyZndDs8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgMS4g Jm5ic3A7ICJJZiBhIGZvcmtpbmcgcHJveHkgcmVjZWl2ZXMgDQphIHJlbGlhYmx5IHNlbnQgMTk5 IHJlc3BvbnNlIGZvciBhPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7IGRpYWxvZywgZm9yIHdoaWNoIHRoZSBwcm94eSBoYXMgcHJldmlvdXNseSBnZW5l cmF0ZWQgYW5kIA0Kc2VudCBhIDE5OTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciPiZndDsgcmVzcG9uc2UsIHRoZSBwcm94eSANCk1VU1QgZm9yd2FyZCB0aGUgMTk5 IHJlc3BvbnNlLiI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7IA0KJm5ic3A7Jmd0OzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPiZndDsgJm5ic3A7Jmd0OyAmbmJzcDsgDQombmJzcDsgRG9lcyBpdCBkZXNjcmliZSB0aGUg Y2FzZSBiZWxvdz8gQWx0aG91Z2ggUDEgaGF2ZSBzZW50IGEgDQoxOTk8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IHJlc3BvbnNlLCBQMSBoYXZzIHRvIA0K Jm5ic3A7Zm9yd29yZCB0aGUgc2VuZCByZWxpYWJseSAxOTkgdG9vLk9yICZuYnNwO2lzIHRoZTwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBmaXJzdCAx OTkgbWlzdGFrZWQgZm9yIDE4eD88L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291 cmllciBOZXciPiZndDsgJm5ic3A7Jmd0OzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtVQUMgJm5ic3A7IA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgUDEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1VBU18yPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDstLS0gDQpJTlZJVEUgLS0tLS0tJmd0OzwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0OyANCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgDQombmJzcDsgJm5ic3A7ICZuYnNwOyAtLS0gSU5WSVRFIChsZWcgMikgLSZndDs8L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KJm5ic3A7Jmx0Oy0tIDE5OShsZWcg MikgLS08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0K Jm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0 Oy0tIDE5OSAobGVnIDIpIC0tLS0tPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyANCiZuYnNwOyZsdDstLSAxOTkobGVnIDIpIC0tPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0O0kgdGhpbmsgaXQgc2hhbGwgYmUgDQoxOTks IGFzIGN1cnJlbnRseSB3cml0dGVuLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciPiZndDsgDQombmJzcDsmZ3Q7PC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsmZ3Q7W0VyaWNdOiBJZiANCiZuYnNwO3RoaXMgaXMg MTk5LCB0aGVuIElzIHRoZXJlIGEgc3BlY2lhbCBwdXJwb3NlIHRvIHNlbmQgDQp0d288L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDE5OSBpbiB0aGUgc2Ft ZSANCmRpYWxvZz88L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZuYnNwOyZndDtJIHRoaW5rIHRoYXQgDQpvbmUgMTk5IGlzIGVub3VnaC48L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KJm5ic3A7Jmd0O0FuZCAm bmJzcDt0aGUgZmlyc3QgMTk5IG1heSBiZSByZWxpYWJsZSB0b28sIHRoYXQgd2lsbCBtYWtlIGl0 IGEgDQpsaXR0bGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7IGRpZmZpY3VsdCB0byBzZW5kIHRoZSANCnNlY29uZCAxOTkuPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCjwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgVGhlIHNlY29uZCAxOTkgY291bGQgaW5jbHVkZSAN CmluZm9ybWF0aW9uIHdoaWNoIGlzIHRvIGJlIGZvcndhcmRlZCB0byB0aGU8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgVUFDLjwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQo8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg DQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsmZ3Q7Mi4gJm5ic3A7IjEwLiAmbmJzcDtV c2FnZSB3aXRoIA0KMTAwcmVsPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyANCiZuYnNwOyZndDs8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyZndDsgJm5ic3A7IA0KV2hlbiBhIDE5OSBFYXJseSBEaWFs b2cgVGVybWluYXRlZCBwcm92aXNpb25hbCByZXNwb25zZSBpcyBzZW50IGJ5IA0KYTwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgVUFTLCBzaW5jZSB0aGUg cHJvdmlzaW9uYWwgDQpyZXNwb25zZSBpcyBvbmx5IHVzZWQgZm9yIGluZm9ybWF0aW9uPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IHB1cnBvc2UsIHRo ZSBVQVMgU0hPVUxEIHNlbmQgaXQgdW5yZWxpYWJseSBldmVuIGlmIHRoZSANCjEwMHJlbDwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0OyAm bmJzcDsgb3B0aW9uIA0KdGFnIFtSRkMzMjYyXSBpcyBwcmVzZW50IGluIHRoZSBSZXF1aXJlIGhl YWRlciBvZiB0aGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXci PiZndDsgYXNzb2NpYXRlZCByZXF1ZXN0LiI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFj ZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0OzwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQg DQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsmZ3Q7PC9GT05UPjwvVFQ+PEJSPjxUVD48 Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyZndDtJIGhhdmUgc2VlbiBhIGNv bW1lbnQgb24gdGhpcyBxdWVzdGlvbixidXQgDQpzdGlsbCBub3QgdW5kZXJzdG9vZCBhYm91dDwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQombmJzcDsm Z3Q7aXQuIElmIHRoZSBJTlZJVEUgaGFzIGEgUmVxdWlyZSB0YWcgIlJlcXVpcmU6IDEwMHJlbCIs ZG9lcyB0aGUgDQpVQVM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7IA0Kc3RpbGw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZuYnNwOyZndDt1c2UgdW5yZWxpYWJsZSANCjE5OSByZXNwb25zZT88L0ZPTlQ+PC9U VD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KJm5ic3A7Jmd0OzwvRk9O VD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0O1Ro YXQgaXMgDQp0aGUgcmVjb21tZW5kYXRpb24sIHllcy4gVGhlIHJlYXNvbnMgaXMgdGhhdCB3ZSB3 YW50IHRvIA0Ka2VlcDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXci PiZndDsgDQoxOTk8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7ICZuYnNwOyZndDthcyAibGlnaHR3ZWlnaHQiIA0KYXMgcG9zc2libGUsIHdpdGhvdXQgcmVx dWlyZWluZyByZS10cmFuc21pc3Npb25zIGFuZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsmZ3Q7UFJBQ0tzLjwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsmZ3Q7PC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyZndDtbRXJpY106 IEJ1dCByZWxpYWJsZSAxOTkgaGF2ZSBtb3JlIGFkdmFudGFnZSwgDQphbmQgSXQgaXMgd29ydGgg dG8gdXNlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyB0 aGUgDQpyZWxpYWJsZSAxOTksSSB0aGluay48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+Jmd0OyBJIGRvbid0IGtub3cgd2hhdCB0aGF0IA0KYWR2YW50YWdlIHdvdWxkIGJl LCBjb21wYXJlZCB0byBoYXZpbmcgdG8gc2VuZDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBQUkFDS3MgZXRjLiBUaGlzIGhhcyBiZWVuIGRpc2N1c3Nl ZCBxdWl0ZSBtdWNoLCBzbyBJIA0Kd291bGQgcmVhbGx5IG5lZWQ8L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IHNvbWUgZ29vZCANCmp1c3RpZmljYXRpb24g dG8gY2hhbmdlIGl0IG5vdy48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij4mZ3Q7IA0KPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyBBbHNvLCB0aGUgZHJhZnQgZG9lc24ndCBmb3JiaWQgDQp5b3UgdG8gc2VuZCB0aGUgMTk5 IHJlbGlhYmx5LiBJdCdzIG9ubHkgYTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyBTSE9VTEQuPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyANCjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPiZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7ICZuYnNwOyZndDtJZiAxOTkgaXMgcmVsaWFibGUsIHRoZXJlIGlzIG9uZSBtb3JlIA0K YWR2YW50YWdlLiBJZiB0aGUgMTk5IGFycml2ZXM8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KJm5ic3A7Jmd0O2JlZm9yZSB0aGUgZmlyc3QgMTh4IHJl c3BvbnNlLCBVQUMgY2FuIGRpc2NhcmQgdGhlIGZpcnN0IDE5OSANCmFuZDwvRk9OVD48L1RUPjxC Uj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQpwcm9jZXNzPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsmZ3Q7aXQgdW50aWwg VUFDIA0KcmVjZWl2ZXMgdGhlIGZpcnN0IDE4eCByZXNwb25zZSB0aGF0IGhhcyB0aGUgc2FtZTwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsm Z3Q7dG8tdGFnIGFzIDE5OSwgYXMgdGhlIHJlbGlhYmxlIDE5OSBzaG91bGQgYmUgDQpyZS10cmFu c21pdGVkIHVudGlsPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyANCiZuYnNwOyZndDtyZWNlaXZlZCBQUkFDSy48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KJm5ic3A7Jmd0OzwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0O0lmIHRoZSANCklOVklURSBj b250YWlucyAiUmVxdWlyZTogMTAwcmVsIiwgdGhlIGZpcnN0IDE4eCBtdXN0IGFsc28gDQpiZTwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0 O3NlbnQgcmVsaWFibHkuIA0KQW5kLCBJIGRvbid0IHRoaW5rIHRoZSBVQVMgaXMgYWxsb3dlZCB0 byBzZW5kIGFub3RoZXI8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291cmllciBO ZXciPiZndDsgJm5ic3A7Jmd0O3JlbGlhYmxlIHJlc3BvbnNlIHVudGlsIHRoZSBmaXJzdCBvbmUg aXMgDQphY2tub3dsZWRnZWQsIHNvIEkgZG9uJ3QgdGhpbms8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KJm5ic3A7Jmd0O2EgcmVsaWFibGUgMTk5IHdv dWxkIHJlYWNoIHRoZSBVQUMgYmVmb3JlIHRoZSBmaXJzdCByZWxpYWJsZSANCjE4eC48L0ZPTlQ+ PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KJm5ic3A7Jmd0Ozwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7Jmd0 O1tFcmljXTogDQpTdXJlbHkgdGhlIFVBUyBpcyBhbGxvd2VkIHRvIHNlbmQgYW5vdGhlciByZWxp YWJsZSANCnJlc3BvbnNlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyB1bnRpbCB0aGUgZmlyc3Qgb25lIGlzIA0KYWNrbm93bGVkZ2VkLDwvRk9OVD48L1RU PjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQo8L0ZPTlQ+PC9UVD48QlI+ PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IElmIEkgcmVtZW1iZXIgY29ycmVjdGx5 LCB0aGUgDQpGSVJTVCByZWxpYWJsZSByZXNwb25zZSBtdXN0IGJlIGFja25vd2xlZGVkPC9GT05U PjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IGJlZm9yZSB0aGUg bmV4dCByZWxpYWJsZSByZXNwb25zZSBpcyBzZW50LiBCdXQsIHdlIGNhbiANCmRvdWJsZSBjaGVj ayBpbjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgdGhl IFBSQUNLIA0Kc3BlYy48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyAmbmJzcDsmZ3Q7YnV0IHJlbGlhYmxlIDE5OSB3aWxsIGJlIHVzZWZ1bCBpZiB0aGUgZmlyc3Qg DQoxOHggaXMgdW5yZWxpYWJsZSwgb3IgdGhlPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyBmaXJzdCANCjE4eCBoYXMgYmVlbiBhY2tud2xlZGdlZC4gSXQn cyBhbm90aGVyIGNhc2UgZGlmZmVyZW50IGZyb20gDQp0aGU8L0ZPTlQ+PC9UVD48QlI+PFRUPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IGFib3ZlIG9uZSAmbmJzcDt3aG9zZSANCklOVklU RSBjb250YWlucyAicmVxdWlyZTogMTAwcmVsIi48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0K ZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyBJZiANCjEwMHJlbCBpcyByZXF1aXJlZCB0aGUgMTh4IGNhbm5vdCBi ZSB1bnJlbGlhYmxlLjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 IA0KUmVnYXJkcyw8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7IA0KPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAN CkNocmlzdGVyPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0 OyANCjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9G T05UPjwvVFQ+PEJSPjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9OVD48 L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZndDsgDQo8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9OVD48L1RUPjxCUj48VFQ+ PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KZmFjZT0iQ291 cmllciBOZXciPiZndDsgPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyANCjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZn dDsgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gDQpjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIA0KbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBp ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIA0KbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgDQpjb21t dW5pY2F0aW9uIHRvIG90aGVycy48L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7IFRoaXMgDQplbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciANCnRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5 b3UgaGF2ZSANCnJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IA0Kdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgDQpzZW5kZXIuPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gDQpzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt LjwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KPC9GT05UPjwv VFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyANCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L0ZP TlQ+PC9UVD48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IA0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0ZPTlQ+PC9UVD48QlI+PFRU PjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZndDsgU2lwIG1haWxpbmcgbGlzdCANCiZuYnNw O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwPC9GT05UPjwvVFQ+PEJS PjxUVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFRoaXMgbGlzdCBpcyBmb3IgTkVX IGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCANClByb3RvY29sPC9GT05UPjwvVFQ+PEJSPjxU VD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBVc2UgDQpzaXAtaW1wbGVtZW50b3JzQGNz LmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgDQpzaXA8L0ZPTlQ+PC9UVD48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFVzZSBzaXBwaW5nQGlldGYub3Jn IGZvciANCm5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIA0Kc2lwPC9GT05U PjwvVFQ+PEJSPjxCUj48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPjxQUkUgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxT UEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUFJF PjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIg c2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPlpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3IiBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+VGhpcyZuYnNwO2VtYWls Jm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgm bmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVk Jm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJz cDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2 ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZu YnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZu YnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQm bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuPG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPlRoaXMmbmJz cDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2 aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFt Jm5ic3A7c3lzdGVtLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1BSRT48L0RJVj48L0JPRFk+ PC9IVE1MPg0K ------_=_NextPart_001_01C99914.BAED86AA-- From root@core3.amsl.com Sat Feb 28 14:00:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 464E33A69CD; Sat, 28 Feb 2009 14:00:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090228220001.464E33A69CD@core3.amsl.com> Date: Sat, 28 Feb 2009 14:00:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 22:00:01 -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 Working Group of the IETF. Title : Framework for Establishing an SRTP Security Context using DTLS Author(s) : J. Fischl, et al. Filename : draft-ietf-sip-dtls-srtp-framework-06.txt Pages : 38 Date : 2009-02-28 This document specifies how to use the Session Initiation Protocol (SIP) to establish an Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-06.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-sip-dtls-srtp-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-28134653.I-D@ietf.org> --NextPart--