From nobody Mon Feb 1 11:30:04 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 8AEF01B3500; Mon, 1 Feb 2016 11:29:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160201192930.8890.68073.idtracker@ietfa.amsl.com> Date: Mon, 01 Feb 2016 11:29:30 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-dns-dual-stack-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:29:30 -0000 X-List-Received-Date: Mon, 01 Feb 2016 19:29:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Authors : Olle E. Johansson Gonzalo Salgueiro Vijay Gurbani Dale R. Worley Filename : draft-ietf-sipcore-dns-dual-stack-03.txt Pages : 9 Date : 2016-02-01 Abstract: RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying Happy Eyeballs to SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-dns-dual-stack-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-dns-dual-stack-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 1 11:36:39 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2961B352B for ; Mon, 1 Feb 2016 11:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 2j-2up5NWvn4 for ; Mon, 1 Feb 2016 11:36:23 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C971B3522 for ; Mon, 1 Feb 2016 11:35:16 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-11v.sys.comcast.net with comcast id D7aL1s0034yXVJQ017bBeC; Mon, 01 Feb 2016 19:35:11 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-06v.sys.comcast.net with comcast id D7bA1s00C1nMCLR017bBxX; Mon, 01 Feb 2016 19:35: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 u11JZ9Hq017850 for ; Mon, 1 Feb 2016 14:35:09 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u11JZ9Lx017847; Mon, 1 Feb 2016 14:35: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: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 01 Feb 2016 14:35:09 -0500 Message-ID: <87si1cz0k2.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1454355311; bh=eiqMHE1Z5Me8A1fUjEX9TFMVgLRSIL7VhCwtO/1YjR4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=owOAyGstRerjPUn1cqqsdFud1tQM/bLSHyktjyGBrQj4oGUxjs1cXtwzfoEIrwY9q EKHh+olBbq3M2jT8t4XlzSJnTIIhrD7hHe+TT5iyr+OUiQAfJdJM0x6R4rzM5yv4c+ MCzYYB2I6zBuiPn6GTL1m/OjrGk0GTSm7CL1waG4ILBwGN8QXlrX8Xw0q8qncsyRvB RvBYa8JI6Wupq0GU/UyFai5y4XdwHGhl4xQJl8BUelfdAzf0YdfGtaC7Gcf8bGTWSS vhv7CmzuT5F8RbT3bBrfbyy9hHksWpXLqztwpN9cCtVTOx3xvVONNIAqSXbWpe/hxZ 3R+wl5RHpxO9g== Archived-At: Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:36:24 -0000 I've done an edit of draft-ietf-sipcore-dns-dual-stack and submitted it as the -03. The notification for the new version will be out as soon as one of the old authors confirms it. It doesn't seem to me that any of the changes are controversial, but nonetheless, please take a careful look at it, as I think we're close to WGLC for the draft. In particular: - The text emphasizes that this draft does not implement Happy Eyeballs for SIP, but rather does necessary preparation for that. - The draft is not marked as updating 3263, but I believe that we will have to do that, as we really are updating 3263. - I've copied the term "address records" from RFC 2782 (SRV records), because that term covers all records that provide addresses for any address families supported by the device. Thus, the term "address records" automatically extends to any new address family that is defined. - It's not obvious to the casual reader how the two revision points in section 4.1 fit into the overall 3263 resolution process. In fact, after any NAPTR processing, resolution branches into 4 cases: . explicit address, . domain name with port number, . domain name without port number and without SRV records, . domain name without port number and with SRV records. Case 4 is delegated to 2782, which *already* requires looking up both A and AAAA records. Cases 2 and 3 are handled in 3263 directly, and are the two items which are being updated. - I've revised the wording regarding how 3263 interacts with 6157. I believe that the new wording expresses what was intended, but people should check me on this. Dale From nobody Tue Feb 2 07:58:03 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488031ACD22 for ; Tue, 2 Feb 2016 07:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 10mJYLevGsjg for ; Tue, 2 Feb 2016 07:58:00 -0800 (PST) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 D50F71ACD16 for ; Tue, 2 Feb 2016 07:58:00 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id u12Fvnw8043987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 08:57:50 -0700 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 4A8151E007E; Tue, 2 Feb 2016 08:57:44 -0700 (MST) Received: from lxomp07u.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 0F1B61E0076; Tue, 2 Feb 2016 08:57:44 -0700 (MST) Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id u12FvhLY055712; Tue, 2 Feb 2016 09:57:43 -0600 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id u12FvhUA055707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Feb 2016 09:57:43 -0600 Received: from PDDCWMBXEX505.ctl.intranet ([fe80::8c68:5e86:9837:2697]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Tue, 2 Feb 2016 08:57:42 -0700 From: "Penar, Russell" To: "'Dale R. Worley'" Thread-Topic: [sipcore] sip/tcp with primary & secondary outbound proxies (behavior upon receipt of tcp rst) Thread-Index: AQHRXJ411DcvmLeEEEu3lrbXwSyFPZ8Y6nhQ Date: Tue, 2 Feb 2016 15:57:42 +0000 Message-ID: <12C684AA1283B949BD80AC8273CF3A723F5ACCA3@PDDCWMBXEX505.ctl.intranet> References: <12C684AA1283B949BD80AC8273CF3A723F59E700@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) <87mvrl15wt.fsf@hobgoblin.ariadne.com> In-Reply-To: <87mvrl15wt.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.16.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] sip/tcp with primary & secondary outbound proxies (behavior upon receipt of tcp rst) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 15:58:02 -0000 Thank you Dale, I will. I appreciate the link as I am definitely new to th= e forum/process. Should I draft using standard RFC template and then look to work that into = an addendum to an existing RFC? I do want to follow process and gain suppor= t. Regards, Russ -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com] Sent: Sunday, January 31, 2016 8:11 PM To: Penar, Russell Cc: sipcore@ietf.org Subject: Re: [sipcore] sip/tcp with primary & secondary outbound proxies (b= ehavior upon receipt of tcp rst) "Penar, Russell" writes: > While we agree on these informal best practices (including retrying > primary target upon receipt of RST), it seems vendors aren't getting > the memo and ideally these practices/behaviors would be included in an > RFC for easy reference and less back and forth with vendors who chose > wrong up front. You could write an RFC covering what you want to see: http://www.ietf.org/edu/documents/81IETF-New-Work.pdf Dale This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Fri Feb 12 11:28:23 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0205B1A88B1 for ; Fri, 12 Feb 2016 11:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 PPGcet5-v5yE for ; Fri, 12 Feb 2016 11:28:20 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52421A88FC for ; Fri, 12 Feb 2016 11:28:20 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-09v.sys.comcast.net with comcast id HXTh1s0012D5gil01XUKsx; Fri, 12 Feb 2016 19:28:19 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-06v.sys.comcast.net with comcast id HXUJ1s00R1nMCLR01XUKeB; Fri, 12 Feb 2016 19:28:19 +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 u1CJSICl003442; Fri, 12 Feb 2016 14:28:18 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1CJSIF4003439; Fri, 12 Feb 2016 14:28:18 -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: "Penar\, Russell" In-Reply-To: <12C684AA1283B949BD80AC8273CF3A723F5ACCA3@PDDCWMBXEX505.ctl.intranet> (Russell.Penar@centurylink.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 12 Feb 2016 14:28:17 -0500 Message-ID: <87io1t684u.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455305299; bh=cBR/w8CWliv4kHu+E4uPoSHSJaUYQmkEeH65IL5taAE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=egK1+oLEcE/q5/GY3CtHg7SXGxKrLPohWGW08Rtfeb/ybl+4RbWRPJOifBOoCTAMW iNiSZ99F4hTMfxVVc1G98NXfYJ+4eEPHtNrUdx2Y4ogls9ixb+QTtf9FqgVXa296QJ MmS8LrN2e41Q8T5Ib5tmITf4fXPE32p1XJzuxHGdCVholdKey492qqI3yYaRWqAevp GhmVOrhSiOlHCp7ocgAZ3voGRyAD4ZllWVHFOB585MDh6W+VbDswYNSZSR72xdVrZe Q+AqYQnb7bMq/x60PCEHbWvZfCVfhq68McEfgo7mlrfs1Yc8mpKUaNbv61Uodxk/2i 3tDp8lPBL4eFw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] sip/tcp with primary & secondary outbound proxies (behavior upon receipt of tcp rst) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 19:28:22 -0000 "Penar, Russell" writes: > Should I draft using standard RFC template and then look to work that > into an addendum to an existing RFC? I do want to follow process and > gain support. Probably the best thing is to write a draft for a "best current practice" RFC containing the various rules we've been talking about. You can see from the list of RFCs (https://www.rfc-editor.org/rfc-index.html) that a lot of them are "best current practice". I suspect that with further discussion you'll hear of a lot of other rules that SIP implementors know but have never been written down. Circulate your draft in the Dispatch working to see what people think. Usually, people use XML2RFC to write RFCs. The page to use that tool is http://xml2rfc.tools.ietf.org/, it also contains links to most of the documentation for it. Dale From nobody Fri Feb 12 11:58:04 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC5D1A894F for ; Fri, 12 Feb 2016 11:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 wGIwOOpNDciO for ; Fri, 12 Feb 2016 11:58:02 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63121A894E for ; Fri, 12 Feb 2016 11:58:01 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-02v.sys.comcast.net with comcast id HXwu1s0052PT3Qt01Xy0ZM; Fri, 12 Feb 2016 19:58:00 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-14v.sys.comcast.net with comcast id HXy01s0031nMCLR01Xy0Ck; Fri, 12 Feb 2016 19:58:00 +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 u1CJvxnx005097 for ; Fri, 12 Feb 2016 14:57:59 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1CJvxc9005094; Fri, 12 Feb 2016 14:57:59 -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: sipcore@ietf.org In-Reply-To: <87si1cz0k2.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 12 Feb 2016 14:57:59 -0500 Message-ID: <87a8n566rc.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455307080; bh=1qAlEoW1UqHs5xu9BbycWv20bMih1EKVuNPqo+Xoj14=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=rweDe8USdR01WbUF4uONWV8KPHh15KvSe/8IAHuyEaY3pvgSPBGjn/69CXKD6VugG 188hnLD05sdz426+bCF+f89Mq0R5QfPgpRdMz3Cw2cSlpYqoQE3gabIRvniS/vj16G KTZBsiLW/QdAQ81CQ4JtTbbEuFaOzeIzNNdYsMAfljDG1qmLa6lLMebA/QfOqMtarL aHR68Pf8rfAEkjAH6cUl9T53qkTxQ/3uvkQWHkAuBHxvbnCBPF/2GyjG+ngQUxFdBd KQPmzCBKgSCKYelT6B4Na2r62dPaNEfx8rbddinfwGsWCSLmBQ5n+wCtEmx60WGGvv TKTDHsfV+4SDQ== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 19:58:03 -0000 I propose modifying draft-ietf-sipcore-dns-dual-stack-03 to correct its statement of the RFCs that it is updating. > - The draft is not marked as updating 3263, but I believe that we will > have to do that, as we really are updating 3263. I think this draft really does update 3263, and it should say so. The only alternative is to argue that the draft is stating what everybody understood 3263 to mean already, and I don't think that is the case. > - I've revised the wording regarding how 3263 interacts with 6157. I > believe that the new wording expresses what was intended, but people > should check me on this. On the other hand, I think that this draft doesn't modify how 6157. It seems to me that the only sensible meaning of the text of 3263 in the light of 6157 is how this draft explains it: This document clarifies the process: If SRV lookup is successful, the major ordering of the list of destination addresses is determined by the priority and weight fields of the SRV records as specified in [RFC2782]. The (minor) ordering among the destinations derived from the "target" field of a single SRV record is determined by [RFC6724]. However, I could be convinced otherwise. Dale From nobody Fri Feb 12 11:59:04 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DFE1A894E for ; Fri, 12 Feb 2016 11:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 DsHMcUh-9HEb for ; Fri, 12 Feb 2016 11:59:02 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33A81A8945 for ; Fri, 12 Feb 2016 11:59:01 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-10v.sys.comcast.net with comcast id HXye1s0055AAYLo01XyzRB; Fri, 12 Feb 2016 19:58:59 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-15v.sys.comcast.net with comcast id HXyy1s00M1nMCLR01XyzVW; Fri, 12 Feb 2016 19:58:59 +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 u1CJwwjn005151 for ; Fri, 12 Feb 2016 14:58:58 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1CJwwB0005148; Fri, 12 Feb 2016 14:58:58 -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: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 12 Feb 2016 14:58:58 -0500 Message-ID: <878u2p66pp.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455307139; bh=6dieVxjJdxauhq8YD+gHLTYrx0JISt5SPmZGax5uK+Y=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=jcA5XItxNAhxR8MtMNnxT3Nfu62ibQVAjB4tWDAtNZWVCGk/a1gObvuNklOvnj+gt qDi1Oyyauz8CRWkITAcyS4juAypmiFB6dICWl4BRcLIFMWdh//B8usEi+3wkNWpZu3 fZwLoaAhuU09hlw0uWysvPIBfmCGQXWbl46Sc9RZlvpDxk2iE1PzURpqkkqBwYPPsz 0NZ0ti0ee8Tqm14f4ZIkn81AEQS3qaQujyFNJYCra1ppVeDB5v0LE4wvR+K7+2L67l hx3xY9D3VNJ0LUTffKp92hxM73D3Kk/4SNDCMu4EixiSPuAsiDpjgZH1Vmj06WFqGf BukkdTp7Qg6uw== Archived-At: Subject: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 19:59:02 -0000 Is anyone considering writing up the actual use of Happy Eyeballs in a SIP context? Does anyone have any practical experience or suggestions for what HE in SIP would be? Dale From nobody Fri Feb 12 12:12:27 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD2B1A897C for ; Fri, 12 Feb 2016 12:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 xO_GeaLvcegi for ; Fri, 12 Feb 2016 12:12:20 -0800 (PST) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4601A8979 for ; Fri, 12 Feb 2016 12:12:20 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1CKBPLZ027737; Fri, 12 Feb 2016 15:12:19 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 20ypb69ugy-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Feb 2016 15:12:19 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 12 Feb 2016 14:12:18 -0600 From: Jonathan Lennox To: "Dale R. Worley" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHRZdCBzyKanvDHTkqEPJO8cE8v658pPE4A Date: Fri, 12 Feb 2016 20:12:17 +0000 Message-ID: <0459CA0C-107B-4136-B2E1-D283AE364306@vidyo.com> References: <878u2p66pp.fsf@hobgoblin.ariadne.com> In-Reply-To: <878u2p66pp.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <22E1BE150FFCE047A0A93AA96E27671B@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-02-12_10:2016-02-12,2016-02-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1602120315 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 20:12:21 -0000 DQo+IE9uIEZlYiAxMiwgMjAxNiwgYXQgMjo1OCBQTSwgRGFsZSBSLiBXb3JsZXkgPHdvcmxleUBh cmlhZG5lLmNvbT4gd3JvdGU6DQo+IA0KPiBJcyBhbnlvbmUgY29uc2lkZXJpbmcgd3JpdGluZyB1 cCB0aGUgYWN0dWFsIHVzZSBvZiBIYXBweSBFeWViYWxscyBpbiBhDQo+IFNJUCBjb250ZXh0Pw0K PiANCj4gRG9lcyBhbnlvbmUgaGF2ZSBhbnkgcHJhY3RpY2FsIGV4cGVyaWVuY2Ugb3Igc3VnZ2Vz dGlvbnMgZm9yIHdoYXQgSEUgaW4NCj4gU0lQIHdvdWxkIGJlPw0KDQpJZiBwYXJhbGxlbCBmb3Jr aW5nIHdvcmtlZCwgZm9ya2luZyB0byB0aGUgdjQgYW5kIHY2IGFkZHJlc3NlcyAod2l0aCB0aGUg dXN1YWwgdGltaW5nIHJ1bGVzIEhhcHB5IEV5ZWJhbGxzIGFkdmlzZXMpIHdvdWxkIHNlZW0gdG8g ZG8gZXhhY3RseSB3aGF0IHdlIHdhbnQg4oCUIDMyNjHigJlzIE1lcmdlZCBSZXF1ZXN0IHJ1bGVz IHdvdWxkIHRha2UgY2FyZSBvZiB0aGUgZHVwbGljYXRlZCByZXF1ZXN0cy4NCg0KVW5mb3J0dW5h dGVseSwgdGhlIHdvcmxkIG9mIEIyQlVBcyBsYXJnZWx5IGJyZWFrcyBwYXJhbGxlbCBmb3JraW5n Lg0KDQpJcyB0aGVyZSBhbnkgd2F5IHRvIHVuYnJlYWsgaXQgZW5vdWdoIHNvIGFzIHRvIHNheSB0 aGF0IGlmIHlvdSBzdXBwb3J0IGluY29taW5nIEhhcHB5IEV5ZWJhbGxzLCB5b3UgaGF2ZSB0byBo YXZlIHJlcXVlc3QgbWVyZ2luZyB3b3JraW5nPw== From nobody Fri Feb 12 12:13:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB91A8980 for ; Fri, 12 Feb 2016 12:13:57 -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, SPF_PASS=-0.001] autolearn=ham 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 gATym1lIbmc2 for ; Fri, 12 Feb 2016 12:13:55 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 79BCC1A8979 for ; Fri, 12 Feb 2016 12:13:55 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id e127so52588160pfe.3 for ; Fri, 12 Feb 2016 12:13:55 -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-type:content-transfer-encoding; bh=iq1/bqleCb4U8slSr/G3Hj2Xjw6EOL1rCRPJQTelz8g=; b=WLg0bqIzZYmpXxA0DuIgdxFoM06AaNPBSvncgWdoVDT6sGGx/BOOCq9OxmWY9EQ50x mbliqTayBJqGJEbnV16LgGKSpgvKxA9EO09/Xz2g2UYB4A5BW1Urs+QIvYRmuifDBGPE Y5bRwcCbpiRS7K6ABq3gt8FSxQge3vnfL/gDkdNU3AgVTHr8GSH3E3x65MVPQG71iYMq QmcHHKDmbxtIIPFJRNzoa4XcV3+KhatZwnfW1Gvp8WBMa7iCr3PNsRi/tQX/qNwjARMS XhAOIK33+HRyEX+mQj5Vwr0Pl4/5xaKZH/6V+z4dWNCBV6ZN+mYdGI6WfCbA0clOHbyP 3SdA== 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-type :content-transfer-encoding; bh=iq1/bqleCb4U8slSr/G3Hj2Xjw6EOL1rCRPJQTelz8g=; b=lX/CEUxY1KHw3pesGrbVVVo+dGT0+XaDDuVJAK5kQi+Y4N2t4vyQbDWO2h4zTg0Lbf 712fjSlu3hejN9vgctZ8xCFXHer4PZY2YOwOraq3f8L/nbGDcfFAOBsWouXDLJxGs6Qc UxMMifsnmTZZAOAMq1+xQ1v3oBFYy+GEMCUxF0+XQptR+qR0CTTj/qCoyYbiWqg+vtFs Jiw/MGl8Dekp9I+c2obccNgzuYz06mtP5GF1SRaBXzziUPyB323Ts09x7aBemI9vd37v AUHMi7JyIUPJjKiaeDToBZrkWrUp8Z/oVCuDdQRqSgeO5aE2GEzZqpfKk+ioJeEK9orI +uiw== X-Gm-Message-State: AG10YOSjs4YD8yJKqYQWxAmx3n4C4PnU0IWq9NZ0E6Idr/D5rthQ7Ttol/q8HpBGQvZzS/eo X-Received: by 10.98.43.194 with SMTP id r185mr4940599pfr.24.1455308035005; Fri, 12 Feb 2016 12:13:55 -0800 (PST) Received: from Simons-MacBook-Air.local (modemcable002.114-70-69.static.videotron.ca. [69.70.114.2]) by smtp.googlemail.com with ESMTPSA id k65sm21347779pfb.30.2016.02.12.12.13.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 12:13:54 -0800 (PST) To: "Dale R. Worley" , sipcore@ietf.org References: <87a8n566rc.fsf@hobgoblin.ariadne.com> From: Simon Perreault Message-ID: <56BE3CFF.6010109@jive.com> Date: Fri, 12 Feb 2016 15:13:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <87a8n566rc.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 20:13:57 -0000 +1 Le 2016-02-12 14:57, Dale R. Worley a écrit : > I propose modifying draft-ietf-sipcore-dns-dual-stack-03 to correct its > statement of the RFCs that it is updating. > >> - The draft is not marked as updating 3263, but I believe that we will >> have to do that, as we really are updating 3263. > > I think this draft really does update 3263, and it should say so. The > only alternative is to argue that the draft is stating what everybody > understood 3263 to mean already, and I don't think that is the case. > >> - I've revised the wording regarding how 3263 interacts with 6157. I >> believe that the new wording expresses what was intended, but people >> should check me on this. > > On the other hand, I think that this draft doesn't modify how 6157. It > seems to me that the only sensible meaning of the text of 3263 in the > light of 6157 is how this draft explains it: > > This document clarifies the process: If SRV lookup is successful, the > major ordering of the list of destination addresses is determined by > the priority and weight fields of the SRV records as specified in > [RFC2782]. The (minor) ordering among the destinations derived from > the "target" field of a single SRV record is determined by [RFC6724]. > > However, I could be convinced otherwise. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Feb 12 12:55:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D711A8A6C for ; Fri, 12 Feb 2016 12:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 rw6z32lHvulk for ; Fri, 12 Feb 2016 12:55:31 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id EE64C1A8A6B for ; Fri, 12 Feb 2016 12:55:30 -0800 (PST) Received: from [192.168.40.17] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 0AB7C93DE5C; Fri, 12 Feb 2016 20:54:33 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_AE54EA50-6DCD-4BAA-9D9C-14A71084374A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <87a8n566rc.fsf@hobgoblin.ariadne.com> Date: Fri, 12 Feb 2016 21:55:23 +0100 Message-Id: References: <87a8n566rc.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 20:55:33 -0000 --Apple-Mail=_AE54EA50-6DCD-4BAA-9D9C-14A71084374A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 12 Feb 2016, at 20:57, Dale R. Worley wrote: > > I propose modifying draft-ietf-sipcore-dns-dual-stack-03 to correct its > statement of the RFCs that it is updating. > >> - The draft is not marked as updating 3263, but I believe that we will >> have to do that, as we really are updating 3263. > > I think this draft really does update 3263, and it should say so. The > only alternative is to argue that the draft is stating what everybody > understood 3263 to mean already, and I don't think that is the case. > >> - I've revised the wording regarding how 3263 interacts with 6157. I >> believe that the new wording expresses what was intended, but people >> should check me on this. > > On the other hand, I think that this draft doesn't modify how 6157. It > seems to me that the only sensible meaning of the text of 3263 in the > light of 6157 is how this draft explains it: > > This document clarifies the process: If SRV lookup is successful, the > major ordering of the list of destination addresses is determined by > the priority and weight fields of the SRV records as specified in > [RFC2782]. The (minor) ordering among the destinations derived from > the "target" field of a single SRV record is determined by [RFC6724]. > > However, I could be convinced otherwise. I agree. /O --Apple-Mail=_AE54EA50-6DCD-4BAA-9D9C-14A71084374A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTIyMDU1MjNaMCMGCSqGSIb3 DQEJBDEWBBSX0FKhL5XnEqQ7lWKWqPEYgwO0MzCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEAJTRSt6qXinIFYkb8RYZ9OEbB2Rji5n4zLZIpFzNxVmuuEExfGaewR0bCdDQSV9AjFojs7SXR AKJHsVTvpheWJr3UdFdAj6TulBMGiwIB9bAWJ5s54zf7KRdtJTIxxIkSsQMGFKDN6hBiZAteWJwa mV9dupJgwo4gOoAaDKFYeZp6pa6DNrs2e0nCTDaY8O/3ZcARy7DGoKRVF+ZqMgOCBgLEJsLhjt82 wWTsoYf9cutGV3dQvI7FhNuw/XGykhd4PPMTB+8QeWPSTb/kGFEksXhszEAgpD5E7kS8EwnoQ6i5 rKhjcuGjKCblQeEy/4t+GNHnj2bzj6NkIsXvBJYEDgAAAAAAAA== --Apple-Mail=_AE54EA50-6DCD-4BAA-9D9C-14A71084374A-- From nobody Fri Feb 12 14:10:57 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3077E1A9103 for ; Fri, 12 Feb 2016 14:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 rtjg0WjCGm5q for ; Fri, 12 Feb 2016 14:10:47 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id A70CB1A90FC for ; Fri, 12 Feb 2016 14:10:45 -0800 (PST) Received: from [192.168.40.17] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7E42F93DE5C; Fri, 12 Feb 2016 22:09:49 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_6C222BA8-890C-4B11-BCB4-FFB77477F056"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <878u2p66pp.fsf@hobgoblin.ariadne.com> Date: Fri, 12 Feb 2016 23:10:39 +0100 Message-Id: <330D9D8A-CB91-4E84-92F4-49A7C54090B2@edvina.net> References: <878u2p66pp.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 22:10:50 -0000 --Apple-Mail=_6C222BA8-890C-4B11-BCB4-FFB77477F056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Feb 2016, at 20:58, Dale R. Worley wrote: >=20 > Is anyone considering writing up the actual use of Happy Eyeballs in a > SIP context? >=20 > Does anyone have any practical experience or suggestions for what HE = in > SIP would be? After discussing this for many years with many people this is my = conclusion: For connection oriented protocols - just point to existing RFC for happy = eyeballs. For UDP we have no solution, period. The only way is to handle this in = DNS SRV and have separate priorities for IPv4 and IPv6 in the order the service = likes. This is why we have tested DNS SRV with dual stacks in many SIPits and = written the draft about=20 dual stack issues - many IPv4 only clients crashed or failed when the = first SRV priority did not have IPv4 addresses at all. They also crashed when IPv6 was in = various headers, as documented in = https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-03 One has to remember that the IPv4 and IPv6 address for a dual stack = server may lead to different servers, thus sending a UDP message at the same time to = both may cause multiple transactions and all kinds of interesting side effects. = (Hadriel Kaplan reminded me of this). So the documentation on Happy Eyeballs in sip is pretty short: Don=E2=80=99= t try this with UDP. Solve the problem another way. (in fact, move to TCP/TLS as soon as you = can :-) ) If someone has a cool solution to this UDP issue - preferably without = loosing one round trip - I would be more than happy to hear it! /O= --Apple-Mail=_6C222BA8-890C-4B11-BCB4-FFB77477F056 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTIyMjEwMzlaMCMGCSqGSIb3 DQEJBDEWBBR2ugAzn9yPRyxgYLShe4qvNassfDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEAA3BDm3MREqqJBwByvH5XBvLIUvwG2i5JZaJ+ZgLh3AlexfIXIW3rNhDSYPgZ1EyCM+d4lbG4 r804g3K/NMYIBe6pYiixpH4sjV8X90mDendjU+T5/2el6Dtl5NLRqU3IiqPLjOtJg6D4sqP0nld/ on9tUDmPNU+QhKjJQ/p0Qk1zrR0uKzbdw6dTRg6F+cfZXVN6+8OvRILoV63ZJj5vLVTjJF1SC511 muXTArlk9drVX9GZq6IEEaR1ry7Xu0LM4h0ycaQXsdmKh1Ux4zZdog5v7cUn//3T6SnLPgjEinGN D4mDcTFxIqgzlPZr1pS0G1U8FVGv+JU7jOMykT+eDAAAAAAAAA== --Apple-Mail=_6C222BA8-890C-4B11-BCB4-FFB77477F056-- From nobody Mon Feb 15 11:51:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEB31A003B for ; Mon, 15 Feb 2016 11:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 5ZsLbI_wL_oE for ; Mon, 15 Feb 2016 11:51:05 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8421A9030 for ; Mon, 15 Feb 2016 11:51:05 -0800 (PST) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1FJoDiO021591; Mon, 15 Feb 2016 14:50:41 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 210ye5j9v1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Feb 2016 14:50:41 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 15 Feb 2016 13:50:39 -0600 From: Jonathan Lennox To: "Olle E. Johansson" Thread-Topic: [sipcore] Happy Eyeballs for SIP Thread-Index: AQHRZdCBzyKanvDHTkqEPJO8cE8v658pXV2AgASP4YA= Date: Mon, 15 Feb 2016 19:50:39 +0000 Message-ID: <69252B73-3F04-4FCF-8C47-63C7C813C2BB@vidyo.com> References: <878u2p66pp.fsf@hobgoblin.ariadne.com> <330D9D8A-CB91-4E84-92F4-49A7C54090B2@edvina.net> In-Reply-To: <330D9D8A-CB91-4E84-92F4-49A7C54090B2@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_69252B733F044FCF8C4763C7C813C2BBvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-02-15_10:2016-02-15,2016-02-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1602150326 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 19:51:07 -0000 --_000_69252B733F044FCF8C4763C7C813C2BBvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBGZWIgMTIsIDIwMTYsIGF0IDU6MTAgUE0sIE9sbGUgRS4gSm9oYW5zc29uIDxvZWpAZWR2 aW5hLm5ldDxtYWlsdG86b2VqQGVkdmluYS5uZXQ+PiB3cm90ZToNCg0KDQpPbiAxMiBGZWIgMjAx NiwgYXQgMjA6NTgsIERhbGUgUi4gV29ybGV5IDx3b3JsZXlAYXJpYWRuZS5jb208bWFpbHRvOndv cmxleUBhcmlhZG5lLmNvbT4+IHdyb3RlOg0KDQpJcyBhbnlvbmUgY29uc2lkZXJpbmcgd3JpdGlu ZyB1cCB0aGUgYWN0dWFsIHVzZSBvZiBIYXBweSBFeWViYWxscyBpbiBhDQpTSVAgY29udGV4dD8N Cg0KRG9lcyBhbnlvbmUgaGF2ZSBhbnkgcHJhY3RpY2FsIGV4cGVyaWVuY2Ugb3Igc3VnZ2VzdGlv bnMgZm9yIHdoYXQgSEUgaW4NClNJUCB3b3VsZCBiZT8NCg0KQWZ0ZXIgZGlzY3Vzc2luZyB0aGlz IGZvciBtYW55IHllYXJzIHdpdGggbWFueSBwZW9wbGUgdGhpcyBpcyBteSBjb25jbHVzaW9uOg0K DQpGb3IgY29ubmVjdGlvbiBvcmllbnRlZCBwcm90b2NvbHMgLSBqdXN0IHBvaW50IHRvIGV4aXN0 aW5nIFJGQyBmb3IgaGFwcHkgZXllYmFsbHMuDQoNCkZvciBVRFAgd2UgaGF2ZSBubyBzb2x1dGlv biwgcGVyaW9kLiBUaGUgb25seSB3YXkgaXMgdG8gaGFuZGxlIHRoaXMgaW4gRE5TIFNSVg0KYW5k IGhhdmUgc2VwYXJhdGUgcHJpb3JpdGllcyBmb3IgSVB2NCBhbmQgSVB2NiBpbiB0aGUgb3JkZXIg dGhlIHNlcnZpY2UgbGlrZXMuDQpUaGlzIGlzIHdoeSB3ZSBoYXZlIHRlc3RlZCBETlMgU1JWIHdp dGggZHVhbCBzdGFja3MgaW4gbWFueSBTSVBpdHMgYW5kIHdyaXR0ZW4gdGhlIGRyYWZ0IGFib3V0 DQpkdWFsIHN0YWNrIGlzc3VlcyAtIG1hbnkgSVB2NCBvbmx5IGNsaWVudHMgY3Jhc2hlZCBvciBm YWlsZWQgd2hlbiB0aGUgZmlyc3QgU1JWIHByaW9yaXR5DQpkaWQgbm90IGhhdmUgSVB2NCBhZGRy ZXNzZXMgYXQgYWxsLiBUaGV5IGFsc28gY3Jhc2hlZCB3aGVuIElQdjYgd2FzIGluIHZhcmlvdXMg aGVhZGVycywNCmFzIGRvY3VtZW50ZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWtsYXRza3ktZGlzcGF0Y2gtaXB2Ni1pbXBhY3QtaXB2NC0wMw0KDQpNb3N0IG9mIHRoZXNl IHByb2JsZW1zIGFyZSBnb2luZyB0byBiZSB0cnVlIGZvciBUQ1AgSVB2NiB0b28sIGFyZW7igJl0 IHRoZXk/IEhhcHB5IEV5ZWJhbGxzIGRvZXNu4oCZdCBtYWtlIHRoZSBwcm9ibGVtIHdvcnNlLiAg SWYgdGhlcmUgYXJlIGJ1Z2d5IGltcGxlbWVudGF0aW9ucyBvdXQgdGhlcmUsIHRoaXMgaXMgc29t ZXRoaW5nIHRoYXQgeW914oCZcmUgcHJlc3VtYWJseSBlaXRoZXIgZ29pbmcgdG8gaGF2ZSB0byBo YXZlIHRoZSBpbXBsZW1lbnRlcnMgZml4LCBvciBlbHNlIGNsZWFuIHVwIHdpdGggU0JDcy4NCg0K T25lIGhhcyB0byByZW1lbWJlciB0aGF0IHRoZSBJUHY0IGFuZCBJUHY2IGFkZHJlc3MgZm9yIGEg ZHVhbCBzdGFjayBzZXJ2ZXIgbWF5IGxlYWQNCnRvIGRpZmZlcmVudCBzZXJ2ZXJzLCB0aHVzIHNl bmRpbmcgYSBVRFAgbWVzc2FnZSBhdCB0aGUgc2FtZSB0aW1lIHRvIGJvdGggbWF5IGNhdXNlDQpt dWx0aXBsZSB0cmFuc2FjdGlvbnMgYW5kIGFsbCBraW5kcyBvZiBpbnRlcmVzdGluZyBzaWRlIGVm ZmVjdHMuIChIYWRyaWVsIEthcGxhbiByZW1pbmRlZA0KbWUgb2YgdGhpcykuDQoNClNvIHRoZSBk b2N1bWVudGF0aW9uIG9uIEhhcHB5IEV5ZWJhbGxzIGluIHNpcCBpcyBwcmV0dHkgc2hvcnQ6IERv buKAmXQgdHJ5IHRoaXMgd2l0aCBVRFAuDQpTb2x2ZSB0aGUgcHJvYmxlbSBhbm90aGVyIHdheS4g KGluIGZhY3QsIG1vdmUgdG8gVENQL1RMUyBhcyBzb29uIGFzIHlvdSBjYW4gOi0pICkNCg0KSWYg c29tZW9uZSBoYXMgYSBjb29sIHNvbHV0aW9uIHRvIHRoaXMgVURQIGlzc3VlIC0gcHJlZmVyYWJs eSB3aXRob3V0IGxvb3Npbmcgb25lIHJvdW5kIHRyaXAgLQ0KSSB3b3VsZCBiZSBtb3JlIHRoYW4g aGFwcHkgdG8gaGVhciBpdCENCg0KVGhlIOKAnG1heSBsZWFkIHRvIGRpZmZlcmVudCBzZXJ2ZXJz 4oCdIGlzc3VlIGlzIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBwZXJzb24gc2V0dGluZyB1cCB0 aGUgU1JWIHJlY29yZHMgZm9yIHRoZSBTSVAgc2VydmVyLCB0aG91Z2guDQoNClNvIGl0IHNob3Vs ZCBiZSBwb3NzaWJsZSwgSSB0aGluaywgdG8gc2F5IHRoYXQgeW91IGNhbiBzZXQgdXAgRE5TIHJl Y29yZHMgZm9yIFVEUCBoYXBweSBleWViYWxscyBvbmx5IGlmIGVpdGhlciAxKSB5b3UgcGVyc29u YWxseSBjYW4gaGFuZGxlIG1lcmdlZCByZXF1ZXN0IGRldGVjdGlvbiBmb3IgYWxsIHJlcXVlc3Rz IHRvIGEgdGFyZ2V0LCBvciAyKSB5b3UgYXJlIGEgcHVyZSAzMjYxIHByb3h5IGFuZCBhbHNvIGNh biBndWFyYW50ZWUgdGhhdCB0aGVyZSBhcmUgbm8gQjJCVUFzICh0aGF0IG1vZGlmeSBGcm9tIHRh ZywgQ2FsbC1JRCwgb3IgQ1NlcSkgb3IgR2F0ZXdheXMgZG93bnN0cmVhbSBvZiB5b3UuICBJZiB0 aGlzIGlzIHRoZSBjYXNlLCB0aGVuIGZvcmtpbmcgdGhlIFNJUCByZXF1ZXN0IHRvIHRoZSB2NCBh bmQgdjYgYWRkcmVzc2VzIHdvdWxkIGFjY29tcGxpc2ggaGFwcHkgZXllYmFsbHMuDQoNCkkgZG9u 4oCZdCBrbm93IGlmIHRoaXMgaXMgYSBsYXJnZSBlbm91Z2ggc3Vic2V0IG9mIFNJUCBlbnZpcm9u bWVudHMgdG8gYmUgaW50ZXJlc3RpbmcsIHRob3VnaC4NCg0K --_000_69252B733F044FCF8C4763C7C813C2BBvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9B02E942EBA2D14994C39584B3343BA6@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIg MTIsIDIwMTYsIGF0IDU6MTAgUE0sIE9sbGUgRS4gSm9oYW5zc29uICZsdDs8YSBocmVmPSJtYWls dG86b2VqQGVkdmluYS5uZXQiIGNsYXNzPSIiPm9lakBlZHZpbmEubmV0PC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAx MiBGZWIgMjAxNiwgYXQgMjA6NTgsIERhbGUgUi4gV29ybGV5ICZsdDs8YSBocmVmPSJtYWlsdG86 d29ybGV5QGFyaWFkbmUuY29tIiBjbGFzcz0iIj53b3JsZXlAYXJpYWRuZS5jb208L2E+Jmd0OyB3 cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJcyBhbnlvbmUgY29uc2lkZXJpbmcg d3JpdGluZyB1cCB0aGUgYWN0dWFsIHVzZSBvZiBIYXBweSBFeWViYWxscyBpbiBhPGJyIGNsYXNz PSIiPg0KU0lQIGNvbnRleHQ/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRG9lcyBhbnlv bmUgaGF2ZSBhbnkgcHJhY3RpY2FsIGV4cGVyaWVuY2Ugb3Igc3VnZ2VzdGlvbnMgZm9yIHdoYXQg SEUgaW48YnIgY2xhc3M9IiI+DQpTSVAgd291bGQgYmU/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KQWZ0ZXIgZGlzY3Vzc2luZyB0aGlzIGZvciBtYW55IHllYXJz IHdpdGggbWFueSBwZW9wbGUgdGhpcyBpcyBteSBjb25jbHVzaW9uOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkZvciBjb25uZWN0aW9uIG9yaWVudGVkIHByb3RvY29scyAtIGp1c3QgcG9p bnQgdG8gZXhpc3RpbmcgUkZDIGZvciBoYXBweSBleWViYWxscy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpGb3IgVURQIHdlIGhhdmUgbm8gc29sdXRpb24sIHBlcmlvZC4gVGhlIG9ubHkg d2F5IGlzIHRvIGhhbmRsZSB0aGlzIGluIEROUyBTUlY8YnIgY2xhc3M9IiI+DQphbmQgaGF2ZSBz ZXBhcmF0ZSBwcmlvcml0aWVzIGZvciBJUHY0IGFuZCBJUHY2IGluIHRoZSBvcmRlciB0aGUgc2Vy dmljZSBsaWtlcy48YnIgY2xhc3M9IiI+DQpUaGlzIGlzIHdoeSB3ZSBoYXZlIHRlc3RlZCBETlMg U1JWIHdpdGggZHVhbCBzdGFja3MgaW4gbWFueSBTSVBpdHMgYW5kIHdyaXR0ZW4gdGhlIGRyYWZ0 IGFib3V0DQo8YnIgY2xhc3M9IiI+DQpkdWFsIHN0YWNrIGlzc3VlcyAtIG1hbnkgSVB2NCBvbmx5 IGNsaWVudHMgY3Jhc2hlZCBvciBmYWlsZWQgd2hlbiB0aGUgZmlyc3QgU1JWIHByaW9yaXR5PGJy IGNsYXNzPSIiPg0KZGlkIG5vdCBoYXZlIElQdjQgYWRkcmVzc2VzIGF0IGFsbC4gVGhleSBhbHNv IGNyYXNoZWQgd2hlbiBJUHY2IHdhcyBpbiB2YXJpb3VzIGhlYWRlcnMsPGJyIGNsYXNzPSIiPg0K YXMgZG9jdW1lbnRlZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQta2xhdHNreS1kaXNwYXRjaC1pcHY2LWltcGFjdC1pcHY0LTAzIiBjbGFzcz0iIj4NCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rbGF0c2t5LWRpc3BhdGNoLWlwdjYtaW1wYWN0 LWlwdjQtMDM8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Nb3N0IG9mIHRoZXNlIHByb2JsZW1zIGFyZSBnb2lu ZyB0byBiZSB0cnVlIGZvciBUQ1AgSVB2NiB0b28sIGFyZW7igJl0IHRoZXk/IEhhcHB5IEV5ZWJh bGxzIGRvZXNu4oCZdCBtYWtlIHRoZSBwcm9ibGVtIHdvcnNlLiAmbmJzcDtJZiB0aGVyZSBhcmUg YnVnZ3kgaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZSwgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCB5 b3XigJlyZSBwcmVzdW1hYmx5IGVpdGhlciBnb2luZyB0byBoYXZlIHRvIGhhdmUgdGhlIGltcGxl bWVudGVycw0KIGZpeCwgb3IgZWxzZSBjbGVhbiB1cCB3aXRoIFNCQ3MuPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ T25lIGhhcyB0byByZW1lbWJlciB0aGF0IHRoZSBJUHY0IGFuZCBJUHY2IGFkZHJlc3MgZm9yIGEg ZHVhbCBzdGFjayBzZXJ2ZXIgbWF5IGxlYWQ8YnIgY2xhc3M9IiI+DQp0byBkaWZmZXJlbnQgc2Vy dmVycywgdGh1cyBzZW5kaW5nIGEgVURQIG1lc3NhZ2UgYXQgdGhlIHNhbWUgdGltZSB0byBib3Ro IG1heSBjYXVzZTxiciBjbGFzcz0iIj4NCm11bHRpcGxlIHRyYW5zYWN0aW9ucyBhbmQgYWxsIGtp bmRzIG9mIGludGVyZXN0aW5nIHNpZGUgZWZmZWN0cy4gKEhhZHJpZWwgS2FwbGFuIHJlbWluZGVk PGJyIGNsYXNzPSIiPg0KbWUgb2YgdGhpcykuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K U28gdGhlIGRvY3VtZW50YXRpb24gb24gSGFwcHkgRXllYmFsbHMgaW4gc2lwIGlzIHByZXR0eSBz aG9ydDogRG9u4oCZdCB0cnkgdGhpcyB3aXRoIFVEUC48YnIgY2xhc3M9IiI+DQpTb2x2ZSB0aGUg cHJvYmxlbSBhbm90aGVyIHdheS4gKGluIGZhY3QsIG1vdmUgdG8gVENQL1RMUyBhcyBzb29uIGFz IHlvdSBjYW4gOi0pICk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiBzb21lb25lIGhh cyBhIGNvb2wgc29sdXRpb24gdG8gdGhpcyBVRFAgaXNzdWUgLSBwcmVmZXJhYmx5IHdpdGhvdXQg bG9vc2luZyBvbmUgcm91bmQgdHJpcCAtPGJyIGNsYXNzPSIiPg0KSSB3b3VsZCBiZSBtb3JlIHRo YW4gaGFwcHkgdG8gaGVhciBpdCE8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGUg4oCcbWF5IGxlYWQgdG8gZGlmZmVyZW50 IHNlcnZlcnPigJ0gaXNzdWUgaXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIHBlcnNvbiBzZXR0 aW5nIHVwIHRoZSBTUlYgcmVjb3JkcyBmb3IgdGhlIFNJUCBzZXJ2ZXIsIHRob3VnaC48L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlNvIGl0IHNob3VsZCBiZSBwb3NzaWJs ZSwgSSB0aGluaywgdG8gc2F5IHRoYXQgeW91IGNhbiBzZXQgdXAgRE5TIHJlY29yZHMgZm9yIFVE UCBoYXBweSBleWViYWxscyBvbmx5IGlmIGVpdGhlciAxKSB5b3UgcGVyc29uYWxseSBjYW4gaGFu ZGxlIG1lcmdlZCByZXF1ZXN0IGRldGVjdGlvbiBmb3IgYWxsIHJlcXVlc3RzIHRvIGEgdGFyZ2V0 LCBvciAyKSB5b3UgYXJlIGEgcHVyZSAzMjYxIHByb3h5IGFuZCBhbHNvIGNhbiBndWFyYW50ZWUg dGhhdA0KIHRoZXJlIGFyZSBubyBCMkJVQXMgKHRoYXQgbW9kaWZ5IEZyb20gdGFnLCBDYWxsLUlE LCBvciBDU2VxKSBvciBHYXRld2F5cyBkb3duc3RyZWFtIG9mIHlvdS4gJm5ic3A7SWYgdGhpcyBp cyB0aGUgY2FzZSwgdGhlbiBmb3JraW5nIHRoZSBTSVAgcmVxdWVzdCB0byB0aGUgdjQgYW5kIHY2 IGFkZHJlc3NlcyB3b3VsZCBhY2NvbXBsaXNoIGhhcHB5IGV5ZWJhbGxzLjwvZGl2Pg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSBkb27igJl0IGtub3cgaWYgdGhpcyBpcyBhIGxh cmdlIGVub3VnaCBzdWJzZXQgb2YgU0lQIGVudmlyb25tZW50cyB0byBiZSBpbnRlcmVzdGluZywg dGhvdWdoLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_69252B733F044FCF8C4763C7C813C2BBvidyocom_-- From nobody Wed Feb 17 05:43:01 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F322B1AC416 for ; Wed, 17 Feb 2016 05:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 bfO_6RldoTfy for ; Wed, 17 Feb 2016 05:42:54 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA371A039D for ; Wed, 17 Feb 2016 05:42:53 -0800 (PST) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4DB5593DE55; Wed, 17 Feb 2016 13:41:51 +0000 (UTC) From: "Olle E. Johansson" Content-Type: multipart/signed; boundary="Apple-Mail=_8FA467B2-24BE-4817-AA60-B28C0DDBA620"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 17 Feb 2016 14:42:46 +0100 Message-Id: <396C47B2-1629-4484-AB96-837B379A84BE@edvina.net> To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Olle E Johansson Subject: [sipcore] SIP outbound with one flow X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 13:43:01 -0000 --Apple-Mail=_8FA467B2-24BE-4817-AA60-B28C0DDBA620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! I am trying to parse the requirements for the number of flows in RFC = 5626 (Outbound). Section 4.2.1 says "At configuration time, UAs obtain one or more SIP URIs representing the default outbound-proxy-set. =E2=80=9C "However, a UA MUST support sets with at least two outbound proxy URIs and SHOULD support sets with up to four URIs.=E2=80=9D " If the set has more than one URI, the UAC MUST send a REGISTER request to at least two of the default outbound proxies from the set. " It seems like using one URI (one outbound proxy and one flow) is = accepted but the UA must support multiple flows. The SIP over Websockets RFC is based on Outbound but only talks about = one connection.=20 If I parse this as a requirement of at least one provided by the = outbound proxy discovery mechanism, but that any UA that claims support = of outbound must be able to handle dual flows. (and yes, there=E2=80=99s a draft on how to use DNS for OB = proxy discovery) Right? /O= --Apple-Mail=_8FA467B2-24BE-4817-AA60-B28C0DDBA620 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTcxMzQyNDdaMCMGCSqGSIb3 DQEJBDEWBBSZIOGd10J8ccfmsBR3GYUTQ67OODCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEA0xakmVN+djnuS1VJFLtVy7YJOTS5xfrwxkPktBb44xqGCI7XSi9hK202afgd18eJ5cGRaCTk Se9PDxvO1LelJq1hgWVMSCjD68v5EvM5HgLBpSmPtXS1QJOTuGXiYNB+m09OMcctybNpza5yp9HM TLCzEW2+o5XeeNaGBB1C7+8AvqRaSxn3k3WXdDiPAWRVdQE8NRYMqcA9DuLpYJZUS9As5w3QnbQl CzpXMUzpu+LG6SKEmefYz8cUgu8Hayhcp3JUgb9LSXbcHdbsBdy4FSL97sSYefn/+oEx7e6FRUw+ xcQIA6mjT5NlZKUTVEBxYpaBjuLrpwMS473KSX0CUQAAAAAAAA== --Apple-Mail=_8FA467B2-24BE-4817-AA60-B28C0DDBA620-- From nobody Wed Feb 17 06:22:04 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F101A21A8 for ; Wed, 17 Feb 2016 06:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 E8vkLqZavSue for ; Wed, 17 Feb 2016 06:22:02 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963ED1A902D for ; Wed, 17 Feb 2016 06:21:59 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-01v.sys.comcast.net with comcast id KSL31s0072GyhjZ01SMyHu; Wed, 17 Feb 2016 14:21:58 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-09v.sys.comcast.net with comcast id KSMx1s0051nMCLR01SMxmk; Wed, 17 Feb 2016 14:21:58 +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 u1HELuHY002250; Wed, 17 Feb 2016 09:21:56 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1HELuOq002245; Wed, 17 Feb 2016 09:21: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: "Olle E. Johansson" In-Reply-To: <396C47B2-1629-4484-AB96-837B379A84BE@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 17 Feb 2016 09:21:56 -0500 Message-ID: <87r3gbwh6j.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455718918; bh=pXPcM3SH8Lv6fCHTTazNO0caIQua6fuo+PFqvGhDbMw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Eemghm47jpXTLMLab4lvD6O3gT9UhhCuOnnFa4xe72D/Y04s72mCrMf4IiitF7aI7 5h5TSnmUzdwyI4MkNmT04CA0t/rV+IoVVVk5qSbEA6PN+XW7vWIT67AlW0tNoOYOkh NW3RsWAeACqjheQjn7sG/EcI+Qg6/5x3UHKe3YyCNkpOwNVeVIo5YWVu48sR8xDUkO dxA3A6W2HDEGgSpk3M6tv0eiUf4n3c4C1aTVADt172j1HI9si4xhlchmPK7zNbY5u2 c9kmAY3SvqMq8/d2xTsqF/s1Omma9F0qPKlWlVZJOg2WB3iFt30k2tE2i65GGX6Nea 51cTyYnVFjAJw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP outbound with one flow X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 14:22:03 -0000 "Olle E. Johansson" writes: > If I parse this as a requirement of at least one provided by the > outbound proxy discovery mechanism, but that any UA that claims > support of outbound must be able to handle dual flows. (and yes, > there's a draft on how to use DNS for OB proxy discovery) > > Right? I agree with you. Also, it seems to me that the mechanism is designed to support the situation where the UA is administratively configured to only establish one flow. Dale From nobody Wed Feb 17 07:39:04 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A9C1A6F87 for ; Wed, 17 Feb 2016 07:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 iBXNWxzZ2IF3 for ; Wed, 17 Feb 2016 07:39:00 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id C37CD1A6FBC for ; Wed, 17 Feb 2016 07:38:52 -0800 (PST) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C9A0B93DE62; Wed, 17 Feb 2016 15:37:49 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_A00B4432-89AA-47EA-9E2D-77AC1CB307BC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <69252B73-3F04-4FCF-8C47-63C7C813C2BB@vidyo.com> Date: Wed, 17 Feb 2016 16:38:45 +0100 Message-Id: References: <878u2p66pp.fsf@hobgoblin.ariadne.com> <330D9D8A-CB91-4E84-92F4-49A7C54090B2@edvina.net> <69252B73-3F04-4FCF-8C47-63C7C813C2BB@vidyo.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 15:39:03 -0000 --Apple-Mail=_A00B4432-89AA-47EA-9E2D-77AC1CB307BC Content-Type: multipart/alternative; boundary="Apple-Mail=_BDFDB46D-D4BA-4CB1-891E-CACBC3B391B8" --Apple-Mail=_BDFDB46D-D4BA-4CB1-891E-CACBC3B391B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Feb 2016, at 20:50, Jonathan Lennox wrote: >=20 >=20 >> On Feb 12, 2016, at 5:10 PM, Olle E. Johansson > wrote: >>=20 >>=20 >>> On 12 Feb 2016, at 20:58, Dale R. Worley > wrote: >>>=20 >>> Is anyone considering writing up the actual use of Happy Eyeballs in = a >>> SIP context? >>>=20 >>> Does anyone have any practical experience or suggestions for what HE = in >>> SIP would be? >>=20 >> After discussing this for many years with many people this is my = conclusion: >>=20 >> For connection oriented protocols - just point to existing RFC for = happy eyeballs. >>=20 >> For UDP we have no solution, period. The only way is to handle this = in DNS SRV >> and have separate priorities for IPv4 and IPv6 in the order the = service likes. >> This is why we have tested DNS SRV with dual stacks in many SIPits = and written the draft about=20 >> dual stack issues - many IPv4 only clients crashed or failed when the = first SRV priority >> did not have IPv4 addresses at all. They also crashed when IPv6 was = in various headers, >> as documented in = https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-03 = >=20 > Most of these problems are going to be true for TCP IPv6 too, aren=E2=80= =99t they? Happy Eyeballs doesn=E2=80=99t make the problem worse. If = there are buggy implementations out there, this is something that = you=E2=80=99re presumably either going to have to have the implementers = fix, or else clean up with SBCs. Oh yeah, these problems are for locating SIP servers, the stuff you do = when you build a list. It applies to all, but is critical for UDP. >=20 >> One has to remember that the IPv4 and IPv6 address for a dual stack = server may lead >> to different servers, thus sending a UDP message at the same time to = both may cause >> multiple transactions and all kinds of interesting side effects. = (Hadriel Kaplan reminded >> me of this). >>=20 >> So the documentation on Happy Eyeballs in sip is pretty short: = Don=E2=80=99t try this with UDP. >> Solve the problem another way. (in fact, move to TCP/TLS as soon as = you can :-) ) >>=20 >> If someone has a cool solution to this UDP issue - preferably without = loosing one round trip - >> I would be more than happy to hear it! >=20 > The =E2=80=9Cmay lead to different servers=E2=80=9D issue is under the = control of the person setting up the SRV records for the SIP server, = though. Yes. The reason I brought it up is that many proposals for solving this = for UDP has failed on exactly that case. >=20 > So it should be possible, I think, to say that you can set up DNS = records for UDP happy eyeballs only if either 1) you personally can = handle merged request detection for all requests to a target, or 2) you = are a pure 3261 proxy and also can guarantee that there are no B2BUAs = (that modify =46rom tag, Call-ID, or CSeq) or Gateways downstream of = you. If this is the case, then forking the SIP request to the v4 and v6 = addresses would accomplish happy eyeballs. >=20 > I don=E2=80=99t know if this is a large enough subset of SIP = environments to be interesting, though. I personally don=E2=80=99t think we should go down that road. We end up = in discussions about multiple edge proxies with SIP outbound and without = outbound and a large number of variations to SIP platform architectures. = There are so many ways one can fail, even though there is a possibility = of finding something that works. We may write =E2=80=9Cthere may be = other solutions to this problem, but this is our recommendation=E2=80=9D = to avoid falling into that can of worms. What we can state is that finding the fastest network path by using = something like Happy Eyeballs connection testing does not work over UDP. = =20 To handle UDP and dual stack clients and servers, we need to use DNS or = other configuration methods. For UDP without outbound, the server side = manages preferences in DNS. For UDP using SIP outbound a discovery = method for edge proxys may configure one IPv4 edge proxy and one IPv6 = edge proxy. Using one service DNS name with A and AAAA records will lead = to problems. Animals (including cute kittens) may be harmed. /O :-) --Apple-Mail=_BDFDB46D-D4BA-4CB1-891E-CACBC3B391B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 15 Feb 2016, at 20:50, Jonathan Lennox <jonathan@vidyo.com> = wrote:


On Feb 12, 2016, at 5:10 PM, Olle E. Johansson <oej@edvina.net> = wrote:


On 12 Feb 2016, at 20:58, Dale R. = Worley <worley@ariadne.com> wrote:

Is anyone considering writing up the actual use of Happy Eyeballs in = a
SIP context?

Does anyone have any practical experience or suggestions for what HE = in
SIP would be?

After discussing this for many years with many people this is my = conclusion:

For connection oriented protocols - just point to existing RFC for happy = eyeballs.

For UDP we have no solution, period. The only way is to handle this in = DNS SRV
and have separate priorities for IPv4 and IPv6 in the order the service = likes.
This is why we have tested DNS SRV with dual stacks in many SIPits and = written the draft about
dual stack issues - many IPv4 only clients crashed or failed when the = first SRV priority
did not have IPv4 addresses at all. They also crashed when IPv6 was in = various headers,
as documented in = https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-03=

Most of these problems are going to be true for TCP IPv6 = too, aren=E2=80=99t they? Happy Eyeballs doesn=E2=80=99t make the = problem worse.  If there are buggy implementations out there, this = is something that you=E2=80=99re presumably either going to have to have = the implementers fix, or else clean up with SBCs.
Oh = yeah, these problems are for locating SIP servers, the stuff you do when = you
build a list. It applies to all, but is critical for = UDP.

=
One has to remember that the IPv4 and IPv6 address for a = dual stack server may lead
to different servers, thus sending a UDP message at the same time to = both may cause
multiple transactions and all kinds of interesting side effects. = (Hadriel Kaplan reminded
me of this).

So the documentation on Happy Eyeballs in sip is pretty short: Don=E2=80=99= t try this with UDP.
Solve the problem another way. (in fact, move to TCP/TLS as soon as you = can :-) )

If someone has a cool solution to this UDP issue - preferably without = loosing one round trip -
I would be more than happy to hear it!

The =E2=80=9Cmay lead to different servers=E2=80=9D = issue is under the control of the person setting up the SRV records for = the SIP server, though.
Yes. The reason I = brought it up is that many proposals for solving this for UDP has = failed
on exactly that case.


So it should be possible, I think, to say that you can = set up DNS records for UDP happy eyeballs only if either 1) you = personally can handle merged request detection for all requests to a = target, or 2) you are a pure 3261 proxy and also can guarantee that there are no B2BUAs (that modify =46rom tag, Call-ID, or CSeq) or = Gateways downstream of you.  If this is the case, then forking the = SIP request to the v4 and v6 addresses would accomplish happy = eyeballs.

I don=E2=80=99t know if this is a large enough subset of = SIP environments to be interesting, = though.
I personally don=E2=80=99t think = we should go down that road. We end up in discussions about multiple = edge proxies with SIP outbound and without outbound and a large number = of variations to SIP platform architectures. There are so many ways one = can fail, even though there is a possibility of finding something that = works. We may write =E2=80=9Cthere may be other solutions to this = problem, but this is our recommendation=E2=80=9D to avoid falling into = that can of worms.

What we can state = is that finding the fastest network path by using something like Happy = Eyeballs connection testing does not work over UDP.  

To handle UDP and dual stack clients and servers, = we need to use DNS or other configuration methods. For UDP without = outbound, the server side manages preferences in DNS. For UDP using SIP = outbound a discovery method for edge proxys may configure one IPv4 edge = proxy and one IPv6 edge proxy. Using one service DNS name with A and = AAAA records will lead to problems. Animals (including cute kittens) may = be harmed.

/O :-)


= --Apple-Mail=_BDFDB46D-D4BA-4CB1-891E-CACBC3B391B8-- --Apple-Mail=_A00B4432-89AA-47EA-9E2D-77AC1CB307BC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTcxNTM4NDZaMCMGCSqGSIb3 DQEJBDEWBBTTe4bdGCzA9/nOXVhBpf+iT1VwQzCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEAGDw/rgEcRA9A31U2A2TbojRlksbxywrGhT3eckIs1aM+8SQ7tae6mNZD9/v4hkjvMUDq3djE YXRBZWnddMwwXn3F109Tfk18kWlHnWdLkA0QIj+kV+rbz3IT4SV+sGkyXQUo5BF84J9F2L+rJ4vA 6Q04FFTRjw9g1PKhpKyJ++PxGfwHKNjr0sNLxy1Lg6fdNrW78y9kiYJLysCbbVipJ0sTokfWa+U+ 3BnaFT6QtH2iJEC3sD1mlnzVBrw/0s7Wx4Tza+UShNhJX4ACh/blnMe8ClmhMjEA9pkoVfc4oCub q6aKGavDw2O0Nm7bkp2lK1S/WbZG0kNHnlsObM5UhQAAAAAAAA== --Apple-Mail=_A00B4432-89AA-47EA-9E2D-77AC1CB307BC-- From nobody Wed Feb 17 11:37:50 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627B61A1A7C for ; Wed, 17 Feb 2016 11:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 J_zcrbxQX0Lq for ; Wed, 17 Feb 2016 11:37:48 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C971A0378 for ; Wed, 17 Feb 2016 11:37:47 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-07v.sys.comcast.net with comcast id KXdh1s00258ss0Y01Xdn0D; Wed, 17 Feb 2016 19:37:47 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-14v.sys.comcast.net with comcast id KXdm1s00D1nMCLR01XdmEf; Wed, 17 Feb 2016 19:37:47 +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 u1HJbkmF016448 for ; Wed, 17 Feb 2016 14:37:46 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1HJbjBn016445; Wed, 17 Feb 2016 14:37:45 -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: sipcore@ietf.org In-Reply-To: <87a8n566rc.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 17 Feb 2016 14:37:45 -0500 Message-ID: <87vb5nunzq.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455737867; bh=NUSD6alUpkkUS51aGPz4bZFkxFiDjO8cSHiKPtNZ4OM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=JjMY2EU/0FK0YKZFOYfjauAD30D5l5T0o44664ZLdofJS7oayC/fy1ChrbHqsqCe7 CEYA1GXGJFGJkPsZhq0K82mNUSzu+n/5YaYNzFQiGort/+Ag8OOJgdv5xnAWfJ9BWI 8/Iu/16ks32w/3mWal22OZP1aqFaRorClWndpBAyljWZrBnk3d0cytPleA4vI3BR1K 9OaSqV07Hkz8MLJ6YfFckn/8bZ3G0TMng66U5Y7pTse1XVvxEsgicTP9iMxbhgJs78 G//soj8C7aR+Jnx7d+zG05VOhi9ZPGnD+T7+CngU4mMBLt01FhiHTIJwF1IcKkWT0W Jo4LKokr79CDA== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:37:49 -0000 worley@ariadne.com (Dale R. Worley) writes: > I propose modifying draft-ietf-sipcore-dns-dual-stack-03 to correct its > statement of the RFCs that it is updating. I've done these updates. The results are accessible at these URLs: https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-04.{xml,txt,html} (Actually, those URLs are the current draft of -04, and the contents will change with time.) Dale From nobody Wed Feb 17 11:57:53 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928E51ACD8A for ; Wed, 17 Feb 2016 11:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.864 X-Spam-Level: * X-Spam-Status: No, score=1.864 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_39=0.6, SPF_SOFTFAIL=0.665] autolearn=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 3i4dwyDczk1q for ; Wed, 17 Feb 2016 11:57:49 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5A41A9051 for ; Wed, 17 Feb 2016 11:57:49 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-03v.sys.comcast.net with comcast id KXxU1s0022XD5SV01Xxow1; Wed, 17 Feb 2016 19:57:48 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-20v.sys.comcast.net with comcast id KXxn1s00W1nMCLR01XxocM; Wed, 17 Feb 2016 19:57:48 +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 u1HJvl22017321; Wed, 17 Feb 2016 14:57:47 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1HJvl36017318; Wed, 17 Feb 2016 14:57:47 -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: Jonathan Lennox In-Reply-To: <0459CA0C-107B-4136-B2E1-D283AE364306@vidyo.com> (jonathan@vidyo.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 17 Feb 2016 14:57:47 -0500 Message-ID: <87mvqzun2c.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455739068; bh=1SonAELftWbRVCiBL0Fb1YfnQGccDc6Kbu3C1mVxsbU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=dOqt4HaZsFcyk1MEdXEJD+D5Pyvv1eWRgH8qOM9Lt+HlPvYNmGEgShQQYv5AzJ3R4 QJCQ3kIq2mOfLiTEQ5TQBL41JHKP1FgDSy7Ju2uo9GqaAP5N1dU5+rkEjPK4az7UJp OyOAzkVit8RRgQswd5PQSWcBJnaKIGdMeqIbHi5zzMfaIyKG4Lkh3gJLn5FN6gcabi Zkw8FnmobVtPOq0pBUef9WaKIA0+4uDUlOQyQP6HQzO/I458QBBkB+pTN8Wp7E9iJY muh3nbRH5gAgo+tVkbU4L58VJjVIngMVsFLm5jjtbRUWOVGxQollGsJmsXr4ddXDVq KFXR08vbhzGMg== Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] Redundant requests (was: Happy Eyeballs for SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:57:50 -0000 Jonathan Lennox writes: > If parallel forking worked, forking to the v4 and v6 addresses (with > the usual timing rules Happy Eyeballs advises) would seem to do > exactly what we want -- 3261's Merged Request rules would take care of > the duplicated requests. > > Unfortunately, the world of B2BUAs largely breaks parallel forking. B2BUAs do break parallel forking, but even without them, parallel forking doesn't work in all cases. Consider this case that I ran into in the wild: UA A Proxy 1 Proxy 2 UA B | | | | | sip:B | | | |-------------->| | | | | | | | 100 | | | |<--------------| | | | | sip:B;transport=UDP | | |-------------->| | | | | | | | 100 | | | | X<--------| | | | | | | | | sip:1.1.1.1 | | | |-------------->| | | | | | | | 180 Ringing | | | |<--------------| | | | | Since the UDP transport failed, Proxy 1 retries with TCP: | | sip:B;transport=TCP | | |-------------->| | | | | | | | 100 | | | |<--------------| | | | | | | | | sip:1.1.1.1 | | | |-------------->| | | | | | | | 482 Merged Request voicemail | | |<--------------| server | | | | | | | | sip:voicemail | | | | |------------------------------>| | | | | | | | | 200 OK | | | | |<------------------------------| | | | | | | | 200 OK | | | | |<--------------| | | | | | | | | 200 OK | | | | |<--------------| | | | | | | | | Sence the second branch succeeded, Proxy 1 cancels the first branch, and UA B stops ringing: | | CANCEL | | | | |-------------->| | | | | | | | | | | CANCEL | | | | |-------------->| | | | | | | In this case, Proxy 1 knows to route SIP:B to Proxy 2. For Proxy 2, Proxy 1 has the URI "sip:proxy2", that is, without a transport specification. So Proxy 1 will try both TCP and UDP. The result is that an INVITE can arrive at Proxy 2 *twice*. The first instance is routed to the UAS, but the second instance is sent to the destination's voicemail. Now I think this syndrome is limited to situations where connectivity is intermittent. But it would be nice to have a mechanism whereby two copies of one request that arrive at an entity can be recognized as "redundant copies" and the second one discarded. Dale From nobody Wed Feb 17 12:11:45 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7B41A8A95 for ; Wed, 17 Feb 2016 12:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 c5lKc_dRzO3f for ; Wed, 17 Feb 2016 12:11:43 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373311A8849 for ; Wed, 17 Feb 2016 12:11:43 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-05v.sys.comcast.net with comcast id KYAW1s005516pyw01YBhad; Wed, 17 Feb 2016 20:11:41 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-08v.sys.comcast.net with comcast id KYBg1s0011nMCLR01YBgpc; Wed, 17 Feb 2016 20:11:41 +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 u1HKBddM017929; Wed, 17 Feb 2016 15:11:39 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1HKBd6q017925; Wed, 17 Feb 2016 15:11:39 -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: Jonathan Lennox In-Reply-To: <69252B73-3F04-4FCF-8C47-63C7C813C2BB@vidyo.com> (jonathan@vidyo.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 17 Feb 2016 15:11:39 -0500 Message-ID: <87k2m3umf8.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455739901; bh=sOJ+OYeaI1t8rMbjvncIoE5OktT0SS7jFHdS0vVtNKw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=nVF5O6EfDVqMjm+vUun2SOw15Aid2+7Yx6y18R38kLCkbpJblXttVpZYIYtVGabrS dOPcWGszNGPNcNDBp88JR8maVteWl62YmfwoCGLwgM9bcZiH5uBa/rcllYw1B9E5zz ROIfqV7W6gYyXpH6tl23/Fo3NPUv3gk7VSwhPnEj3oFZdA2dOZwWXru8+3fjCuMvgo eWJDRVGKGAhrE8G7FkHh3v2v0fw1MxrIEeVMNUs3EVX2Ge+zUSvDwTyMI9l5aKyJM+ LyBUc7xcdtlCNn95jTonUpx/Tiha0F73NQqCD1mgrPN2lx2dXaZF6EN2prk17J/n+D hlnoPoDPj+X4w== Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 20:11:44 -0000 It seems to me that a short form answer is "An entity can accept UDP in a dual-stack environment if the entity can assure that it (or some downstream entity) will detect merged requests." What prevents TCP from having this problem is that we expect that the sender will send SYN and then wait to receive SYN-ACK before sending the request. However, I know nothing to stop a sender from sending the packet containing the request immediately after sending the SYN packet. If a sender was to do this successively on IPv4 and IPv6, a merged request could result. ---------- In addition, the abstract Happy Eyeballs specification allows the sender to change the order in which it contacts the various transport addresses of the destination, based on the results of previous contact attempts and perhaps configured information. Strictly speaking, this is an extension of 3263, and should be documented. In a perfect world, implementors would report to us the best ways to do that and we could publish it. Dale From nobody Wed Feb 17 12:48:23 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA871B2DDD for ; Wed, 17 Feb 2016 12:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 RjfaREvU9-dk for ; Wed, 17 Feb 2016 12:48:20 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 802F81B2DDF for ; Wed, 17 Feb 2016 12:48:16 -0800 (PST) Received: from [192.168.40.17] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id F0D4893DE5F; Wed, 17 Feb 2016 20:47:13 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_FD1646B4-C0CF-495E-8CA0-066720E0ED11"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <87k2m3umf8.fsf@hobgoblin.ariadne.com> Date: Wed, 17 Feb 2016 21:48:09 +0100 Message-Id: <12689A9E-8025-4336-8043-0ED91F335468@edvina.net> References: <87k2m3umf8.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Jonathan Lennox , sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 20:48:22 -0000 --Apple-Mail=_FD1646B4-C0CF-495E-8CA0-066720E0ED11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Feb 2016, at 21:11, Dale R. Worley wrote: >=20 > It seems to me that a short form answer is "An entity can accept UDP = in a > dual-stack environment if the entity can assure that it (or some > downstream entity) will detect merged requests.=E2=80=9D Maybe, but we=E2=80=99re going down a slippery slope. REGISTER messages can be different - with two contacts in both, or an IPv4 contact in the IPv4 one and IPv6 contact in the IPv6 one. If we are going to open up for this solution, then we=E2=80=99ll end up = in a method-by- method investigation and discussion. Is it the transaction layer that handles this case - sending one request in two copies over two different flows? I would rather see this as the transaction layer selecting flow before sending one request. In any case, we need to look at how SIP Outbound can be applied here. >=20 > What prevents TCP from having this problem is that we expect that the > sender will send SYN and then wait to receive SYN-ACK before sending = the > request. However, I know nothing to stop a sender from sending the > packet containing the request immediately after sending the SYN = packet. > If a sender was to do this successively on IPv4 and IPv6, a merged > request could result. If so, then HTTP would have a problem too. I think we need to check this assumption with Dan Wing. >=20 > ---------- >=20 > In addition, the abstract Happy Eyeballs specification allows the = sender > to change the order in which it contacts the various transport = addresses > of the destination, based on the results of previous contact attempts > and perhaps configured information. Strictly speaking, this is an > extension of 3263, and should be documented. In a perfect world, > implementors would report to us the best ways to do that and we could > publish it. Right. I don=E2=80=99t think the current implementations of Happy = Eyeballs actually follow the algorithms published in the RFC. And yes, this is an extension of RFC 3263 but has to be seen in the light of the DNS SRV RFC that says that all IP-addresses for a=20 given name has to be contacted before going to the next entry. That RFC is wide open for Happy Eyeballs and doesn=E2=80=99t need any update, according to the folks in the IETF DNS directorate (which=20 I have consulted).=20 I fully agree that this document is needed. /O= --Apple-Mail=_FD1646B4-C0CF-495E-8CA0-066720E0ED11 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTcyMDQ4MTBaMCMGCSqGSIb3 DQEJBDEWBBRXRNQF094sJP0XMMuPJJec2dYJnTCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEAjeDuFgDZkceFmQsu9fjSPD6cPvm+PvN82GDDlJuFp2K7+R2KapSWQFPB4RbmUEhSadsAg+t3 oKP5Ssqut+Z+ASa5Ip5qkj/jpNlo03nOE1egum7CpQKAFmYtVPhCMNQOmBR9oyMlzwKoS8GTKfo0 k8T/90xhrc/gqNCAV/NJy1ixEzr4hVFOgcmQSsz1fabCQP3L6gLVrEjVPp4kLUbDx+V+GUDUkWrw NrN5pQb0Y9tUZsA1B0fB04DeGvkksN+Wx5e9sFYEIFeLJ2x7rvislSBwtEdldbGPcSP31Jvuo/FC fndiAiZaaddVUv84D0f+L4IsZujQ1jSqg0LD1hYjSgAAAAAAAA== --Apple-Mail=_FD1646B4-C0CF-495E-8CA0-066720E0ED11-- From nobody Thu Feb 18 08:16:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF581A8AB4 for ; Thu, 18 Feb 2016 08:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 QnDvbUngkaWY for ; Thu, 18 Feb 2016 08:16:49 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E0D1AC39D for ; Thu, 18 Feb 2016 08:16:49 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-11v.sys.comcast.net with comcast id KsFP1s0014xDoy801sGoLG; Thu, 18 Feb 2016 16:16:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-05v.sys.comcast.net with comcast id KsGn1s00S3KdFy101sGnK5; Thu, 18 Feb 2016 16:16:48 +0000 To: sipcore@ietf.org References: <87k2m3umf8.fsf@hobgoblin.ariadne.com> <12689A9E-8025-4336-8043-0ED91F335468@edvina.net> From: Paul Kyzivat Message-ID: <56C5EE6D.40106@alum.mit.edu> Date: Thu, 18 Feb 2016 11:16:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <12689A9E-8025-4336-8043-0ED91F335468@edvina.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455812208; bh=xFUIkfHhn7CJ9/4e0koQ4SqEb3WIJpBg2QMGN9J7HSQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ks4vmyAqM6N3l1UIaVGoRsSyxMHd81+/fQUVbNOZaw9kz6EF+/MOK+iOVsDQU+JNV 3uhkZz4KXmC9GDWEbx+XVSt749COiSStDFBD/06t8ySPsU3AJameQHCZj8lbGMI4Gm 7uGQ4wJPB+Ho8H1x65OzIZPoi5s/gxizqfJcXekTm0VAzMIUG2ioP2aUAsd+5/ThOP zLMcMRBM0fGT22C3Po6K6GoDmLFDIGTNMsLca46inafJ87ECmoaUeIQCWQ4uCzZrod 0hwNSAFr3QGM2OHXcd511du7tUb6s0r1DfVsQvy3164zJMfPj5Abe7h4CLGuOb61fA 47lEhRxmsCW3Q== Archived-At: Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:16:50 -0000 On 2/17/16 3:48 PM, Olle E. Johansson wrote: > Is it the transaction layer that handles this case - sending one request > in two copies over two different flows? I would rather see this as the > transaction layer selecting flow before sending one request. How can this work for UDP? How can the flow that works be selected before sending the request? (One answer is by using ICE (actually STUN connectivity checks) first. But making ICE mandatory for all SIP would be pretty radical.) Thanks, Paul From nobody Fri Feb 19 01:10:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5711B2B1C for ; Fri, 19 Feb 2016 01:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=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 anEFhUk5VsiC for ; Fri, 19 Feb 2016 01:10:06 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 48B401B2B11 for ; Fri, 19 Feb 2016 01:10:03 -0800 (PST) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6A4DA93DE54; Fri, 19 Feb 2016 09:08:57 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_A98721A5-C871-43A5-9C21-59377C1477E5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <87mvqzun2c.fsf@hobgoblin.ariadne.com> Date: Fri, 19 Feb 2016 10:09:55 +0100 Message-Id: <67C01114-A0C7-45F2-B8B5-2F9953252C1C@edvina.net> References: <87mvqzun2c.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Jonathan Lennox , sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Redundant requests (was: Happy Eyeballs for SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 09:10:08 -0000 --Apple-Mail=_A98721A5-C871-43A5-9C21-59377C1477E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My secret working group =E2=80=9CYay for SIP Outbound=E2=80=9D says that = moving to=20 flow-oriented SIP will avoid this issue. We have time when opening a flow to play around with Happy Eyeballs and thus avoid forking=20 other messages than the REGISTER, which should be forked and have separate reg-id=E2=80=99s. /O > On 17 Feb 2016, at 20:57, Dale R. Worley wrote: >=20 > Jonathan Lennox writes: >> If parallel forking worked, forking to the v4 and v6 addresses (with >> the usual timing rules Happy Eyeballs advises) would seem to do >> exactly what we want -- 3261's Merged Request rules would take care = of >> the duplicated requests. >>=20 >> Unfortunately, the world of B2BUAs largely breaks parallel forking. >=20 > B2BUAs do break parallel forking, but even without them, parallel > forking doesn't work in all cases. Consider this case that I ran into > in the wild: >=20 > UA A Proxy 1 Proxy 2 UA B > | | | | > | sip:B | | | > |-------------->| | | > | | | | > | 100 | | | > |<--------------| | | > | | sip:B;transport=3DUDP | > | |-------------->| | > | | | | > | | 100 | | > | | X<--------| | > | | | | > | | | sip:1.1.1.1 | > | | |-------------->| > | | | | > | | | 180 Ringing | > | | |<--------------| > | | | | > Since the UDP transport failed, Proxy 1 retries with TCP: > | | sip:B;transport=3DTCP | > | |-------------->| | > | | | | > | | 100 | | > | |<--------------| | > | | | | > | | | sip:1.1.1.1 | > | | |-------------->| > | | | | > | | | 482 Merged Request = voicemail > | | |<--------------| = server > | | | | = | > | | | sip:voicemail | = | > | | = |------------------------------>| > | | | | = | > | | | 200 OK | = | > | | = |<------------------------------| > | | | | = | > | | 200 OK | | = | > | |<--------------| | = | > | | | | = | > | 200 OK | | | = | > |<--------------| | | = | > | | | | = | > Sence the second branch succeeded, Proxy 1 cancels the first branch, = and > UA B stops ringing: > | | CANCEL | | = | > | |-------------->| | = | > | | | | = | > | | | CANCEL | = | > | | |-------------->| = | > | | | | = | >=20 > In this case, Proxy 1 knows to route SIP:B to Proxy 2. For Proxy 2, > Proxy 1 has the URI "sip:proxy2", that is, without a transport > specification. So Proxy 1 will try both TCP and UDP. The result is > that an INVITE can arrive at Proxy 2 *twice*. The first instance is > routed to the UAS, but the second instance is sent to the = destination's > voicemail. >=20 > Now I think this syndrome is limited to situations where connectivity = is > intermittent. But it would be nice to have a mechanism whereby two > copies of one request that arrive at an entity can be recognized as > "redundant copies" and the second one discarded. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_A98721A5-C871-43A5-9C21-59377C1477E5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTkwOTA5NTVaMCMGCSqGSIb3 DQEJBDEWBBTyigc3IAUxx5tQ3MR8RaEZRDLE+jCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEA3TwI8Qm3V+gEcrCL0z35eMC5g5fNJ7vYduBp2hxfUrlyMgboyfti/Rr/3md6G1sSVZz2Ba/q BP1PJOIefY+mfU+K2kcYCOvB1zNVxyo9qO5cZysAilloALWdWG2OIIDfLgpSMf0mlxAVawI3oUjF s6+AqjrmrcjVPl/o8L32Li4Ezq4aY4FUekFT5S+uHjt+YJc94/CilthWQD76O+418ZYbqiNDBMrs n7GgnGgyX9pWlELxVQoxyUmE5riW1lFZ2kSedQ1JvX0M+SZax3YuekzudsUPcYzSx2IWDywPL0wA cSxYYmsTWA4zL0zFKSh3mUkoi7Q7fJeuKFN837h69gAAAAAAAA== --Apple-Mail=_A98721A5-C871-43A5-9C21-59377C1477E5-- From nobody Fri Feb 19 06:51:14 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A5D1B2D0D for ; Fri, 19 Feb 2016 06:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_39=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 91BOCUJokj4l for ; Fri, 19 Feb 2016 06:51: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 A806E1A86EA for ; Fri, 19 Feb 2016 06:51:11 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1JEoxCC033441 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 19 Feb 2016 08:51:10 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: sipcore@ietf.org References: <87mvqzun2c.fsf@hobgoblin.ariadne.com> From: Robert Sparks Message-ID: <56C72BD3.2040106@nostrum.com> Date: Fri, 19 Feb 2016 08:50:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <87mvqzun2c.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Redundant requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:51:13 -0000 Dale - There's not enough in that flow to show what the problem you ran into really was. If Proxy 1 was actually being a proxy, proxy 2 would have had all the information it needed to treat that 2nd request as a merge. For the scenario to play out as you describe, Proxy 1 had to doing something more b2b like. RjS On 2/17/16 1:57 PM, Dale R. Worley wrote: > Jonathan Lennox writes: >> If parallel forking worked, forking to the v4 and v6 addresses (with >> the usual timing rules Happy Eyeballs advises) would seem to do >> exactly what we want -- 3261's Merged Request rules would take care of >> the duplicated requests. >> >> Unfortunately, the world of B2BUAs largely breaks parallel forking. > B2BUAs do break parallel forking, but even without them, parallel > forking doesn't work in all cases. Consider this case that I ran into > in the wild: > > UA A Proxy 1 Proxy 2 UA B > | | | | > | sip:B | | | > |-------------->| | | > | | | | > | 100 | | | > |<--------------| | | > | | sip:B;transport=UDP | > | |-------------->| | > | | | | > | | 100 | | > | | X<--------| | > | | | | > | | | sip:1.1.1.1 | > | | |-------------->| > | | | | > | | | 180 Ringing | > | | |<--------------| > | | | | > Since the UDP transport failed, Proxy 1 retries with TCP: > | | sip:B;transport=TCP | > | |-------------->| | > | | | | > | | 100 | | > | |<--------------| | > | | | | > | | | sip:1.1.1.1 | > | | |-------------->| > | | | | > | | | 482 Merged Request voicemail > | | |<--------------| server > | | | | | > | | | sip:voicemail | | > | | |------------------------------>| > | | | | | > | | | 200 OK | | > | | |<------------------------------| > | | | | | > | | 200 OK | | | > | |<--------------| | | > | | | | | > | 200 OK | | | | > |<--------------| | | | > | | | | | > Sence the second branch succeeded, Proxy 1 cancels the first branch, and > UA B stops ringing: > | | CANCEL | | | > | |-------------->| | | > | | | | | > | | | CANCEL | | > | | |-------------->| | > | | | | | > > In this case, Proxy 1 knows to route SIP:B to Proxy 2. For Proxy 2, > Proxy 1 has the URI "sip:proxy2", that is, without a transport > specification. So Proxy 1 will try both TCP and UDP. The result is > that an INVITE can arrive at Proxy 2 *twice*. The first instance is > routed to the UAS, but the second instance is sent to the destination's > voicemail. > > Now I think this syndrome is limited to situations where connectivity is > intermittent. But it would be nice to have a mechanism whereby two > copies of one request that arrive at an entity can be recognized as > "redundant copies" and the second one discarded. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Feb 19 08:36:40 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051C51ACDDE for ; Fri, 19 Feb 2016 08:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 U-Qavq3EEJe5 for ; Fri, 19 Feb 2016 08:36:36 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E10D1ACC83 for ; Fri, 19 Feb 2016 08:36:35 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-02v.sys.comcast.net with comcast id LGcQ1s0062D5gil01GcaQ3; Fri, 19 Feb 2016 16:36:34 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-06v.sys.comcast.net with comcast id LGcZ1s0061nMCLR01GcZiT; Fri, 19 Feb 2016 16:36:34 +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 u1JGaWoS012744; Fri, 19 Feb 2016 11:36:32 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1JGaW6b012741; Fri, 19 Feb 2016 11:36:32 -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: Robert Sparks In-Reply-To: <56C72BD3.2040106@nostrum.com> (rjsparks@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 19 Feb 2016 11:36:32 -0500 Message-ID: <878u2godwv.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455899794; bh=nZreXtS7xvdUs2ZCz2I1sfcuHeuIc26hRZe9iJ7JBAc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=bvNqmPBdXC4K9YooDnOx5DKemTQ7OI0UgaNpdWSPbJ7XjAuXb6mH3KSwoz+gr4HMy aE0WQp2CUB3hcqeUDeJkFlMK8oi6fUIsXICvZnDHSFxtbCHq7fWW51tdCLogVRY+mH H/f3bsq+jbqE+ITgo/+EpaxICX6g1ynEGHoJIuWsyxg7YVjTpHY1DrQ/e3JpzKlOIG cujhKbNe9tWE+Jc/4DK2GcoixgZMjPEIrdV4PKGkZGzh6ULvcpWe+fRf6KgWXEkyKP c1y/ZlFA9vbkOqdf+821BMFbE5BSTMkspkcLQRfEZRPfywC1jCQI1Nb1wWjrFnfP0N 6Dv1APDG41DtQ== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Redundant requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 16:36:38 -0000 Robert Sparks writes: > There's not enough in that flow to show what the problem you ran into > really was. If Proxy 1 was actually being a proxy, proxy 2 would have > had all the information it needed to treat that 2nd request as a > merge. For the scenario to play out as you describe, Proxy 1 had to > doing something more b2b like. Proxy 2 is within specification. Proxies aren't required to detected merged requests. See RFC 3261 section 16.3: Notice that a proxy is not required to detect merged requests and MUST NOT treat merged requests as an error condition. The endpoints receiving the requests will resolve the merge as described in Section 8.2.2.2. And it turns out that in a number of cases, you really don't want a proxy to detect merged requests, because the second version of an INVITE that a proxy sees may have a different request-URI (because an upstream device is forking the call to a different destination this time). And the merged-requests logic doesn't check the request-URI: 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. I can see two possible resolutions: One is that proxies do merged request detection, but include the request-URI in the comparison. The other would be to create a mechanism specifically to label and detect redundant transmissions. Of course, the latter would be entirely new, but I can construct situations where I can't see any other way to solve the problem. Dale From nobody Fri Feb 19 12:22:06 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6881A8897 for ; Fri, 19 Feb 2016 12:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 MQqeWuHYNZMT for ; Fri, 19 Feb 2016 12:22:03 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A401ACD4F for ; Fri, 19 Feb 2016 12:22:01 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-07v.sys.comcast.net with comcast id LLME1s0032Ka2Q501LN0wU; Fri, 19 Feb 2016 20:22:00 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-11v.sys.comcast.net with comcast id LLMz1s0071nMCLR01LMzN2; Fri, 19 Feb 2016 20:22:00 +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 u1JKLxlj023200; Fri, 19 Feb 2016 15:21:59 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1JKLwQx023196; Fri, 19 Feb 2016 15:21:58 -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: <67C01114-A0C7-45F2-B8B5-2F9953252C1C@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 19 Feb 2016 15:21:58 -0500 Message-ID: <87si0omowp.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455913320; bh=ES39RyzQOq+3qMEV/kAlxw+P2pg6ue25iDWJNFMg/tg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=hwbumpGsU2QI3ldzKpWDf20LjbIol30vSz9a+zkPewgG44mtkAAAxz0wrqzFcZORq cGoCv6ye3y+U+Wyc5ZrErRGfWiOkYXHTz3Xlm4z/tQm0nKvUXea43gM5JGa2YmyUE7 BmBj+eQGAIpGNp+ASC9zp7V8sCFC6ni6b1ulf1JGsvtsVytmOGJ87cpzucQifeV453 qccozufMz1QVLXS24CNp0+jS3u5e3s2CACRleUQAjgn4n9ENcDVbF1w3kzEdyGAOVg OyJ+ZghJ8+69EEi6eeNS/HeqjILmGboXSjQq+dpLAPmtiwNaoE0jt9ZNyu3lekluhl sSLaU/dJ14P4w== Archived-At: Cc: jonathan@vidyo.com, sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Redundant requests (was: Happy Eyeballs for SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 20:22:05 -0000 "Olle E. Johansson" writes: > My secret working group "Yay for SIP Outbound" says that moving to > flow-oriented SIP will avoid this issue. We have time when opening a > flow to play around with Happy Eyeballs and thus avoid forking > other messages than the REGISTER, which should be forked and > have separate reg-id's. As long as the sender waits to receive the SYN-ACK before sending the request, then sticking to flow-oriented SIP should fix the problem. I am considering whether we want to introduce a merged requests rule for proxies. It would be much the same as for UASs, except that it would require that the request-URI match as well as the From tag, Call-ID, and CSeq. That would allow multiple copies of a request to be sent on one hop through different transports without having to worry about races between the copies. Dale From nobody Tue Feb 23 06:50:41 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 5B6761B3086; Tue, 23 Feb 2016 06:50:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160223145038.10810.46616.idtracker@ietfa.amsl.com> Date: Tue, 23 Feb 2016 06:50:38 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-dns-dual-stack-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 14:50:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Authors : Olle E. Johansson Gonzalo Salgueiro Vijay Gurbani Dale R. Worley Filename : draft-ietf-sipcore-dns-dual-stack-04.txt Pages : 9 Date : 2016-02-23 Abstract: RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying Happy Eyeballs to SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-dns-dual-stack-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-dns-dual-stack-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 23 07:40:20 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259151B2C92 for ; Tue, 23 Feb 2016 07:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 WAzzXsi7qgVq for ; Tue, 23 Feb 2016 07:40:16 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A0F1B2EEB for ; Tue, 23 Feb 2016 07:40:15 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-12v.sys.comcast.net with comcast id Mrfq1s00X29Cfhx01rgFVQ; Tue, 23 Feb 2016 15:40:15 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-03v.sys.comcast.net with comcast id Mrg91s0031nMCLR01rgCDl; Tue, 23 Feb 2016 15:40:15 +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 u1NFe5nH029902; Tue, 23 Feb 2016 10:40:05 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1NFe3O2029899; Tue, 23 Feb 2016 10:40:03 -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: <12689A9E-8025-4336-8043-0ED91F335468@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 23 Feb 2016 10:40:03 -0500 Message-ID: <87a8mrl9kc.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456242015; bh=vURIddVeGHT3rlQ5uiCjkKOZDQECziMCqo8VwTk8A2k=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=db0V0EYLeRoa5QzqYraiiBnZO0exrtTv9ZHNcFfgi+HkulLgF31wkzLefi+LNP3Wn vezuaAcTlOUWAz25U6UoLQeTf5XThfon0lHH+fc+kyERf/OlunJw3znW9H1jbkqYm7 LlVauhDCtTLBK/+4py2ucWaIplm6+zin5XMy7k9StYFKj0BMTyQ2thyasCWrvQ/YF0 bTNQVDNjfDobyyaBNs0lPQHcoigOCD3M0xhE/FrOUjDs9jRVh3nCe+YGfU60eU+SGW F3DbX4iDKyTUVOn3qrMZNukSjn6e7B69lBkv0Rh4YUxvW9hZUa/iRmUprLFDKQ9Y9a 753dWdz3JZTtQ== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 15:40:18 -0000 "Olle E. Johansson" writes: >> It seems to me that a short form answer is "An entity can accept UDP in a >> dual-stack environment if the entity can assure that it (or some >> downstream entity) will detect merged requests." > Maybe, but we're going down a slippery slope. REGISTER messages > can be different - with two contacts in both, or an IPv4 contact in the > IPv4 one and IPv6 contact in the IPv6 one. I don't think I understand you -- if the UA sends REGISTER requests with different contacts intended to maintain concurrent registrations, the requests will have different Call-Ids. Dale From nobody Tue Feb 23 07:44:55 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CC91B3131 for ; Tue, 23 Feb 2016 07:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 2ew3i1LrSlNy for ; Tue, 23 Feb 2016 07:44:52 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156521B2FFD for ; Tue, 23 Feb 2016 07:44:52 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-04v.sys.comcast.net with comcast id Mrko1s00153iAfU01rkq6N; Tue, 23 Feb 2016 15:44:50 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-10v.sys.comcast.net with comcast id Mrkp1s00N1nMCLR01rkqhi; Tue, 23 Feb 2016 15:44:50 +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 u1NFinmw030148 for ; Tue, 23 Feb 2016 10:44:49 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1NFinPd030145; Tue, 23 Feb 2016 10:44:49 -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: sipcore@ietf.org In-Reply-To: <20160223145038.10810.46616.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 23 Feb 2016 10:44:49 -0500 Message-ID: <877fhvl9ce.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456242290; bh=F54G3HgtaNsWDWT2feWNRfBbsWARZS8FssxRAtkwB/s=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=X8INDw/f/YKCV8kt5OJl5cyLzh4oKoI6HEp7Gp8TXlzYMcduhyGLqsydnwwD4qaaF j7GUoitkRhfiL0dBhlG89riAf5V4xFb7TmB6Y2kJ4xT0DkFcHYqqMzR/x2C8WQjvVI /7PQ43TmBVfi9jImq4QpzcqYFsmWFX036i2ksdZFgzqJd+JmfrzlOEUmthJI1htFhw RDvmJ25mt4tPtuyUiAOH7X8JK0GF2APVRBkC20Z/HqG3SCPjjpUolTXaU0LXWiHZQ7 dJOad0MVSH/0xyTVHsQOp9K3ku2U4dRyEOQ42CbrC7Ftk2aqCNoh27Z7cHhToA55GZ V3Hax8Lp5bXMg== Archived-At: Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 15:44:54 -0000 Since nobody has offered any comments, I've submitted draft-ietf-sipcore-dns-dual-stack-04. I think this draft is ready for WGLC, as I know of no open issues (within its narrow scope). Comments? Dale From nobody Tue Feb 23 09:08:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA2B1B36A6 for ; Tue, 23 Feb 2016 09:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 2X2qCV5yZ41o for ; Tue, 23 Feb 2016 09:08:15 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4E61B36A0 for ; Tue, 23 Feb 2016 09:08:15 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-02v.sys.comcast.net with comcast id Mt7d1s0042LrikM01t8EYe; Tue, 23 Feb 2016 17:08:14 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id Mt8D1s00c1nMCLR01t8E9w; Tue, 23 Feb 2016 17:08: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 u1NH8DCm002591 for ; Tue, 23 Feb 2016 12:08:13 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1NH8DgN002588; Tue, 23 Feb 2016 12:08:13 -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: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 23 Feb 2016 12:08:13 -0500 Message-ID: <87d1rnjqwy.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456247294; bh=zfbK8mPT/q1I1CisC1ymkG3NK7g9p9fc9TWhqW8UWlM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=CzaDOQ9y+gbaeh26nDoREuBwFdLuhhodKZDiYGykAS42kynkMQVj97thpUsfiEOzn OFrU0+lzT3QFiN7W8azZnB40xYf3shFj9ahlCs/1O6gYDBk9o4P6i2CoUpKu5n+FfH 5RqE/0lXmrbUZd8P4vOBi9qoCBmHRB7sx+vk/rKbxXucwD5hI5/RXuPopvAvzzGqXa 1+//0fH4YYqPnQvD+ET2Kv3WsAUxYtx+cAgV35IaytxSPfBbGVy1Fvsc6AScA74oIP eyzkewA1I4eTM5mzlGbnAQ+7qWXsA8BmTILMwJ6H1KyUObemkGUM5Zu6NTdIy5c6Q3 V2OrOljLmhFdg== Archived-At: Subject: [sipcore] Happy Eyeballs issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 17:08:16 -0000 It seems to me that there are two major issues to be discussed in Happy Eyeballs for SIP: 1) The sender is allowed to contact the targets in a different order than is specified by RFC 3263 (including simultaneously contacting targets). This decision can be based on (a) network diversity (if an IPv6 contact failed, it might be wise to try an IPv4 contact next) and (b) the past history of contacting these targets. To what degree should reordering be specified, and should it be permitted/recommended/required? 2) Handling the potential for multiple copies of a request to arrive at a destination via one or more of these strategies: a) Enhance the merged requests logic to reliably detect and eliminate duplicates. b) Use only connection-based protocols, waiting for connection establishment before sending a request. c) Use OPTIONS to probe connectivity before sending a request. Dale From nobody Wed Feb 24 07:43:04 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23141B36E2 for ; Wed, 24 Feb 2016 07:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 8iquDtZYlcNs for ; Wed, 24 Feb 2016 07:43:02 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 AA7C81B36B2 for ; Wed, 24 Feb 2016 07:43:01 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id g62so35713525wme.0 for ; Wed, 24 Feb 2016 07:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type; bh=YWidmvAwzyDtEiG1z5yqYdRZKIkKHY5nPK560XVRZMA=; b=Bgxy+FUuS6kSYfEC2+/uV6QqW83pZGCdWKquZrpZki4VgEcvQxPZ88elYgsCP8e4rC ruOeQRi1Zqxm8y80ICB9dH7H5jmOORId8p2d0q3ITZOmJp/QlX2WEesxrBTxamTQ7xuF +IoBVnONuy5dLWNCsi/4El6Vil3yYvvjfTNLWoielAAfchrr3yGohP8J+qHphrkHS2d6 qXqGVc4LrgY1MCQsoWvThfVBR1wblj5XlUKQfw7oD20Xg0wQnJr5h9LZrKIolVU0BeO4 owEucOd+KB09Z4tT9YgG4qEDYQt/JYYkjAWGn0bDm8TATa7kWVcbFpZ701rORFlYrbVP JOgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=YWidmvAwzyDtEiG1z5yqYdRZKIkKHY5nPK560XVRZMA=; b=hfIdBvnq1OWzaDok+favREe18mggalkwUJEQnpqXGEE8v4OpwLxVDseTOLI2WvrE1P YovjCEfC8eR4LtI4BlcP9V4I+5qA8I4arct4M051vout00BHL0OninHW3MOQRrv2pK+2 Wc4uOycHqaG/O6kYKvuWklBzUJnOxQZHTlTPlFE5aIHmIQXaL40NXapFnTIBAt3uT2G4 yv0tPOlOCIR2Bj2OtGju1okGATOmt5uXFcyaCTy4IzHMVh+fx4tOp7dFJL/NshC98kWU JqdN4q1BBXxGtAF8HWqOtmw1qhuwv+83afIYCtc2sQn/O2WHUmznNkukBEigreZkapvP pJZg== X-Gm-Message-State: AG10YOT3dBky4SLTB8akbnc8sCehyOTfE6OC7f/QRUR9NRC1rLm2ICpLYDilRAIpr0ftYk2epe4y2G6SjaDHDU8k X-Received: by 10.28.109.150 with SMTP id b22mr26557756wmi.27.1456328579986; Wed, 24 Feb 2016 07:42:59 -0800 (PST) From: Brett Tate References: <87d1rnjqwy.fsf@hobgoblin.ariadne.com> In-Reply-To: <87d1rnjqwy.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIPrhkju6bP+Po8Q4p1S2TgegMYMJ6+p7wA Date: Wed, 24 Feb 2016 10:42:58 -0500 Message-ID: <347397c1a03714a551462eee0f958111@mail.gmail.com> To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Happy Eyeballs issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 15:43:03 -0000 Hi, Concerning number 1, reordering should still be allowed based upon local policy (RFC 3261 section 8.1.2) which might include availability (RFC 3263 section 2). I currently don't have a strong opinion about discussing reordering within the draft. I assume that the draft would discuss or reference some of the things mentioned within RFC 6555 section 4 with potential SIP related adjustments. Mid-dialog requests may also be a source of interoperability issues. RFC 3261 is somewhat vague about detecting merged requests within dialog. Thus some devices return 500 (or other failure response) instead of 482 during a merged request situation. I don't recall if there are any devices that allow merged requests to be processed without detecting merged request and without rejecting the non-incremented cseq. > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley > Sent: Tuesday, February 23, 2016 12:08 PM > To: sipcore@ietf.org > Subject: [sipcore] Happy Eyeballs issues > > It seems to me that there are two major issues to be discussed in Happy > Eyeballs for SIP: > > 1) The sender is allowed to contact the targets in a different order than is > specified by RFC 3263 (including simultaneously contacting targets). > > This decision can be based on (a) network diversity (if an IPv6 contact > failed, it might be wise to try an IPv4 contact next) and (b) the past > history of contacting these targets. > > To what degree should reordering be specified, and should it be > permitted/recommended/required? > > 2) Handling the potential for multiple copies of a request to arrive at a > destination via one or more of these strategies: > > a) Enhance the merged requests logic to reliably detect and eliminate > duplicates. > > b) Use only connection-based protocols, waiting for connection establishment > before sending a request. > > c) Use OPTIONS to probe connectivity before sending a request. From nobody Fri Feb 26 02:54:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11CE1A894C for ; Fri, 26 Feb 2016 02:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 qohwT_dw8KUK for ; Fri, 26 Feb 2016 02:54:08 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 644301A894B for ; Fri, 26 Feb 2016 02:54:07 -0800 (PST) Received: from [192.168.40.17] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 0E24393DE54; Fri, 26 Feb 2016 10:52:54 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_76E24B6F-72A7-4DF2-A86F-CBAE5AF2F598"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <87d1rnjqwy.fsf@hobgoblin.ariadne.com> Date: Fri, 26 Feb 2016 11:54:01 +0100 Message-Id: References: <87d1rnjqwy.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Happy Eyeballs issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 10:54:11 -0000 --Apple-Mail=_76E24B6F-72A7-4DF2-A86F-CBAE5AF2F598 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Feb 2016, at 18:08, Dale R. Worley wrote: >=20 > It seems to me that there are two major issues to be discussed in > Happy Eyeballs for SIP: >=20 > 1) The sender is allowed to contact the targets in a different order > than is specified by RFC 3263 (including simultaneously contacting > targets). Does RFC 3263 really specify an order for *ONE* host that has multiple address records? >=20 > This decision can be based on (a) network diversity (if an IPv6 > contact failed, it might be wise to try an IPv4 contact next) and (b) > the past history of contacting these targets. >=20 > To what degree should reordering be specified, and should it be > permitted/recommended/required? Sorry, this text confused me. Are you using =E2=80=9Ccontact=E2=80=9D as = =E2=80=9CContact:=E2=80=9D header in SIP or in the role of a target as a result of a DNS lookup? >=20 > 2) Handling the potential for multiple copies of a request to arrive > at a destination via one or more of these strategies: >=20 > a) Enhance the merged requests logic to reliably detect and eliminate > duplicates. >=20 > b) Use only connection-based protocols, waiting for connection > establishment before sending a request. >=20 > c) Use OPTIONS to probe connectivity before sending a request. Which will delay a call much more=E2=80=A6=20 Let=E2=80=99s agree that we have a solution for connection-oriented = protocols. For UDP, should we really add proxy-merge stuff? Using SIP Outbound lets a device discover working flows at registration time, then the = calls will not be delayed. It=E2=80=99s an existing solution that we just need = to=20 recommend. The other way is for the service to separate DNS SRV records so there=E2=80=99s no dual stack hosts for UDP. Adding new merge rules will take a long time. Using what we already have is a faster move. :-) We may have to look into some requirements in SIP outbound to make it easier to swallow for developers, but that=E2=80=99s a different topic = that I will try to approach in a separate mail. /O --Apple-Mail=_76E24B6F-72A7-4DF2-A86F-CBAE5AF2F598 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMjYxMDU0MDFaMCMGCSqGSIb3 DQEJBDEWBBSKpAO6u3HBXinYtZI1d8no2upzDzCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEADQdAkIuCh8Du9ZTAd6QnixlwU7WBMyhlIR2c33nv7L/I1H00lebjWDBMm1+hNzsXz2Kmw71M d37Tgm3q3c2N0ZTfRag6NgftdKbSsYuTsh1fgc9Z+gncrHJTbQ9W0yPbfmmlxhM9VD0i8mVVZx2O F/dwI4nnC/nVA2S/JgN08w260/Dmw2ypkvTaRmawtoLC7QsP/yDzuI3lp6l2hp4LsKDss/3066m0 5HRVetyXcD6FA6sIkDQtghrtpssyl88XJxKAmO9lntQDhhf75X6vSfFOXhOfR2xrIbQYEA9aky9W md/daP0GrLrq3fOEEvSnUNUZryEsv3vpotEt45NcLwAAAAAAAA== --Apple-Mail=_76E24B6F-72A7-4DF2-A86F-CBAE5AF2F598-- From nobody Fri Feb 26 13:26:28 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42BB1B30AF for ; Fri, 26 Feb 2016 13:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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-YFx9inByIb for ; Fri, 26 Feb 2016 13:26:26 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F211B30AD for ; Fri, 26 Feb 2016 13:26:25 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-10v.sys.comcast.net with comcast id P9S01s0082Udklx019SR8t; Fri, 26 Feb 2016 21:26:25 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id P9SP1s00a1nMCLR019SQem; Fri, 26 Feb 2016 21:26:25 +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 u1QLQNkG028065; Fri, 26 Feb 2016 16:26:23 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1QLQM7Z028062; Fri, 26 Feb 2016 16:26:22 -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: Fri, 26 Feb 2016 16:26:22 -0500 Message-ID: <877fhrups1.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456521985; bh=B+Z4x/COMPrvs07vQ/h5u9oczUF7mZ9VVeJl2bbwJZM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ahHvwVEfa+iv6vbF6h+IoT3ihBH99+p0o1Mbfrj+gbamHuvHWzsKTyomymNiTnRnd xdeio41mjtWlXNpLFGyJ2B1Mc0w+ynzg1wA2zYs4ky9jzd9l3a3lfWVNjtgGCd7C3x hjVPE+Zxw9H1q7SZGIuC5WTz+fxmBnqCYN7KpuzCQ7vEiLEvja01SWLhA+yfKNsPi+ qm9pO+O8/MPo0VtR+Z2DYIU0whabFtUWmuQkKPMHXpmK1oxux3AIygGyY/upAUs0Up r2dA06fDEFiEZq8d1FKitajnBNHM8kcnhU6W7F/3QRzwGCzNvaIb8Q+goz8FotzMDN N5lMHh3vDF4Pg== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:26:27 -0000 "Olle E. Johansson" writes: >> 1) The sender is allowed to contact the targets in a different order >> than is specified by RFC 3263 (including simultaneously contacting >> targets). > > Does RFC 3263 really specify an order for *ONE* host that has > multiple address records? If a host name has multiple A/AAAA records, then 3263 does not prescribe an ordering. >> This decision can be based on (a) network diversity (if an IPv6 >> contact failed, it might be wise to try an IPv4 contact next) and (b) >> the past history of contacting these targets. >> >> To what degree should reordering be specified, and should it be >> permitted/recommended/required? > > Sorry, this text confused me. Are you using "contact" as "Contact:" header in SIP > or in the role of a target as a result of a DNS lookup? I meant "target address". Dale From nobody Fri Feb 26 14:02:54 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCB01B3180 for ; Fri, 26 Feb 2016 14:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 w0KPKP1XYNFv for ; Fri, 26 Feb 2016 14:02:51 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179851B3121 for ; Fri, 26 Feb 2016 14:02:51 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-12v.sys.comcast.net with comcast id PA291s00A2Qkjl901A2qXJ; Fri, 26 Feb 2016 22:02:50 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-15v.sys.comcast.net with comcast id PA2p1s00M1nMCLR01A2q8A; Fri, 26 Feb 2016 22:02:50 +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 u1QM2nIO031340 for ; Fri, 26 Feb 2016 17:02:49 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u1QM2nCW031337; Fri, 26 Feb 2016 17:02:49 -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: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 26 Feb 2016 17:02:49 -0500 Message-ID: <874mcvuo3a.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456524170; bh=VBS+JQd+gi2N4gYxUKiAjCEoyOPhbcY4UbgnLy0SF+4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=qpA4Sl9QPTQi6GDkXKmfVWayixczbjWP87agQzMO0UM6oqKD+ntF2K6odOviqbM5O ml/hqQ1Xe9GnOMGKETDZebch9sXK/yNzOjyoF/6XZ436x8sv7stC1MSNGd3rb5gzt5 hBUAJWZqrJVoLbEP3eylZWLbImUQdbUD9sEEDJnYJ3k227WhBTgFc+egKQEPEpJEwE 5xNL0Wv57gbNYwoownQgsFTaboej2M/MzZ0Wkq8H3jeA5JeZWWfbAGuwnH9CwgeaqO FpJS29hXU+xeoDjHD2OYoLVtXw5kU53K4ooMXRpD5G+Ef5wn0zuw57emcOH31lbU9v yxOUHOyGgstbw== Archived-At: Subject: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 22:02:53 -0000 This is an outline I've assembled for a Happy Eyeballs solution. I've not compared it with RFC 6555, though, which will probably reveal some more items to include. Also, I haven't looked at mid-dialog request issues. In practice, we may need to adjust/subset SIP Outbound to encourage implementors to use it. That is probably best done in another draft, though. Discussion is requested! I. When UAs communicate with their base proxies, it is recommended that they use SIP Outbound. II. RFC 3363/draft-ietf-sipcore-dns-dual-stack prescribes how a device determines a series of target addresses at which to contact a SIP URI. A device is permitted to change the order in which target addresses are contacted: A. An address to which the device has a connection may be contacted before other addresses. (E.g., if the device is using SIP Outbound.) B. An address which did not respond when the device contacted it in the past may be postponed after an address which did respond, or for which the device has no information. C. Two or more addresses may be contacted simultaneously rather than sequentially if provisions are made to avoid merged requests: 1. If both addresses use a connection-oriented protocol, for one of the addresses, the request is not sent until sending the request to the other address has failed. In particular, connections to both addresses may be initiated simultaneously, but the request cannot be sent on the one connection until sending the request on the other connection has failed. 2. The mechanism described in IV is used to avoid merged requests. D. As always, based on local policy. III. Careful revision of the timeouts involved: I haven't looked into this. Bogdan says: When comes to timers, from my experience, having the B timer to the default values (64xT1) it is not something acceptable in real platform - as you mentioned, the user experience will be a disaster in this case. For TCP -> use small timeouts for connect ; for UDP and generic SIP -> use small B timer . With these setting, the switching between 2 destination (A or AAA) will be relative fast. IV. Detecting merged requests in proxies - the "group" extension. The group extension is used to allow a device to send simultaneous redundant UDP requests to multiple addresses. (This mechanism is a special case of a mechanism I've been designing, so some of the details are determined by constraints that are not from this use case.) Assume the device is sending this request that it received: INVITE sip:biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 20 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: To the "first" target, 10.5.0.10, it sends this request: INVITE sip:biloxi.example.com SIP/2.0 Route: ;group=2 ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.1;group ------------------------------------------------------^^^^^^ Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 19 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: If this request is successfully received by 10.5.0.10, then it will be processed normally, since the Route header will be deleted by that device. Simultaneously, to the "second" target, 10.5.0.20, it sends this request: INVITE sip:biloxi.example.com SIP/2.0 Proxy-Require: group ----^^^^^^^^^^^^^^^^^^^^ Route: ;group=2 ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.2;group ------------------------------------------------------^^^^^^ Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 19 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: If the second target does not implement this extension, it rejects this request with a 420 error. The sending device will then postpone using this target until the request to the first target fails, at which time it will send a request like the request to the first target, or a request which does not use this extension. If the second target *does* implement this extension, it understands that the two requests are "equivalent", in that processing either one has "equivalent effect" (from the user's point of view), and that it should accept and process one of them and reject the other with an error (495 Grouping). We assume that by administrative control, if any targets of a SIP URI implement the "group" extension, then all of them do, and their processing is coordinated such that exactly one request of a group is processed. Of course, this is trivially true if all of the targets are addresses of the same device. A target device detects that a request falls into a group by the presence of the "group" field parameter in a Route header (which specifies its address). The group parameter designates a Via header, counting from the last Via header as number 1. The branch parameter of this header tells the identify of the request within the group; two requests that are received with the same value of this branch parameter are duplicates caused by the network. The branch parameter of the next Via header tells the identity of the group. Dale From nobody Fri Feb 26 14:33:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4852B1B31E3 for ; Fri, 26 Feb 2016 14:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 BkDOoRZSjTYd for ; Fri, 26 Feb 2016 14:33:31 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E641B2A61 for ; Fri, 26 Feb 2016 14:33:31 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with comcast id PAZP1s0022N9P4d01AZWh5; Fri, 26 Feb 2016 22:33:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id PAZV1s00R3KdFy101AZW3s; Fri, 26 Feb 2016 22:33:30 +0000 To: sipcore@ietf.org References: <874mcvuo3a.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <56D0D2B8.9090009@alum.mit.edu> Date: Fri, 26 Feb 2016 17:33:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <874mcvuo3a.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456526010; bh=/RE6P24ifH4Z4t50v6NUFFewF5KfUVLCLUaQTgSZ6kI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=I7WUJr/XpA1drHiam+ECQ+J7LCUZZ3Zxrpi3JGtv6j4THVRs5+GE/0gR/asnHmaCm hcIV8/CYLReM+qc1SKXjQFxPcTBsJMoDeQCKlVOQZaWR036oAdYRkzsPWWhuuVz3gu sxKcQ0PhZ2c3gO93DC/kBHpXao27a1k1i4rbhBFNhcr9pDfia5tbHPHzVnRg7TlV8c HzeHSdqS2sYHKTBBHP1KWG+I3yOteq0kuqIyjDSQa6Z14atKiBWvwk+zMhiqNsrNwA gFal4wfeFfFsm/AvQjBJFWwf2rgJMguzTTE9zbnZNMr3b8W7iJarVJ5+Q+IRSYkq4J LlQnpj2vys50g== Archived-At: Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 22:33:33 -0000 I only skimmed this, but ISTM that the use of proxy-require with a new option will make this nearly undeployable. Thanks, Paul On 2/26/16 5:02 PM, Dale R. Worley wrote: > This is an outline I've assembled for a Happy Eyeballs solution. I've > not compared it with RFC 6555, though, which will probably reveal some > more items to include. > > Also, I haven't looked at mid-dialog request issues. > > In practice, we may need to adjust/subset SIP Outbound to encourage > implementors to use it. That is probably best done in another draft, > though. > > Discussion is requested! > > I. When UAs communicate with their base proxies, it is recommended > that they use SIP Outbound. > > II. RFC 3363/draft-ietf-sipcore-dns-dual-stack prescribes how a > device determines a series of target addresses at which to contact a > SIP URI. A device is permitted to change the order in which target > addresses are contacted: > > A. An address to which the device has a connection may be contacted > before other addresses. (E.g., if the device is using SIP Outbound.) > > B. An address which did not respond when the device contacted it > in the past may be postponed after an address which did respond, > or for which the device has no information. > > C. Two or more addresses may be contacted simultaneously rather than > sequentially if provisions are made to avoid merged requests: > > 1. If both addresses use a connection-oriented protocol, for > one of the addresses, the request is not sent until sending > the request to the other address has failed. In particular, > connections to both addresses may be initiated simultaneously, > but the request cannot be sent on the one connection until > sending the request on the other connection has failed. > > 2. The mechanism described in IV is used to avoid merged requests. > > D. As always, based on local policy. > > III. Careful revision of the timeouts involved: > > I haven't looked into this. Bogdan says: > > When comes to timers, from my experience, having the B timer to the > default values (64xT1) it is not something acceptable in real platform - > as you mentioned, the user experience will be a disaster in this case. > > For TCP -> use small timeouts for connect ; for UDP and generic SIP -> > use small B timer . With these setting, the switching between 2 > destination (A or AAA) will be relative fast. > > IV. Detecting merged requests in proxies - the "group" extension. > > The group extension is used to allow a device to send simultaneous > redundant UDP requests to multiple addresses. (This mechanism is a > special case of a mechanism I've been designing, so some of the details > are determined by constraints that are not from this use case.) > > Assume the device is sending this request that it received: > > INVITE sip:biloxi.example.com SIP/2.0 > Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 > Max-Forwards: 20 > To: Bob > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > > To the "first" target, 10.5.0.10, it sends this request: > > INVITE sip:biloxi.example.com SIP/2.0 > Route: ;group=2 > ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.1;group > ------------------------------------------------------^^^^^^ > Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 > Max-Forwards: 19 > To: Bob > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > > If this request is successfully received by 10.5.0.10, then it will be > processed normally, since the Route header will be deleted by that > device. > > Simultaneously, to the "second" target, 10.5.0.20, it sends this request: > > INVITE sip:biloxi.example.com SIP/2.0 > Proxy-Require: group > ----^^^^^^^^^^^^^^^^^^^^ > Route: ;group=2 > ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.2;group > ------------------------------------------------------^^^^^^ > Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 > Max-Forwards: 19 > To: Bob > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > > If the second target does not implement this extension, it rejects > this request with a 420 error. The sending device will then postpone > using this target until the request to the first target fails, at > which time it will send a request like the request to the first > target, or a request which does not use this extension. > > If the second target *does* implement this extension, it understands > that the two requests are "equivalent", in that processing either one > has "equivalent effect" (from the user's point of view), and that it > should accept and process one of them and reject the other with an > error (495 Grouping). > > We assume that by administrative control, if any targets of a SIP URI > implement the "group" extension, then all of them do, and their > processing is coordinated such that exactly one request of a group is > processed. Of course, this is trivially true if all of the targets > are addresses of the same device. > > A target device detects that a request falls into a group by the > presence of the "group" field parameter in a Route header (which > specifies its address). The group parameter designates a Via header, > counting from the last Via header as number 1. The branch parameter > of this header tells the identify of the request within the group; two > requests that are received with the same value of this branch > parameter are duplicates caused by the network. The branch parameter > of the next Via header tells the identity of the group. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Feb 29 08:45:05 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C9D1B373B for ; Mon, 29 Feb 2016 08:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 msdbsydk990h for ; Mon, 29 Feb 2016 08:45:01 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id DB9811B373C for ; Mon, 29 Feb 2016 08:45:00 -0800 (PST) Received: from [192.168.40.17] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id DDB4093DE5B; Mon, 29 Feb 2016 16:43:42 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_BD585C6E-6E70-4FAC-82C8-10A0515E66A3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <877fhrups1.fsf@hobgoblin.ariadne.com> Date: Mon, 29 Feb 2016 17:44:54 +0100 Message-Id: <4231786F-AA95-47E3-A58A-4489CBB8B874@edvina.net> References: <877fhrups1.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Happy Eyeballs issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 16:45:03 -0000 --Apple-Mail=_BD585C6E-6E70-4FAC-82C8-10A0515E66A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Feb 2016, at 22:26, Dale R. Worley wrote: >=20 > "Olle E. Johansson" writes: >>> 1) The sender is allowed to contact the targets in a different order >>> than is specified by RFC 3263 (including simultaneously contacting >>> targets). >>=20 >> Does RFC 3263 really specify an order for *ONE* host that has >> multiple address records? >=20 > If a host name has multiple A/AAAA records, then 3263 does not = prescribe > an ordering. Then we=E2=80=99re back to 2782. I discussed exactly this in the meeting = with two guys from the IETF DNS directorate. We concluded that 2782 is very open for simultaneous connections, like Happy Eyeballs. It states that all = addresses found for a name (that you understand/support) shall be contacted before = you move to the next name in your list, not any order. So we should be fine. /O >=20 >>> This decision can be based on (a) network diversity (if an IPv6 >>> contact failed, it might be wise to try an IPv4 contact next) and = (b) >>> the past history of contacting these targets. >>>=20 >>> To what degree should reordering be specified, and should it be >>> permitted/recommended/required? >>=20 >> Sorry, this text confused me. Are you using "contact" as "Contact:" = header in SIP >> or in the role of a target as a result of a DNS lookup? >=20 > I meant "target address". >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_BD585C6E-6E70-4FAC-82C8-10A0515E66A3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMjkxNjQ0NTRaMCMGCSqGSIb3 DQEJBDEWBBS/u3OXZ1TK59OgKeNVKxHSYdjXqjCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEASBfdgxnn8fK+j7WYqbiWyheSPPd51HAEHFR60wdf/9CJms/wqrk/qSaQfa059G9cAfYUlfgz FQsdgxQL9ctxVi+Uoj0gE7T/5nhNr+VHANCQi22HcwVhzpzTUPvBVARvzHaciiZU5/N6sI04xhLV fdjFjYQThV/tzX/eg1D841svGu7tDCfHetSgFbi9kxdyPPm5nr4jO3PS6ynpqON8e3eB6NekcoXo rv+rdUCVvFrDvKnoX3LdKdW5caW4mv2RukgMu+UiWjl7OOGwp+E9U+6UoE6+56XV9WebeynnxkG0 rTW1+l7APqgAMsu4wMAhAqO1wmI17CqtV2EWLyd59QAAAAAAAA== --Apple-Mail=_BD585C6E-6E70-4FAC-82C8-10A0515E66A3-- From nobody Mon Feb 29 09:19:23 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F271B37F5 for ; Mon, 29 Feb 2016 09:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 ReliZEzc3U3U for ; Mon, 29 Feb 2016 09:19:20 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6046A1B37E0 for ; Mon, 29 Feb 2016 09:19:19 -0800 (PST) Received: from [192.168.40.17] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id DC1FA93DE5B; Mon, 29 Feb 2016 17:18:01 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_89B758F7-AA27-4B41-9065-2195ACCC0628"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <874mcvuo3a.fsf@hobgoblin.ariadne.com> Date: Mon, 29 Feb 2016 18:19:13 +0100 Message-Id: References: <874mcvuo3a.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 17:19:22 -0000 --Apple-Mail=_89B758F7-AA27-4B41-9065-2195ACCC0628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Feb 2016, at 23:02, Dale R. Worley wrote: >=20 > This is an outline I've assembled for a Happy Eyeballs solution. I've > not compared it with RFC 6555, though, which will probably reveal some > more items to include. >=20 > Also, I haven't looked at mid-dialog request issues. >=20 > In practice, we may need to adjust/subset SIP Outbound to encourage > implementors to use it. That is probably best done in another draft, > though. >=20 > Discussion is requested! I really think that bullet 1 should separate connection oriented = transport from the rest, which is UDP=E2=80=A6 :-) Then we=E2=80=99ll focus on UDP, because that=E2=80=99s our problem. >=20 > I. When UAs communicate with their base proxies, it is recommended > that they use SIP Outbound. Always, but especially Outbound will solve issues for UDP. >=20 > II. RFC 3363/draft-ietf-sipcore-dns-dual-stack prescribes how a > device determines a series of target addresses at which to contact a > SIP URI. A device is permitted to change the order in which target > addresses are contacted: >=20 > A. An address to which the device has a connection may be contacted > before other addresses. (E.g., if the device is using SIP = Outbound.) s/connection/flow/ >=20 > B. An address which did not respond when the device contacted it > in the past may be postponed after an address which did respond, > or for which the device has no information. >=20 > C. Two or more addresses may be contacted simultaneously rather = than > sequentially if provisions are made to avoid merged requests: Again, this only applies to UDP. >=20 > 1. If both addresses use a connection-oriented protocol, for > one of the addresses, the request is not sent until sending > the request to the other address has failed. In particular, > connections to both addresses may be initiated simultaneously, > but the request cannot be sent on the one connection until > sending the request on the other connection has failed. No, with Happy Eyeballs you determine which connection to use *BEFORE* sending any request. So this is only needed for connection-less transports. >=20 > 2. The mechanism described in IV is used to avoid merged = requests. >=20 > D. As always, based on local policy. We should only point to the relevant RFCs for how to prefer one address = family before another, not add to the list of proposals. >=20 > III. Careful revision of the timeouts involved: >=20 > I haven't looked into this. Bogdan says: >=20 > When comes to timers, from my experience, having the B timer to the=20= > default values (64xT1) it is not something acceptable in real = platform -=20 > as you mentioned, the user experience will be a disaster in this = case. >=20 > For TCP -> use small timeouts for connect ; for UDP and generic SIP = ->=20 > use small B timer . With these setting, the switching between 2=20 > destination (A or AAA) will be relative fast. For connection-oriented protocols, this is already covered by Happy = Eyeballs. For UDP, I don=E2=80=99t see how this is specific to the problem at = hand. I must have missed something. We want to avoid serial failover, not speed it up. >=20 > IV. Detecting merged requests in proxies - the "group" extension. >=20 > The group extension is used to allow a device to send simultaneous > redundant UDP requests to multiple addresses. (This mechanism is a > special case of a mechanism I've been designing, so some of the = details > are determined by constraints that are not from this use case.) >=20 > Assume the device is sending this request that it received: >=20 > INVITE sip:biloxi.example.com SIP/2.0 > Via: SIP/2.0/UDP 10.0.1.123;branch=3Dz9hG4bK77ef4c2312983 > Max-Forwards: 20 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: >=20 > To the "first" target, 10.5.0.10, it sends this request: >=20 > INVITE sip:biloxi.example.com SIP/2.0 > Route: ;group=3D2 > ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Via: SIP/2.0/UDP 10.0.1.10;branch=3Dz9hG4bKnashds8.1;group > ------------------------------------------------------^^^^^^ > Via: SIP/2.0/UDP 10.0.1.123;branch=3Dz9hG4bK77ef4c2312983 > Max-Forwards: 19 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: >=20 > If this request is successfully received by 10.5.0.10, then it will be > processed normally, since the Route header will be deleted by that > device. >=20 > Simultaneously, to the "second" target, 10.5.0.20, it sends this = request: >=20 > INVITE sip:biloxi.example.com SIP/2.0 > Proxy-Require: group > ----^^^^^^^^^^^^^^^^^^^^ > Route: ;group=3D2 > ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Via: SIP/2.0/UDP 10.0.1.10;branch=3Dz9hG4bKnashds8.2;group > ------------------------------------------------------^^^^^^ > Via: SIP/2.0/UDP 10.0.1.123;branch=3Dz9hG4bK77ef4c2312983 > Max-Forwards: 19 > To: Bob > From: Alice ;tag=3D1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: >=20 > If the second target does not implement this extension, it rejects > this request with a 420 error. The sending device will then postpone > using this target until the request to the first target fails, at > which time it will send a request like the request to the first > target, or a request which does not use this extension. >=20 > If the second target *does* implement this extension, it understands > that the two requests are "equivalent", in that processing either one > has "equivalent effect" (from the user's point of view), and that it > should accept and process one of them and reject the other with an > error (495 Grouping). >=20 > We assume that by administrative control, if any targets of a SIP URI > implement the "group" extension, then all of them do, and their > processing is coordinated such that exactly one request of a group is > processed. Of course, this is trivially true if all of the targets > are addresses of the same device. >=20 > A target device detects that a request falls into a group by the > presence of the "group" field parameter in a Route header (which > specifies its address). The group parameter designates a Via header, > counting from the last Via header as number 1. The branch parameter > of this header tells the identify of the request within the group; two > requests that are received with the same value of this branch > parameter are duplicates caused by the network. The branch parameter > of the next Via header tells the identity of the group. I would be happy if this was separate work, not part of this draft. The migration to IPv6 needs to be easy, and asking for dual simultaneous connections over TCP/TLS is big enough for many implementations. = Implementing a whole new proxy merge scheme in the same document will in my view make = it as ignored as SIP outbound currently is=E2=80=A6 I would prefer is this = document was based on as much existing documents as possible so it can be fast-tracked. I think UDP can survive by=20 a) recommending SIP outbound - setting up a working flow *before* the = call and/or b) recommending server side DNS SRV separation, one prio per address = family, no dual stack hosts for UDP This is stuff that can be implemented quickly and can be tested at SIPit = this fall. A new merge extension may be tested at SIPit two or four years from = now=E2=80=A6 Sorry for not being optimistic=E2=80=A6 /O >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_89B758F7-AA27-4B41-9065-2195ACCC0628 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAw/zvTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMTIxODA1NTZaFw0x NjEyMTExODA1NTZaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEN BQADggIBAHxgZcQ5PWVh9S+4jVooejp71WhkpFOLJl9T7cYQ5jjHYJK4A5QXcByNhN42oL8grx7a nIsOxDQf93zEx4y+t2QQpvh4LssrbUpDg5UVCtDWPKRxnnAGIJ+uHx+zUUleQ3rdzGGkk4lOVw1o oeIoFt83a4a32iTP8RODaS1O2K38npQPX0Ggy1bpcVUXn19w+mCMueMg6yfvkv0n7URJ7jNzANvE 5OAtzWJt/eVn3czf0KJSvzN74pS/+3K0hPw8Wl/TrdBUtpul2x5gVH34djA/kW3uWfW18bC82hxc OerzO/XOE1VBRlqFns0OmSDL9MA7BgJ7Qx5dgjElbIcojo1v9Uk/bNF04qMDwTrbWCKvxaRx3crY R4LTzFfpnZVrqmXBGUXZBsbQHxeSBxAev0A7D1krDU57sIKnKdkW4n16dZMEnqQL3YcwYlUHmrWK KZO8M295MQ8V6e7Q5h+iRvX00TtWt0c0UBpAKeZbpOw0nTwtsjp+7SEVxefzcOXSxxlrGLuipEU9 rKPNFBDUpqmipi+x6Dfb4Jv0bEn1rLXidlj9x2sY0IJbU38qDCjL2IVSMiV5E7p8tlIExJ7JKuKk 6sgNGFDxvc6VqHxQh9g8FgpDE0XF+4PEcn6Lq5VL603KhEc/aJw+mtXrhFEWXulwYphnsxU9/rih gG8S7EXjMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw/zvTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMjkxNzE5MTRaMCMGCSqGSIb3 DQEJBDEWBBTzGV6/URsjG58KnCH+lVaS/ucr0TCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMP870wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMP870wDQYJKoZIhvcNAQEBBQAE ggEASGER2zIeYYo/FHCjCr3XYgFMNiXz2e14tE00RxNpA8Z9OfmRSrJ55f3SEu3mUQRfQmuKF6l7 US1sBX4gJZOjNbo9ORP9L0sJ70OFCzFU4mh94E8+gZvZQyMe4+BYXISBU58R0B5axfLm20zsCCNt nMfUDGRpHsVrrrb96WLCAdz+w663gUGgSY8YrpOFH4xB9OMgNN0dESKgfHOqp+FLb7lmxuDi56Sz uxcXiPry8gfbz+MngYF0IFp4IjD5GL73k7G40b4V2znEeYBJtUd9Cw5MmNQYFw69PDTEv6lN5OTw IfzRijYRGtfML1Qs7IVTpzuDHzBvnTu5x4ELiv6t7wAAAAAAAA== --Apple-Mail=_89B758F7-AA27-4B41-9065-2195ACCC0628-- From nobody Mon Feb 29 12:41:35 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36D01B3B8D for ; Mon, 29 Feb 2016 12:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 YRSgM2zichfe for ; Mon, 29 Feb 2016 12:37:09 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5226B1B3B9C for ; Mon, 29 Feb 2016 12:37:07 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-03v.sys.comcast.net with comcast id QLb61s00627uzMh01Ld6pW; Mon, 29 Feb 2016 20:37:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-02v.sys.comcast.net with comcast id QLd61s0063KdFy101Ld6T1; Mon, 29 Feb 2016 20:37:06 +0000 To: sipcore@ietf.org References: <874mcvuo3a.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <56D4ABF1.5060400@alum.mit.edu> Date: Mon, 29 Feb 2016 15:37:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456778226; bh=DgPcXlEob+hQLiXgOp9X9dnLLiEXPYPcKQK6mV5bKx4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kqa2XnR4vZQQtOPOyO/v77tCzmgJjUFUOVqQEreQ/pYOYwsha5n7C08E8T5cNQZ82 C4onTfV/DohQvPCnah8gHk+iRlLZBl122TUGGVr+vMBjhI1YzfVnFsTli+UExmShSe A1cl3oVAWivJWjKnGEJrYatKP+lKCLxB/fv9uRmQSMP4E/swUdMsw4p4FRu0KsB/H8 A2BfEqklvHmnQDfcfyO8IzGyI1i+1FC9GeXApI8XWd50AmwTAjo177CuSDOzwkNJfL oaVRKW7S2bmLxnJ1oNHmoFQmfVg2R+wLtaERVlrPITiweatyzjtrH8JGHZ27zDCECx AxnJ82l8sKQVg== Archived-At: Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 20:37:11 -0000 >> A target device detects that a request falls into a group by the >> presence of the "group" field parameter in a Route header (which >> specifies its address). The group parameter designates a Via header, >> counting from the last Via header as number 1. The branch parameter >> of this header tells the identify of the request within the group; two >> requests that are received with the same value of this branch >> parameter are duplicates caused by the network. The branch parameter >> of the next Via header tells the identity of the group. > I would be happy if this was separate work, not part of this draft. > > The migration to IPv6 needs to be easy, and asking for dual simultaneous > connections over TCP/TLS is big enough for many implementations. Implementing > a whole new proxy merge scheme in the same document will in my view make it as > ignored as SIP outbound currently is… I would prefer is this document was based > on as much existing documents as possible so it can be fast-tracked. > > I think UDP can survive by > a) recommending SIP outbound - setting up a working flow *before* the call > and/or > b) recommending server side DNS SRV separation, one prio per address family, > no dual stack hosts for UDP > > This is stuff that can be implemented quickly and can be tested at SIPit this fall. > A new merge extension may be tested at SIPit two or four years from now… > Sorry for not being optimistic… Why do we need to have a solution for UDP? ISTM it is generally understood that UDP for sip was a mistake, or perhaps just a tactical optimization in the early days. And now we are encouraging widespread of TLS too. Why would we want to ask people to commit additional development resources to patching up UDP issues? So why don't we treat this as yet another reason to deprecate UDP, or at least treat it with benign neglect? This will give people one more nudge to move on. Thanks, Paul