From nobody Fri Nov 4 14:28:14 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE1812969B; Fri, 4 Nov 2016 14:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z9ozB9f9exm; Fri, 4 Nov 2016 14:28:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B841294AA; Fri, 4 Nov 2016 14:28:04 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA4LS1DF029191 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Nov 2016 16:28:03 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" , "dispatch@ietf.org" From: Adam Roach Message-ID: Date: Fri, 4 Nov 2016 16:28:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A1B50B280F4E72838B2CB70C" Archived-At: Cc: "art-ads@ietf.org" Subject: [sipcore] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 'SIPCORE' List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 21:28:08 -0000 This is a multi-part message in MIME format. --------------A1B50B280F4E72838B2CB70C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as SIPCORE chair] Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload. Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items. We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions. Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul. The proposed charter text follows. > The Session Initiation Protocol Core (SIPCore) working group is > chartered to maintain and continue the development of the SIP protocol, > currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and > 6665. > > The SIPCore working group will concentrate on specifications that update > or replace the core SIP specifications named above as well as > specifications pertaining to small, self-contained SIP protocol > extensions. The process and requirements for new SIP extensions are > documented in RFC5727, "Change Process for the Session Initiation > Protocol". > > Throughout its work, the group will strive to maintain the basic model > and architecture defined by SIP. In particular: > > 1. Services and features are provided end-to-end whenever possible. > > 2. Reuse of existing Internet protocols and architectures and > integrating with other Internet applications is crucial. > > 3. Standards-track extensions and new features must be generally > applicable, and not applicable only to a specific set of session > types. > > 4. Simpler solutions that solve a given problem should be favored > over more complex solutions. > > The primary source of change requirements to the core SIP specifications > (enumerated above) will be a) interoperability problems that stem from > ambiguous, or under-defined specification, and b) requirements from > other working groups in the ART Area. The primary source of new protocol > extensions is the DISPATCH working group, which will generally make the > determination regarding whether new SIP-related work warrants a new > working group or belongs in an existing one. For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charter-ietf-sipcore/ Thanks! /a --------------A1B50B280F4E72838B2CB70C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.


The Session Initiation Protocol Core (SIPCore) working group is
chartered to maintain and continue the development of the SIP protocol,
currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
6665.

The SIPCore working group will concentrate on specifications that update
or replace the core SIP specifications named above as well as
specifications pertaining to small, self-contained SIP protocol
extensions.  The process and requirements for new SIP extensions are
documented in RFC5727, "Change Process for the Session Initiation
Protocol".

Throughout its work, the group will strive to maintain the basic model
and architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and
   integrating with other Internet applications is crucial.

3. Standards-track extensions and new features must be generally
   applicable, and not applicable only to a specific set of session
   types.

4. Simpler solutions that solve a given problem should be favored
    over more complex solutions.

The primary source of change requirements to the core SIP specifications
(enumerated above) will be a) interoperability problems that stem from
ambiguous, or under-defined specification, and b) requirements from
other working groups in the ART Area. The primary source of new protocol
extensions is the DISPATCH working group, which will generally make the
determination regarding whether new SIP-related work warrants a new
working group or belongs in an existing one.


For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charter-ietf-sipcore/

Thanks!

/a

--------------A1B50B280F4E72838B2CB70C-- From nobody Fri Nov 4 17:23:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21B51294F2; Fri, 4 Nov 2016 17:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lFojgJVRWcJ; Fri, 4 Nov 2016 17:23:41 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0057.outbound.protection.outlook.com [104.47.36.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B08B1294CF; Fri, 4 Nov 2016 17:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FVGmYSmE5u6fhtHdo3mh+TPm0Ry4ZjM3FfYJsLVgXLE=; b=JC8p0eyhhRLNh2fZovShDPy9zkgCr9RLLhgi5yMyyTKPQ1WDdZVH1XUkjoXfXlsViGUF8yxat87rL6tHyI/lc+Ou0llwsupDf0AE0NRH8WnBhCUyPnSHm+FTmWCePWSeT9jRfAa4fS3bYw1zSIioDnaTkkWHx3nQSPwxG3CYMak= Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1660.namprd06.prod.outlook.com (10.163.232.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Sat, 5 Nov 2016 00:23:39 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.0693.016; Sat, 5 Nov 2016 00:23:39 +0000 From: Dan York To: SIPCORE Thread-Topic: [dispatch] SIPCORE Rechartering Thread-Index: AQHSNuJa3q7ocdyfvEOM+myanQ4V26DJh+6A Date: Sat, 5 Nov 2016 00:23:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-ms-office365-filtering-correlation-id: b116eac0-d71c-4123-be03-08d40511fd9e x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1660; 7:8KTBhTzI0VXiOp1a1JkYd4yII3Dm2Be4xiffEkCnu9lJa86F3I7X2B7AnfJJVPqZJwULoZ2mlCjmsf2WSQbgk5lEm5+4eUgUedAglubFE5lGen9P8QVo5UdtpQLoysDMOqxp62csP96f9HykWYd+mHgvKNOp1RWCO1ty4692i3QvYjKCYm6cSAu3j3fcVTKUueSBBWiZV4esQhvRf8/G5Sd/S6OnBqP/KsTJZepqpzjVRugaaQOroh/vMO5SDfsPrWu9vpKiALRql4xeEAcwDDH6WSJhX2+P9Va5ZZ64zs5K8VADHTfoONVCIaEEKQsS5YV+jAyUfxqEyE6YFLpWKi2rfFzV+/xGXHf0rxMhtmU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1660; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0601MB1660; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1660; x-forefront-prvs: 011787B9DD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(24454002)(189002)(377454003)(33656002)(450100001)(92566002)(122556002)(2900100001)(101416001)(8676002)(86362001)(81156014)(77096005)(36756003)(81166006)(7736002)(66066001)(8936002)(7846002)(19580405001)(68736007)(19580395003)(106116001)(99286002)(105586002)(586003)(106356001)(82746002)(2906002)(5002640100001)(16236675004)(189998001)(5660300001)(11100500001)(83716003)(3660700001)(3280700002)(97736004)(87936001)(6916009)(6116002)(110136003)(3846002)(2950100002)(76176999)(54356999)(50986999)(10400500002)(102836003)(4326007)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1660; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BCC4B4E50CB4425DA6A0DA5CB8A8D8F2isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2016 00:23:39.1962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1660 Archived-At: Cc: "art-ads@ietf.org" Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 00:23:42 -0000 --_000_BCC4B4E50CB4425DA6A0DA5CB8A8D8F2isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, On Nov 4, 2016, at 5:28 PM, Adam Roach > wrote: We, the SIPCORE chairs and area director, seek to fix that. We would like t= o amend the SIPCORE charter to allow it to take on small, self-contained pr= otocol extensions in addition to changes to the core SIP protocol. This is = a relatively minor update to the existing charter, which expands the scope = as described above, and adds back in two of the architectural principles fr= om the SIP charter which are applicable only to protocol extensions. Please provide feedback on the proposed charter by sending email to the SIP= CORE mailing list. We will also discuss this briefly during the DISPATCH se= ssion in Seoul. This makes sense to me. The proposed text looked fine to me. Dan --_000_BCC4B4E50CB4425DA6A0DA5CB8A8D8F2isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <6BC5FCDCAB001142A82000C90F0F89AA@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Adam,

On Nov 4, 2016, at 5:28 PM, Adam Roach <adam@nostrum.com> wrote:
<snip>

We, the SIPCORE chairs and area director, seek to fix that. W= e would like to amend the SIPCORE charter to allow it to take on small, sel= f-contained protocol extensions in addition to changes to the core SIP prot= ocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and a= dds back in two of the architectural principles from the SIP charter which = are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending em= ail to the SIPCORE mailing list. We will also discuss this briefly during t= he DISPATCH session in Seoul.


This makes sense to me. The proposed text looked fine to me.

Dan


--_000_BCC4B4E50CB4425DA6A0DA5CB8A8D8F2isocorg_-- From nobody Fri Nov 4 18:18:10 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEAE129459 for ; Fri, 4 Nov 2016 18:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1sNfIYputti for ; Fri, 4 Nov 2016 18:18:07 -0700 (PDT) Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F405A1293E9 for ; Fri, 4 Nov 2016 18:18:06 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id uA51G52M002368 for ; Fri, 4 Nov 2016 21:18:05 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id B4A336D for ; Fri, 4 Nov 2016 21:18:05 -0400 (EDT) Received: from sendprodmail01.cc.columbia.edu (sendprodmail01.cc.columbia.edu [128.59.72.13]) by hazelnut (Postfix) with ESMTP id 9CA3D6D for ; Fri, 4 Nov 2016 21:18:05 -0400 (EDT) Received: from mail-oi0-f72.google.com (mail-oi0-f72.google.com [209.85.218.72]) by sendprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id uA51I5tb020242 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 4 Nov 2016 21:18:05 -0400 Received: by mail-oi0-f72.google.com with SMTP id y143so165288904oie.3 for ; Fri, 04 Nov 2016 18:18:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jyT9hneea2bzmpJWnJjjksj3EzTsz7cCaxSnxXsZwbg=; b=dgRuxvpUdLQWZHwIsrtAPMOmHinmSKlGG/Ld5qpJaVrWjk3foayIh+krXxKPfg57dt +TCo9ZpMh8D0YfNLOaT+OOD/Yl0GrWTgruDpQDZaqEzt8qePITKF/fRM88Z4ytweNcs1 E5d11ffOsbr1le6Tg557wFGY2THbkkp/QWl9bnKqey2XKI8QmbhQmUQAoNtLeHWMDjKQ rxjU02CM53GTJx+fD4memCnoy3zDsu6NSgZ++fbirYxsshoElXfn+23I9xQnH6EjPv8L E59DnrK/OZu+9jL5bJZpt9jCWFEK7DA3PdlvcYb8QWGLUFbGRFAABJtLHoy6VFjcEvDT a80w== X-Gm-Message-State: ABUngvc0rAwcvhGwziftvWXFma4oxl4IS7EhgRBZt90Egh3fK+Vb2jbKUKVrctp5DXgdSELi5MZR38+VCvqU7DoUYkE1qN/cg66hn9zy4uidCTTzEWlg5jixZT5pD1Qy3Fhd0wBlNcJe4VYFXrNrYigBsB0= X-Received: by 10.157.0.73 with SMTP id 67mr11602363ota.141.1478308684906; Fri, 04 Nov 2016 18:18:04 -0700 (PDT) X-Received: by 10.157.0.73 with SMTP id 67mr11602357ota.141.1478308684757; Fri, 04 Nov 2016 18:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.199.10 with HTTP; Fri, 4 Nov 2016 18:17:44 -0700 (PDT) In-Reply-To: References: From: Henning Schulzrinne Date: Fri, 4 Nov 2016 21:17:44 -0400 Message-ID: To: SIPCORE Content-Type: multipart/alternative; boundary=94eb2c11f30e060f91054083901f X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.13 Archived-At: Cc: Dan York Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 01:18:09 -0000 --94eb2c11f30e060f91054083901f Content-Type: text/plain; charset=UTF-8 Will existing SIP-related drafts in DISPATCH be moved to SIPCORE? On Fri, Nov 4, 2016 at 8:23 PM, Dan York wrote: > Adam, > > On Nov 4, 2016, at 5:28 PM, Adam Roach wrote: > > > > We, the SIPCORE chairs and area director, seek to fix that. We would like > to amend the SIPCORE charter to allow it to take on small, self-contained > protocol extensions in addition to changes to the core SIP protocol. This > is a relatively minor update to the existing charter, which expands the > scope as described above, and adds back in two of the architectural > principles from the SIP charter which are applicable only to protocol > extensions. > > Please provide feedback on the proposed charter by sending email to the > SIPCORE mailing list. We will also discuss this briefly during the DISPATCH > session in Seoul. > > > This makes sense to me. The proposed text looked fine to me. > > Dan > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --94eb2c11f30e060f91054083901f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Will existing SIP-related drafts in DISPATCH be moved to S= IPCORE?

On F= ri, Nov 4, 2016 at 8:23 PM, Dan York <york@isoc.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Adam,

On Nov 4, 2016, at 5:28 PM, Adam Roach <adam@nostrum.com> wrote:
<snip>

We, the SIPCORE chairs and area director, seek to fix that. We would lik= e to amend the SIPCORE charter to allow it to take on small, self-contained= protocol extensions in addition to changes to the core SIP protocol. This = is a relatively minor update to the existing charter, which expands the scope as described above, and a= dds back in two of the architectural principles from the SIP charter which = are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the = SIPCORE mailing list. We will also discuss this briefly during the DISPATCH= session in Seoul.


This makes sense to me. The proposed text looked fine to me.

Dan



_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--94eb2c11f30e060f91054083901f-- From nobody Sun Nov 6 01:18:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E5E129457 for ; Sun, 6 Nov 2016 01:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9yxwiEdF9LI for ; Sun, 6 Nov 2016 01:18:29 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B22A1293FB for ; Sun, 6 Nov 2016 01:18:27 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id D6B005390; Sun, 6 Nov 2016 10:18:08 +0100 (CET) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 6 Nov 2016 10:18:07 +0100 Message-Id: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 09:18:32 -0000 Hi! Paul and I had a conversation about source address selection in SIP on = the SIP Forum IPv6 list that I wanted to move here. An IPv6 interface by default has multiple addresses. Today=E2=80=99s = computers also quite frequently have multiple interfaces. A modern SIP stack has many IP addresses to select from. In many cases applications let the operating system handle address = election and set the IP packets sender IP address to the one that matches the interface and the selected destination address (by = using DNS as an example). In SIP we have multiple addresses in the SIP message. Much can be = simplified by using fqdn in the messages and a GRUU with a SIP domain in the contact. In fact most of the = examples in RFC 3261 use FQDNs. But it=E2=80=99s not how SIP is implemented out there in the wild=E2=80=A6= I tried to find any words in RFC 3261 or RFC 3263 about selection of = interfaces and addresses but found nothing. Having said that, it=E2=80=99s not easy so if anyone on sipcore can = point me to the right section I will be grateful. If not, I think we may need a clarification on Transaction layer = handling of IP address selection in the SIP protocol. Given a specific target, how do we handle multiple = interfaces and multiple addresses per interface - which address do we put in the SIP messages - like in = via=E2=80=99s, record-route, SDPs and contacts. We have been testing at SIPit with multiple ULAs attached to a network = and a proxy on one of the ULAs. No one could connect to that proxy properly (sadly for me not even = Kamailio itself, which brags about having IPv6 support from day one). IPv6 source address selection is covered here: https://tools.ietf.org/html/rfc6724 Quoting RFC 6724: "The IPv6 addressing architecture [RFC4291] allows multiple unicast addresses to be assigned to interfaces. These addresses might have different reachability scopes (link-local, site-local, or global). These addresses might also be "preferred" or "deprecated" [RFC4862]. Privacy considerations have introduced the concepts of "public addresses" and "temporary addresses" [RFC4941]. The mobility architecture introduces "home addresses" and "care-of addresses" [RFC6275]. In addition, multi-homing situations will result in more addresses per node. For example, a node might have multiple interfaces, some of them tunnels or virtual interfaces, or a site might have multiple ISP attachments with a global prefix per ISP. The end result is that IPv6 implementations will very often be faced with multiple possible source and destination addresses when initiating communication. It is desirable to have default algorithms, common across all implementations, for selecting source and destination addresses so that developers and administrators can reason about and predict the behavior of their systems.=E2=80=9D Executive question summary: Does the current set of SIP standards cover = IP address selection for the *sender* when we have multiple IP interfaces (IPv4, = IPv6) or just one interface with multiple addresses? If not, should we do something about it? /O From nobody Sun Nov 6 04:34:25 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D20A1294A8 for ; Sun, 6 Nov 2016 04:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if6wxtffk9gv for ; Sun, 6 Nov 2016 04:34:20 -0800 (PST) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF93E12947A for ; Sun, 6 Nov 2016 04:34:20 -0800 (PST) Received: from jirimac.local (94.142.238.227 [94.142.238.227]) by mx.zohomail.com with SMTPS id 147843564553586.42043338303301; Sun, 6 Nov 2016 04:34:05 -0800 (PST) To: "Olle E. Johansson" , SIPCORE References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> From: Jiri Kuthan Message-ID: <20e363e0-dc68-25a7-0ddc-4bde6bf05055@iptel.org> Date: Sun, 6 Nov 2016 13:34:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 12:34:22 -0000 On 06/11/16 10:18, Olle E. Johansson wrote: > Hi! > > Paul and I had a conversation about source address selection in SIP on the SIP Forum IPv6 list that I wanted to move here. > > An IPv6 interface by default has multiple addresses. Today’s computers also quite frequently have multiple interfaces. > A modern SIP stack has many IP addresses to select from. > > In many cases applications let the operating system handle address election and set the IP packets sender IP address to the > one that matches the interface and the selected destination address (by using DNS as an example). > > In SIP we have multiple addresses in the SIP message. Much can be simplified by using fqdn in the messages > and a GRUU with a SIP domain in the contact. In fact most of the examples in RFC 3261 use FQDNs. > > But it’s not how SIP is implemented out there in the wild… > > I tried to find any words in RFC 3261 or RFC 3263 about selection of interfaces and addresses but found nothing. > Having said that, it’s not easy so if anyone on sipcore can point me to the right section I will be grateful. > > If not, I think we may need a clarification on Transaction layer handling of IP address selection in > the SIP protocol. Given a specific target, how do we handle multiple interfaces and multiple addresses > per interface - which address do we put in the SIP messages - like in via’s, record-route, SDPs and contacts. > > We have been testing at SIPit with multiple ULAs attached to a network and a proxy on one of the ULAs. > No one could connect to that proxy properly (sadly for me not even Kamailio itself, which brags about having > IPv6 support from day one). > > IPv6 source address selection is covered here: > https://tools.ietf.org/html/rfc6724 > > Quoting RFC 6724: > > "The IPv6 addressing architecture [RFC4291] allows multiple unicast > addresses to be assigned to interfaces. These addresses might have > different reachability scopes (link-local, site-local, or global). > These addresses might also be "preferred" or "deprecated" [RFC4862]. > Privacy considerations have introduced the concepts of "public > addresses" and "temporary addresses" [RFC4941]. The mobility > architecture introduces "home addresses" and "care-of addresses" > [RFC6275]. In addition, multi-homing situations will result in more > addresses per node. For example, a node might have multiple > interfaces, some of them tunnels or virtual interfaces, or a site > might have multiple ISP attachments with a global prefix per ISP. > > The end result is that IPv6 implementations will very often be faced > with multiple possible source and destination addresses when > initiating communication. It is desirable to have default > algorithms, common across all implementations, for selecting source > and destination addresses so that developers and administrators can > reason about and predict the behavior of their systems.” > > Executive question summary: Does the current set of SIP standards cover IP address > selection for the *sender* when we have multiple IP interfaces (IPv4, IPv6) > or just one interface with multiple addresses? IMO, the OS makes the choice and the app just finds out what it is and print it last-minute in the message being sent out. This seems more an implementor's choice rather than protocol standardization, doesn't it. -jiri p.s. https://github.com/kamailio/kamailio/blob/master/forward.c get_out_socket() does that as an example. From nobody Sun Nov 6 05:47:52 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73DB129892 for ; Sun, 6 Nov 2016 05:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jYxXgthv2YT for ; Sun, 6 Nov 2016 05:47:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A500A129889 for ; Sun, 6 Nov 2016 05:47:45 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 673B0E6A3F577 for ; Sun, 6 Nov 2016 13:47:41 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA6DlhnW009710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 6 Nov 2016 13:47:43 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uA6DlhkW025262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 6 Nov 2016 14:47:43 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.214]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Sun, 6 Nov 2016 14:47:43 +0100 From: "Drage, Keith (Nokia - GB)" To: "'SIPCORE'" Thread-Topic: [dispatch] SIPCORE Rechartering Thread-Index: AQHSNuJbof3GUTb0uE6yIgkvbI355qDL9N4A Date: Sun, 6 Nov 2016 13:47:42 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFA8477@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADFA8477FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 13:47:49 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADFA8477FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90ZSB0aGF0IEkgZG9u4oCZdCBhY3R1YWxseSB0aGluayBpdCB3YXMgdGhlIHZvbHVtZSBvZiB3 b3JrIOKAkyBJIHRoaW5rIGl0IHdhcyBtb3JlIEN1bGxlbiBKZW5uaW5ncyB0cnlpbmcgdG8gZ2V0 IHJpZCBvZiBhdCBsZWFzdCB0d28gd29ya2luZyBncm91cCBjaGFpcnMgaGUgZGlkIG5vdCBsaWtl Lg0KDQpPdGhlcndpc2Ugd2h5IHRoZSBub24tYXBwZWFyYW5jZSBvZiBhbnkgb2YgdGhvc2UgV0cg Y2hhaXJzIGluIHRoZSByZXN0cnVjdHVyZWQgb3JnYW5pc2F0aW9uPyBFdmVyeSBvdGhlciBzcGxp dCBoYXMgcmV0YWluZWQgV0cgY2hhaXJzLg0KDQpLZWl0aA0KDQpGcm9tOiBkaXNwYXRjaCBbbWFp bHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFJvYWNoDQpT ZW50OiAwNCBOb3ZlbWJlciAyMDE2IDIxOjI4DQpUbzogJ1NJUENPUkUnOyBkaXNwYXRjaEBpZXRm Lm9yZw0KQ2M6IGFydC1hZHNAaWV0Zi5vcmcNClN1YmplY3Q6IFtkaXNwYXRjaF0gU0lQQ09SRSBS ZWNoYXJ0ZXJpbmcNCg0KDQpbYXMgU0lQQ09SRSBjaGFpcl0NCg0KQmFjayB3aGVuIHdlIHRyYW5z aXRpb25lZCBmcm9tIHRoZSBTSVBQSU5HL1NJUCB3b3JraW5nIGdyb3VwIHN0cnVjdHVyZSB0byBT SVBDT1JFLCB3ZSBwdXQgcmVsYXRpdmVseSB0aWdodCBsaW1pdHMgb24gdGhlIFNJUENPUkUgY2hh cnRlci4gVGhpcyB3YXMgYSByZWNvZ25pdGlvbiBvZiB0aGUgZmFjdCB0aGF0IHRoZSB2b2x1bWUg b2YgU0lQLXJlbGF0ZWQgd29yayBhdCB0aGUgdGltZSB3YXMgdG9vIGxhcmdlIGZvciBhbnkgb25l IHdvcmtpbmcgZ3JvdXAgdG8gcmVhc29uYWJseSBoYW5kbGUuIEluc3RlYWQsIHRoZSBpbnRlbnRp b24gd2FzIHRoYXQgdGhlIERJU1BBVENIIG1vZGVsIG9mIGNyZWF0aW5nIHNtYWxsLCBzaG9ydC1s aXZlZCB3b3JraW5nIGdyb3VwcyBmb3Igc3BlY2lmaWMgdG9waWNzIHdvdWxkIGJlIGEgYmV0dGVy IHdheSB0byBtYW5hZ2UgdGhlIHJlbGF0aXZlbHkgaGVhdnkgd29ya2xvYWQuDQoNCkZhc3QgZm9y d2FyZCBzZXZlbiB5ZWFycyB0byB0b2RheS4gU0lQIGlzIGEgbXVjaCBtb3JlIG1hdHVyZSBwcm90 b2NvbCwgYW5kIHRoZSBpbmZsb3cgb2YgbmV3IHdvcmsgaXMgc2lnbmlmaWNhbnRseSBzbWFsbGVy IHRoYW4gaXQgd2FzIGJhY2sgdGhlbi4gQXQgdGhlIHNhbWUgdGltZSwgd2UgaGF2ZSBoYWQgc2V2 ZXJhbCBzbWFsbCwgc2VsZi1jb250YWluZWQgd29yayBpdGVtcyBzaG93IHVwIGluIERJU1BBVENI IHRoYXQgd2VyZSBkZWVtZWQgdG9vIHNtYWxsIHRvIGNyZWF0ZSBhIG5ldyB3b3JraW5nIGdyb3Vw IGZvciwgYnV0IHByZWNsdWRlZCBmcm9tIGJlaW5nIGRpc3BhdGNoZWQgdG8gU0lQQ09SRSBieSBp dHMgY2hhcnRlci4gVGhpcyBoYXMgbGVkIHRvIHVubmVjZXNzYXJ5IGRlbGF5cyBhcyB3ZSBkZXRl cm1pbmVkIHRoZSBiZXN0IGRpc3Bvc2l0aW9uIGZvciB0aGVzZSBpdGVtcy4NCg0KV2UsIHRoZSBT SVBDT1JFIGNoYWlycyBhbmQgYXJlYSBkaXJlY3Rvciwgc2VlayB0byBmaXggdGhhdC4gV2Ugd291 bGQgbGlrZSB0byBhbWVuZCB0aGUgU0lQQ09SRSBjaGFydGVyIHRvIGFsbG93IGl0IHRvIHRha2Ug b24gc21hbGwsIHNlbGYtY29udGFpbmVkIHByb3RvY29sIGV4dGVuc2lvbnMgaW4gYWRkaXRpb24g dG8gY2hhbmdlcyB0byB0aGUgY29yZSBTSVAgcHJvdG9jb2wuIFRoaXMgaXMgYSByZWxhdGl2ZWx5 IG1pbm9yIHVwZGF0ZSB0byB0aGUgZXhpc3RpbmcgY2hhcnRlciwgd2hpY2ggZXhwYW5kcyB0aGUg c2NvcGUgYXMgZGVzY3JpYmVkIGFib3ZlLCBhbmQgYWRkcyBiYWNrIGluIHR3byBvZiB0aGUgYXJj aGl0ZWN0dXJhbCBwcmluY2lwbGVzIGZyb20gdGhlIFNJUCBjaGFydGVyIHdoaWNoIGFyZSBhcHBs aWNhYmxlIG9ubHkgdG8gcHJvdG9jb2wgZXh0ZW5zaW9ucy4NCg0KUGxlYXNlIHByb3ZpZGUgZmVl ZGJhY2sgb24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYnkgc2VuZGluZyBlbWFpbCB0byB0aGUgU0lQ Q09SRSBtYWlsaW5nIGxpc3QuIFdlIHdpbGwgYWxzbyBkaXNjdXNzIHRoaXMgYnJpZWZseSBkdXJp bmcgdGhlIERJU1BBVENIIHNlc3Npb24gaW4gU2VvdWwuDQoNClRoZSBwcm9wb3NlZCBjaGFydGVy IHRleHQgZm9sbG93cy4NCg0KDQpUaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUg KFNJUENvcmUpIHdvcmtpbmcgZ3JvdXAgaXMNCmNoYXJ0ZXJlZCB0byBtYWludGFpbiBhbmQgY29u dGludWUgdGhlIGRldmVsb3BtZW50IG9mIHRoZSBTSVAgcHJvdG9jb2wsDQpjdXJyZW50bHkgZGVm aW5lZCBhcyBwcm9wb3NlZCBzdGFuZGFyZCBSRkNzIDMyNjEsIDMyNjIsIDMyNjMsIDMyNjQsIGFu ZA0KNjY2NS4NCg0KVGhlIFNJUENvcmUgd29ya2luZyBncm91cCB3aWxsIGNvbmNlbnRyYXRlIG9u IHNwZWNpZmljYXRpb25zIHRoYXQgdXBkYXRlDQpvciByZXBsYWNlIHRoZSBjb3JlIFNJUCBzcGVj aWZpY2F0aW9ucyBuYW1lZCBhYm92ZSBhcyB3ZWxsIGFzDQpzcGVjaWZpY2F0aW9ucyBwZXJ0YWlu aW5nIHRvIHNtYWxsLCBzZWxmLWNvbnRhaW5lZCBTSVAgcHJvdG9jb2wNCmV4dGVuc2lvbnMuICBU aGUgcHJvY2VzcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBuZXcgU0lQIGV4dGVuc2lvbnMgYXJlDQpk b2N1bWVudGVkIGluIFJGQzU3MjcsICJDaGFuZ2UgUHJvY2VzcyBmb3IgdGhlIFNlc3Npb24gSW5p dGlhdGlvbg0KUHJvdG9jb2wiLg0KDQpUaHJvdWdob3V0IGl0cyB3b3JrLCB0aGUgZ3JvdXAgd2ls bCBzdHJpdmUgdG8gbWFpbnRhaW4gdGhlIGJhc2ljIG1vZGVsDQphbmQgYXJjaGl0ZWN0dXJlIGRl ZmluZWQgYnkgU0lQLiBJbiBwYXJ0aWN1bGFyOg0KDQoxLiBTZXJ2aWNlcyBhbmQgZmVhdHVyZXMg YXJlIHByb3ZpZGVkIGVuZC10by1lbmQgd2hlbmV2ZXIgcG9zc2libGUuDQoNCjIuIFJldXNlIG9m IGV4aXN0aW5nIEludGVybmV0IHByb3RvY29scyBhbmQgYXJjaGl0ZWN0dXJlcyBhbmQNCiAgIGlu dGVncmF0aW5nIHdpdGggb3RoZXIgSW50ZXJuZXQgYXBwbGljYXRpb25zIGlzIGNydWNpYWwuDQoN CjMuIFN0YW5kYXJkcy10cmFjayBleHRlbnNpb25zIGFuZCBuZXcgZmVhdHVyZXMgbXVzdCBiZSBn ZW5lcmFsbHkNCiAgIGFwcGxpY2FibGUsIGFuZCBub3QgYXBwbGljYWJsZSBvbmx5IHRvIGEgc3Bl Y2lmaWMgc2V0IG9mIHNlc3Npb24NCiAgIHR5cGVzLg0KDQo0LiBTaW1wbGVyIHNvbHV0aW9ucyB0 aGF0IHNvbHZlIGEgZ2l2ZW4gcHJvYmxlbSBzaG91bGQgYmUgZmF2b3JlZA0KICAgIG92ZXIgbW9y ZSBjb21wbGV4IHNvbHV0aW9ucy4NCg0KVGhlIHByaW1hcnkgc291cmNlIG9mIGNoYW5nZSByZXF1 aXJlbWVudHMgdG8gdGhlIGNvcmUgU0lQIHNwZWNpZmljYXRpb25zDQooZW51bWVyYXRlZCBhYm92 ZSkgd2lsbCBiZSBhKSBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIHRoYXQgc3RlbSBmcm9tDQph bWJpZ3VvdXMsIG9yIHVuZGVyLWRlZmluZWQgc3BlY2lmaWNhdGlvbiwgYW5kIGIpIHJlcXVpcmVt ZW50cyBmcm9tDQpvdGhlciB3b3JraW5nIGdyb3VwcyBpbiB0aGUgQVJUIEFyZWEuIFRoZSBwcmlt YXJ5IHNvdXJjZSBvZiBuZXcgcHJvdG9jb2wNCmV4dGVuc2lvbnMgaXMgdGhlIERJU1BBVENIIHdv cmtpbmcgZ3JvdXAsIHdoaWNoIHdpbGwgZ2VuZXJhbGx5IG1ha2UgdGhlDQpkZXRlcm1pbmF0aW9u IHJlZ2FyZGluZyB3aGV0aGVyIG5ldyBTSVAtcmVsYXRlZCB3b3JrIHdhcnJhbnRzIGEgbmV3DQp3 b3JraW5nIGdyb3VwIG9yIGJlbG9uZ3MgaW4gYW4gZXhpc3Rpbmcgb25lLg0KDQoNCg0KRm9yIGVh c2Ugb2YgcmVmZXJlbmNlLCB0aGUgZXhpc3RpbmcgU0lQQ09SRSBjaGFydGVyIGlzIGF0IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zaXBjb3JlLw0KDQpUaGFu a3MhDQoNCi9hDQo= --_000_949EF20990823C4C85C18D59AA11AD8BADFA8477FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmF1dGhvci1hLWx6 NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6DQoJe21zby1zdHlsZS1uYW1lOmF1 dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6O30NCnNwYW4uYXV0 aG9yLWEtbHo3Nnp6NzJ6ejY4eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0eg0KCXttc28tc3R5bGUt bmFtZTphdXRob3ItYS1sejc2eno3Mnp6Njh6ejc2emZuejgwemljZGZwbHo4Mnp6ODR6O30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Tm90ZSB0aGF0IEkgZG9u4oCZdCBhY3R1YWxseSB0aGluayBpdCB3YXMgdGhl IHZvbHVtZSBvZiB3b3JrIOKAkyBJIHRoaW5rIGl0IHdhcyBtb3JlIEN1bGxlbiBKZW5uaW5ncyB0 cnlpbmcgdG8gZ2V0IHJpZCBvZiBhdCBsZWFzdCB0d28gd29ya2luZyBncm91cCBjaGFpcnMgaGUg ZGlkDQogbm90IGxpa2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PdGhlcndpc2Ugd2h5IHRoZSBub24tYXBwZWFyYW5j ZSBvZiBhbnkgb2YgdGhvc2UgV0cgY2hhaXJzIGluIHRoZSByZXN0cnVjdHVyZWQgb3JnYW5pc2F0 aW9uPyBFdmVyeSBvdGhlciBzcGxpdCBoYXMgcmV0YWluZWQgV0cgY2hhaXJzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ S2VpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 Ij4gZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5BZGFtIFJvYWNoPGJyPg0KPGI+U2VudDo8L2I+IDA0IE5vdmVtYmVyIDIwMTYg MjE6Mjg8YnI+DQo8Yj5Ubzo8L2I+ICdTSVBDT1JFJzsgZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQo8 Yj5DYzo8L2I+IGFydC1hZHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Rpc3BhdGNo XSBTSVBDT1JFIFJlY2hhcnRlcmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlthcyBT SVBDT1JFIGNoYWlyXTxvOnA+PC9vOnA+PC9wPg0KPHA+QmFjayB3aGVuIHdlIHRyYW5zaXRpb25l ZCBmcm9tIHRoZSBTSVBQSU5HL1NJUCB3b3JraW5nIGdyb3VwIHN0cnVjdHVyZSB0byBTSVBDT1JF LCB3ZSBwdXQgcmVsYXRpdmVseSB0aWdodCBsaW1pdHMgb24gdGhlIFNJUENPUkUgY2hhcnRlci4g VGhpcyB3YXMgYSByZWNvZ25pdGlvbiBvZiB0aGUgZmFjdCB0aGF0IHRoZSB2b2x1bWUgb2YgU0lQ LXJlbGF0ZWQgd29yayBhdCB0aGUgdGltZSB3YXMgdG9vIGxhcmdlIGZvciBhbnkgb25lIHdvcmtp bmcNCiBncm91cCB0byByZWFzb25hYmx5IGhhbmRsZS4gSW5zdGVhZCwgdGhlIGludGVudGlvbiB3 YXMgdGhhdCB0aGUgRElTUEFUQ0ggbW9kZWwgb2YgY3JlYXRpbmcgc21hbGwsIHNob3J0LWxpdmVk IHdvcmtpbmcgZ3JvdXBzIGZvciBzcGVjaWZpYyB0b3BpY3Mgd291bGQgYmUgYSBiZXR0ZXIgd2F5 IHRvIG1hbmFnZSB0aGUgcmVsYXRpdmVseSBoZWF2eSB3b3JrbG9hZC48bzpwPjwvbzpwPjwvcD4N CjxwPkZhc3QgZm9yd2FyZCBzZXZlbiB5ZWFycyB0byB0b2RheS4gU0lQIGlzIGEgbXVjaCBtb3Jl IG1hdHVyZSBwcm90b2NvbCwgYW5kIHRoZSBpbmZsb3cgb2YgbmV3IHdvcmsgaXMgc2lnbmlmaWNh bnRseSBzbWFsbGVyIHRoYW4gaXQgd2FzIGJhY2sgdGhlbi4gQXQgdGhlIHNhbWUgdGltZSwgd2Ug aGF2ZSBoYWQgc2V2ZXJhbCBzbWFsbCwgc2VsZi1jb250YWluZWQgd29yayBpdGVtcyBzaG93IHVw IGluIERJU1BBVENIIHRoYXQgd2VyZSBkZWVtZWQNCiB0b28gc21hbGwgdG8gY3JlYXRlIGEgbmV3 IHdvcmtpbmcgZ3JvdXAgZm9yLCBidXQgcHJlY2x1ZGVkIGZyb20gYmVpbmcgZGlzcGF0Y2hlZCB0 byBTSVBDT1JFIGJ5IGl0cyBjaGFydGVyLiBUaGlzIGhhcyBsZWQgdG8gdW5uZWNlc3NhcnkgZGVs YXlzIGFzIHdlIGRldGVybWluZWQgdGhlIGJlc3QgZGlzcG9zaXRpb24gZm9yIHRoZXNlIGl0ZW1z LjxvOnA+PC9vOnA+PC9wPg0KPHA+V2UsIHRoZSBTSVBDT1JFIGNoYWlycyBhbmQgYXJlYSBkaXJl Y3Rvciwgc2VlayB0byBmaXggdGhhdC4gV2Ugd291bGQgbGlrZSB0byBhbWVuZCB0aGUgU0lQQ09S RSBjaGFydGVyIHRvIGFsbG93IGl0IHRvIHRha2Ugb24gc21hbGwsIHNlbGYtY29udGFpbmVkIHBy b3RvY29sIGV4dGVuc2lvbnMgaW4gYWRkaXRpb24gdG8gY2hhbmdlcyB0byB0aGUgY29yZSBTSVAg cHJvdG9jb2wuIFRoaXMgaXMgYSByZWxhdGl2ZWx5IG1pbm9yIHVwZGF0ZSB0bw0KIHRoZSBleGlz dGluZyBjaGFydGVyLCB3aGljaCBleHBhbmRzIHRoZSBzY29wZSBhcyBkZXNjcmliZWQgYWJvdmUs IGFuZCBhZGRzIGJhY2sgaW4gdHdvIG9mIHRoZSBhcmNoaXRlY3R1cmFsIHByaW5jaXBsZXMgZnJv bSB0aGUgU0lQIGNoYXJ0ZXIgd2hpY2ggYXJlIGFwcGxpY2FibGUgb25seSB0byBwcm90b2NvbCBl eHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIHByb3ZpZGUgZmVlZGJhY2sgb24g dGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYnkgc2VuZGluZyBlbWFpbCB0byB0aGUgU0lQQ09SRSBtYWls aW5nIGxpc3QuIFdlIHdpbGwgYWxzbyBkaXNjdXNzIHRoaXMgYnJpZWZseSBkdXJpbmcgdGhlIERJ U1BBVENIIHNlc3Npb24gaW4gU2VvdWwuPG86cD48L286cD48L3A+DQo8cD5UaGUgcHJvcG9zZWQg Y2hhcnRlciB0ZXh0IGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdiBpZD0ibWFnaWNkb21pZDIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6 Ij5UaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUgKFNJUENvcmUpIHdvcmtpbmcg Z3JvdXAgaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9t aWQzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3 M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Y2hhcnRlcmVkIHRvIG1haW50YWluIGFu ZCBjb250aW51ZSB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbCw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216 Njd6OXo4NXp6MTIyeiI+Y3VycmVudGx5IGRlZmluZWQgYXMgcHJvcG9zZWQgc3RhbmRhcmQgUkZD cyAzMjYxLCAzMjYyLCAzMjYzLCAzMjY0LCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ1Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+NjY2 NS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ2Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtYWdpY2RvbWlkNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0 aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPlRoZSBTSVBDb3Jl IHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25jZW50cmF0ZSBvbiBzcGVjaWZpY2F0aW9ucyB0aGF0IHVw ZGF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDgi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6 NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij5vciByZXBsYWNlIHRoZSBjb3JlIFNJUCBzcGVj aWZpY2F0aW9ucyBuYW1lZCBhYm92ZSBhcyB3ZWxsIGFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkOSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoi PnNwZWNpZmljYXRpb25zIHBlcnRhaW5pbmcgdG8gc21hbGwsIHNlbGYtY29udGFpbmVkIFNJUCBw cm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21p ZDEwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3 M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+ZXh0ZW5zaW9ucy4mbmJzcDsgVGhlIHBy b2Nlc3MgYW5kIHJlcXVpcmVtZW50cyBmb3IgbmV3IFNJUCBleHRlbnNpb25zIGFyZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDExIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtp c216Njd6OXo4NXp6MTIyeiI+ZG9jdW1lbnRlZCBpbiBSRkM1NzI3LCAmcXVvdDtDaGFuZ2UgUHJv Y2VzcyBmb3IgdGhlIFNlc3Npb24gSW5pdGlhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDEyIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+ UHJvdG9jb2wmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkMTMiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEy MnoiPlRocm91Z2hvdXQgaXRzIHdvcmssIHRoZSBncm91cCB3aWxsIHN0cml2ZSB0byBtYWludGFp biB0aGUgYmFzaWMgbW9kZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Im1hZ2ljZG9taWQxNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9y LWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPmFuZCBhcmNoaXRlY3R1 cmUgZGVmaW5lZCBieSBTSVAuIEluIHBhcnRpY3VsYXI6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMTYiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNyI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6 ZWRraXNtejY3ejl6ODV6ejEyMnoiPjEuIFNlcnZpY2VzIGFuZCBmZWF0dXJlcyBhcmUgcHJvdmlk ZWQgZW5kLXRvLWVuZCB3aGVuZXZlciBwb3NzaWJsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxOCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDE5Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHpl ZGtpc216Njd6OXo4NXp6MTIyeiI+Mi4gUmV1c2Ugb2YgZXhpc3RpbmcgSW50ZXJuZXQgcHJvdG9j b2xzIGFuZCBhcmNoaXRlY3R1cmVzIGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ibWFnaWNkb21pZDIwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Jm5ic3A7 Jm5ic3A7IGludGVncmF0aW5nIHdpdGggb3RoZXIgSW50ZXJuZXQgYXBwbGljYXRpb25zIGlzIGNy dWNpYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlk MjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9Im1hZ2ljZG9taWQyMiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPjMuIFN0 YW5kYXJkcy10cmFjayBleHRlbnNpb25zIGFuZCBuZXcgZmVhdHVyZXMgbXVzdCBiZSBnZW5lcmFs bHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyMyI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3 M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPiZuYnNwOyZuYnNwOyBhcHBsaWNhYmxlLCBhbmQg bm90IGFwcGxpY2FibGUgb25seSB0byBhIHNwZWNpZmljIHNldCBvZiBzZXNzaW9uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lz bXo2N3o5ejg1enoxMjJ6Ij4mbmJzcDsmbmJzcDsgdHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyNiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4eno3 Nnpmbno4MHppY2RmcGx6ODJ6ejg0eiI+NC4gU2ltcGxlciBzb2x1dGlvbnMgdGhhdCBzb2x2ZSBh IGdpdmVuIHByb2JsZW0gc2hvdWxkIGJlIGZhdm9yZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0eiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IG92ZXIgbW9yZSBjb21wbGV4IHNvbHV0aW9ucy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyOCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNk b21pZDI5Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcw eno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+VGhlIHByaW1hcnkgc291cmNlIG9m IGNoYW5nZSByZXF1aXJlbWVudHMgdG8gdGhlIGNvcmUgU0lQIHNwZWNpZmljYXRpb25zPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzAiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVk a2lzbXo2N3o5ejg1enoxMjJ6Ij4oZW51bWVyYXRlZCBhYm92ZSkgd2lsbCBiZSBhKSBpbnRlcm9w ZXJhYmlsaXR5IHByb2JsZW1zIHRoYXQgc3RlbSBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6 Ij5hbWJpZ3VvdXMsIG9yIHVuZGVyLWRlZmluZWQgc3BlY2lmaWNhdGlvbiwgYW5kIGIpIHJlcXVp cmVtZW50cyBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdp Y2RvbWlkMzIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6 NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij5vdGhlciB3b3JraW5nIGdyb3Vw cyBpbiB0aGUgQVJUIEFyZWEuIFRoZSBwcmltYXJ5IHNvdXJjZSBvZiBuZXcgcHJvdG9jb2w8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQzMyI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6 ZWRraXNtejY3ejl6ODV6ejEyMnoiPmV4dGVuc2lvbnMgaXMgdGhlIERJU1BBVENIIHdvcmtpbmcg Z3JvdXAsIHdoaWNoIHdpbGwgZ2VuZXJhbGx5IG1ha2UgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enox MjJ6Ij5kZXRlcm1pbmF0aW9uIHJlZ2FyZGluZyB3aGV0aGVyIG5ldyBTSVAtcmVsYXRlZCB3b3Jr IHdhcnJhbnRzIGEgbmV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkMzUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1h LWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij53b3JraW5nIGdyb3VwIG9y IGJlbG9uZ3MgaW4gYW4gZXhpc3Rpbmcgb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5Gb3IgZWFzZSBv ZiByZWZlcmVuY2UsIHRoZSBleGlzdGluZyBTSVBDT1JFIGNoYXJ0ZXIgaXMgYXQgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLXNpcGNvcmUvIj4N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zaXBjb3JlLzwv YT48bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjxwPi9hPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_949EF20990823C4C85C18D59AA11AD8BADFA8477FR712WXCHMBA11z_-- From nobody Sun Nov 6 05:47:55 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BE6129898; Sun, 6 Nov 2016 05:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvNXxvS-GiSS; Sun, 6 Nov 2016 05:47:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A510912988F; Sun, 6 Nov 2016 05:47:45 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C1DFC5EE21A14; Sun, 6 Nov 2016 13:47:40 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA6DlgUC009705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Nov 2016 13:47:43 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uA6Dlgin025252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Nov 2016 14:47:42 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.214]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Sun, 6 Nov 2016 14:47:42 +0100 From: "Drage, Keith (Nokia - GB)" To: "'SIPCORE'" , "dispatch@ietf.org" Thread-Topic: [dispatch] SIPCORE Rechartering Thread-Index: AQHSNuJbof3GUTb0uE6yIgkvbI355qDL81hQ Date: Sun, 6 Nov 2016 13:47:41 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFA846B@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADFA846BFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "art-ads@ietf.org" Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 13:47:50 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADFA846BFR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyaGFwcyB5b3UgY291aWxkIGVsYWJvcmF0ZSBvbiBob3cgeW91IG5vdyBzZWUgdGhlIHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIFNJUENPUkUgYW5kIERJU1BBVENILiBJdCBpcyBub3QgY2xlYXIgdG8g bWUgd2hhdCB0aGUgY3JpdGVyaWEgYXJlIGZvciBzdWJtaXR0aW5nIHNvbWV0aGluZyBuZXcgdG8g RElTUEFUQ0gsIHZlcnN1cyBTSVBDT1JFIGRpcmVjdGx5Lg0KDQpXb3VsZCBldmVyeXRoaW5nIGdv IHRvIERJU1BBVENIIGZpcnN0IGFuZCB0aGUgY2hhbmdlIGhlcmUgaXMgdG8gYWxsb3cgU0lQQ09S RSB0byB0YWtlIG9uIHdvcmsgdGhhdCBoYXMgYmVlbiBkaXNwYXRjaGVkLCBvciB3b3VsZCBTSVBD T1JFIGJlIHRoZSBmaXJzdCBwb2ludCBvZiBlbnRyeSBmb3IgbWF0ZXJpYWwsIGFuZCBpZiBzbywg dG8gd2hhdCBzY29wZS4NCg0KRmluYWxseSwgc29tZSBzdHVmZiBmcm9tIERJU1BBVENIIGhhcyBn b25lIGRpcmVjdCB0byBBRCBzcG9uc29yZWQg4oCTIHdvdWxkIHlvdSBub3cgc2VlIHRob3NlIGJl Y29taW5nIFdHIGl0ZW1zIG9mIFNJUENPUkUsIG9yIHdvdWxkIHRoYXQgcm91dGUgc3RpbGwgYmUg ZW52aXNhZ2VkLCBhbmQgaWYgc28sIHdvdWxkIHRoZSDigJxkaXNwYXRjaOKAnSBvY2N1ciBmcm9t IERJU1BBVENIIG9yIFNJUENPUkUuDQoNCk1heWJlIHlvdSBjb3VsZCB1c2Ugc29tZSByZWNlbnQg ZHJhZnRzIGFuZCBSRkNzIGFzIGV4YW1wbGVzIG9mIHdoZXJlIHlvdSB0aGluayB0aGluZ3Mgd2ls bCBjaGFuZ2UuDQoNCktlaXRoDQoNCkZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNClNlbnQ6IDA0IE5vdmVtYmVy IDIwMTYgMjE6MjgNClRvOiAnU0lQQ09SRSc7IGRpc3BhdGNoQGlldGYub3JnDQpDYzogYXJ0LWFk c0BpZXRmLm9yZw0KU3ViamVjdDogW2Rpc3BhdGNoXSBTSVBDT1JFIFJlY2hhcnRlcmluZw0KDQoN ClthcyBTSVBDT1JFIGNoYWlyXQ0KDQpCYWNrIHdoZW4gd2UgdHJhbnNpdGlvbmVkIGZyb20gdGhl IFNJUFBJTkcvU0lQIHdvcmtpbmcgZ3JvdXAgc3RydWN0dXJlIHRvIFNJUENPUkUsIHdlIHB1dCBy ZWxhdGl2ZWx5IHRpZ2h0IGxpbWl0cyBvbiB0aGUgU0lQQ09SRSBjaGFydGVyLiBUaGlzIHdhcyBh IHJlY29nbml0aW9uIG9mIHRoZSBmYWN0IHRoYXQgdGhlIHZvbHVtZSBvZiBTSVAtcmVsYXRlZCB3 b3JrIGF0IHRoZSB0aW1lIHdhcyB0b28gbGFyZ2UgZm9yIGFueSBvbmUgd29ya2luZyBncm91cCB0 byByZWFzb25hYmx5IGhhbmRsZS4gSW5zdGVhZCwgdGhlIGludGVudGlvbiB3YXMgdGhhdCB0aGUg RElTUEFUQ0ggbW9kZWwgb2YgY3JlYXRpbmcgc21hbGwsIHNob3J0LWxpdmVkIHdvcmtpbmcgZ3Jv dXBzIGZvciBzcGVjaWZpYyB0b3BpY3Mgd291bGQgYmUgYSBiZXR0ZXIgd2F5IHRvIG1hbmFnZSB0 aGUgcmVsYXRpdmVseSBoZWF2eSB3b3JrbG9hZC4NCg0KRmFzdCBmb3J3YXJkIHNldmVuIHllYXJz IHRvIHRvZGF5LiBTSVAgaXMgYSBtdWNoIG1vcmUgbWF0dXJlIHByb3RvY29sLCBhbmQgdGhlIGlu ZmxvdyBvZiBuZXcgd29yayBpcyBzaWduaWZpY2FudGx5IHNtYWxsZXIgdGhhbiBpdCB3YXMgYmFj ayB0aGVuLiBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBoYXZlIGhhZCBzZXZlcmFsIHNtYWxsLCBzZWxm LWNvbnRhaW5lZCB3b3JrIGl0ZW1zIHNob3cgdXAgaW4gRElTUEFUQ0ggdGhhdCB3ZXJlIGRlZW1l ZCB0b28gc21hbGwgdG8gY3JlYXRlIGEgbmV3IHdvcmtpbmcgZ3JvdXAgZm9yLCBidXQgcHJlY2x1 ZGVkIGZyb20gYmVpbmcgZGlzcGF0Y2hlZCB0byBTSVBDT1JFIGJ5IGl0cyBjaGFydGVyLiBUaGlz IGhhcyBsZWQgdG8gdW5uZWNlc3NhcnkgZGVsYXlzIGFzIHdlIGRldGVybWluZWQgdGhlIGJlc3Qg ZGlzcG9zaXRpb24gZm9yIHRoZXNlIGl0ZW1zLg0KDQpXZSwgdGhlIFNJUENPUkUgY2hhaXJzIGFu ZCBhcmVhIGRpcmVjdG9yLCBzZWVrIHRvIGZpeCB0aGF0LiBXZSB3b3VsZCBsaWtlIHRvIGFtZW5k IHRoZSBTSVBDT1JFIGNoYXJ0ZXIgdG8gYWxsb3cgaXQgdG8gdGFrZSBvbiBzbWFsbCwgc2VsZi1j b250YWluZWQgcHJvdG9jb2wgZXh0ZW5zaW9ucyBpbiBhZGRpdGlvbiB0byBjaGFuZ2VzIHRvIHRo ZSBjb3JlIFNJUCBwcm90b2NvbC4gVGhpcyBpcyBhIHJlbGF0aXZlbHkgbWlub3IgdXBkYXRlIHRv IHRoZSBleGlzdGluZyBjaGFydGVyLCB3aGljaCBleHBhbmRzIHRoZSBzY29wZSBhcyBkZXNjcmli ZWQgYWJvdmUsIGFuZCBhZGRzIGJhY2sgaW4gdHdvIG9mIHRoZSBhcmNoaXRlY3R1cmFsIHByaW5j aXBsZXMgZnJvbSB0aGUgU0lQIGNoYXJ0ZXIgd2hpY2ggYXJlIGFwcGxpY2FibGUgb25seSB0byBw cm90b2NvbCBleHRlbnNpb25zLg0KDQpQbGVhc2UgcHJvdmlkZSBmZWVkYmFjayBvbiB0aGUgcHJv cG9zZWQgY2hhcnRlciBieSBzZW5kaW5nIGVtYWlsIHRvIHRoZSBTSVBDT1JFIG1haWxpbmcgbGlz dC4gV2Ugd2lsbCBhbHNvIGRpc2N1c3MgdGhpcyBicmllZmx5IGR1cmluZyB0aGUgRElTUEFUQ0gg c2Vzc2lvbiBpbiBTZW91bC4NCg0KVGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBmb2xsb3dzLg0K DQoNClRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSAoU0lQQ29yZSkgd29ya2lu ZyBncm91cCBpcw0KY2hhcnRlcmVkIHRvIG1haW50YWluIGFuZCBjb250aW51ZSB0aGUgZGV2ZWxv cG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbCwNCmN1cnJlbnRseSBkZWZpbmVkIGFzIHByb3Bvc2Vk IHN0YW5kYXJkIFJGQ3MgMzI2MSwgMzI2MiwgMzI2MywgMzI2NCwgYW5kDQo2NjY1Lg0KDQpUaGUg U0lQQ29yZSB3b3JraW5nIGdyb3VwIHdpbGwgY29uY2VudHJhdGUgb24gc3BlY2lmaWNhdGlvbnMg dGhhdCB1cGRhdGUNCm9yIHJlcGxhY2UgdGhlIGNvcmUgU0lQIHNwZWNpZmljYXRpb25zIG5hbWVk IGFib3ZlIGFzIHdlbGwgYXMNCnNwZWNpZmljYXRpb25zIHBlcnRhaW5pbmcgdG8gc21hbGwsIHNl bGYtY29udGFpbmVkIFNJUCBwcm90b2NvbA0KZXh0ZW5zaW9ucy4gIFRoZSBwcm9jZXNzIGFuZCBy ZXF1aXJlbWVudHMgZm9yIG5ldyBTSVAgZXh0ZW5zaW9ucyBhcmUNCmRvY3VtZW50ZWQgaW4gUkZD NTcyNywgIkNoYW5nZSBQcm9jZXNzIGZvciB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uDQpQcm90b2Nv bCIuDQoNClRocm91Z2hvdXQgaXRzIHdvcmssIHRoZSBncm91cCB3aWxsIHN0cml2ZSB0byBtYWlu dGFpbiB0aGUgYmFzaWMgbW9kZWwNCmFuZCBhcmNoaXRlY3R1cmUgZGVmaW5lZCBieSBTSVAuIElu IHBhcnRpY3VsYXI6DQoNCjEuIFNlcnZpY2VzIGFuZCBmZWF0dXJlcyBhcmUgcHJvdmlkZWQgZW5k LXRvLWVuZCB3aGVuZXZlciBwb3NzaWJsZS4NCg0KMi4gUmV1c2Ugb2YgZXhpc3RpbmcgSW50ZXJu ZXQgcHJvdG9jb2xzIGFuZCBhcmNoaXRlY3R1cmVzIGFuZA0KICAgaW50ZWdyYXRpbmcgd2l0aCBv dGhlciBJbnRlcm5ldCBhcHBsaWNhdGlvbnMgaXMgY3J1Y2lhbC4NCg0KMy4gU3RhbmRhcmRzLXRy YWNrIGV4dGVuc2lvbnMgYW5kIG5ldyBmZWF0dXJlcyBtdXN0IGJlIGdlbmVyYWxseQ0KICAgYXBw bGljYWJsZSwgYW5kIG5vdCBhcHBsaWNhYmxlIG9ubHkgdG8gYSBzcGVjaWZpYyBzZXQgb2Ygc2Vz c2lvbg0KICAgdHlwZXMuDQoNCjQuIFNpbXBsZXIgc29sdXRpb25zIHRoYXQgc29sdmUgYSBnaXZl biBwcm9ibGVtIHNob3VsZCBiZSBmYXZvcmVkDQogICAgb3ZlciBtb3JlIGNvbXBsZXggc29sdXRp b25zLg0KDQpUaGUgcHJpbWFyeSBzb3VyY2Ugb2YgY2hhbmdlIHJlcXVpcmVtZW50cyB0byB0aGUg Y29yZSBTSVAgc3BlY2lmaWNhdGlvbnMNCihlbnVtZXJhdGVkIGFib3ZlKSB3aWxsIGJlIGEpIGlu dGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgdGhhdCBzdGVtIGZyb20NCmFtYmlndW91cywgb3IgdW5k ZXItZGVmaW5lZCBzcGVjaWZpY2F0aW9uLCBhbmQgYikgcmVxdWlyZW1lbnRzIGZyb20NCm90aGVy IHdvcmtpbmcgZ3JvdXBzIGluIHRoZSBBUlQgQXJlYS4gVGhlIHByaW1hcnkgc291cmNlIG9mIG5l dyBwcm90b2NvbA0KZXh0ZW5zaW9ucyBpcyB0aGUgRElTUEFUQ0ggd29ya2luZyBncm91cCwgd2hp Y2ggd2lsbCBnZW5lcmFsbHkgbWFrZSB0aGUNCmRldGVybWluYXRpb24gcmVnYXJkaW5nIHdoZXRo ZXIgbmV3IFNJUC1yZWxhdGVkIHdvcmsgd2FycmFudHMgYSBuZXcNCndvcmtpbmcgZ3JvdXAgb3Ig YmVsb25ncyBpbiBhbiBleGlzdGluZyBvbmUuDQoNCg0KDQpGb3IgZWFzZSBvZiByZWZlcmVuY2Us IHRoZSBleGlzdGluZyBTSVBDT1JFIGNoYXJ0ZXIgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLXNpcGNvcmUvDQoNClRoYW5rcyENCg0KL2ENCg== --_000_949EF20990823C4C85C18D59AA11AD8BADFA846BFR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmF1dGhvci1hLWx6 NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6DQoJe21zby1zdHlsZS1uYW1lOmF1 dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6O30NCnNwYW4uYXV0 aG9yLWEtbHo3Nnp6NzJ6ejY4eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0eg0KCXttc28tc3R5bGUt bmFtZTphdXRob3ItYS1sejc2eno3Mnp6Njh6ejc2emZuejgwemljZGZwbHo4Mnp6ODR6O30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UGVyaGFwcyB5b3UgY291aWxkIGVsYWJvcmF0ZSBvbiBob3cgeW91IG5vdyBz ZWUgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFNJUENPUkUgYW5kIERJU1BBVENILiBJdCBpcyBu b3QgY2xlYXIgdG8gbWUgd2hhdCB0aGUgY3JpdGVyaWEgYXJlIGZvciBzdWJtaXR0aW5nIHNvbWV0 aGluZw0KIG5ldyB0byBESVNQQVRDSCwgdmVyc3VzIFNJUENPUkUgZGlyZWN0bHkuIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+V291bGQgZXZlcnl0aGluZyBnbyB0byBESVNQQVRDSCBmaXJzdCBhbmQgdGhlIGNoYW5nZSBo ZXJlIGlzIHRvIGFsbG93IFNJUENPUkUgdG8gdGFrZSBvbiB3b3JrIHRoYXQgaGFzIGJlZW4gZGlz cGF0Y2hlZCwgb3Igd291bGQgU0lQQ09SRSBiZSB0aGUgZmlyc3QgcG9pbnQNCiBvZiBlbnRyeSBm b3IgbWF0ZXJpYWwsIGFuZCBpZiBzbywgdG8gd2hhdCBzY29wZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpbmFsbHks IHNvbWUgc3R1ZmYgZnJvbSBESVNQQVRDSCBoYXMgZ29uZSBkaXJlY3QgdG8gQUQgc3BvbnNvcmVk IOKAkyB3b3VsZCB5b3Ugbm93IHNlZSB0aG9zZSBiZWNvbWluZyBXRyBpdGVtcyBvZiBTSVBDT1JF LCBvciB3b3VsZCB0aGF0IHJvdXRlIHN0aWxsIGJlIGVudmlzYWdlZCwNCiBhbmQgaWYgc28sIHdv dWxkIHRoZSDigJxkaXNwYXRjaOKAnSBvY2N1ciBmcm9tIERJU1BBVENIIG9yIFNJUENPUkUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5NYXliZSB5b3UgY291bGQgdXNlIHNvbWUgcmVjZW50IGRyYWZ0cyBhbmQgUkZDcyBh cyBleGFtcGxlcyBvZiB3aGVyZSB5b3UgdGhpbmsgdGhpbmdzIHdpbGwgY2hhbmdlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+S2VpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0 ZXh0Ij4gZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5BZGFtIFJvYWNoPGJyPg0KPGI+U2VudDo8L2I+IDA0IE5vdmVtYmVyIDIw MTYgMjE6Mjg8YnI+DQo8Yj5Ubzo8L2I+ICdTSVBDT1JFJzsgZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+ DQo8Yj5DYzo8L2I+IGFydC1hZHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Rpc3Bh dGNoXSBTSVBDT1JFIFJlY2hhcnRlcmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlth cyBTSVBDT1JFIGNoYWlyXTxvOnA+PC9vOnA+PC9wPg0KPHA+QmFjayB3aGVuIHdlIHRyYW5zaXRp b25lZCBmcm9tIHRoZSBTSVBQSU5HL1NJUCB3b3JraW5nIGdyb3VwIHN0cnVjdHVyZSB0byBTSVBD T1JFLCB3ZSBwdXQgcmVsYXRpdmVseSB0aWdodCBsaW1pdHMgb24gdGhlIFNJUENPUkUgY2hhcnRl ci4gVGhpcyB3YXMgYSByZWNvZ25pdGlvbiBvZiB0aGUgZmFjdCB0aGF0IHRoZSB2b2x1bWUgb2Yg U0lQLXJlbGF0ZWQgd29yayBhdCB0aGUgdGltZSB3YXMgdG9vIGxhcmdlIGZvciBhbnkgb25lIHdv cmtpbmcNCiBncm91cCB0byByZWFzb25hYmx5IGhhbmRsZS4gSW5zdGVhZCwgdGhlIGludGVudGlv biB3YXMgdGhhdCB0aGUgRElTUEFUQ0ggbW9kZWwgb2YgY3JlYXRpbmcgc21hbGwsIHNob3J0LWxp dmVkIHdvcmtpbmcgZ3JvdXBzIGZvciBzcGVjaWZpYyB0b3BpY3Mgd291bGQgYmUgYSBiZXR0ZXIg d2F5IHRvIG1hbmFnZSB0aGUgcmVsYXRpdmVseSBoZWF2eSB3b3JrbG9hZC48bzpwPjwvbzpwPjwv cD4NCjxwPkZhc3QgZm9yd2FyZCBzZXZlbiB5ZWFycyB0byB0b2RheS4gU0lQIGlzIGEgbXVjaCBt b3JlIG1hdHVyZSBwcm90b2NvbCwgYW5kIHRoZSBpbmZsb3cgb2YgbmV3IHdvcmsgaXMgc2lnbmlm aWNhbnRseSBzbWFsbGVyIHRoYW4gaXQgd2FzIGJhY2sgdGhlbi4gQXQgdGhlIHNhbWUgdGltZSwg d2UgaGF2ZSBoYWQgc2V2ZXJhbCBzbWFsbCwgc2VsZi1jb250YWluZWQgd29yayBpdGVtcyBzaG93 IHVwIGluIERJU1BBVENIIHRoYXQgd2VyZSBkZWVtZWQNCiB0b28gc21hbGwgdG8gY3JlYXRlIGEg bmV3IHdvcmtpbmcgZ3JvdXAgZm9yLCBidXQgcHJlY2x1ZGVkIGZyb20gYmVpbmcgZGlzcGF0Y2hl ZCB0byBTSVBDT1JFIGJ5IGl0cyBjaGFydGVyLiBUaGlzIGhhcyBsZWQgdG8gdW5uZWNlc3Nhcnkg ZGVsYXlzIGFzIHdlIGRldGVybWluZWQgdGhlIGJlc3QgZGlzcG9zaXRpb24gZm9yIHRoZXNlIGl0 ZW1zLjxvOnA+PC9vOnA+PC9wPg0KPHA+V2UsIHRoZSBTSVBDT1JFIGNoYWlycyBhbmQgYXJlYSBk aXJlY3Rvciwgc2VlayB0byBmaXggdGhhdC4gV2Ugd291bGQgbGlrZSB0byBhbWVuZCB0aGUgU0lQ Q09SRSBjaGFydGVyIHRvIGFsbG93IGl0IHRvIHRha2Ugb24gc21hbGwsIHNlbGYtY29udGFpbmVk IHByb3RvY29sIGV4dGVuc2lvbnMgaW4gYWRkaXRpb24gdG8gY2hhbmdlcyB0byB0aGUgY29yZSBT SVAgcHJvdG9jb2wuIFRoaXMgaXMgYSByZWxhdGl2ZWx5IG1pbm9yIHVwZGF0ZSB0bw0KIHRoZSBl eGlzdGluZyBjaGFydGVyLCB3aGljaCBleHBhbmRzIHRoZSBzY29wZSBhcyBkZXNjcmliZWQgYWJv dmUsIGFuZCBhZGRzIGJhY2sgaW4gdHdvIG9mIHRoZSBhcmNoaXRlY3R1cmFsIHByaW5jaXBsZXMg ZnJvbSB0aGUgU0lQIGNoYXJ0ZXIgd2hpY2ggYXJlIGFwcGxpY2FibGUgb25seSB0byBwcm90b2Nv bCBleHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIHByb3ZpZGUgZmVlZGJhY2sg b24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYnkgc2VuZGluZyBlbWFpbCB0byB0aGUgU0lQQ09SRSBt YWlsaW5nIGxpc3QuIFdlIHdpbGwgYWxzbyBkaXNjdXNzIHRoaXMgYnJpZWZseSBkdXJpbmcgdGhl IERJU1BBVENIIHNlc3Npb24gaW4gU2VvdWwuPG86cD48L286cD48L3A+DQo8cD5UaGUgcHJvcG9z ZWQgY2hhcnRlciB0ZXh0IGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdiBpZD0ibWFnaWNkb21pZDIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enox MjJ6Ij5UaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUgKFNJUENvcmUpIHdvcmtp bmcgZ3JvdXAgaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2lj ZG9taWQzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcw eno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Y2hhcnRlcmVkIHRvIG1haW50YWlu IGFuZCBjb250aW51ZSB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbCw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtp c216Njd6OXo4NXp6MTIyeiI+Y3VycmVudGx5IGRlZmluZWQgYXMgcHJvcG9zZWQgc3RhbmRhcmQg UkZDcyAzMjYxLCAzMjYyLCAzMjYzLCAzMjY0LCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ1Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+ NjY2NS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ2 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJtYWdpY2RvbWlkNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i YXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPlRoZSBTSVBD b3JlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25jZW50cmF0ZSBvbiBzcGVjaWZpY2F0aW9ucyB0aGF0 IHVwZGF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21p ZDgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejcz enR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij5vciByZXBsYWNlIHRoZSBjb3JlIFNJUCBz cGVjaWZpY2F0aW9ucyBuYW1lZCBhYm92ZSBhcyB3ZWxsIGFzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkOSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEy MnoiPnNwZWNpZmljYXRpb25zIHBlcnRhaW5pbmcgdG8gc21hbGwsIHNlbGYtY29udGFpbmVkIFNJ UCBwcm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNk b21pZDEwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcw eno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+ZXh0ZW5zaW9ucy4mbmJzcDsgVGhl IHByb2Nlc3MgYW5kIHJlcXVpcmVtZW50cyBmb3IgbmV3IFNJUCBleHRlbnNpb25zIGFyZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDExIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHpl ZGtpc216Njd6OXo4NXp6MTIyeiI+ZG9jdW1lbnRlZCBpbiBSRkM1NzI3LCAmcXVvdDtDaGFuZ2Ug UHJvY2VzcyBmb3IgdGhlIFNlc3Npb24gSW5pdGlhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDEyIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIy eiI+UHJvdG9jb2wmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtYWdpY2RvbWlkMTMiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6 ejEyMnoiPlRocm91Z2hvdXQgaXRzIHdvcmssIHRoZSBncm91cCB3aWxsIHN0cml2ZSB0byBtYWlu dGFpbiB0aGUgYmFzaWMgbW9kZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1hZ2ljZG9taWQxNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0 aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPmFuZCBhcmNoaXRl Y3R1cmUgZGVmaW5lZCBieSBTSVAuIEluIHBhcnRpY3VsYXI6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMTYiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNyI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6 NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPjEuIFNlcnZpY2VzIGFuZCBmZWF0dXJlcyBhcmUgcHJv dmlkZWQgZW5kLXRvLWVuZCB3aGVuZXZlciBwb3NzaWJsZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxOCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDE5Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3 NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Mi4gUmV1c2Ugb2YgZXhpc3RpbmcgSW50ZXJuZXQgcHJv dG9jb2xzIGFuZCBhcmNoaXRlY3R1cmVzIGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDIwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Jm5i c3A7Jm5ic3A7IGludGVncmF0aW5nIHdpdGggb3RoZXIgSW50ZXJuZXQgYXBwbGljYXRpb25zIGlz IGNydWNpYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2Rv bWlkMjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyMiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBj bGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPjMu IFN0YW5kYXJkcy10cmFjayBleHRlbnNpb25zIGFuZCBuZXcgZmVhdHVyZXMgbXVzdCBiZSBnZW5l cmFsbHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQy MyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6 dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPiZuYnNwOyZuYnNwOyBhcHBsaWNhYmxlLCBh bmQgbm90IGFwcGxpY2FibGUgb25seSB0byBhIHNwZWNpZmljIHNldCBvZiBzZXNzaW9uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVk a2lzbXo2N3o5ejg1enoxMjJ6Ij4mbmJzcDsmbmJzcDsgdHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyNiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4 eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0eiI+NC4gU2ltcGxlciBzb2x1dGlvbnMgdGhhdCBzb2x2 ZSBhIGdpdmVuIHByb2JsZW0gc2hvdWxkIGJlIGZhdm9yZWQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0 eiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG92ZXIgbW9yZSBjb21wbGV4IHNvbHV0aW9ucy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyOCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFn aWNkb21pZDI5Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1s ejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+VGhlIHByaW1hcnkgc291cmNl IG9mIGNoYW5nZSByZXF1aXJlbWVudHMgdG8gdGhlIGNvcmUgU0lQIHNwZWNpZmljYXRpb25zPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzAiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0 emVka2lzbXo2N3o5ejg1enoxMjJ6Ij4oZW51bWVyYXRlZCBhYm92ZSkgd2lsbCBiZSBhKSBpbnRl cm9wZXJhYmlsaXR5IHByb2JsZW1zIHRoYXQgc3RlbSBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enox MjJ6Ij5hbWJpZ3VvdXMsIG9yIHVuZGVyLWRlZmluZWQgc3BlY2lmaWNhdGlvbiwgYW5kIGIpIHJl cXVpcmVtZW50cyBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkMzIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1h LWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij5vdGhlciB3b3JraW5nIGdy b3VwcyBpbiB0aGUgQVJUIEFyZWEuIFRoZSBwcmltYXJ5IHNvdXJjZSBvZiBuZXcgcHJvdG9jb2w8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQzMyI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6 NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPmV4dGVuc2lvbnMgaXMgdGhlIERJU1BBVENIIHdvcmtp bmcgZ3JvdXAsIHdoaWNoIHdpbGwgZ2VuZXJhbGx5IG1ha2UgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1 enoxMjJ6Ij5kZXRlcm1pbmF0aW9uIHJlZ2FyZGluZyB3aGV0aGVyIG5ldyBTSVAtcmVsYXRlZCB3 b3JrIHdhcnJhbnRzIGEgbmV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtYWdpY2RvbWlkMzUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhv ci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij53b3JraW5nIGdyb3Vw IG9yIGJlbG9uZ3MgaW4gYW4gZXhpc3Rpbmcgb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5Gb3IgZWFz ZSBvZiByZWZlcmVuY2UsIHRoZSBleGlzdGluZyBTSVBDT1JFIGNoYXJ0ZXIgaXMgYXQgPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLXNpcGNvcmUv Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zaXBjb3Jl LzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjxwPi9hPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_949EF20990823C4C85C18D59AA11AD8BADFA846BFR712WXCHMBA11z_-- From nobody Mon Nov 7 00:59:52 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83769129678 for ; Mon, 7 Nov 2016 00:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIQyjTXRS2vd for ; Mon, 7 Nov 2016 00:59:47 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DDF129AB7 for ; Mon, 7 Nov 2016 00:59:45 -0800 (PST) Received: from [10.100.100.215] (unknown [195.149.146.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 70B595390; Mon, 7 Nov 2016 09:59:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <20e363e0-dc68-25a7-0ddc-4bde6bf05055@iptel.org> Date: Mon, 7 Nov 2016 09:59:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <41CB36A4-9CD6-42F7-AAE2-29F43A31DA36@edvina.net> References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <20e363e0-dc68-25a7-0ddc-4bde6bf05055@iptel.org> To: Jiri Kuthan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 08:59:51 -0000 > On 06 Nov 2016, at 13:34, Jiri Kuthan wrote: >=20 > On 06/11/16 10:18, Olle E. Johansson wrote: >> Hi! >>=20 >> Paul and I had a conversation about source address selection in SIP = on the SIP Forum IPv6 list that I wanted to move here. >>=20 >> An IPv6 interface by default has multiple addresses. Today=E2=80=99s = computers also quite frequently have multiple interfaces. >> A modern SIP stack has many IP addresses to select from. >>=20 >> In many cases applications let the operating system handle address = election and set the IP packets sender IP address to the >> one that matches the interface and the selected destination address = (by using DNS as an example). >>=20 >> In SIP we have multiple addresses in the SIP message. Much can be = simplified by using fqdn in the messages >> and a GRUU with a SIP domain in the contact. In fact most of the = examples in RFC 3261 use FQDNs. >>=20 >> But it=E2=80=99s not how SIP is implemented out there in the wild=E2=80= =A6 >>=20 >> I tried to find any words in RFC 3261 or RFC 3263 about selection of = interfaces and addresses but found nothing. >> Having said that, it=E2=80=99s not easy so if anyone on sipcore can = point me to the right section I will be grateful. >>=20 >> If not, I think we may need a clarification on Transaction layer = handling of IP address selection in >> the SIP protocol. Given a specific target, how do we handle multiple = interfaces and multiple addresses >> per interface - which address do we put in the SIP messages - like in = via=E2=80=99s, record-route, SDPs and contacts. >>=20 >> We have been testing at SIPit with multiple ULAs attached to a = network and a proxy on one of the ULAs. >> No one could connect to that proxy properly (sadly for me not even = Kamailio itself, which brags about having >> IPv6 support from day one). >>=20 >> IPv6 source address selection is covered here: >> https://tools.ietf.org/html/rfc6724 >>=20 >> Quoting RFC 6724: >>=20 >> "The IPv6 addressing architecture [RFC4291] allows multiple unicast >> addresses to be assigned to interfaces. These addresses might have >> different reachability scopes (link-local, site-local, or global). >> These addresses might also be "preferred" or "deprecated" = [RFC4862]. >> Privacy considerations have introduced the concepts of "public >> addresses" and "temporary addresses" [RFC4941]. The mobility >> architecture introduces "home addresses" and "care-of addresses" >> [RFC6275]. In addition, multi-homing situations will result in = more >> addresses per node. For example, a node might have multiple >> interfaces, some of them tunnels or virtual interfaces, or a site >> might have multiple ISP attachments with a global prefix per ISP. >>=20 >> The end result is that IPv6 implementations will very often be = faced >> with multiple possible source and destination addresses when >> initiating communication. It is desirable to have default >> algorithms, common across all implementations, for selecting source >> and destination addresses so that developers and administrators can >> reason about and predict the behavior of their systems.=E2=80=9D >>=20 >> Executive question summary: Does the current set of SIP standards = cover IP address >> selection for the *sender* when we have multiple IP interfaces (IPv4, = IPv6) >> or just one interface with multiple addresses? >=20 > IMO, the OS makes the choice and the app just finds out what it is and = print > it last-minute in the message being sent out. This seems more an = implementor's > choice rather than protocol standardization, doesn't it. Maybe. Like with other stuff, we may need a note to implementors so they get it right. May note be an IETF document though. >=20 > -jiri >=20 > p.s. https://github.com/kamailio/kamailio/blob/master/forward.c > get_out_socket() does that as an example. Which is code that doesn=E2=80=99t do IPv6 source address selection = right when we tested ;-) Thanks for pointing me to the proper file! /O From nobody Mon Nov 7 01:49:56 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD1512962B for ; Mon, 7 Nov 2016 01:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORIuTtnsQGxy for ; Mon, 7 Nov 2016 01:49:53 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0844912958C for ; Mon, 7 Nov 2016 01:49:53 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id q124so11538478itd.1 for ; Mon, 07 Nov 2016 01:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=KQ5noWg+VI1tixqNNr/WwANpvHoqZGEAG/h2rDYIADQ=; b=kwoY9aLgZ5sVGPrGw6wProkYRphjsLooboorhqVrlINGvkHi/G3tqIapqKzoVccyUX 9WLQFAOorPwv4SdLYtAkx9Q24QVmdRIruD5QurdhMMqCRIxmMelu59OuvH1seAErpFiR 5v18sAKghn5uzUmYK7gatmBkpxHxAiA91yl5yTAw+uBF5y5QbV++PenrvFPCP5UjMvVc epRjqCL3OonsfhvSp+VGZxIqAi8AsfcjKWhoMiFM4vW6L+Fr2vX75z4BwdEHzyboTudD w4qv8dLk9WWb8RpCAMnKj/0xMDo6Haf8Rk5NBSON/dV6J6vmBro2yjKRy4isGf0icBWu chNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=KQ5noWg+VI1tixqNNr/WwANpvHoqZGEAG/h2rDYIADQ=; b=YCNfv3AL+c9ot1rYDrLT342Jz91T3HB8C3SzSMJx3GGo+/41UMwS9L+4zU1gZlcV2K u5cMd7FzTE+Mq7fOc10lipmvoAC1QEXJ6jxXBHRpF+NX02484rLpHxCnKS4wNeS0uykG o/SOrlfEToFc6Vu8w9whTbMWg0981TCxNExVXzvv0IpKFTkhttnRsJbkP7qfb487tE9L RJM7JxeIh0itCWgdTemHF0Gif7nvHzKGh+Mfsk6QkntiGXW3RVNBAwbqzSR+/8R5CLkR CZX0iEtsscOvFOcwoC192MTmVqDa4/LB20QEqwYfKDvD7Z8P25zQ1jTez1mBMTMTcMjj Cf5A== X-Gm-Message-State: ABUngveXxGt0ha/OfH6jKACEumKW21rH+u8IELKQrLZUiNkpa8CEL4VEAKMtZjpuRiXYELiUg7U4bJA82/gC9g== X-Received: by 10.36.4.20 with SMTP id 20mr3897857itb.109.1478512187952; Mon, 07 Nov 2016 01:49:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.188.7 with HTTP; Mon, 7 Nov 2016 01:49:47 -0800 (PST) From: Adnan Aziz Date: Mon, 7 Nov 2016 10:49:47 +0100 Message-ID: To: sip-implementors@lists.cs.columbia.edu Content-Type: multipart/alternative; boundary=001a11c149a2c256c20540b2f182 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] SIP-URI Without Userinfo X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 09:49:54 -0000 --001a11c149a2c256c20540b2f182 Content-Type: text/plain; charset=UTF-8 Hello Everyone, According to the rfc3261, the userinfo in the sip-uri is optional. If there is no userinfo part then there should not be any "@" sign as well in the sip-uri. I have couple of questions 1) If I am receiving a sip request without userinfo part in the sip-usri, starting with "@" then is it a malformed packet? 2) What should be the standard behavior of SIP server while responding to such packets? Regards, Adnan Aziz -- *Adnan Aziz* --001a11c149a2c256c20540b2f182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Everyone,

According to t= he rfc3261, the userinfo in the sip-uri is optional.
If there is n= o userinfo part then there should not be any "@" sign as well in = the sip-uri.


I have couple of questions

=
1) If I am receiving a sip request without userinfo part in the sip-us= ri, starting with "@" then is it a malformed packet?

2) What should be the standard behavior of SIP server while respondin= g to such packets?

Regards,
= Adnan Aziz
--
Adnan Aziz

--001a11c149a2c256c20540b2f182-- From nobody Mon Nov 7 02:46:49 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22602129BB8 for ; Mon, 7 Nov 2016 02:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqSCtMxNvNPa for ; Mon, 7 Nov 2016 02:46:46 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842EB129B98 for ; Mon, 7 Nov 2016 02:46:46 -0800 (PST) X-AuditID: c1b4fb3a-83dd4980000070a2-f9-58205b9463c7 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 52.C1.28834.49B50285; Mon, 7 Nov 2016 11:46:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 11:46:43 +0100 From: Christer Holmberg To: Adnan Aziz , "sip-implementors@lists.cs.columbia.edu" Thread-Topic: [sipcore] SIP-URI Without Userinfo Thread-Index: AQHSONxNFXigs7ka8UCZuhcKgHESn6DNWOyA Date: Mon, 7 Nov 2016 10:46:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D4461DE012ACEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7se6UaIUIg9an1hZP539itTgxcQWr xdcfm9gcmD12zrrL7rFkyU8mj/Ob1jAHMEdx2aSk5mSWpRbp2yVwZaxsWsxaMEekYvvmRtYG xvcCXYycHBICJhKXlt5hAbGFBNYxSkw/ptbFyAVkL2aUePJsKnsXIwcHm4CFRPc/bZAaEYF6 iaWf3rGC2MwCmhKPdu5lArGFBfQlmg6+ZgUpFxEwkDg3tQbCNJI4cJsZxGQRUJHY/9QdpJhX wFri7bav7BBLAyTWT3/CCGJzCgRKTFz5F2w4o4CYxPdTa5ggFolL3HoynwniYAGJJXvOM0PY ohIvH/8DWyoqoCex5n4YRFhR4ur05VCtCRIPpv1kglgrKHFy5hOWCYyis5BMnYWkbBaSMoi4 gcT7c/OZIWxtiWULX0PZ+hIbv5xlhLCtJeZumcmOrGYBI8cqRtHi1OLi3HQjI73Uoszk4uL8 PL281JJNjMCIPLjlt9UOxoPPHQ8xCnAwKvHwFrjKRwixJpYVV+YeYpTgYFYS4d0QpRAhxJuS WFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA+NCXkOzbd7HHXwy Ylmn3DvbaqVV3Wzx5O7m07qT2WaflzvG+H3HslcxWmVeF3dvYbgmdtPd18f5r4X5wpIzc+sF 2Q/NmXKnytQ87/i3LJdpuRYH/7wP2Z00yaAhk1k9PEe6oPbjjifHL97XumW2STJrY/OcwOZX jnMNV3p/YV3j9eyPY+28EyeUWIozEg21mIuKEwH9cnscxAIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP-URI Without Userinfo X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 10:46:48 -0000 --_000_D4461DE012ACEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >According to the rfc3261, the userinfo in the sip-uri is optional. >If there is no userinfo part then there should not be any "@" sign as well= in the sip-uri. Correct. >I have couple of questions > >1) If I am receiving a sip request without userinfo part in the sip-usri, = starting with "@" then is it a malformed packet? It=92s a malformed SIP URI. >2) What should be the standard behavior of SIP server while responding to = such packets? Send a response with an error response code. Regards, Christer --_000_D4461DE012ACEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>According to the rfc3261, the userinfo in the sip-uri is optional.=
>If there is no userinfo part then there should not be any "@"= sign as well in the sip-uri.

Correct.

>I have couple of questions
>
>1) If I am receiving a sip request without userinfo part in the si= p-usri, starting with "@" then is it a malformed packet?
 
It=92s a malformed SIP URI.

>2) What should be the standard behavior of SIP server while respon= ding to such packets?

Send a response with an error response code.

Regards,

Christer


 --_000_D4461DE012ACEchristerholmbergericssoncom_-- From nobody Mon Nov 7 06:29:13 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE6129689 for ; Mon, 7 Nov 2016 06:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O69R8J3v3KEl for ; Mon, 7 Nov 2016 06:29:10 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C321294BB for ; Mon, 7 Nov 2016 06:29:10 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id d2so92100112pfd.0 for ; Mon, 07 Nov 2016 06:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=4e/BpbHYAZt+emdrgUvB2suXqAlJFsuFSumZtIASdt8=; b=MRqCfQ5xLtYYVskXz/pBpjwmuxcL2Q7EUG3N9dJT0hPJTJIcPaby0utUIBVXgm4FMG mmgJgKv33aIPTmD0jCU6VC6UfMEYklvJcBUyIDFu6OgME9DEVAnesd0c7Tj6edpSjxRo 7ZjklC5ClT3uL9elrsqzPPdkOqFzJXsO/KJBXOUtkcg3kVf3jgn1ciWkefUVhDKdF0Kz 1n4EcjqC80awPO/X1cXPgytrJZP4ORXUzhf0GfzHPvxLSkzAy5WhPpQPxuEskbYDpdoZ wVGj1MaJo34TsAhQEJyABnCkWyNtAwbxRKBCZ358oZTE4o+ViLQtYUd+GD/GSSCxNG5t Mgyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4e/BpbHYAZt+emdrgUvB2suXqAlJFsuFSumZtIASdt8=; b=hRBgTtGDa3cF3+YlLpzTdlku5tUKRuO1snao/NXsws6HiSPGCjFBygjTOL4dW4QwIT XdNs5IqQzgbd4IGAn2mpA5GOpvp0Thq2KAsovVBMAKDfg1ufSaURbAEaE8muojRfZCN0 UySHnnqDU4laxSMCrGPL9ICPfhpGIp3FmAMktHqnmeIg23Zi/cHmd8yubPIPoZUZLZGK VKP6Yj4hNeS5zyA0DYO6/Y7fp8Buc8Xv/mfFAx9ik31XEXvaTilii4oi6hj5bwXhrN/X KGONecQmuc2+GgW+ABOjGElFBgN2BwLlktVBt24mwJLR6mw3xfo33IaFLD1Gel3d0eyG Xgeg== X-Gm-Message-State: ABUngve9TI3DBNMCHGFHzKehS4Pbi7UoXub49NzQrP/dcDds26PDUw0evwDa23lt05pq7YsCzUufLIynwyu8UzhoGRtbTmZhGb+28ml/UIxBZBvCOzdxHUrxik0xq9l/fJyIgHmg8LQAqNHC08ncMrDvV7EMp4XES7z+kmGr7PtB5Cs= X-Received: by 10.98.137.21 with SMTP id v21mr14165110pfd.48.1478528472733; Mon, 07 Nov 2016 06:21:12 -0800 (PST) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:c11c:39ad:1913:8672]) by smtp.gmail.com with ESMTPSA id f132sm32885973pfa.72.2016.11.07.06.21.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 06:21:12 -0800 (PST) To: "Olle E. Johansson" , SIPCORE References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> From: Simon Perreault Message-ID: <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> Date: Mon, 7 Nov 2016 09:21:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 14:29:12 -0000 Le 2016-11-06 à 04:18, Olle E. Johansson a écrit : > Executive question summary: Does the current set of SIP standards cover IP address > selection for the *sender* when we have multiple IP interfaces (IPv4, IPv6) > or just one interface with multiple addresses? > > If not, should we do something about it? Even ignoring all implementation and real-world constraints, what do you think would be the theoretically perfect UA behaviour? Let's start with measuring how big is the gap between theory and practice? -- Simon Perreault Director of Engineering, Platform | Jive Communications, Inc. https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com From nobody Mon Nov 7 06:44:29 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A168C129560 for ; Mon, 7 Nov 2016 06:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8w4k7Dyqc6Q for ; Mon, 7 Nov 2016 06:44:26 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05167129648 for ; Mon, 7 Nov 2016 06:44:24 -0800 (PST) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-10v.sys.comcast.net with SMTP id 3l9ncnNu2Hqol3l9rcYCmj; Mon, 07 Nov 2016 14:44:23 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-po-07v.sys.comcast.net with SMTP id 3l9qcNjgxnXik3l9rcNpck; Mon, 07 Nov 2016 14:44:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uA7EiLc9016811; Mon, 7 Nov 2016 09:44:21 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uA7EiLn9016808; Mon, 7 Nov 2016 09:44:21 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: chaudhryadnan@gmail.com In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 07 Nov 2016 09:44:20 -0500 Message-ID: <87r36nfiyj.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIH2HOL2yirflVyEIdmvPs3+LDR98/DN+z3rY8sYcFGKpk20dgq9ASflz4OLVrikGURPuQsrtu/marQrR9lOwnGmjbhTg87XHCCZ4+gxGM43m0mNKY8L xC+/ZTuD1zBK0DW0fPJSuHqiqJDBKJDFNnFVs7d3INfglYxcRcZ3QxVf28xc1PikMcMSaTprj/LonqbWhpyoH+zvki5Mt3jnODg/zAkyrzvWsa1lY1tJdbh4 7FwndqqXc1dL/jppxp+OdTX7L1YBzs7l+7zhK41YKw25G2Vt8FKRLOKiiRlTp361LhkNx1ppW6hd1QBCTO7zXQ== Archived-At: Cc: sip-implementors@lists.cs.columbia.edu, sipcore@ietf.org Subject: Re: [sipcore] SIP-URI Without Userinfo X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 14:44:27 -0000 To amplify Christer's replyP: Christer Holmberg writes: >>I have couple of questions >> >>1) If I am receiving a sip request without userinfo part in the >>sip-usri, starting with "@" then is it a malformed packet? > > It's a malformed SIP URI. In particular, it is syntactically incorrect, which you can see by comparison with the ABNF in RFC 3261 section 25.1 production "SIP-URI". > >>2) What should be the standard behavior of SIP server while responding >>to such packets? > > Send a response with an error response code. Specifically, a 400 response: 21.4.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Call-ID header field". However, there is a certain amount of freedom that SIP servers have regarding precisely what 4xx response codes they give for particular requests, because the errors in SIP requests cannot be precisely categorized. Dale From nobody Mon Nov 7 06:51:01 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0696F129860 for ; Mon, 7 Nov 2016 06:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPneTsg3lUjP for ; Mon, 7 Nov 2016 06:50:58 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CFA1296F7 for ; Mon, 7 Nov 2016 06:50:57 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id w33so88239724qtc.3 for ; Mon, 07 Nov 2016 06:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ANN5t112T9avPgVC3LmRiTktJTJG2ER6byJVBPkSx/s=; b=V03UU/UYHGuqmOTBtkeh3OKfYrvJmQ8OgT+/lgDJuNu+cX6SzVQnohjNl+K2WkXr27 3jNaI6ysViQok55x/nIz2Kq59UMjLUMjrxjkAQDEmvmIGnzBkvQtl7D3Uw+jzAO0uKr7 5jI1if8eC0eDIak4wSlf/wV4q1ONRMgMgEXmnKmsfP2FVUOT4ypNAEtjaz9F2EVXTQlm 5n211HgGsdilYhTKxmwICs+CxjJ9Z8U0mh+HVyrf2HR/17Jwai35wybEOE2X1ALqM2KI jlCGx5+v0AoxqSGSDBBvBrR92x7nWG7gIZT4dWh4+1EMM9GbwjtP6QehL+8s5n1Csd3y kTQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ANN5t112T9avPgVC3LmRiTktJTJG2ER6byJVBPkSx/s=; b=Birk+qa/RIM1VjAREuo91rWF51P7LCOebSZ13SOyEw0dD8WdiKeieMsayigmt39o+/ srZ2xz1vew4h4AQc/RDEsHlRrc0TQsaZdoxYv8+onIukN0ib+IIXjOmi4KedGXBQPp/d 3FwqN7V4HfoZjXcczakb2jl8ehh1qcZuCjrWoIS+a52L4/Cnf17rHjRhMbhTRxaMZ0Zt A3vsJV144+3BTPlDR6QTSbXAnpxIie+5Z03X4MY9Mda86fzcchopo+/b1ZBp3XPohHbU c7RCpBTxjy6Xqu/ae9zmcwEry6bZ3ldo6Y+RULgVImuN8yc1S+B429QDxGi64yDkbvPa wpKA== X-Gm-Message-State: ABUngvdYHOU9KoqGbRe+2TTmz/z4brSxBKYBHYUYcfG2MX5qtrhm5s1Zy4Qi8X0m6zKGVQ== X-Received: by 10.200.49.106 with SMTP id h39mr7687093qtb.69.1478530256862; Mon, 07 Nov 2016 06:50:56 -0800 (PST) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com. [209.85.220.182]) by smtp.gmail.com with ESMTPSA id 58sm16593582qtz.33.2016.11.07.06.50.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 06:50:56 -0800 (PST) Received: by mail-qk0-f182.google.com with SMTP id n21so67699892qka.3 for ; Mon, 07 Nov 2016 06:50:56 -0800 (PST) X-Received: by 10.55.6.14 with SMTP id 14mr7086218qkg.167.1478530256256; Mon, 07 Nov 2016 06:50:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Mon, 7 Nov 2016 06:50:55 -0800 (PST) In-Reply-To: <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> From: Roman Shpount Date: Mon, 7 Nov 2016 09:50:55 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a114d7564b6e54f0540b72649 Archived-At: Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 14:51:00 -0000 --001a114d7564b6e54f0540b72649 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is the same problem as selection of IPv4 vs IPv6 or UDP vs TCP when running behind firewall. What we typically do is run a STUN server on the same protocols, IPs and ports as our SIP proxy. Client would enumerate local interfaces and send a STUN BIND request to DNS results of the server name resolution. Once we find the STUN request that received the response, we would start the SIP UA on that interface and register. The whole process is very similar to ICE candidate nomination. If keep-alive on the connection fails due to client migration to another network or DHCP lease expiration, we would restart the whole process with STUN BIND requests and re-registration. Another alternative is to use SIP OPTIONS request for the same purpose as STUN BIND. This uses more resources, but does not require STUN. Final option is simply do the UDP connect from the unbound socket to the server IP and then get the socket address. This would give you the local address which has the route to the server. This does not guarantee that SIP request will actually be delivered over that route, especially if client on some kind of VPN, but it does give you the most likely local interface. Even in the previous two cases we normally start with this interface when sending connection verification requests. Given that STUN BIND support is already required for UDP keep-alive messages by sip-outbound, and that it is typically already supported by SIP Proxies, we have preferred the STUN based implementation. Bottom line is there are independent SIP UAs for each of the local interfaces. Correct SIP UA to be used for connection to a specific server is determined by sending a test STUN or SIP request. Regards, _____________ Roman Shpount On Mon, Nov 7, 2016 at 9:21 AM, Simon Perreault wrote= : > Le 2016-11-06 =C3=A0 04:18, Olle E. Johansson a =C3=A9crit : > > Executive question summary: Does the current set of SIP standards cover > IP address > > selection for the *sender* when we have multiple IP interfaces (IPv4, > IPv6) > > or just one interface with multiple addresses? > > > > If not, should we do something about it? > > Even ignoring all implementation and real-world constraints, what do you > think would be the theoretically perfect UA behaviour? Let's start with > measuring how big is the gap between theory and practice? > > -- > Simon Perreault > Director of Engineering, Platform | Jive Communications, Inc. > https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a114d7564b6e54f0540b72649 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is the same problem as selection of IPv4 vs IPv6 or U= DP vs TCP when running behind firewall.

What we typicall= y do is run a STUN server on the same protocols, IPs and ports as our SIP p= roxy. Client would enumerate local interfaces and send a STUN BIND request = to DNS results of the server name resolution. Once we find the STUN request= that received the response, we would start the SIP UA on that interface an= d register. The whole process is very similar to ICE candidate nomination. = If keep-alive on the connection fails due to client migration to another ne= twork or DHCP lease expiration, we would restart the whole process with STU= N BIND requests and re-registration.

Another alter= native is to use SIP OPTIONS request for the same purpose as STUN BIND. Thi= s uses more resources, but does not require STUN.

= Final option is simply do the UDP connect from the unbound socket to the se= rver IP and then get the socket address. This would give you the local addr= ess which has the route to the server. This does not guarantee that SIP req= uest will actually be delivered over that route, especially if client on so= me kind of VPN, but it does give you the most likely local interface. Even = in the previous two cases we normally start with this interface when sendin= g connection verification requests.

Given that STU= N BIND support is already required for UDP keep-alive messages by sip-outbo= und, and that it is typically already supported by SIP Proxies, we have pre= ferred the STUN based implementation.

Bottom line = is there are independent SIP UAs for each of the local interfaces. Correct = SIP UA to be used for connection to a specific server is determined by send= ing a test STUN or SIP request.
=C2=A0
Regards,

_____________
Roman Shpount=

On Mon, Nov 7, 2016 at 9:21 AM, Simon Perrea= ult <sperreault@jive.com> wrote:
Le 2016-11-06 =C3=A0 04:18, Olle E. Johansson a = =C3=A9crit :
> Executive question summary: Does the current set of SIP standards cove= r IP address
> selection for the *sender* when we have multiple IP interfaces (IPv4, = IPv6)
> or just one interface with multiple addresses?
>
> If not, should we do something about it?

Even ignoring all implementation and real-world constraints, what do= you
think would be the theoretically perfect UA behaviour? Let's start with=
measuring how big is the gap between theory and practice?

--
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://j= ive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--001a114d7564b6e54f0540b72649-- From nobody Mon Nov 7 07:17:33 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A871299A2 for ; Mon, 7 Nov 2016 07:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mod-imLbbrp for ; Mon, 7 Nov 2016 07:17:29 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CE71299C9 for ; Mon, 7 Nov 2016 07:17:28 -0800 (PST) Received: from [10.100.100.215] (unknown [195.149.146.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id A5CDB6C07; Mon, 7 Nov 2016 16:17:19 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_4150EF5C-D98C-4D51-A71A-9E45A5293DB3" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 7 Nov 2016 16:17:18 +0100 Message-Id: References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> To: Roman Shpount X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 15:17:32 -0000 --Apple-Mail=_4150EF5C-D98C-4D51-A71A-9E45A5293DB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 07 Nov 2016, at 15:50, Roman Shpount wrote: >=20 > This is the same problem as selection of IPv4 vs IPv6 or UDP vs TCP = when running behind firewall. Yes and no. When you want to communicate with something in the same = network you may have multiple addresses available to use IPv4 IPV6 global IPv6 global temporary IPv6 ULA Is it crystal clear for a SIP developer which one to use?=20 I think this may be a generic issue for all IP applications, but wanted = to open the discussion to see if I missed something. We have seen problems with this at SIPit so this is something a lot of = developers have not=20 implemented correctly in their SIP implementations. >=20 > What we typically do is run a STUN server on the same protocols, IPs = and ports as our SIP proxy. Client would enumerate local interfaces and = send a STUN BIND request to DNS results of the server name resolution. = Once we find the STUN request that received the response, we would start = the SIP UA on that interface and register. The whole process is very = similar to ICE candidate nomination. If keep-alive on the connection = fails due to client migration to another network or DHCP lease = expiration, we would restart the whole process with STUN BIND requests = and re-registration. STUN would not work in many of these cases. >=20 > Another alternative is to use SIP OPTIONS request for the same purpose = as STUN BIND. This uses more resources, but does not require STUN. So who decides what to put in the VIA of the SIP Options?? >=20 > Final option is simply do the UDP connect from the unbound socket to = the server IP and then get the socket address. This would give you the = local address which has the route to the server. This does not guarantee = that SIP request will actually be delivered over that route, especially = if client on some kind of VPN, but it does give you the most likely = local interface. Even in the previous two cases we normally start with = this interface when sending connection verification requests. I think that=E2=80=99s what the code that Jiri pointed to does. But we = still have the issue with multiple ULAs. Maybe the O/S have fixed that now. >=20 > Given that STUN BIND support is already required for UDP keep-alive = messages by sip-outbound, and that it is typically already supported by = SIP Proxies, we have preferred the STUN based implementation. You assume we have an inside and an outside, based on the IPv4 NAT = model. Think IPv6 for a while :-) >=20 > Bottom line is there are independent SIP UAs for each of the local = interfaces. Correct SIP UA to be used for connection to a specific = server is determined by sending a test STUN or SIP request. Food for thought. /O > =20 > Regards, >=20 > _____________ > Roman Shpount >=20 > On Mon, Nov 7, 2016 at 9:21 AM, Simon Perreault > wrote: > Le 2016-11-06 =C3=A0 04:18, Olle E. Johansson a =C3=A9crit : > > Executive question summary: Does the current set of SIP standards = cover IP address > > selection for the *sender* when we have multiple IP interfaces = (IPv4, IPv6) > > or just one interface with multiple addresses? > > > > If not, should we do something about it? >=20 > Even ignoring all implementation and real-world constraints, what do = you > think would be the theoretically perfect UA behaviour? Let's start = with > measuring how big is the gap between theory and practice? >=20 > -- > Simon Perreault > Director of Engineering, Platform | Jive Communications, Inc. > https://jive.com | +1 418 478 0989 ext. 1241 = | sperreault@jive.com = >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = >=20 --Apple-Mail=_4150EF5C-D98C-4D51-A71A-9E45A5293DB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 07 Nov 2016, at 15:50, Roman Shpount <roman@telurix.com> = wrote:

This is the same problem as selection of IPv4 vs = IPv6 or UDP vs TCP when running behind = firewall.
Yes and no. When you want to = communicate with something in the same network you may = have
multiple addresses available to = use
IPv4
IPV6 global
IPv6 global = temporary
IPv6 ULA

Is it = crystal clear for a SIP developer which one to use? 
I = think this may be a generic issue for all IP applications, but wanted to = open the discussion to
see if I missed = something.

We have seen problems = with this at SIPit so this is something a lot of developers have = not 
implemented correctly in their SIP = implementations.

What we typically do is run a STUN = server on the same protocols, IPs and ports as our SIP proxy. Client = would enumerate local interfaces and send a STUN BIND request to DNS = results of the server name resolution. Once we find the STUN request = that received the response, we would start the SIP UA on that interface = and register. The whole process is very similar to ICE candidate = nomination. If keep-alive on the connection fails due to client = migration to another network or DHCP lease expiration, we would restart = the whole process with STUN BIND requests and = re-registration.
STUN would not work in = many of these cases.
Another alternative is to use SIP = OPTIONS request for the same purpose as STUN BIND. This uses more = resources, but does not require STUN.
So = who decides what to put in the VIA of the SIP Options??

Final option is simply do the UDP connect from the unbound = socket to the server IP and then get the socket address. This would give = you the local address which has the route to the server. This does not = guarantee that SIP request will actually be delivered over that route, = especially if client on some kind of VPN, but it does give you the most = likely local interface. Even in the previous two cases we normally start = with this interface when sending connection verification = requests.
I think that=E2=80=99s what the = code that Jiri pointed to does. But we still have the issue with = multiple ULAs. Maybe
the O/S have fixed that = now.


Given that STUN BIND support is already = required for UDP keep-alive messages by sip-outbound, and that it is = typically already supported by SIP Proxies, we have preferred the STUN = based implementation.
You assume we have = an inside and an outside, based on the IPv4 NAT model. Think IPv6 for a = while :-)

Bottom line is there are independent = SIP UAs for each of the local interfaces. Correct SIP UA to be used for = connection to a specific server is determined by sending a test STUN or = SIP request.
Food for = thought.

/O
 
Regards,

_____________
Roman = Shpount

On Mon, Nov 7, 2016 at 9:21 = AM, Simon Perreault <sperreault@jive.com> wrote:
Le = 2016-11-06 =C3=A0 04:18, Olle E. Johansson a =C3=A9crit :
> Executive question summary: Does the current set of SIP standards = cover IP address
> selection for the *sender* when we have multiple IP interfaces = (IPv4, IPv6)
> or just one interface with multiple addresses?
>
> If not, should we do something about it?

Even ignoring all implementation and real-world constraints, what = do you
think would be the theoretically perfect UA behaviour? Let's start = with
measuring how big is the gap between theory and practice?

--
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


= --Apple-Mail=_4150EF5C-D98C-4D51-A71A-9E45A5293DB3-- From nobody Mon Nov 7 09:03:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A6412967B for ; Mon, 7 Nov 2016 09:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baeRvPSP9cpG for ; Mon, 7 Nov 2016 09:03:05 -0800 (PST) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 23686129850 for ; Mon, 7 Nov 2016 09:03:04 -0800 (PST) X-AuditID: 1207440f-1f3ff700000009a9-22-5820b3c713d4 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 25.A6.02473.7C3B0285; Mon, 7 Nov 2016 12:03:04 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uA7H32r5009490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 7 Nov 2016 12:03:03 -0500 From: Paul Kyzivat To: sipcore@ietf.org References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> Message-ID: <718f4ecc-173b-a7a1-1fa5-e72ca5ffecda@alum.mit.edu> Date: Mon, 7 Nov 2016 12:03:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixO6iqHtis0KEQfdiZouvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49j/u8wFz3grVv+aw9jA+Iyri5GTQ0LAROLE8QNsILaQwGVG iZMfA7sYuYDst0wSa/fsYQRJsAloScw59J8FxBYWMJOYvOcoWIOIgIjEs+n/oJrzJU6vWcza xcjBwStgL9F61RgkzCKgIvF+UjtYiahAmsT2dbuZQWxeAUGJkzOfgI3kFLCRePWrFcxmBho/ b/NDZghbXqJ562zmCYx8s5C0zEJSNgtJ2QJG5lWMcok5pbm6uYmZOcWpybrFyYl5ealFuiZ6 uZkleqkppZsYISHGv4Oxa73MIUYBDkYlHt4X/QoRQqyJZcWVuYcYJTmYlER5UzYBhfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwFoHkeFMSK6tSi/JhUtIcLErivOpL1P2EBNITS1KzU1MLUotg sjIcHEoSvHEgjYJFqempFWmZOSUIaSYOTpDhPEDDe8CGFxck5hZnpkPkTzEqSonzTt4IlBAA SWSU5sH1wlLAK0ZxoFeEee+AtPMA0wdc9yugwUxAg6tiwAaXJCKkpBoYdbi1SjQyWxu6qrQd O9OSHwsVqfzW/JC03CN48gKT1iXnXj9tcpA89nrqxQsPGkT+vnm8UzHMg8VxoWQMa66XwnNr Y9V7JyMYk9KYon9m7o9PzftU5FcUZX8wRzE7/NvsyPMrWyxPHzDZ1acU3nJ9v8br5IniL0PW dv3iLGFSZjKa+bo51V6JpTgj0VCLuag4EQAGo5lC3AIAAA== Archived-At: Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:03:07 -0000 On 11/7/16 9:21 AM, Simon Perreault wrote: > Le 2016-11-06 à 04:18, Olle E. Johansson a écrit : >> Executive question summary: Does the current set of SIP standards cover IP address >> selection for the *sender* when we have multiple IP interfaces (IPv4, IPv6) >> or just one interface with multiple addresses? >> >> If not, should we do something about it? > > Even ignoring all implementation and real-world constraints, what do you > think would be the theoretically perfect UA behaviour? Let's start with > measuring how big is the gap between theory and practice? I think we need to first clarify what we mean here. Does this choice necessarily impact *anything* in the outgoing sip message? If so, what? The most likely thing that it would affect is Via. It is reasonable to assume that the Via header has the same address that goes into the sender field of the IP packet. 3261 doesn't exactly say that, but section 8.1.1.7 does say: The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected (which may involve the usage of the procedures in [4]). which is pretty close. But that only needs to work for routing of the transaction response. So as long as the next hop can get back this way all should be good. It isn't necessary for the UAS to be able to route to this address. Is there some thought that this choice affects anything else in the outgoing message? (What to put in the Contact header is a different question. I trust that isn't part of the current question.) Thanks, Paul From nobody Mon Nov 7 09:32:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A5D129580 for ; Mon, 7 Nov 2016 09:32: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO9h65JsFRcv for ; Mon, 7 Nov 2016 09:32:20 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A111299E6 for ; Mon, 7 Nov 2016 09:32:01 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id c47so91642124qtc.2 for ; Mon, 07 Nov 2016 09:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WpE9SwiBKrsCQ5K/AkxltOZ9gw9PZ/Ps5Kv07Nx51O8=; b=R6VVXNwYHv8BIQq7suWHRHhDV41KnKdAPNpIRaDqi1pozrAMGdTgFVC1pK+7PTWbHv nNkn+eUrUlgerBevTI9RatTswGAk3FIN0DIMEQujbFIHp44H3gpmylD7IUc0/Brn8O1a 28Awfo4iia0kpBynAcJD6B3UaD0JIhArQNk70jNQbphg8XDcw7DF8no8ORTVsoaVBO4a 6nhzT7RrQuam855/Rgl27U71P2SyNaC4TRCL5uu3qkwYk39UcXfHE0srwsraXhu3LNBR 3K726mb31mTYOh6aZaTgfxzp2L9cW5jS07BnvT3AGAkJNBjbZJ9jZY3ml9EEnHJjDf2R 3Wkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WpE9SwiBKrsCQ5K/AkxltOZ9gw9PZ/Ps5Kv07Nx51O8=; b=NnrjnDmebw+NNbtGq3YgfClNRjoVkUSBpPJ6vEbYppJG66WmNwKbCqmZZvjqQF8VYN JefRRBRLCvRYbmLq2NFabHd3W33GkLDWN/Y9Y/DY28AfS13GF4IvlT+mKMT0Qsi5mspp eZThWi+XHK3GoZKTIy7TWy25Krcs3etckMVRPubwIGPlseOAHAwF7dFrJByCHkeyn2Rg hiXNwS++tgMyFZW1pn6FRUCupbUOjS4AQZHu5b/QgFqqyapVfnzeAbfdYAEbNncz6tVW SnhzMJXbvTwLYI6vpYoF4esdXhDClGcwl2+lVW5uiAaHD4qicgbalsQxDYBVMDDzMft/ ri9Q== X-Gm-Message-State: ABUngvcmzf0L/a+HKYPppF9Za/nOAKoJEj5Lol9yBYLbkzLRw0qcobIGO1QDismDnrwf3g== X-Received: by 10.237.62.89 with SMTP id m25mr8296162qtf.119.1478539920839; Mon, 07 Nov 2016 09:32:00 -0800 (PST) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com. [209.85.220.172]) by smtp.gmail.com with ESMTPSA id w75sm3920750qkb.36.2016.11.07.09.32.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 09:32:00 -0800 (PST) Received: by mail-qk0-f172.google.com with SMTP id n204so174921828qke.2 for ; Mon, 07 Nov 2016 09:32:00 -0800 (PST) X-Received: by 10.55.79.17 with SMTP id d17mr8584886qkb.110.1478539920195; Mon, 07 Nov 2016 09:32:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Mon, 7 Nov 2016 09:31:59 -0800 (PST) In-Reply-To: References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> From: Roman Shpount Date: Mon, 7 Nov 2016 12:31:59 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a114a89ccbacc050540b966b3 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:32:22 -0000 --001a114a89ccbacc050540b966b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 7, 2016 at 10:17 AM, Olle E. Johansson wrote: > > On 07 Nov 2016, at 15:50, Roman Shpount wrote: > > This is the same problem as selection of IPv4 vs IPv6 or UDP vs TCP when > running behind firewall. > > Yes and no. When you want to communicate with something in the same > network you may have > multiple addresses available to use > IPv4 > IPV6 global > IPv6 global temporary > IPv6 ULA > My suggestion was to use the same procedures as the ones defined when collecting base candidates for ICE. These should be fairly well defined and tested with things like WebRTC. > Is it crystal clear for a SIP developer which one to use? > I think this may be a generic issue for all IP applications, but wanted t= o > open the discussion to > see if I missed something. > > We have seen problems with this at SIPit so this is something a lot of > developers have not > implemented correctly in their SIP implementations. > > > What we typically do is run a STUN server on the same protocols, IPs and > ports as our SIP proxy. Client would enumerate local interfaces and send = a > STUN BIND request to DNS results of the server name resolution. Once we > find the STUN request that received the response, we would start the SIP = UA > on that interface and register. The whole process is very similar to ICE > candidate nomination. If keep-alive on the connection fails due to client > migration to another network or DHCP lease expiration, we would restart t= he > whole process with STUN BIND requests and re-registration. > > STUN would not work in many of these cases. > Why would not it work? This is the same procedure as ICE -- send a STUN bind message over UDP or TCP from each potential client address (gathered through interface enumeration) to each potential server address (gathered through DNS resolution). If the server is running STUN on each protocol (including TCP and TLS), address and port it exposes for external calls, this check will work if communications are possible. > Another alternative is to use SIP OPTIONS request for the same purpose as > STUN BIND. This uses more resources, but does not require STUN. > > So who decides what to put in the VIA of the SIP Options?? > In this case client starts a SIP UA on each potential local address and sends a SIP OPTIONS request to each potential server address from each SIP UA. Each SIP UA is bound to the specific address, so it should be clear which address to put in the VIA. > Final option is simply do the UDP connect from the unbound socket to the > server IP and then get the socket address. This would give you the local > address which has the route to the server. This does not guarantee that S= IP > request will actually be delivered over that route, especially if client = on > some kind of VPN, but it does give you the most likely local interface. > Even in the previous two cases we normally start with this interface when > sending connection verification requests. > > I think that=E2=80=99s what the code that Jiri pointed to does. But we st= ill have > the issue with multiple ULAs. Maybe > the O/S have fixed that now. > This code works often enough. Issues that we saw with just doing this are related to clients who are connected via a VPN to a corporate environment that block SIP. Another issue is deciding when to use UDP vs TCP when behind firewall. This code provides no indication that UDP is blocked. > Given that STUN BIND support is already required for UDP keep-alive > messages by sip-outbound, and that it is typically already supported by S= IP > Proxies, we have preferred the STUN based implementation. > > You assume we have an inside and an outside, based on the IPv4 NAT model. > Think IPv6 for a while :-) > Once again, what I am proposing is not that different then full ICE with ICE lite communication. This is known to work with IPv6 :-). > Bottom line is there are independent SIP UAs for each of the local > interfaces. Correct SIP UA to be used for connection to a specific server > is determined by sending a test STUN or SIP request. > > Food for thought. > > _____________ Roman Shpount --001a114a89ccbacc050540b966b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 7, 2016 at 10:17 AM, Olle E. Johansson &= lt;oej@edvina.net&g= t; wrote:

<= div>
On 07 Nov 2016, a= t 15:50, Roman Shpount <roman@telurix.com> wrote:

This is the same= problem as selection of IPv4 vs IPv6 or UDP vs TCP when running behind fir= ewall.
Yes and no. When you want to communic= ate with something in the same network you may have
multiple addr= esses available to use
IPv4
IPV6 global
IPv6 = global temporary
IPv6 ULA

=
My suggestion was to use the same procedures as the ones defined when = collecting base candidates for ICE. These should be fairly well defined and= tested with things like WebRTC.

=C2=A0
Is it crystal clear for a SIP developer which one to use?=C2=A0<= br>
I think this may be a generic issue for all IP applications, = but wanted to open the discussion to
see if I missed something.

We have seen problems with this at SIPit so this is= something a lot of developers have not=C2=A0
implemented correct= ly in their SIP implementations.


What we typi= cally do is run a STUN server on the same protocols, IPs and ports as our S= IP proxy. Client would enumerate local interfaces and send a STUN BIND requ= est to DNS results of the server name resolution. Once we find the STUN req= uest that received the response, we would start the SIP UA on that interfac= e and register. The whole process is very similar to ICE candidate nominati= on. If keep-alive on the connection fails due to client migration to anothe= r network or DHCP lease expiration, we would restart the whole process with= STUN BIND requests and re-registration.
STUN would not work in many of these cases.
=C2=A0
Why would not it work? This is the same procedure as ICE = -- send a STUN bind message over UDP or TCP from each potential client addr= ess (gathered through interface enumeration) to each potential server addre= ss (gathered through DNS resolution). If the server is running STUN on each= protocol (including TCP and TLS), address and port it exposes for external= calls, this check will work if communications are possible.
Another alternative is to use SIP OPTIONS request for the same purpose a= s STUN BIND. This uses more resources, but does not require STUN.
=
So who decides what to put in the VIA of the SIP = Options??

=C2=A0In this case cl= ient starts a SIP UA on each potential local address and sends a SIP OPTION= S request to each potential server address from each SIP UA. Each SIP UA is= bound to the specific address, so it should be clear which address to put = in the VIA.=C2=A0
Final option is simply do the UDP connec= t from the unbound socket to the server IP and then get the socket address.= This would give you the local address which has the route to the server. T= his does not guarantee that SIP request will actually be delivered over tha= t route, especially if client on some kind of VPN, but it does give you the= most likely local interface. Even in the previous two cases we normally st= art with this interface when sending connection verification requests.
<= /div>
I think that=E2=80=99s what the code that Ji= ri pointed to does. But we still have the issue with multiple ULAs. Maybe
the O/S have fixed that now.
=C2=A0
This code works often enough. Issues that we saw with just doing t= his are related to clients who are connected via a VPN to a corporate envir= onment that block SIP. Another issue is deciding when to use UDP vs TCP whe= n behind firewall. This code provides no indication that UDP is blocked.=C2= =A0
<= div dir=3D"ltr">
Given that STUN BIND support is already required for U= DP keep-alive messages by sip-outbound, and that it is typically already su= pported by SIP Proxies, we have preferred the STUN based implementation.
You assume we have an inside and an outsid= e, based on the IPv4 NAT model. Think IPv6 for a while :-)
=C2=A0
Once again, what I am proposing is not that d= ifferent then full ICE with ICE lite communication. This is known to work w= ith IPv6 :-).
Bottom line is there are independent SIP UA= s for each of the local interfaces. Correct SIP UA to be used for connectio= n to a specific server is determined by sending a test STUN or SIP request.=
Food for thought.


_____________<= br>Roman Shpount

=C2=A0
--001a114a89ccbacc050540b966b3-- From nobody Mon Nov 7 09:35:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B980129677 for ; Mon, 7 Nov 2016 09:35:32 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX8GZdXd-1RF for ; Mon, 7 Nov 2016 09:35:31 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4757A129680 for ; Mon, 7 Nov 2016 09:35:24 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id x190so183611082qkb.0 for ; Mon, 07 Nov 2016 09:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WeCnH5yw5Vn3ZZ4Oe9MIWHuyOG466uXxH0l0EMSrhWo=; b=W+gyuITWNzNY2xJXFJA9zSBbFiBYcXgBgvUC9Izm1XI0B762TbfDOyY5COVdvLTFhG DrEYk2++9vrVUUDEFLyBD1usGvMFEdYaul1m1pd+0EA3bHrR0DjOl0R0FZI2FtBhrjVx C5yxPMZ6ZQ+EEx839M6AJJcKiRRsllKxQHdwR1p8k34M9QmUUm+I0QzWM/WDiT0GkWDx VzhE936BIJdtLaZcZfAHs1DsQ1tRJJxZ44Qthu6lOuHkbSqEDLeip7rcCOaZYicQcrO1 +bQDiQKFYivW9eLiIgsuBPVokjoXgjT8Dmru5Je4YGvJNjXP4xeDldk8i9dZGUzSmI6Q 0fnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WeCnH5yw5Vn3ZZ4Oe9MIWHuyOG466uXxH0l0EMSrhWo=; b=b1nBUDu9slTywYrdZNWzTI0XN1hPRl6EGeTu3P5LceiquT/7g7X2ysO0h/+ZDdN1sc o6yARt7E71IlGK+IUTJ1ECpgk1vFvSZbVdEFE/CGfICKtYlWgGkR63yzDNwrbzqY8Klz BYRCgtuSLvpmhcsmNDRExh1UlxNpxtqcTAGgpVhORH0YQZaLabacuwX9bSsmLzk6udxO 46flQG7Y4znqr3LGMk1xpthED2U34qWVYgNiYhBfQGVddTKEmqMrOJ8tHmzf0Z3j/YnZ U/93ve3DtFEoxE9vpX1SbTFOU14SpQJweQ8O8jaNA7qG4Ka91BpjJPtoriyC3Vsuwh7i Z4hw== X-Gm-Message-State: ABUngve8EMSjEuoVGqOdOpxvauHMKk+GVYtOMsXNcvlzylFY0Ib+pIPp5NzIisIUzUrSXg== X-Received: by 10.55.71.9 with SMTP id u9mr8798360qka.251.1478540123289; Mon, 07 Nov 2016 09:35:23 -0800 (PST) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com. [209.85.220.177]) by smtp.gmail.com with ESMTPSA id q3sm10849075qte.41.2016.11.07.09.35.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 09:35:23 -0800 (PST) Received: by mail-qk0-f177.google.com with SMTP id x190so183610841qkb.0 for ; Mon, 07 Nov 2016 09:35:23 -0800 (PST) X-Received: by 10.55.107.71 with SMTP id g68mr7482511qkc.259.1478540118901; Mon, 07 Nov 2016 09:35:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Mon, 7 Nov 2016 09:35:18 -0800 (PST) In-Reply-To: <718f4ecc-173b-a7a1-1fa5-e72ca5ffecda@alum.mit.edu> References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> <718f4ecc-173b-a7a1-1fa5-e72ca5ffecda@alum.mit.edu> From: Roman Shpount Date: Mon, 7 Nov 2016 12:35:18 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114ff8e892cc3f0540b972b6 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:35:32 -0000 --001a114ff8e892cc3f0540b972b6 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 12:03 PM, Paul Kyzivat wrote: > Is there some thought that this choice affects anything else in the > outgoing message? The only other issue this affects is delivering SIP response to a message when client IP changes in the middle of the SIP transaction. You either need to accept that the transaction can fail or come up with a mechanism to recover a SIP transaction on the new client local IP or use something like TURN to always tunnel SIP messages through the same IP/port in the cloud (resource intensive). Regards, _____________ Roman Shpount --001a114ff8e892cc3f0540b972b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 7, 2016 at 12:03 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
Is there some thought that this = choice affects anything else in the outgoing message?

=
The only other issue this affects is delivering SIP response to = a message when client IP changes in the middle of the SIP transaction. You = either need to accept that the transaction can fail or come up with a mecha= nism to recover a SIP transaction on the new client local IP or use somethi= ng like TURN to always tunnel SIP messages through the same IP/port in the = cloud (resource intensive).

Regards,
_____________
Roman Shpount
= =C2=A0
--001a114ff8e892cc3f0540b972b6-- From nobody Mon Nov 7 09:59:48 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544F812952E; Mon, 7 Nov 2016 09:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkz-xtX9EtSl; Mon, 7 Nov 2016 09:59:30 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8044C12956F; Mon, 7 Nov 2016 09:59:27 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 97682B770BE13; Mon, 7 Nov 2016 17:59:24 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id uA7HxPZE020681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2016 17:59:26 GMT Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id uA7HxPfi001120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2016 17:59:25 GMT Received: from [135.185.238.154] (shoonya.ih.lucent.com [135.185.238.154]) by umail.lucent.com (8.13.8/TPES) with ESMTP id uA7HxOsp004302; Mon, 7 Nov 2016 11:59:24 -0600 (CST) To: "'SIPCORE'" , "dispatch@ietf.org" References: From: "Vijay K.Gurbani" Message-ID: <6ef992f5-c559-4b51-2597-daeb54de412a@nokia-bell-labs.com> Date: Mon, 7 Nov 2016 11:59:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "art-ads@ietf.org" Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:59:43 -0000 On 11/04/2016 04:28 PM, Adam Roach wrote: > Please provide feedback on the proposed charter by sending email to the > SIPCORE mailing list. We will also discuss this briefly during the > DISPATCH session in Seoul. The change to the charter sounds reasonable. Having been a beneficiary of one of the first mini-WGs to be dispatch'ed (sipclf), the model of dispatch'ing has worked. However, in its trajectory, as Adam states, SIP is now a more mature protocol and I suspect the itches that need to be scratched have more to do with operational issues with SIP than core modifications to the protocol itself. Seems reasonable to perform such tweaks in sipcore. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@bell-labs.com / vijay.gurbani@nokia-bell-labs.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Mon Nov 7 12:00:48 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E427E1299D5 for ; Mon, 7 Nov 2016 12:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DBgrVKp9dXe for ; Mon, 7 Nov 2016 12:00:44 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0053.outbound.protection.outlook.com [104.47.40.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68989129A99 for ; Mon, 7 Nov 2016 12:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xh8gZcQA9OrF7xheC2IJKtYsR3Fh6DjRsd75DE3tJvA=; b=D9c0mlBhngZ5ST0dm0QMUhyDPg/luIqBg4GquIynuKSYNCANlslgy4fh/INtn7YU3QX7WQfqc/NIdkXQ7aVl8EVrK4wa5Mcc0tsIaOYcc/fGUwtFhSLqdQjatCpEwqDYVXw6cd3stkQiWKGlM41hm/3DZyt+/JyDF7+78VDAa5Q= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 20:00:35 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 20:00:35 +0000 From: "Asveren, Tolga" To: Roman Shpount , Paul Kyzivat Thread-Topic: [sipcore] Source address selection in SIP Thread-Index: AQHSOA7D/pjoAyNyqUWPf0xxdh5WHaDNlECAgAAtOwCAAAkEAIAAJqdQ Date: Mon, 7 Nov 2016 20:00:34 +0000 Message-ID: References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> <718f4ecc-173b-a7a1-1fa5-e72ca5ffecda@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 1855b25a-1f75-479a-12c9-08d40748bcc8 x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:5b3FOdUTE57J6mJjLC1/xG/QuxlPLiWzglDngUJmWcaJScnMrLuNixp41+OQmDrppuv5m09kDI1pwEFG4raGRg+99vMsZi7ovFgQyQIAid0HZ4Zhb6VUOApC/dbyWLxxJ7fMU0dvLWuUk5pP1N5Rf6Dn2ORIGrHHf3FmolocdEEs+SEGAamzqYKHd2BKMiXt1ug4eqGt5T6hapntYlLCPcploN9MnsoVQMYtPc9UyaJk0DJwR+5lTKrabAcLdEY/N1G2j02/jI9uOOvZXVSrwhSYyOvLvcqRrfKwhRlSd8zZSMZ/CNbdWe4bZGZD8/P5NvZWhMv6TSRDB2RE8gbdtadgDDnDq9Zg9njM4rjC7Lw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2350; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045074)(6060229)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6046074)(6061226); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(199003)(43544003)(377454003)(189002)(7846002)(7736002)(106356001)(4326007)(76176999)(5002640100001)(8936002)(8676002)(74316002)(81166006)(81156014)(93886004)(19580395003)(19300405004)(19580405001)(68736007)(50986999)(97736004)(6116002)(790700001)(3846002)(5001770100001)(102836003)(586003)(11100500001)(7696004)(87936001)(2171001)(66066001)(2950100002)(5660300001)(15975445007)(16236675004)(77096005)(10400500002)(86362001)(54356999)(76576001)(19625215002)(92566002)(551934003)(189998001)(19609705001)(99286002)(106116001)(9686002)(3280700002)(105586002)(2906002)(3660700001)(33656002)(122556002)(2900100001)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350142C7203AF32B2B615F0B2A70SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 20:00:34.9418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 20:00:47 -0000 --_000_SN2PR03MB2350142C7203AF32B2B615F0B2A70SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aS0gRm9yIFVEUCwgc2hvdWxkbuKAmXQgdGhlIHJlcGx5IHNlbnQgYmFzZWQgb24g4oCccmVjZWl2 ZWTigJ0gcGFyYW1ldGVyPyAoUkZDMzI2MSAxOC4yLjIpDQpUaGlzIHNob3VsZCB0YWtlIGNhcmUg b2YgdGhlIElQIEFkZHJlc3MgaXNzdWUgSU1ITy4NCg0KaWktIEZvciB0aGUgcG9ydCwg4oCccnBv cnTigJ0gd291bGQgcHJvdmlkZSBhIHNvbHV0aW9uIGJ1dCBpdCBpcyBub3QgZGVmaW5lZCBpbiBS RkMzMjYxIGJ1dCBpbiBSRkMzNTgxIChJTUhPIGl0IGlzIGEgZ29vZCBpZGVhIGZvciB0aGUgc2Vu ZGVyIGFsd2F5cyBhZGQgdGhlIOKAnHJwb3J04oCdLCBhbmQgZXZlbiBpbiBpdHMgYWJzZW5jZSBJ IHRoaW5rIHRoZXJlIGlzIG5vIGhhcm0gZm9yIHRoZSByZWNlaXZlciB0byBhc3N1bWUgdGhhdCBp dCBoYXMgYmVlbiByZWNlaXZlZCBhbmQgaGVuY2UgdXNlIHRoZSBwb3J0IHZhbHVlIGluIHRoZSBw YWNrZXQgaGVhZGVyIGZvciByZXNwb25zZSByb3V0aW5nKS4NCg0KaWlpLSBJIGRvbuKAmXQgdGhp bmsg4oCccm91dGluZyByZXNwb25zZXMgZHVyaW5nIGZhaWxvdmVyIHdpdGhvdXQgZmFpbGluZyB0 aGUgdHJhbnNhY3Rpb27igJ0gaXMgYSB3aWRlbHkgcmVxdWlyZWQvaW1wbGVtZW50ZWQgc3RyYXRl Z3kuIEJ5IGFuZCBsYXJnZSwgc3VjaCB0cmFuc2FjdGlvbiBmYWlsIGFuZCBhcmUgcmV0cmllZC4N Cg0KSSBhbSBub3Qgc2F5aW5nIHRoYXQgcG9wdWxhdGluZyBWaWEgaGVhZGVyIHdpdGggdGhlIGFj dHVhbCBwYWNrZXQgc291cmNlIElQL3BvcnQgaXMgYSBiYWQgaWRlYSBidXQgSSB0aGluayB0aGVy ZSBpcyBub3RoaW5nIG11Y2ggYnJva2VuIGZyb20gcHJvdG9jb2wgbWVjaGFuaWNzIHBlcnNwZWN0 aXZlIGlmIGl0IGlzIG5vdCBkb25lLiBJbiBwcmFjdGljZSwgaXQgbWF5IGNhdXNlIOKAnGZhbHNl IGFsYXJtc+KAnSBhcyBmYXIgYXMgcHJlc2VuY2Ugb2YgYSBOQVQgZGV2aWNlIGlzIGNvbmNlcm5l ZC4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFuIFNocG91bnQNClNlbnQ6IE1vbmRheSwg Tm92ZW1iZXIgMDcsIDIwMTYgMTI6MzUgUE0NClRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFs dW0ubWl0LmVkdT4NCkNjOiBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtzaXBjb3JlXSBTb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gaW4gU0lQDQoNCk9uIE1vbiwgTm92 IDcsIDIwMTYgYXQgMTI6MDMgUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1 PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCklzIHRoZXJlIHNvbWUgdGhv dWdodCB0aGF0IHRoaXMgY2hvaWNlIGFmZmVjdHMgYW55dGhpbmcgZWxzZSBpbiB0aGUgb3V0Z29p bmcgbWVzc2FnZT8NCg0KVGhlIG9ubHkgb3RoZXIgaXNzdWUgdGhpcyBhZmZlY3RzIGlzIGRlbGl2 ZXJpbmcgU0lQIHJlc3BvbnNlIHRvIGEgbWVzc2FnZSB3aGVuIGNsaWVudCBJUCBjaGFuZ2VzIGlu IHRoZSBtaWRkbGUgb2YgdGhlIFNJUCB0cmFuc2FjdGlvbi4gWW91IGVpdGhlciBuZWVkIHRvIGFj Y2VwdCB0aGF0IHRoZSB0cmFuc2FjdGlvbiBjYW4gZmFpbCBvciBjb21lIHVwIHdpdGggYSBtZWNo YW5pc20gdG8gcmVjb3ZlciBhIFNJUCB0cmFuc2FjdGlvbiBvbiB0aGUgbmV3IGNsaWVudCBsb2Nh bCBJUCBvciB1c2Ugc29tZXRoaW5nIGxpa2UgVFVSTiB0byBhbHdheXMgdHVubmVsIFNJUCBtZXNz YWdlcyB0aHJvdWdoIHRoZSBzYW1lIElQL3BvcnQgaW4gdGhlIGNsb3VkIChyZXNvdXJjZSBpbnRl bnNpdmUpLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQo= --_000_SN2PR03MB2350142C7203AF32B2B615F0B2A70SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmktIEZvciBVRFAsIHNob3VsZG7igJl0IHRo ZSByZXBseSBzZW50IGJhc2VkIG9uIOKAnHJlY2VpdmVk4oCdIHBhcmFtZXRlcj8gKFJGQzMyNjEg MTguMi4yKQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgc2hvdWxkIHRha2UgY2FyZSBvZiB0aGUg SVAgQWRkcmVzcyBpc3N1ZSBJTUhPLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+aWktIEZvciB0aGUgcG9ydCwg4oCccnBvcnTigJ0gd291bGQgcHJvdmlkZSBhIHNv bHV0aW9uIGJ1dCBpdCBpcyBub3QgZGVmaW5lZCBpbiBSRkMzMjYxIGJ1dCBpbiBSRkMzNTgxIChJ TUhPIGl0IGlzIGEgZ29vZCBpZGVhIGZvciB0aGUgc2VuZGVyIGFsd2F5cyBhZGQgdGhlIOKAnHJw b3J04oCdLA0KIGFuZCBldmVuIGluIGl0cyBhYnNlbmNlIEkgdGhpbmsgdGhlcmUgaXMgbm8gaGFy bSBmb3IgdGhlIHJlY2VpdmVyIHRvIGFzc3VtZSB0aGF0IGl0IGhhcyBiZWVuIHJlY2VpdmVkIGFu ZCBoZW5jZSB1c2UgdGhlIHBvcnQgdmFsdWUgaW4gdGhlIHBhY2tldCBoZWFkZXIgZm9yIHJlc3Bv bnNlIHJvdXRpbmcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ aWlpLSBJIGRvbuKAmXQgdGhpbmsg4oCccm91dGluZyByZXNwb25zZXMgZHVyaW5nIGZhaWxvdmVy IHdpdGhvdXQgZmFpbGluZyB0aGUgdHJhbnNhY3Rpb27igJ0gaXMgYSB3aWRlbHkgcmVxdWlyZWQv aW1wbGVtZW50ZWQgc3RyYXRlZ3kuIEJ5IGFuZCBsYXJnZSwgc3VjaCB0cmFuc2FjdGlvbg0KIGZh aWwgYW5kIGFyZSByZXRyaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SSBhbSBub3Qgc2F5aW5nIHRoYXQgcG9wdWxhdGluZyBWaWEgaGVhZGVyIHdpdGggdGhl IGFjdHVhbCBwYWNrZXQgc291cmNlIElQL3BvcnQgaXMgYSBiYWQgaWRlYSBidXQgSSB0aGluayB0 aGVyZSBpcyBub3RoaW5nIG11Y2ggYnJva2VuIGZyb20gcHJvdG9jb2wgbWVjaGFuaWNzDQogcGVy c3BlY3RpdmUgaWYgaXQgaXMgbm90IGRvbmUuIEluIHByYWN0aWNlLCBpdCBtYXkgY2F1c2Ug4oCc ZmFsc2UgYWxhcm1z4oCdIGFzIGZhciBhcyBwcmVzZW5jZSBvZiBhIE5BVCBkZXZpY2UgaXMgY29u Y2VybmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNpcGNvcmUgW21haWx0bzpzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbWFuIFNocG91bnQ8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAwNywgMjAxNiAxMjozNSBQTTxicj4N CjxiPlRvOjwvYj4gUGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIFNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBpbiBTSVA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBOb3YgNywgMjAxNiBhdCAxMjowMyBQTSwgUGF1bCBL eXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJnZXQ9 Il9ibGFuayI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JcyB0aGVyZSBzb21lIHRob3VnaHQgdGhhdCB0aGlzIGNob2ljZSBhZmZlY3RzIGFueXRo aW5nIGVsc2UgaW4gdGhlIG91dGdvaW5nIG1lc3NhZ2U/PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb25seSBvdGhlciBpc3N1 ZSB0aGlzIGFmZmVjdHMgaXMgZGVsaXZlcmluZyBTSVAgcmVzcG9uc2UgdG8gYSBtZXNzYWdlIHdo ZW4gY2xpZW50IElQIGNoYW5nZXMgaW4gdGhlIG1pZGRsZSBvZiB0aGUgU0lQIHRyYW5zYWN0aW9u LiBZb3UgZWl0aGVyIG5lZWQgdG8gYWNjZXB0IHRoYXQgdGhlIHRyYW5zYWN0aW9uIGNhbiBmYWls IG9yIGNvbWUgdXAgd2l0aCBhIG1lY2hhbmlzbSB0byByZWNvdmVyIGEgU0lQDQogdHJhbnNhY3Rp b24gb24gdGhlIG5ldyBjbGllbnQgbG9jYWwgSVAgb3IgdXNlIHNvbWV0aGluZyBsaWtlIFRVUk4g dG8gYWx3YXlzIHR1bm5lbCBTSVAgbWVzc2FnZXMgdGhyb3VnaCB0aGUgc2FtZSBJUC9wb3J0IGlu IHRoZSBjbG91ZCAocmVzb3VyY2UgaW50ZW5zaXZlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJy Pg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN2PR03MB2350142C7203AF32B2B615F0B2A70SN2PR03MB2350namp_-- From nobody Mon Nov 7 12:14:41 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59121295EC for ; Mon, 7 Nov 2016 12:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jVawQ8zrY8M for ; Mon, 7 Nov 2016 12:14:37 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF8B129493 for ; Mon, 7 Nov 2016 12:14:37 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w33so94608794qtc.3 for ; Mon, 07 Nov 2016 12:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wtZV3/q+40dbFMnu1hKn8g+sCQR8dTq3DFd56wqhSlA=; b=bvQb6jtBQNbLWBbzNiCcvHuyPY3yRslHDC+5ML2jinqcNAVkiTmL98XrQmziLDqf1D QDUeQT+BKT0s6tQTSPqAvWVTeOOvF5J4/ZPx0SbMyA9g8Cj4bWKY4cyVpQsmhF6ebsXA Xc1bUNdBPhF8WVjD9lnz1ZCC89a4RHkU3U/ViwGTD5yvxDXrnYpnzhtT9bMT6ZvpXI87 dzUDO1Zn57bLD5CUmCGQlVRi6zSMcUkCnJbTpgAJGauSVTUHw7KwdjmJU4O0qx0Z/uMY virDYLg3EimaX6abobjAKpETjdU5UyX7NAilyP5jJzg6iYlEDu4uFMCyngHOcHBJ+pQG gMig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wtZV3/q+40dbFMnu1hKn8g+sCQR8dTq3DFd56wqhSlA=; b=Avn/GjuSfccWwrHNP8JrnMmXohXr9pwMDQWkB5Uu5Ci8MaR48u/SGweLWu99sYW8Jm TeLB1m85VxagvaMr5RkmsrswZuhxbFneAP9OeF8Tj8cGhi5OoBVXzvZzKXhmhtR2HU/P PpKtLf5VKKcfEx7IbyI/MPCMbSbnsJqZwO8Raaoekvfl4AtIqvjsjRTqegIQkppwfBsx jZRTYdPUnXnuMxncDHSnu3CsXd00Kof84Nc81ztg2LseQLyvRu4g3WlykzgFNDVtzFUd W7xLxk+jP+Iv6hD6KE+YwRNSHzgKtLmaOA5fu0pMW3kHBA/2blVe/gq1v+fvpjE1oZ6H BpaQ== X-Gm-Message-State: ABUngvcwtGM7AcN7i8LeIJdtU0gu7WOQ0GnQWRRu5wBuURjIIyyFM4th+1QKv3ydGmKWOA== X-Received: by 10.237.56.165 with SMTP id k34mr8675522qte.95.1478549676079; Mon, 07 Nov 2016 12:14:36 -0800 (PST) Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com. [209.85.216.176]) by smtp.gmail.com with ESMTPSA id n77sm17376963qkn.28.2016.11.07.12.14.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 12:14:35 -0800 (PST) Received: by mail-qt0-f176.google.com with SMTP id p16so94612794qta.0 for ; Mon, 07 Nov 2016 12:14:35 -0800 (PST) X-Received: by 10.237.53.43 with SMTP id a40mr8896852qte.71.1478549675495; Mon, 07 Nov 2016 12:14:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Mon, 7 Nov 2016 12:14:34 -0800 (PST) In-Reply-To: References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> <718f4ecc-173b-a7a1-1fa5-e72ca5ffecda@alum.mit.edu> From: Roman Shpount Date: Mon, 7 Nov 2016 15:14:34 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a11c01b1e30dd520540bbac9c Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 20:14:39 -0000 --001a11c01b1e30dd520540bbac9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a side note: received and rport are generally useless for TCP or TLS based transactions. Responses are supposed to be sent over the same TCP/TLS connection. For UDP, when sending a message you can safely put 127.0.0.1 in the VIA address and include rport. The response will get to the right place. I agree that always adding rport by the receiver is a good idea. Not implementing transaction fail-over when devices migrate from one IP to another typically causes about 1-2% call drops. If you are running a service with long average call duration, such as call conferencing service, this percentage becomes much higher. You can typically implement some sort of call recovery by using INVITE with Replaces to work around such dropped calls. Regards, _____________ Roman Shpount On Mon, Nov 7, 2016 at 3:00 PM, Asveren, Tolga wrote: > i- For UDP, shouldn=E2=80=99t the reply sent based on =E2=80=9Creceived= =E2=80=9D parameter? > (RFC3261 18.2.2) > > This should take care of the IP Address issue IMHO. > > > > ii- For the port, =E2=80=9Crport=E2=80=9D would provide a solution but it= is not defined > in RFC3261 but in RFC3581 (IMHO it is a good idea for the sender always a= dd > the =E2=80=9Crport=E2=80=9D, and even in its absence I think there is no = harm for the > receiver to assume that it has been received and hence use the port value > in the packet header for response routing). > > > > iii- I don=E2=80=99t think =E2=80=9Crouting responses during failover wit= hout failing the > transaction=E2=80=9D is a widely required/implemented strategy. By and la= rge, such > transaction fail and are retried. > > > > I am not saying that populating Via header with the actual packet source > IP/port is a bad idea but I think there is nothing much broken from > protocol mechanics perspective if it is not done. In practice, it may cau= se > =E2=80=9Cfalse alarms=E2=80=9D as far as presence of a NAT device is conc= erned. > > > > Thanks, > > Tolga > > > > *From:* sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Roman > Shpount > *Sent:* Monday, November 07, 2016 12:35 PM > *To:* Paul Kyzivat > *Cc:* SIPCORE > *Subject:* Re: [sipcore] Source address selection in SIP > > > > On Mon, Nov 7, 2016 at 12:03 PM, Paul Kyzivat > wrote: > > Is there some thought that this choice affects anything else in the > outgoing message? > > > > The only other issue this affects is delivering SIP response to a message > when client IP changes in the middle of the SIP transaction. You either > need to accept that the transaction can fail or come up with a mechanism = to > recover a SIP transaction on the new client local IP or use something lik= e > TURN to always tunnel SIP messages through the same IP/port in the cloud > (resource intensive). > > > > Regards, > > _____________ > Roman Shpount > > > --001a11c01b1e30dd520540bbac9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a side note: received and rport are generally useless= for TCP or TLS based transactions. Responses are supposed to be sent over = the same TCP/TLS connection.

For UDP, when sending a mes= sage you can safely put 127.0.0.1 in the VIA address and include rport. The= response will get to the right place. I agree that always adding rport by = the receiver is a good idea.

Not implementing tran= saction fail-over when devices migrate from one IP to another typically cau= ses about 1-2% call drops. If you are running a service with long average c= all duration, such as call conferencing service, this percentage becomes mu= ch higher. You can typically implement some sort of call recovery by using = INVITE with Replaces to work around such dropped calls.

Regards,
<= div>
_____= ________
Roman Shpount

On Mon, Nov 7, 2016 at 3:00 PM, Asveren, Tol= ga <tasveren@sonusnet.com> wrote:

i- For UDP, shouldn=E2=80=99t the rep= ly sent based on =E2=80=9Creceived=E2=80=9D parameter? (RFC3261 18.2.2)

This should take care of the IP Addre= ss issue IMHO.

=C2=A0

ii- For the port, =E2=80=9Crport=E2= =80=9D would provide a solution but it is not defined in RFC3261 but in RFC= 3581 (IMHO it is a good idea for the sender always add the =E2=80=9Crport= =E2=80=9D, and even in its absence I think there is no harm for the receiver to assum= e that it has been received and hence use the port value in the packet head= er for response routing).

=C2=A0

iii- I don=E2=80=99t think =E2=80=9Cr= outing responses during failover without failing the transaction=E2=80=9D i= s a widely required/implemented strategy. By and large, such transaction fail and are retried.

=C2=A0

I am not saying that populating Via h= eader with the actual packet source IP/port is a bad idea but I think there= is nothing much broken from protocol mechanics perspective if it is not done. In practice, it may cause =E2=80=9Cfalse al= arms=E2=80=9D as far as presence of a NAT device is concerned.

=C2=A0

Thanks,

Tolga

=C2=A0

From: sipcore [mailto:sipcore-bounces@ietf.o= rg] On Behalf Of Roman Shpount
Sent: Monday, November 07, 2016 12:35 PM
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Source address selection in SIP=

=C2=A0

On Mon, Nov 7, 2016 at 12:03 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

Is there some thought that this choice affects anyth= ing else in the outgoing message?

=C2=A0

The only other issue this affects is delivering SIP = response to a message when client IP changes in the middle of the SIP trans= action. You either need to accept that the transaction can fail or come up = with a mechanism to recover a SIP transaction on the new client local IP or use something like TURN to alway= s tunnel SIP messages through the same IP/port in the cloud (resource inten= sive).

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0


--001a11c01b1e30dd520540bbac9c-- From nobody Mon Nov 7 15:05:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A249F129B85; Mon, 7 Nov 2016 15:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7ulwVC76Cka; Mon, 7 Nov 2016 15:05:16 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F12129BAF; Mon, 7 Nov 2016 15:05:08 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA7N56Wa051923 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Nov 2016 17:05:07 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: SIPCORE Date: Mon, 07 Nov 2016 17:05:06 -0600 Message-ID: <2581BBD3-557C-4BD2-B6A7-CC472FB06038@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D0419DDD-97D5-4FFF-92FD-557E0D4BDDB2_=" Embedded-HTML: [{"HTML":[870, 8196], "plain":[273, 3405], "uuid":"1600C0CA-5C8A-43AB-B0D1-5C23687E04E7"}] X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "art-ads@ietf.org" , "dispatch@ietf.org" Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 23:05:19 -0000 --=_MailMate_D0419DDD-97D5-4FFF-92FD-557E0D4BDDB2_= Content-Type: text/plain; format=flowed The proposed new SIPCORE charter text is now available at https://datatracker.ietf.org/doc/charter-ietf-sipcore/ . It's identical to the text from Adam's email, other than some potential formatting differences. Thanks! Ben. On 4 Nov 2016, at 16:28, Adam Roach wrote: > [as SIPCORE chair] > > Back when we transitioned from the SIPPING/SIP working group structure > to SIPCORE, we put relatively tight limits on the SIPCORE charter. > This was a recognition of the fact that the volume of SIP-related work > at the time was too large for any one working group to reasonably > handle. Instead, the intention was that the DISPATCH model of creating > small, short-lived working groups for specific topics would be a > better way to manage the relatively heavy workload. > > Fast forward seven years to today. SIP is a much more mature protocol, > and the inflow of new work is significantly smaller than it was back > then. At the same time, we have had several small, self-contained work > items show up in DISPATCH that were deemed too small to create a new > working group for, but precluded from being dispatched to SIPCORE by > its charter. This has led to unnecessary delays as we determined the > best disposition for these items. > > We, the SIPCORE chairs and area director, seek to fix that. We would > like to amend the SIPCORE charter to allow it to take on small, > self-contained protocol extensions in addition to changes to the core > SIP protocol. This is a relatively minor update to the existing > charter, which expands the scope as described above, and adds back in > two of the architectural principles from the SIP charter which are > applicable only to protocol extensions. > > Please provide feedback on the proposed charter by sending email to > the SIPCORE mailing list. We will also discuss this briefly during the > DISPATCH session in Seoul. > > The proposed charter text follows. > >> The Session Initiation Protocol Core (SIPCore) working group is >> chartered to maintain and continue the development of the SIP >> protocol, >> currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, >> and >> 6665. >> >> The SIPCore working group will concentrate on specifications that >> update >> or replace the core SIP specifications named above as well as >> specifications pertaining to small, self-contained SIP protocol >> extensions. The process and requirements for new SIP extensions are >> documented in RFC5727, "Change Process for the Session Initiation >> Protocol". >> >> Throughout its work, the group will strive to maintain the basic >> model >> and architecture defined by SIP. In particular: >> >> 1. Services and features are provided end-to-end whenever possible. >> >> 2. Reuse of existing Internet protocols and architectures and >> integrating with other Internet applications is crucial. >> >> 3. Standards-track extensions and new features must be generally >> applicable, and not applicable only to a specific set of session >> types. >> >> 4. Simpler solutions that solve a given problem should be favored >> over more complex solutions. >> >> The primary source of change requirements to the core SIP >> specifications >> (enumerated above) will be a) interoperability problems that stem >> from >> ambiguous, or under-defined specification, and b) requirements from >> other working groups in the ART Area. The primary source of new >> protocol >> extensions is the DISPATCH working group, which will generally make >> the >> determination regarding whether new SIP-related work warrants a new >> working group or belongs in an existing one. > > For ease of reference, the existing SIPCORE charter is at > https://datatracker.ietf.org/doc/charter-ietf-sipcore/ > > Thanks! > > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=_MailMate_D0419DDD-97D5-4FFF-92FD-557E0D4BDDB2_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The proposed new SIPCORE charter text is now available= at https://datatracker.ietf.org/doc/charter-ietf-sipco= re/ . It's identical to the text from Adam's email, other than some p= otential formatting differences.
Thanks!
Ben.
On 4 Nov 2016, at 16:28, Adam Roach wrote:

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.


The= Session Initiation Protocol Core (SIPCore) working group is
cha= rtered to maintain and continue the development of the SIP protocol,
cur= rently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
666= 5.

The= SIPCore working group will concentrate on specifications that update
or replace the core SIP specifications named above as well as
spe= cifications pertaining to small, self-contained SIP protocol
=
ext= ensions.=C2=A0 The process and requirements for new SIP extensions are
doc= umented in RFC5727, "Change Process for the Session Initiation=
Pro= tocol".

Thr= oughout its work, the group will strive to maintain the basic model
and= architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and
=C2= =A0=C2=A0 integrating with other Internet applications is crucial.

3. Standards-track extensions and new features must be generally
=C2= =A0=C2=A0 applicable, and not applicable only to a specific set of session
=C2= =A0=C2=A0 types.

4. Simpler solutions that solve a given problem should be favored
=C2=A0= =C2=A0=C2=A0 over more complex solutions.

The= primary source of change requirements to the core SIP specifications
(en= umerated above) will be a) interoperability problems that stem from
amb= iguous, or under-defined specification, and b) requirements from
oth= er working groups in the ART Area. The primary source of new protocol
ext= ensions is the DISPATCH working group, which will generally make the<= /span>
det= ermination regarding whether new SIP-related work warrants a new<= /div>
wor= king group or belongs in an existing one.


For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charte= r-ietf-sipcore/

Thanks!

/a

___________________________= ____________________
dispatch mailing list
dispatch@ietf.org
--=_MailMate_D0419DDD-97D5-4FFF-92FD-557E0D4BDDB2_=-- From nobody Mon Nov 7 15:22:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F75F129AD0 for ; Mon, 7 Nov 2016 15:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJvPtcs2T7zY for ; Mon, 7 Nov 2016 15:22:36 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0127129789 for ; Mon, 7 Nov 2016 15:22:35 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA7NMQOh053315 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Nov 2016 17:22:28 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Henning Schulzrinne" Date: Mon, 07 Nov 2016 17:22:26 -0600 Message-ID: <9C196785-8945-4419-88E9-2C4DB9969F49@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: SIPCORE , Dan York Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 23:22:37 -0000 On 4 Nov 2016, at 20:17, Henning Schulzrinne wrote: > Will existing SIP-related drafts in DISPATCH be moved to SIPCORE? To my knowledge, there are no SIP related drafts that are actual milestones for DISPATCH. It would seem reasonable to "dispatch" drafts currently in discussion that fit the proposed new SIPCORE charter to SIPCORE. There have been some drafts that DISPATCH recommended to be AD sponsored. I wouldn't expect a wholesale move of active AD sponsored drafts to SIPCORE, but I think it is an option we could consider on a case by case basis. In any case, we should not hold up progress on active drafts pending the SIPCORE recharter. > > On Fri, Nov 4, 2016 at 8:23 PM, Dan York wrote: > >> Adam, >> >> On Nov 4, 2016, at 5:28 PM, Adam Roach wrote: >> >> >> >> We, the SIPCORE chairs and area director, seek to fix that. We would >> like >> to amend the SIPCORE charter to allow it to take on small, >> self-contained >> protocol extensions in addition to changes to the core SIP protocol. >> This >> is a relatively minor update to the existing charter, which expands >> the >> scope as described above, and adds back in two of the architectural >> principles from the SIP charter which are applicable only to protocol >> extensions. >> >> Please provide feedback on the proposed charter by sending email to >> the >> SIPCORE mailing list. We will also discuss this briefly during the >> DISPATCH >> session in Seoul. >> >> >> This makes sense to me. The proposed text looked fine to me. >> >> Dan >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Nov 7 17:28:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4AB127071 for ; Mon, 7 Nov 2016 17:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tygG1tXMT8NQ for ; Mon, 7 Nov 2016 17:28:41 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201FA12940F for ; Mon, 7 Nov 2016 17:28:41 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-09v.sys.comcast.net with SMTP id 3vDJc4dFq1XXB3vDMcfk6s; Tue, 08 Nov 2016 01:28:40 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-07v.sys.comcast.net with SMTP id 3vDKcfB4rV3TX3vDKc0dwu; Tue, 08 Nov 2016 01:28:40 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uA81SbYr025053; Mon, 7 Nov 2016 20:28:37 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uA81Saq2025046; Mon, 7 Nov 2016 20:28:36 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 07 Nov 2016 20:28:36 -0500 Message-ID: <8737j2g3p7.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfN3Qw1LmMqGM/gKg/0bBjU8vgJ0mwq4Ny2LokaAsJJBTjHtZVHIfmVdHcdS4H04c5TGGkcguRFsKtCkbzqG1djIA1lkixQp6DjFcfBXIad8WAmgJBwRo wb7dOGtb4uK7uaLjUzVLmS19SWIF05fnH5RUFGLrrNyxYe34FZohactAuf2k9N9/2+T+i0p495qdrg== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 01:28:42 -0000 "Olle E. Johansson" writes: > An IPv6 interface by default has multiple addresses. Today's computers > also quite frequently have multiple interfaces. A modern SIP stack > has many IP addresses to select from. > I tried to find any words in RFC 3261 or RFC 3263 about selection of > interfaces and addresses but found nothing. Having said that, it's > not easy so if anyone on sipcore can point me to the right section I > will be grateful. > > If not, I think we may need a clarification on Transaction layer > handling of IP address selection in the SIP protocol. Given a specific > target, how do we handle multiple interfaces and multiple addresses > per interface - which address do we put in the SIP messages - like in > via's, record-route, SDPs and contacts. > > We have been testing at SIPit with multiple ULAs attached to a network > and a proxy on one of the ULAs. No one could connect to that proxy > properly (sadly for me not even Kamailio itself, which brags about > having IPv6 support from day one). It seems to me that the relevant texts are: RFC 7984 section 4, "Clarification of Interaction with RFC 6724" RFC 6157 section 5, "Contacting Servers: Interaction of RFC 3263 and RFC 3484" RFC 6724 section 5, "Source Address Selection" In the case where the client's one IPv6 interface has a number of global-scope addresses, only one of which can talk to an outgoing router, and the destination has one IPv6 address (that can only be reached in the global scope), processing seems to progress as follows: Destination address selection is trivial, as there's only one destination address. Source address selection starts with all of the client's IPv6 addresses. RFC 6724 section 5's source address prioritization rules are performed as follows: Rule 1 makes no choice. Rule 2 makes no choice because all of the interface addresses have global scope. Rule 3 makes no choice because (I assume) no addresses are deprecated. Rule 4 makes no choice because (I assume) we are not using IPv6 mobility. Rule 5 makes no choice because the destination address is not one of the client's addresses. Rule 5.5 is: Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. If SA or SA's prefix is assigned by the selected next-hop that will be used to send to D and SB or SB's prefix is assigned by a different next-hop, then prefer SA. Similarly, if SB or SB's prefix is assigned by the next-hop that will be used to send to D and SA or SA's prefix is assigned by a different next-hop, then prefer SB. Now since there is only one next-hop router, the next-hop is well-defined. And that router has assigned the prefix of exactly one of the interface's addresses. Rule 5.5 prioritizes that source address above all the other addresses. Since that step prefers one address over all others, the remaining rules are not significant. Thus, the client should be using the source address which links to the proxy. Which is what you would expect. Interestingly, this logic is supposed to be incorporated into the getaddrinfo() function, so the SIP implementation shouldn't need to contain specific logic to handle it if the implementation invokes getaddrinfo(). However, that section has this qualifier: Discussion: An IPv6 implementation is not required to remember which next-hops advertised which prefixes. The conceptual models of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] have no such requirement. Hence, Rule 5.5 is only applicable to implementations that track this information. Interestingly, I've been having problems with my browser (an old edition of Firefox) when I got IPv6 service, and it is exactly this problem! > Executive question summary: Does the current set of SIP standards cover > IP address selection for the *sender* when we have multiple IP > interfaces (IPv4, IPv6) or just one interface with multiple addresses? RFC 6724 section 5 clearly deals with all addresses of all interfaces at the same time, so I think that issue is properly handled. Dale From nobody Tue Nov 8 00:39:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F66129BDC for ; Tue, 8 Nov 2016 00:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F1kCE6dvbmE for ; Tue, 8 Nov 2016 00:39:08 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0083.outbound.protection.outlook.com [104.47.33.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19CE129BDF for ; Tue, 8 Nov 2016 00:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qfFYD8ns7rqZfEMnGza87uO4EA38jwJJeJ1sFcKTZaA=; b=c2TFfxA0R0LF3FlxOVqAFPvWykgMyhE9wO1vyPM9Qr5sp3RwVKVemrsbo8BPonz4TUKKlzo+rapnOAw3L/5/U7J5ZmI6Tx+tDhAzTOZ51+lUdLAV63+xi76uSMUiVgf7x6dUbtcBI35WLmsQHGeiBRVQmNIl0tOshHifLEdPUqo= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Tue, 8 Nov 2016 08:38:58 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0707.006; Tue, 8 Nov 2016 08:38:58 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [sipcore] Source address selection in SIP Thread-Index: AQHSOA7D/pjoAyNyqUWPf0xxdh5WHaDNlECAgAAtOwCAAAkEAIAAJqdQgAAF2ACAAM7nwA== Date: Tue, 8 Nov 2016 08:38:58 +0000 Message-ID: References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <80999829-c6de-0cd0-589d-0dfb0bf5cd8a@jive.com> <718f4ecc-173b-a7a1-1fa5-e72ca5ffecda@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 089fde71-9f92-4ea5-d8c8-08d407b2aeed x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:5CfQ1er3C5ZKCmCznaeo0PufB0744tpY+FdjGY5JjYiYgHI8Rz3f2ukTjf6mu8T12qsz8Vx6rGc6sOr0ZFtXtCOPebZ/hh1KziDeWdTEPoPq58h8F8+jTcGLoebVD8cgLloEotl6hUoj0ut2VQaqVPoHag4fb7+lEVDc+9kTZviQjuluqVtBJic7EkRxd6P4/FvBtI2vdAUgk5h+JlKfb7Zr1lCyglO1wbVo6BxEQlBT2zJGjuoD+noFA9Q7SZ5DzMnlxByqKKFFzq086nVeweP4wGyIWmAD2HckLcoCcWV3WYseQVvh8cfIy2xSxgg6YTuaex6PRt8nODvtdAGGUjN+bDmj1li7M95S5U30tno= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2349; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045074)(6060229)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6046074)(6061226); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(377454003)(24454002)(43544003)(105586002)(7736002)(77096005)(106116001)(92566002)(97736004)(33656002)(87936001)(99286002)(101416001)(9686002)(66066001)(7846002)(81166006)(106356001)(551934003)(93886004)(76576001)(122556002)(76176999)(50986999)(586003)(54356999)(6116002)(790700001)(6916009)(86362001)(2950100002)(8936002)(2900100001)(68736007)(110136003)(2906002)(189998001)(4326007)(7696004)(3660700001)(74316002)(3280700002)(3846002)(19609705001)(8676002)(102836003)(5660300001)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350D0B4286580665C809167B2A60SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2016 08:38:58.4407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 08:39:11 -0000 --_000_SN2PR03MB2350D0B4286580665C809167B2A60SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBzdXJwcmlzZWQgdGhhdCBjYWxscyBmYWlsIGJlY2F1c2Ugb2YgSVAgYWRkcmVzcyBtaWdy YXRpb24uIFRoaXMgc2VlbXMgdG8gYmUgbW9yZSBvZiBhbiBhcHBsaWNhdGlvbiBpc3N1ZSByYXRo ZXIgdGhhbiByZWxhdGVkIHdpdGggdGhlIFNJUCBwcm90b2NvbC4gU0lQIGhhcyByZXRyYW5zbWlz c2lvbnMgZm9yIHRyYW5zYWN0aW9ucy4gSSB0aGluayBhcHBsaWNhdGlvbnMgbmVlZCB0byBiZSB1 cGRhdGVkL2NvcnJlY3RlZCBmb3IgdGhlIHNjZW5hcmlvcyB5b3UgbWVudGlvbi4NCg0KVGhhbmtz LA0KVG9sZ2ENCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29t XQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwNywgMjAxNiAzOjE1IFBNDQpUbzogQXN2ZXJlbiwg VG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4NCkNjOiBQYXVsIEt5eml2YXQgPHBreXppdmF0 QGFsdW0ubWl0LmVkdT47IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W3NpcGNvcmVdIFNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBpbiBTSVANCg0KSnVzdCBhIHNpZGUg bm90ZTogcmVjZWl2ZWQgYW5kIHJwb3J0IGFyZSBnZW5lcmFsbHkgdXNlbGVzcyBmb3IgVENQIG9y IFRMUyBiYXNlZCB0cmFuc2FjdGlvbnMuIFJlc3BvbnNlcyBhcmUgc3VwcG9zZWQgdG8gYmUgc2Vu dCBvdmVyIHRoZSBzYW1lIFRDUC9UTFMgY29ubmVjdGlvbi4NCg0KRm9yIFVEUCwgd2hlbiBzZW5k aW5nIGEgbWVzc2FnZSB5b3UgY2FuIHNhZmVseSBwdXQgMTI3LjAuMC4xIGluIHRoZSBWSUEgYWRk cmVzcyBhbmQgaW5jbHVkZSBycG9ydC4gVGhlIHJlc3BvbnNlIHdpbGwgZ2V0IHRvIHRoZSByaWdo dCBwbGFjZS4gSSBhZ3JlZSB0aGF0IGFsd2F5cyBhZGRpbmcgcnBvcnQgYnkgdGhlIHJlY2VpdmVy IGlzIGEgZ29vZCBpZGVhLg0KDQpOb3QgaW1wbGVtZW50aW5nIHRyYW5zYWN0aW9uIGZhaWwtb3Zl ciB3aGVuIGRldmljZXMgbWlncmF0ZSBmcm9tIG9uZSBJUCB0byBhbm90aGVyIHR5cGljYWxseSBj YXVzZXMgYWJvdXQgMS0yJSBjYWxsIGRyb3BzLiBJZiB5b3UgYXJlIHJ1bm5pbmcgYSBzZXJ2aWNl IHdpdGggbG9uZyBhdmVyYWdlIGNhbGwgZHVyYXRpb24sIHN1Y2ggYXMgY2FsbCBjb25mZXJlbmNp bmcgc2VydmljZSwgdGhpcyBwZXJjZW50YWdlIGJlY29tZXMgbXVjaCBoaWdoZXIuIFlvdSBjYW4g dHlwaWNhbGx5IGltcGxlbWVudCBzb21lIHNvcnQgb2YgY2FsbCByZWNvdmVyeSBieSB1c2luZyBJ TlZJVEUgd2l0aCBSZXBsYWNlcyB0byB3b3JrIGFyb3VuZCBzdWNoIGRyb3BwZWQgY2FsbHMuDQoN ClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIE1vbiwgTm92IDcs IDIwMTYgYXQgMzowMCBQTSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxt YWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQppLSBGb3IgVURQLCBzaG91bGRu 4oCZdCB0aGUgcmVwbHkgc2VudCBiYXNlZCBvbiDigJxyZWNlaXZlZOKAnSBwYXJhbWV0ZXI/IChS RkMzMjYxIDE4LjIuMikNClRoaXMgc2hvdWxkIHRha2UgY2FyZSBvZiB0aGUgSVAgQWRkcmVzcyBp c3N1ZSBJTUhPLg0KDQppaS0gRm9yIHRoZSBwb3J0LCDigJxycG9ydOKAnSB3b3VsZCBwcm92aWRl IGEgc29sdXRpb24gYnV0IGl0IGlzIG5vdCBkZWZpbmVkIGluIFJGQzMyNjEgYnV0IGluIFJGQzM1 ODEgKElNSE8gaXQgaXMgYSBnb29kIGlkZWEgZm9yIHRoZSBzZW5kZXIgYWx3YXlzIGFkZCB0aGUg 4oCccnBvcnTigJ0sIGFuZCBldmVuIGluIGl0cyBhYnNlbmNlIEkgdGhpbmsgdGhlcmUgaXMgbm8g aGFybSBmb3IgdGhlIHJlY2VpdmVyIHRvIGFzc3VtZSB0aGF0IGl0IGhhcyBiZWVuIHJlY2VpdmVk IGFuZCBoZW5jZSB1c2UgdGhlIHBvcnQgdmFsdWUgaW4gdGhlIHBhY2tldCBoZWFkZXIgZm9yIHJl c3BvbnNlIHJvdXRpbmcpLg0KDQppaWktIEkgZG9u4oCZdCB0aGluayDigJxyb3V0aW5nIHJlc3Bv bnNlcyBkdXJpbmcgZmFpbG92ZXIgd2l0aG91dCBmYWlsaW5nIHRoZSB0cmFuc2FjdGlvbuKAnSBp cyBhIHdpZGVseSByZXF1aXJlZC9pbXBsZW1lbnRlZCBzdHJhdGVneS4gQnkgYW5kIGxhcmdlLCBz dWNoIHRyYW5zYWN0aW9uIGZhaWwgYW5kIGFyZSByZXRyaWVkLg0KDQpJIGFtIG5vdCBzYXlpbmcg dGhhdCBwb3B1bGF0aW5nIFZpYSBoZWFkZXIgd2l0aCB0aGUgYWN0dWFsIHBhY2tldCBzb3VyY2Ug SVAvcG9ydCBpcyBhIGJhZCBpZGVhIGJ1dCBJIHRoaW5rIHRoZXJlIGlzIG5vdGhpbmcgbXVjaCBi cm9rZW4gZnJvbSBwcm90b2NvbCBtZWNoYW5pY3MgcGVyc3BlY3RpdmUgaWYgaXQgaXMgbm90IGRv bmUuIEluIHByYWN0aWNlLCBpdCBtYXkgY2F1c2Ug4oCcZmFsc2UgYWxhcm1z4oCdIGFzIGZhciBh cyBwcmVzZW5jZSBvZiBhIE5BVCBkZXZpY2UgaXMgY29uY2VybmVkLg0KDQpUaGFua3MsDQpUb2xn YQ0KDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0K U2VudDogTW9uZGF5LCBOb3ZlbWJlciAwNywgMjAxNiAxMjozNSBQTQ0KVG86IFBhdWwgS3l6aXZh dCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+Pg0K Q2M6IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFtzaXBjb3JlXSBTb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gaW4gU0lQDQoN Ck9uIE1vbiwgTm92IDcsIDIwMTYgYXQgMTI6MDMgUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRA YWx1bS5taXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCklzIHRo ZXJlIHNvbWUgdGhvdWdodCB0aGF0IHRoaXMgY2hvaWNlIGFmZmVjdHMgYW55dGhpbmcgZWxzZSBp biB0aGUgb3V0Z29pbmcgbWVzc2FnZT8NCg0KVGhlIG9ubHkgb3RoZXIgaXNzdWUgdGhpcyBhZmZl Y3RzIGlzIGRlbGl2ZXJpbmcgU0lQIHJlc3BvbnNlIHRvIGEgbWVzc2FnZSB3aGVuIGNsaWVudCBJ UCBjaGFuZ2VzIGluIHRoZSBtaWRkbGUgb2YgdGhlIFNJUCB0cmFuc2FjdGlvbi4gWW91IGVpdGhl ciBuZWVkIHRvIGFjY2VwdCB0aGF0IHRoZSB0cmFuc2FjdGlvbiBjYW4gZmFpbCBvciBjb21lIHVw IHdpdGggYSBtZWNoYW5pc20gdG8gcmVjb3ZlciBhIFNJUCB0cmFuc2FjdGlvbiBvbiB0aGUgbmV3 IGNsaWVudCBsb2NhbCBJUCBvciB1c2Ugc29tZXRoaW5nIGxpa2UgVFVSTiB0byBhbHdheXMgdHVu bmVsIFNJUCBtZXNzYWdlcyB0aHJvdWdoIHRoZSBzYW1lIElQL3BvcnQgaW4gdGhlIGNsb3VkIChy ZXNvdXJjZSBpbnRlbnNpdmUpLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hw b3VudA0KDQoNCg== --_000_SN2PR03MB2350D0B4286580665C809167B2A60SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gc3VycHJpc2VkIHRoYXQgY2FsbHMg ZmFpbCBiZWNhdXNlIG9mIElQIGFkZHJlc3MgbWlncmF0aW9uLiBUaGlzIHNlZW1zIHRvIGJlIG1v cmUgb2YgYW4gYXBwbGljYXRpb24gaXNzdWUgcmF0aGVyIHRoYW4gcmVsYXRlZCB3aXRoIHRoZSBT SVAgcHJvdG9jb2wuIFNJUCBoYXMNCiByZXRyYW5zbWlzc2lvbnMgZm9yIHRyYW5zYWN0aW9ucy4g SSB0aGluayBhcHBsaWNhdGlvbnMgbmVlZCB0byBiZSB1cGRhdGVkL2NvcnJlY3RlZCBmb3IgdGhl IHNjZW5hcmlvcyB5b3UgbWVudGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21h biBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBOb3ZlbWJlciAwNywgMjAxNiAzOjE1IFBNPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVu LCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUGF1 bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7OyBTSVBDT1JFICZsdDtzaXBj b3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIFNvdXJj ZSBhZGRyZXNzIHNlbGVjdGlvbiBpbiBTSVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBhIHNpZGUgbm90ZTogcmVjZWl2ZWQgYW5kIHJw b3J0IGFyZSBnZW5lcmFsbHkgdXNlbGVzcyBmb3IgVENQIG9yIFRMUyBiYXNlZCB0cmFuc2FjdGlv bnMuIFJlc3BvbnNlcyBhcmUgc3VwcG9zZWQgdG8gYmUgc2VudCBvdmVyIHRoZSBzYW1lIFRDUC9U TFMgY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkZvciBVRFAsIHdoZW4gc2VuZGluZyBhIG1lc3NhZ2UgeW91IGNhbiBzYWZlbHkgcHV0IDEy Ny4wLjAuMSBpbiB0aGUgVklBIGFkZHJlc3MgYW5kIGluY2x1ZGUgcnBvcnQuIFRoZSByZXNwb25z ZSB3aWxsIGdldCB0byB0aGUgcmlnaHQgcGxhY2UuIEkgYWdyZWUgdGhhdCBhbHdheXMgYWRkaW5n IHJwb3J0IGJ5IHRoZSByZWNlaXZlciBpcyBhIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IGltcGxlbWVudGluZyB0cmFu c2FjdGlvbiBmYWlsLW92ZXIgd2hlbiBkZXZpY2VzIG1pZ3JhdGUgZnJvbSBvbmUgSVAgdG8gYW5v dGhlciB0eXBpY2FsbHkgY2F1c2VzIGFib3V0IDEtMiUgY2FsbCBkcm9wcy4gSWYgeW91IGFyZSBy dW5uaW5nIGEgc2VydmljZSB3aXRoIGxvbmcgYXZlcmFnZSBjYWxsIGR1cmF0aW9uLCBzdWNoIGFz IGNhbGwgY29uZmVyZW5jaW5nIHNlcnZpY2UsIHRoaXMgcGVyY2VudGFnZQ0KIGJlY29tZXMgbXVj aCBoaWdoZXIuIFlvdSBjYW4gdHlwaWNhbGx5IGltcGxlbWVudCBzb21lIHNvcnQgb2YgY2FsbCBy ZWNvdmVyeSBieSB1c2luZyBJTlZJVEUgd2l0aCBSZXBsYWNlcyB0byB3b3JrIGFyb3VuZCBzdWNo IGRyb3BwZWQgY2FsbHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3Vu dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwg Tm92IDcsIDIwMTYgYXQgMzowMCBQTSwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0 bzp0YXN2ZXJlbkBzb251c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2ZXJlbkBzb251c25l dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPmktIEZvciBVRFAsIHNob3VsZG7igJl0IHRoZSByZXBseSBzZW50IGJhc2VkIG9uIOKAnHJl Y2VpdmVk4oCdIHBhcmFtZXRlcj8gKFJGQzMyNjEgMTguMi4yKQ0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhpcyBzaG91bGQgdGFrZSBjYXJlIG9mIHRoZSBJUCBBZGRyZXNzIGlzc3VlIElNSE8uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWktIEZvciB0aGUg cG9ydCwg4oCccnBvcnTigJ0gd291bGQgcHJvdmlkZSBhIHNvbHV0aW9uIGJ1dCBpdCBpcyBub3Qg ZGVmaW5lZCBpbiBSRkMzMjYxIGJ1dCBpbiBSRkMzNTgxDQogKElNSE8gaXQgaXMgYSBnb29kIGlk ZWEgZm9yIHRoZSBzZW5kZXIgYWx3YXlzIGFkZCB0aGUg4oCccnBvcnTigJ0sIGFuZCBldmVuIGlu IGl0cyBhYnNlbmNlIEkgdGhpbmsgdGhlcmUgaXMgbm8gaGFybSBmb3IgdGhlIHJlY2VpdmVyIHRv IGFzc3VtZSB0aGF0IGl0IGhhcyBiZWVuIHJlY2VpdmVkIGFuZCBoZW5jZSB1c2UgdGhlIHBvcnQg dmFsdWUgaW4gdGhlIHBhY2tldCBoZWFkZXIgZm9yIHJlc3BvbnNlIHJvdXRpbmcpLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmlpaS0gSSBkb27igJl0IHRo aW5rIOKAnHJvdXRpbmcgcmVzcG9uc2VzIGR1cmluZyBmYWlsb3ZlciB3aXRob3V0IGZhaWxpbmcg dGhlIHRyYW5zYWN0aW9u4oCdIGlzIGEgd2lkZWx5DQogcmVxdWlyZWQvaW1wbGVtZW50ZWQgc3Ry YXRlZ3kuIEJ5IGFuZCBsYXJnZSwgc3VjaCB0cmFuc2FjdGlvbiBmYWlsIGFuZCBhcmUgcmV0cmll ZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFtIG5v dCBzYXlpbmcgdGhhdCBwb3B1bGF0aW5nIFZpYSBoZWFkZXIgd2l0aCB0aGUgYWN0dWFsIHBhY2tl dCBzb3VyY2UgSVAvcG9ydCBpcyBhIGJhZCBpZGVhIGJ1dA0KIEkgdGhpbmsgdGhlcmUgaXMgbm90 aGluZyBtdWNoIGJyb2tlbiBmcm9tIHByb3RvY29sIG1lY2hhbmljcyBwZXJzcGVjdGl2ZSBpZiBp dCBpcyBub3QgZG9uZS4gSW4gcHJhY3RpY2UsIGl0IG1heSBjYXVzZSDigJxmYWxzZSBhbGFybXPi gJ0gYXMgZmFyIGFzIHByZXNlbmNlIG9mIGEgTkFUIGRldmljZSBpcyBjb25jZXJuZWQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNpcGNvcmUgW21haWx0bzo8YSBocmVm PSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9tYW4gU2hwb3Vu dDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDA3LCAyMDE2IDEyOjM1IFBNPGJy Pg0KPGI+VG86PC9iPiBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBh bHVtLm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gU0lQQ09SRSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaXBjb3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBTb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gaW4gU0lQ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgTm92IDcsIDIwMTYg YXQgMTI6MDMgUE0sIFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFs dW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SXMgdGhlcmUgc29tZSB0aG91Z2h0IHRoYXQgdGhpcyBjaG9pY2UgYWZmZWN0cyBhbnl0 aGluZyBlbHNlIGluIHRoZSBvdXRnb2luZyBtZXNzYWdlPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBvbmx5IG90aGVy IGlzc3VlIHRoaXMgYWZmZWN0cyBpcyBkZWxpdmVyaW5nIFNJUCByZXNwb25zZSB0byBhIG1lc3Nh Z2Ugd2hlbiBjbGllbnQgSVAgY2hhbmdlcyBpbiB0aGUgbWlkZGxlIG9mIHRoZSBTSVAgdHJhbnNh Y3Rpb24uIFlvdSBlaXRoZXIgbmVlZCB0byBhY2NlcHQgdGhhdCB0aGUgdHJhbnNhY3Rpb24NCiBj YW4gZmFpbCBvciBjb21lIHVwIHdpdGggYSBtZWNoYW5pc20gdG8gcmVjb3ZlciBhIFNJUCB0cmFu c2FjdGlvbiBvbiB0aGUgbmV3IGNsaWVudCBsb2NhbCBJUCBvciB1c2Ugc29tZXRoaW5nIGxpa2Ug VFVSTiB0byBhbHdheXMgdHVubmVsIFNJUCBtZXNzYWdlcyB0aHJvdWdoIHRoZSBzYW1lIElQL3Bv cnQgaW4gdGhlIGNsb3VkIChyZXNvdXJjZSBpbnRlbnNpdmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19f X19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN2PR03MB2350D0B4286580665C809167B2A60SN2PR03MB2350namp_-- From nobody Tue Nov 8 11:31:33 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD16129872 for ; Tue, 8 Nov 2016 11:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMoCnNmrFwyT for ; Tue, 8 Nov 2016 11:31:30 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979681295A0 for ; Tue, 8 Nov 2016 11:31:30 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id x190so228068684qkb.0 for ; Tue, 08 Nov 2016 11:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=mot0ty8O0pi0Y60ptt+feF3aj59xLH9+dlxO0QIm2HY=; b=mxrfGWuSGWtRkopBEb3U+BReBzSbI266mA5h8saxUGcVbES3mMrgJNGuOOdooy44/2 aaEAql9jYIYEut6KG1scaNja1t+3oV+cglXex9lgffl/fyyFcwekB/K0vuhLnBCfBPUN ueNlg2yzyGSFhRvsfZc13ObdjZvTU3prIFQZQcSCweB4LMiKBkjLhHd7yM8Dkl2Abf+i 8mh3LKFgVK0Vf1M6e8/YmgtXIW8yXWI2f/SUnQ1dWjY14d6vHuJbyFiC9L0um/CP+S8Q 9Xuw7BKQYwqfOgTFZZB6Fx74Y/ZYxuQ68ZWk2HJQGvm1puWqyTE01iwO4nI0SGQ/n4om 1Pug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=mot0ty8O0pi0Y60ptt+feF3aj59xLH9+dlxO0QIm2HY=; b=L1yGXx30tmhD3jkYnOjUfujxpCJ+aDwGXhYMlWbi6f2hKukbjTKO/XgO7w/EO33y1/ 4e7k61K8id86VczjYzGzl9oUCAWrsYBtn2WL4ENzKdvJOvHQCHIKViC9AcxI8Iur1w+W Zq08Ekf7LesAP0wPgFeav+xnx5kwgJfkihpBcObOWWfGlWkeq2bhIRWfB04Vjf+4Cb08 5U+ttmk6W12+tRZ2ULM0GDeh7yFnaM64oeHPz3FgmmYqMyK+1d/PEGWvNMlrmvF9Iw6S zgjMBO+2EuK2T1n7tZGrBb5rUoGW7uyiC6DhIC6OkTjTQPnGfWnJS2xGZGMvwF9kjDbi PUDg== X-Gm-Message-State: ABUngvcY1hqpnWmyE59SYagmTlHNJvciHe8DAP1AK97n4QRi0AeY3bjsWkFRVzjmhCOhgg== X-Received: by 10.55.99.141 with SMTP id x135mr13945217qkb.147.1478633489620; Tue, 08 Nov 2016 11:31:29 -0800 (PST) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com. [209.85.220.171]) by smtp.gmail.com with ESMTPSA id a54sm20216293qta.49.2016.11.08.11.31.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 11:31:29 -0800 (PST) Received: by mail-qk0-f171.google.com with SMTP id x190so228068235qkb.0 for ; Tue, 08 Nov 2016 11:31:29 -0800 (PST) X-Received: by 10.55.197.6 with SMTP id p6mr15961392qki.239.1478633488980; Tue, 08 Nov 2016 11:31:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Tue, 8 Nov 2016 11:31:28 -0800 (PST) From: Roman Shpount Date: Tue, 8 Nov 2016 14:31:28 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a1149a18cdd32e60540cf2f3e Archived-At: Cc: SIPCORE Subject: [sipcore] Source address cahnges in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 19:31:32 -0000 --001a1149a18cdd32e60540cf2f3e Content-Type: text/plain; charset=UTF-8 I am changing the subject since this is not about the SIP source address selection any more. On Tue, Nov 8, 2016 at 3:38 AM, Asveren, Tolga wrote: > I am surprised that calls fail because of IP address migration. This seems > to be more of an application issue rather than related with the SIP > protocol. SIP has retransmissions for transactions. I think applications > need to be updated/corrected for the scenarios you mention. > > > SIP has re-transmission for transactions but a lot of state full SIP transactions implementations will not update the via header between re-transmissions. So, if original message is sent from one IP and re-transmission from another, response to the re-transmission will go the the original IP/port. Another interesting error case is when SIP over TCP or TLS is used and IP address changes when SIP message is in flight. TCP connection is reset, but it is unclear if SIP message was delivered to the server. Also, server has no active TCP connection to send back the response. Both of those situations in combination with SIP Session Timers can cause calls to fail. Finally, there is a situation when server needs to send a SIP Session timer message to the client, but client IP have changed and client have not detected this change yet. In such cases, server need to lookup client IP/port based on GRUU in contact on every re-transmit. _____________ Roman Shpount --001a1149a18cdd32e60540cf2f3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am changing the subject since this is not about the SIP source addre= ss selection any more.

On Tue, Nov 8, 2016 at 3:38 AM, Asveren, Tolga <tasveren@sonu= snet.com> wrote:

I am surprised that calls fail because of IP= address migration. This seems to be more of an application issue rather th= an related with the SIP protocol. SIP has retransmissions for transactions. I think applications need to be updated/= corrected for the scenarios you mention.



SIP has re-transmission for transactions but a lot of state full SIP trans= actions implementations will not update the via header between re-transmiss= ions. So, if original message is sent from one IP and re-transmission from another, response to = the re-transmission will go the the original IP/port.

Another interesti= ng error case is when SIP over TCP or TLS = is used and IP addre= ss changes when SIP message is in flight. TCP connection is reset, but it is unclear if SIP mes= sage was delivered to the server. Also, server has no active TCP connection to send back the re= sponse.

Both of those situations in combination wi= th SIP Session Timers can cause calls to fail.

Fin= ally, there is a situation when server needs to send a SIP Session timer me= ssage to the client, but client IP have changed and client have not detected this change yet. I= n such cases, server need to lookup client IP/port based on GRUU in contact on every re-transmit.
_____________
Roman = Shpount
=C2=A0
--001a1149a18cdd32e60540cf2f3e-- From nobody Tue Nov 8 14:07:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD383129715 for ; Tue, 8 Nov 2016 14:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JM_d2ZSAKTHN for ; Tue, 8 Nov 2016 14:07:16 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4751298AB for ; Tue, 8 Nov 2016 14:07:15 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-01v.sys.comcast.net with SMTP id 4EXpcHb1eTaLw4EXycRSfW; Tue, 08 Nov 2016 22:07:14 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-03v.sys.comcast.net with SMTP id 4EXvcGB0jbQub4EXwcXRsQ; Tue, 08 Nov 2016 22:07:14 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uA8M7AVL020676; Tue, 8 Nov 2016 17:07:10 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uA8M79WI020673; Tue, 8 Nov 2016 17:07:09 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 08 Nov 2016 17:07:09 -0500 Message-ID: <87zil9d3si.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfPbWwxG5ANPVbTW10jmT5OObAsBiI9FBCLg08B9luVIn5TwGHauB3LaQ4OSxG2E1fS83YKLsMIMZoq6ItR8eOJKQLnEGfcz+UvoZYxZWciKI43bpNTvf 8NZKI7e26u0wudM1nxn/H9FRkAkU3qO1DUVt3xI/IXetv6Wq9HXbvO52jtJJDEdRLJ4L33IwWCAyRRyNpGk2GkIQO6cTa6e2FP5nx6mStUnJ/sxjtZRhOXDu Archived-At: Cc: sipcore@ietf.org, oej@edvina.net, roman@telurix.com Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 22:07:17 -0000 "Olle E. Johansson" writes: > So who decides what to put in the VIA of the SIP Options?? And also, how does it get put there? In many cases, it seems that the underlying network stack will send the request with the "right" source address, but the SIP client first has to extract from the network stack what the source address will be, then insert it into the Via header, and then send the request... I suppose this isn't an interesting question of protocol design, but it is probably an annoyance to implementers. Dale From nobody Tue Nov 8 14:20:00 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09348129569 for ; Tue, 8 Nov 2016 14:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05UaqrMfxOmH for ; Tue, 8 Nov 2016 14:19:57 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4E212954C for ; Tue, 8 Nov 2016 14:19:57 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-02v.sys.comcast.net with SMTP id 4EkGc3ySc0MKR4EkGcS0II; Tue, 08 Nov 2016 22:19:56 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-08v.sys.comcast.net with SMTP id 4EkEckrVb930J4EkEcerOq; Tue, 08 Nov 2016 22:19:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uA8MJrew022046; Tue, 8 Nov 2016 17:19:53 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uA8MJrnd022043; Tue, 8 Nov 2016 17:19:53 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: oej@edvina.net, sipcore@ietf.org In-Reply-To: <8737j2g3p7.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 08 Nov 2016 17:19:53 -0500 Message-ID: <87wpgdd37a.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfA49u/aERqX7lpnmyFoXIIL/1HXSrUlrETKRvIeUhHm7+KKkGUzLH+XNfjwAkQ9koUr4V0zOvI9g8KN37b6HVKA0nHDbZXSMzZXnEFM4l7jKvoz1Q0YD +gBxREfLXc5FdZriWMfDQJqAQlVIKypdkoem3bHSbR9vfgXcL8wO+fv9Sfvu4tBCE+mQ5ZFwv4G3GA== Archived-At: Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 22:19:59 -0000 "Olle E. Johansson" writes: > An IPv6 interface by default has multiple addresses. Today's computers > also quite frequently have multiple interfaces. A modern SIP stack > has many IP addresses to select from. > We have been testing at SIPit with multiple ULAs attached to a network > and a proxy on one of the ULAs. No one could connect to that proxy > properly (sadly for me not even Kamailio itself, which brags about > having IPv6 support from day one). Thinking more about this, it seems that a very similar problem occurs in IPv4: Consider a SIP client with two IPv4 interfaces, only one of which is on a network with a gateway router to the global Internet. When the client sends a message, it specifies the destination IPv4 address. The client's network stack consults the "route table" to find the IPv4 address of the global gateway and the interface with which to contact the gateway. The network stack uses the source address of that interface. Everything works as you would like. The only detail that is not covered is arranging for the Via to contain an address, host name, or rport such that the response can route back to the client. Approximately the same thing should happen in the IPv6 case that Olle cites: The underlying network stack will, by default, execute the IPv6 source selection algorithm based on the destination IPv6 address, and it will identify the IPv6 interface and the source address that can contact the gateway. However, Olle reports that the requests fail. I do not see how that could happen -- the default behavior of the network stack should cause the request to be sent in a way that will succeed. So I hope that Olle can supply more information regarding exactly how this failure happens. I suspect that the failure is more complicated that it initially appears. Dale From nobody Wed Nov 9 00:09:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD05129676 for ; Wed, 9 Nov 2016 00:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpR-7BpE2haY for ; Wed, 9 Nov 2016 00:09:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2E8129660 for ; Wed, 9 Nov 2016 00:09:15 -0800 (PST) Received: from [22.70.218.197] ([172.56.12.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA988tsY043423 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2016 02:09:02 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [172.56.12.7] claimed to be [22.70.218.197] References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> Mime-Version: 1.0 (1.0) In-Reply-To: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3C2DC0DC-3D79-4AA8-92DD-DCA3D43DF5E1@nostrum.com> X-Mailer: iPhone Mail (13G36) From: Adam Roach Date: Wed, 9 Nov 2016 17:08:49 +0900 To: "Olle E. Johansson" Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 08:09:17 -0000 [as individual] Can you give a little more detail about the nature of the failures? It's not= immediately clear what would fail here. As was pointed out elsewhere, for U= DP, responses are routed per received address; and for TCP, they're sent bac= k on the connection from which the request arrived. /a > On Nov 6, 2016, at 18:18, Olle E. Johansson wrote: >=20 > We have been testing at SIPit with multiple ULAs attached to a network and= a proxy on one of the ULAs. > No one could connect to that proxy properly (sadly for me not even Kamaili= o itself, which brags about having > IPv6 support from day one). From nobody Wed Nov 9 01:21:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBA4129534 for ; Wed, 9 Nov 2016 01:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dBkHUV2ZCNo for ; Wed, 9 Nov 2016 01:21:15 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0050.outbound.protection.outlook.com [104.47.33.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B701294EB for ; Wed, 9 Nov 2016 01:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1MpA2tslkR4Ehx+he84BtJp/FI/iDyTrgSaNgpN1Rng=; b=hUiw2lgpFnJnCanicK/WuTgMR51nvx1ZI61ZOwLuLJXdrg8rWyQTeNRe03zltLYuC08a5eOJkPNrD45RMdtzDGIB6fBMsn4BStbiDMofN0wxjz1z9HwTIXMGB8oRqleTkUuytN+0MJEuQBD/0MCGX9s6WlEGJnjX2kmf11gbGeE= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Wed, 9 Nov 2016 09:21:10 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0707.006; Wed, 9 Nov 2016 09:21:10 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [sipcore] Source address cahnges in SIP Thread-Index: AQHSOfa4iATDs2QIhUaFKEHbjf7VUaDQX/hA Date: Wed, 9 Nov 2016 09:21:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 6aa8b789-6bbe-430c-cb8e-08d40881be72 x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:tCm4fiCptgQp9tGb3RmPkYVE1je7kuEt8FfO1V5vfCNj4zA0U21DKKY8uBQ4hSL/EMqiTxqR058/2u3jtNnIvzpj+Ce4v9oe5Gshg24qXUSkZRGgSzZhivA1KW3gy5/6yWQgigoiJJaFgLXN73MNyhi9vwSW6UyxgyuKaYF9tr0iwc28cpPLssigO4YddwbC2/bqx9Y0V1W2OhcNoWGl0h3RAjkBPWs/gcVj+wTSH5xB9ebJTUqPO2TSAeETXGwPEFTRM3VKUJHFP02VgW34aMMCV/UF/W/2tk42sBSb19PTkfIIyViYpeqPCuE8xPRGIP3Xj1RzVu/qlQVbYxhskGhtyJN3s8eUxNHlUecircQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(6060229)(6045074)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6061226)(6046074); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(189002)(199003)(377454003)(8936002)(3660700001)(81166006)(3280700002)(122556002)(81156014)(8676002)(7736002)(74316002)(7846002)(4326007)(92566002)(9686002)(68736007)(87936001)(19609705001)(551934003)(66066001)(6116002)(106116001)(3846002)(86362001)(2906002)(99286002)(110136003)(33656002)(2900100001)(6916009)(790700001)(7696004)(106356001)(105586002)(2950100002)(586003)(50986999)(76576001)(76176999)(54356999)(77096005)(189998001)(5660300001)(102836003)(101416001)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350EF963A4CB59102754CDAB2B90SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2016 09:21:10.3668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address cahnges in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 09:21:17 -0000 --_000_SN2PR03MB2350EF963A4CB59102754CDAB2B90SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aS0gSWYgYSB0cmFuc2FjdGlvbiBmYWlscywgaXQgaXMgYXBwbGljYXRpb27igJlzIHJlc3BvbnNp YmlsaXR5IHRvIGRvIHRoZSByaWdodCB0aGluZyDigJN3aGF0ZXZlciB0aGF0IGlzIGJhc2VkIG9u IHRoZSBleHBlY3RlZCBvdXRjb21lLSwgZS5nLiBzZW5kaW5nIGEgbmV3IHJlcXVlc3QuDQppaS0g Rm9yIHRoZSBUQ1Agc2NlbmFyaW8geW91IG1lbnRpb25lZCwgaXQgaXMgYWdhaW4gdXAgdG8gdGhl IGFwcGxpY2F0aW9uIHRvIHNlbmQgYSBuZXcgcmVxdWVzdCBqdXN0IHRvIGJlIHN1cmUgdGhhdCBp dCBoYXMgYmVlbiByZWNlaXZlZC4NCmlpaS0gIEZvciBTSVAgU2Vzc2lvbiBUaW1lcnM6IFRoZXkg dXN1YWxseSBhcmUgc2V0IG9uIGEgdmFsdWUgbXVjaCBoaWdoZXIgdGhhbiB0cmFuc2FjdGlvbiB0 aW1lb3V0IHZhbHVlcy4NCg0KT3ZlcmFsbCwgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGEgc2Vy aW91cyBTSVAgcHJvdG9jb2wgbGV2ZWwgaXNzdWUgaGVyZSwgd2hpY2ggaXMgY2F1c2luZyBwYWlu IGluIHByYWN0aWNlLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFtt YWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAwOCwgMjAx NiAyOjMxIFBNDQpUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4NCkNj OiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IFNJUENPUkUgPHNpcGNvcmVA aWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2lwY29yZV0gU291cmNlIGFkZHJlc3MgY2FobmdlcyBpbiBT SVANCg0KSSBhbSBjaGFuZ2luZyB0aGUgc3ViamVjdCBzaW5jZSB0aGlzIGlzIG5vdCBhYm91dCB0 aGUgU0lQIHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBhbnkgbW9yZS4NCg0KT24gVHVlLCBOb3Yg OCwgMjAxNiBhdCAzOjM4IEFNLCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29t PG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+PiB3cm90ZToNCkkgYW0gc3VycHJpc2VkIHRo YXQgY2FsbHMgZmFpbCBiZWNhdXNlIG9mIElQIGFkZHJlc3MgbWlncmF0aW9uLiBUaGlzIHNlZW1z IHRvIGJlIG1vcmUgb2YgYW4gYXBwbGljYXRpb24gaXNzdWUgcmF0aGVyIHRoYW4gcmVsYXRlZCB3 aXRoIHRoZSBTSVAgcHJvdG9jb2wuIFNJUCBoYXMgcmV0cmFuc21pc3Npb25zIGZvciB0cmFuc2Fj dGlvbnMuIEkgdGhpbmsgYXBwbGljYXRpb25zIG5lZWQgdG8gYmUgdXBkYXRlZC9jb3JyZWN0ZWQg Zm9yIHRoZSBzY2VuYXJpb3MgeW91IG1lbnRpb24uDQoNCg0KU0lQIGhhcyByZS10cmFuc21pc3Np b24gZm9yIHRyYW5zYWN0aW9ucyBidXQgYSBsb3Qgb2Ygc3RhdGUgZnVsbCBTSVAgdHJhbnNhY3Rp b25zIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdCB1cGRhdGUgdGhlIHZpYSBoZWFkZXIgYmV0d2Vl biByZS10cmFuc21pc3Npb25zLiBTbywgaWYgb3JpZ2luYWwgbWVzc2FnZSBpcyBzZW50IGZyb20g b25lIElQIGFuZCByZS10cmFuc21pc3Npb24gZnJvbSBhbm90aGVyLCByZXNwb25zZSB0byB0aGUg cmUtdHJhbnNtaXNzaW9uIHdpbGwgZ28gdGhlIHRoZSBvcmlnaW5hbCBJUC9wb3J0Lg0KDQpBbm90 aGVyIGludGVyZXN0aW5nIGVycm9yIGNhc2UgaXMgd2hlbiBTSVAgb3ZlciBUQ1Agb3IgVExTIGlz IHVzZWQgYW5kIElQIGFkZHJlc3MgY2hhbmdlcyB3aGVuIFNJUCBtZXNzYWdlIGlzIGluIGZsaWdo dC4gVENQIGNvbm5lY3Rpb24gaXMgcmVzZXQsIGJ1dCBpdCBpcyB1bmNsZWFyIGlmIFNJUCBtZXNz YWdlIHdhcyBkZWxpdmVyZWQgdG8gdGhlIHNlcnZlci4gQWxzbywgc2VydmVyIGhhcyBubyBhY3Rp dmUgVENQIGNvbm5lY3Rpb24gdG8gc2VuZCBiYWNrIHRoZSByZXNwb25zZS4NCg0KQm90aCBvZiB0 aG9zZSBzaXR1YXRpb25zIGluIGNvbWJpbmF0aW9uIHdpdGggU0lQIFNlc3Npb24gVGltZXJzIGNh biBjYXVzZSBjYWxscyB0byBmYWlsLg0KDQpGaW5hbGx5LCB0aGVyZSBpcyBhIHNpdHVhdGlvbiB3 aGVuIHNlcnZlciBuZWVkcyB0byBzZW5kIGEgU0lQIFNlc3Npb24gdGltZXIgbWVzc2FnZSB0byB0 aGUgY2xpZW50LCBidXQgY2xpZW50IElQIGhhdmUgY2hhbmdlZCBhbmQgY2xpZW50IGhhdmUgbm90 IGRldGVjdGVkIHRoaXMgY2hhbmdlIHlldC4gSW4gc3VjaCBjYXNlcywgc2VydmVyIG5lZWQgdG8g bG9va3VwIGNsaWVudCBJUC9wb3J0IGJhc2VkIG9uIEdSVVUgaW4gY29udGFjdCBvbiBldmVyeSBy ZS10cmFuc21pdC4NCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0K --_000_SN2PR03MB2350EF963A4CB59102754CDAB2B90SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmktIElmIGEgdHJhbnNhY3Rpb24gZmFpbHMs IGl0IGlzIGFwcGxpY2F0aW9u4oCZcyByZXNwb25zaWJpbGl0eSB0byBkbyB0aGUgcmlnaHQgdGhp bmcg4oCTd2hhdGV2ZXIgdGhhdCBpcyBiYXNlZCBvbiB0aGUgZXhwZWN0ZWQgb3V0Y29tZS0sIGUu Zy4gc2VuZGluZyBhIG5ldyByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5paS0gRm9yIHRoZSBU Q1Agc2NlbmFyaW8geW91IG1lbnRpb25lZCwgaXQgaXMgYWdhaW4gdXAgdG8gdGhlIGFwcGxpY2F0 aW9uIHRvIHNlbmQgYSBuZXcgcmVxdWVzdCBqdXN0IHRvIGJlIHN1cmUgdGhhdCBpdCBoYXMgYmVl biByZWNlaXZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWlpLSZuYnNwOyBGb3IgU0lQIFNlc3Npb24g VGltZXJzOiBUaGV5IHVzdWFsbHkgYXJlIHNldCBvbiBhIHZhbHVlIG11Y2ggaGlnaGVyIHRoYW4g dHJhbnNhY3Rpb24gdGltZW91dCB2YWx1ZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPk92ZXJhbGwsIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhIHNlcmlv dXMgU0lQIHByb3RvY29sIGxldmVsIGlzc3VlIGhlcmUsIHdoaWNoIGlzIGNhdXNpbmcgcGFpbiBp biBwcmFjdGljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50IFtt YWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92 ZW1iZXIgMDgsIDIwMTYgMjozMSBQTTxicj4NCjxiPlRvOjwvYj4gQXN2ZXJlbiwgVG9sZ2EgJmx0 O3Rhc3ZlcmVuQHNvbnVzbmV0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFBhdWwgS3l6aXZhdCAm bHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1Jmd0OzsgU0lQQ09SRSAmbHQ7c2lwY29yZUBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NpcGNvcmVdIFNvdXJjZSBhZGRyZXNzIGNhaG5n ZXMgaW4gU0lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gY2hhbmdpbmcgdGhlIHN1YmplY3Qgc2lu Y2UgdGhpcyBpcyBub3QgYWJvdXQgdGhlIFNJUCBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gYW55 IG1vcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFR1ZSwgTm92IDgsIDIwMTYgYXQgMzozOCBBTSwgQXN2ZXJlbiwgVG9sZ2EgJmx0Ozxh IGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2 ZXJlbkBzb251c25ldC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBzdXJwcmlzZWQgdGhh dCBjYWxscyBmYWlsIGJlY2F1c2Ugb2YgSVAgYWRkcmVzcyBtaWdyYXRpb24uIFRoaXMgc2VlbXMg dG8gYmUgbW9yZSBvZiBhbiBhcHBsaWNhdGlvbg0KIGlzc3VlIHJhdGhlciB0aGFuIHJlbGF0ZWQg d2l0aCB0aGUgU0lQIHByb3RvY29sLiBTSVAgaGFzIHJldHJhbnNtaXNzaW9ucyBmb3IgdHJhbnNh Y3Rpb25zLiBJIHRoaW5rIGFwcGxpY2F0aW9ucyBuZWVkIHRvIGJlIHVwZGF0ZWQvY29ycmVjdGVk IGZvciB0aGUgc2NlbmFyaW9zIHlvdSBtZW50aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U0lQIGhhcyBy ZS10cmFuc21pc3Npb24gZm9yIHRyYW5zYWN0aW9ucyBidXQgYSBsb3Qgb2Ygc3RhdGUgZnVsbCBT SVAgdHJhbnNhY3Rpb25zIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdCB1cGRhdGUgdGhlIHZpYSBo ZWFkZXIgYmV0d2VlbiByZS10cmFuc21pc3Npb25zLiBTbywgaWYgb3JpZ2luYWwgbWVzc2FnZSBp cyBzZW50IGZyb20gb25lIElQIGFuZCByZS10cmFuc21pc3Npb24gZnJvbSBhbm90aGVyLCByZXNw b25zZQ0KIHRvIHRoZSByZS10cmFuc21pc3Npb24gd2lsbCBnbyB0aGUgdGhlIG9yaWdpbmFsIElQ L3BvcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFub3RoZXIgaW50ZXJlc3RpbmcgZXJyb3IgY2FzZSBpcyB3aGVuIFNJUCBvdmVyIFRDUCBv ciBUTFMgaXMgdXNlZCBhbmQgSVAgYWRkcmVzcyBjaGFuZ2VzIHdoZW4gU0lQIG1lc3NhZ2UgaXMg aW4gZmxpZ2h0LiBUQ1AgY29ubmVjdGlvbiBpcyByZXNldCwgYnV0IGl0IGlzIHVuY2xlYXIgaWYg U0lQIG1lc3NhZ2Ugd2FzIGRlbGl2ZXJlZCB0byB0aGUgc2VydmVyLiBBbHNvLCBzZXJ2ZXIgaGFz IG5vIGFjdGl2ZSBUQ1ANCiBjb25uZWN0aW9uIHRvIHNlbmQgYmFjayB0aGUgcmVzcG9uc2UuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJvdGgg b2YgdGhvc2Ugc2l0dWF0aW9ucyBpbiBjb21iaW5hdGlvbiB3aXRoIFNJUCBTZXNzaW9uIFRpbWVy cyBjYW4gY2F1c2UgY2FsbHMgdG8gZmFpbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmluYWxseSwgdGhlcmUgaXMgYSBzaXR1YXRpb24gd2hl biBzZXJ2ZXIgbmVlZHMgdG8gc2VuZCBhIFNJUCBTZXNzaW9uIHRpbWVyIG1lc3NhZ2UgdG8gdGhl IGNsaWVudCwgYnV0IGNsaWVudCBJUCBoYXZlIGNoYW5nZWQgYW5kIGNsaWVudCBoYXZlIG5vdCBk ZXRlY3RlZCB0aGlzIGNoYW5nZSB5ZXQuIEluIHN1Y2ggY2FzZXMsIHNlcnZlciBuZWVkIHRvIGxv b2t1cCBjbGllbnQgSVAvcG9ydCBiYXNlZCBvbiBHUlVVDQogaW4gY29udGFjdCBvbiBldmVyeSBy ZS10cmFuc21pdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN2PR03MB2350EF963A4CB59102754CDAB2B90SN2PR03MB2350namp_-- From nobody Wed Nov 9 01:23:08 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B441294B9 for ; Wed, 9 Nov 2016 01:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNWMowsNzTNU for ; Wed, 9 Nov 2016 01:23:04 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC651294AA for ; Wed, 9 Nov 2016 01:23:04 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id D7DF85390; Wed, 9 Nov 2016 10:22:55 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <3C2DC0DC-3D79-4AA8-92DD-DCA3D43DF5E1@nostrum.com> Date: Wed, 9 Nov 2016 10:23:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <3C2DC0DC-3D79-4AA8-92DD-DCA3D43DF5E1@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 09:23:06 -0000 > On 09 Nov 2016, at 09:08, Adam Roach wrote: >=20 > [as individual] >=20 > Can you give a little more detail about the nature of the failures? = It's not immediately clear what would fail here. As was pointed out = elsewhere, for UDP, responses are routed per received address; and for = TCP, they're sent back on the connection from which the request arrived. 1. DNS for a server has ULA address 2. Client with a hole set of IPv6 addresses - link local, global and = multiple ULA resolves DNS 3. Client fails to select ULA address as source to reach server /O >=20 > /a >=20 >> On Nov 6, 2016, at 18:18, Olle E. Johansson wrote: >>=20 >> We have been testing at SIPit with multiple ULAs attached to a = network and a proxy on one of the ULAs. >> No one could connect to that proxy properly (sadly for me not even = Kamailio itself, which brags about having >> IPv6 support from day one). >=20 From nobody Wed Nov 9 02:26:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A235B129993 for ; Wed, 9 Nov 2016 02:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5N6MWUGAaL2 for ; Wed, 9 Nov 2016 02:26:11 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0061.outbound.protection.outlook.com [104.47.36.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D62129997 for ; Wed, 9 Nov 2016 02:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B9QP413N8Kii3NnOF7nvPSi7v9spz8kQfA4ITHXxKRA=; b=WU0pbjk0Sz3KSbc7/GzAPZPpmxq1+XplFWzYSoXyY/45oRy5LDt20LeaNUrn1TWuYM1UyZLmrXL+t3GADUNFuk3DydDShelZLYtf9lH8NbjmwlZjws18FqqTncoXIIs+dyQNbBjDmBOQFg1pRTbzi6HAcx3N63lRLpYbXcJAoNY= Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2343.namprd03.prod.outlook.com (10.166.93.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Wed, 9 Nov 2016 10:25:57 +0000 Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.0707.013; Wed, 9 Nov 2016 10:25:57 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" , Adam Roach Thread-Topic: [sipcore] Source address selection in SIP Thread-Index: AQHSOA7D/pjoAyNyqUWPf0xxdh5WHaDQUOKAgAAUwICAABEqAA== Date: Wed, 9 Nov 2016 10:25:57 +0000 Message-ID: References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <3C2DC0DC-3D79-4AA8-92DD-DCA3D43DF5E1@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: ae4bb1a8-b1a1-4bde-62b2-08d4088acb88 x-microsoft-exchange-diagnostics: 1; CO2PR03MB2343; 7:b2axpBktNz5GOCyAv139OIhLOMs1B/HvBFsQ0zXYLBt3IQFjKwMqbz7jCGcOodrQRLdED3zSAM5XrpOI9r7e9mg29dz8F10c+dJYPeYISBYitLa0lUmq7VwKAVlm9ciuSFVVZJTl6FMPi1nqooso21vmrPUfzNaYlDEYtGWTMPTqID/UuBHW13n/vUD4C+uifZaQ+Ga+0h2GA91YCpyVfgvJeFzKjzqeBYPYGlDZ8CCCwesUJtsffh8YTr7yO22Ni7vSBT4xRztzcQMjr3pNBRBbKqvSWGdHwggZnyOvGe3D+tZ9FEwY+iJbdkc23E2SDPNi+jIlhKH9tVU8z0JYrv7Bpc9Gm3uLG3pAwiPI3RY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2343; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(6060229)(6045074)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061226)(6046074); SRVR:CO2PR03MB2343; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2343; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(199003)(13464003)(189002)(24454002)(76176999)(54356999)(50986999)(3846002)(9686002)(6116002)(102836003)(99286002)(106356001)(106116001)(105586002)(586003)(92566002)(122556002)(8936002)(33656002)(66066001)(77096005)(2900100001)(101416001)(2906002)(68736007)(4326007)(305945005)(8676002)(7736002)(189998001)(81156014)(81166006)(76576001)(74316002)(7696004)(2950100002)(7846002)(87936001)(97736004)(5001770100001)(86362001)(5660300001)(3660700001)(3280700002)(5890100001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2343; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2016 10:25:57.7162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2343 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 10:26:13 -0000 Isn't this more an issue on OS-level, that it fails to select ULA as the so= urce when destination is ULA? Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. > Johansson > Sent: Wednesday, November 09, 2016 4:23 AM > To: Adam Roach > Cc: SIPCORE ; Olle E Johansson > Subject: Re: [sipcore] Source address selection in SIP >=20 >=20 > > On 09 Nov 2016, at 09:08, Adam Roach wrote: > > > > [as individual] > > > > Can you give a little more detail about the nature of the failures? It'= s not > immediately clear what would fail here. As was pointed out elsewhere, for > UDP, responses are routed per received address; and for TCP, they're sent > back on the connection from which the request arrived. >=20 > 1. DNS for a server has ULA address > 2. Client with a hole set of IPv6 addresses - link local, global and mult= iple ULA > resolves DNS 3. Client fails to select ULA address as source to reach ser= ver >=20 > /O > > > > /a > > > >> On Nov 6, 2016, at 18:18, Olle E. Johansson wrote: > >> > >> We have been testing at SIPit with multiple ULAs attached to a network > and a proxy on one of the ULAs. > >> No one could connect to that proxy properly (sadly for me not even > >> Kamailio itself, which brags about having > >> IPv6 support from day one). > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Nov 9 02:35:20 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5BF1299B7 for ; Wed, 9 Nov 2016 02:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-ibR5S18JWI for ; Wed, 9 Nov 2016 02:35:16 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D31A1296D3 for ; Wed, 9 Nov 2016 02:35:15 -0800 (PST) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 89B245390; Wed, 9 Nov 2016 11:35:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 9 Nov 2016 11:34:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85615AD9-6EE3-4A38-B3C3-163CB9BBD622@edvina.net> References: <165501DC-37DB-4EFD-B596-51CCF8FB6902@edvina.net> <3C2DC0DC-3D79-4AA8-92DD-DCA3D43DF5E1@nostrum.com> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 10:35:18 -0000 > On 09 Nov 2016, at 11:25, Asveren, Tolga = wrote: >=20 > Isn't this more an issue on OS-level, that it fails to select ULA as = the source when destination is ULA? Could be an O/S level issue, but the report indicated that most O/S has = sorted out these problems in regards to IPv6. Which means that we need to make sure that implementations do the right = thing and use the right source address in the SIP message. Easy to test in the SIPit network - = maybe some of you can set something up for the IETF hackathon coming up? This failed miserably when we tested with many implementations.=20 I think the question for this group really is whether this is something = that needs some extra specification, as the current set of RFCs (as far as I can see) is pretty silent about = selecting IP address from a set=20 to choose from. Seems like most of the text is based on one single IP = per device. In addition we have the issue with changing IP during a call where = there=E2=80=99s no guidance for developers in the current set of documents. Outbound doesn=E2=80=99t really handle = in-dialog situations and there seems to be a set of different solutions out there. I am still not sure there=E2=80=99s a problem that requires additional = RFCs or updates from this wg or if it just something we should publish another SIP Forum developer document = about... /O >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. >> Johansson >> Sent: Wednesday, November 09, 2016 4:23 AM >> To: Adam Roach >> Cc: SIPCORE ; Olle E Johansson >> Subject: Re: [sipcore] Source address selection in SIP >>=20 >>=20 >>> On 09 Nov 2016, at 09:08, Adam Roach wrote: >>>=20 >>> [as individual] >>>=20 >>> Can you give a little more detail about the nature of the failures? = It's not >> immediately clear what would fail here. As was pointed out elsewhere, = for >> UDP, responses are routed per received address; and for TCP, they're = sent >> back on the connection from which the request arrived. >>=20 >> 1. DNS for a server has ULA address >> 2. Client with a hole set of IPv6 addresses - link local, global and = multiple ULA >> resolves DNS 3. Client fails to select ULA address as source to reach = server >>=20 >> /O >>>=20 >>> /a >>>=20 >>>> On Nov 6, 2016, at 18:18, Olle E. Johansson wrote: >>>>=20 >>>> We have been testing at SIPit with multiple ULAs attached to a = network >> and a proxy on one of the ULAs. >>>> No one could connect to that proxy properly (sadly for me not even >>>> Kamailio itself, which brags about having >>>> IPv6 support from day one). >>>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Nov 9 08:18:16 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9F31293E8 for ; Wed, 9 Nov 2016 08:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y2B_YsLrKVc for ; Wed, 9 Nov 2016 08:18:13 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4084F1293FF for ; Wed, 9 Nov 2016 08:18:13 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-07v.sys.comcast.net with SMTP id 4VZ1cTiNLff8q4VZkcKkkj; Wed, 09 Nov 2016 16:18:12 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-09v.sys.comcast.net with SMTP id 4VZhc5fa50vPt4VZic0W8t; Wed, 09 Nov 2016 16:18:11 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uA9GI8hK020672; Wed, 9 Nov 2016 11:18:08 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uA9GI6sE020664; Wed, 9 Nov 2016 11:18:06 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: <85615AD9-6EE3-4A38-B3C3-163CB9BBD622@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 09 Nov 2016 11:18:06 -0500 Message-ID: <87r36kaapt.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain X-CMAE-Envelope: MS4wfN0+FIT6TcPRnw7w462U8gifZoWAxXXCJB10pWbk3lh4o5qS+ZPqfx0jJTV6Gt7ho79aq+6IEoOTMvRsbtksg8dDoyRFJmDCtPPARL/7wv+9o7HzxZoz unAP4e9aoWXNMbh6YPsGBTWfKhAJtUQvusQ8S7mDAs/gWQBaBHB52br4WVb8JvLymLIv/4Tte1SugytOH69oXW4AAeS08Rt7oTjeSRDwTj63kcYqrz1WJH+I Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 16:18:15 -0000 "Olle E. Johansson" writes: > I think the question for this group really is whether this is > something that needs some extra specification, as the current set of > RFCs (as far as I can see) is pretty silent about selecting IP address > from a set to choose from. Seems like most of the text is based on one > single IP per device. It seems to me that the existing RFCs provide sufficient guidance, as my long-winded analysis a few days ago detailed. Dale From nobody Wed Nov 9 08:20:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD772129455 for ; Wed, 9 Nov 2016 08:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R13WXZ91xUjd for ; Wed, 9 Nov 2016 08:20:42 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E5B12941A for ; Wed, 9 Nov 2016 08:20:41 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with SMTP id 4VbacceHt8GkC4Vc9cDaVM; Wed, 09 Nov 2016 16:20:41 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-03v.sys.comcast.net with SMTP id 4Vc7cIyWabQub4Vc8cYzHq; Wed, 09 Nov 2016 16:20:40 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uA9GKciB020948; Wed, 9 Nov 2016 11:20:39 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uA9GKcf0020943; Wed, 9 Nov 2016 11:20:38 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 09 Nov 2016 11:20:38 -0500 Message-ID: <87oa1oaall.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain X-CMAE-Envelope: MS4wfKXFyBlLmAJsv31jmx5nw/bcTDI9/Sa/olUy3SddvNjLYp1CLV++ZwnHPgowgm9jc0PKfEUiqpvshUA/NqdAeR3JI8HehglH/pih08AsyNPu8CvZQeuJ hdn8Mjr78r5d8uaF2t9tQPPuyPGx05JVl8VTNyjECJjYZk+vowEXviyMXEuQaqgE6z+80AKSnz7SRXOVjRJiMxf/l39c6SJWzf8ToHbX8BLil74Y8m5Brg5F Archived-At: Cc: oej@edvina.net, sipcore@ietf.org Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 16:20:43 -0000 "Olle E. Johansson" writes: >> Can you give a little more detail about the nature of the failures? >> It's not immediately clear what would fail here. As was pointed out >> elsewhere, for UDP, responses are routed per received address; and >> for TCP, they're sent back on the connection from which the request >> arrived. > > 1. DNS for a server has ULA address > 2. Client with a hole set of IPv6 addresses - link local, global and > multiple ULA resolves DNS > 3. Client fails to select ULA address as source to reach server It would help if you listed all the addresses involved, or at least gave a generic description of what source address the client did select. Also, what version of Kamailio(sp?) was involved, and what was the OS that it was running on? Does Kamailio do source address selection itself or does it allow the OS to choose the source address? Dale From nobody Wed Nov 9 16:58:30 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B031612951A for ; Wed, 9 Nov 2016 16:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qylIdQbUCbqo for ; Wed, 9 Nov 2016 16:58:26 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C3C1294AC for ; Wed, 9 Nov 2016 16:58:26 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n21so167332534qka.3 for ; Wed, 09 Nov 2016 16:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=/iHjn60jKqIiacoaX2ep2taSfQX4iQaN3Auu0MBgZRE=; b=TBLoYzmfsu8m+uqmkbZc2iV7nzn9F2DGhcw76vZH8+p5IOblIMnOdRjCKIOUP3fpxh YbdZXyRVMkMmWlMFSncTM19APMrSBcgDy4/UDq4+rL3do1bQWHSAmhZcMKGQCC/y6hGc PUzVaENq8//zH2d6EpDHcKbuKXsu0y1zMREsM70SGNDVVL9xYl1IM2wp5Hj1h8YS3OWr EpyLpm1S+tzJ8EB81iDjh6d87IKltveOHGc8VdkLjOrrImXDYvNHo4JRebH2pgpVe6zk 44UgTgvUa5KGIxQKJQlitEc23IrE72Fzy7TtNHbCGeddxz5m1RKsCuzZP0cTjo/T3PhN y8UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/iHjn60jKqIiacoaX2ep2taSfQX4iQaN3Auu0MBgZRE=; b=IL5EaSWbpiN6tPrus3IRQ7yWrM7iW794oj1GAG/9TeRLB6isxvgrDVOLM5MQ7VCeie X2TAEHdSGRIqbmu/i8chfJH0zMPDv12WNVd6xvev5VPjlFLQ+e5kIdUiwjbsndMO/tJR aC02a8NAOT3cvQDXfQ0G8AbZSFhjzQ5no5hnEpI/Jtv6jujqInQu0kK2oLquHmZ7mPYS Pfq7s7a3lPOQZwo7xQS+rj1/8eH9Mck/crbBhu4iV0SljJ3/jyVGLjE5dkdKRR7BLGjj /SW2+Kh2EiKxOdCHxIA+frhUYl7prOWPoOW5QFb74GVXp1oMMaU2+qhRMxeP7GmHIE5D EMGQ== X-Gm-Message-State: ABUngveS7/gATLC29PLb0Z0S053CdoIRWBamzelJfLg3CG30jXaKMl01DC5fjsJRvX27tg== X-Received: by 10.55.201.8 with SMTP id q8mr2868598qki.42.1478739505817; Wed, 09 Nov 2016 16:58:25 -0800 (PST) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com. [209.85.220.181]) by smtp.gmail.com with ESMTPSA id p19sm1236996qte.23.2016.11.09.16.58.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 16:58:25 -0800 (PST) Received: by mail-qk0-f181.google.com with SMTP id n21so167332209qka.3 for ; Wed, 09 Nov 2016 16:58:25 -0800 (PST) X-Received: by 10.55.79.17 with SMTP id d17mr3188727qkb.110.1478739505139; Wed, 09 Nov 2016 16:58:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Wed, 9 Nov 2016 16:58:24 -0800 (PST) From: Roman Shpount Date: Wed, 9 Nov 2016 19:58:24 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a114a89cceba83f0540e7de29 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address changes in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 00:58:28 -0000 --001a114a89cceba83f0540e7de29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 9, 2016 at 4:21 AM, Asveren, Tolga wrote: > i- If a transaction fails, it is application=E2=80=99s responsibility to = do the > right thing =E2=80=93whatever that is based on the expected outcome-, e.g= . sending > a new request. > What happens on most of the clients if SIP Session timer refresh transaction fails? Form what I know, typically the call is torn down. > ii- For the TCP scenario you mentioned, it is again up to the application > to send a new request just to be sure that it has been received. > For TCP sending the same request for an existing transaction over a new flow can produce "interesting" results. In most cases response will be sent to via address and port from the original transaction, which are ephemeral. Plus the RFC says that message sent over TCP should be re-transmitted. > iii- For SIP Session Timers: They usually are set on a value much higher > than transaction timeout values. > It does not matter what SIP Session timer value is. If SIP Session timer refresh transaction fails, the whole call normally fails. > Overall, I don=E2=80=99t think there is a serious SIP protocol level issu= e here, > which is causing pain in practice. > > > Actually, as far as I know, there are at least two SIP protocol level issues here: 1. Handling of client IP change in the middle of transaction is not specified anywhere. 2. Handling of TCP connection tear down in the middle of transaction is not specified anywhere. Handling of SIP responses when client TCP connection was torn down in RFC 3621 (sending to received/port from VIA over TCP) does not work unless client is on public IP. Regards, _____________ Roman Shpount --001a114a89cceba83f0540e7de29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 9, 2016 at 4:21 AM, Asveren, Tolga <= tasveren@sonusnet.com> wrote:

i- If a transaction fails, it is application= =E2=80=99s responsibility to do the right thing =E2=80=93whatever that is b= ased on the expected outcome-, e.g. sending a new request.

=

What happens on mos= t of the clients if SIP Session timer refresh transaction fails? Form what = I know, typically the call is torn down.
=C2=A0

ii- For the TCP scenario you mentioned, it i= s again up to the application to send a new request just to be sure that it= has been received.


= For TCP sending the same request for an existing transaction over a new flo= w can produce "interesting" results. In most cases response will = be sent to via address and port from the original transaction, which are ep= hemeral. Plus the RFC says that message sent over TCP should be re-transmit= ted.
=C2=A0

iii-=C2=A0 For SIP Session Timers: They usua= lly are set on a value much higher than transaction timeout values.<= /p>


It does not matter what SIP= Session timer value is. If SIP Session timer refresh transaction fails, th= e whole call normally fails.
=C2=A0

Overall, I don=E2=80=99t think there is a se= rious SIP protocol level issue here, which is causing pain in practice.



Actually, as far as I know, there are at least two SIP protocol level issu= es here:

1. Handling of client IP change in the mi= ddle of transaction is not specified anywhere.=C2=A0
2. Handling = of TCP connection tear down in the middle of transaction is not specified a= nywhere. Handling of SIP responses when client TCP connection was torn down= in RFC 3621 (sending to received/port from VIA over TCP) does not work unl= ess client is on public IP.=C2=A0

Regards,
_____________
Roman Shpount=
=C2=A0
--001a114a89cceba83f0540e7de29-- From nobody Fri Nov 11 01:20:03 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7281129A8F for ; Fri, 11 Nov 2016 01:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKpt01bHj2l6 for ; Fri, 11 Nov 2016 01:20:00 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69FF129A88 for ; Fri, 11 Nov 2016 01:19:59 -0800 (PST) Received: from [192.168.40.20] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 0B7C46C04; Fri, 11 Nov 2016 10:19:51 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <87oa1oaall.fsf@hobgoblin.ariadne.com> Date: Fri, 11 Nov 2016 10:19:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8ED6B73A-4CEF-4930-B3E3-3A63C0DD0672@edvina.net> References: <87oa1oaall.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 09:20:02 -0000 > On 09 Nov 2016, at 17:20, Dale R. Worley wrote: >=20 > "Olle E. Johansson" writes: >>> Can you give a little more detail about the nature of the failures? >>> It's not immediately clear what would fail here. As was pointed out >>> elsewhere, for UDP, responses are routed per received address; and >>> for TCP, they're sent back on the connection from which the request >>> arrived. >>=20 >> 1. DNS for a server has ULA address >> 2. Client with a hole set of IPv6 addresses - link local, global and >> multiple ULA resolves DNS >> 3. Client fails to select ULA address as source to reach server >=20 > It would help if you listed all the addresses involved, or at least = gave > a generic description of what source address the client did select. I have no idea what address the clients selected - I just got no = messages to my server.=20 >=20 > Also, what version of Kamailio(sp?) was involved, and what was the OS > that it was running on? Does Kamailio do source address selection > itself or does it allow the OS to choose the source address? I guess at that time it was Kamailio 4.0 - I test the dev code in github so there=E2=80=99s no version number really. This was SIPit 31 in Nice, = France. There was a link to Kamailio=E2=80=99s code for doing this earlier in = this thread. I haven=E2=80=99t gone through the details, but I think we=E2=80=99re = opening a socket to the target and check what address the O/S selects.=20 Will try to set up more tests so I can file a bug report. :-) /O= From nobody Fri Nov 11 08:14:57 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F1D129717 for ; Fri, 11 Nov 2016 08:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyXny7ZNI-gw for ; Fri, 11 Nov 2016 08:14:55 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFBC129595 for ; Fri, 11 Nov 2016 08:14:54 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-06v.sys.comcast.net with SMTP id 5EStcUzmZ2Nhq5ETdcgr26; Fri, 11 Nov 2016 16:14:53 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-17v.sys.comcast.net with SMTP id 5ETbcMKPAb59W5ETcctmOf; Fri, 11 Nov 2016 16:14:53 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uABFUvOZ015947; Fri, 11 Nov 2016 10:30:57 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uABFUted015943; Fri, 11 Nov 2016 10:30:55 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: <8ED6B73A-4CEF-4930-B3E3-3A63C0DD0672@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 11 Nov 2016 10:30:55 -0500 Message-ID: <877f8a6nkg.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKgMLxlP4cc5HUikFNfVUc4aS8UGsZFIbKtg3XPEHpEAlhOL/dGr7xgx5yZerx4k7YIAnAMvh4Bs3SHLF7SCz3QBj4omYZHVcw8VT1jSqu7GU8+vicVV lEU7u8Esa2ce74heXcgYWAQ40o6gsYzDWr+gSIuuD/vvm83kQfg0UdCvFiaX/yi3pG2QlBfuBJoh0g== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 16:14:56 -0000 "Olle E. Johansson" writes: > I have no idea what address the clients selected - I just got no messages > to my server. > Will try to set up more tests so I can file a bug report. :-) It seems to me that there are two groups of possible causes. One group is fairly simple code failures, the OS is choosing the link address as the source address, Kamailio is choosing the wrong destination address, or something like that. That group has the property that you can point to some piece of code that is behaving incorrectly (out of specification). The other group comes from this clause in RFC 6724: Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. If SA or SA's prefix is assigned by the selected next-hop that will be used to send to D and SB or SB's prefix is assigned by a different next-hop, then prefer SA. Similarly, if SB or SB's prefix is assigned by the next-hop that will be used to send to D and SA or SA's prefix is assigned by a different next-hop, then prefer SB. Discussion: An IPv6 implementation is not required to remember which next-hops advertised which prefixes. The conceptual models of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] have no such requirement. Hence, Rule 5.5 is only applicable to implementations that track this information. It's possible that the OS is selecting a global source address but not one that the gateway router sees, because the source address has a prefix that the router isn't using. And it seems from "Discussion" that the OS is *not* required by existing RFCs to pick the global address with the prefix that will actually get gatewayed globally. How to go about fixing that is an interesting question. Dale From nobody Fri Nov 11 09:44:56 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E474612941A for ; Fri, 11 Nov 2016 09:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnCwsz-cLVem for ; Fri, 11 Nov 2016 09:44:52 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A17112963A for ; Fri, 11 Nov 2016 09:44:51 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n204so27874360qke.2 for ; Fri, 11 Nov 2016 09:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=beiJph1AXZ/MBh+LZdj/xWzxnZomm20FcfhoxrYlpYU=; b=tQpofsAVNpeozSJC1uOaciGX5eZBl+5VNg2nYBasdoFmyzs5XzhUwbSuwz5U5Wxvvd ZwDf+dQcK02pirvu5kqtGm91RfYTjUQjaIxkOzHb48K8w+lLL3TswD1WDa6T0NQLl5Ql qZMArEHNUDDbJplvC6KL3yIr4Q4xWLyBfyyeGVFnJHpM0bgYBouk79yO5Lm6gY0mgHHc f1BANSf0uyxjKkTCLO2CdkP8hqlO0n582Gl8nLqxxKK4LKvKjLjDNLsTvs3dHbmdAVcl WUUy/4PH415Gmh3dB305MuhhQph1qz4UzJBS1IFDjP3vB/ZfDyeBi6dwHRbJ6aRwxIt7 0xQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=beiJph1AXZ/MBh+LZdj/xWzxnZomm20FcfhoxrYlpYU=; b=WMVs5FkSentY56QBftqvasW3KroSTGhn/HkWxcV5ct9qtN4nhMGZ4xQM3VHRnvqPGk LBdCNAl8vlReJWCq8d+DvzrTFMaW/oTdnrzuA0W3jsa8BbUu8SV7IfsIM/ldyprCn8S3 QBu+3073P5b6xC7bw2huXqVCjmkGWhhXKirMG83hTD+tkCrDZyk+dRl+Ke22Spu/6iIk gY4UZmUDNNhz04x9Xn/r510vw14BguwqMdwZBZxlie27y1dcalDEV7OCu69q/a5GwcLX pzfcbRX638KLhCQsk2wnQFMBowC+2i0thi1yok4cfGV6kH/UkzXkcgUmH0tal+0cWuIK cl8g== X-Gm-Message-State: ABUngvcPON6qWwFt44FIvdKO91DixSLQANdCOX6olhw5vYDLu9k8wRGPbyPLQed//bG1zw== X-Received: by 10.55.8.20 with SMTP id 20mr4952709qki.3.1478886290490; Fri, 11 Nov 2016 09:44:50 -0800 (PST) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com. [209.85.216.179]) by smtp.gmail.com with ESMTPSA id i41sm5875059qtc.18.2016.11.11.09.44.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Nov 2016 09:44:49 -0800 (PST) Received: by mail-qt0-f179.google.com with SMTP id c47so13760749qtc.2 for ; Fri, 11 Nov 2016 09:44:49 -0800 (PST) X-Received: by 10.200.37.101 with SMTP id 34mr417259qtn.273.1478886289546; Fri, 11 Nov 2016 09:44:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Fri, 11 Nov 2016 09:44:48 -0800 (PST) In-Reply-To: <877f8a6nkg.fsf@hobgoblin.ariadne.com> References: <8ED6B73A-4CEF-4930-B3E3-3A63C0DD0672@edvina.net> <877f8a6nkg.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Fri, 11 Nov 2016 12:44:48 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11404b32f3a6b005410a0ba0 Archived-At: Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 17:44:55 -0000 --001a11404b32f3a6b005410a0ba0 Content-Type: text/plain; charset=UTF-8 One issue we saw was clients using VPN, with VPN taking them to a business network which blocks SIP. This is why we added addresses enumeration and STUN checks similar to ICE to verify which address actually has internet access. Regards, _____________ Roman Shpount On Fri, Nov 11, 2016 at 10:30 AM, Dale R. Worley wrote: > "Olle E. Johansson" writes: > > I have no idea what address the clients selected - I just got no messages > > to my server. > > > Will try to set up more tests so I can file a bug report. :-) > > It seems to me that there are two groups of possible causes. One group > is fairly simple code failures, the OS is choosing the link address as > the source address, Kamailio is choosing the wrong destination address, > or something like that. That group has the property that you can point > to some piece of code that is behaving incorrectly (out of > specification). > > The other group comes from this clause in RFC 6724: > > Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. > If SA or SA's prefix is assigned by the selected next-hop that will > be used to send to D and SB or SB's prefix is assigned by a different > next-hop, then prefer SA. Similarly, if SB or SB's prefix is > assigned by the next-hop that will be used to send to D and SA or > SA's prefix is assigned by a different next-hop, then prefer SB. > > Discussion: An IPv6 implementation is not required to remember > which next-hops advertised which prefixes. The conceptual models > of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] > have no such requirement. Hence, Rule 5.5 is only applicable to > implementations that track this information. > > It's possible that the OS is selecting a global source address but not > one that the gateway router sees, because the source address has a > prefix that the router isn't using. And it seems from "Discussion" that > the OS is *not* required by existing RFCs to pick the global address > with the prefix that will actually get gatewayed globally. > > How to go about fixing that is an interesting question. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11404b32f3a6b005410a0ba0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One issue we saw was clients using VPN, with VPN taking th= em to a business network which blocks SIP.

This is why w= e added addresses enumeration and STUN checks similar to ICE to verify whic= h address actually has internet access.

Regards,
_____________
Roman Shpount

On Fri, Nov 11, 2016 at 10:30 AM, Dale R. Wo= rley <worley@ariadne.com> wrote:
"Olle E. Johansson" <oej@edvina.net> writes:
> I have no idea what address the clients select= ed - I just got no messages
> to my server.

> Will try to set up more tests so I can file a = bug report. :-)

It seems to me that there are two groups of possible causes.=C2=A0 O= ne group
is fairly simple code failures, the OS is choosing the link address as
the source address, Kamailio is choosing the wrong destination address,
or something like that.=C2=A0 That group has the property that you can poin= t
to some piece of code that is behaving incorrectly (out of
specification).

The other group comes from this clause in RFC 6724:

=C2=A0 =C2=A0Rule 5.5: Prefer addresses in a prefix advertised by the next-= hop.
=C2=A0 =C2=A0If SA or SA's prefix is assigned by the selected next-hop = that will
=C2=A0 =C2=A0be used to send to D and SB or SB's prefix is assigned by = a different
=C2=A0 =C2=A0next-hop, then prefer SA.=C2=A0 Similarly, if SB or SB's p= refix is
=C2=A0 =C2=A0assigned by the next-hop that will be used to send to D and SA= or
=C2=A0 =C2=A0SA's prefix is assigned by a different next-hop, then pref= er SB.

=C2=A0 =C2=A0 =C2=A0 Discussion: An IPv6 implementation is not required to = remember
=C2=A0 =C2=A0 =C2=A0 which next-hops advertised which prefixes.=C2=A0 The c= onceptual models
=C2=A0 =C2=A0 =C2=A0 of IPv6 hosts in Section 5 of [RFC4861] and Section 3 = of [RFC4191]
=C2=A0 =C2=A0 =C2=A0 have no such requirement.=C2=A0 Hence, Rule 5.5 is onl= y applicable to
=C2=A0 =C2=A0 =C2=A0 implementations that track this information.

It's possible that the OS is selecting a global source address but not<= br> one that the gateway router sees, because the source address has a
prefix that the router isn't using.=C2=A0 And it seems from "Discu= ssion" that
the OS is *not* required by existing RFCs to pick the global address
with the prefix that will actually get gatewayed globally.

How to go about fixing that is an interesting question.

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--001a11404b32f3a6b005410a0ba0-- From nobody Sun Nov 13 01:56:32 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBDA12944E for ; Sun, 13 Nov 2016 01:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOR8YvOFpPJ3 for ; Sun, 13 Nov 2016 01:56:27 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0052.outbound.protection.outlook.com [104.47.38.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CBE12957A for ; Sun, 13 Nov 2016 01:56:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wRD+bVnuX2GG3JpSD/OLoUfGfPOQxBgAjSi7FU68vSY=; b=lNmbnEPzeoz5d5Sm48i94bFHYoRqbsplbFAxVIf/zYcRYlJEXz5kv6A7u6w13ia1bdhf0X9yAFGkm3VKrYrN79ALArJpq9Wut3qQ7tmjhq5OX7JlBTwVTvTrq3VbH9u8TAyUGdC1TVZmoBxrORziLytWmlCTkGibph75z/PUIog= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sun, 13 Nov 2016 09:56:22 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0721.010; Sun, 13 Nov 2016 09:56:22 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [sipcore] Source address changes in SIP Thread-Index: AQHSOu2OWDYqpr+tO0qGIr6HdliNp6DWr6Bg Date: Sun, 13 Nov 2016 09:56:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:QKffvjzrGkKe3k86bHmbOt9HYCClUiSh40jevhUtD16HU/2AcKcpCN/GbZds53ygqLREU4wA9EmwPjJtzOEBNETicLJNIA1CpQMVsXMr9RontjI1MLTK/OxtLx6hqAjdBDgRRr7g2iL3Ft510geAYn1bfhSY678c6oFaBQhtTOwUVv0jtqOVC+y9ZxQVIiLORCOwo6qgm3qczdkMjivThlixL4i9pvyNQGnlCrWKjNUoLlXsOv/byWcn05Yw+F43rLjQtaZ5BAaA7Gq31lr3/k0rWmuhgeceunn+7VGgrUS+6+l1IgvF6n/aOg5i5EED9Te5Amw14s0Em+uKkuJx1Picmu9S8ZHTLGO49eHzkGk= x-ms-office365-filtering-correlation-id: 617b74df-0279-4b6e-87f2-08d40bab52f0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060229)(6045074)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6046074)(6061226); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(336003)(199003)(24454002)(189002)(377454003)(5660300001)(3280700002)(19609705001)(2950100002)(77096005)(586003)(74316002)(8676002)(6916009)(790700001)(3846002)(92566002)(9686002)(66066001)(6116002)(7736002)(2906002)(4326007)(102836003)(76576001)(110136003)(2900100001)(229853002)(87936001)(122556002)(101416001)(33656002)(106116001)(105586002)(97736004)(81156014)(54356999)(68736007)(99286002)(8936002)(76176999)(50986999)(7696004)(81166006)(551934003)(3660700001)(189998001)(86362001)(7846002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350E8AAA808E61E8F3ADB8FB2BD0SN2PR03MB2350namp_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 09:56:22.3679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Source address changes in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 09:56:30 -0000 --_000_SN2PR03MB2350E8AAA808E61E8F3ADB8FB2BD0SN2PR03MB2350namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx0aG91Z2gg4oCcUkZDNDAyOCAxMCBQZXJmb3JtaW5nIFJlZnJlc2hlc+KAnSBtZW50aW9ucyBh Ym91dCB0ZXJtaW5hdGluZyB0aGUgc2Vzc2lvbiBpZiB0aGUgc2Vzc2lvbiByZWZyZXNoIHRyYW5z YWN0aW9uIHRpbWVzIG91dCBubyBub3JtYXRpdmUga2V5d29yZHMgYXJlIHVzZWQuIEkgYWxzbyBk byBub3QgdGhpbmsgdHJ5aW5nIGEgbmV3IHNlc3Npb24gcmVmcmVzaCByZXF1ZXN0IHdvdWxkIGJy ZWFrIGFueXRoaW5nIGZyb20gcHJvdG9jb2wgbWFjaGluZXJ5IHBlcnNwZWN0aXZlLiBJIHdvdWxk IHRoaW5rIHRoYXQgYSBwcnVkZW50IGFwcGxpY2F0aW9uIHdvdWxkIGRvIHNvIGlmIHRoZXJlIGlz IHRoZSBwb3NzaWJpbGl0eSBvZiBJUCBBZGRyZXNzIGNoYW5nZSDigJMgb3Igc29tZSBvdGhlciBy ZWFzb24gZm9yIHJldHJ5IC0uDQoNClRoZSBUQ1AgY2FzZSBpcyBzaW1pbGFyLCBpZiB0aGUgZGVw bG95bWVudCBtb2RlbC9wcmFjdGljYWwgcmVhbGl0eSBtYWtlcyBpdCBwb3NzaWJsZSB0aGF0IFRD UCBjb25uZWN0aW9uIGNhbiBiZSBicm9rZW4gZXZlbiBpZiB0aGUgcGVlciBpcyBzdGlsbCBhbGl2 ZSwgYW4gYXBwbGljYXRpb24gYmV0dGVyIHVzZXMgcmV0cmFuc21pc3Npb24gZm9yIFRDUCBhcyB3 ZWxsLiBBY3R1YWxseSwgdGhpcyBpcyB3aWRlbHkgaW1wbGVtZW50ZWQgaW4gbWFueSBwcm9kdWN0 cy4gUGxlYXNlIG5vdGUgdGhhdCBlc3RhYmxpc2hpbmcgYSBUQ1AgY29ubmVjdGlvbiB0b3dhcmQg VUUgYmVoaW5kIE5BVCB3b3VsZCBub3QgYmUgcG9zc2libGUgZm9yIG1vc3Qgb2YgdGhlIGNhc2Vz IGV2ZW4gaWYgdGhlIG5ldHdvcmstc2lkZSBlcXVpcG1lbnQgdXNlcyB0aGUg4oCccmlnaHTigJ0g SVAgQWRkcmVzcy9wb3J0LiBNb3N0IE5BVHMgd291bGRu4oCZdCBhbGxvdyBpbmJvdW5kIFRDUCBj b25uZWN0aW9uIGVzdGFibGlzaG1lbnQgcmVxdWVzdHMuDQoNCk92ZXJhbGwsIGFsbCB0aGVzZSBz ZWVtIHRvIG1lIG1vcmUgaXNzdWVzIHRvIGJlIGRlYWx0IHdpdGggYnkgYXBwbGljYXRpb25zLiBJ TUhPIGl0IGNvdWxkIGJlIGFuIGlkZWEgdG8gcHJvdmlkZSBzb21lIGd1aWRhbmNlIGFib3V0IHRo ZW0gaW4gYSDigJxCZXN0IFByYWN0aWNlc+KAnSBkb2N1bWVudCB0aG91Z2guDQoNClRoYW5rcywN ClRvbGdhDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDksIDIwMTYgNzo1OCBQTQ0KVG86IEFzdmVyZW4s IFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+DQpDYzogUGF1bCBLeXppdmF0IDxwa3l6aXZh dEBhbHVtLm1pdC5lZHU+OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtzaXBjb3JlXSBTb3VyY2UgYWRkcmVzcyBjaGFuZ2VzIGluIFNJUA0KDQpPbiBXZWQsIE5vdiA5 LCAyMDE2IGF0IDQ6MjEgQU0sIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208 bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KaS0gSWYgYSB0cmFuc2FjdGlv biBmYWlscywgaXQgaXMgYXBwbGljYXRpb27igJlzIHJlc3BvbnNpYmlsaXR5IHRvIGRvIHRoZSBy aWdodCB0aGluZyDigJN3aGF0ZXZlciB0aGF0IGlzIGJhc2VkIG9uIHRoZSBleHBlY3RlZCBvdXRj b21lLSwgZS5nLiBzZW5kaW5nIGEgbmV3IHJlcXVlc3QuDQoNCldoYXQgaGFwcGVucyBvbiBtb3N0 IG9mIHRoZSBjbGllbnRzIGlmIFNJUCBTZXNzaW9uIHRpbWVyIHJlZnJlc2ggdHJhbnNhY3Rpb24g ZmFpbHM/IEZvcm0gd2hhdCBJIGtub3csIHR5cGljYWxseSB0aGUgY2FsbCBpcyB0b3JuIGRvd24u DQoNCmlpLSBGb3IgdGhlIFRDUCBzY2VuYXJpbyB5b3UgbWVudGlvbmVkLCBpdCBpcyBhZ2FpbiB1 cCB0byB0aGUgYXBwbGljYXRpb24gdG8gc2VuZCBhIG5ldyByZXF1ZXN0IGp1c3QgdG8gYmUgc3Vy ZSB0aGF0IGl0IGhhcyBiZWVuIHJlY2VpdmVkLg0KDQpGb3IgVENQIHNlbmRpbmcgdGhlIHNhbWUg cmVxdWVzdCBmb3IgYW4gZXhpc3RpbmcgdHJhbnNhY3Rpb24gb3ZlciBhIG5ldyBmbG93IGNhbiBw cm9kdWNlICJpbnRlcmVzdGluZyIgcmVzdWx0cy4gSW4gbW9zdCBjYXNlcyByZXNwb25zZSB3aWxs IGJlIHNlbnQgdG8gdmlhIGFkZHJlc3MgYW5kIHBvcnQgZnJvbSB0aGUgb3JpZ2luYWwgdHJhbnNh Y3Rpb24sIHdoaWNoIGFyZSBlcGhlbWVyYWwuIFBsdXMgdGhlIFJGQyBzYXlzIHRoYXQgbWVzc2Fn ZSBzZW50IG92ZXIgVENQIHNob3VsZCBiZSByZS10cmFuc21pdHRlZC4NCg0KaWlpLSAgRm9yIFNJ UCBTZXNzaW9uIFRpbWVyczogVGhleSB1c3VhbGx5IGFyZSBzZXQgb24gYSB2YWx1ZSBtdWNoIGhp Z2hlciB0aGFuIHRyYW5zYWN0aW9uIHRpbWVvdXQgdmFsdWVzLg0KDQpJdCBkb2VzIG5vdCBtYXR0 ZXIgd2hhdCBTSVAgU2Vzc2lvbiB0aW1lciB2YWx1ZSBpcy4gSWYgU0lQIFNlc3Npb24gdGltZXIg cmVmcmVzaCB0cmFuc2FjdGlvbiBmYWlscywgdGhlIHdob2xlIGNhbGwgbm9ybWFsbHkgZmFpbHMu DQoNCk92ZXJhbGwsIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhIHNlcmlvdXMgU0lQIHByb3Rv Y29sIGxldmVsIGlzc3VlIGhlcmUsIHdoaWNoIGlzIGNhdXNpbmcgcGFpbiBpbiBwcmFjdGljZS4N Cg0KDQpBY3R1YWxseSwgYXMgZmFyIGFzIEkga25vdywgdGhlcmUgYXJlIGF0IGxlYXN0IHR3byBT SVAgcHJvdG9jb2wgbGV2ZWwgaXNzdWVzIGhlcmU6DQoNCjEuIEhhbmRsaW5nIG9mIGNsaWVudCBJ UCBjaGFuZ2UgaW4gdGhlIG1pZGRsZSBvZiB0cmFuc2FjdGlvbiBpcyBub3Qgc3BlY2lmaWVkIGFu eXdoZXJlLg0KMi4gSGFuZGxpbmcgb2YgVENQIGNvbm5lY3Rpb24gdGVhciBkb3duIGluIHRoZSBt aWRkbGUgb2YgdHJhbnNhY3Rpb24gaXMgbm90IHNwZWNpZmllZCBhbnl3aGVyZS4gSGFuZGxpbmcg b2YgU0lQIHJlc3BvbnNlcyB3aGVuIGNsaWVudCBUQ1AgY29ubmVjdGlvbiB3YXMgdG9ybiBkb3du IGluIFJGQyAzNjIxIChzZW5kaW5nIHRvIHJlY2VpdmVkL3BvcnQgZnJvbSBWSUEgb3ZlciBUQ1Ap IGRvZXMgbm90IHdvcmsgdW5sZXNzIGNsaWVudCBpcyBvbiBwdWJsaWMgSVAuDQoNClJlZ2FyZHMs DQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_SN2PR03MB2350E8AAA808E61E8F3ADB8FB2BD0SN2PR03MB2350namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFsdGhvdWdoIOKAnFJGQzQwMjggMTAgUGVy Zm9ybWluZyBSZWZyZXNoZXPigJ0gbWVudGlvbnMgYWJvdXQgdGVybWluYXRpbmcgdGhlIHNlc3Np b24gaWYgdGhlIHNlc3Npb24gcmVmcmVzaCB0cmFuc2FjdGlvbiB0aW1lcyBvdXQgbm8gbm9ybWF0 aXZlIGtleXdvcmRzIGFyZSB1c2VkLg0KIEkgYWxzbyBkbyBub3QgdGhpbmsgdHJ5aW5nIGEgbmV3 IHNlc3Npb24gcmVmcmVzaCByZXF1ZXN0IHdvdWxkIGJyZWFrIGFueXRoaW5nIGZyb20gcHJvdG9j b2wgbWFjaGluZXJ5IHBlcnNwZWN0aXZlLiBJIHdvdWxkIHRoaW5rIHRoYXQgYSBwcnVkZW50IGFw cGxpY2F0aW9uIHdvdWxkIGRvIHNvIGlmIHRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSBvZiBJUCBB ZGRyZXNzIGNoYW5nZSDigJMgb3Igc29tZSBvdGhlciByZWFzb24gZm9yIHJldHJ5IC0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgVENQIGNhc2UgaXMgc2lt aWxhciwgaWYgdGhlIGRlcGxveW1lbnQgbW9kZWwvcHJhY3RpY2FsIHJlYWxpdHkgbWFrZXMgaXQg cG9zc2libGUgdGhhdCBUQ1AgY29ubmVjdGlvbiBjYW4gYmUgYnJva2VuIGV2ZW4gaWYgdGhlIHBl ZXIgaXMgc3RpbGwgYWxpdmUsIGFuIGFwcGxpY2F0aW9uDQogYmV0dGVyIHVzZXMgcmV0cmFuc21p c3Npb24gZm9yIFRDUCBhcyB3ZWxsLiBBY3R1YWxseSwgdGhpcyBpcyB3aWRlbHkgaW1wbGVtZW50 ZWQgaW4gbWFueSBwcm9kdWN0cy4gUGxlYXNlIG5vdGUgdGhhdCBlc3RhYmxpc2hpbmcgYSBUQ1Ag Y29ubmVjdGlvbiB0b3dhcmQgVUUgYmVoaW5kIE5BVCB3b3VsZCBub3QgYmUgcG9zc2libGUgZm9y IG1vc3Qgb2YgdGhlIGNhc2VzIGV2ZW4gaWYgdGhlIG5ldHdvcmstc2lkZSBlcXVpcG1lbnQgdXNl cyB0aGUg4oCccmlnaHTigJ0NCiBJUCBBZGRyZXNzL3BvcnQuIE1vc3QgTkFUcyB3b3VsZG7igJl0 IGFsbG93IGluYm91bmQgVENQIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCByZXF1ZXN0cy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk92ZXJhbGwsIGFsbCB0aGVz ZSBzZWVtIHRvIG1lIG1vcmUgaXNzdWVzIHRvIGJlIGRlYWx0IHdpdGggYnkgYXBwbGljYXRpb25z LiBJTUhPIGl0IGNvdWxkIGJlIGFuIGlkZWEgdG8gcHJvdmlkZSBzb21lIGd1aWRhbmNlIGFib3V0 IHRoZW0gaW4gYSDigJxCZXN0IFByYWN0aWNlc+KAnQ0KIGRvY3VtZW50IHRob3VnaC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJp eC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAwOSwgMjAxNiA3 OjU4IFBNPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNu ZXQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBhbHVt Lm1pdC5lZHUmZ3Q7OyBTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIFNvdXJjZSBhZGRyZXNzIGNoYW5nZXMgaW4gU0lQPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBXZWQsIE5vdiA5LCAyMDE2IGF0IDQ6MjEgQU0sIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBo cmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFzdmVy ZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmktIElmIGEgdHJhbnNh Y3Rpb24gZmFpbHMsIGl0IGlzIGFwcGxpY2F0aW9u4oCZcyByZXNwb25zaWJpbGl0eSB0byBkbyB0 aGUgcmlnaHQgdGhpbmcg4oCTd2hhdGV2ZXIgdGhhdA0KIGlzIGJhc2VkIG9uIHRoZSBleHBlY3Rl ZCBvdXRjb21lLSwgZS5nLiBzZW5kaW5nIGEgbmV3IHJlcXVlc3QuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2hhdCBoYXBwZW5zIG9uIG1vc3Qgb2YgdGhlIGNsaWVudHMgaWYgU0lQIFNlc3Npb24gdGlt ZXIgcmVmcmVzaCB0cmFuc2FjdGlvbiBmYWlscz8gRm9ybSB3aGF0IEkga25vdywgdHlwaWNhbGx5 IHRoZSBjYWxsIGlzIHRvcm4gZG93bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWktIEZvciB0aGUgVENQIHNjZW5hcmlvIHlvdSBtZW50 aW9uZWQsIGl0IGlzIGFnYWluIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiB0byBzZW5kIGEgbmV3IHJl cXVlc3QganVzdA0KIHRvIGJlIHN1cmUgdGhhdCBpdCBoYXMgYmVlbiByZWNlaXZlZC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIFRDUCBzZW5kaW5nIHRoZSBzYW1lIHJlcXVlc3QgZm9y IGFuIGV4aXN0aW5nIHRyYW5zYWN0aW9uIG92ZXIgYSBuZXcgZmxvdyBjYW4gcHJvZHVjZSAmcXVv dDtpbnRlcmVzdGluZyZxdW90OyByZXN1bHRzLiBJbiBtb3N0IGNhc2VzIHJlc3BvbnNlIHdpbGwg YmUgc2VudCB0byB2aWEgYWRkcmVzcyBhbmQgcG9ydCBmcm9tIHRoZSBvcmlnaW5hbCB0cmFuc2Fj dGlvbiwgd2hpY2ggYXJlIGVwaGVtZXJhbC4gUGx1cyB0aGUgUkZDDQogc2F5cyB0aGF0IG1lc3Nh Z2Ugc2VudCBvdmVyIFRDUCBzaG91bGQgYmUgcmUtdHJhbnNtaXR0ZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWlpLSZuYnNwOyBGb3IgU0lQIFNl c3Npb24gVGltZXJzOiBUaGV5IHVzdWFsbHkgYXJlIHNldCBvbiBhIHZhbHVlIG11Y2ggaGlnaGVy IHRoYW4gdHJhbnNhY3Rpb24gdGltZW91dA0KIHZhbHVlcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXQgZG9lcyBub3QgbWF0dGVyIHdoYXQgU0lQIFNlc3Npb24gdGltZXIgdmFsdWUgaXMu IElmIFNJUCBTZXNzaW9uIHRpbWVyIHJlZnJlc2ggdHJhbnNhY3Rpb24gZmFpbHMsIHRoZSB3aG9s ZSBjYWxsIG5vcm1hbGx5IGZhaWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPk92ZXJhbGwsIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhIHNlcmlv dXMgU0lQIHByb3RvY29sIGxldmVsIGlzc3VlIGhlcmUsIHdoaWNoIGlzIGNhdXNpbmcgcGFpbiBp biBwcmFjdGljZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFjdHVhbGx5LCBhcyBmYXIgYXMgSSBrbm93LCB0 aGVyZSBhcmUgYXQgbGVhc3QgdHdvIFNJUCBwcm90b2NvbCBsZXZlbCBpc3N1ZXMgaGVyZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gSGFu ZGxpbmcgb2YgY2xpZW50IElQIGNoYW5nZSBpbiB0aGUgbWlkZGxlIG9mIHRyYW5zYWN0aW9uIGlz IG5vdCBzcGVjaWZpZWQgYW55d2hlcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBIYW5kbGluZyBvZiBUQ1AgY29ubmVjdGlvbiB0 ZWFyIGRvd24gaW4gdGhlIG1pZGRsZSBvZiB0cmFuc2FjdGlvbiBpcyBub3Qgc3BlY2lmaWVkIGFu eXdoZXJlLiBIYW5kbGluZyBvZiBTSVAgcmVzcG9uc2VzIHdoZW4gY2xpZW50IFRDUCBjb25uZWN0 aW9uIHdhcyB0b3JuIGRvd24gaW4gUkZDIDM2MjEgKHNlbmRpbmcgdG8gcmVjZWl2ZWQvcG9ydCBm cm9tIFZJQSBvdmVyIFRDUCkgZG9lcyBub3Qgd29yayB1bmxlc3MNCiBjbGllbnQgaXMgb24gcHVi bGljIElQLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN2PR03MB2350E8AAA808E61E8F3ADB8FB2BD0SN2PR03MB2350namp_-- From nobody Sun Nov 13 21:38:17 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBFD129543; Sun, 13 Nov 2016 21:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFEjQnJX9LP4; Sun, 13 Nov 2016 21:38:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC99127077; Sun, 13 Nov 2016 21:38:11 -0800 (PST) Received: from [31.133.137.110] (dhcp-896e.meeting.ietf.org [31.133.137.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAE5c8Lw025714 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 13 Nov 2016 23:38:09 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-896e.meeting.ietf.org [31.133.137.110] claimed to be [31.133.137.110] From: "Ben Campbell" To: SIPCORE Date: Mon, 14 Nov 2016 14:38:07 +0900 Message-ID: <85FA1C39-E71D-4225-AC56-6BD6B6465206@nostrum.com> In-Reply-To: <2581BBD3-557C-4BD2-B6A7-CC472FB06038@nostrum.com> References: <2581BBD3-557C-4BD2-B6A7-CC472FB06038@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_500C35E0-72AC-40F0-BB2C-4C325947C2D5_=" Embedded-HTML: [{"HTML":[782, 9452], "plain":[232, 3889], "uuid":"07E4E0D5-73EC-47BF-84B4-3EABD719FFF2"}] X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "art-ads@ietf.org" , "dispatch@ietf.org" Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 05:38:13 -0000 --=_MailMate_500C35E0-72AC-40F0-BB2C-4C325947C2D5_= Content-Type: text/plain; format=flowed Hi, The proposed charter (at the link below) will be reviewed by the IESG at the Dec 1 Telechat. If people have further comments, please make them as soon as possible. Thanks! Ben. On 8 Nov 2016, at 8:05, Ben Campbell wrote: > The proposed new SIPCORE charter text is now available at > https://datatracker.ietf.org/doc/charter-ietf-sipcore/ . It's > identical to the text from Adam's email, other than some potential > formatting differences. > > Thanks! > > Ben. > > On 4 Nov 2016, at 16:28, Adam Roach wrote: > >> [as SIPCORE chair] >> >> Back when we transitioned from the SIPPING/SIP working group >> structure to SIPCORE, we put relatively tight limits on the SIPCORE >> charter. This was a recognition of the fact that the volume of >> SIP-related work at the time was too large for any one working group >> to reasonably handle. Instead, the intention was that the DISPATCH >> model of creating small, short-lived working groups for specific >> topics would be a better way to manage the relatively heavy workload. >> >> Fast forward seven years to today. SIP is a much more mature >> protocol, and the inflow of new work is significantly smaller than it >> was back then. At the same time, we have had several small, >> self-contained work items show up in DISPATCH that were deemed too >> small to create a new working group for, but precluded from being >> dispatched to SIPCORE by its charter. This has led to unnecessary >> delays as we determined the best disposition for these items. >> >> We, the SIPCORE chairs and area director, seek to fix that. We would >> like to amend the SIPCORE charter to allow it to take on small, >> self-contained protocol extensions in addition to changes to the core >> SIP protocol. This is a relatively minor update to the existing >> charter, which expands the scope as described above, and adds back in >> two of the architectural principles from the SIP charter which are >> applicable only to protocol extensions. >> >> Please provide feedback on the proposed charter by sending email to >> the SIPCORE mailing list. We will also discuss this briefly during >> the DISPATCH session in Seoul. >> >> The proposed charter text follows. >> >>> The Session Initiation Protocol Core (SIPCore) working group is >>> chartered to maintain and continue the development of the SIP >>> protocol, >>> currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, >>> and >>> 6665. >>> >>> The SIPCore working group will concentrate on specifications that >>> update >>> or replace the core SIP specifications named above as well as >>> specifications pertaining to small, self-contained SIP protocol >>> extensions. The process and requirements for new SIP extensions are >>> documented in RFC5727, "Change Process for the Session Initiation >>> Protocol". >>> >>> Throughout its work, the group will strive to maintain the basic >>> model >>> and architecture defined by SIP. In particular: >>> >>> 1. Services and features are provided end-to-end whenever possible. >>> >>> 2. Reuse of existing Internet protocols and architectures and >>> integrating with other Internet applications is crucial. >>> >>> 3. Standards-track extensions and new features must be generally >>> applicable, and not applicable only to a specific set of session >>> types. >>> >>> 4. Simpler solutions that solve a given problem should be favored >>> over more complex solutions. >>> >>> The primary source of change requirements to the core SIP >>> specifications >>> (enumerated above) will be a) interoperability problems that stem >>> from >>> ambiguous, or under-defined specification, and b) requirements from >>> other working groups in the ART Area. The primary source of new >>> protocol >>> extensions is the DISPATCH working group, which will generally make >>> the >>> determination regarding whether new SIP-related work warrants a new >>> working group or belongs in an existing one. >> >> For ease of reference, the existing SIPCORE charter is at >> https://datatracker.ietf.org/doc/charter-ietf-sipcore/ >> >> Thanks! >> >> /a > >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=_MailMate_500C35E0-72AC-40F0-BB2C-4C325947C2D5_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
The proposed charter (at the link below) will be = reviewed by the IESG at the Dec 1 Telechat. If people have further commen= ts, please make them as soon as possible.
Thanks!
Ben.
On 8 Nov 2016, at 8:05, Ben Campbell wrote:
The proposed new SIPCORE charter text is now available= at https://datatracker.ietf.org/doc/charter-ietf-sipco= re/ . It's identical to the text from Adam's email, other than some p= otential formatting differences.
Thanks!
Ben.
On 4 Nov 2016, at 16:28, Adam Roach wrote:

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.


The= Session Initiation Protocol Core (SIPCore) working group is
cha= rtered to maintain and continue the development of the SIP protocol,
cur= rently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
666= 5.

The= SIPCore working group will concentrate on specifications that update
or replace the core SIP specifications named above as well as
spe= cifications pertaining to small, self-contained SIP protocol
=
ext= ensions.=C2=A0 The process and requirements for new SIP extensions are
doc= umented in RFC5727, "Change Process for the Session Initiation=
Pro= tocol".

Thr= oughout its work, the group will strive to maintain the basic model
and= architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and
=C2= =A0=C2=A0 integrating with other Internet applications is crucial.

3. Standards-track extensions and new features must be generally
=C2= =A0=C2=A0 applicable, and not applicable only to a specific set of session
=C2= =A0=C2=A0 types.

4. Simpler solutions that solve a given problem should be favored
=C2=A0= =C2=A0=C2=A0 over more complex solutions.

The= primary source of change requirements to the core SIP specifications
(en= umerated above) will be a) interoperability problems that stem from
amb= iguous, or under-defined specification, and b) requirements from
oth= er working groups in the ART Area. The primary source of new protocol
ext= ensions is the DISPATCH working group, which will generally make the<= /span>
det= ermination regarding whether new SIP-related work warrants a new<= /div>
wor= king group or belongs in an existing one.


For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charte= r-ietf-sipcore/

Thanks!

/a

___________________________= ____________________
dispatch mailing list
dispatch@ietf.org
___________________________= ____________________
sipcore mailing list
sipcore@ietf.org
--=_MailMate_500C35E0-72AC-40F0-BB2C-4C325947C2D5_=-- From nobody Tue Nov 15 18:56:48 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D311295A6 for ; Tue, 15 Nov 2016 18:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YCZKFK-bubg for ; Tue, 15 Nov 2016 18:56:45 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57F8129529 for ; Tue, 15 Nov 2016 18:56:44 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-01v.sys.comcast.net with SMTP id 6qOfcSMJwTaLw6qOxckfsS; Wed, 16 Nov 2016 02:56:43 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-04v.sys.comcast.net with SMTP id 6qOwczro1OKK96qOwcGIC2; Wed, 16 Nov 2016 02:56:43 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uAG2ug0E018972; Tue, 15 Nov 2016 21:56:42 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uAG2ufoi018968; Tue, 15 Nov 2016 21:56:41 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: roman@telurix.com, oej@edvina.net, sipcore@ietf.org In-Reply-To: <87fumsz8az.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 15 Nov 2016 21:56:41 -0500 Message-ID: <87d1hwyvx2.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfNZK2761W8NFWEu1UeyuY566Mi3YeSVtJRYiJmwYiAG62OGnp1fXwAFw1EehYIL6DiUUtcSXLWlhOOLlzFYd6nFUWrxI7+sXCump0hLxHlO4JL4MvKWV 931yFbLCaVoSFXDEN7H5WVPT5f6/ZS+SUbDSnUa7enthJ9YQbIMPeTuxVMAKGYT5HQDMc7EvLWmTTVAFkBY0P7UCVjAPnj/umveeEuEf3GvxLkg3BqFIBKLq Archived-At: Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:56:47 -0000 worley@ariadne.com (Dale R. Worley) writes: > Part of the trouble is that you can send to a single destination address > through more than one interface. I wonder if the address selection > system provides for a way for an application to say "send all global > traffic through interface X"? Looking at RFC 6724, it looks like the "policy table" (section 2.1) can be used to instruct the implementation to send SIP traffic destined for certain prefixes using certain source addresses (which map to interfaces). And it looks like the glibc version of getaddrinfo() uses a file /etc/gai.conf to provide policy table services. Dale From nobody Tue Nov 15 19:22:54 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924F112952F for ; Tue, 15 Nov 2016 19:22:51 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HbeeXzl5MEU for ; Tue, 15 Nov 2016 19:22:50 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DCE12957F for ; Tue, 15 Nov 2016 19:17:26 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id c47so89142271qtc.2 for ; Tue, 15 Nov 2016 19:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ByhjrIidb57+bAagzyAtjJE5FEsTvZvYEoO9H/rnJUU=; b=pWcX9n+GqStEj9y1M2YgIdqFbXjkE3wKunjvgD65bpWQ2sRvgoudLTxKuUxXIyASTr ulweW9P4AA1Uhl3uJ+O9Lv6kUzOlDGE+axwcR0+8Tkghq5ZL1gG1u0G7MduUbsxraMuJ mLhCXkPvY4ske+kwgih+issJsDd6l4BWl9nc/EeKiA/X9VjR277QHubuhZrWW6h7gdvA tgcaKwahkktGe+poEzII7irZM4gDS2+YfZJF8UVX9B9YKsib/TYy/ZQ/DQloBieoMbSE NFqboXKy+vLaD2+INt5v9Xlg/Aqj524FuYmjS0/4CtZhFl748EMp7QXrpk0DK+XJlnVf ea1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ByhjrIidb57+bAagzyAtjJE5FEsTvZvYEoO9H/rnJUU=; b=NeGElTbYmyZV0bpxrRGQo6fSFZ7P33hpsY1+O8SdFVFd0QmUAReT8r2CqRr1/+zTDT bVv3iG5zKJw/3MXpWYJj747xo87ZgTHo02X5nSnKQlte1AV+bXLBhFscUK4ldKN0hwwm NQYlkZCR3DwMGy8Zdb0lAp/4602zjvUR8Rcc5PRhsnqKMhq+YkVOeznUQ/OsB7un72nv S/FHKDc+0hVjUdYjVcEtNtNhrzpa5DiynuixYAIEqvV/koFdIpPTwrCCdNtto+PmNSwl OeMma/8uVaTIx+snihyIPmyAzDRbbmB/475eIQlwVaohS6DtUF1x4PGSVEh6KeYVuG4R fQVg== X-Gm-Message-State: ABUngvc+zbPT9cYFck89Hpz/l5q1Z6E20+4KwawzvGJ5hJa56h2geM4/BfBhDPbFrvXC0g== X-Received: by 10.237.60.170 with SMTP id d39mr506566qtf.132.1479266245166; Tue, 15 Nov 2016 19:17:25 -0800 (PST) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com. [209.85.220.170]) by smtp.gmail.com with ESMTPSA id f36sm16609726qkf.43.2016.11.15.19.17.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 19:17:24 -0800 (PST) Received: by mail-qk0-f170.google.com with SMTP id x190so160004917qkb.0 for ; Tue, 15 Nov 2016 19:17:24 -0800 (PST) X-Received: by 10.55.79.17 with SMTP id d17mr1042653qkb.110.1479266244464; Tue, 15 Nov 2016 19:17:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.135.243 with HTTP; Tue, 15 Nov 2016 19:17:23 -0800 (PST) In-Reply-To: <87d1hwyvx2.fsf@hobgoblin.ariadne.com> References: <87fumsz8az.fsf@hobgoblin.ariadne.com> <87d1hwyvx2.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Tue, 15 Nov 2016 22:17:23 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a114a89cc07a389054162835c Archived-At: Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 03:22:52 -0000 --001a114a89cc07a389054162835c Content-Type: text/plain; charset=UTF-8 Typically doing a UDP connect with unbound local socket and then looking at the socket address works quite well for determining local policy. Unfortunately local policy can lie. For instance end point can be behind the VPN that sets the default route to something (office network) that blocks SIP. There is an option to be aggressive and send connectivity checks from all available interfaces or, alternatively, implementation can follow the local policy and fail to connect. The implementation needs to decide what is more important -- following the policy or establishing the connection. Regards, _____________ Roman Shpount On Tue, Nov 15, 2016 at 9:56 PM, Dale R. Worley wrote: > worley@ariadne.com (Dale R. Worley) writes: > > Part of the trouble is that you can send to a single destination address > > through more than one interface. I wonder if the address selection > > system provides for a way for an application to say "send all global > > traffic through interface X"? > > Looking at RFC 6724, it looks like the "policy table" (section 2.1) can > be used to instruct the implementation to send SIP traffic destined for > certain prefixes using certain source addresses (which map to > interfaces). And it looks like the glibc version of getaddrinfo() uses > a file /etc/gai.conf to provide policy table services. > > Dale > --001a114a89cc07a389054162835c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Typically doing a UDP connect with unbound local socket an= d then looking at the socket address works quite well for determining local= policy. Unfortunately local policy can lie. For instance end point can be = behind the VPN that sets the default route to something (office network) th= at blocks SIP. There is an option to be aggressive and send connectivity ch= ecks from all available interfaces or, alternatively, implementation can fo= llow the local policy and fail to connect. The implementation needs to deci= de what is more important -- following the policy or establishing the conne= ction.

Regards,
_____________
R= oman Shpount

On Tue, Nov 15, 2016 at 9:56 PM, Dale R. Wor= ley <worley@ariadne.com> wrote:
worley@ariadne.com (Dale R= . Worley) writes:
> Part of the trouble is that you can send to a single destination addre= ss
> through more than one interface.=C2=A0 I wonder if the address selecti= on
> system provides for a way for an application to say "send all glo= bal
> traffic through interface X"?

Looking at RFC 6724, it looks like the "policy table" (section 2.= 1) can
be used to instruct the implementation to send SIP traffic destined for
certain prefixes using certain source addresses (which map to
interfaces).=C2=A0 And it looks like the glibc version of getaddrinfo() use= s
a file /etc/gai.conf to provide policy table services.

Dale

--001a114a89cc07a389054162835c-- From nobody Tue Nov 15 19:46:16 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A44129566 for ; Tue, 15 Nov 2016 19:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.342 X-Spam-Level: X-Spam-Status: No, score=-0.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UELPvlUvvCNf for ; Tue, 15 Nov 2016 19:46:14 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7413D1294F7 for ; Tue, 15 Nov 2016 19:46:14 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-11v.sys.comcast.net with SMTP id 6r9nc1u17lSxs6rArc5gA9; Wed, 16 Nov 2016 03:46:13 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-20v.sys.comcast.net with SMTP id 6rApcn1x4cuHl6rApct0zq; Wed, 16 Nov 2016 03:46:13 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uAG3kAOG024436; Tue, 15 Nov 2016 22:46:10 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uAFMT8Qf014100; Tue, 15 Nov 2016 17:29:08 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 15 Nov 2016 17:29:08 -0500 Message-ID: <87fumsz8az.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLcP/zkbC9lL07ThwwrCldNIzhJzXjW9SzDijl3nwvmg6f5Ey/9f1WUz/PkCnotamSpN+JAm31QVNpnRGKIZA3zhQJJSd/IjAiu6zmNT+wloBNRsWjWw 1WxAJVrTTSmvspRWUy/urZv5F5gFKUAwYRneetMAXU6A5l7Jj+vAe2GgX1ehJ6PQJfPz5ZyQaqzLGxZZgXRO6gZrVU8NpbxY+dboNqNetKnrG068pOIvD9dV Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 03:46:15 -0000 Roman Shpount writes: > One issue we saw was clients using VPN, with VPN taking them to a business > network which blocks SIP. > > This is why we added addresses enumeration and STUN checks similar to ICE > to verify which address actually has internet access. Interesting... that's not fixable as an ordinary source address selection problem. It's really a sort of Happy Eyeballs problem, where one interface has global SIP access and one doesn't but the client has no way to determine the right interface without trial because both interfaces have outgoing routers. We're working on a "Happy Eyeballs for SIP" draft, but the current version explicitly doesn't address this sort of problem: A dual-stack host normally has one physical interface, and all network access is done via IPv4 and IPv6 addresses assigned to that interface. However, a dual-stack host might have additional physical interfaces or additional logical interfaces (e.g., because of a VPN). Additional Happy EarBalls considerations for optimal operation with additional physical or logical interfaces is for further study and is outside the scope of this document. Part of the trouble is that you can send to a single destination address through more than one interface. I wonder if the address selection system provides for a way for an application to say "send all global traffic through interface X"? Perhaps we should add some guidance in this area, either in this cycle of work or in a future one. Dale From nobody Wed Nov 16 08:00:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE35C129686 for ; Wed, 16 Nov 2016 08:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeEOcYqCxt47 for ; Wed, 16 Nov 2016 08:00:06 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B205129550 for ; Wed, 16 Nov 2016 08:00:02 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-09v.sys.comcast.net with SMTP id 72cXcHQT11XXB72czc2War; Wed, 16 Nov 2016 16:00:01 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-11v.sys.comcast.net with SMTP id 72cwcP8ZHhUx872cxcFgnj; Wed, 16 Nov 2016 16:00:01 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uAGFxwl9014965; Wed, 16 Nov 2016 10:59:58 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uAGFxubN014960; Wed, 16 Nov 2016 10:59:56 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 16 Nov 2016 10:59:56 -0500 Message-ID: <87wpg3xvnn.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfFi8bqRyqqZX58daf8fuZYHX/DL3fcTXOcV3xk5y+c1m7F/KbJ47DN/am+K03qaEvBKqbwzV+/qc5RhAUP+s5qg3Hbd867c1oMKrlTyaPgw3F8e4Posh D59PH3jMs0Bkhd/PUXUmJLerpQqnyHh3QmfN3kuB5RnRv2707ASb/hD8lEbHFHv8IUvVX9IAa9KFHK5f1HBuHAmKvXsFCkdUVzLmO68x5IJ0eaH/GcxyAG5Q Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Source address selection in SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 16:00:08 -0000 Roman Shpount writes: > There is an option to be aggressive and send connectivity > checks from all available interfaces or, alternatively, implementation can > follow the local policy and fail to connect. The implementation needs to > decide what is more important -- following the policy or establishing the > connection. Within the conceptual framework of Happy Eyeballs, it's clear that the optimal strategy is to consider the alternative source interfaces (or perhaps source addresses) as connectivity alternatives in much the same way that destination addresses are. Then, use the local policy to determine the order in which to check the possibilties, but (in general) use the most policy-preferred alternative that actually works. The details to do this well are probably messy, though. As we expand the scope of the Happy Eyeballs draft, please remind us to address this issue at some point. Dale From nobody Thu Nov 17 00:27:13 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D5C1296A2; Thu, 17 Nov 2016 00:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM34JkTe-etA; Thu, 17 Nov 2016 00:27:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D212941A; Thu, 17 Nov 2016 00:27:06 -0800 (PST) Received: from dhcp-978a.meeting.ietf.org (dhcp-978a.meeting.ietf.org [31.133.151.138]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH8R2Z4048601 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Nov 2016 02:27:04 -0600 (CST) (envelope-from adam@nostrum.com) To: Brian Rosen , IETF STIR Mail List References: From: Adam Roach Message-ID: Date: Thu, 17 Nov 2016 17:27:01 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "dispatch@ietf.org" , 'SIPCORE' Subject: [sipcore] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 'SIPCORE' List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:27:08 -0000 [as SIPCORE chair] On 11/17/16 10:14, Brian Rosen wrote: > I’ve sent this to stir, even though it has not been decided where the 666 draft will land My understanding coming out of DISPATCH is that 666 is appropriate for SIPCORE, assuming the new charter is approved by the IESG. I expect the proposed charter changes to be uncontroversial. Based on the foregoing, we (the SIPCORE chairs) think it would be appropriate to hold general discussion of both of the draft-schulzrinne-dispatch-callinfo-spam and draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list. I've copied DISPATCH and SIPCORE on this message, and set followups to SIPCORE. /a From nobody Thu Nov 17 00:53:27 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337E81294F0; Thu, 17 Nov 2016 00:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DmcS5_GFdrG; Thu, 17 Nov 2016 00:53:21 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44FB1294C6; Thu, 17 Nov 2016 00:53:21 -0800 (PST) Received: from dhcp-9744.meeting.ietf.org (dhcp-9744.meeting.ietf.org [31.133.151.68]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH8rJ59050982 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Thu, 17 Nov 2016 02:53:21 -0600 (CST) (envelope-from rjsparks@nostrum.com) References: To: stir@ietf.org, "sipcore@ietf.org" From: Robert Sparks X-Forwarded-Message-Id: Message-ID: <927fb975-f4e2-2021-f719-972d4f62cbde@nostrum.com> Date: Thu, 17 Nov 2016 17:53:19 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BE1EC0B521888C9EC1D72E8B" Archived-At: Subject: [sipcore] Fwd: Re: [dispatch] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:53:23 -0000 This is a multi-part message in MIME format. --------------BE1EC0B521888C9EC1D72E8B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Reply-all betrayed me. Forwarding for completeness. Sorry for the extra noise. -------- Forwarded Message -------- Subject: Re: [dispatch] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage) Date: Thu, 17 Nov 2016 17:51:52 +0900 From: Robert Sparks To: dispatch@ietf.org [as a STIR co-chair] I agree with this. Later in the discussion, I expect we will recommend splitting the passport extension work out and running that through STIR, but that doesn't need to happen immediately. If we discover that there's frequent unnatural tension in needing to talk about stir things while figuring out the SIP mechanics in these drafts, we can revisit. RjS On 11/17/16 5:27 PM, Adam Roach wrote: > [as SIPCORE chair] > > On 11/17/16 10:14, Brian Rosen wrote: >> I’ve sent this to stir, even though it has not been decided where the >> 666 draft will land > > My understanding coming out of DISPATCH is that 666 is appropriate for > SIPCORE, assuming the new charter is approved by the IESG. I expect > the proposed charter changes to be uncontroversial. > > Based on the foregoing, we (the SIPCORE chairs) think it would be > appropriate to hold general discussion of both of the > draft-schulzrinne-dispatch-callinfo-spam and > draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list. > > I've copied DISPATCH and SIPCORE on this message, and set followups to > SIPCORE. > > /a > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------BE1EC0B521888C9EC1D72E8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Reply-all betrayed me. Forwarding for completeness.

Sorry for the extra noise.



-------- Forwarded Message --------
Subject: Re: [dispatch] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage)
Date: Thu, 17 Nov 2016 17:51:52 +0900
From: Robert Sparks <rjsparks@nostrum.com>
To: dispatch@ietf.org 


[as a STIR co-chair]

I agree with this.

Later in the discussion, I expect we will recommend splitting the 
passport extension work out and running that through STIR, but that 
doesn't need to happen immediately.

If we discover that there's frequent unnatural tension in needing to 
talk about stir things while figuring out the SIP mechanics in these 
drafts, we can revisit.

RjS


On 11/17/16 5:27 PM, Adam Roach wrote:
> [as SIPCORE chair]
>
> On 11/17/16 10:14, Brian Rosen wrote:
>> I’ve sent this to stir, even though it has not been decided where the 
>> 666 draft will land
>
> My understanding coming out of DISPATCH is that 666 is appropriate for 
> SIPCORE, assuming the new charter is approved by the IESG. I expect 
> the proposed charter changes to be uncontroversial.
>
> Based on the foregoing, we (the SIPCORE chairs) think it would be 
> appropriate to hold general discussion of both of the
> draft-schulzrinne-dispatch-callinfo-spam and 
> draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list.
>
> I've copied DISPATCH and SIPCORE on this message, and set followups to 
> SIPCORE.
>
> /a
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
--------------BE1EC0B521888C9EC1D72E8B-- From jan.1.petersen@nokia.com Mon Nov 21 10:38:37 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C23A129B1A for ; Mon, 21 Nov 2016 10:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJqZFe8vW1iv for ; Mon, 21 Nov 2016 10:38:35 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0095.outbound.protection.outlook.com [104.47.1.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913CC12967E for ; Mon, 21 Nov 2016 10:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5Y64WkvFZ++Qq3dIDGh4WFJEkp4zO/4CsmfKk+cZWU0=; b=pd28XnZ07dMUoS4hxjJkmWpFPVWbKxeu1PKhG2cwCyotFVkj6xx8a53T7qekXRF4Azn2kdvmH3DpvKPVvPxerm1DlsOg0d4kNRjp1n1Pac+XqGZkZ0XkJv8vEy4LzJDS31wnor4YDwvCYhRD8DntY4snmz1JUyGSJ4vFhEr80Zg= Received: from HE1PR07MB1722.eurprd07.prod.outlook.com (10.166.124.152) by HE1PR07MB1721.eurprd07.prod.outlook.com (10.166.124.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Mon, 21 Nov 2016 18:38:31 +0000 Received: from HE1PR07MB1722.eurprd07.prod.outlook.com ([10.166.124.152]) by HE1PR07MB1722.eurprd07.prod.outlook.com ([10.166.124.152]) with mapi id 15.01.0747.009; Mon, 21 Nov 2016 18:38:31 +0000 From: "Petersen, Jan 1. (Nokia - DE/Munich)" To: "sipcore@ietf.org" Thread-Topic: Question regarding RFC 3262 Thread-Index: AdJEJkkWEQkZejHITqy6j2WFUUbpnw== Date: Mon, 21 Nov 2016 18:38:30 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jan.1.petersen@nokia.com; x-originating-ip: [131.228.2.20] x-ms-office365-filtering-correlation-id: dd25e342-24df-43ad-bdf3-08d4123d97a7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR07MB1721; x-microsoft-exchange-diagnostics: 1; HE1PR07MB1721; 7:IowWeTBBvmL34/7YqO06hEd034vcZ2eiJ2goGfqrJ/GpL9h4J96SeCqjQr///uTWvMhtJ5bcDqeNRnBQiBH7QDdLXDiAqI4cAViFiZzaE8IazIHp+EFi3llNrQN6ukSe6jT5K/b1U6OdYH+R0a7QRdW0PKZBW9fg34ZYcO1xSo3c9SkIDpfhAOWYmCSLZ7oujJOFknby7abYnO1in6xOK2niKPu+SXIcYwVlkskk2bbaacnYi/61Ma8hdPkhEEQMgtXppACeBK4tGu6pFjPfPu0dj1EI45Ml4L2pnMuhzhkeRdpFpvmwBvcyjsvgyAIYfcZdNNLOyf0fCy+y6iVVy66Qbt2ZmNJO3/Fp0fahlRqcxuKJDhtFt5VUlQc6/vx+rbcN/HzZlwXT5ocTaVtFfHOhdTLf8mDJVL9HE9D/pTxGmCaRI9tqlcV4IK19kFFUtgat7yK+ETUP8COCLV8jrg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324)(6041248)(6072148); SRVR:HE1PR07MB1721; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1721; x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(66654002)(189002)(51874003)(68736007)(106356001)(2351001)(81156014)(8676002)(9686002)(1730700003)(81166006)(450100001)(3280700002)(77096005)(8936002)(86362001)(122556002)(5640700001)(6116002)(3660700001)(102836003)(7736002)(305945005)(7846002)(87936001)(74316002)(3846002)(76576001)(7696004)(107886002)(551934003)(189998001)(6506003)(5660300001)(66066001)(2501003)(33656002)(7116003)(2906002)(101416001)(97736004)(6916009)(92566002)(105586002)(2900100001)(50986999)(54356999)(110136003)(38730400001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1721; H:HE1PR07MB1722.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB17223A9DBB88CE3942EBF3DF8DB50HE1PR07MB1722eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2016 18:38:31.1339 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1721 Archived-At: X-Mailman-Approved-At: Tue, 22 Nov 2016 07:57:21 -0800 Subject: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 18:40:26 -0000 --_000_HE1PR07MB17223A9DBB88CE3942EBF3DF8DB50HE1PR07MB1722eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello SIP Experts and RFC 3262 authors, I am wondering how the race condition between provisional and final respons= es to the INVITE request that may occur based on this rfc 3262 is to be sol= ved. I have checked Errata and subsequent rfcs (such as RFC 5407), but was not a= ble to find any solution to this specific race condition. The issue occurs if the UAS is responding with an (subsequent) provisional = response to the INVITE request, using 100rel, while the shortly afterwards = the UAS is actually sending the final response to the INVITE, before the PR= ACK to the provisional response has been received by the UAS: The UAS MAY send a final response to the initial request before having received PRACKs for all unacknowledged reliable provisional responses, unless the final response is 2xx and any of the unacknowledged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding responses. So as a result, the UAC may receive the provisional response to the INVITE,= immediately followed by the final response 2xx to the INVITE. However, the= UAC may still send the PRACK for the provisional response here, but the UA= S has already terminated the transaction when this "late" PRACK is received= . Consequently the UAS responds to this "late" PRACK with a 481 Call/Transa= ction Does Not Exist, which in turn causes the UAC to terminate the already= established and ongoing SIP session. Can you please clarify how SIP UAs (UAC and UAS and even SIP Proxies) shoul= d handle and solve such a race condition? Especially, is the PRACK transact= ion directly affecting the corresponding SIP dialog, such that a late negat= ive response to the PRACK received on UAC side (after the 2xx final respons= e to the INVITE has been received already before) is justifying to execute = the release of the already successfully established session by the UAC? What exactly is meant by "... but[the UAS] MUST be prepared to process PRAC= K requests for those outstanding responses"? Does "process" refers to respo= nd with a 2xx, or to provide any final response, i.e. even a negative respo= nse - compared to just dropping it without any response? Many thanks in advance! Jan Petersen, NOKIA email: jan.1.petersen@nokia.com --_000_HE1PR07MB17223A9DBB88CE3942EBF3DF8DB50HE1PR07MB1722eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello SIP Experts and RFC 3262 authors,
 
 
I am wondering how the race condition between provisional and final re= sponses to the INVITE request that may occur based on this rfc 3262 is to b= e solved.
 
I have checked Errata and subsequent rfcs (such as RFC 5407), but was = not able to find any solution to this specific race condition.
 
 
The issue occurs if the UAS is responding with an (subsequent) provisi= onal response to the INVITE request, using 100rel, while the shortly afterw= ards the UAS is actually sending the final response to the INVITE, before t= he PRACK to the provisional response has been received by the UAS:
 
The UAS MAY send a final = response to the initial request before
having received PRACKs fo= r all unacknowledged reliable provisional
responses, unless the fin= al response is 2xx and any of the
unacknowledged reliable p= rovisional responses contained a session
description.  In tha= t case, it MUST NOT send a final response until
those provisional respons= es are acknowledged.  If the UAS does send a
final response when relia= ble responses are still unacknowledged, it
SHOULD NOT continue to re= transmit the unacknowledged reliable
provisional responses, bu= t it MUST be prepared to process PRACK
requests for those outsta= nding responses.
 
 
So as a result, the UAC may receive the provisional response to the IN= VITE, immediately followed by the final response 2xx to the INVITE. However= , the UAC may still send the PRACK for the provisional response here, but t= he UAS has already terminated the transaction when this “late” PRACK is received. Consequently th= e UAS responds to this “late” PRACK with a 481 Call/Transaction= Does Not Exist, which in turn causes the UAC to terminate the already esta= blished and ongoing SIP session.
 
Can you please clarify how SIP UAs (UAC and UAS and even SIP Proxies) = should handle and solve such a race condition? Especially, is the PRACK tra= nsaction directly affecting the corresponding SIP dialog, such that a late = negative response to the PRACK received on UAC side (after the 2xx final response to the INVITE has been received a= lready before) is justifying to execute the release of the already successf= ully established session by the UAC?
 
What exactly is meant by “… = but[the UAS] MUST be prepared to process PRACK requests for those outstanding responses”? Does “process” refers to respond with a 2xx, or to provide any f= inal response, i.e. even a negative response – compared to just dropp= ing it without any response?
 
 
Many thanks in advance!
 
Jan Petersen, NOKIA
 
 
 
 --_000_HE1PR07MB17223A9DBB88CE3942EBF3DF8DB50HE1PR07MB1722eurp_-- From nobody Tue Nov 22 10:08:47 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F326129A9F for ; Tue, 22 Nov 2016 10:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJeyBE2-e_Z5 for ; Tue, 22 Nov 2016 10:08:39 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7285D129E33 for ; Tue, 22 Nov 2016 10:05:27 -0800 (PST) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAMI5QLx019087 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 22 Nov 2016 12:05:26 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: sipcore@ietf.org References: From: Robert Sparks Message-ID: <0e45e6a2-7988-5845-8c9d-448c206bf2d5@nostrum.com> Date: Tue, 22 Nov 2016 12:05:26 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0BB52BFF519D2FF1DACACFC3" Archived-At: Subject: Re: [sipcore] Question regarding RFC 3262 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 18:08:44 -0000 This is a multi-part message in MIME format. --------------0BB52BFF519D2FF1DACACFC3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 11/21/16 12:38 PM, Petersen, Jan 1. (Nokia - DE/Munich) wrote: > Hello SIP Experts and RFC 3262 authors, > I am wondering how the race condition between provisional and final > responses to the INVITE request that may occur based on this rfc 3262 > is to be solved. > I have checked Errata and subsequent rfcs (such as RFC 5407), but was > not able to find any solution to this specific race condition. > The issue occurs if the UAS is responding with an (subsequent) > provisional response to the INVITE request, using 100rel, while the > shortly afterwards the UAS is actually sending the final response to > the INVITE, before the PRACK to the provisional response has been > received by the UAS: > The UAS MAY send a final response to the initial request before > having received PRACKs for all unacknowledged reliable provisional > responses, unless the final response is 2xx and any of the > unacknowledged reliable provisional responses contained a session > description. In that case, it MUST NOT send a final response until > those provisional responses are acknowledged. If the UAS does send a > final response when reliable responses are still unacknowledged, it > SHOULD NOT continue to retransmit the unacknowledged reliable > provisional responses, but it MUST be prepared to process PRACK > requests for those outstanding responses. > So as a result, the UAC may receive the provisional response to the > INVITE, immediately followed by the final response 2xx to the INVITE. > However, the UAC may still send the PRACK for the provisional response > here, but the UAS has already terminated the transaction when this > late PRACK is received. Consequently the UAS responds to this late > PRACK with a 481 Call/Transaction Does Not Exist, which in turn causes > the UAC to terminate the already established and ongoing SIP session. > Can you please clarify how SIP UAs (UAC and UAS and even SIP Proxies) > should handle and solve such a race condition? Especially, is the > PRACK transaction directly affecting the corresponding SIP dialog, > such that a late negative response to the PRACK received on UAC side > (after the 2xx final response to the INVITE has been received already > before) is justifying to execute the release of the already > successfully established session by the UAC? > What exactly is meant by but[the UAS] MUST be prepared to process > PRACK requests for those outstanding responses? Does process refers > to respond with a 2xx, or to provide any final response, i.e. even a > negative response compared to just dropping it without any response? It means that it must keep enough state to not return a 481. (A UAS that 481s such a PRACK has not followed the requirement). The expectation is that the PRACK would get a 200. The "In that case" sentence defends against the real problems with the race condition you're looking at. The remaining situations where there wouldn't be a 200 to the PRACK are places where context requires another response (like a 500 or a failure due to use or attempted use of an extension). > Many thanks in advance! > Jan Petersen, NOKIA > email: _jan.1.petersen@nokia.com_ > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------0BB52BFF519D2FF1DACACFC3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 11/21/16 12:38 PM, Petersen, Jan 1. (Nokia - DE/Munich) wrote:
Hello SIP Experts and RFC 3262 authors,
I am wondering how the race condition between provisional and final responses to the INVITE request that may occur based on this rfc 3262 is to be solved.
I have checked Errata and subsequent rfcs (such as RFC 5407), but was not able to find any solution to this specific race condition.
The issue occurs if the UAS is responding with an (subsequent) provisional response to the INVITE request, using 100rel, while the shortly afterwards the UAS is actually sending the final response to the INVITE, before the PRACK to the provisional response has been received by the UAS:
The UAS MAY send a final response to the initial request before
having received PRACKs for all unacknowledged reliable provisional
responses, unless the final response is 2xx and any of the
unacknowledged reliable provisional responses contained a session
description. In that case, it MUST NOT send a final response until
those provisional responses are acknowledged. If the UAS does send a
final response when reliable responses are still unacknowledged, it
SHOULD NOT continue to retransmit the unacknowledged reliable
provisional responses, but it MUST be prepared to process PRACK
requests for those outstanding responses.
So as a result, the UAC may receive the provisional response to the INVITE, immediately followed by the final response 2xx to the INVITE. However, the UAC may still send the PRACK for the provisional response here, but the UAS has already terminated the transaction when this late PRACK is received. Consequently the UAS responds to this late PRACK with a 481 Call/Transaction Does Not Exist, which in turn causes the UAC to terminate the already established and ongoing SIP session.
Can you please clarify how SIP UAs (UAC and UAS and even SIP Proxies) should handle and solve such a race condition? Especially, is the PRACK transaction directly affecting the corresponding SIP dialog, such that a late negative response to the PRACK received on UAC side (after the 2xx final response to the INVITE has been received already before) is justifying to execute the release of the already successfully established session by the UAC?
What exactly is meant by but[the UAS] MUST be prepared to process PRACK requests for those outstanding responses? Does process refers to respond with a 2xx, or to provide any final response, i.e. even a negative response compared to just dropping it without any response?
It means that it must keep enough state to not return a 481. (A UAS that 481s such a PRACK has not followed the requirement). The expectation is that the PRACK would get a 200. The "In that case" sentence defends against the real problems with the race condition you're looking at. The remaining situations where there wouldn't be a 200 to the PRACK are places where context requires another response (like a 500 or a failure due to use or attempted use of an extension).
Many thanks in advance!
Jan Petersen, NOKIA
 

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--------------0BB52BFF519D2FF1DACACFC3-- From nobody Thu Nov 24 08:40:52 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5B01299F4 for ; Thu, 24 Nov 2016 08:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hY1-U3308sxp for ; Thu, 24 Nov 2016 08:40:49 -0800 (PST) Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B8C1299FB for ; Thu, 24 Nov 2016 08:40:48 -0800 (PST) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F3F9055CD for ; Thu, 24 Nov 2016 11:40:37 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9A3CF554D for ; Thu, 24 Nov 2016 11:40:36 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.255.250.181] ([UNAVAILABLE]. [207.164.22.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Thu, 24 Nov 2016 11:40:37 -0500 From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_0BD351FC-5810-4F23-A92F-CD27CBEF02EF" Message-Id: <38ECDE12-9B45-47F2-B032-571877770D7F@iii.ca> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 24 Nov 2016 06:25:28 -0800 References: To: SIPCORE In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sipcore] [dispatch] SIPCORE Rechartering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 16:40:51 -0000 --Apple-Mail=_0BD351FC-5810-4F23-A92F-CD27CBEF02EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This change seems like a good idea to me.=20 > On Nov 4, 2016, at 2:28 PM, Adam Roach wrote: >=20 > [as SIPCORE chair] >=20 > Back when we transitioned from the SIPPING/SIP working group structure = to SIPCORE, we put relatively tight limits on the SIPCORE charter. This = was a recognition of the fact that the volume of SIP-related work at the = time was too large for any one working group to reasonably handle. = Instead, the intention was that the DISPATCH model of creating small, = short-lived working groups for specific topics would be a better way to = manage the relatively heavy workload. >=20 > Fast forward seven years to today. SIP is a much more mature protocol, = and the inflow of new work is significantly smaller than it was back = then. At the same time, we have had several small, self-contained work = items show up in DISPATCH that were deemed too small to create a new = working group for, but precluded from being dispatched to SIPCORE by its = charter. This has led to unnecessary delays as we determined the best = disposition for these items. > We, the SIPCORE chairs and area director, seek to fix that. We would = like to amend the SIPCORE charter to allow it to take on small, = self-contained protocol extensions in addition to changes to the core = SIP protocol. This is a relatively minor update to the existing charter, = which expands the scope as described above, and adds back in two of the = architectural principles from the SIP charter which are applicable only = to protocol extensions. >=20 > Please provide feedback on the proposed charter by sending email to = the SIPCORE mailing list. We will also discuss this briefly during the = DISPATCH session in Seoul. >=20 > The proposed charter text follows. >=20 >=20 >=20 >> The Session Initiation Protocol Core (SIPCore) working group is >> chartered to maintain and continue the development of the SIP = protocol, >> currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, = and >> 6665. >>=20 >> The SIPCore working group will concentrate on specifications that = update >> or replace the core SIP specifications named above as well as >> specifications pertaining to small, self-contained SIP protocol >> extensions. The process and requirements for new SIP extensions are >> documented in RFC5727, "Change Process for the Session Initiation >> Protocol". >>=20 >> Throughout its work, the group will strive to maintain the basic = model >> and architecture defined by SIP. In particular: >>=20 >> 1. Services and features are provided end-to-end whenever possible. >>=20 >> 2. Reuse of existing Internet protocols and architectures and >> integrating with other Internet applications is crucial. >>=20 >> 3. Standards-track extensions and new features must be generally >> applicable, and not applicable only to a specific set of session >> types. >>=20 >> 4. Simpler solutions that solve a given problem should be favored >> over more complex solutions. >>=20 >> The primary source of change requirements to the core SIP = specifications >> (enumerated above) will be a) interoperability problems that stem = from >> ambiguous, or under-defined specification, and b) requirements from >> other working groups in the ART Area. The primary source of new = protocol >> extensions is the DISPATCH working group, which will generally make = the >> determination regarding whether new SIP-related work warrants a new >> working group or belongs in an existing one. >=20 >=20 > For ease of reference, the existing SIPCORE charter is = athttps://datatracker.ietf.org/doc/charter-ietf-sipcore/ = > Thanks! > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_0BD351FC-5810-4F23-A92F-CD27CBEF02EF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

This change seems like a good idea to me. 


On Nov 4, 2016, at 2:28 PM, Adam Roach <adam@nostrum.com> wrote:

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.



The Session Initiation Protocol Core (SIPCore) working group is
chartered to maintain and continue the development of the SIP protocol,
currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
6665.

The SIPCore working group will concentrate on specifications that update
or replace the core SIP specifications named above as well as
specifications pertaining to small, self-contained SIP protocol
extensions.  The process and requirements for new SIP extensions are
documented in RFC5727, "Change Process for the Session Initiation
Protocol".

Throughout its work, the group will strive to maintain the basic model
and architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and
   integrating with other Internet applications is crucial.

3. Standards-track extensions and new features must be generally
   applicable, and not applicable only to a specific set of session
   types.

4. Simpler solutions that solve a given problem should be favored
    over more complex solutions.

The primary source of change requirements to the core SIP specifications
(enumerated above) will be a) interoperability problems that stem from
ambiguous, or under-defined specification, and b) requirements from
other working groups in the ART Area. The primary source of new protocol
extensions is the DISPATCH working group, which will generally make the
determination regarding whether new SIP-related work warrants a new
working group or belongs in an existing one.


For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charter-ietf-sipcore/

Thanks!

/a

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--Apple-Mail=_0BD351FC-5810-4F23-A92F-CD27CBEF02EF-- From nobody Mon Nov 28 17:25:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE41D12A228 for ; Mon, 28 Nov 2016 17:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDL_Wv5B3BUG for ; Mon, 28 Nov 2016 17:25:12 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E33912A227 for ; Mon, 28 Nov 2016 17:25:12 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAT1PATg045082 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 28 Nov 2016 19:25:11 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" From: Adam Roach Message-ID: Date: Mon, 28 Nov 2016 19:25:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 01:25:14 -0000 [as chair] SIPCORE: The chairs would like to call for adoption of draft-schulzrinne-dispatch-status-unwanted as a SIPCORE draft, provisional on approval of the currently proposed SIPCORE charter revisions (which we believe have a high probability of approval). If you have any opinion on such adoption, please comment on the SIPCORE mailing list within the next two weeks. While we do not wish to rush discussion unnecessarily, we have been informally told by 3GPP that the registration of a SIP status code meaning "reject this call and any subsequent calls from the same caller" is both important and time-sensitive. To that end, we plan to run this call for adoption over the next two weeks (ending Monday, December 12). Assuming adoption and approval of the new charter, we will then run a three-week working group last call (ending shortly after the end of the year). Given the relatively simple mechanism and limited scope of the current document, we believe this is a reasonable timeframe. If you disagree, please speak up. Working group participants are strongly encouraged to review and comment on the document at this time. Thanks! /a From nobody Mon Nov 28 17:53:59 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F9012A23C for ; Mon, 28 Nov 2016 17:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbiXbNKpjZWH for ; Mon, 28 Nov 2016 17:53:55 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A747412A23A for ; Mon, 28 Nov 2016 17:53:55 -0800 (PST) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uAT1jP3L000673; Mon, 28 Nov 2016 20:53:54 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 270ykmt70u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2016 20:53:54 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAT1rrUH013604; Mon, 28 Nov 2016 20:53:53 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAT1rg2s013500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Nov 2016 20:53:45 -0500 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 29 Nov 2016 01:53:30 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 20:53:29 -0500 From: "DOLLY, MARTIN C" To: Adam Roach Thread-Topic: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSSd92AVGSlf+ZMU25j7USfLZWiaDvMwNm Date: Tue, 29 Nov 2016 01:53:28 +0000 Message-ID: <7C7531C3-212C-4344-8CE1-9A1F54A25F51@att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C7531C3212C43448CE19A1F54A25F51attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-28_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611290027 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 01:53:58 -0000 --_000_7C7531C3212C43448CE19A1F54A25F51attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Nov 28, 2016, at 8:25 PM, Adam Roach > wrote: [as chair] SIPCORE: The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the currently = proposed SIPCORE charter revisions (which we believe have a high probabilit= y of approval). If you have any opinion on such adoption, please comment on= the SIPCORE mailing list within the next two weeks. While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "reject= this call and any subsequent calls from the same caller" is both important= and time-sensitive. To that end, we plan to run this call for adoption ove= r the next two weeks (ending Monday, December 12). Assuming adoption and ap= proval of the new charter, we will then run a three-week working group last= call (ending shortly after the end of the year). Given the relatively simp= le mechanism and limited scope of the current document, we believe this is = a reasonable timeframe. If you disagree, please speak up. Working group participants are strongly encouraged to review and comment on= the document at this time. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7C7531C3212C43448CE19A1F54A25F51attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Nov 28, 2016, at 8:25 PM, Adam Roach <adam@nostrum.com> wrote:

[as chair]

SIPCORE:

The chairs would like to call for adoption of draft-schulzrinne-dispa= tch-status-unwanted as a SIPCORE draft, provisional on approval of the curr= ently proposed SIPCORE charter revisions (which we believe have a high prob= ability of approval). If you have any opinion on such adoption, please comment on the SIPCORE mailing list w= ithin the next two weeks.

While we do not wish to rush discussion unnecessarily, we have been i= nformally told by 3GPP that the registration of a SIP status code meaning &= quot;reject this call and any subsequent calls from the same caller" i= s both important and time-sensitive. To that end, we plan to run this call for adoption over the next two weeks (ending= Monday, December 12). Assuming adoption and approval of the new charter, w= e will then run a three-week working group last call (ending shortly after = the end of the year). Given the relatively simple mechanism and limited scope of the current document, we = believe this is a reasonable timeframe. If you disagree, please speak up.

Working group participants are strongly encouraged to review and comm= ent on the document at this time.

Thanks!

/a

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_7C7531C3212C43448CE19A1F54A25F51attcom_-- From nobody Mon Nov 28 19:13:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01AF129E82 for ; Mon, 28 Nov 2016 19:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RepfNbIb2iN for ; Mon, 28 Nov 2016 19:13:19 -0800 (PST) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id AD52F12956F for ; Mon, 28 Nov 2016 19:13:18 -0800 (PST) X-AuditID: 1207440f-46bff700000009ea-64-583cf24d0ea3 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 21.C5.02538.D42FC385; Mon, 28 Nov 2016 22:13:18 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uAT3DGr3004738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 28 Nov 2016 22:13:17 -0500 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <1f290ece-96d7-b9a5-c41c-bafc0454ab9d@alum.mit.edu> Date: Mon, 28 Nov 2016 22:13:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixO6iqOv3ySbCYPtxJouvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8GDu8wF27kr1p38wtrAOJuzi5GTQ0LAROLO9jksILaQwGVG idvXfboYuYDsd0wSG1r3MIMkhAVSJCYeXMMEYosIiEg8m/6PDaLBTmLP7G3sIDabgJbEnEP/ wQbxCthLnOh4wQpiswioSuzcNBXMFhVIk3jYuJIZokZQ4uTMJ2D1nED1V54vA5vDLGArcWfu bmYIW15i+9s5zBMY+WYhaZmFpGwWkrIFjMyrGOUSc0pzdXMTM3OKU5N1i5MT8/JSi3RN9HIz S/RSU0o3MUKCjH8HY9d6mUOMAhyMSjy8O6xsIoRYE8uKK3MPMUpyMCmJ8k53AwrxJeWnVGYk FmfEF5XmpBYfYpTgYFYS4ZX+CJTjTUmsrEotyodJSXOwKInzqi9R9xMSSE8sSc1OTS1ILYLJ ynBwKEnw/v4A1ChYlJqeWpGWmVOCkGbi4AQZzgM0XBVseHFBYm5xZjpE/hSjopQ4ryhIswBI IqM0D64XlgReMYoDvSLMyw7SzgNMIHDdr4AGMwENfvvaGmRwSSJCSqqBkfeQ274vMU7vX7fP 8JblmTN5vvT8d48ytlkzeRVlrL5iZPE2q0N0T/kq/m0Lzyw4FS2rkdPz9tyiFb+eGyfNuuW2 1Lduz8/ff9SLr7Hvbm3I2uxeEpAdd7V/8bnZ+/xTXJkm57y0C3KJ9OldUr5s8jT7+6vKbpsZ zVic+LnKZKNGp4rUuymGj5VYijMSDbWYi4oTAZ2lPfHdAgAA Archived-At: Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 03:13:21 -0000 I support adoption. Thanks, Paul On 11/28/16 8:25 PM, Adam Roach wrote: > [as chair] > > SIPCORE: > > The chairs would like to call for adoption of > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE draft, > provisional on approval of the currently proposed SIPCORE charter > revisions (which we believe have a high probability of approval). If you > have any opinion on such adoption, please comment on the SIPCORE mailing > list within the next two weeks. > > While we do not wish to rush discussion unnecessarily, we have been > informally told by 3GPP that the registration of a SIP status code > meaning "reject this call and any subsequent calls from the same caller" > is both important and time-sensitive. To that end, we plan to run this > call for adoption over the next two weeks (ending Monday, December 12). > Assuming adoption and approval of the new charter, we will then run a > three-week working group last call (ending shortly after the end of the > year). Given the relatively simple mechanism and limited scope of the > current document, we believe this is a reasonable timeframe. If you > disagree, please speak up. > > Working group participants are strongly encouraged to review and comment > on the document at this time. > > Thanks! > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Nov 28 19:42:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94308129440 for ; Mon, 28 Nov 2016 19:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gkD4bV-tV9N for ; Mon, 28 Nov 2016 19:42:13 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5711D129463 for ; Mon, 28 Nov 2016 19:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1817; q=dns/txt; s=iport; t=1480390931; x=1481600531; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=a/TZ7xjT/Cqa7xfiJX7LnAl57l7Q4eNlLG3rFmcgDDY=; b=L38aQN5AvytCl5aFIkNMjehUqefPmZb7CSpiCIP78lprt+FvAxzU6uQy eC4NyPz5zNlAJZPEEXg2QuH6gVR/MV3fFS0PluMvTOi4CCtKUV08B181I ECpwMaZFwY0YHF7YuyTdctKWRrS3jp3x0A4kODPxH8snF0PYR7MCEyDBE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCA+DxY/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAR9YgQMHjTyXH5R0ggcdC4UvRgICAoFyPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBAwEBAQEaHTQQCwIBCBgeECcLJQIEE4hlCA6vKotHAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBFwWGPoF9gl6EJYNVgjAFlGuFaQGRBYFyhHeJSY1xhAs?= =?us-ascii?q?BHjeBFCEOAQGDXIFFcoVQgTCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,714,1473120000"; d="scan'208";a="176844531" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2016 03:42:10 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAT3gAav030571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Nov 2016 03:42:10 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 28 Nov 2016 21:42:09 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Mon, 28 Nov 2016 21:42:09 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: SIPCORE Thread-Topic: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSSd93Yju1NQr8lUGVZ6DERy2kLKDvreMAgAAIEoA= Date: Tue, 29 Nov 2016 03:42:09 +0000 Message-ID: References: <1f290ece-96d7-b9a5-c41c-bafc0454ab9d@alum.mit.edu> In-Reply-To: <1f290ece-96d7-b9a5-c41c-bafc0454ab9d@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.211.215] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 03:42:14 -0000 I support adoption too. Cheers, Gonzalo > On Nov 28, 2016, at 10:13 PM, Paul Kyzivat wrote: >=20 > I support adoption. >=20 > Thanks, > Paul >=20 > On 11/28/16 8:25 PM, Adam Roach wrote: >> [as chair] >>=20 >> SIPCORE: >>=20 >> The chairs would like to call for adoption of >> draft-schulzrinne-dispatch-status-unwanted as a SIPCORE draft, >> provisional on approval of the currently proposed SIPCORE charter >> revisions (which we believe have a high probability of approval). If you >> have any opinion on such adoption, please comment on the SIPCORE mailing >> list within the next two weeks. >>=20 >> While we do not wish to rush discussion unnecessarily, we have been >> informally told by 3GPP that the registration of a SIP status code >> meaning "reject this call and any subsequent calls from the same caller" >> is both important and time-sensitive. To that end, we plan to run this >> call for adoption over the next two weeks (ending Monday, December 12). >> Assuming adoption and approval of the new charter, we will then run a >> three-week working group last call (ending shortly after the end of the >> year). Given the relatively simple mechanism and limited scope of the >> current document, we believe this is a reasonable timeframe. If you >> disagree, please speak up. >>=20 >> Working group participants are strongly encouraged to review and comment >> on the document at this time. >>=20 >> Thanks! >>=20 >> /a >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Nov 28 20:42:51 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F402E129494 for ; Mon, 28 Nov 2016 20:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKOD-t4yQ0Rr for ; Mon, 28 Nov 2016 20:42:47 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0077.outbound.protection.outlook.com [104.47.41.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917CC12945A for ; Mon, 28 Nov 2016 20:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lEKUrcYhlbzJHMuklU8T65vuMqYB5waLYsJ23mwjgFE=; b=AELapXY5zFOH+EGSdl0Sj1LH7Oflklu7xnlUX8j0tkb4iJzgfgDTU7kxO22+Ye5iRzRxlz1ogOj04xVcmzf3znQ/SGKS8r5FdXiuR91D475cLHa3ai646jnGfE74GjaHYsx6j1TSOCteWbenUdP4kMvzVIHQDt/P9qKLaovkf8g= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Tue, 29 Nov 2016 04:42:45 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0747.015; Tue, 29 Nov 2016 04:42:45 +0000 From: "Asveren, Tolga" To: SIPCORE Thread-Topic: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSSd98Gce34iPlEE+5eFvzODH4P6DvSU4AgAAIEoCAABDUkA== Date: Tue, 29 Nov 2016 04:42:45 +0000 Message-ID: References: <1f290ece-96d7-b9a5-c41c-bafc0454ab9d@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 3819281b-24c1-4c38-5565-08d4181229ef x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:WcX1wCRgR+WX/i6f7Co0X3mEgRCZ10GOUzGAHNEEhFrVnoz82h+u2qfaPOIB946oX4b1SlfvomeVZVFRsrYdwGowzFrnRzACm6JCYbMBPtQDTSufsuQ2PTyHNMJC/zJ1+R3iolaTKapUabDP5EMqPKBEnRPD6gEfbybmQgkV0iCQ4jLyr59IWihY8cwzYgA17K3+ClZOjSJM9RupcXDCS4G13aO0KY7GOFGTzbnsu2bx4tIIIEwLf4iVBWnOe0ZqJM5YdQOsSm1rS577sWLu9fFTWnkFR0PfuMg8LYyj6BfoZslFCDpdyJ2yLxt1Jdz4+KMr4SgikXUTIrQiLTWNJxXI/0sCj5DfKiA0CjDnFXSrYhE9MGwYUZPvra2WrN2BTllokMKUCSjG1fGpPTuDGpKriEJikBE/cWCHsGtP9lf1n2myD1s13ulQHHwy/yVRmG+mlScPN9pRX+PIq+39kA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045199)(6040361)(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6041248)(6046074)(20161123555025)(20161123560025)(20161123564025)(20161123562025); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 01415BB535 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(199003)(24454002)(189002)(13464003)(81166006)(8676002)(81156014)(8936002)(230783001)(450100001)(68736007)(86362001)(50986999)(97736004)(38730400001)(3846002)(189998001)(39400400001)(39380400001)(77096006)(39410400001)(101416001)(6506003)(39450400002)(66066001)(54356999)(76176999)(102836003)(6116002)(3280700002)(74316002)(9686002)(122556002)(229853002)(7696004)(5660300001)(92566002)(305945005)(33656002)(2906002)(106116001)(105586002)(106356001)(3660700001)(2900100001)(7846002)(110136003)(2950100002)(6916009)(99286002)(7736002)(76576001)(107886002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2016 04:42:45.6820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 04:42:50 -0000 Me too. Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo > Salgueiro (gsalguei) > Sent: Monday, November 28, 2016 10:42 PM > To: SIPCORE > Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne= - > dispatch-status-unwanted >=20 > I support adoption too. >=20 > Cheers, >=20 > Gonzalo >=20 > > On Nov 28, 2016, at 10:13 PM, Paul Kyzivat > wrote: > > > > I support adoption. > > > > Thanks, > > Paul > > > > On 11/28/16 8:25 PM, Adam Roach wrote: > >> [as chair] > >> > >> SIPCORE: > >> > >> The chairs would like to call for adoption of > >> draft-schulzrinne-dispatch-status-unwanted as a SIPCORE draft, > >> provisional on approval of the currently proposed SIPCORE charter > >> revisions (which we believe have a high probability of approval). If > >> you have any opinion on such adoption, please comment on the SIPCORE > >> mailing list within the next two weeks. > >> > >> While we do not wish to rush discussion unnecessarily, we have been > >> informally told by 3GPP that the registration of a SIP status code > >> meaning "reject this call and any subsequent calls from the same calle= r" > >> is both important and time-sensitive. To that end, we plan to run > >> this call for adoption over the next two weeks (ending Monday, > December 12). > >> Assuming adoption and approval of the new charter, we will then run a > >> three-week working group last call (ending shortly after the end of > >> the year). Given the relatively simple mechanism and limited scope of > >> the current document, we believe this is a reasonable timeframe. If > >> you disagree, please speak up. > >> > >> Working group participants are strongly encouraged to review and > >> comment on the document at this time. > >> > >> Thanks! > >> > >> /a > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Nov 28 21:32:39 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6583A129448 for ; Mon, 28 Nov 2016 21:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hffKye16QVZp for ; Mon, 28 Nov 2016 21:32:36 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B93D126CD8 for ; Mon, 28 Nov 2016 21:32:36 -0800 (PST) X-AuditID: c1b4fb2d-089fe70000001117-cb-583d12f14a9c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id DC.A0.04375.1F21D385; Tue, 29 Nov 2016 06:32:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Tue, 29 Nov 2016 06:32:32 +0100 From: Christer Holmberg To: Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSSd9y397CIqw4nk2NFZ4I78+BXaDvcCDw Date: Tue, 29 Nov 2016 05:32:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BEADF6A@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7t+4nIdsIg8bduhZ7/i5it/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXx6949xoLfPBXTJm9jaWC8wdXFyMkhIWAi sbB7GVsXIxeHkMA6Rokty58yQTiLGSU2XdnI2MXIwcEmYCHR/U8bpEFEwF7i7de1rCC2sECK xMWvp1gg4qkSa188ZoewjSROzDjNDGKzCKhKbD34E6yeV8BXYtn942wgtpCAncSe2dvA6jmB Zl55vgzMZhQQk/h+ag0TiM0sIC5x68l8JohDBSSW7DnPDGGLSrx8/I8VwlaSWHt4OwtEvY7E gt2f2CBsbYllC18zQ+wVlDg58wnLBEaRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ66UW ZSYXF+fn6eWllmxiBMbDwS2/dXcwrn7teIhRgINRiYe3wM0mQog1say4MvcQowQHs5IIrxcw moR4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpgTOufwB7o lur50Yr9v5DK/sCewIZJxWFh/Z1/ig3DLwmXblkozDKtZvVHmZ4sh6tvjAuE6j9+0lxUrv+B 4w/7zDgn9uV6B88enFD0KPKCpf1+u2hJX+GN0yOnbW2ys/dK/qAdr3yeaXL9CcN7Si5r5uWG s/THcav97pozOWjDYdM5D5p4+OyVWIozEg21mIuKEwHdGCShgwIAAA== Archived-At: Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 05:32:38 -0000 I support adoption. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: 29 November 2016 03:25 To: 'SIPCORE' Subject: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispa= tch-status-unwanted [as chair] SIPCORE: The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the currently = proposed SIPCORE charter revisions (which we believe have a high probabilit= y of approval). If you have any opinion on such adoption, please comment on= the SIPCORE mailing list within the next two weeks. While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "reject= this call and any subsequent calls from the same caller"=20 is both important and time-sensitive. To that end, we plan to run this call= for adoption over the next two weeks (ending Monday, December 12).=20 Assuming adoption and approval of the new charter, we will then run a three= -week working group last call (ending shortly after the end of the year). G= iven the relatively simple mechanism and limited scope of the current docum= ent, we believe this is a reasonable timeframe. If you disagree, please spe= ak up. Working group participants are strongly encouraged to review and comment on= the document at this time. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Nov 29 05:37:35 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3568712946E for ; Tue, 29 Nov 2016 05:37:34 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm_WC5XP9d35 for ; Tue, 29 Nov 2016 05:37:32 -0800 (PST) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id CA0A3129B7F for ; Tue, 29 Nov 2016 05:37:31 -0800 (PST) Received: (qmail 32132 invoked by uid 0); 29 Nov 2016 13:37:22 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 29 Nov 2016 13:37:22 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id DpYK1u0031MNPNq01pYNqv; Tue, 29 Nov 2016 06:32:22 -0700 X-Authority-Analysis: v=2.1 cv=K/+xQUmI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=Z80JlwQ0AAAA:8 a=36i028sKSvL8txcTJFcA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=lje8bhSvXF7fUmdd:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=obGFCI3_7AGB19sD6zJV:22 a=Zz-tw7mMPhxMdvFcggwQ:22 a=BKKCjISod1eDJeS0ORpz:22 a=zjWhRoSqWz9hl55Hdlzg:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To: From:Subject:Date; bh=FM/1OwGQeBi1Qs8IgA7x3dQnZO3UZY9LQkoLpNedS3Q=; b=SPPUX1B 627jSZty0EIa7XQ2WQay9XBa/4dRPMekUC8Bew+vsGZra4JbwmLW3OdY3AH38cHjz73w7m53wdq0R Z/Z2D+AxKCzCgTr/CrLj3xjIIdUHi6cnZ8mM55Pt4ERS; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:58476 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1cBiWA-0005mL-Nz for sipcore@ietf.org; Tue, 29 Nov 2016 06:32:18 -0700 User-Agent: Microsoft-MacOutlook/f.1c.1.161117 Date: Tue, 29 Nov 2016 08:32:16 -0500 From: Richard Shockey To: SIPCORE Message-ID: Thread-Topic: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted References: <7C7531C3-212C-4344-8CE1-9A1F54A25F51@att.com> In-Reply-To: <7C7531C3-212C-4344-8CE1-9A1F54A25F51@att.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3563253138_17940653" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1cBiWA-0005mL-Nz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:58476 X-Source-Auth: richard+shockey.us X-Email-Count: 3 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 13:37:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3563253138_17940653 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 +1=C2=A0=20 =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 =20 From: sipcore on behalf of "DOLLY, MARTIN C" Date: Monday, November 28, 2016 at 8:53 PM To: Adam Roach Cc: SIPCORE Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-d= ispatch-status-unwanted =20 I support Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com =20 On Nov 28, 2016, at 8:25 PM, Adam Roach wrote: [as chair] SIPCORE: The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the currently p= roposed SIPCORE charter revisions (which we believe have a high probability = of approval). If you have any opinion on such adoption, please comment on th= e SIPCORE mailing list within the next two weeks. While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "reject = this call and any subsequent calls from the same caller" is both important a= nd time-sensitive. To that end, we plan to run this call for adoption over t= he next two weeks (ending Monday, December 12). Assuming adoption and approv= al of the new charter, we will then run a three-week working group last call= (ending shortly after the end of the year). Given the relatively simple mec= hanism and limited scope of the current document, we believe this is a reaso= nable timeframe. If you disagree, please speak up. Working group participants are strongly encouraged to review and comment on= the document at this time. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcor= e@ietf.org https://www.ietf.org/mailman/listinfo/sipcore=20 --B_3563253138_17940653 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

+1=C2=A0

 <= /span>

— 

Richard Shockey

<= /div>

Shockey Consulting LLC=

Chairman of the Board SIP Forum

www.shockey.us

<= div>

www.sipforum.org<= /span>

richard<= at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

 

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in = 0in'>

Fro= m: sipcore <sipc= ore-bounces@ietf.org> on behalf of "DOLLY, MARTIN C" <md3135= @att.com>
Date: Monday, November 28, 2016 at 8:53 PM
To: = Adam Roach <adam@nostrum.com>
Cc: SIPCORE <sipcore@ie= tf.org>
Subject: Re: [sipcore] Call for (provisional) Adoption:= draft-schulzrinne-dispatch-status-unwanted

=

 

I support

Martin = C. Dolly

Lead Member of Technical Staff=

Core & Government/Regulatory Standards=

AT&T

= Cell: +1.609.903.3360

<= p class=3DMsoNormal>Email: md3135@att.= com

 


On Nov 28, 2016, at 8:2= 5 PM, Adam Roach <adam@nostrum.com&= gt; wrote:

[as chair]

SIPCORE:

The ch= airs would like to call for adoption of draft-schulzrinne-dispatch-status-un= wanted as a SIPCORE draft, provisional on approval of the currently proposed= SIPCORE charter revisions (which we believe have a high probability of appr= oval). If you have any opinion on such adoption, please comment on the SIPCO= RE mailing list within the next two weeks.

While we do not wish to ru= sh discussion unnecessarily, we have been informally told by 3GPP that the r= egistration of a SIP status code meaning "reject this call and any subs= equent calls from the same caller" is both important and time-sensitive= . To that end, we plan to run this call for adoption over the next two weeks= (ending Monday, December 12). Assuming adoption and approval of the new cha= rter, we will then run a three-week working group last call (ending shortly = after the end of the year). Given the relatively simple mechanism and limite= d scope of the current document, we believe this is a reasonable timeframe. = If you disagree, please speak up.

Working group participants are stro= ngly encouraged to review and comment on the document at this time.

T= hanks!

/a

_______________________________________________
s= ipcore mailing list
sipcore@ietf.org
https://www.iet= f.org/mailman/listinfo/sipcore

_______________________________________________ sipcore mailing l= ist sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore

--B_3563253138_17940653-- From nobody Tue Nov 29 06:17:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CCD129BDA for ; Tue, 29 Nov 2016 06:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7UCgN6NBwpS for ; Tue, 29 Nov 2016 06:17:16 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBBB129BD1 for ; Tue, 29 Nov 2016 06:17:16 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id f188so69803764pgc.3 for ; Tue, 29 Nov 2016 06:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Fql4M/SGNj0Mf2/W1KMZ5gzGLGa2p9+L1gx5QS2/ybc=; b=aJhBKIxp2J6A8L0KFezw/8IcS1oqcylP9NgB4nETmS5yCxWqQiBRsMz6aN+Tos7+fi DXe43GtyOighswtFxzkb6dhVEMC8243IkSIp232AXSIYdUpsX05a+QSQwjcCbpOml3SE 6Mj4DXakcH9gdzs8lCo0yiayLPU8ZEGsraqwiDWkR9cMWuKTFFsCAoefN32fRNGUzjjb cY1osMkiPUbrCCmXoQsVGpccHH3yZYe9YcyIQ0xCGMk5OBsDh6LHabH6zKnVMDry7/sx ws+eion4NZZMWBBJZw+3zEg1ZICO7QZ0MJRnFrnmhnpaqV/BjBoar6d1O9j2S4Ei0K0k WDgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Fql4M/SGNj0Mf2/W1KMZ5gzGLGa2p9+L1gx5QS2/ybc=; b=jwm2rhCu9IyqqrDtdDfjaZXDqsJeNt0xrVQYNGiXt6XRvRAyeLauyLwYeSywuY553O p2mlceU7ilAp3+chSCZTvnGlQo+onfl+HuXHV/85XowbscYKn4jW2SGOtfBPsXh+yPux gu6OApA/a1FKyGoRoEiGviz68Ps4qQ19LXMaCgGrt2LvyOiiZZibtaKIsC9mvnaVb6XQ DQZuJkHJN+lhiTwdeXpPcBFse+u+3lB5ApF3WMRp+ty6OfjYRU/e4qv3VFU08hPkhip0 XWJqevwkN5TvuWlnkoERDShoW+PuE7GOZ5PfeHjkAJwa35OyNTAT+ITlmiT9NxjfsXEL S3ew== X-Gm-Message-State: AKaTC03cKQKt1kW9ntnK6Ofi71UqETV15qQqdw3HjdswxvqiADp4RyAxF0vBpbDme1XmaSTZeHgWb+2JrQkmgxwzV2tsNAX6Lcj/HPJAJ6240rLUIMnjAlWyxplNj7sdJ2Rwe4+C884xb9es5aIFt0Kh1boivC8yLjWfAkFCNMq89mY= X-Received: by 10.84.162.204 with SMTP id o12mr62856127plg.17.1480429035625; Tue, 29 Nov 2016 06:17:15 -0800 (PST) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:d4f:b7f6:cb06:5f2e]) by smtp.gmail.com with ESMTPSA id a7sm95640019pfl.87.2016.11.29.06.17.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 06:17:15 -0800 (PST) To: Adam Roach , 'SIPCORE' References: From: Simon Perreault Message-ID: <201209ee-d301-5649-c353-fab8d12abb32@jive.com> Date: Tue, 29 Nov 2016 09:17:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 14:17:19 -0000 Support. -- Simon Perreault Director of Engineering, Platform | Jive Communications, Inc. https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com From nobody Tue Nov 29 06:56:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C11D12969E for ; Tue, 29 Nov 2016 06:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAxX99_aeHr8 for ; Tue, 29 Nov 2016 06:56:17 -0800 (PST) Received: from mailport8.csra.com (mailport8.csra.com [131.131.97.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAF2129BED for ; Tue, 29 Nov 2016 06:56:15 -0800 (PST) Received: from csrrdu1exm032.corp.csra.com (HELO mail.csra.com) ([10.8.2.32]) by mailport8.csra.com with ESMTP/TLS/AES256-SHA; 29 Nov 2016 09:54:02 -0500 Received: from CSRRDU1EXM025.corp.csra.com (10.8.2.25) by CSRRDU1EXM025.corp.csra.com (10.8.2.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 29 Nov 2016 09:56:13 -0500 Received: from CSRRDU1EXM025.corp.csra.com ([10.8.2.25]) by CSRRDU1EXM025.corp.csra.com ([10.8.2.25]) with mapi id 15.00.1210.000; Tue, 29 Nov 2016 09:56:13 -0500 From: "Gunn, Janet P" To: Adam Roach Thread-Topic: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSSd9yDmRS3ZFnk0KQ1kTSV62RkqDvhtQAgACGxiA= Date: Tue, 29 Nov 2016 14:56:12 +0000 Message-ID: References: <7C7531C3-212C-4344-8CE1-9A1F54A25F51@att.com> In-Reply-To: <7C7531C3-212C-4344-8CE1-9A1F54A25F51@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.8.2.8] Content-Type: multipart/alternative; boundary="_000_b4f1927e2d3d471187937ee328f11bbdCSRRDU1EXM025corpcsraco_" MIME-Version: 1.0 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 14:56:20 -0000 --_000_b4f1927e2d3d471187937ee328f11bbdCSRRDU1EXM025corpcsraco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Janet From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C Sent: Monday, November 28, 2016 8:53 PM To: Adam Roach Cc: SIPCORE Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-d= ispatch-status-unwanted I support Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Nov 28, 2016, at 8:25 PM, Adam Roach > wrote: [as chair] SIPCORE: The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the currently = proposed SIPCORE charter revisions (which we believe have a high probabilit= y of approval). If you have any opinion on such adoption, please comment on= the SIPCORE mailing list within the next two weeks. While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "reject= this call and any subsequent calls from the same caller" is both important= and time-sensitive. To that end, we plan to run this call for adoption ove= r the next two weeks (ending Monday, December 12). Assuming adoption and ap= proval of the new charter, we will then run a three-week working group last= call (ending shortly after the end of the year). Given the relatively simp= le mechanism and limited scope of the current document, we believe this is = a reasonable timeframe. If you disagree, please speak up. Working group participants are strongly encouraged to review and comment on= the document at this time. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore This electronic message transmission contains information from CSRA that ma= y be attorney-client privileged, proprietary or confidential. The informati= on in this message is intended only for use by the individual(s) to whom it= is addressed. If you believe you have received this message in error, plea= se contact me immediately and be aware that any use, disclosure, copying or= distribution of the contents of this message is strictly prohibited. NOTE:= Regardless of content, this email shall not operate to bind CSRA to any or= der or other contract unless pursuant to explicit written agreement or gove= rnment initiative expressly permitting the use of email for such purpose. --_000_b4f1927e2d3d471187937ee328f11bbdCSRRDU1EXM025corpcsraco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Janet

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Monday, November 28, 2016 8:53 PM
To: Adam Roach <adam@nostrum.com>
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulz= rinne-dispatch-status-unwanted

 

I support<= /p>

Martin C. Dolly

Lead Member of Technical Staff

Core & Government/Regulatory Standards

AT&T

Cell: += 1.609.903.3360

Email: md3= 135@att.com

 


On Nov 28, 2016, at 8:25 PM, Adam Roach <adam@nostrum.com> wrote:

[as chair]

SIPCORE:

The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the currently = proposed SIPCORE charter revisions (which we believe have a high probabilit= y of approval). If you have any opinion on such adoption, please comment on the SIPCORE mailing list withi= n the next two weeks.

While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "r= eject this call and any subsequent calls from the same caller" is both= important and time-sensitive. To that end, we plan to run this call for adoption over the next two weeks (ending Mond= ay, December 12). Assuming adoption and approval of the new charter, we wil= l then run a three-week working group last call (ending shortly after the e= nd of the year). Given the relatively simple mechanism and limited scope of the current document, we believe thi= s is a reasonable timeframe. If you disagree, please speak up.

Working group participants are strongly encouraged to review and comment on= the document at this time.

Thanks!

/a

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore


This electronic message transmission contains information from CSRA that= may be attorney-client privileged, proprietary or confidential. The inform= ation in this message is intended only for use by the individual(s) to whom= it is addressed. If you believe you have received this message in error, please contact me immediately and= be aware that any use, disclosure, copying or distribution of the contents= of this message is strictly prohibited. NOTE: Regardless of content, this = email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written ag= reement or government initiative expressly permitting the use of email for = such purpose.

--_000_b4f1927e2d3d471187937ee328f11bbdCSRRDU1EXM025corpcsraco_-- From nobody Tue Nov 29 13:29:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E15F129516 for ; Tue, 29 Nov 2016 13:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDkjDYZV4ZCy for ; Tue, 29 Nov 2016 13:29:32 -0800 (PST) Received: from mail-wj0-x235.google.com (mail-wj0-x235.google.com [IPv6:2a00:1450:400c:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161B512952B for ; Tue, 29 Nov 2016 13:29:31 -0800 (PST) Received: by mail-wj0-x235.google.com with SMTP id mp19so157326631wjc.1 for ; Tue, 29 Nov 2016 13:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pbdeXP7no1OwVwKDAjUzKT22Rk3hIg6FOLFyLUekcyw=; b=DUb8rFJKAokoY7Vmfd53QnXVWY+s4Oi9CY0zuxztdyoQKbrwCOqHtJp1HS7ZlnPNKc z7lzZtDlqQtJhbvRF8hY2Z5p7V9yzoTD1s8Afb6Y237PYL6HMCkSGrBz6zPqWkwynG5m OGHMxFIYy/Ht2stb3s4Oc8K78kVsKvmWFREDKwLgH6iEGCwQ0CMW+lHT9Uri8LAAV0MU 01yKgqsGrZz0yAay35gR23dLgfbsvdLmIhFzw0BTWa3NuFLPuTw4RuHNdsP63lBtTU1z y5U/GGHyENscAD1v9Pd+WhIAiad743HPy4ivFvA7kNzPEGJrfrziEsCDOmlbADkACgFc jmYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pbdeXP7no1OwVwKDAjUzKT22Rk3hIg6FOLFyLUekcyw=; b=HLt/4gyTrMeTaceA0btTqeoQHGSPlVPdC5lRa+wWmpNA2+trMFcChmgWJghdK0JyJ+ 3PW+SMN/Z0Nth9AnqV3TGLQiMUApZKCg0by0TYbKFlIgCXTpebXNiCJU6jpdqA5T3MhX 7ITeN0CaIbHKhwMmPp4PaELlGGK9rRdJ8XruZYgsqZyh0/4LA/1QqD4ToidVQz5w4UZp Gmro73u/xABE9VkJjzJj3DA/El+9KpTs48Kn5Laqtnsu6dxdVr/skVGO5yzG7dB2olQl zLlsFdim7dggI7dx4D53I1odFcD9ppo6DMek02OLWHGAfWX62R8tyajaUusYyICkwc2I oR0w== X-Gm-Message-State: AKaTC03xVNJNnEk9ZudXMKcAJSnCA7/3R+JBhwrTkgAzYcOBJloHFcSfY218D21j3Y+Uk7KnWb+sLeeDC6IW3Q== X-Received: by 10.194.24.102 with SMTP id t6mr21306889wjf.111.1480454970510; Tue, 29 Nov 2016 13:29:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.173.98 with HTTP; Tue, 29 Nov 2016 13:29:29 -0800 (PST) In-Reply-To: References: From: Ranjit Avasarala Date: Tue, 29 Nov 2016 15:29:29 -0600 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b5d25509f976a05427748c1 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 21:29:33 -0000 --047d7b5d25509f976a05427748c1 Content-Type: text/plain; charset=UTF-8 I support Regards Ranjit On Mon, Nov 28, 2016 at 7:25 PM, Adam Roach wrote: > [as chair] > > SIPCORE: > > The chairs would like to call for adoption of > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE draft, > provisional on approval of the currently proposed SIPCORE charter revisions > (which we believe have a high probability of approval). If you have any > opinion on such adoption, please comment on the SIPCORE mailing list within > the next two weeks. > > While we do not wish to rush discussion unnecessarily, we have been > informally told by 3GPP that the registration of a SIP status code meaning > "reject this call and any subsequent calls from the same caller" is both > important and time-sensitive. To that end, we plan to run this call for > adoption over the next two weeks (ending Monday, December 12). Assuming > adoption and approval of the new charter, we will then run a three-week > working group last call (ending shortly after the end of the year). Given > the relatively simple mechanism and limited scope of the current document, > we believe this is a reasonable timeframe. If you disagree, please speak up. > > Working group participants are strongly encouraged to review and comment > on the document at this time. > > Thanks! > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --047d7b5d25509f976a05427748c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support

Regards
Ranjit

On Mon, N= ov 28, 2016 at 7:25 PM, Adam Roach <adam@nostrum.com> wrote:<= br>
[as chair]

SIPCORE:

The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the curre= ntly proposed SIPCORE charter revisions (which we believe have a high proba= bility of approval). If you have any opinion on such adoption, please comme= nt on the SIPCORE mailing list within the next two weeks.

While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "r= eject this call and any subsequent calls from the same caller" is both= important and time-sensitive. To that end, we plan to run this call for ad= option over the next two weeks (ending Monday, December 12). Assuming adopt= ion and approval of the new charter, we will then run a three-week working = group last call (ending shortly after the end of the year). Given the relat= ively simple mechanism and limited scope of the current document, we believ= e this is a reasonable timeframe. If you disagree, please speak up.

Working group participants are strongly encouraged to review and comment on= the document at this time.

Thanks!

/a

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore<= br>

--047d7b5d25509f976a05427748c1-- From nobody Wed Nov 30 08:42:20 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59791295CB for ; Wed, 30 Nov 2016 08:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdGjs_IeRIez for ; Wed, 30 Nov 2016 08:42:14 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5A41299B9 for ; Wed, 30 Nov 2016 08:15:59 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id j65so356915258iof.0 for ; Wed, 30 Nov 2016 08:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4EDwCMjijUFHX8s5RCOR8Xa4IeOBAhKBAIb21SihoDY=; b=w1AFGq1kWKIY8aodi4UOc2cf77bduBpUM7RUMI+FTiG7CYgRvbPIPN7JsqyR9CmQHT ljni4UWP4ugVsqhoJHPRqt77jUwiym4ZjbESJKAIgJ+CDbrEPqIrdBxPApU9K7k0z8jB mDP1nhVMZi2Cn9tndDSiBQnSr+TGS6U+Aiy52L6GMMc5SVLseAIFMYsmXyyRaUeKrxWH E2zauDeneTRnz1TGtOkcdRLMzB1BHWyC5Y+yHwNFw0OldYv3SHuKEzzENYXplarNZyIp UTzjDkcgCKPvBbKwtP08HkFiapisQYAGI29HaVMjlTg8PcmrysoAntcZEPKZoBDPFGZK hPsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4EDwCMjijUFHX8s5RCOR8Xa4IeOBAhKBAIb21SihoDY=; b=aYMaQQOPT4r1y2vpcQuBTMlp15svfR2HCOje4tf2IUhn2FO+HAYCwdIPhw9JPhPlyJ 5FLipGvoyJX1/WtnSazny/arDSBaIkpHUhyX82w6CSN8f0MoClicDIfHceVQ8qo9LK64 QbIJxk68wt8jFcsTfoI9DCrP1mkDx2HnK94CkEFMC3wNz0jWSKIGhkYGULBwKpwW3ftZ SUDvz1FI62TCt5G+FirvmBlkkpnEohCiHMjmniOaN3oAVpNB7ahdt2pXRUvQIflG2iFc zM8nC/0aJtAsJ9kib7iyDUjyWBM6NRUtLM82ZCe3FEK99syGNmRPbDbO/ArunLzrN87T RTxQ== X-Gm-Message-State: AKaTC03iiPi6VLCgISSGCLJTYqsQypdLpsyuYNZGKoae4VJLrLzH2YeGS8WdAMXMziP5Pfq7yQ8JZZf4vmtBRw== X-Received: by 10.36.212.66 with SMTP id x63mr26838227itg.14.1480522558261; Wed, 30 Nov 2016 08:15:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.29.209 with HTTP; Wed, 30 Nov 2016 08:15:57 -0800 (PST) In-Reply-To: References: From: Andy Hutton Date: Wed, 30 Nov 2016 16:15:57 +0000 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=94eb2c0b0c262acf390542870561 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 16:42:18 -0000 --94eb2c0b0c262acf390542870561 Content-Type: text/plain; charset=UTF-8 I support. Andy On Tue, Nov 29, 2016 at 1:25 AM, Adam Roach wrote: > [as chair] > > SIPCORE: > > The chairs would like to call for adoption of > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE draft, > provisional on approval of the currently proposed SIPCORE charter revisions > (which we believe have a high probability of approval). If you have any > opinion on such adoption, please comment on the SIPCORE mailing list within > the next two weeks. > > While we do not wish to rush discussion unnecessarily, we have been > informally told by 3GPP that the registration of a SIP status code meaning > "reject this call and any subsequent calls from the same caller" is both > important and time-sensitive. To that end, we plan to run this call for > adoption over the next two weeks (ending Monday, December 12). Assuming > adoption and approval of the new charter, we will then run a three-week > working group last call (ending shortly after the end of the year). Given > the relatively simple mechanism and limited scope of the current document, > we believe this is a reasonable timeframe. If you disagree, please speak up. > > Working group participants are strongly encouraged to review and comment > on the document at this time. > > Thanks! > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --94eb2c0b0c262acf390542870561 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support.

Andy

On Tue, Nov 29, 2016 at 1:2= 5 AM, Adam Roach <adam@nostrum.com> wrote:
[as chair]

SIPCORE:

The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the curre= ntly proposed SIPCORE charter revisions (which we believe have a high proba= bility of approval). If you have any opinion on such adoption, please comme= nt on the SIPCORE mailing list within the next two weeks.

While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "r= eject this call and any subsequent calls from the same caller" is both= important and time-sensitive. To that end, we plan to run this call for ad= option over the next two weeks (ending Monday, December 12). Assuming adopt= ion and approval of the new charter, we will then run a three-week working = group last call (ending shortly after the end of the year). Given the relat= ively simple mechanism and limited scope of the current document, we believ= e this is a reasonable timeframe. If you disagree, please speak up.

Working group participants are strongly encouraged to review and comment on= the document at this time.

Thanks!

/a

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore<= br>

--94eb2c0b0c262acf390542870561-- From nobody Wed Nov 30 09:02:20 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE871295FD for ; Wed, 30 Nov 2016 09:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWzFpSZtsV67 for ; Wed, 30 Nov 2016 09:02:12 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F5B128AB0 for ; Wed, 30 Nov 2016 09:02:02 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id p16so193503972qta.0 for ; Wed, 30 Nov 2016 09:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F6oMmqMCtV0OI5/DZw5WIKAIJO3GzoIDCGFAuE9cYko=; b=uCiEQog8hQCyaM7pGyv9KnxJOQ6MHizsuG73ysR6hPEvtnoDO/+mbOEz/R6h6LPOj+ zK6pjAwiIC0/0drY3h9piYUjBn1uWwPULumd2r4WXz+5SbcIABK/drEXizxxFx4wFJix HkMaIMqiSzpRXQ59z8ZK+7KZrpNzLWk3hkczuQdrmtZE1KWJBZGG/rIxCow96y5/aPxr 17pc74yEDxJMAA9YFXQ4mFBTBRsgCVtehbS09z7LnBBAk5V0qpVmsXy5rWXOhiZOPhpK 6QO5LAQSPaSDsEyUJhZ6sE6+5Cb1No0YX0/Bhom3WDn0KaL85LMeNiOEG8l0ACjMLDPN rXLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F6oMmqMCtV0OI5/DZw5WIKAIJO3GzoIDCGFAuE9cYko=; b=dvQ8eLhXNko8yD6CybUWTCd6HGgGquvcYMCZGBcd0q4vjFPrjjPjFNTKAiv32GKDYY zmTWGjIkubFvSlZWVWRMRWPIv80DR6iqVo38t8Rf4nHbwccEFWQpyuCUNK8Brg1Rxmh4 /VRlfcNUbu+XXivM7e89fon7poTJnwTeOBrKF0uujMRtF0tyEs5vhYGEYfaD0MdEAvD2 9Ew1v7AVk0EV7gulrusVyhWzhTDVDj2EwxIDvL2NKzj2GBOqVaOQMPlm+sKVQME0Y8hv A4cCMwMDd87jPFv5kaxHgbHMVIrEp00VQ8m8tVhYGKejRE/iTzsK18uTRXNjBiVhh5aC kG9g== X-Gm-Message-State: AKaTC03DkrWt8a4pxnHIoH2oi/uYEv2Ebc32chxIHNWZOC+AwL8S7k52mmGE+kcLxhtarw== X-Received: by 10.200.43.5 with SMTP id 5mr29701151qtu.279.1480525321579; Wed, 30 Nov 2016 09:02:01 -0800 (PST) Received: from ?IPv6:2600:1003:b119:7cf:998e:43ca:995c:8fd5? ([2600:1003:b119:7cf:998e:43ca:995c:8fd5]) by smtp.gmail.com with ESMTPSA id 21sm15453326qkh.4.2016.11.30.09.01.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Nov 2016 09:01:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Eric Burger In-Reply-To: Date: Wed, 30 Nov 2016 12:01:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7A911399-B0B6-4A4A-846C-5A0AD9489E52@gmail.com> References: To: Roach Adam X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 17:02:16 -0000 Opinion: Yes, please. > On Nov 28, 2016, at 8:25 PM, Adam Roach wrote: >=20 > [as chair] >=20 > SIPCORE: >=20 > The chairs would like to call for adoption of = draft-schulzrinne-dispatch-status-unwanted as a SIPCORE draft, = provisional on approval of the currently proposed SIPCORE charter = revisions (which we believe have a high probability of approval). If you = have any opinion on such adoption, please comment on the SIPCORE mailing = list within the next two weeks. >=20 > While we do not wish to rush discussion unnecessarily, we have been = informally told by 3GPP that the registration of a SIP status code = meaning "reject this call and any subsequent calls from the same caller" = is both important and time-sensitive. To that end, we plan to run this = call for adoption over the next two weeks (ending Monday, December 12). = Assuming adoption and approval of the new charter, we will then run a = three-week working group last call (ending shortly after the end of the = year). Given the relatively simple mechanism and limited scope of the = current document, we believe this is a reasonable timeframe. If you = disagree, please speak up. >=20 > Working group participants are strongly encouraged to review and = comment on the document at this time. >=20 > Thanks! >=20 > /a >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Nov 30 09:22:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997B01294C3 for ; Wed, 30 Nov 2016 09:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcvrFMh40309 for ; Wed, 30 Nov 2016 09:22:04 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD761294D8 for ; Wed, 30 Nov 2016 09:22:02 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id EAFB87A9DCF8C; Wed, 30 Nov 2016 17:21:58 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id uAUHM1WG030270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Nov 2016 17:22:01 GMT Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id uAUHM018007835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2016 17:22:00 GMT Received: from [135.185.238.154] (shoonya.ih.lucent.com [135.185.238.154]) by umail.lucent.com (8.13.8/TPES) with ESMTP id uAUHLxsA000932; Wed, 30 Nov 2016 11:21:59 -0600 (CST) To: Adam Roach , "'SIPCORE'" References: From: "Vijay K.Gurbani" Message-ID: <7cea6664-4a10-cdda-548b-53580afb2dd3@nokia-bell-labs.com> Date: Wed, 30 Nov 2016 11:21:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Call for (provisional) Adoption:draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 17:22:13 -0000 On 11/28/2016 07:25 PM, Adam Roach wrote: > The chairs would like to call for adoption of > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE draft, > provisional on approval of the currently proposed SIPCORE charter > revisions (which we believe have a high probability of approval). If you > have any opinion on such adoption, please comment on the SIPCORE mailing > list within the next two weeks. [...] Yes for adoption. Couple minor nits from a quick review: - S1: s/was unwanted/is unwanted/ (Reason: to match the present tense verb "express") - S6: s/is used/be used/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@bell-labs.com / vijay.gurbani@nokia-bell-labs.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Wed Nov 30 09:56:42 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63B31295BD for ; Wed, 30 Nov 2016 09:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.616 X-Spam-Level: X-Spam-Status: No, score=-3.616 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WniakL7BHopv for ; Wed, 30 Nov 2016 09:56:35 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33161295EF for ; Wed, 30 Nov 2016 09:56:34 -0800 (PST) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2016 12:56:33 -0500 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 30 Nov 2016 12:56:32 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 12:56:31 -0500 From: Andrew Allen To: Andy Hutton , Adam Roach Thread-Topic: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSSd9yMVsodqhGukWXaXs6lO81QqDyCiOA///ISK4= Date: Wed, 30 Nov 2016 17:56:31 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233A84671BXMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: Cc: 'SIPCORE' Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 17:56:41 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233A84671BXMB122CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Sent from my BlackBerry - the most secure mobile device From: andyhutton.ietf@gmail.com Sent: November 30, 2016 11:42 AM To: adam@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Call for (provisional) Adoption: draft-schulzrinne-d= ispatch-status-unwanted I support. Andy On Tue, Nov 29, 2016 at 1:25 AM, Adam Roach > wrote: [as chair] SIPCORE: The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the currently = proposed SIPCORE charter revisions (which we believe have a high probabilit= y of approval). If you have any opinion on such adoption, please comment on= the SIPCORE mailing list within the next two weeks. While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "reject= this call and any subsequent calls from the same caller" is both important= and time-sensitive. To that end, we plan to run this call for adoption ove= r the next two weeks (ending Monday, December 12). Assuming adoption and ap= proval of the new charter, we will then run a three-week working group last= call (ending shortly after the end of the year). Given the relatively simp= le mechanism and limited scope of the current document, we believe this is = a reasonable timeframe. If you disagree, please speak up. Working group participants are strongly encouraged to review and comment on= the document at this time. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_BBF5DDFE515C3946BC18D733B20DAD233A84671BXMB122CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

Sent from my BlackBerry - the most secure mobile device
From: andyhutton.ietf@gmail.com
Sent: November 30, 2016 11:42 AM
To: adam@nostrum.com
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Call for (provisional) Ad= option: draft-schulzrinne-dispatch-status-unwanted

I support.

Andy

On Tue, Nov 29, 2016 at 1:25 AM, Adam Roach <adam@nostrum.com<= /a>> wrote:
[as chair]

SIPCORE:

The chairs would like to call for adoption of draft-schulzrinne-dispatch-st= atus-unwanted as a SIPCORE draft, provisional on approval of the curre= ntly proposed SIPCORE charter revisions (which we believe have a high proba= bility of approval). If you have any opinion on such adoption, please comment on the SIPCORE mailing list w= ithin the next two weeks.

While we do not wish to rush discussion unnecessarily, we have been informa= lly told by 3GPP that the registration of a SIP status code meaning "r= eject this call and any subsequent calls from the same caller" is both= important and time-sensitive. To that end, we plan to run this call for adoption over the next two weeks (ending Mond= ay, December 12). Assuming adoption and approval of the new charter, we wil= l then run a three-week working group last call (ending shortly after the e= nd of the year). Given the relatively simple mechanism and limited scope of the current document, we believe thi= s is a reasonable timeframe. If you disagree, please speak up.

Working group participants are strongly encouraged to review and comment on= the document at this time.

Thanks!

/a

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore<= br>

--_000_BBF5DDFE515C3946BC18D733B20DAD233A84671BXMB122CNCrimnet_-- From nobody Wed Nov 30 14:59:16 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA93129514; Wed, 30 Nov 2016 14:59:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148054675180.9654.5251117708811332719.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 14:59:11 -0800 Archived-At: Cc: sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] Ben Campbell's Yes on charter-ietf-sipcore-03-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 22:59:12 -0000 Ben Campbell has entered the following ballot position for charter-ietf-sipcore-03-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sipcore/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do people think this needs external review?