From nobody Mon Jan 11 13:32:25 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 2E11B1A92E2 for ; Mon, 11 Jan 2016 13:32:25 -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, 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 rozjWbneBmv9 for ; Mon, 11 Jan 2016 13:32:24 -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 EA6531A92E1 for ; Mon, 11 Jan 2016 13:32:23 -0800 (PST) Received: from mutabilis-2.local (pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0BLVxeE075413 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Jan 2016 15:31:59 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187] claimed to be mutabilis-2.local To: "Olle E. Johansson" , Gonzalo Salgueiro , "Vijay K. Gurbani" , SIPCORE From: "A. Jean Mahoney" Message-ID: <56941F4E.10206@nostrum.com> Date: Mon, 11 Jan 2016 15:31:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Going forward with draft-ietf-sipcore-dns-dual-stack 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, 11 Jan 2016 21:32:25 -0000 Hi all, As chairs, we are looking to see if can restart the work on this WG item. For the draft to go forward we need the authors and the working group to commit to working on and reviewing it. There's outstanding feedback that needs to be incorporated into this expired draft: https://mailarchive.ietf.org/arch/msg/sipcore/bvqJHA6kLHOE0GamFfeJjN450Qc https://mailarchive.ietf.org/arch/msg/sipcore/LRdKLi9X2bn8bePrddQ4Feh5Ie0 https://mailarchive.ietf.org/arch/msg/sipcore/AgN1Os5ktSrCNLoymu2HzxDQrmo Authors, can one of you commit to updating the draft with the above feedback? Thanks! Jean, as chair From nobody Wed Jan 13 13:25: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 5CCC51A01AE for ; Wed, 13 Jan 2016 13:25:56 -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, 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 yL-f9FKuOOIV for ; Wed, 13 Jan 2016 13:25:55 -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 16B791A01A9 for ; Wed, 13 Jan 2016 13:25:55 -0800 (PST) Received: from mutabilis-2.local (pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0DLPenk097931 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Jan 2016 15:25:41 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187] claimed to be mutabilis-2.local To: "Olle E. Johansson" , Gonzalo Salgueiro , "Vijay K. Gurbani" , SIPCORE , "Dale R. Worley" References: <56941F4E.10206@nostrum.com> From: "A. Jean Mahoney" Message-ID: <5696C0D4.5040807@nostrum.com> Date: Wed, 13 Jan 2016 15:25:40 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56941F4E.10206@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Going forward with draft-ietf-sipcore-dns-dual-stack 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, 13 Jan 2016 21:25:56 -0000 Hi all, Dale Worley will be taking up the pen on the draft with the authors' and chairs' thanks. The original authors will still be engaged and have offered assistance if needed. In addition to the feedback below, Dale has identified some open issues and questions that he'll be bringing to the list soon. Thanks! Jean On 1/11/16 3:31 PM, A. Jean Mahoney wrote: > Hi all, > > As chairs, we are looking to see if can restart the work on this WG > item. For the draft to go forward we need the authors and the working > group to commit to working on and reviewing it. > > There's outstanding feedback that needs to be incorporated into this > expired draft: > > https://mailarchive.ietf.org/arch/msg/sipcore/bvqJHA6kLHOE0GamFfeJjN450Qc > https://mailarchive.ietf.org/arch/msg/sipcore/LRdKLi9X2bn8bePrddQ4Feh5Ie0 > https://mailarchive.ietf.org/arch/msg/sipcore/AgN1Os5ktSrCNLoymu2HzxDQrmo > > Authors, can one of you commit to updating the draft with the above > feedback? > > Thanks! > > Jean, as chair > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jan 14 10:44: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 D96031A8ADF for ; Thu, 14 Jan 2016 10:44:33 -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, 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 A_JHSRD-GOMY for ; Thu, 14 Jan 2016 10:44:32 -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 C3BD61A1A56 for ; Thu, 14 Jan 2016 10:44:31 -0800 (PST) Received: from mutabilis-2.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 u0EIiUUC047147 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 14 Jan 2016 12:44:30 -0600 (CST) (envelope-from mahoney@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 mutabilis-2.local To: SIPCORE From: "A. Jean Mahoney" Message-ID: <5697EC8E.5010102@nostrum.com> Date: Thu, 14 Jan 2016 12:44:30 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] WG session for sipcore in Buenos Aires? 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, 14 Jan 2016 18:44:34 -0000 Hi all, Please think about sipcore topics (current and/or future) that we could discuss in a WG session in Buenos Aires, and bring them to the mailing list by the beginning of February. Thanks! Jean From nobody Fri Jan 22 19:31:03 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 891131B3072; Fri, 22 Jan 2016 19:31:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160123033100.6033.46928.idtracker@ietfa.amsl.com> Date: Fri, 22 Jan 2016 19:31:00 -0800 Archived-At: Cc: ben@nostrum.com, aroach@mozilla.com, sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] sipcore - New Meeting Session Request for IETF 95 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: Sat, 23 Jan 2016 03:31:00 -0000 A new meeting session request has just been submitted by Adam Roach, a Chair of the sipcore working group. --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 100 Conflicts to Avoid: First Priority: avtcore, perc, avtext, rtcweb, mmusic, stir, webpush, xrblock, netvc Special Requests: --------------------------------------------------------- From nobody Sun Jan 24 16:23: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 8201A1B35F5 for ; Sun, 24 Jan 2016 16:23:51 -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 Ew9E3RmT2XJH for ; Sun, 24 Jan 2016 16:23:50 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB571B35F3 for ; Sun, 24 Jan 2016 16:23:46 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-05v.sys.comcast.net with comcast id A0NG1s0022D5gil010PmrC; Mon, 25 Jan 2016 00:23:46 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-06v.sys.comcast.net with comcast id A0Pl1s0041nMCLR010PlFt; Mon, 25 Jan 2016 00:23:45 +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 u0P0NgwR012368 for ; Sun, 24 Jan 2016 19:23:42 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0P0NgOB012365; Sun, 24 Jan 2016 19:23:42 -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: Sun, 24 Jan 2016 19:23:42 -0500 Message-ID: <87lh7ebj75.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453681426; bh=bDWE03JYQKu8NvYkJHJfUWAOoaEb/2TJepXEFjRL6Ts=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=tBXpzSqbFmDKp2zcWhUNhaW1WOascpv6sk9ofaeegIbfYfn3h/b2v0qjKUt9hN+mz EAVW0oWML7UXgrEX0TkaScz463MCJ/BpEw2VdjXVuAD+l6/8xnfTow8m3t8zRFa3Gv uWZUIoIkhP8MxJ7NLNmZ/yhqfMzB5UNE5KAr2hY+aZb63d5/fdncsRQSYBiRqJpO0I zo6ldrDuojNMhO4YWrdjYteLguaxwzay8GQb8GT8gikDI35PFU9fHCmFsWBuCdd6CU ee/hWnZTVOfJ69mXqihvFlIMmlYNXU/gNYyi3Mkoq78OfFPfwxQ6JjHugFpJup6yBF US8jYJ1JTxUxw== Archived-At: Subject: [sipcore] Going forward with draft-ietf-sipcore-dns-dual-stack 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, 25 Jan 2016 00:23:51 -0000 I've been appointed the editor of draft-ietf-sipcore-dns-dual-stack. In the next few days, I'll be making updates in the next few days and responding to outstanding reviews. Dale From nobody Sun Jan 24 16:43: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 E285F1B3636 for ; Sun, 24 Jan 2016 16:43:51 -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 o8Hfuz8ssTge for ; Sun, 24 Jan 2016 16:43:50 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B671F1B3637 for ; Sun, 24 Jan 2016 16:43:50 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-03v.sys.comcast.net with comcast id A0jk1s00156HXL0010jqMe; Mon, 25 Jan 2016 00:43:50 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-12v.sys.comcast.net with comcast id A0jp1s0041nMCLR010jpDW; Mon, 25 Jan 2016 00:43:49 +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 u0P0hkRN013182 for ; Sun, 24 Jan 2016 19:43:46 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0P0hkBC013179; Sun, 24 Jan 2016 19:43:46 -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 References: <17960B77-D25A-4135-844E-51FCEDFC51D0@edvina.net> Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 24 Jan 2016 19:43:46 -0500 Message-ID: <87h9i2bi9p.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453682630; bh=ZMAhmv5WTqT9pJemM8Yf2JRk6whHbjm0cpc1wapXW+c=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=rDNVXbhBh4n02urNP4+XA0yGBo0cpQo0J/oo7sCQFZBNzdwdWZA/sUR+zFAY9bL2U G1HdC4M2plrRs5PCbtmQqjpd3gmwZciXCvCQNg9viA3AA3eZhXt5TWd756Bd75JF2E A0gfSXFRSUjpNEnwUdiN1Hvg78i1ofPLR1KX3O2fP/ijI8Fzrb6Ewj1JcvIFWguSL0 WkVjGNlYsFyPmrRYxuWUKMRKmURcECB4NN/aHatyoxHil3UNGOshV6Gy7pmx3seBoH 4AjuMMpwMLzJO/GKr4GmZtXxqmMPm53j33/vyNOOqUUt/8BLE6J0md69Lt3SH3S0ED U+GeYIaMc4+ag== Archived-At: Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack: Simon Perreault's review 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, 25 Jan 2016 00:43:52 -0000 I've edited in a number of Simon's changes. However: Simon Perreault writes: > - It's not clear to me whether Section 4.1 advocates parallel connections > or not. Is Happy Eyeballs to be applied or not? Or are we not recommending > one way or another? This needs to be made more explicit. At this point, the relationship between this draft and Happy Eyeballs is not clear to me. My expectations of a combination of 3263 and "Happy Eyeballs" are: 1. A client must look up both A and AAAA records for a destination in all situations where it looks up a destination. 2. A client whose initial attempt to reach a destination via IPv6 fails should quickly attempt to reach it via IPv4, regardless of whether the destination has declared that it prefers a second IPv6 address to its IPv4 address (RFC 6555 section 4 item 1). 3. A client must remember whether attempts to reach a destination via IPv6 have failed in the past, and if so, prefer IPv4 to reach it (RFC 6555 section 4). Item 1 does not seem to me to be normative. RFC 3263 is a mess to read, but any sensible integration of it with the RFCs it references seems to me to imply that a SIP client (as RFC 3263 calls the sender) must look up address records for all address families that it supports (in any of the 3 situations in which it looks up address records). Items 2 and 3 seem to me to be the essence of "Happy Eyeballs", and they are normative changes to RFC 3263/2782, since when SRV records are involved, the SRV records currently declare the order which the client MUST use the specified addresses. > - The guidance in Section 4.2 could benefit from stronger normative > language: > > When indicating address family preference through SRV, IPv4-only and/ > or IPv6-only clients should be prepared to handle SRV record sets > that don't resolve into an ip address in the address family used by > that client. In such a case, the client should simply proceed to the > next priority and try the hostnames in the alternate address family. > > Suggestion: s/should/MUST/g > > And please remove the "and try the hostnames in the alternate address > family." part, which makes no sense (a hostname cannot be "in an address > family"). Actually, this paragraph should be moved out of section 4.2, because 4.2 is about how a client should indicate how it prefers to be contacted, whereas this text is about *all* clients, that resolution may produce addresses the client doesn't support, and it must be prepared to ignore those addresses. > minor > ===== > > - Should this draft formally update RFC 3263? Assuming that we're actually incorporating the Happy Eyeballs processing, it updates RFC 3263: - In regard to URIs that do not invoke SRV records, Happy Eyeballs processing provides more constraints on the sequence in which resolved addresses are used. As a tightening of the requirements of RFC 3263, it is an update thereof. - in regard to URIs that invoke SRV records, the sequence specified by the SRV records can be overridden. This contravenes RFC 2782 as incorporated by RFC 3263, and so is an update. However, Olle says: > At one point it did, but the wg - especially Cullen Jennings - did not > accept it. I personally still think it's needed. How do we resolve this? Dale From nobody Sun Jan 24 17:09: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 1A18F1B366B for ; Sun, 24 Jan 2016 17:09: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 Rculr4mjmYnj for ; Sun, 24 Jan 2016 17:09:15 -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 E52E81B366A for ; Sun, 24 Jan 2016 17:09:14 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-01v.sys.comcast.net with comcast id A18t1s0032Bo0NV0119Dej; Mon, 25 Jan 2016 01:09:13 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-05v.sys.comcast.net with comcast id A19D1s0021nMCLR0119DDV; Mon, 25 Jan 2016 01:09:13 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u0P19A3A014231 for ; Sun, 24 Jan 2016 20:09:10 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0P19AOj014228; Sun, 24 Jan 2016 20:09:10 -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: Sun, 24 Jan 2016 20:09:10 -0500 Message-ID: <87fuxmbh3d.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453684153; bh=AjN0boXfG7Twzrz09wzR6Pwz6dtrPG9n4gPq4z0zVlc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ILUNfvEe7/YckzUdec5nvhDWPTr0EfUiupGZe1TvxTDD2v1TFHSXECchAfk9T3pMt 1uqZzeqUnfdebwIalFJ7ACRqyJgvxPvK06AssneQYeelfadS1eDTtzZPUeicpm+mln XzsEFGsLIMrhu+X1yFdW9KstauPCFioa56cByhdf9Lh58eW4CFv4vPRvW1FrZg4aFv NjKoLNjtDZon//npz9A0diqt8kTdNxUi0afGAcOXB1XiQg4+gyDkuMH6SzC98DefYK zIXd9l33z10LGdXEQAnIHyROYfZiPCflRya5Z5/JPmXY3Pbi6XsUVddUIf1TtWqVza 48pzjmlMfXd6Q== Archived-At: Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack: branch parameters 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, 25 Jan 2016 01:09:16 -0000 At the risk of opening a can of worms: draft-ietf-sipcore-dns-dual-stack resembles RFC 3263 in that it describes how to send a SIP request to a URI. They provide a process for resolving the URI into one or more network connection points (address, port, and transport protocol), which the sender attempts to contact in sequence until it successfully contacts the destination. RFC 3263 states that the transmission to each address/port must have a different Via branch parameter: If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different value of the Via branch ID than the previous (and therefore constitutes a new SIP transaction). That request is sent to the next element in the list as specified by RFC 2782. The nasty consequence of this is that if the destination receives one request but its response (e.g., a 100 response) does not get back to the sender in time, the sender can send another request to a different address/port/transport that arrives at the same destination, but is marked as being a different SIP transaction by the new branch parameter value. And so the destination processes this request as a different branch of the SIP request. I've seen this cause trouble in practice: If proxy A routes to proxy B using the URI , proxy A can attempt to contact proxy B using UDP. If it does not receive a response quickly, it can then attempt to contact proxy B using TCP. If there has been network congestion, both the UDP datagram and the TCP SYN can arrive at proxy B at the same time, and proxy B has no way to know that they are "equivalent" and should be processed together. Instead, proxy B will forward one of them to the destination phone. It will then forward the other one to the destination phone, the phone rejects it with 482 (since it's already ringing for another branch of this call), proxy B will then sequentially-fork it to the phone's voice mail. This leaves the destination phone ringing and the caller's phone talking to the destination user's voicemail. A better user experience would be obtained if all copies of the request were sent with the same branch parameter, so that the destination will know to ignore all but the first copy that it received. Dale From nobody Sun Jan 24 23:12: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 204401ACE91 for ; Sun, 24 Jan 2016 23:12:13 -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 9swBgSHF-i8c for ; Sun, 24 Jan 2016 23:12:11 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0151ACE90 for ; Sun, 24 Jan 2016 23:12:09 -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 F15E393DE54; Mon, 25 Jan 2016 07:11:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Olle E. Johansson" In-Reply-To: <87h9i2bi9p.fsf@hobgoblin.ariadne.com> Date: Mon, 25 Jan 2016 08:12:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D304150-8188-4F48-8F95-0543514B8CDB@edvina.net> References: <17960B77-D25A-4135-844E-51FCEDFC51D0@edvina.net> <87h9i2bi9p.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: Simon Perreault's review 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, 25 Jan 2016 07:12:13 -0000 > On 25 Jan 2016, at 01:43, Dale R. Worley wrote: >=20 > I've edited in a number of Simon's changes. However: >=20 > Simon Perreault writes: >> - It's not clear to me whether Section 4.1 advocates parallel = connections >> or not. Is Happy Eyeballs to be applied or not? Or are we not = recommending >> one way or another? This needs to be made more explicit. >=20 > At this point, the relationship between this draft and Happy Eyeballs = is > not clear to me. This draft was meant to only clear up DNS lookups to prepare for another draft that discusses Happy Eyeballs in SIP. But that one could not be = done if we did not have both A and AAAA records at the same time. > My expectations of a combination of 3263 and "Happy > Eyeballs" are: >=20 > 1. A client must look up both A and AAAA records for a destination in = all > situations where it looks up a destination. >=20 > 2. A client whose initial attempt to reach a destination via IPv6 = fails > should quickly attempt to reach it via IPv4, regardless of whether = the > destination has declared that it prefers a second IPv6 address to = its > IPv4 address (RFC 6555 section 4 item 1). The problem here is UDP. We=E2=80=99ve spent many hours discussing this. For connection oriented protocols we can follow Happy Eyeballs, but it doesn=E2=80=99t work for UDP. For UDP, we need a solution based=20= on DNS. I think I have a presentation that outlines this somewhere. >=20 > 3. A client must remember whether attempts to reach a destination via > IPv6 have failed in the past, and if so, prefer IPv4 to reach it = (RFC > 6555 section 4). >=20 > Item 1 does not seem to me to be normative. RFC 3263 is a mess to = read, > but any sensible integration of it with the RFCs it references seems = to > me to imply that a SIP client (as RFC 3263 calls the sender) must look > up address records for all address families that it supports (in any = of > the 3 situations in which it looks up address records). >=20 > Items 2 and 3 seem to me to be the essence of "Happy Eyeballs", and = they > are normative changes to RFC 3263/2782, since when SRV records are > involved, the SRV records currently declare the order which the client > MUST use the specified addresses. >=20 >> - The guidance in Section 4.2 could benefit from stronger normative >> language: >>=20 >> When indicating address family preference through SRV, IPv4-only = and/ >> or IPv6-only clients should be prepared to handle SRV record sets >> that don't resolve into an ip address in the address family used by >> that client. In such a case, the client should simply proceed to = the >> next priority and try the hostnames in the alternate address = family. >>=20 >> Suggestion: s/should/MUST/g >>=20 >> And please remove the "and try the hostnames in the alternate address >> family." part, which makes no sense (a hostname cannot be "in an = address >> family"). >=20 > Actually, this paragraph should be moved out of section 4.2, because = 4.2 > is about how a client should indicate how it prefers to be contacted, > whereas this text is about *all* clients, that resolution may produce > addresses the client doesn't support, and it must be prepared to = ignore > those addresses. >=20 >> minor >> =3D=3D=3D=3D=3D >>=20 >> - Should this draft formally update RFC 3263? >=20 > Assuming that we're actually incorporating the Happy Eyeballs > processing, it updates RFC 3263: >=20 > - In regard to URIs that do not invoke SRV records, Happy Eyeballs > processing provides more constraints on the sequence in which = resolved > addresses are used. As a tightening of the requirements of RFC 3263, > it is an update thereof. >=20 > - in regard to URIs that invoke SRV records, the sequence specified by > the SRV records can be overridden. This contravenes RFC 2782 as > incorporated by RFC 3263, and so is an update. >=20 > However, Olle says: >> At one point it did, but the wg - especially Cullen Jennings - did = not >> accept it. I personally still think it's needed. >=20 > How do we resolve this? If we write documents in order to guide developers, an update would be easy to follow while browsing the RFCs. And it is indeed an update. The formal problem that I think worries people is that if we update RFC 3263 the definition of =E2=80=9CSIP compliant=E2=80=9D = will change and that will affect many vendors. Personally I think that=E2=80=99s a = good thing. /O From nobody Sun Jan 24 23:13: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 3012A1ACE91 for ; Sun, 24 Jan 2016 23:13: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 iyoqwHo6D-qt for ; Sun, 24 Jan 2016 23:13:21 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0124B1ACE8C for ; Sun, 24 Jan 2016 23:13:20 -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 CAD3393DE5E; Mon, 25 Jan 2016 07:12:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Olle E. Johansson" In-Reply-To: <87fuxmbh3d.fsf@hobgoblin.ariadne.com> Date: Mon, 25 Jan 2016 08:13:04 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <87fuxmbh3d.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: branch parameters 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, 25 Jan 2016 07:13:22 -0000 > On 25 Jan 2016, at 02:09, Dale R. Worley wrote: > > At the risk of opening a can of worms: > > draft-ietf-sipcore-dns-dual-stack resembles RFC 3263 in that it > describes how to send a SIP request to a URI. They provide a process > for resolving the URI into one or more network connection points > (address, port, and transport protocol), which the sender attempts to > contact in sequence until it successfully contacts the destination. > > RFC 3263 states that the transmission to each address/port must have a > different Via branch parameter: > > If a failure occurs, the client SHOULD create a new request, which is > identical to the previous, but has a different value of the Via > branch ID than the previous (and therefore constitutes a new SIP > transaction). That request is sent to the next element in the list > as specified by RFC 2782. > > The nasty consequence of this is that if the destination receives one > request but its response (e.g., a 100 response) does not get back to the > sender in time, the sender can send another request to a different > address/port/transport that arrives at the same destination, but is > marked as being a different SIP transaction by the new branch parameter > value. And so the destination processes this request as a different > branch of the SIP request. > > I've seen this cause trouble in practice: If proxy A routes to proxy B > using the URI , proxy A can attempt to contact proxy B > using UDP. If it does not receive a response quickly, it can then > attempt to contact proxy B using TCP. If there has been network > congestion, both the UDP datagram and the TCP SYN can arrive at proxy B > at the same time, and proxy B has no way to know that they are > "equivalent" and should be processed together. Instead, proxy B will > forward one of them to the destination phone. It will then forward the > other one to the destination phone, the phone rejects it with 482 (since > it's already ringing for another branch of this call), proxy B will then > sequentially-fork it to the phone's voice mail. This leaves the > destination phone ringing and the caller's phone talking to the > destination user's voicemail. > > A better user experience would be obtained if all copies of the request > were sent with the same branch parameter, so that the destination will > know to ignore all but the first copy that it received. I am not sure this is related to the draft, but it does indicate that RFC 3263 may need a generic overhaul. /O From nobody Mon Jan 25 10:08:32 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 6B3C11B3836; Mon, 25 Jan 2016 10:08:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160125180830.9626.16435.idtracker@ietfa.amsl.com> Date: Mon, 25 Jan 2016 10:08:30 -0800 Archived-At: Cc: ben@nostrum.com, aroach@mozilla.com, sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] sipcore - Update to a Meeting Session Request for IETF 95 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, 25 Jan 2016 18:08:30 -0000 An update to a meeting session request has just been submitted by Adam Roach, a Chair of the sipcore working group. --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: avtcore perc avtext rtcweb mmusic stir webpush xrblock netvc Special Requests: --------------------------------------------------------- From nobody Mon Jan 25 10:09:01 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 7DCE71B3842; Mon, 25 Jan 2016 10:08:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160125180859.11116.66780.idtracker@ietfa.amsl.com> Date: Mon, 25 Jan 2016 10:08:59 -0800 Archived-At: Cc: ben@nostrum.com, aroach@mozilla.com, sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] sipcore - Update to a Meeting Session Request for IETF 95 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, 25 Jan 2016 18:08:59 -0000 An update to a meeting session request has just been submitted by Adam Roach, a Chair of the sipcore working group. --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: avtcore perc avtext rtcweb mmusic stir webpush xrblock netvc dispatch Special Requests: --------------------------------------------------------- From nobody Mon Jan 25 11:54:07 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 4817B1A009F for ; Mon, 25 Jan 2016 11:54:06 -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 RU1EHXo24XEr for ; Mon, 25 Jan 2016 11:54:05 -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 4B20E1A009E for ; Mon, 25 Jan 2016 11:54:05 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-07v.sys.comcast.net with comcast id AKsq1s0042LrikM01Ku4mS; Mon, 25 Jan 2016 19:54:04 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id AKu31s0071nMCLR01Ku38Q; Mon, 25 Jan 2016 19:54:04 +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 u0PJs2TC021046; Mon, 25 Jan 2016 14:54:02 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0PJs2Dg021038; Mon, 25 Jan 2016 14:54:02 -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: <2D304150-8188-4F48-8F95-0543514B8CDB@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 25 Jan 2016 14:54:01 -0500 Message-ID: <87h9i1a10m.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453751644; bh=Bd1frYEoVlrGd2D//N6AZKrlzvel8YonpxIGahs+KS0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=i0+931AfFyJ2VdcAbavEKFDKH6WKfYqTVJHopsNsZWbqF0RBkUG6oDhpYZw9OoR4K CX8dYBpWxwCTddYNRfZ1I3yONl3Br+ns5NnLea3IFgSXhORBQXPSXP3wrRCGQdN4qs PJHI5sr2VRiOnCzyz41A5fGxp6pn06oqZi+nWgyP+yxKdb90P3b0y9GEJ/Q7DFPEgx MeCb8xgvn0y0GM9lc1nsZ95/gT5V6MpxFBneCQElPguUDoGG9YFGHBmNNI7cjG3ynA k0lghFgnYlYxRu3Ti1M3xPad6uLZZa6L5cmz+9/qVuA4keafsf3DC0kdC2uidIy5GQ /byFgi7YbXuDA== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: Simon Perreault's review 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, 25 Jan 2016 19:54:06 -0000 "Olle E. Johansson" writes: >> At this point, the relationship between this draft and Happy Eyeballs is >> not clear to me. > This draft was meant to only clear up DNS lookups to prepare for another > draft that discusses Happy Eyeballs in SIP. But that one could not be done > if we did not have both A and AAAA records at the same time. If I understand you correctly: The scope of this draft is quite narrow. It is to update these two passages of RFC 3263: 4.2 Determining Port and IP Address [a host name with a port number:] If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. [...] [a host name without a port number, but no SRV records for the host name:] If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously, at the default port for that transport. Processing then proceeds as described above for an explicit port once the A or AAAA records have been looked up. to align with this passage of RFC 2782 (SRV records): Note that where this document refers to "address records", it means A RR's, AAAA RR's, or their most modern equivalent. Is that correct? Dale From nobody Mon Jan 25 11:58:32 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 20EB81A00BD for ; Mon, 25 Jan 2016 11:58:31 -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 aNOv-2H6cVsE for ; Mon, 25 Jan 2016 11:58:29 -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 D2D8E1A00AE for ; Mon, 25 Jan 2016 11:58:29 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-09v.sys.comcast.net with comcast id AKxF1s0072VvR6D01KyUcj; Mon, 25 Jan 2016 19:58:28 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-19v.sys.comcast.net with comcast id AKyU1s0041nMCLR01KyUVf; Mon, 25 Jan 2016 19:58:28 +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 u0PJwRat021490; Mon, 25 Jan 2016 14:58:27 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0PJwR5w021487; Mon, 25 Jan 2016 14:58:27 -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: <2D304150-8188-4F48-8F95-0543514B8CDB@edvina.net> (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 25 Jan 2016 14:58:27 -0500 Message-ID: <87d1spa0t8.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453751908; bh=o5xJTbxyqGgYOZXHFhDw2vf6kWnHJjFpAQ/erJjjqCo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=vcFg9IsWvSfSbyBLB9tQhJcpT+AhzXlPscSIyL8f5Kw0CtSxbNk10Ijwt1lt9zjcY pF6Bjic5iFh+uiSivuNNz5cW2mxis4RajoQY+fTRjJTRh5mG1Lmo1y/7/erIbssGCO CfeC/UB6xruRR+rqrGOFWLyvHJFdguIw8p/eyODlpaIFloFPRmzPMtYxyanDdrNVzW lYp6Cls09LlJ4N5GEXFRgBMXwwl+8pj/RjKWdzbBd+nZ641AMGo+9FqjsO0NFgV+aa Js5TCEV5Rn6OYIsGzM7wFB20a4ayGnBXog7tZFggPMa+ekb6+R6HUoeiWwHBLB7pD7 l3YLM75KZND8w== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: Simon Perreault's review 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, 25 Jan 2016 19:58:31 -0000 "Olle E. Johansson" writes: > The formal problem that I think worries people is that if we update > RFC 3263 the definition of "SIP compliant" will change and that will > affect many vendors. Personally I think that's a good thing. My understanding is that "SIP compliant", to be well-defined, must always followed by a list of the RFCs that compliance is claimed for, so the customers and vendors can always ask whether a device is compliant with RFC 8123, or whatever it will be, as well as RFC 3263. Certainly this happened when "SIP" changed from RFC 2543 to RFC 3261. But maybe customers are acting differently these days. Dale From nobody Mon Jan 25 12:23: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 CAE0C1A00DC for ; Mon, 25 Jan 2016 12:23:16 -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 Gc1HTi8DmdQU for ; Mon, 25 Jan 2016 12:23:15 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2A41A00A3 for ; Mon, 25 Jan 2016 12:23:15 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-11v.sys.comcast.net with comcast id ALNi1s0032Ka2Q501LPEQJ; Mon, 25 Jan 2016 20:23:14 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-11v.sys.comcast.net with comcast id ALPD1s00N1nMCLR01LPEon; Mon, 25 Jan 2016 20:23: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 u0PKNDdk023977; Mon, 25 Jan 2016 15:23:13 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0PKNDqc023970; Mon, 25 Jan 2016 15:23: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: "Penar\, Russell" In-Reply-To: <12C684AA1283B949BD80AC8273CF3A723F45A77F@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 25 Jan 2016 15:23:12 -0500 Message-ID: <87a8nt9znz.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453753394; bh=HFkLhuioENMfo4EBU7PkWgarf/T24wKbH2yNUnxcdzk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=mrwTL8/r5oTccIjJsWDF7nK0w+YySTU9uofaol+xxJMcYWzP1w7DliAStyP3D6RVF VtY7Nt+BA4S4reM8Jm3EqRSdctSI1Z3AV0dokPj+urY81WJDh9Ik8VQLbA6aKVwjN2 waEBtc8IKWsDquayclLRsVqozJGf8XyWsiPNjP0JGJXHXGE+99fErCXhKw/li8vYk0 n3DshGhbPrAzF+vOnMTzYZfrchdvJvYhnQWNybbG9jjpkYDZA+IjRpsoNp20C/MXqw DF5BOkhmUuzn49YCKGQazyGCEkamCAhkYGcJQklyygHTAa05lF4hA00c/GVpk0Q8sn f0AEvQZZCG24A== 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: Mon, 25 Jan 2016 20:23:17 -0000 "Penar, Russell" writes: > I'm seeing non-ideal behavior from cpe and hoping this group can > provide guidelines specific to the scenario below, and ultimately > standardize ideal cpe behavior for the given context. I haven't found > any specifications defining the ideal behavior, and it was suggested > during sipnoc to contact sipcore as an appropriate next step. Unfortunately, Sipcore doesn't so much define ideal behavior as define the behaviors that a UA (CPE) is permitted to have. Within that context, a UA can drop a call whenever it chooses. In the use cases we see, the general advice is "If the UA is behaving in a way that provides a poor user experience, buy a different type of UA." That usually gives the UA manufacturers incentive to improve their UAs. > Where a standing call is setup against the primary sbc; after a > primary sbc mated pair failover, calls are at risk of being dropped if > a tcp connection is not established back to the primary sbc. This can > be due to session audits from the platform, or more specific to my ask > is a cpe re-Invite scenario. For example, when cpe puts standing call > on hold (after sbc failover), the sbc target for re-establishing the > signaling tcp session is critical. > > I've seen cpe exhibit ideal behavior, where upon receipt of tcp rst > the cpe connects back to the primary sbc. In that ideal scenario, the > call stays up, mid-call control doesn't fail, etc. And I've seen > non-ideal behavior where once the cpe attempts to put the call on > hold, it reacts to the tcp rst by failing over to the secondary sbc > and dropping the standing call. Fwiw, I'm told the vendor exhibiting > the ideal behavior only recently began to do so (reportedly from > customer pressure to properly support geo-redundant setups as > described above). As a general rule, the failure of a TCP connection does not change the state of any SIP call. But if the UA wants to issue a re-INVITE for an existing call, it will send an INVITE request using the "route set" of the call. The UA learns the route set during call set-up; the devices on the path that the INVITE request takes will add Record-Route or Contact headers containing addresses; the collection of these headers is the route set and specifies the path which all further requests for that call will take. Since the SBC wants to see further requests for the call, it adds an address for itself in either a Record-Route header or a Contact header (depending on the technical details of the SBC). If you want the calls to fail over, it's critical that the address is one that routes to both the primary and secondary SBCs -- it is a host name which DNS maps to the addresses of both SBCs. If the address is only for the SBC involved in the call setup, if that SBC goes down and the UA attempts a re-INVITE, the UA can't send the re-INVITE. The UA may decide to tear down the call, but some UAs don't -- instead, they assume that if the call truly fails, the user will hang up and so they maintain the call until the user hangs up. It's understood that if a UA attempts to send a request on a TCP connection and the TCP connection produces some sort of error that the UA should either attempt to reestablish the TCP connection or send the request to an alternative destination (e.g., the other SBC). This is specified in RFC 3263 section 4.3: For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the transaction layer times out without ever having received any response, provisional or final (i.e., timer B or timer F in RFC 3261 [1] fires). If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different value of the Via branch ID than the previous (and therefore constitutes a new SIP transaction). That request is sent to the next element in the list as specified by RFC 2782. Dale From nobody Mon Jan 25 15:26:43 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 B3EB51A1EED for ; Mon, 25 Jan 2016 15:26:41 -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, 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 6KFLLTqRbxPU for ; Mon, 25 Jan 2016 15:26:39 -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 CF3531A1EEA for ; Mon, 25 Jan 2016 15:26:39 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id u0PNQU4u008210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2016 16:26:30 -0700 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9D14B1E007E; Mon, 25 Jan 2016 16:26:25 -0700 (MST) Received: from lxdnp31k.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 842111E0071; Mon, 25 Jan 2016 16:26:25 -0700 (MST) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u0PNQPJn022527; Mon, 25 Jan 2016 16:26:25 -0700 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u0PNP6ju021240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Jan 2016 16:26:22 -0700 Received: from PDDCWMBXEX504.ctl.intranet ([fe80::f8d9:8c16:7f70:657b]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Mon, 25 Jan 2016 16:23:51 -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: AQHRV6441DcvmLeEEEu3lrbXwSyFPZ8MytbQ Date: Mon, 25 Jan 2016 23:23:51 +0000 Message-ID: <12C684AA1283B949BD80AC8273CF3A723F57F803@PDDCWMBXEX504.ctl.intranet> References: <12C684AA1283B949BD80AC8273CF3A723F45A77F@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) <87a8nt9znz.fsf@hobgoblin.ariadne.com> In-Reply-To: <87a8nt9znz.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.40.132] 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: Mon, 25 Jan 2016 23:26:41 -0000 Thanks for the reply Dale, comments in line. Regards, Russ -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com] Sent: Monday, January 25, 2016 1:23 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: > I'm seeing non-ideal behavior from cpe and hoping this group can > provide guidelines specific to the scenario below, and ultimately > standardize ideal cpe behavior for the given context. I haven't found > any specifications defining the ideal behavior, and it was suggested > during sipnoc to contact sipcore as an appropriate next step. Unfortunately, Sipcore doesn't so much define ideal behavior as define the = behaviors that a UA (CPE) is permitted to have. Within that context, a UA = can drop a call whenever it chooses. In the use cases we see, the general = advice is "If the UA is behaving in a way that provides a poor user experie= nce, buy a different type of UA." That usually gives the UA manufacturers = incentive to improve their UAs. RP - That's a fair stance, we have seen at least one vendor move to the "id= eal" behavior presumably from customer pressure. Would it also be fair to = state Sipcore defines behavior that a UA is not permitted to have? Perhaps= what I'm really trying to get here is a MUST NOT statement against connect= ing to secondary targets upon receipt of a TCP RST. > Where a standing call is setup against the primary sbc; after a > primary sbc mated pair failover, calls are at risk of being dropped if > a tcp connection is not established back to the primary sbc. This can > be due to session audits from the platform, or more specific to my ask > is a cpe re-Invite scenario. For example, when cpe puts standing call > on hold (after sbc failover), the sbc target for re-establishing the > signaling tcp session is critical. > > I've seen cpe exhibit ideal behavior, where upon receipt of tcp rst > the cpe connects back to the primary sbc. In that ideal scenario, the > call stays up, mid-call control doesn't fail, etc. And I've seen > non-ideal behavior where once the cpe attempts to put the call on > hold, it reacts to the tcp rst by failing over to the secondary sbc > and dropping the standing call. Fwiw, I'm told the vendor exhibiting > the ideal behavior only recently began to do so (reportedly from > customer pressure to properly support geo-redundant setups as > described above). As a general rule, the failure of a TCP connection does not change the stat= e of any SIP call. But if the UA wants to issue a re-INVITE for an existin= g call, it will send an INVITE request using the "route set" of the call. = The UA learns the route set during call set-up; the devices on the path tha= t the INVITE request takes will add Record-Route or Contact headers contain= ing addresses; the collection of these headers is the route set and specifi= es the path which all further requests for that call will take. Since the SBC wants to see further requests for the call, it adds an addres= s for itself in either a Record-Route header or a Contact header (depending= on the technical details of the SBC). If you want the calls to fail over,= it's critical that the address is one that routes to both the primary and = secondary SBCs -- it is a host name which DNS maps to the addresses of both= SBCs. RP - We're using DNS SRV to support geo-redundant access SBCs. The "route = set" doesn't appear to be an issue, as the re-Invite does go to the correct= location (primary), but upon receipt of the TCP RST the UA immediately dro= ps the call, sets up a new TCP connection to the secondary and Registers. = The UA gathers primary and secondary targets (for outbound proxy FQDN) upon= boot up and then accordingly based on TTL. If the address is only for the SBC involved in the call setup, if that SBC = goes down and the UA attempts a re-INVITE, the UA can't send the re-INVITE.= The UA may decide to tear down the call, but some UAs don't -- instead, t= hey assume that if the call truly fails, the user will hang up and so they = maintain the call until the user hangs up. RP - I agree in principle when using SRV the SBC's Contact/R-R should have = the SBC FQDN and not a specific IP address. With use of outbound proxy, I = haven't seen issues with UA's not failing over when Contact (for example) i= s returned with only the SBC (HA pair IP address) involved in the call setu= p. It's understood that if a UA attempts to send a request on a TCP connection= and the TCP connection produces some sort of error that the UA should eith= er attempt to reestablish the TCP connection or send the request to an alte= rnative destination (e.g., the other SBC). This is specified in RFC 3263 s= ection 4.3: For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the transaction layer times out without ever having received any response, provisional or final (i.e., timer B or timer F in RFC 3261 [1] fires). If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different value of the Via branch ID than the previous (and therefore constitutes a new SIP transaction). That request is sent to the next element in the list as specified by RFC 2782. RP - Could we amend this section of 3263, to reflect a UA SHOULD (specific = to context of TCP) try the current element where a SIP dialog is establishe= d before trying the next element per 2782? 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 Tue Jan 26 00:50:56 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 C4F2D1A870D for ; Tue, 26 Jan 2016 00:50:55 -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 OAvHKMADvd2O for ; Tue, 26 Jan 2016 00:50:54 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B6A561A8706 for ; Tue, 26 Jan 2016 00:50:53 -0800 (PST) Received: from [192.168.222.158] (unknown [195.149.146.45]) by smtp7.webway.se (Postfix) with ESMTPA id 497A193DE59; Tue, 26 Jan 2016 08:50:19 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Olle E. Johansson" In-Reply-To: <87h9i1a10m.fsf@hobgoblin.ariadne.com> Date: Tue, 26 Jan 2016 09:50:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E9F22C9-689D-44B8-8CF0-63EF6C33B78B@edvina.net> References: <87h9i1a10m.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: Simon Perreault's review 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, 26 Jan 2016 08:50:55 -0000 > On 25 Jan 2016, at 20:54, Dale R. Worley wrote: >=20 > "Olle E. Johansson" writes: >>> At this point, the relationship between this draft and Happy = Eyeballs is >>> not clear to me. >=20 >> This draft was meant to only clear up DNS lookups to prepare for = another >> draft that discusses Happy Eyeballs in SIP. But that one could not be = done >> if we did not have both A and AAAA records at the same time. >=20 > If I understand you correctly: >=20 > The scope of this draft is quite narrow. It is to update these two > passages of RFC 3263: >=20 > 4.2 Determining Port and IP Address >=20 > [a host name with a port number:] > If the TARGET was not a numeric IP address, but a port is present in > the URI, the client performs an A or AAAA record lookup of the = domain > name. >=20 > [...] >=20 > [a host name without a port number, but no SRV records for the host = name:] > If no SRV records were found, the client performs an A or AAAA = record > lookup of the domain name. The result will be a list of IP > addresses, each of which can be contacted using the transport > protocol determined previously, at the default port for that > transport. Processing then proceeds as described above for an > explicit port once the A or AAAA records have been looked up. >=20 > to align with this passage of RFC 2782 (SRV records): >=20 > Note that where this document refers to "address records", it means = A > RR's, AAAA RR's, or their most modern equivalent. >=20 > Is that correct? Yes, the one important point was to make sure that =E2=80=9CA or AAAA=E2=80= =9D was redefined to clearly mean =E2=80=9CA and AAAA=E2=80=9D records so that we would always have = the possibility to perform Happy Eyeballs. It=E2=80=99s mentioned in several places in RFC = 3263 if I remember=20 correctly and unfortunately copied to other RFCs. The second part was using the DNS SRV to indicate the server manager=E2=80= =99s order of preference. We=E2=80=99ve been discussing back and forth wheather the Happy Eyeballs = part should be part of this draft or not, but have decided multiple times to = split it up. It may or may not be the right way :-) /O= From nobody Tue Jan 26 00:52:16 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 2765D1A8715 for ; Tue, 26 Jan 2016 00:52:14 -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 VFEoWCkuSLT7 for ; Tue, 26 Jan 2016 00:52:13 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2A78C1A8714 for ; Tue, 26 Jan 2016 00:52:13 -0800 (PST) Received: from [192.168.222.158] (unknown [195.149.146.45]) by smtp7.webway.se (Postfix) with ESMTPA id EE27493DE63; Tue, 26 Jan 2016 08:51:39 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Olle E. Johansson" In-Reply-To: <87d1spa0t8.fsf@hobgoblin.ariadne.com> Date: Tue, 26 Jan 2016 09:52:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d1spa0t8.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: Simon Perreault's review 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, 26 Jan 2016 08:52:14 -0000 > On 25 Jan 2016, at 20:58, Dale R. Worley wrote: >=20 > "Olle E. Johansson" writes: >> The formal problem that I think worries people is that if we update >> RFC 3263 the definition of "SIP compliant" will change and that will >> affect many vendors. Personally I think that's a good thing. >=20 > My understanding is that "SIP compliant", to be well-defined, must > always followed by a list of the RFCs that compliance is claimed for, = so > the customers and vendors can always ask whether a device is compliant > with RFC 8123, or whatever it will be, as well as RFC 3263. Certainly > this happened when "SIP" changed from RFC 2543 to RFC 3261. But maybe > customers are acting differently these days. I am not sure, but RFC 3261 clearly depends on 3263. If we update 3263, doesn=E2=80=99t that mean that 3261 depends on the new RFC too? So in order to be 3261 SIP-compliant, which is quite often a = requirement, it would also mean being compliant with proper dual stack handling, as defined by this new draft=E2=80=A6 /O= From nobody Tue Jan 26 08:04: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 E003A1B304F for ; Tue, 26 Jan 2016 08:04: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 1UzR0Lz6gP56 for ; Tue, 26 Jan 2016 08:04:32 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF001B304E for ; Tue, 26 Jan 2016 08:04:30 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-03v.sys.comcast.net with comcast id Ag2r1s0015BUCh401g4Wxy; Tue, 26 Jan 2016 16:04:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-16v.sys.comcast.net with comcast id Ag4V1s00Y3KdFy101g4VyD; Tue, 26 Jan 2016 16:04:30 +0000 To: sipcore@ietf.org References: <87d1spa0t8.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <56A7990C.70401@alum.mit.edu> Date: Tue, 26 Jan 2016 11:04:28 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453824270; bh=Md90YUAf/xCj6cO38p5DZCh6T6+ap3eaOYuSdsNOJgY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=K96FYzbnyNZR2X0QkixsG1qWnA421QQg6IMAP5hoIoR8uWzLH2F3sz0JtOhYsvdIP SmNJqxafvF/eAl+o3JhLYv+j71y0GsmymWGuTBRSMqbdmQSUKQT5SgNu3yyBuHsas0 4ZIX7D09K5WRHmyCwFLrpwQ7u8mHOSRo7PMLOUu2mC7knJIJ8+sGGE/ll6NxBjBVMC DmEdVWu0o27c3SVr9AlCsGyWBbr/EFGoBq+qkpRGEUNJHd91sRCpmbb5m6pGANMrXs mX5V6Rhm8Ov45RN+G2bCc8+ciRehKOzwPSlgUG9QxSa3IRLz8JNHymADmKNekFgjJ1 esSNq36mh6NKA== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: Simon Perreault's review 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, 26 Jan 2016 16:04:34 -0000 On 1/26/16 3:52 AM, Olle E. Johansson wrote: > >> On 25 Jan 2016, at 20:58, Dale R. Worley wrote: >> >> "Olle E. Johansson" writes: >>> The formal problem that I think worries people is that if we update >>> RFC 3263 the definition of "SIP compliant" will change and that will >>> affect many vendors. Personally I think that's a good thing. >> >> My understanding is that "SIP compliant", to be well-defined, must >> always followed by a list of the RFCs that compliance is claimed for, so >> the customers and vendors can always ask whether a device is compliant >> with RFC 8123, or whatever it will be, as well as RFC 3263. Certainly >> this happened when "SIP" changed from RFC 2543 to RFC 3261. But maybe >> customers are acting differently these days. > > I am not sure, but RFC 3261 clearly depends on 3263. If we update 3263, > doesn’t that mean that 3261 depends on the new RFC too? > > So in order to be 3261 SIP-compliant, which is quite often a requirement, > it would also mean being compliant with proper dual stack handling, > as defined by this new draft… IIUC, you cannot revise history. Something that was once 3261 compliant remains so, regardless of what revisions are made later. That is why we don't reissue revised RFCs using the original numbers. Revising 3263 doesn't automatically force implementations of 3261 to implement that revision. What it does do is make compliance to 3261 something that should, in itself, be considered insufficient. If we wanted to provide a single RFC number that people could claim compliance to that would reflect the current understanding of sufficiency then we would need to issue a revision to 3261. Thanks, Paul From nobody Tue Jan 26 08:14:32 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 B60E31B3074 for ; Tue, 26 Jan 2016 08:14:30 -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 NvrGojWiK9gf for ; Tue, 26 Jan 2016 08:14:25 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D18D1A82E2 for ; Tue, 26 Jan 2016 08:14:25 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id b14so138868918wmb.1 for ; Tue, 26 Jan 2016 08:14:25 -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=6Fl1+LCXUG2MrMVx/SbyyH8jqkxp9BTeebL+mpyIy2s=; b=OVjYVatR9KtfaS8uAT7VeR7t4dE8PsX843iJI/sUcXWh09BvwiH4rkQ75Jx3yad1uE Tr4b/RftpAsyaJVuKU+AW6BFgKJPOXcT0jKIRIryduMLgDjGp54i7EGPvCpNZtSoU6k2 CT0UAKr62afBf+TBlXF6SSEBGyPXEzvLNhj03d5Btu+/Ywlt+LbHrai6pdkxi1lqFGNL EoGdaNKVt44Qcued/8ghoNyktcvxCDxkGR+lhSDvMquidrJdyjez+QkIpjPZSZ104hnV Sk+9w/ooLRExPm7rQzoSftuymIbQdJHq1T6D5PVeWJWkgCG0awEd8yGIiLwfWCzEn5xP qNbA== 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=6Fl1+LCXUG2MrMVx/SbyyH8jqkxp9BTeebL+mpyIy2s=; b=gysjlCBuKik/uZ8g3Q/77nEmmDOLcnG/aWPy1/jURcfzRvEh1zxAEWq4sOJEui94Nt t0tfr7Ecjws6b6I5ADTRFHqXZgWukWfinS0Z9sh/m/++pBoEYUMVHShUeHQEKNp/WeIO mV/Kn0CV8LrDpS8lOjynNZ5ewkrpmck9/t/F9w+hHh1khpCXBMMZwnfdH4O5JlXjEya+ FjrEFssZs3luTR6J1/VWdpeC3QmgKinsE5/bShlwVwIlBf6H1BId1QwqJr86EO1lk1Ri AHy6KxWOpCRPuH37KDFDV9IxawweZjtHZlu29KzfvgLyy5igrvKXq+m5j/A2TjkbpTS4 ywvQ== X-Gm-Message-State: AG10YOTcaE0I8tn5l2nUnDY8zSneL8pgFng/6M1/AXK9n9sLmZZ61UfTJK0C1jJNgLwIvjCwfBejvaLa/oEKgLnU X-Received: by 10.194.158.135 with SMTP id wu7mr24359009wjb.142.1453824863765; Tue, 26 Jan 2016 08:14:23 -0800 (PST) From: Brett Tate References: <87fuxmbh3d.fsf@hobgoblin.ariadne.com> In-Reply-To: <87fuxmbh3d.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLcQjfBTjYantPy1j2iqiDij56t1Zz4B6lA Date: Tue, 26 Jan 2016 11:14:23 -0500 Message-ID: <29e056ac5c7ce97a51afee4e75e6619b@mail.gmail.com> To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: branch parameters 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, 26 Jan 2016 16:14:30 -0000 Hi, > A better user experience would be obtained if all copies of > the request were sent with the same branch parameter, so that > the destination will know to ignore all but the first copy > that it received. Although merged request handling can potentially be improved within SIP, I'm not sure that the proposed improvement is better than current behavior. However, this draft will definitely cause more merged request situations (and delays before advancing to reachable server). I'm also not sure if the proposed improvement actually addresses the real issue. Are you experiencing a transaction correlation issue or just a lack of 1xx to compliantly allow you to send CANCEL? Changing the branch allows the sender to know which destination actually worked. Without that knowledge, it would not know the destination and port for sending ACK-for-non-2xx and/or CANCEL (unless added something else to the Via). The requests can take different paths before merging. Ignoring requests from the different path can cause the path to appear non responsive (although intermediary can send 100 response to reduce some of the side effects). Thanks, Brett From nobody Tue Jan 26 08:31: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 D473C1B3096 for ; Tue, 26 Jan 2016 08:30:55 -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 YZrPykz3KA50 for ; Tue, 26 Jan 2016 08:30:54 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B151B3024 for ; Tue, 26 Jan 2016 08:30:53 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with comcast id AgWX1s0082JGN3p01gWtpS; Tue, 26 Jan 2016 16:30:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id AgWs1s00Z3KdFy101gWsrQ; Tue, 26 Jan 2016 16:30:53 +0000 To: sipcore@ietf.org References: <12C684AA1283B949BD80AC8273CF3A723F45A77F@PDDCWMBXEX504.ctl.intranet> <87a8nt9znz.fsf@hobgoblin.ariadne.com> <12C684AA1283B949BD80AC8273CF3A723F57F803@PDDCWMBXEX504.ctl.intranet> From: Paul Kyzivat Message-ID: <56A79F3C.1060201@alum.mit.edu> Date: Tue, 26 Jan 2016 11:30:52 -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: <12C684AA1283B949BD80AC8273CF3A723F57F803@PDDCWMBXEX504.ctl.intranet> 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=1453825853; bh=SueKl6jQx8DzV54aMjJvcNFGmJ3JTfn0v7VUQED1/0c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GJiet4rejToOMlQ5IC5QsxX5k5lf1PTnkDp7nFFfLAXh7JYMH3Gk5YPGZXBcVTIOH lQ6aKtb1dEUGfLaL/21ONbYpJov2wJ8guc1DjuZQKMvyHhzDnQbvWeZ/lPCtmkD8Pw 7xwskAwTmSp9HhbC1LWmI0ZJ8TnRP/duVWJxGIDnq6B2+9DADh5pHz971De0rs0J1P lGqvk8OX98i/K7/qHssGL7T+g6igxMNhHtcyySTe95ZVYqZbjWOtI6OSZ1xuY03kGM RXCng8zyvUnB43p4r7KaZo/QelTMfD2DONq0Cp3O8unWo2Vui/qxKh9cLahkOM2f+f kpwwOiwCHxAKA== Archived-At: 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, 26 Jan 2016 16:30:56 -0000 Russ, Are you aware of RFC5626? It provides an explicit mechanism for redundant registration paths. Thanks, Paul On 1/25/16 6:23 PM, Penar, Russell wrote: > Thanks for the reply Dale, comments in line. > Regards, > Russ > > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Monday, January 25, 2016 1:23 PM > To: Penar, Russell > Cc: sipcore@ietf.org > Subject: Re: [sipcore] sip/tcp with primary & secondary outbound proxies (behavior upon receipt of tcp rst) > > "Penar, Russell" writes: >> I'm seeing non-ideal behavior from cpe and hoping this group can >> provide guidelines specific to the scenario below, and ultimately >> standardize ideal cpe behavior for the given context. I haven't found >> any specifications defining the ideal behavior, and it was suggested >> during sipnoc to contact sipcore as an appropriate next step. > > Unfortunately, Sipcore doesn't so much define ideal behavior as define the behaviors that a UA (CPE) is permitted to have. Within that context, a UA can drop a call whenever it chooses. In the use cases we see, the general advice is "If the UA is behaving in a way that provides a poor user experience, buy a different type of UA." That usually gives the UA manufacturers incentive to improve their UAs. > > RP - That's a fair stance, we have seen at least one vendor move to the "ideal" behavior presumably from customer pressure. Would it also be fair to state Sipcore defines behavior that a UA is not permitted to have? Perhaps what I'm really trying to get here is a MUST NOT statement against connecting to secondary targets upon receipt of a TCP RST. > >> Where a standing call is setup against the primary sbc; after a >> primary sbc mated pair failover, calls are at risk of being dropped if >> a tcp connection is not established back to the primary sbc. This can >> be due to session audits from the platform, or more specific to my ask >> is a cpe re-Invite scenario. For example, when cpe puts standing call >> on hold (after sbc failover), the sbc target for re-establishing the >> signaling tcp session is critical. >> >> I've seen cpe exhibit ideal behavior, where upon receipt of tcp rst >> the cpe connects back to the primary sbc. In that ideal scenario, the >> call stays up, mid-call control doesn't fail, etc. And I've seen >> non-ideal behavior where once the cpe attempts to put the call on >> hold, it reacts to the tcp rst by failing over to the secondary sbc >> and dropping the standing call. Fwiw, I'm told the vendor exhibiting >> the ideal behavior only recently began to do so (reportedly from >> customer pressure to properly support geo-redundant setups as >> described above). > > As a general rule, the failure of a TCP connection does not change the state of any SIP call. But if the UA wants to issue a re-INVITE for an existing call, it will send an INVITE request using the "route set" of the call. The UA learns the route set during call set-up; the devices on the path that the INVITE request takes will add Record-Route or Contact headers containing addresses; the collection of these headers is the route set and specifies the path which all further requests for that call will take. > > Since the SBC wants to see further requests for the call, it adds an address for itself in either a Record-Route header or a Contact header (depending on the technical details of the SBC). If you want the calls to fail over, it's critical that the address is one that routes to both the primary and secondary SBCs -- it is a host name which DNS maps to the addresses of both SBCs. > > RP - We're using DNS SRV to support geo-redundant access SBCs. The "route set" doesn't appear to be an issue, as the re-Invite does go to the correct location (primary), but upon receipt of the TCP RST the UA immediately drops the call, sets up a new TCP connection to the secondary and Registers. The UA gathers primary and secondary targets (for outbound proxy FQDN) upon boot up and then accordingly based on TTL. > > If the address is only for the SBC involved in the call setup, if that SBC goes down and the UA attempts a re-INVITE, the UA can't send the re-INVITE. The UA may decide to tear down the call, but some UAs don't -- instead, they assume that if the call truly fails, the user will hang up and so they maintain the call until the user hangs up. > > RP - I agree in principle when using SRV the SBC's Contact/R-R should have the SBC FQDN and not a specific IP address. With use of outbound proxy, I haven't seen issues with UA's not failing over when Contact (for example) is returned with only the SBC (HA pair IP address) involved in the call setup. > > It's understood that if a UA attempts to send a request on a TCP connection and the TCP connection produces some sort of error that the UA should either attempt to reestablish the TCP connection or send the request to an alternative destination (e.g., the other SBC). This is specified in RFC 3263 section 4.3: > > For SIP requests, failure occurs if the transaction layer reports a > 503 error response or a transport failure of some sort (generally, > due to fatal ICMP errors in UDP or connection failures in TCP). > Failure also occurs if the transaction layer times out without ever > having received any response, provisional or final (i.e., timer B or > timer F in RFC 3261 [1] fires). If a failure occurs, the client > SHOULD create a new request, which is identical to the previous, but > has a different value of the Via branch ID than the previous (and > therefore constitutes a new SIP transaction). That request is sent > to the next element in the list as specified by RFC 2782. > > RP - Could we amend this section of 3263, to reflect a UA SHOULD (specific to context of TCP) try the current element where a SIP dialog is established before trying the next element per 2782? > > Dale > > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Jan 26 09:34:30 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 CF1891A90B4 for ; Tue, 26 Jan 2016 09:34:29 -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 4d96YxnRkQAW for ; Tue, 26 Jan 2016 09:34:29 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 ABA491A90AA for ; Tue, 26 Jan 2016 09:34:28 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id r129so114209485wmr.0 for ; Tue, 26 Jan 2016 09:34:28 -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=FLRhtu3VC5Ea3cXR1Ow08pKgyLEIWcrsQG3T+Z4BPxY=; b=cklgQVa6KzXbit0o0IYpD0lH3zvB3QatvhZTGHOx11mhgieQ8ccCC5UWQSliVHwAMj jvCeYMuuj92bEWDFar739nbsGXvMEvXfBLWgK/muk8QODsLhW2T4wfXCbzA4StxqhSJf QOo5jCibLy9eTTUfzSF43P2Al5hRrHE5n0Y6kFeeK/pmPwA1fp81z+A4Xln4j01ipwHw Nt4dumzAQq9eD80uFJjIldK115qvUcDYhDHX7ShsBao210Cz6biTIZX4lu6HFWE7kuV+ rL2jFfnJZAHEbFT+3/ve+BrCjDN73xm/i9m/sTysM6D0tKXDwFxg0XQ7NfTax7NWFcbS paFA== 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=FLRhtu3VC5Ea3cXR1Ow08pKgyLEIWcrsQG3T+Z4BPxY=; b=ci1VWH4rreg6P1M/XE+Xnf8NzJr6yKyEon44IWSowSnYEAdTY08xm31HrNNc25qxh7 TnMfkiTvinkf7WiimyMefVK1c8SW59m6v/5/cfi2VGsG/J0xGFDRKKkGWnTfkKzw99h6 t82h+bhWvfx8Vr/34V17yiAU3390h7Poj+7KMcfsR/Kc/SV67c8TiSIxUFXD0ikplmCK JV8u4W433zIk1lEDNNI7VKkmJrEDAORZIOZm7FQXdYK65KQgJeCU6/0ZYW/Y01i0N63k uDJYxjLMBBoVWAC6rz2jLUk8qXhK9HwGw8PZn3E/JaA6aNOwMo3PBeclrImrYLL56+MZ beOg== X-Gm-Message-State: AG10YOQuXJ0yWsMyBEsNA9u/kTRC1yEfOHrnoUFichNLCYNJ8GiuSFaki79EJz2sCBUDRVsgMxH2yEMEZUsk9MLd X-Received: by 10.194.21.101 with SMTP id u5mr28705070wje.53.1453829667217; Tue, 26 Jan 2016 09:34:27 -0800 (PST) From: Brett Tate References: <87fuxmbh3d.fsf@hobgoblin.ariadne.com> 29e056ac5c7ce97a51afee4e75e6619b@mail.gmail.com In-Reply-To: 29e056ac5c7ce97a51afee4e75e6619b@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLcQjfBTjYantPy1j2iqiDij56t1Zz4B6lAgAAqFDA= Date: Tue, 26 Jan 2016 12:34:26 -0500 Message-ID: To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: branch parameters 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, 26 Jan 2016 17:34:30 -0000 Hi, Sorry about resend. After reading the raised issue again, you can ignore my question since I now understand the service interaction issue that you were raising. > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Tuesday, January 26, 2016 11:14 AM > To: 'Dale R. Worley'; 'sipcore@ietf.org' > Subject: RE: [sipcore] draft-ietf-sipcore-dns-dual-stack: branch parameters > > Hi, > > > A better user experience would be obtained if all copies of the > > request were sent with the same branch parameter, so that the > > destination will know to ignore all but the first copy that it > > received. > > Although merged request handling can potentially be improved within SIP, I'm > not sure that the proposed improvement is better than current behavior. > However, this draft will definitely cause more merged request situations (and > delays before advancing to reachable server). I'm also not sure if the > proposed improvement actually addresses the real issue. Are you experiencing > a transaction correlation issue or just a lack of 1xx to compliantly allow > you to send CANCEL? > > Changing the branch allows the sender to know which destination actually > worked. Without that knowledge, it would not know the destination and port > for sending ACK-for-non-2xx and/or CANCEL (unless added something else to the > Via). > > The requests can take different paths before merging. Ignoring requests from > the different path can cause the path to appear non responsive (although > intermediary can send 100 response to reduce some of the side effects). > > Thanks, > Brett From nobody Tue Jan 26 12:39:38 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 B3A221B2D43 for ; Tue, 26 Jan 2016 12:39:37 -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, 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 q_Ty9Mpkmyrl for ; Tue, 26 Jan 2016 12:39:35 -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 66CFB1B2D40 for ; Tue, 26 Jan 2016 12:39:35 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id u0QKdXNS013798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2016 13:39:33 -0700 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 103951E01AA; Tue, 26 Jan 2016 14:39:28 -0600 (CST) Received: from lxdnp31k.corp.intranet (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id D870D1E01F7; Tue, 26 Jan 2016 14:39:27 -0600 (CST) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u0QKdRUZ017929; Tue, 26 Jan 2016 13:39:27 -0700 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u0QKdRHN017903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Jan 2016 13:39:27 -0700 Received: from PDDCWMBXEX504.ctl.intranet ([fe80::f8d9:8c16:7f70:657b]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Tue, 26 Jan 2016 13:39:27 -0700 From: "Penar, Russell" To: "'pkyzivat@alum.mit.edu'" Thread-Topic: [sipcore] sip/tcp with primary & secondary outbound Thread-Index: AQHRWHXVeJ510xr1/Ee1exRG+3AHCw== Date: Tue, 26 Jan 2016 20:39:26 +0000 Message-ID: <12C684AA1283B949BD80AC8273CF3A723F580028@PDDCWMBXEX504.ctl.intranet> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] 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 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, 26 Jan 2016 20:39:37 -0000 Thank you Paul, I am aware and somewhat familiar with 5626, largely for the Keep-Alive cont= ent. I'm missing the details in 5626 addressing the TCP/RST issue for an HA prox= y as I described. 3.3 gets close with a possible solution, however in practice UAs I encounte= r have a single outbound proxy field and don't support dual registration pa= ths. If they did, I believe my scenario is still an issue given most comme= rcial proxies are stateful b2bua's (SBCs) and the second path won't recogni= ze the session re-Invite as valid. Regards, Russ -----Original Message----- ---------------------------------------------------------------------- Date: Tue, 26 Jan 2016 11:30:52 -0500 From: Paul Kyzivat To: sipcore@ietf.org Subject: Re: [sipcore] sip/tcp with primary & secondary outbound proxies (behavior upon receipt of tcp rst) Message-ID: <56A79F3C.1060201@alum.mit.edu> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed Russ, Are you aware of RFC5626? It provides an explicit mechanism for redundant r= egistration paths. Thanks, Paul On 1/25/16 6:23 PM, Penar, Russell wrote: > Thanks for the reply Dale, comments in line. > Regards, > Russ > > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Monday, January 25, 2016 1:23 PM > To: Penar, Russell > Cc: sipcore@ietf.org > Subject: Re: [sipcore] sip/tcp with primary & secondary outbound > proxies (behavior upon receipt of tcp rst) > > "Penar, Russell" writes: >> I'm seeing non-ideal behavior from cpe and hoping this group can >> provide guidelines specific to the scenario below, and ultimately >> standardize ideal cpe behavior for the given context. I haven't >> found any specifications defining the ideal behavior, and it was >> suggested during sipnoc to contact sipcore as an appropriate next step. > > Unfortunately, Sipcore doesn't so much define ideal behavior as define th= e behaviors that a UA (CPE) is permitted to have. Within that context, a U= A can drop a call whenever it chooses. In the use cases we see, the genera= l advice is "If the UA is behaving in a way that provides a poor user exper= ience, buy a different type of UA." That usually gives the UA manufacturer= s incentive to improve their UAs. > > RP - That's a fair stance, we have seen at least one vendor move to the "= ideal" behavior presumably from customer pressure. Would it also be fair t= o state Sipcore defines behavior that a UA is not permitted to have? Perha= ps what I'm really trying to get here is a MUST NOT statement against conne= cting to secondary targets upon receipt of a TCP RST. > >> Where a standing call is setup against the primary sbc; after a >> primary sbc mated pair failover, calls are at risk of being dropped >> if a tcp connection is not established back to the primary sbc. This >> can be due to session audits from the platform, or more specific to >> my ask is a cpe re-Invite scenario. For example, when cpe puts >> standing call on hold (after sbc failover), the sbc target for >> re-establishing the signaling tcp session is critical. >> >> I've seen cpe exhibit ideal behavior, where upon receipt of tcp rst >> the cpe connects back to the primary sbc. In that ideal scenario, >> the call stays up, mid-call control doesn't fail, etc. And I've seen >> non-ideal behavior where once the cpe attempts to put the call on >> hold, it reacts to the tcp rst by failing over to the secondary sbc >> and dropping the standing call. Fwiw, I'm told the vendor exhibiting >> the ideal behavior only recently began to do so (reportedly from >> customer pressure to properly support geo-redundant setups as >> described above). > > As a general rule, the failure of a TCP connection does not change the st= ate of any SIP call. But if the UA wants to issue a re-INVITE for an exist= ing call, it will send an INVITE request using the "route set" of the call.= The UA learns the route set during call set-up; the devices on the path t= hat the INVITE request takes will add Record-Route or Contact headers conta= ining addresses; the collection of these headers is the route set and speci= fies the path which all further requests for that call will take. > > Since the SBC wants to see further requests for the call, it adds an addr= ess for itself in either a Record-Route header or a Contact header (dependi= ng on the technical details of the SBC). If you want the calls to fail ove= r, it's critical that the address is one that routes to both the primary an= d secondary SBCs -- it is a host name which DNS maps to the addresses of bo= th SBCs. > > RP - We're using DNS SRV to support geo-redundant access SBCs. The "rout= e set" doesn't appear to be an issue, as the re-Invite does go to the corre= ct location (primary), but upon receipt of the TCP RST the UA immediately d= rops the call, sets up a new TCP connection to the secondary and Registers.= The UA gathers primary and secondary targets (for outbound proxy FQDN) up= on boot up and then accordingly based on TTL. > > If the address is only for the SBC involved in the call setup, if that SB= C goes down and the UA attempts a re-INVITE, the UA can't send the re-INVIT= E. The UA may decide to tear down the call, but some UAs don't -- instead,= they assume that if the call truly fails, the user will hang up and so the= y maintain the call until the user hangs up. > > RP - I agree in principle when using SRV the SBC's Contact/R-R should hav= e the SBC FQDN and not a specific IP address. With use of outbound proxy, = I haven't seen issues with UA's not failing over when Contact (for example)= is returned with only the SBC (HA pair IP address) involved in the call se= tup. > > It's understood that if a UA attempts to send a request on a TCP connecti= on and the TCP connection produces some sort of error that the UA should ei= ther attempt to reestablish the TCP connection or send the request to an al= ternative destination (e.g., the other SBC). This is specified in RFC 3263= section 4.3: > > For SIP requests, failure occurs if the transaction layer reports a > 503 error response or a transport failure of some sort (generally, > due to fatal ICMP errors in UDP or connection failures in TCP). > Failure also occurs if the transaction layer times out without ever > having received any response, provisional or final (i.e., timer B or > timer F in RFC 3261 [1] fires). If a failure occurs, the client > SHOULD create a new request, which is identical to the previous, but > has a different value of the Via branch ID than the previous (and > therefore constitutes a new SIP transaction). That request is sent > to the next element in the list as specified by RFC 2782. > > RP - Could we amend this section of 3263, to reflect a UA SHOULD (specifi= c to context of TCP) try the current element where a SIP dialog is establis= hed before trying the next element per 2782? > > Dale > > This communication is the property of CenturyLink and may contain confide= ntial or privileged information. Unauthorized use of this communication is = strictly prohibited and may be unlawful. If you have received this communic= ation in error, please immediately notify the sender by reply e-mail and de= stroy all copies of the communication and any attachments. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > 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 Tue Jan 26 17:50:25 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 95C4E1B3145 for ; Tue, 26 Jan 2016 17:50:23 -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 oJy3IqMm1oYo for ; Tue, 26 Jan 2016 17:50:22 -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 5AF9A1B2FE6 for ; Tue, 26 Jan 2016 17:50:22 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-04v.sys.comcast.net with comcast id ApqM1s0065Geu2801pqMv9; Wed, 27 Jan 2016 01:50:21 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-20v.sys.comcast.net with comcast id ApqL1s00W1nMCLR01pqMQs; Wed, 27 Jan 2016 01:50:21 +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 u0R1oKU3015028; Tue, 26 Jan 2016 20:50:20 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0R1oJpQ015021; Tue, 26 Jan 2016 20:50:19 -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: Brett Tate In-Reply-To: <29e056ac5c7ce97a51afee4e75e6619b@mail.gmail.com> (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 26 Jan 2016 20:50:19 -0500 Message-ID: <87wpqv7pus.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453859421; bh=IyzEeMSBll0IBXdnEB1Cba42Yw6D5H1KKDXIfJdqQQc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=W2zz0JPrDnqKI7FSjHcVSBcMkwdCV/oPOx+pkg3xeQyxcRpMR+KXh5w69A3a5i7up 5VwdnvZVn7JfQ3dQI6yL1lDx+3XwoWGxlpYMT4X8/2tRQwQbG7mETSal8YLc02vYNV S84Sk/kFpDwgb1bR0y2K1Zw9gau/QPsw1e1R1rSfqiaFL6g5GMBO2iFf+xqFKkX0Ib JqYCxJdPA0hBpADWOVS5exZ9L04/oX30SSBvSbbkYxCfmep+JU+kdLieqf3ly7jAl3 zUKPcgjSpFEGIur3Bhs4Tf7gTldKIj8Cou6wAK4uS7PShoH0dx+nKeBNm4QTWfURbD UWIaZoYWukf9w== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-dns-dual-stack: branch parameters 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, 27 Jan 2016 01:50:23 -0000 Brett Tate writes: > Changing the branch allows the sender to know which destination actually > worked. Yes, that's true. I've been assuming without thinking about it that if a 100 response arrives, the recipient can tell from the source address/port of the 100 what destination/address port was used for the request that is being responded to. But of course, that's not true. And that is the fatal flaw in my proposal, unless "added something else to the Via", as you say. Dale From nobody Tue Jan 26 18:11: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 2070D1B33A0 for ; Tue, 26 Jan 2016 18:11:05 -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 MHUS7g1YpEHC for ; Tue, 26 Jan 2016 18:11:03 -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 C74981B339F for ; Tue, 26 Jan 2016 18:11:03 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-12v.sys.comcast.net with comcast id Aq9x1s0032LrikM01qB3xT; Wed, 27 Jan 2016 02:11:03 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id AqB21s0041nMCLR01qB2Rn; Wed, 27 Jan 2016 02:11:02 +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 u0R2B1R3017158; Tue, 26 Jan 2016 21:11:01 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0R2B13U017153; Tue, 26 Jan 2016 21:11:01 -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: <12C684AA1283B949BD80AC8273CF3A723F57F803@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 26 Jan 2016 21:11:01 -0500 Message-ID: <87mvrr7owa.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453860663; bh=GW+97cCdsqjhb1reuX2nyNWMdRZJ7YV7+h/XR99CPts=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=NqCIAQHgm4yxlt1QIQHifoxjOprh44fKEnItzF2MMK62o77H/eq7Zb6SO4cIj8nFo sHkTUFPtkfn0Axu6BW+Xf6DlKE5HR1DNoo3LDPrLsqwcWSXojcSvyZ42kw5kw2vGFC 4g9BDnA3u+/jfytq1Ao57HMrsdB39r3FTny5pVZWxsVA3LISAGLEA9mb2fxl2nn8vW LJqTsM+xU8nhlBnZMfwooeRt2F6RMzlCI38CNhmJmREQ5z7L1wHKC1bX5k7k+b8Olu 14rbLVBiWEKvaoKgOQy8mgFlObA/QYqq6MktNeLOmtalJwK9LGLIogSkImvMrl5JbF bEQ7vavV9oG3A== 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: Wed, 27 Jan 2016 02:11:05 -0000 "Penar, Russell" writes: > RP - That's a fair stance, we have seen at least one vendor move to > the "ideal" behavior presumably from customer pressure. Would it also > be fair to state Sipcore defines behavior that a UA is not permitted > to have? It's true that Sipcore defines behavior that a UA is not permitted to have, because that is the logical negation of the behavior that it is required to have. > Perhaps what I'm really trying to get here is a MUST NOT statement > against connecting to secondary targets upon receipt of a TCP RST. I don't think that there is any intention to make such a requirement. In principle, a UA has to contact targets in the order specified by RFC 3263, e.g., the SRV records for the URI, but in practice -- given transient network failures -- there can be no guarantee. It's not clear to me what that matters to you. You wrote: > Most, if not all, vendor sbc mated pairs maintain signaling/media state, > but not tcp state (reportedly doing so is significantly hard/expensive). If the SBCs share call (signaling/media) state, then the re-INVITE doesn't have to go to the same SBC that the original INVITE did. On the other hand, if updates to a call must be made at the same SBC that the call was established (that is, if they don't share signaling state), then an SBC should Record-Route itself with a URI which routes to itself only. And in that case, if the UA's TCP connection to the SBC fails, it will be forced to reestablish a TCP connection to that SBC, because the URI in the route set only routes to that address. > RP - We're using DNS SRV to support geo-redundant access SBCs. The > "route set" doesn't appear to be an issue, as the re-Invite does go to > the correct location (primary), but upon receipt of the TCP RST the UA > immediately drops the call, sets up a new TCP connection to the > secondary and Registers. The UA gathers primary and secondary targets > (for outbound proxy FQDN) upon boot up and then accordingly based on > TTL. That's a strange UA; it seems to consider the secondary SBC to be a different destination from the primary SBC, rather than being two destination addresses for one destination URI. > RP - Could we amend this section of 3263, to reflect a UA SHOULD > (specific to context of TCP) try the current element where a SIP > dialog is established before trying the next element per 2782? I don't think there would be much support for that, at least not without considerably more justification. What I don't seem to be understanding is how the two SBCs are presented to the UA. You write as if they are redudant deeply in SIP, so that they share dialog (signaling) state. In that case, there is some URI which maps to *both* of them, and the UA is told to register at that one URI. Of course, if the UA needs to update a call, it can send the re-INVITE to either SBC, because both SBCs can manage the state of the call. But your failure mode sounds like the UA is told of the two SBCs separately, and doesn't treat them as alternative addresses for the "same" destination. Of course, in that case, the UA doesn't know that it can send re-INVITEs to the secondary SBC to update calls that were placed through the primary SBC. Dale From nobody Wed Jan 27 12:52: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 817431ABC10 for ; Wed, 27 Jan 2016 12:52:52 -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, 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 WtTfb1daQENB for ; Wed, 27 Jan 2016 12:52:50 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 933481A930A for ; Wed, 27 Jan 2016 12:52:48 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id u0RKqcb3034239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2016 14:52:38 -0600 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 91DD11E0073; Wed, 27 Jan 2016 14:52:33 -0600 (CST) Received: from lxomp06u.corp.intranet (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 73E031E005B; Wed, 27 Jan 2016 14:52:33 -0600 (CST) Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id u0RKqXiL027616; Wed, 27 Jan 2016 14:52:33 -0600 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id u0RKqXwn027608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jan 2016 14:52:33 -0600 Received: from PDDCWMBXEX504.ctl.intranet ([fe80::f8d9:8c16:7f70:657b]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Wed, 27 Jan 2016 13:52:32 -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: AQHRWKf31DcvmLeEEEu3lrbXwSyFPZ8PzaDA Date: Wed, 27 Jan 2016 20:52:32 +0000 Message-ID: <12C684AA1283B949BD80AC8273CF3A723F590EB6@PDDCWMBXEX504.ctl.intranet> References: <12C684AA1283B949BD80AC8273CF3A723F57F803@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) <87mvrr7owa.fsf@hobgoblin.ariadne.com> In-Reply-To: <87mvrr7owa.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: Wed, 27 Jan 2016 20:52:52 -0000 Thank you Dale, Apologies for any confusion, I worked to clear it up in line below. Regards, Russ -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com] Sent: Tuesday, January 26, 2016 7: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: > RP - That's a fair stance, we have seen at least one vendor move to > the "ideal" behavior presumably from customer pressure. Would it also > be fair to state Sipcore defines behavior that a UA is not permitted > to have? It's true that Sipcore defines behavior that a UA is not permitted to have,= because that is the logical negation of the behavior that it is required t= o have. > Perhaps what I'm really trying to get here is a MUST NOT statement > against connecting to secondary targets upon receipt of a TCP RST. I don't think that there is any intention to make such a requirement. In principle, a UA has to contact targets in the order specified by RFC 326= 3, e.g., the SRV records for the URI, but in practice -- given transient ne= twork failures -- there can be no guarantee. RP - It's a very specific case, where the single primary target in SRV cons= ists of 2 SBCs in a Highly Available active/hot-standby configuration. We = want to steer UA makers away from taking a simple TCP RST as a reason to mo= ve to the next target. In doing so, they will force active calls to be dro= pped. I see value in trying a TCP connection with the primary before movin= g to the next and dropping calls. It's not clear to me what that matters to you. You wrote: > Most, if not all, vendor sbc mated pairs maintain signaling/media > state, but not tcp state (reportedly doing so is significantly hard/expen= sive). If the SBCs share call (signaling/media) state, then the re-INVITE doesn't = have to go to the same SBC that the original INVITE did. On the other hand, if updates to a call must be made at the same SBC that t= he call was established (that is, if they don't share signaling state), the= n an SBC should Record-Route itself with a URI which routes to itself only.= And in that case, if the UA's TCP connection to the SBC fails, it will be= forced to reestablish a TCP connection to that SBC, because the URI in the= route set only routes to that address. > RP - We're using DNS SRV to support geo-redundant access SBCs. The > "route set" doesn't appear to be an issue, as the re-Invite does go to > the correct location (primary), but upon receipt of the TCP RST the UA > immediately drops the call, sets up a new TCP connection to the > secondary and Registers. The UA gathers primary and secondary targets > (for outbound proxy FQDN) upon boot up and then accordingly based on > TTL. That's a strange UA; it seems to consider the secondary SBC to be a differe= nt destination from the primary SBC, rather than being two destination addr= esses for one destination URI. RP - In the context of how it gathers the targets it is a very typical UA, = market leader type. > RP - Could we amend this section of 3263, to reflect a UA SHOULD > (specific to context of TCP) try the current element where a SIP > dialog is established before trying the next element per 2782? I don't think there would be much support for that, at least not without co= nsiderably more justification. RP - Yeah, I think I wasn't clear enough in my problem statement (rely too = much on pictures in other forums). This is a very common deployment model = for medium to large VoIP providers, at least with respect to how the SBCs a= re deployed. What I don't seem to be understanding is how the two SBCs are presented to = the UA. You write as if they are redudant deeply in SIP, so that they shar= e dialog (signaling) state. In that case, there is some URI which maps to = *both* of them, and the UA is told to register at that one URI. Of course,= if the UA needs to update a call, it can send the re-INVITE to either SBC,= because both SBCs can manage the state of the call. RP - Each target in DNS (e.g. SBC1- weighted primary target and SBC2- weigh= ted secondary target) consists of a mated pair of SBCs. The mated pair is = deeply redundant in SIP, but not in TCP. The lack of TCP redundancy is wha= t leads us to the TCP RST scenario. One of the mated pair has faulted or b= een taken down for maintenance; RTP is still flowing over UDP via the now a= ctive second mate in the pair, and given a new TCP connection the SIP chann= el would be healthy as well. So the UA is causing an unnecessary call drop= by considering the RST a complete primary target failure and moving on. But your failure mode sounds like the UA is told of the two SBCs separately= , and doesn't treat them as alternative addresses for the "same" destinatio= n. Of course, in that case, the UA doesn't know that it can send re-INVITE= s to the secondary SBC to update calls that were placed through the primary= SBC. RP - The destination is a single FQDN - e.g. sbc.carrier.com. DNS resolves= that to two weighted targets, essentially a primary and failover scheme. = The UA is correct in assuming once it connects to the second target all bet= s are off with any existing dialogs. 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 Wed Jan 27 17:42:32 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 B27841A01E7 for ; Wed, 27 Jan 2016 17:42:25 -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 95kTZ2-69voh for ; Wed, 27 Jan 2016 17:42:24 -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 665351A01D7 for ; Wed, 27 Jan 2016 17:42:24 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-07v.sys.comcast.net with comcast id BDgf1s0054ueUHc01DiPyA; Thu, 28 Jan 2016 01:42:23 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-03v.sys.comcast.net with comcast id BDiN1s0081nMCLR01DiPxv; Thu, 28 Jan 2016 01:42:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u0S1gMCj001808; Wed, 27 Jan 2016 20:42:22 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0S1gLI8001805; Wed, 27 Jan 2016 20:42:21 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Penar\, Russell" In-Reply-To: <12C684AA1283B949BD80AC8273CF3A723F590EB6@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 27 Jan 2016 20:42:21 -0500 Message-ID: <87zivq5vk2.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453945343; bh=UGWgRau7TY2A1QvY8+qXa5tZUPHCCPPE0TKUh+MTRQA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=mTAKd2wbqqneJhJIN4Z2BdQE0uDVN0VgrwRQgpvOcztB+Xwm+FRkLLK68V/ORWcWe hMmBe838Vv/WSQC8fzuDszGDoHn7SCDmKn5PouC2Bje896WfmB+mTBcicqDgp5iX2W +gd5/ZztL98Fx/mPhrldp64+PpEa2PJjtzUWXb3acxWTZmaRYWsqYc/jiHdc2bt/DD S5VKVzd+WCii5T24I12N+bIxC5Oo7XyUT335dFz01427ix+em8+G4e/OaI7Q6+iLmJ Ciz2nMch39Vprj5/eCGx7wi4opp0AZJbU4nvWoGXSXK3UqqjzzzMl7KqDzkVFjCzcu ZO22hgweqPNkQ== 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: Thu, 28 Jan 2016 01:42:25 -0000 "Penar, Russell" writes: > RP - It's a very specific case, where the single primary target in SRV > consists of 2 SBCs in a Highly Available active/hot-standby > configuration. We want to steer UA makers away from taking a simple > TCP RST as a reason to move to the next target. In doing so, they > will force active calls to be dropped. I see value in trying a TCP > connection with the primary before moving to the next and dropping > calls. If I understand you correctly, the UA is configured with a single FQDN, which maps through SRV records to two SBCs. The SBCs share signaling and media state. Initially, the UA creates a call by contacting one SBC -- from the SIP point of view, it establishes a TCP connection to one of the addresses associated with the FQDN for the proxy to which it is to send calls. In the failure case, the first SBC goes down. Since the SBCs share media state, the media continues to flow and the call state of the dialog is maintained at the UA, at the SBCs collectively, and at the far-end UA. Now, the UA attempts a re-INVITE. It sends the request to the first address for the Record-Route URI, which is the common FQDN of the two SBCs. Since the UA has a TCP connection to this address, it uses this TCP connection. This TCP send fails immediately with an RST. At this point, the UA should attempt to resend the request, and it should attempt to contact both addresses for the SBCs -- a new TCP connection to the first SBC tried as the TCP connection may have been lost due to a transient error, and the second SBC should be contacted as it is the other address for the FQDN. Since the SBCs share signaling/media state, the dialog can be updates via either of them, so it doesn't matter which SBC the UA sends the re-INVITE to. It seems that what happens is that the UA drops the call and then tries to contact the second SBC. I see that there are two possible situations, which require different solutions: 1. If the Record-Route is the FQDN for both SBCs, the UA must not conclude that the dialog is broken until it has attempted to contact every address for the Record-Route FQDN and has failed to reach all of the addresses. 2. If the Record-Route is a FQDN or address for the primary SBC, then the UA is behaving correctly, since the dialog can only be updated through that SBC. In that case, the fix is to change the URI that is put in the Record-Route by the SBC. Dale From nobody Wed Jan 27 19:07: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 A864F1B3125 for ; Wed, 27 Jan 2016 19:07: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_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 gj5s0xlWEYxm for ; Wed, 27 Jan 2016 19:07:15 -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 67D941B3124 for ; Wed, 27 Jan 2016 19:07:14 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-01v.sys.comcast.net with comcast id BF741s0042TL4Rh01F7DqN; Thu, 28 Jan 2016 03:07:13 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-17v.sys.comcast.net with comcast id BF7C1s00M1nMCLR01F7DLw; Thu, 28 Jan 2016 03:07:13 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u0S37Ce4010852 for ; Wed, 27 Jan 2016 22:07:12 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0S37B7J010849; Wed, 27 Jan 2016 22:07:11 -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: Wed, 27 Jan 2016 22:07:11 -0500 Message-ID: <87wpqu5rmo.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453950433; bh=TsAR5Wgz7tB2+nuUrsuKZj2vaguYW4OvnJ9nCJN2mHg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=dnXjzKjCDxjRtTU7hAoRUjtL2ifMhQYCBWrFW5lgKPuUwEeWTDmQsuiRZEvYscfjx 4ybtvCr0dxSpWCWGFDVCK4zFj2QJO84j7VSdJlHfgXtqTqtEHDpllKxMNXEmQgxJiV ivVd3ax+RC+gb8b8VZLL65HOQi2JKw578Xa6N+6KT0pXny6WYRldSJYowyKnmS1eF+ f87Mx2BoEZIAqWa4cu3IA52+eeozRmtprKC+yoW0i9ob/y37j1F7qTAQptoL4gt9lv 9/QAN4YV4noK4qCONrFzWsSO7gWn+5JJTprVUvY3xbYfGJhNElqOxt5EXi+eyVWB7E icEn87ImF0lvw== Archived-At: Subject: [sipcore] First draft of 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: Thu, 28 Jan 2016 03:07:16 -0000 I've made a first draft of draft-ietf-sipcore-dns-dual-stack-03. This message is to invite people to look at it. I think that it addresses all the substantial issues that are outstanding and all that I've discovered, but I've not compared the new text with the mailing list messages to check that I've covered everything. This draft is based on the idea that it does not specify Happy Eyeballs procedures for SIP, but it cleans up a number of matters in RFC 3263 so that specifying Happy Eyeballs can be done clearly. These URLs can be used to retrieve the XML and text versions: http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-03.xml http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-03.txt A summary of the changes is given in section 9.1: 9.1. Changes from draft-ietf-sipcore-dns-dual-stack-02 to draft-ietf- sipcore-dns-dual-stack-03 Updated wording, punctuation, and capitalization in various places. Clarified that this draft does not document Happy Eyeballs for SIP, but is preparatory for it. Attempted to use "update" for text that is definitively a change to the preexisting text and "clarify" for text that is a more clear statement of the (presumed) intention of the preexisting text. Removed normative words from section 1, the introduction. Introduced definition of "address records" (taken from RFC 2782, SRV records) to allow the definition to expand to include any new address families automatically. Relocated the text requiring a client to ignore addresses that it discovers in address families it does not support from section 4.2 (which describes why the situation would arise) to section 4.1 (which describes how clients look up RRs). Clarified the interaction with RFC 6157 (source and destination address selection in IPv6) to specify what must have been intended: The major sort of the destinations is the ordering determined by priority/weight in the SRV records; the addresses derived from a single SRV record's target are minorly sorted based on RFC 6157. Removed editor's name from the acknowledgments list. Dale From nobody Wed Jan 27 19:53:11 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 0C9B41B31F8 for ; Wed, 27 Jan 2016 19:53:10 -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, 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 Yq-IIMXLlfti for ; Wed, 27 Jan 2016 19:53:08 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 45AAE1B319F for ; Wed, 27 Jan 2016 19:53:08 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id u0S3qxVO060954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2016 21:52:59 -0600 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1971E1E0071; Wed, 27 Jan 2016 20:52:54 -0700 (MST) Received: from lxdnp32k.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id F01361E004E; Wed, 27 Jan 2016 20:52:53 -0700 (MST) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id u0S3qrZ8003520; Wed, 27 Jan 2016 20:52:53 -0700 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id u0S3qrXj003517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jan 2016 20:52:53 -0700 Received: from PDDCWMBXEX504.ctl.intranet ([fe80::f8d9:8c16:7f70:657b]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Wed, 27 Jan 2016 20:52:53 -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: AQHRWW0g1DcvmLeEEEu3lrbXwSyFPZ8QPnCQ Date: Thu, 28 Jan 2016 03:52:52 +0000 Message-ID: <12C684AA1283B949BD80AC8273CF3A723F5911F1@PDDCWMBXEX504.ctl.intranet> References: <12C684AA1283B949BD80AC8273CF3A723F590EB6@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) <87zivq5vk2.fsf@hobgoblin.ariadne.com> In-Reply-To: <87zivq5vk2.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] 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: Thu, 28 Jan 2016 03:53:10 -0000 That is very close to 100% correct. The minor but significant delta is DNS= target 1 is two SBCs acting as one, in a primary/hot-standby configuration= . DNS target 2, is a separate mated-pair of SBCs. So as the UA sees things = (and in reality), the two SBCs returned in DNS do not share state for signa= ling and/or media. I'm in complete agreement with your quote just below, as I believe it start= s to get at the heart of the issue I'm raising. "Now, the UA attempts a re-INVITE. It sends the request to the first addre= ss for the Record-Route URI, which is the common FQDN of the two SBCs. Sin= ce the UA has a TCP connection to this address, it uses this TCP connection= . This TCP send fails immediately with an RST. At this point, the UA should attempt to resend the request, ... a new TCP c= onnection to the first SBC tried as the TCP connection may have been lost d= ue to a transient error.." // This last sentence is what I'm looking to enf= orce, or at least suggest officially. If existing RFCs already do so, I'd = like to review with you and perhaps request to make the language clearer fo= r UA manufacturers and consumer (for reference to said vendors). Regards, Russ -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com] Sent: Wednesday, January 27, 2016 6:42 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: > RP - It's a very specific case, where the single primary target in SRV > consists of 2 SBCs in a Highly Available active/hot-standby > configuration. We want to steer UA makers away from taking a simple > TCP RST as a reason to move to the next target. In doing so, they > will force active calls to be dropped. I see value in trying a TCP > connection with the primary before moving to the next and dropping > calls. If I understand you correctly, the UA is configured with a single FQDN, whi= ch maps through SRV records to two SBCs. The SBCs share signaling and medi= a state. Initially, the UA creates a call by contacting one SBC -- from the SIP poin= t of view, it establishes a TCP connection to one of the addresses associat= ed with the FQDN for the proxy to which it is to send calls. In the failure case, the first SBC goes down. Since the SBCs share media s= tate, the media continues to flow and the call state of the dialog is maint= ained at the UA, at the SBCs collectively, and at the far-end UA. Now, the UA attempts a re-INVITE. It sends the request to the first addres= s for the Record-Route URI, which is the common FQDN of the two SBCs. Sinc= e the UA has a TCP connection to this address, it uses this TCP connection.= This TCP send fails immediately with an RST. At this point, the UA should attempt to resend the request, and it should a= ttempt to contact both addresses for the SBCs -- a new TCP connection to th= e first SBC tried as the TCP connection may have been lost due to a transie= nt error, and the second SBC should be contacted as it is the other address= for the FQDN. Since the SBCs share signaling/media state, the dialog can = be updates via either of them, so it doesn't matter which SBC the UA sends = the re-INVITE to. It seems that what happens is that the UA drops the call and then tries to = contact the second SBC. I see that there are two possible situations, which require different solutions: 1. If the Record-Route is the FQDN for both SBCs, the UA must not conclude = that the dialog is broken until it has attempted to contact every address f= or the Record-Route FQDN and has failed to reach all of the addresses. 2. If the Record-Route is a FQDN or address for the primary SBC, then the U= A is behaving correctly, since the dialog can only be updated through that = SBC. In that case, the fix is to change the URI that is put in the Record-= Route by the SBC. 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 Thu Jan 28 17:44:59 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 4962F1B3669 for ; Thu, 28 Jan 2016 17:44:58 -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 2kuSiISlNEgR for ; Thu, 28 Jan 2016 17:44:56 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742851B3668 for ; Thu, 28 Jan 2016 17:44:56 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-04v.sys.comcast.net with comcast id Bdk41s0022XD5SV01dkvnF; Fri, 29 Jan 2016 01:44:55 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-20v.sys.comcast.net with comcast id Bdku1s00G1nMCLR01dkuix; Fri, 29 Jan 2016 01:44:55 +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 u0T1isKM022584; Thu, 28 Jan 2016 20:44:54 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0T1irFr022581; Thu, 28 Jan 2016 20:44:53 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Russell.Penar@centurylink.com References: <12C684AA1283B949BD80AC8273CF3A723F590EB6@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) <87zivq5vk2.fsf@hobgoblin.ariadne.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 28 Jan 2016 20:44:53 -0500 Message-ID: <8760yd5fca.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1454031895; bh=ifMVf+J3XJNcI8TWtDcwP2nONCsF7uY3wk5S+/MC52Y=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Fk/8ChHr05ug9MB6vvm69Dmr+YHWex6QtN0PCvHiu36Pwr6l/E8bFj757z0mbVnsY VDy1nnr+z9aG1EeMHYH6OpAlXoIw51/YTacp4ruIUl1HryRnN5AA3qB5hPwUiQmJkI /q18ogbzcBvVjyHCz3z7hNUXOYXFLRUqQt1dD0E3dKCpNTUW9xF9K0IhRilwoznEPD 6GLu6k+Dr7dCh1ziYNf26lSBW7N4KAdZ4zJNR7+I32IPgOIl/ysCtxGxbGC/gKBAl6 ZkNGEoMXGKF3UppxSe8TSNQWtwUAC4GyLbV+bthg0huKq7tfiOPScmdn3z35gCTHRd 9CQr4BmGPYy/g== 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, 29 Jan 2016 01:44:58 -0000 "Penar, Russell" writes: > That is very close to 100% correct. The minor but significant delta > is DNS target 1 is two SBCs acting as one, in a primary/hot-standby > configuration. DNS target 2, is a separate mated-pair of SBCs. So as > the UA sees things (and in reality), the two SBCs returned in DNS do > not share state for signaling and/or media. [trimmed] OK, now I understand the configuration: There are two *pairs* of SBCs, each pair of which shares state, but the two pairs do not. I think the situation is covered by four rules which are well-established: 1. If a device attempts to send a request to a TCP address, and the device has a previously-existing TCP connection to the address, and the attempt to send the request on that connection fails, the device must not assume that the target is unreachable, because the TCP connection might have failed due to a transient problem in the past that is now resolved. The device may only conclude that the address is unreachable (at this time) if the attempt to create and use a new TCP connection fails. 2. A device may not conclude that a URI is unreachable unless attempts to contact all of its addresses fail. 3. A device may not conclude that the signaling path of an existing call has failed unless the Record-Route/Contact URI is unreachable. 4. An intermediate device should add to an INVITE a Record-Route URI that routes to itself and all other intermediate devices that can be used to update the state of the call. Rule 4 is not a standard, but is known to be the best practice. In your case, when a call goes through an SBC, the Record-Route URI should be one that routes to both SBCs in that pair, but not to the SBCs in the other pair. Rule 3 is not a standard, and a UA may tear down a call any time it desires to. But clearly, unless the signaling path becomes unusable, the UA shouldn't tear down the call. And in some usages, it might be a better user experience to keep the call up even if the signaling path fails -- the user may prefer to have his on-hold request fail and just keep on talking. Rule 2 is what RFC 3263 specifies. Rule 1 is the core of your complaint, that the UA concludes that a TCP target is unreachable just because an old TCP connection to it isn't usable. I don't know if rule 1 is specified anywhere, but this sort of thing is a known problem in any situation when using a persistent connection, and the proper recovery from it (attempting to reestablish the connection) is well-known as the way to recover from it. Of course, the UA my decide to attempt first to contact the other address for the Record-Route URI, that is, the second SBC of the pair, on the grounds that the first address seems to be less reliable. (The UA has latitude in what order to contact the addresses for the URI.) If that is successful, by rules 2 and 3 it should never tear down the call, since the UA has successfully contacted the Record-Route URI. Dale From nobody Fri Jan 29 08:06: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 C58691B30DC for ; Fri, 29 Jan 2016 08:06:51 -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 k-0PPsPlYDnz for ; Fri, 29 Jan 2016 08:06:50 -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 93D3B1B30DB for ; Fri, 29 Jan 2016 08:06:50 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-07v.sys.comcast.net with comcast id Bs6W1s0012XD5SV01s6pDc; Fri, 29 Jan 2016 16:06:49 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-20v.sys.comcast.net with comcast id Bs6o1s00M1nMCLR01s6oYJ; Fri, 29 Jan 2016 16:06:49 +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 u0TG6l63015866; Fri, 29 Jan 2016 11:06:47 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u0TG6lPw015863; Fri, 29 Jan 2016 11:06: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: Russell.Penar@centurylink.com In-Reply-To: <8760yd5fca.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 29 Jan 2016 11:06:47 -0500 Message-ID: <87mvro4bfs.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1454083609; bh=vJvb1svPM7WYMelE5t040iPZvZuJOXSyx2IL+PCblbQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=B4FT1eq9sByNodecmoi/1knz20+41R7+Xzf8QTk2U+x3Ik6MLXU55sRHyQlo92uq5 bJQuSc7Rh6lgr8EqiUJRyOcXO8V44DfoSKHtQHeatFJo/hrtjFLWgCi+TqA6yPS9bl 44k0ya87tyAG1kfI9rCegucTBUDN3g0pmOmxT+3nMe4znoXD8U2rrwZVgyWz3VTo9e NNDkrAjAZFCjQq7yNIMpnp6fCJ9HH052a9S8G7IwLhPx47SntR4grSv4lzlNJtER9L SqANirdvPAtnUVxy26Ze1y7TnmIWMlwoy3bHIGQ2GvKkpJkXihGFUbgujMNduFpDld u8sFyc4jMN98g== 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, 29 Jan 2016 16:06:51 -0000 There seems to be another aspect of this: Why does the UA send a request along a TCP connection that should have been torn down already? When the SBC shuts down, the best practice would be for it to close (TCP FIN) all TCP connections it has open. In worse practice, it would force-close (TCP RST) all TCP connections it had open. In either case, the FIN or RST reaches the UA, which causes its TCP stack to mark the TCP connection closed. When the UA next wants to send a request to the SBC, it should notice that the TCP connection is already torn down and not attempt to send the request on it. Dale From nobody Fri Jan 29 14:37: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 AAB381A904A for ; Fri, 29 Jan 2016 14:37:11 -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, 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 2PTsmB6bwVCf for ; Fri, 29 Jan 2016 14:37:05 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 825721A903C for ; Fri, 29 Jan 2016 14:37:04 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id u0TMasXO026173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2016 16:36:54 -0600 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id EBD891E0072; Fri, 29 Jan 2016 15:36:48 -0700 (MST) Received: from lxdnp31k.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id DCE321E0071; Fri, 29 Jan 2016 15:36:48 -0700 (MST) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u0TMami1055312; Fri, 29 Jan 2016 15:36:48 -0700 Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id u0TMam3w055309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Jan 2016 15:36:48 -0700 Received: from PDDCWMBXEX504.ctl.intranet ([fe80::f8d9:8c16:7f70:657b]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.03.0195.001; Fri, 29 Jan 2016 15:36:48 -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: AQHRWq8N1DcvmLeEEEu3lrbXwSyFPZ8TE6cQ Date: Fri, 29 Jan 2016 22:36:47 +0000 Message-ID: <12C684AA1283B949BD80AC8273CF3A723F59E700@PDDCWMBXEX504.ctl.intranet> References: <8760yd5fca.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) <87mvro4bfs.fsf@hobgoblin.ariadne.com> In-Reply-To: <87mvro4bfs.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.40.131] 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: Fri, 29 Jan 2016 22:37:11 -0000 Agreed in principle. In practice, the SBC (multiple vendors) dies quietly = and only when the mate is contacted is the RST sent to the UA. 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 refe= rence and less back and forth with vendors who chose wrong up front. Regards, Russ -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com] Sent: Friday, January 29, 2016 9:07 AM To: Penar, Russell Cc: sipcore@ietf.org Subject: Re: [sipcore] sip/tcp with primary & secondary outbound proxies (b= ehavior upon receipt of tcp rst) There seems to be another aspect of this: Why does the UA send a request a= long a TCP connection that should have been torn down already? When the SBC shuts down, the best practice would be for it to close (TCP FIN) all TCP connections it has open. In worse practice, it would force-cl= ose (TCP RST) all TCP connections it had open. In either case, the FIN or RST reaches the UA, which causes its TCP stack t= o mark the TCP connection closed. When the UA next wants to send a request to the SBC, it should notice that = the TCP connection is already torn down and not attempt to send the request= on it. 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 Sun Jan 31 19:11: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 9DFB11A8913 for ; Sun, 31 Jan 2016 19:11:18 -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 Rt-g4CKKkEL1 for ; Sun, 31 Jan 2016 19:11:17 -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 084331A8912 for ; Sun, 31 Jan 2016 19:11:16 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-07v.sys.comcast.net with comcast id CrBC1s0012TL4Rh01rBGn0; Mon, 01 Feb 2016 03:11:16 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-17v.sys.comcast.net with comcast id CrBE1s00W1nMCLR01rBFY0; Mon, 01 Feb 2016 03:11: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 u113BERG009613; Sun, 31 Jan 2016 22:11:14 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u113BEvD009610; Sun, 31 Jan 2016 22:11:14 -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: <12C684AA1283B949BD80AC8273CF3A723F59E700@PDDCWMBXEX504.ctl.intranet> (Russell.Penar@centurylink.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 31 Jan 2016 22:11:14 -0500 Message-ID: <87mvrl15wt.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1454296276; bh=pdbMND21ThBLsXsIDoB/dYvvjfAur7ya4+VWnqTdvmE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=QQXeDxe8P/FMHYIhEWWtQT5a233IgZFxt6qSpJdosJSCkFWyY7FFTAR2MAJqxO9gX 1HpCXRDuIT6orIG66KpAZAcd/zFwWWLL8CSSwysnVXZkMMLKAGukMIF8WuaoaMxMQU /D5k/xt5Jni9ll1UYLyHD9lLtiazExPvqv0yW4Ebl44cFdNnOywrqHaeQIZ+1HEy6E qMNsYvF0S+hucGffo0QbB98KkSsNEsHOPIILV7UR2/toHtShBsoUX+21vQYOPkmYQb A5IJs+IfHWBfmK8mv2AnqcBUvCAUi/26zqb7qO7ZNsPT0J0Muo014cQM8DhYZEA9IU 1RZ20jOn9xvog== 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: Mon, 01 Feb 2016 03:11:18 -0000 "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