From nobody Thu Jul 2 14:36:12 2015 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 94F981A8783 for ; Thu, 2 Jul 2015 14:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 KXgFXL0hNTQu for ; Thu, 2 Jul 2015 14:36:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F52A1A8763 for ; Thu, 2 Jul 2015 14:36:09 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t62LZqXM099213 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Jul 2015 16:36:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Christer Holmberg" , "Paul Kyzivat" Date: Thu, 02 Jul 2015 16:35:52 -0500 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata 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, 02 Jul 2015 21:36:10 -0000 On 19 Jun 2015, at 11:01, Christer Holmberg wrote: > Hi, > >>>> Hi Roland, >>>> >>>> We could add a clarifying note. >>>> >>>> But, I don't think the note should talk about "use-cases". It >>>> should >>>> simply say that, if forking occurs, RSeq values are processed per >>>> early dialog, independently from the RSeq values on other early >>>> dialogs. >>> >>> +1 >>> >>> Note that the same is true for CSeq. It would be a very stupid >>> implementation that handled the CSeq per-dialog but not the RSeq. >> >> Note that the scope of RSeq values is a single INVITE transaction, >> not a dialog. (So, for a re-INVITE in the same dialog the RSeq value >> might turn out > to be lower than that for the INVITE that >> established the dialog.) > > Correct, that needs to be clear. > >> But that value space is owned by the UAS for the INVITE. So, from the >> perspective of the sender of the INVITE (receiver of provisional >> responses), >the value space must be managed independently for the >> combination of INVITE transaction AND dialog id. So the required >> logic is somewhat >different than what is required for CSeq. > > *Nodding like when I am not really sure I understood what you said, > but it did sound correct* :) > From this discussion, am I correct in understanding that the errata is not quite correct? If so, do people prefer that I reject the existing eratta, and let someone submit a new one? Alternatively, given that the language appears to need some thought, or at least word-smithing, do people still think it reasonable to handle this as an errata? Thanks! Ben. From nobody Thu Jul 2 22:46:06 2015 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 BC3F51B2C88 for ; Thu, 2 Jul 2015 22:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDFjFczG20Qz for ; Thu, 2 Jul 2015 22:46:04 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF011B2C79 for ; Thu, 2 Jul 2015 22:46:03 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-2c-5596219966f7 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.0F.25217.99126955; Fri, 3 Jul 2015 07:46:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Fri, 3 Jul 2015 07:46:01 +0200 From: Christer Holmberg To: Ben Campbell , Paul Kyzivat Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g///pywD//9iRUIAU+dAA//9WNoA= Date: Fri, 3 Jul 2015 05:46:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje4sxWmhBl+usFnM7zzNbrFiwwFW i68/NrE5MHv8ff+ByWPJkp9MHrN2PmEJYI7isklJzcksSy3St0vgyti39RJLwQbBiv55K5gb GB/zdjFyckgImEi0PjjDBGGLSVy4t56ti5GLQ0jgKKPE07vnWCGcRYwSnW+es3QxcnCwCVhI dP/TBmkQEfCQmPUQpIaTg1lAU+LRzr1gg4QFDCR+fHnBAlFjKHHyRDuU7Sfx+M47sHoWARWJ 9tX97CA2r4CvxMO7e5lBbCGBNUwSXw4kg9icAvYSsz/dBathBDru+6k1TBC7xCVuPZkPdbSA xJI955khbFGJl4//sULYShJrD29ngajXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDYLydhZ SFpmIWmZhaRlASPLKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAmDq45bfVDsaDzx0PMQpw MCrx8C58MzVUiDWxrLgy9xCjNAeLkjjvjM15oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY s1YpHxHSs+j7Lqv/5Lvwb8NJYnO9o91V5JWzoqeJn+43mGSok2DQWdhdV3/kWz3nqZtLt+Vc tvm932disu2ODuFvX7sir0y6WJDi7Dn/+pSfK45/fr9SidOj2dH7rOHuPr9Ku46v3n/8+JUf PVa+8+j58h1pvJ/2cuieub/znIqMzdPbqwUfK7EUZyQaajEXFScCAP/oTV+KAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata 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, 03 Jul 2015 05:46:05 -0000 Hi Ben, Assuming we have to submit a new errata in order to do the word smiting, I = guess rejecting the current one is the way forward. Nobody has objected to = the correction as such. However, I guess we should then on the list should agree on the actual text= , before submitting a new errata. Regards, Christer -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: 03 July 2015 00:36 To: Christer Holmberg; Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata On 19 Jun 2015, at 11:01, Christer Holmberg wrote: > Hi, > >>>> Hi Roland, >>>> >>>> We could add a clarifying note. >>>> >>>> But, I don't think the note should talk about "use-cases". It=20 >>>> should simply say that, if forking occurs, RSeq values are=20 >>>> processed per early dialog, independently from the RSeq values on=20 >>>> other early dialogs. >>> >>> +1 >>> >>> Note that the same is true for CSeq. It would be a very stupid=20 >>> implementation that handled the CSeq per-dialog but not the RSeq. >> >> Note that the scope of RSeq values is a single INVITE transaction,=20 >> not a dialog. (So, for a re-INVITE in the same dialog the RSeq value=20 >> might turn out > to be lower than that for the INVITE that=20 >> established the dialog.) > > Correct, that needs to be clear. > >> But that value space is owned by the UAS for the INVITE. So, from the=20 >> perspective of the sender of the INVITE (receiver of provisional=20 >> responses), >the value space must be managed independently for the=20 >> combination of INVITE transaction AND dialog id. So the required=20 >> logic is somewhat >different than what is required for CSeq. > > *Nodding like when I am not really sure I understood what you said,=20 > but it did sound correct* :) > From this discussion, am I correct in understanding that the errata is not= quite correct? If so, do people prefer that I reject the existing eratta, = and let someone submit a new one? Alternatively, given that the language ap= pears to need some thought, or at least word-smithing, do people still thin= k it reasonable to handle this as an errata? Thanks! Ben. From nobody Fri Jul 3 08:48:35 2015 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 881281B2FFD for ; Fri, 3 Jul 2015 08:48:34 -0700 (PDT) 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 6gnuSuAUPKB7 for ; Fri, 3 Jul 2015 08:48:33 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D591B2FF2 for ; Fri, 3 Jul 2015 08:48:32 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-08v.sys.comcast.net with comcast id nroM1q0012XD5SV01roXmy; Fri, 03 Jul 2015 15:48:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-20v.sys.comcast.net with comcast id nroW1q00E3Ge9ey01roWS1; Fri, 03 Jul 2015 15:48:31 +0000 Message-ID: <5596AECD.1080306@alum.mit.edu> Date: Fri, 03 Jul 2015 11:48:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christer Holmberg , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> 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=1435938511; bh=k6WTZH3dturWaybIkSy90+O9dsfs6CgIIcwALEaTGIY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M5jWNrc5GJo2RRvppZZ9i+Rs0TfEPiLPcPGVGrt3Q/VstnH4vikvaxGkRQC1P1rWp BSgqnlzC1wMpjocCoV5Cvux1dNYHnhZmgfwLSucgFe2J6Cf6PW/j/4xQO8OavMflSa gd3HZYIn2seUzmWF+AH9CHKzSLhWC3zwlSso2xSmrOqsJuDhyQlwJfD/NV+qXr/lqZ YfyGUF6hUG/Dnb2A9bV1pdcu9+g6rwi7YIUAS8/SZhDVi4mR7S/stCHsulGZAK+mvC PYCboENhdTDIMAXg5945Pa6sVwaQUPTnSHWOcuU72BQRpYCi7/sbjv3IcM4w2IJ6kY mAlhfEKnRimoQ== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata 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, 03 Jul 2015 15:48:34 -0000 WFM On 7/3/15 1:46 AM, Christer Holmberg wrote: > Hi Ben, > > Assuming we have to submit a new errata in order to do the word smiting, I guess rejecting the current one is the way forward. Nobody has objected to the correction as such. > > However, I guess we should then on the list should agree on the actual text, before submitting a new errata. > > Regards, > > Christer > > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 03 July 2015 00:36 > To: Christer Holmberg; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RSeq and forking - Errata > > > On 19 Jun 2015, at 11:01, Christer Holmberg wrote: > >> Hi, >> >>>>> Hi Roland, >>>>> >>>>> We could add a clarifying note. >>>>> >>>>> But, I don't think the note should talk about "use-cases". It >>>>> should simply say that, if forking occurs, RSeq values are >>>>> processed per early dialog, independently from the RSeq values on >>>>> other early dialogs. >>>> >>>> +1 >>>> >>>> Note that the same is true for CSeq. It would be a very stupid >>>> implementation that handled the CSeq per-dialog but not the RSeq. >>> >>> Note that the scope of RSeq values is a single INVITE transaction, >>> not a dialog. (So, for a re-INVITE in the same dialog the RSeq value >>> might turn out > to be lower than that for the INVITE that >>> established the dialog.) >> >> Correct, that needs to be clear. >> >>> But that value space is owned by the UAS for the INVITE. So, from the >>> perspective of the sender of the INVITE (receiver of provisional >>> responses), >the value space must be managed independently for the >>> combination of INVITE transaction AND dialog id. So the required >>> logic is somewhat >different than what is required for CSeq. >> >> *Nodding like when I am not really sure I understood what you said, >> but it did sound correct* :) >> > > From this discussion, am I correct in understanding that the errata is not quite correct? If so, do people prefer that I reject the existing eratta, and let someone submit a new one? Alternatively, given that the language appears to need some thought, or at least word-smithing, do people still think it reasonable to handle this as an errata? > > Thanks! > > Ben. > From Russell.Penar@centurylink.com Tue Jul 7 10:22:41 2015 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 A29EE1ACED5 for ; Tue, 7 Jul 2015 10:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 TQ_IDIB3OYJF for ; Tue, 7 Jul 2015 10:22:38 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0CB71ACECC for ; Tue, 7 Jul 2015 10:22:38 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id t67HMbW6007704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2015 11:22:37 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E848D1E0049 for ; Tue, 7 Jul 2015 12:22:31 -0500 (CDT) Received: from lxdnp31k.corp.intranet (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id C08721E0060 for ; Tue, 7 Jul 2015 12:22:31 -0500 (CDT) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id t67HMVIh048846 for ; Tue, 7 Jul 2015 11:22:31 -0600 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 t67HMVbq048838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 Jul 2015 11:22:31 -0600 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; Tue, 7 Jul 2015 11:22:31 -0600 From: "Penar, Russell" To: "'sipcore@ietf.org'" Thread-Topic: sip/tcp with primary & secondary outbound proxies (behavior upon receipt of tcp rst) Thread-Index: AdC42YJtqzrwy+ppS+ib/7ZarVKNjg== Date: Tue, 7 Jul 2015 17:22:30 +0000 Message-ID: <12C684AA1283B949BD80AC8273CF3A723F45A77F@PDDCWMBXEX504.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: multipart/alternative; boundary="_000_12C684AA1283B949BD80AC8273CF3A723F45A77FPDDCWMBXEX504ct_" MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: [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, 07 Jul 2015 17:33:06 -0000 --_000_12C684AA1283B949BD80AC8273CF3A723F45A77FPDDCWMBXEX504ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm seeing non-ideal behavior from cpe and hoping this group can provide gu= idelines specific to the scenario below, and ultimately standardize ideal c= pe behavior for the given context. I haven't found any specifications defi= ning the ideal behavior, and it was suggested during sipnoc to contact sipc= ore as an appropriate next step. Scenario context: Example platform has two geographically redundant access sbcs (each sbc is = a highly available mated pair). Both sbc ip addresses are provided to cpe i= n a primary/secondary priority configuration via srv record lookups. Most,= if not all, vendor sbc mated pairs maintain signaling/media state, but not= tcp state (reportedly doing so is significantly hard/expensive). Sbc mate= d pair failovers are fairly common (e.g. often required for software upgrad= es) relative to primary geographic site failure. Problem/Variance: 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 connectio= n is not established back to the primary sbc. This can be due to session a= udits from the platform, or more specific to my ask is a cpe re-Invite scen= ario. 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 w= here once the cpe attempts to put the call on hold, it reacts to the tcp rs= t by failing over to the secondary sbc and dropping the standing call. Fwi= w, 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). Regards, Russ Work - +1.303.626.2812 Mobile - +1.425.753.6191 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. --_000_12C684AA1283B949BD80AC8273CF3A723F45A77FPDDCWMBXEX504ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m seeing non-ideal behavior from cpe and hop= ing this group can provide guidelines specific to the scenario below, and u= ltimately standardize ideal cpe behavior for the given context.  I hav= en’t found any specifications defining the ideal behavior, and it was suggested during sipnoc to contact sipcore as an appr= opriate next step.

 

Scenario context:

Example platform has two geographically redundant ac= cess sbcs (each sbc is a highly available mated pair). Both sbc ip addresse= s are provided to cpe in a primary/secondary priority configuration via srv= record lookups.  Most, if not all, vendor sbc mated pairs maintain signaling/media state, but not tcp state (= reportedly doing so is significantly hard/expensive).  Sbc mated pair = failovers are fairly common (e.g. often required for software upgrades) rel= ative to primary geographic site failure. 

 

Problem/Variance:

Where a standing call is setup against the primary s= bc; after a primary sbc mated pair failover, calls are at risk of being dro= pped 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), th= e sbc target for re-establishing the signaling tcp session is critical.&nbs= p;

 

I’ve seen cpe exhibit ideal behavior, where up= on receipt of tcp rst the cpe connects back to the primary sbc.  In th= at 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, IR= 17;m told the vendor exhibiting the ideal behavior only recently began to d= o so (reportedly from customer pressure to properly support geo-redundant setups as described above).

 

Regards,

Russ

 

Work - +1.303.626.2812

Mobile - +1.425.753.6191<= /p>

 

This communication is the property of CenturyLink and may contain c= onfidential or privileged information. Unauthorized use of this communicati= on is strictly prohibited and may be unlawful. If you have received this co= mmunication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communicat= ion and any attachments.
--_000_12C684AA1283B949BD80AC8273CF3A723F45A77FPDDCWMBXEX504ct_-- From nobody Thu Jul 9 09:29:17 2015 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 B456E1B2AC1 for ; Thu, 9 Jul 2015 09:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 VBhgUdE-n5gJ for ; Thu, 9 Jul 2015 09:29:15 -0700 (PDT) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) (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 3CD341B2A49 for ; Thu, 9 Jul 2015 09:29:15 -0700 (PDT) Received: by qkcl188 with SMTP id l188so6109134qkc.1 for ; Thu, 09 Jul 2015 09:29:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=HWoQ4eI0n4kbaGuy09LbXwsxbC2gkpuBqau9b8Kl3Ws=; b=WQQwWGRk1smzTPT1n2tatFAvySJkWf/D70n3JSJg7JhczukxsQq11cW4e0ZRspZRN4 fgmI4u3Y4yw2Vtrnj2g0mxfCT46TViQVihs6M0Z+LcEyhi1uLlF8HMvCtpu4977EzM1o wXKEY/SAFVmYRj8xK1DTf+QXnvB0wEp0sulsGOPUaXkZQLml1wyioxxwBMX5udzfbX3h iKGGd1exIk18cCwC6ZFk8/CRZTvxmjhLAJfS4Icgxb5tFtKwkJlgSY3AxhYe+gqCeQMi 2WpcQEel6euAILOljVwmPCjVTOHk/7mMcvGvk8judXRLbgFqVRrTWfj4XdPuHUzc2x+L xnSg== X-Gm-Message-State: ALoCoQk2B80lKThUIbkI0w0Yt+dubdROaiejCQ0uzE2waEWUFVLQkBpFz4ErlBcDZYsUDJOKfsi/ X-Received: by 10.55.49.85 with SMTP id x82mr25914333qkx.49.1436459354442; Thu, 09 Jul 2015 09:29:14 -0700 (PDT) Received: from [10.0.2.234] (c-69-247-98-168.hsd1.pa.comcast.net. [69.247.98.168]) by smtp.gmail.com with ESMTPSA id o3sm3925425qga.36.2015.07.09.09.29.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jul 2015 09:29:13 -0700 (PDT) From: Chris Wendt Content-Type: multipart/alternative; boundary="Apple-Mail=_3448F9DE-7335-4D8C-B01D-8707ADBCE36C" Message-Id: <967BA2C5-042A-485A-8544-BB0322D4A208@chriswendt.net> Date: Thu, 9 Jul 2015 12:29:11 -0400 To: sipcore@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [sipcore] help with UAC vs. UAS response in Allow field 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, 09 Jul 2015 16:29:16 -0000 --Apple-Mail=_3448F9DE-7335-4D8C-B01D-8707ADBCE36C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We are having a debate over interpretation of what a UAS should provide = in the Allow header. In [Section 20.5] All methods, including ACK and CANCEL, understood by = the UA MUST be > included in the list of methods in the Allow header field, when > present. Should the interpretation be that UA implies both UAS and UAC should = respond in it=E2=80=99s Allow header with it=E2=80=99s own supported = methods, or=20 Should a UAS provide an Allow with only with the UAC supported methods = in the context of a session? Any opinions or pointers to more explicit text to clarify the = interpretation would be appreciated. Thanks! -Chris= --Apple-Mail=_3448F9DE-7335-4D8C-B01D-8707ADBCE36C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We are having a debate over interpretation of what a UAS = should provide in the Allow header.

In [Section 20.5] All methods, = including ACK and CANCEL, understood by the UA MUST = be
included in the list of methods in the Allow header field, = when
present.
Should the interpretation be that UA = implies both UAS and UAC should respond in it=E2=80=99s Allow header = with it=E2=80=99s own supported methods, or 
Should a UAS provide an Allow with only with the UAC = supported methods in the context of a session?

Any opinions or pointers to more = explicit text to clarify the interpretation would be = appreciated.

Thanks!

-Chris
= --Apple-Mail=_3448F9DE-7335-4D8C-B01D-8707ADBCE36C-- From nobody Thu Jul 9 12:06:20 2015 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 B649D1B2B43 for ; Thu, 9 Jul 2015 12:06:18 -0700 (PDT) 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 E3PXcHBSOPeC for ; Thu, 9 Jul 2015 12:06:17 -0700 (PDT) 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 6448E1B2B42 for ; Thu, 9 Jul 2015 12:06:17 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-12v.sys.comcast.net with comcast id qK4H1q00B2Fh1PH01K6GPg; Thu, 09 Jul 2015 19:06:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-08v.sys.comcast.net with comcast id qK6G1q0033Ge9ey01K6GQw; Thu, 09 Jul 2015 19:06:16 +0000 Message-ID: <559EC626.6050705@alum.mit.edu> Date: Thu, 09 Jul 2015 15:06:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <967BA2C5-042A-485A-8544-BB0322D4A208@chriswendt.net> In-Reply-To: <967BA2C5-042A-485A-8544-BB0322D4A208@chriswendt.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436468776; bh=ofOKb3pYm6aGBgGW8f39Yn6Vym/2zxX+d52LM5kKD6E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PVu0DwAFxldU2Lr+nhSE+PxGkLN7tiCJxKo6p27BVGwvrr5bqCkkZwDW/Rg3IlCK6 Of7PzR//IBqe5/ppE1Yrqi5+0ZbJj6VvP+X5pbejBoqazNE27WGF6axoO45By2O6wy OIoz25vZVrqcV3Frrinjb/bLQrhZDK59WaJreKSAO8TcG3+t1XdzzBxOYpbglRjMLa tSZ1aom+lyiffYMWObCT2P/rPjK6Q25ZCAYmZXDqhGjx7GKvVgi6ZWH6SDRls6csWZ KncpjOOcVl0lGrRDH3liIGwQWpk6s9BHeQQFSxmEV6iIFwxfrQfbXM+eaT53rQ69tq 7MJGTiAsRwegQ== Archived-At: Subject: Re: [sipcore] help with UAC vs. UAS response in Allow field 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, 09 Jul 2015 19:06:19 -0000 On 7/9/15 12:29 PM, Chris Wendt wrote: > We are having a debate over interpretation of what a UAS should provide > in the Allow header. > > In [Section 20.5] All methods, including ACK and CANCEL, understood by > the UA MUST be >> >> included in the list of methods in the Allow header field, when >> present. > > Should the interpretation be that UA implies both UAS and UAC should > respond in it’s Allow header with it’s own supported methods, or > Should a UAS provide an Allow with only with the UAC supported methods > in the context of a session? > > Any opinions or pointers to more explicit text to clarify the > interpretation would be appreciated. AFAIK each end should indicate independently - this is not a negotiation. Also, it need not be symmetric. But also be aware that this mechanism, along with related ones such as Accept* are limited and imprecise, so don't count too much on what you can infer from them being the last word. Better to consider these as hints. To elaborate, for Allow the definition isn't entirely clear whether this means methods that can be handled when received, methods that might be sent, or both. IMO it makes most sense for it to mean those that can be processed when received. For instance this makes quite a difference of REGISTER, SUBSCRIBE, and PUBLISH, that many UAs aren't prepared to receive but may well send. Furthermore, you may only accept a method in certain contexts. Even though you announce that you allow SUBSCRIBE, you probably only allow subscriptions to certain event types and resources, and perhaps only from certain subscribers. Thanks, Paul From nobody Fri Jul 10 10:49:11 2015 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 8B0431A036F for ; Fri, 10 Jul 2015 10:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziz85wW3FK4B for ; Fri, 10 Jul 2015 10:49:08 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 A501D1A0282 for ; Fri, 10 Jul 2015 10:49:07 -0700 (PDT) Received: by widjy10 with SMTP id jy10so21547623wid.1 for ; Fri, 10 Jul 2015 10:49:06 -0700 (PDT) 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=4Mdfwp4XuENc5fDALLe5d1jdQuz3xlJK8vq5C7agJD8=; b=Ejapa7TylMDPnh1/XtMAmvHclvvi5TMyaAEPA4e/osQnBNHUZeYINri0QHqNf3ue1e Q6hKwPifFRfY6alB2fmY6bvDNKtxTxSwQm27XoiIE5bxBDEmwG2Ao8lNX0rWGhXKUBRU jwEGr/9dQ2dhPNGnw6HUPXtizK3iJml7ANN71FS1iiSsgo7wSJYbp1SW2LRQMEa3AxTY BlWEuGHrcVKXAv4Bd18ITKvPBLmHn3LI1T97G2r7v0P5Fp36rU0myd8iAG90SwIHuVk9 GijT8yq+LhfpIIp8V1vv00D366KIuhIAc//f2Y2vzO01eS3zRYZmi64DCX1Y44yzUgpW CfZw== X-Gm-Message-State: ALoCoQlaoOgZZ0TpVPGiFZ0009b2+c403C/T1JHfqFTpwFKRPWH8k74kgoDk8uliu7ltxNlLn21J X-Received: by 10.180.188.139 with SMTP id ga11mr63617wic.7.1436550546309; Fri, 10 Jul 2015 10:49:06 -0700 (PDT) From: Brett Tate References: <967BA2C5-042A-485A-8544-BB0322D4A208@chriswendt.net> <559EC626.6050705@alum.mit.edu> In-Reply-To: <559EC626.6050705@alum.mit.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKBYjmchdv/cWmCjVXc/KGnzdOOxgFKl9OHnGlNyKA= Date: Fri, 10 Jul 2015 13:49:12 -0400 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] help with UAC vs. UAS response in Allow field 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, 10 Jul 2015 17:49:09 -0000 Hi, In addition to Paul's response, there is an Allow ambiguity concerning dialog/context versus all understood methods. Sections 13.2.1, 13.2.2.1, and 13.3.1.4 indicate (non-normative) being dialog/context specific. However, section 20.5 normatively indicates "All methods" which definitely conflicts with section 13.2.2.1. Section 20.5: "All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present." > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, July 09, 2015 3:06 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] help with UAC vs. UAS response in Allow field > > On 7/9/15 12:29 PM, Chris Wendt wrote: > > We are having a debate over interpretation of what a UAS should > > provide in the Allow header. > > > > In [Section 20.5] All methods, including ACK and CANCEL, understood by > > the UA MUST be > >> > >> included in the list of methods in the Allow header field, when > >> present. > > > > Should the interpretation be that UA implies both UAS and UAC should > > respond in it's Allow header with it's own supported methods, or > > Should a UAS provide an Allow with only with the UAC supported methods > > in the context of a session? > > > > Any opinions or pointers to more explicit text to clarify the > > interpretation would be appreciated. > > AFAIK each end should indicate independently - this is not a negotiation. > Also, it need not be symmetric. > > But also be aware that this mechanism, along with related ones such as > Accept* are limited and imprecise, so don't count too much on what you can > infer from them being the last word. Better to consider these as hints. > > To elaborate, for Allow the definition isn't entirely clear whether this > means methods that can be handled when received, methods that might be sent, > or both. IMO it makes most sense for it to mean those that can be processed > when received. For instance this makes quite a difference of REGISTER, > SUBSCRIBE, and PUBLISH, that many UAs aren't prepared to receive but may well > send. > > Furthermore, you may only accept a method in certain contexts. Even though > you announce that you allow SUBSCRIBE, you probably only allow subscriptions > to certain event types and resources, and perhaps only from certain > subscribers. > > Thanks, > Paul From nobody Mon Jul 13 15:19:54 2015 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 2E3BC1A7005 for ; Mon, 13 Jul 2015 15:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 vVwYWgwegoz3 for ; Mon, 13 Jul 2015 15:19:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46C61A7004 for ; Mon, 13 Jul 2015 15:19:51 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6DMJZd7062890 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jul 2015 17:19:45 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 13 Jul 2015 17:19:34 -0500 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata 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, 13 Jul 2015 22:19:53 -0000 On 3 Jul 2015, at 0:46, Christer Holmberg wrote: > Hi Ben, > > Assuming we have to submit a new errata in order to do the word > smiting, I guess rejecting the current one is the way forward. Nobody > has objected to the correction as such. "word smiting" is a wonderful typo for this. I'm going to use that one :-) Rejecting it is not absolutely necessary to edit the wording, but I think it may be the right thing to do here [see below] > > However, I guess we should then on the list should agree on the actual > text, before submitting a new errata. I agree. But after reading the discussion so far (especially Paul's comment), I'm not sure if this is a simple fix, or if it needs more thought. Therefore I'm going to reject the errata as it currently stands. I'd like to see the working group discuss the correct fix. If that turns out to be an errata, we can submit that one when it's agreed upon. If it turns out to be something else, we can cross that bridge when we come to it. Thanks! Ben. From nobody Mon Jul 13 16:09:00 2015 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 5C0A21A874C for ; Mon, 13 Jul 2015 16:08:58 -0700 (PDT) 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 4gM3kw6clSnc for ; Mon, 13 Jul 2015 16:08:57 -0700 (PDT) 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 250501A8737 for ; Mon, 13 Jul 2015 16:08:57 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-12v.sys.comcast.net with comcast id rz7F1q0032TL4Rh01z8wnj; Mon, 13 Jul 2015 23:08:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id rz8v1q00Z3Ge9ey01z8wjL; Mon, 13 Jul 2015 23:08:56 +0000 Message-ID: <55A44506.3090209@alum.mit.edu> Date: Mon, 13 Jul 2015 19:08:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Campbell , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> In-Reply-To: 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=1436828936; bh=H377BFDk88ubFaKQrFJyBeh8Or2OGrbMjVwKG/mMPbo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rwSc7yepL7RPZfQi5RBMSWBhnsJDVvmOmfd24F7SMU2MzNH/8SaFyRe1LrtaiNzWa dtgDYWgu4AwWP/KAaFNFlMsoSMpLVUH7InMPO7+HrHKxRsrV6Bu3eUOx7k3eNfoqSi sTbxapTLpNfh8vA3++cTRmdUImLHm1xgxwLEgYS0Uot9GAHDOxmY48k+GAcIzVGNZ0 K+qV2xTsVik/S/PK2mLnn2HvhB7OXGIe0bxtw3lGyqgJkry5sYHn+h8bIVlK7T8x3V fc/IueKSITJ/r23o9l4XPlYRE95sKZpp3rqjYLp4L6VZMW7ZFuol6bW8fLf1XI5QHa OKFkchiAduHVQ== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata 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, 13 Jul 2015 23:08:58 -0000 On 7/13/15 6:19 PM, Ben Campbell wrote: > > > On 3 Jul 2015, at 0:46, Christer Holmberg wrote: > >> Hi Ben, >> >> Assuming we have to submit a new errata in order to do the word >> smiting, I guess rejecting the current one is the way forward. Nobody >> has objected to the correction as such. > > "word smiting" is a wonderful typo for this. I'm going to use that one :-) > > Rejecting it is not absolutely necessary to edit the wording, but I > think it may be the right thing to do here [see below] > >> >> However, I guess we should then on the list should agree on the actual >> text, before submitting a new errata. > > I agree. But after reading the discussion so far (especially Paul's > comment), I'm not sure if this is a simple fix, or if it needs more > thought. Therefore I'm going to reject the errata as it currently > stands. I'd like to see the working group discuss the correct fix. If > that turns out to be an errata, we can submit that one when it's agreed > upon. If it turns out to be something else, we can cross that bridge > when we come to it. Do we want to start that discussion *now*? Or wait until after the meeting? While sipcore isn't meeting, most of the sipcore regulars are probably concentrating on things that *will* be going on at the meeting. So I'm inclined to think it would be better to wait about a month before starting the discussion. Thanks, Paul From nobody Mon Jul 13 16:12:22 2015 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 523B41A8742 for ; Mon, 13 Jul 2015 16:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 9U-OECQMtxIy for ; Mon, 13 Jul 2015 16:12:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559F61A8753 for ; Mon, 13 Jul 2015 16:12:19 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6DNC3RJ011639 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jul 2015 18:12:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Paul Kyzivat" Date: Mon, 13 Jul 2015 18:12:03 -0500 Message-ID: <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> In-Reply-To: <55A44506.3090209@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata 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, 13 Jul 2015 23:12:21 -0000 On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: > On 7/13/15 6:19 PM, Ben Campbell wrote: >> >> >> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >> >>> Hi Ben, >>> >>> Assuming we have to submit a new errata in order to do the word >>> smiting, I guess rejecting the current one is the way forward. >>> Nobody >>> has objected to the correction as such. >> >> "word smiting" is a wonderful typo for this. I'm going to use that >> one :-) >> >> Rejecting it is not absolutely necessary to edit the wording, but I >> think it may be the right thing to do here [see below] >> >>> >>> However, I guess we should then on the list should agree on the >>> actual >>> text, before submitting a new errata. >> >> I agree. But after reading the discussion so far (especially Paul's >> comment), I'm not sure if this is a simple fix, or if it needs more >> thought. Therefore I'm going to reject the errata as it currently >> stands. I'd like to see the working group discuss the correct fix. If >> that turns out to be an errata, we can submit that one when it's >> agreed >> upon. If it turns out to be something else, we can cross that bridge >> when we come to it. > > Do we want to start that discussion *now*? Or wait until after the > meeting? > > While sipcore isn't meeting, most of the sipcore regulars are probably > concentrating on things that *will* be going on at the meeting. So I'm > inclined to think it would be better to wait about a month before > starting the discussion. I will leave that to the chairs, but I don't think the world is going to end if it waits a few weeks. Ben. From nobody Tue Jul 14 09:32:09 2015 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 DAC5D1A3BA7 for ; Tue, 14 Jul 2015 09:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 5py7h_q68c-P for ; Tue, 14 Jul 2015 09:32:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEDB1A6F20 for ; Tue, 14 Jul 2015 09:32:06 -0700 (PDT) Received: from mutabilis-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6EGW4CE057394 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Jul 2015 11:32:04 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be mutabilis-2.local To: Ben Campbell , Paul Kyzivat References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> From: "A. Jean Mahoney" Message-ID: <55A5397E.6050804@nostrum.com> Date: Tue, 14 Jul 2015 11:31:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata 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, 14 Jul 2015 16:32:09 -0000 On 7/13/15 6:12 PM, Ben Campbell wrote: > On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: > >> On 7/13/15 6:19 PM, Ben Campbell wrote: >>> >>> >>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>> >>>> Hi Ben, >>>> >>>> Assuming we have to submit a new errata in order to do the word >>>> smiting, I guess rejecting the current one is the way forward. Nobody >>>> has objected to the correction as such. >>> >>> "word smiting" is a wonderful typo for this. I'm going to use that >>> one :-) >>> >>> Rejecting it is not absolutely necessary to edit the wording, but I >>> think it may be the right thing to do here [see below] >>> >>>> >>>> However, I guess we should then on the list should agree on the actual >>>> text, before submitting a new errata. >>> >>> I agree. But after reading the discussion so far (especially Paul's >>> comment), I'm not sure if this is a simple fix, or if it needs more >>> thought. Therefore I'm going to reject the errata as it currently >>> stands. I'd like to see the working group discuss the correct fix. If >>> that turns out to be an errata, we can submit that one when it's agreed >>> upon. If it turns out to be something else, we can cross that bridge >>> when we come to it. >> >> Do we want to start that discussion *now*? Or wait until after the >> meeting? >> >> While sipcore isn't meeting, most of the sipcore regulars are >> probably concentrating on things that *will* be going on at the >> meeting. So I'm inclined to think it would be better to wait about a >> month before starting the discussion. > > I will leave that to the chairs, but I don't think the world is going > to end if it waits a few weeks. It's OK with the chairs to hold off discussing this topic until after Prague. Jean > > Ben. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jul 15 02:51:26 2015 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 69DD91A0218 for ; Wed, 15 Jul 2015 02:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwNAwlARb8PK for ; Wed, 15 Jul 2015 02:51:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF2D1A020D for ; Wed, 15 Jul 2015 02:51:21 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-fd-55a62d1773c2 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.AF.25217.71D26A55; Wed, 15 Jul 2015 11:51:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Wed, 15 Jul 2015 11:51:18 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Allow-Events mandatory in 489 missing from RFC6665 Thread-Index: AdC+4q7sSVUDT1zyRw2y6nO2A6AI7Q== Date: Wed, 15 Jul 2015 09:51:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D9167C4@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D9167C4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja647rJQg75eI4uvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9KlNUwFV1wqLvz4y9LA+Nq6i5GTQ0LARGLvnLmsELaYxIV7 69m6GLk4hASOMkq8+veEHcJZzCjR9agJyOHgYBOwkOj+pw3SICKgKbH821Z2EFtYwFpi+YRr TBBxB4mlG9+zgZSLCOhJvJtTCBJmEVCVaNzygw3E5hXwlXi+4y3YXkagvd9PrQFrZRYQl7j1 ZD4TxD0CEkv2nGeGsEUlXj7+B3WnosTV6cuh6vMlDv9/ygQxU1Di5MwnLBMYhWYhGTULSdks JGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNocWpxcW66kZFealFmcnFxfp5eXmrJ JkZgRBzc8ttqB+PB546HGAU4GJV4eBfsWxoqxJpYVlyZe4hRmoNFSZx3xua8UCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MS2R/XHTd37H4gMukCRe8jlV9uHe6a8EzoRCnp/v1d/nNkJE1 79p11MDwmoVp2aE3e1yyb4lo6i91Evte4j3But/h4lrhKVs1G5YkMnzrvH5U0P2o8pSKErvm qRtUbnnn7fpb5vFd09EhxnFdybvmGc4rd9epHT16/dxiG81ZxgVLvG9cyH04Q4mlOCPRUIu5 qDgRANedFShpAgAA Archived-At: Subject: [sipcore] Allow-Events mandatory in 489 missing from RFC6665 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, 15 Jul 2015 09:51:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D9167C4ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Once upon a time, we decided to stop using the "header field tables" in our= specs, and instead have explicit text regarding header field usage when ne= eded. In RFC3265, it was stated that Allow-Events is mandatory in 489 response fo= r SUBSCRIBE/NOTIFY: 7.2. New Headers This table expands on tables 2 and 3 in SIP [1], as amended by the changes described in section 7.1. Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT ----------------------------------------------------------------- Allow-Events R o o - o o o o o o Allow-Events 2xx - o - o o o o o o Allow-Events 489 - - - - - - - m m Event R - - - - - - - m m Subscription-State R - - - - - - - - m In RFC6665, the above table was removed, but I can find no text saying that= Allow-Events is mandatory in 489. There is a "SHOULD include in requests/r= esponses that create a dialog". This has caused some deployment issues, when 6665 endpoints are communicati= ng with 3265 endpoints. So, unless there was a decision to not mandate Allow-Events in 489 anymore,= and unless I've missed some text which actually does indicate it is mandat= ory, I think we could make a simple errata, simply adding a "MUST include" = statement somewhere. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D9167C4ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Once upon a time, we decided to= stop using the ”header field tables” in our specs, and instead= have explicit text regarding header field usage when needed.

 

In RFC326= 5, it was stated that Allow-Events is mandatory in 489 response for SUBSCRI= BE/NOTIFY:

&nbs= p;

7.2. New Headers

 

   This table expands on tables 2= and 3 in SIP [1], as amended by the

   changes described in section 7= .1.

 

   Header field   =    where proxy ACK BYE CAN INV OPT REG PRA SUB NOT

   ------------------------------= -----------------------------------

   Allow-Events   =      R        &= nbsp; o   o   -   o   o  = o   o   o   o

   Allow-Events   =     2xx         -&nb= sp;  o   -   o   o   o &n= bsp; o   o   o

   Allow-Events   =     489         -&nb= sp;  -   -   -   -   - &n= bsp; -   m   m

   Event    &= nbsp;          R  &n= bsp;       -   -   - = ;  -   -   -   -   m &nbs= p; m

   Subscription-State  R&nbs= p;         -   - &nb= sp; -   -   -   -   -   -=    m

 

In RFC666= 5, the above table was removed, but I can find no text saying that Allow-Ev= ents is mandatory in 489. There is a “SHO= ULD include in requests/responses that create a dialog”.

 

This has caused some deployment= issues, when 6665 endpoints are communicating with 3265 endpoints.

 

So, unless there was a decision= to not mandate Allow-Events in 489 anymore, and unless I’ve missed s= ome text which actually does indicate it is mandatory, I think we could mak= e a simple errata, simply adding a “MUST include” statement somewhere.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D9167C4ESESSMB209erics_-- From nobody Wed Jul 15 18:15:58 2015 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 6C2451B2C76 for ; Wed, 15 Jul 2015 18:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 6oiixxT_1hAe for ; Wed, 15 Jul 2015 18:15:55 -0700 (PDT) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) (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 80BF81B2C6E for ; Wed, 15 Jul 2015 18:15:55 -0700 (PDT) Received: by qkdl129 with SMTP id l129so41007367qkd.0 for ; Wed, 15 Jul 2015 18:15:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=F3M3OLLBm1vJ8GhdyXkNLavehDCGl8hKdz7jZcy/lEU=; b=WZfuH3cI52foMmQLYNNVcql6gs6HcBXgHcVSvMP62GUj0sEY/1PdV78w9jkntZpS2X mLF+VolcdOKdAMsTV3XNeytybFeWuWE/HIzc5XdZMtCVpw8vdCIiRS/harPyPP0MVcni bcB34NDDoXeTeItDKQb3wFfzt9Iiro+52w1GtzKmNrgbLKjTPtKoo7gayoVDo5HoykV8 +83I/jreZkmkQo5yuJW7YxJjoXgjHUTdCfSw/5NyVhH92V7HcQZIpF44/Pz0lqifVLtj gdVJ8SPvjmt1+SndX02EOMBXM/qK0SlGn8lFB5a8Kfn7qbA8D+Q+WiWfcdkCWdxB1kGG rJEw== X-Gm-Message-State: ALoCoQnSnpS6ujoVNaf+URcyhgJ0hli9Xq1KLV4ELY4ShGjSUU1JmyffVi86WGKbS/wHcyvuDk6h X-Received: by 10.140.82.180 with SMTP id h49mr12946156qgd.29.1437009354790; Wed, 15 Jul 2015 18:15:54 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:8da6:3924:9bad:2fc9? ([2601:41:c101:9364:8da6:3924:9bad:2fc9]) by smtp.gmail.com with ESMTPSA id l33sm3226710qkh.12.2015.07.15.18.15.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jul 2015 18:15:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Chris Wendt In-Reply-To: <559EC626.6050705@alum.mit.edu> Date: Wed, 15 Jul 2015 21:15:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <967BA2C5-042A-485A-8544-BB0322D4A208@chriswendt.net> <559EC626.6050705@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2102) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] help with UAC vs. UAS response in Allow field 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, 16 Jul 2015 01:15:57 -0000 Hi Paul, Thanks. I would agree, purely from the perspective of 20.5 and in = general practice that a UA (either UAS or UAC) should report their = allowed methods independent of other UA in the chain. Also agree that this shouldn=92t be any sense of a contractual agreement = what will happen depending on the context. And probably isn=92t a = straight forward way to capture all of the cases to provide normative = behavior. -Chris > On Jul 9, 2015, at 3:06 PM, Paul Kyzivat = wrote: >=20 > On 7/9/15 12:29 PM, Chris Wendt wrote: >> We are having a debate over interpretation of what a UAS should = provide >> in the Allow header. >>=20 >> In [Section 20.5] All methods, including ACK and CANCEL, understood = by >> the UA MUST be >>>=20 >>> included in the list of methods in the Allow header field, when >>> present. >>=20 >> Should the interpretation be that UA implies both UAS and UAC should >> respond in it=92s Allow header with it=92s own supported methods, or >> Should a UAS provide an Allow with only with the UAC supported = methods >> in the context of a session? >>=20 >> Any opinions or pointers to more explicit text to clarify the >> interpretation would be appreciated. >=20 > AFAIK each end should indicate independently - this is not a = negotiation. Also, it need not be symmetric. >=20 > But also be aware that this mechanism, along with related ones such as = Accept* are limited and imprecise, so don't count too much on what you = can infer from them being the last word. Better to consider these as = hints. >=20 > To elaborate, for Allow the definition isn't entirely clear whether = this means methods that can be handled when received, methods that might = be sent, or both. IMO it makes most sense for it to mean those that can = be processed when received. For instance this makes quite a difference = of REGISTER, SUBSCRIBE, and PUBLISH, that many UAs aren't prepared to = receive but may well send. >=20 > Furthermore, you may only accept a method in certain contexts. Even = though you announce that you allow SUBSCRIBE, you probably only allow = subscriptions to certain event types and resources, and perhaps only = from certain subscribers. >=20 > Thanks, > Paul >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore