From nobody Tue Jun 1 07:46:28 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17B33A1ACC for ; Tue, 1 Jun 2021 07:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 tb9OfT5aWrpC for ; Tue, 1 Jun 2021 07:46:14 -0700 (PDT) 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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E6E3A1AD7 for ; Tue, 1 Jun 2021 07:46:13 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id o49PlZADpx10yo5ellsNLb; Tue, 01 Jun 2021 14:46:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1622558771; bh=LUtQt3kHmFD6qjo9Yi4895SyziWcBWdpKrvANuSRjvs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=e8dVakJCrfEgvwBKM0mH5WJ57rStWT/p6O8NxA5F+/n9xrptc0nPEqHB2nSDDGR06 0z3I9SfIXy4FVEcfxrByr5AEaijEu1qHTawbQIJH/R0uwjAIm4QHHABhQX8PFyC6fz ZA1RYpOOg2+blYTlIgkxc99pflr3J/BfOqtGIVhu/G9aP+PuaPiPioxrCGIAFBzFBd inqSebehoptrJrD7tAA6Uuoo9K+mYVLO7cAcoFXXYWPFB2MppTZ9Fy9ketThXUXXfH 771lmu1KqQT7VcdHAtB2RuLJiPXdn1V/PR0FRKPc6Eh9472RuwUhwoTwoTdLWYb1F3 6rhlRIymEPtvw== Received: from MacBook-Air.localdomain ([24.62.227.142]) by resomta-ch2-13v.sys.comcast.net with ESMTPA id o5eflJQUgAtJTo5ehlwyVR; Tue, 01 Jun 2021 14:46:07 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduledrvdelhedgkeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeehnecuhfhrohhmpefrrghulhcumfihiihivhgrthcuoehprghulhdrkhihiihivhgrthestghomhgtrghsthdrnhgvtheqnecuggftrfgrthhtvghrnhepkeetleeufeejfeelledukedtueejheffvddutdejuedtteeivdfgudefkeekjefhnecuffhomhgrihhnpehivghtfhdrohhrghdpohhuthhlohhokhdrtghomhenucfkphepvdegrdeivddrvddvjedrudegvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopeforggtuehoohhkqdetihhrrdhlohgtrghlughomhgrihhnpdhinhgvthepvdegrdeivddrvddvjedrudegvddpmhgrihhlfhhrohhmpehprghulhdrkhihiihivhgrthestghomhgtrghsthdrnhgvthdprhgtphhtthhopehsihhptghorhgvsehivghtfhdrohhrgh X-Xfinity-VMeta: sc=0.00;st=legit To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Tue, 1 Jun 2021 10:46:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] RFC 4028 UAS behavior requirement of Require header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 14:46:26 -0000 Hoil, I already replied once about this. I'll try again. The simple answer to why the UAS should add Require:timer is that RFC4028 says that it must. Arguing that 4028 could have been written differently is a futile exercise. That RFC was written over 16 years ago, and people have been implementing it since long before it became an rfc. Are you imagining that anyone will revise the rfc or change their implementations for your convenience? Thanks, Paul On 5/28/21 4:18 PM, Hoil Choi wrote: > Hi Ranjit, thanks for taking a look. > > However, I'm more interested in case where UAS is responding to UAC's > request with refresher as itself (uac).  Consider this case - > > UAC ---- INVITE (Session-Expires: 1800;refresher=uac, Supported: timer) > ----> UAS > UAC <---- 200 OK (Session-Expires: 1800;refresher=uac) > --------------------- UAS > > In this case, the statement in question seems to convey that UAS should > also add "Require: timer" in its 200 response.  Why would this be, when > it's clear that UAC declared itself as the refresher and that timer is > supported? > > For reference, RFC 4028 Section 9 UAS Behavior (or page 16) > If the refresher parameter in the Session-Expires header field in the > 2xx response has a value of 'uac', the UAS MUST place a Require header > field into the response with the value 'timer'. > > Thanks, > Hoil > > ------------------------------------------------------------------------ > *From:* Ranjit Avasarala > *Sent:* Friday, May 28, 2021 12:38 PM > *To:* Hoil Choi ; > Sip-implementors@lists.cs.columbia.edu > > *Cc:* sipcore@ietf.org > *Subject:* Re: [sipcore] RFC 4028 UAS behavior requirement of Require > header > Hi Holi > the presence of the "Require" header with value "timer" from UAS > indicates to UAC that it (UAC) is performing the refreshing operation. > but if the UAS is the refresher, then if Require header with value > "timer" is present in response from UAS, then UAC should send BYE if it > does not receive a session refresh request from UAS. > > Regards > Ranjit > > > > On Fri, May 28, 2021 at 10:02 AM Hoil Choi > wrote: > > Hello, > > I hope this mail finds appropriate person or team for an answer to > my question on RFC 4028. > I am a SIP enthusiast and always learning a lot about it, but by no > means am I an expert; so please excuse my ignorance. > > I came across an interesting statement In Section 9 UAS Behavior (or > page 16). > > > If the refresher parameter in the Session-Expires header field in the >    2xx response has a value of 'uac', the UAS MUST place a Require >    header field into the response with the value 'timer'. > > > Statement seems to convey that UAS must place a Require header with > value 'timer' when UAC requests itself to be the refresher. > > However, this statement should only be true, if UAC did not put > Session-Expire with value of 'uac'. > > If UAC, in INVITE request, put Session-Expire with value of 'uac' > (itself), UAS should not bother putting Require header field in the > response.  Or to be more accurate, UAC should include 'timer' in > Supported header, so that UAS doesn't have to bother putting Require > header field. > > What is the reason behind the requirement of Require header, from > UAS in this case? > > Thanks! > Hoil Choi > 253-273-5442 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Jun 1 07:46:34 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6063A1AF5 for ; Tue, 1 Jun 2021 07:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=alum.mit.edu 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 E1xnXCSsXNq4 for ; Tue, 1 Jun 2021 07:46:23 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2051.outbound.protection.outlook.com [40.107.220.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119073A1AA5 for ; Tue, 1 Jun 2021 07:46:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EF86k9j0ehprF/HoJ+YkN2uYrw/VEAU3OgmMR0HF3AQ0QvQ9CHuka0ivl3/aL8qmD1tM+DJrGgnNE6jQQZiPySdTweZv3CxSx2vlaFYFh1HKy63AqF/Zm7AoHJfwwHFzzK7vdDEjD0NjkylWM4BbCC6Ol2THObZ6g2OOUmpsg+FWASwj7nLCmVLjlYZ7xQbutVTsbvOVdfYyj5PY6NHP1QHp1zIrY5ec2aCePYcwZJMkvbazaVW0QC6NZaMRhYP8x/bDbfFqCGsV2acP0Xm0DKXuPaY+MkDdNKzdsiquNKB9NuZ2mMWqHDaE99gKv6S8GsVg3OHvWCqhafG2cdJxeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EeLaVPmX1vlCVBZKbQQ7rnhvfmv2uksKlzY3bH6j6iQ=; b=dR8ZFt3YOVKUazxff0PTf9CAgl7GnkCmwwTlqYQxrzfWkr/lYGuWC+MfBfqHWw1TEespWN2wdHOnl4wEoXe4j8FyJV5SgBvNDIe6rPu5LJyk0mnwHC9F5wQqB90nyowL7NXyiV/SwSpORJ/HxZnNVSnh3qtfotEU4W94Uc7z38KlrvpzlUof2Op8AIUUh2ZDHyuAYsi/s06JrMKlYd/FiwvQHFKTKc89wMy9MJpSRroymO/x36vHjdSvvKWPj1ncg1IW3koET1Jae6WHyJq1I2NHEIymdzpe7impfXeFsCNVsIPmUuAHe+x6KlbjGXYRPdJUc2igk4IGax9YjxOKIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EeLaVPmX1vlCVBZKbQQ7rnhvfmv2uksKlzY3bH6j6iQ=; b=O/FnaqCyqHLyWNC352flk49JfLaE+AGEvh6HNmzTkLxMXDonkN2keF0ByMbryfLIabjtLxwOur2yyc/EWcYZeaS58HpUDlbUNTbVmua4gqts/GmHasgfWpQyMqGda97SGZBegfWax1wrGI/jcpPmrwoQwkNLobFFrLPOx/bG9DA= Received: from BN9PR03CA0958.namprd03.prod.outlook.com (2603:10b6:408:108::33) by BL1PR12MB5127.namprd12.prod.outlook.com (2603:10b6:208:31b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20; Tue, 1 Jun 2021 14:46:21 +0000 Received: from BN1NAM02FT009.eop-nam02.prod.protection.outlook.com (2603:10b6:408:108:cafe::95) by BN9PR03CA0958.outlook.office365.com (2603:10b6:408:108::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.21 via Frontend Transport; Tue, 1 Jun 2021 14:46:21 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BN1NAM02FT009.mail.protection.outlook.com (10.13.2.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.30 via Frontend Transport; Tue, 1 Jun 2021 14:46:20 +0000 Received: from MacBook-Air.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 151EkIHw016341 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 1 Jun 2021 10:46:19 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <90facc4d-f0e8-d3a0-8489-ae37347eeef3@alum.mit.edu> Date: Tue, 1 Jun 2021 10:46:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0007be86-dda2-4019-f810-08d9250c054b X-MS-TrafficTypeDiagnostic: BL1PR12MB5127: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: b0pFB7c5+PM3Gu0iGBEnWc4N2mccp0aBBQ9tx5+uNo7rqXpF1byyhw37bQabtk69d8TGraGQdu9Z5SlTtTPPDefldXtiqxuSw3qQ9vpyzXF9vMFtHggeEy+QKXCTs/96apZ5rKvsW8eojg47XpEVkdVMIAmOkRq175LSNRtwrAUBH+XtXVdCG+4YZrg0IY459ou4E7HhQjhubmowmjEywbUBFzkFEpDgIeWImGa7+DBj0XdW1DExY3WBsCtlnKPfc8NdBV3Yd9fRgHRI4u9ikiI7d8BXj8AdVnBSkWuMUwyVtI4zpG6f8zt3b+BoXUWccH+4k3s/mNrE1d/y16cWSjTOAQOqKJhdhl07LG9I9BQFFhJjVfsinrM+535YarazDdzFAEk3YfbNHGMg5ANsWv/SRfn/B0UdEFqg9L24yDN9lJlM3BkBsW/yHNXJfZXQo55YnFVEGQWFWEV/secYGk695hVjWTBEBN+vOUiCfsXWMafNtH6acE769dzOZMcib7vfGjO31hdWq8UGF5WpwwrCCqmcpDIrzbWxEBPW7Tb8fseZ/NFN0xo6VN/53H80mp7RHbfqvASMYxMyhh5/Bc7Qau9Y5lMVjkmtEI18TkRvut9ZQ/2ap/2mXXZrZJvqIqDolUU3ZfD16GyMdqo3RqvZdulLy8X3/TOpc+7iMANKLk1zKgNfiA3NbSN+6sXYQl3ZfOqfoPqe7v/QQbdxTFEUMZBb0B2h7iUi9wXgH6hZw+PmB6rM6fl8gLe8ZP5qdD90tk6wNy2rELLGUPcN5eyit7lZgs9iaJvQit7iRb2JVt436RIddONJNTmq6hdb X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(376002)(346002)(136003)(396003)(39860400002)(36840700001)(46966006)(966005)(478600001)(45080400002)(336012)(83380400001)(5660300002)(70206006)(8936002)(7596003)(186003)(36860700001)(8676002)(356005)(47076005)(31696002)(82740400003)(31686004)(6916009)(75432002)(53546011)(36906005)(70586007)(316002)(26005)(786003)(2906002)(86362001)(82310400003)(956004)(2616005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2021 14:46:20.7486 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0007be86-dda2-4019-f810-08d9250c054b X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT009.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5127 Archived-At: Subject: Re: [sipcore] RFC 4028 UAS behavior requirement of Require header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 14:46:30 -0000 Hoil, I already replied once about this. I'll try again. The simple answer to why the UAS should add Require:timer is that RFC4028 says that it must. Arguing that 4028 could have been written differently is a futile exercise. That RFC was written over 16 years ago, and people have been implementing it since long before it became an rfc. Are you imagining that anyone will revise the rfc or change their implementations for your convenience? Thanks, Paul On 5/28/21 4:18 PM, Hoil Choi wrote: > Hi Ranjit, thanks for taking a look. > > However, I'm more interested in case where UAS is responding to UAC's > request with refresher as itself (uac).  Consider this case - > > UAC ---- INVITE (Session-Expires: 1800;refresher=uac, Supported: timer) > ----> UAS > UAC <---- 200 OK (Session-Expires: 1800;refresher=uac) > --------------------- UAS > > In this case, the statement in question seems to convey that UAS should > also add "Require: timer" in its 200 response.  Why would this be, when > it's clear that UAC declared itself as the refresher and that timer is > supported? > > For reference, RFC 4028 Section 9 UAS Behavior (or page 16) > If the refresher parameter in the Session-Expires header field in the > 2xx response has a value of 'uac', the UAS MUST place a Require header > field into the response with the value 'timer'. > > Thanks, > Hoil > > ------------------------------------------------------------------------ > *From:* Ranjit Avasarala > *Sent:* Friday, May 28, 2021 12:38 PM > *To:* Hoil Choi ; > Sip-implementors@lists.cs.columbia.edu > > *Cc:* sipcore@ietf.org > *Subject:* Re: [sipcore] RFC 4028 UAS behavior requirement of Require > header > Hi Holi > the presence of the "Require" header with value "timer" from UAS > indicates to UAC that it (UAC) is performing the refreshing operation. > but if the UAS is the refresher, then if Require header with value > "timer" is present in response from UAS, then UAC should send BYE if it > does not receive a session refresh request from UAS. > > Regards > Ranjit > > > > On Fri, May 28, 2021 at 10:02 AM Hoil Choi > wrote: > > Hello, > > I hope this mail finds appropriate person or team for an answer to > my question on RFC 4028. > I am a SIP enthusiast and always learning a lot about it, but by no > means am I an expert; so please excuse my ignorance. > > I came across an interesting statement In Section 9 UAS Behavior (or > page 16). > > > If the refresher parameter in the Session-Expires header field in the >    2xx response has a value of 'uac', the UAS MUST place a Require >    header field into the response with the value 'timer'. > > > Statement seems to convey that UAS must place a Require header with > value 'timer' when UAC requests itself to be the refresher. > > However, this statement should only be true, if UAC did not put > Session-Expire with value of 'uac'. > > If UAC, in INVITE request, put Session-Expire with value of 'uac' > (itself), UAS should not bother putting Require header field in the > response.  Or to be more accurate, UAC should include 'timer' in > Supported header, so that UAS doesn't have to bother putting Require > header field. > > What is the reason behind the requirement of Require header, from > UAS in this case? > > Thanks! > Hoil Choi > 253-273-5442 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Jun 1 09:02:57 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EE73A1C86 for ; Tue, 1 Jun 2021 08:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvqTwAWm5Q8e for ; Tue, 1 Jun 2021 08:40:29 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12olkn2010.outbound.protection.outlook.com [40.92.21.10]) (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 AC58A3A1C87 for ; Tue, 1 Jun 2021 08:40:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kxX9XKm1QAJLOwDQQWCafDAIdFFiWG+neQybE9XVda3lBaX+t/2qPP6pMmx7WKwwTafl1tFNRTAIaJJCqvpNISMRWx/32pVuJ+0IAlXN9rCb/YTEcKSUd1+XaYPV4vmhKHfSpWnP81e5brfuXpecr6QLWqYTt7czEaGvO+MsXtJo5kZZI7jGOOCaFb7tBa4jts/Qz87NB/m7bYcGpxNGCh4H+U8jwSMSRjg9cX57zNzv2fuhZeeImeeDSJh5SfiASbimLecBbGYQHNyQs54D/Mnn+F+WbvbPQADybHvji9e60dt3Hjkg2krwzlD7L8JTNrirOmc1C3RFbCzeSucwhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GbqYfR7TP1x/83a55n4VQcvYdTsqaaaiSbC3PZ3QAt0=; b=nrbTyOnYvu+j+ZNQVV/R0JP2pheZvKn2LIubDd7dXvI9yeq2KHxG3gp0HsEjkiOn5pLzGvmqpTkH6rert1959Ci+DA3Zvvd2Lf6iZEY9T+5VQBhFxG3NHfAa2t1podqj6hVgd2KhdeT1KXkNHRInB+yLHpuyPvSM8D2Qd91W2sAN3opzfcMggJJzczXlC2qzJX3LwG+R3fcZ/3fOZLNJb5MGuxFCAyk6zulcck5rMJAXAVkdPQiphBHuKIVFI6wj90oFHs91OTMDtTvYQCTtOnFAKmioI6BPpVigh3FMnHTApBCvensh6Vqr1sCed+75w/ueZ+QMPoYmiwcuELCRsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GbqYfR7TP1x/83a55n4VQcvYdTsqaaaiSbC3PZ3QAt0=; b=lqwLO9x+960gNFnxMNXYOhndT67BpPW6MPeXHFXTTwdxnrla8neiZ3POt1dLAmMrFzpQKXXXJqY2fn7MlmwV0TKnRZhI4vgjYOhG4xxrLo/kp0L7lihcbX+SsWuI2XR038yZ6LMYLyf0mLHhZxMrhNvJ/2mTJVp5n5RKhbB/MbXE30lbpCp7hmixgfkh5AouIwdv9FfgmRRAopTK0UzLfnOzI0x2S6hiB3u1hbiQ6N9QZrpweLoKPg+YuLbbC5+I5IhiJi8CSXIKsGzxFqVaEWemBl5mu3fDKuU8/0aILFkirjTke/NHomZkUM2jOCBnsKHJHY60fJRQrGXuvPRpag== Received: from MW2NAM12FT057.eop-nam12.prod.protection.outlook.com (2a01:111:e400:fc65::4a) by MW2NAM12HT144.eop-nam12.prod.protection.outlook.com (2a01:111:e400:fc65::291) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.10; Tue, 1 Jun 2021 15:40:26 +0000 Received: from CO6PR02MB7603.namprd02.prod.outlook.com (2a01:111:e400:fc65::40) by MW2NAM12FT057.mail.protection.outlook.com (2a01:111:e400:fc65::261) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.10 via Frontend Transport; Tue, 1 Jun 2021 15:40:26 +0000 Received: from CO6PR02MB7603.namprd02.prod.outlook.com ([fe80::11c6:9a98:84a:7f22]) by CO6PR02MB7603.namprd02.prod.outlook.com ([fe80::11c6:9a98:84a:7f22%7]) with mapi id 15.20.4173.030; Tue, 1 Jun 2021 15:40:26 +0000 From: Hoil Choi To: Ranjit Avasarala CC: "Sip-implementors@lists.cs.columbia.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 4028 UAS behavior requirement of Require header Thread-Index: AQHXU42WCj5aHc4bTkuBkpJKe+ECaKr5St6AgAAHxtSAAAmpgIAF9SGQ Date: Tue, 1 Jun 2021 15:40:26 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:B5CFB406C7646DE18D13321FB6A26F6AD8D63EF04580ABAF4C4FF5D770A4DF33; UpperCasedChecksum:E20DB0EC5CA6EF39F0361907FD6ED65477EE956C5E8ED510D3F74D29B372872C; SizeAsReceived:7322; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [BjMEBQs3HxobzOEKFltQyvOedqC//DJl] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 9bd258eb-3354-4ec7-efd5-08d9251393f2 x-ms-traffictypediagnostic: MW2NAM12HT144: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kTIAgSHsqNy9LuCsaX0iAYfRJvMsVlbn3GTjSFTG9g+DNSuHpLPa2+jvzMOi6yvChx1LdVD4IRR59LAgFtelth/eG1en5lmJBd18F8G7l+a2oc2JX2WGnIK1lKLMVSyZ5Ow9Kiu0ZiX7Fwy6bNVlyJP67Q86hA1evZ5G3SpeLnz4dNbrJXOZCosoKPaCuLlZWhmamLmd2BQYibABIdusJZJauzTzE0jJZ0bpLlunDld0ECchVjZJ4nn6Hdj/LR3g9LZVWJL33LCRa9spipL7dDyLCmGpTKw4STMKqs91pRz0s0HvVvOVBwvt8mSE3DOJn2hKz3hw7unexHJgcxGOWa/Sw/pKfAYCwKiEqBxaBY0mzUsRzqxe6lhcv5IHQvHS4SbAQYu6ozzQCd/PkpWYi1QGePYsHFtx6VWD0wnEfhBovLjjr1vK9ZqwVIlF98xYqeMn+EMG312VB602UgNwW3u6v50Br2aHijcKRt93kA8= x-ms-exchange-antispam-messagedata: Mxlsbzgb2Yhr6e9Qh7sjNqr0/JRjNMgHMujUFiyO54ItOgbhM4q0zYJrMotOXenA4DNSpmjop9w18w/gLfvKfkYBnU5wLgW3MicLSgPw1GtjSMXj59wTPw+egmyIZsBnQkLPFklGLkRmKnax6sF2MA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR02MB7603F4213B0FAE0D788F7150EE3E9CO6PR02MB7603namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT057.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 9bd258eb-3354-4ec7-efd5-08d9251393f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2021 15:40:26.5169 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM12HT144 Archived-At: X-Mailman-Approved-At: Tue, 01 Jun 2021 09:02:55 -0700 Subject: Re: [sipcore] RFC 4028 UAS behavior requirement of Require header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 15:40:39 -0000 --_000_CO6PR02MB7603F4213B0FAE0D788F7150EE3E9CO6PR02MB7603namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Ranjit. The word "MUST" seems to throw some vendors off. I saw at = least one device that behaves this way due to the word "MUST". Is there wa= y to get that reviewed and edited? Thanks, Hoil ________________________________ From: Ranjit Avasarala Sent: Friday, May 28, 2021 1:40 PM To: Hoil Choi Cc: Sip-implementors@lists.cs.columbia.edu ; sipcore@ietf.org Subject: Re: [sipcore] RFC 4028 UAS behavior requirement of Require header Hi Holi The RFC says UAS should add a Require: timer in response when UAC is the re= fresher to indicate to UAC that it is the refresher. But I think this is re= dundant as UAC anyway knows it is the refresher and does not need a reminde= r from UAS. On Fri, May 28, 2021 at 3:18 PM Hoil Choi > wrote: Hi Ranjit, thanks for taking a look. However, I'm more interested in case where UAS is responding to UAC's reque= st with refresher as itself (uac). Consider this case - UAC ---- INVITE (Session-Expires: 1800;refresher=3Duac, Supported: timer) -= ---> UAS UAC <---- 200 OK (Session-Expires: 1800;refresher=3Duac) ------------------= --- UAS In this case, the statement in question seems to convey that UAS should als= o add "Require: timer" in its 200 response. Why would this be, when it's c= lear that UAC declared itself as the refresher and that timer is supported? For reference, RFC 4028 Section 9 UAS Behavior (or page 16) If the refresher parameter in the Session-Expires header field in the 2xx r= esponse has a value of 'uac', the UAS MUST place a Require header field int= o the response with the value 'timer'. Thanks, Hoil ________________________________ From: Ranjit Avasarala = > Sent: Friday, May 28, 2021 12:38 PM To: Hoil Choi >; Sip-im= plementors@lists.cs.columbia.edu > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RFC 4028 UAS behavior requirement of Require header Hi Holi the presence of the "Require" header with value "timer" from UAS indicates = to UAC that it (UAC) is performing the refreshing operation. but if the UAS= is the refresher, then if Require header with value "timer" is present in = response from UAS, then UAC should send BYE if it does not receive a sessio= n refresh request from UAS. Regards Ranjit On Fri, May 28, 2021 at 10:02 AM Hoil Choi > wrote: Hello, I hope this mail finds appropriate person or team for an answer to my quest= ion on RFC 4028. I am a SIP enthusiast and always learning a lot about it, but by no means a= m I an expert; so please excuse my ignorance. I came across an interesting statement In Section 9 UAS Behavior (or page 1= 6). If the refresher parameter in the Session-Expires header field in the 2xx response has a value of 'uac', the UAS MUST place a Require header field into the response with the value 'timer'. Statement seems to convey that UAS must place a Require header with value '= timer' when UAC requests itself to be the refresher. However, this statement should only be true, if UAC did not put Session-Exp= ire with value of 'uac'. If UAC, in INVITE request, put Session-Expire with value of 'uac' (itself),= UAS should not bother putting Require header field in the response. Or to= be more accurate, UAC should include 'timer' in Supported header, so that = UAS doesn't have to bother putting Require header field. What is the reason behind the requirement of Require header, from UAS in th= is case? Thanks! Hoil Choi 253-273-5442 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_CO6PR02MB7603F4213B0FAE0D788F7150EE3E9CO6PR02MB7603namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Ranjit.  The word "MUST" seems to throw some ven= dors off.  I saw at least one device that behaves this way due to the = word "MUST".  Is there way to get that reviewed and edited?<= /div>

Thanks,
Hoil

From: Ranjit Avasarala <= ranjitkav12@gmail.com>
Sent: Friday, May 28, 2021 1:40 PM
To: Hoil Choi <hoil.choi@hotmail.com>
Cc: Sip-implementors@lists.cs.columbia.edu <Sip-implementors@list= s.cs.columbia.edu>; sipcore@ietf.org <sipcore@ietf.org>
Subject: Re: [sipcore] RFC 4028 UAS behavior requirement of Require = header
 
Hi Holi

The RFC says UAS should add a Require: timer in response when UAC is t= he refresher to indicate to UAC that it is the refresher. But I think this = is redundant as UAC anyway knows it is the refresher and does not need a re= minder from UAS.

On Fri, May 28, 2021 at 3:18 PM Hoi= l Choi <hoil.choi@hotmail.com> wrote:
Hi Ranjit, thanks for taking a look.  

However, I'm more interested in case where UAS is responding to UAC's reque= st with refresher as itself (uac).  Consider this case - 

UAC ---- INVITE (Session-Expires: 1800;refres= her=3Duac, Supported: timer) ----> UAS<= /div>
UAC <---- 200 OK (Session-Expires: 1800;refresher=3Duac) -----------= ---------- UAS

In this c= ase, the statement in question seems to convey that UAS should also add &qu= ot;Require: timer" in its 200 response.  Why would this be, when = it's clear that UAC declared itself as the refresher and that timer is supported?  

For refer= ence, RFC 4028 Section 9 UAS Behavior (or page 16)
If the refresher parameter in the Session-Expires= header field in the 2xx response has a value of 'uac', the UAS MUST place a Require header field into the respo= nse with the value 'timer'.

Thanks,
Hoil

F= rom: Ranjit Avasarala <ranjitkav12@gmail.com>
Sent: Friday, May 28, 2021 12:38 PM
To: Hoil Choi <hoil.choi@hotmail.com>; Sip-implementors@lists.cs.columbia.edu <Sip-implementors@lists.cs.= columbia.edu>
Cc: sipcore@ie= tf.org <sipcor= e@ietf.org>
Subject: Re: [sipcore] RFC 4028 UAS behavior requirement of Require = header
 
Hi Holi
the presence of the "Require" header with value "timer&= quot; from UAS indicates to UAC that it (UAC) is performing the refreshing = operation. but if the UAS is the refresher, then if Require header with val= ue "timer" is present in response from UAS, then UAC should send BYE if it does not receive a session refresh request from UAS.=

Regards
Ranjit



On Fri, May 28, 2021 at 10:02 AM Hoil Choi <hoil.choi@hotmail.com&g= t; wrote:
Hello, 

I hope this mail finds appropriate person or team for an answer to my quest= ion on RFC 4028. 
I am a SIP enthusiast and always learning a lot about it, but by no means a= m I an expert; so please excuse my ignorance.  

I came across an interesting statement In Section 9 UAS Behavior (or page 1= 6).

If the refresher parameter in the Session-Ex=
pires header field in the=0A=
   2xx response has a value of 'uac', the UAS MUST place a Requir=
e=0A=
   header field into the response with the value 'timer'.

Statement seems to convey that UAS must place a Require header with value '= timer' when UAC requests itself to be the refresher.  

However, this statement should only be true, if UAC did not put Session-Exp= ire with value of 'uac'.  

If UAC, in INVITE request, put Session-Expire with value of 'uac' (itself),= UAS should not bother putting Require header field in the response.  = Or to be more accurate, UAC should include 'timer' in Supported header, so = that UAS doesn't have to bother putting Require header field.  

What is the reason behind the requirement of Require header, from UAS in th= is case?

Thanks!
Hoil Choi
253-273-5442

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