From nobody Mon Oct 2 04:15:44 2017 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 A7B1F13459F for ; Mon, 2 Oct 2017 04:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 QWjrfu7ooHYy for ; Mon, 2 Oct 2017 04:15:38 -0700 (PDT) Received: from know-smtprelay-omc-8.server.virginmedia.net (know-smtprelay-omc-8.server.virginmedia.net [80.0.253.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA461329F9 for ; Mon, 2 Oct 2017 04:15:37 -0700 (PDT) Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-8-imp with bizsmtp id GbFa1w00C3hDt9d01bFbBp; Mon, 02 Oct 2017 12:15:35 +0100 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.1 cv=Fvv4hDfq c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=48vgC7mUAAAA:8 a=0ZgzDHaQzhVBHrr1te0A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 To: sipcore@ietf.org References: <150667511763.14067.17235300359095515956@ietfa.amsl.com> From: Keith Drage Message-ID: <5ad25988-ee9d-7aa7-b06c-a9f840f4102d@ntlworld.com> Date: Mon, 2 Oct 2017 12:15:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150667511763.14067.17235300359095515956@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1506942935; bh=/t5Dfq6K/5esdqj8frDDhkoPJFQBrGvVe2zkNCDon6g=; h=Subject:To:References:From:Date:In-Reply-To; b=qb2vC9nfIjIfXgSTMdccLUfFgBwG16Qq30UW0MBccw98GclMsgvGntwAZLbEZiMuH UhVRGBi0io05+sE/5I99GVYBk+9799TsGhxd0PDHXt2xZN7uRbmZ3QW09+I6oHWzuU xK1TX2VHhFRlm2jcMTGY8joaEM0bSWMRzLGb5dBFqHnSFOdnj5MMrBhzIS9fekkr6S 74bijmcUgjY70oFezTUfWKtfpqykYH5i/k49S7SUqo9U3ZtBBIyknE4s2V8T7bETHi jF/jLN7mwWsnfETQJwd76ZZSX5tnm5Co/y6ocAUqgRyWguL7k3c/ihCsYPuUS18AhF unn3LD+RX9hLQ== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 11:15:42 -0000 I notice neither the ABNF or the text provide normative restrictions to limit this parameter to the case where the value "q850" is used elsewhere in the Reason header field. So consider the case where I have implemented SIP, the Reason header extension, and this extension. I then receive a Reason header field with a value different to q850, but with a location. Presumably this should be considered a error, but t would appear that syntactic analysis based on the ABNF does not throw this out and I have to get to the level of "does the received information make sense" working outside what the draft describes, before deciding what to discard, and the document offers nothing in terms of telling me just to discard the location, or to discard the entire Reason header field. In general I would think I would just discard the erroneous location, but the document does not tell me so. Keith On 29-Sep-17 9:51 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core WG of the IETF. > > Title : ISUP Cause Location Parameter for the SIP Reason Header Field > Author : Roland Jesske > Filename : draft-ietf-sipcore-reason-q850-loc-01.txt > Pages : 6 > Date : 2017-09-29 > > Abstract: > The SIP Reason header field is defined for carrying ISUP cause values > as well as SIP response codes. Some services in SIP networks may > need to know the ISUP location where the call was released in the > PSTN network to correctly interpret the reason of release. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-loc-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-reason-q850-loc-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Oct 2 04:26:47 2017 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 866831345BF for ; Mon, 2 Oct 2017 04:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=Bp3+p2Vw; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=rBHsM6/o 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 1o01FkfyXJYg for ; Mon, 2 Oct 2017 04:26:42 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 D34D91345BA for ; Mon, 2 Oct 2017 04:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1506943602; x=1538479602; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=diurmqTP2D9eJW2+XvacS50IZi1JZe0cdbDnHNgrWDU=; b=Bp3+p2VwBT8Tc4zQoZnqub2SLuWYuBAm29a2IdzqM/Q+8H3L1Tddm+3/ 29H5eg2+tYT+pp5ecFWOXhAtZxGEN9pdWToiaegEPXfAEoGINE6dRm64i k+n0CBh6XhPje1rSB5njFAmkFbAIyN8iTOI0SETlc8suTl3GNrLvhuIsS xx1bhUO5iplmqE46Yni4zR70zWFGoW4lLEf/l3GzISz6e/D2TDR5PNj4h nBZ2RMCq/nxGJRAu9cqc1cej7a0l4t7LXxQlXZgwCAqT1qUfSmFlIYd/X 8m7cTySbJo4g803IfDFLK1Q8pyto5Zh0vTwdJnvmZn3UiwlSaY8FlCBXG w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2017 13:26:38 +0200 X-IronPort-AV: E=Sophos;i="5.42,469,1500933600"; d="scan'208";a="43733688" Received: from he104852.emea1.cds.t-internal.com ([10.169.118.15]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 02 Oct 2017 13:26:37 +0200 Received: from HE105709.EMEA1.cds.t-internal.com (10.169.118.41) by HE104852.emea1.cds.t-internal.com (10.169.118.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 2 Oct 2017 13:26:37 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105709.EMEA1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Mon, 2 Oct 2017 13:26:37 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.18) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 2 Oct 2017 13:26:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=diurmqTP2D9eJW2+XvacS50IZi1JZe0cdbDnHNgrWDU=; b=rBHsM6/oaEVnc8VJW0zvU24QmCYIhxjUC/hQcBOXTq+1gbWy3TA8XPrCdIQ87DcERA73mFubtKAr/fzOZC9W3DTFbowKrb5N1UbHkXsE4MVRvsEsQw5csx9msu7HFQMKlOo+evJBISYI+KS8G34Pv3sqsS2djeUunVcN8u4QXB0= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0482.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 2 Oct 2017 11:26:36 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Mon, 2 Oct 2017 11:26:36 +0000 From: "Jesske, Roland" To: Keith Drage , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-01.txt Thread-Index: AQHTOQBR6wcVoN3w/0yCrpG6NHPRAKLQbYkAgAAB0UA= Date: Mon, 2 Oct 2017 11:26:36 +0000 Message-ID: References: <150667511763.14067.17235300359095515956@ietfa.amsl.com> <5ad25988-ee9d-7aa7-b06c-a9f840f4102d@ntlworld.com> In-Reply-To: <5ad25988-ee9d-7aa7-b06c-a9f840f4102d@ntlworld.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.186] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:ebNbneD2X0Fal25I3kVyyFFTQiWFvSoGhomLuWjwn0z9PggXBfSErt44Xbw24/2/E2i0z4uD0i2RNq4uHvfevrDt0D1gs3bjqX8sgblMQi8Oq6MW/9YP62FA+k8QShV82KDwZsQSwxckzDKbYFTB1C9MiVQZx0M2P1sGb9A57i3ZMx/hVegeQNglM5dZMVF6aYzM8AyF+AdnqEWCn6ALLKIDRTZKkGmziFUAI+V16rBJdqRxy4ezFJhE+lxsVmUvU7qktvcKqIShK44OOpoDP4Iz675nEaIYTEFEDlHAsa2hKKpS1S3OE0hZapoaxstxvYuk3Fr1Wybqs4Ymk1QI2g==; 5:SmNSwaYfp+fj8y2Z9Zo3/MXl6skmtCljCuCgd4EyaYFVFXNlyzbaGUrFNebrtegLYeylcj+YQo5uEHz4Rl56NPkAng4qSdLFJm9m7QsPojK4x+rfwctNuDiY2QncccceWF2Ys3wjD7fkF1VTpMGzzQ==; 24:vQ0MdN/g9QzFDJgNqKumNHFUYHSuWznrA7IFlJYFn4NHJuHxJQnkSTE9rP+rAiqKyrwNlcJSxX+fN/LHpND+tcdFrVaPatCVHzH1KbGLA7I=; 7:pbP9uml/0TmAdl9vbja9a7hiaos9u1kc7fH3mBgV0LyaVuDUXV527W/Rp+VJdRh0pvFRyDAd6kOHS9MkFZwb51Wrv379BRPg6nLMWAZnEf2anV5uyv+Vng02RoGByCzTmSc8fKGk/I9496jUJAfTCmfyVA5ygTtvUlZGS9B7OsE5jly7/WJEzwdP9dtnmRDxx3h3GaAFDOwCJI/692h+z7oR+Sq76M0L+Hv3WzG4+E0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0785a5a7-5fa0-40c9-1ce9-08d509887169 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0482; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0482; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(377454003)(24454002)(189002)(377424004)(97736004)(76176999)(189998001)(7736002)(305945005)(50986999)(106356001)(72206003)(966005)(9686003)(53546010)(54356999)(3846002)(2501003)(8656003)(230783001)(86362001)(102836003)(478600001)(5660300001)(33656002)(5250100002)(75402003)(74482002)(3280700002)(3660700001)(6116002)(8676002)(2900100001)(8936002)(2950100002)(55016002)(81156014)(14454004)(81166006)(316002)(66066001)(7696004)(345774005)(68736007)(2906002)(105586002)(6306002)(110136005)(53936002)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0482; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 11:26:36.5084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0482 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 11:26:45 -0000 Hi Keith, Thank you for your comment. You are right, this should be considered and I will add some words describi= ng such procedure. i.e. discarding the location. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Keith Drage > Gesendet: Montag, 2. Oktober 2017 13:16 > An: sipcore@ietf.org > Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-01.= txt >=20 > I notice neither the ABNF or the text provide normative restrictions to l= imit > this parameter to the case where the value "q850" is used elsewhere in th= e > Reason header field. >=20 > So consider the case where I have implemented SIP, the Reason header > extension, and this extension. I then receive a Reason header field with = a > value different to q850, but with a location. Presumably this should be > considered a error, but t would appear that syntactic analysis based on t= he > ABNF does not throw this out and I have to get to the level of "does the > received information make sense" working outside what the draft describes= , > before deciding what to discard, and the document offers nothing in terms > of telling me just to discard the location, or to discard the entire Reas= on > header field. >=20 > In general I would think I would just discard the erroneous location, but= the > document does not tell me so. >=20 > Keith >=20 > On 29-Sep-17 9:51 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Session Initiation Protocol Core WG of= the > IETF. > > > > Title : ISUP Cause Location Parameter for the SIP Re= ason Header > Field > > Author : Roland Jesske > > Filename : draft-ietf-sipcore-reason-q850-loc-01.txt > > Pages : 6 > > Date : 2017-09-29 > > > > Abstract: > > The SIP Reason header field is defined for carrying ISUP cause valu= es > > as well as SIP response codes. Some services in SIP networks may > > need to know the ISUP location where the call was released in the > > PSTN network to correctly interpret the reason of release. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-l > > oc-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-reason-q850-loc-= 0 > > 1 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Oct 4 11:29:11 2017 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 88B6F134466 for ; Wed, 4 Oct 2017 11:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGyw3feuUU4c for ; Wed, 4 Oct 2017 11:29:08 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AB3134467 for ; Wed, 4 Oct 2017 11:29:07 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id 6so11884379qtw.3 for ; Wed, 04 Oct 2017 11:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=q6lERpRVej4mFDm2eBEepYGnlxhfNggNFG+tTyGTtHs=; b=MPbmX/28g9oIkiFJpYQkNWSn48as4d0OYxIt4aMODW/sd3bXCu3e6oFExBF8jr7unM yOygHnvyF9lNSK+kRIpAUmgP2ylXH8D12z24I0odI6V8wHQSnEWQNOknzFkHqRgY5Ncg jydiKoom7k3vuKnddmmJKffVisX/HTmHUMh//fEbNje+fma4ZZoybZjIyiJONORfWBah GeL0IpZq7/kDtN49IUK+dZXHo4TdTHaXoH8HFVhJxaUrYx8+uuuyb/GmmFJOu4wpGptg giN5iH7tFXF00L6S+Gs4yRNUkgHuTLfI/7CbVqPK3NY+T2/eCQodfgZj8X6Z1RKQAfep v5ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=q6lERpRVej4mFDm2eBEepYGnlxhfNggNFG+tTyGTtHs=; b=I8DGWqc7FRP09xQ1Sl9aGes0aIsOozfsdNMdDoOZbooBqEzPYGvk1SP9FJW16lANf/ rUsE4AL9vfV3UaydVJV2tWxccfINgh2rmZTJbSkhw3cRA40B6XxXgbLaikJ4PJQEhA5O 0OlwBsyKZRht4Of9Uye0PBJriEpjsA1K1rx7JwIcoKdBUTU0wT/v1YR8JSLjc9Z8AjkD Q0jDzGCT1cg2Sx5D1L+OkzjbkMuESl/6ehwIPDEz/e/1ULchTRst1QhrScsh8WovlR74 NjYGlyTdKmHIfpGX8em+4oqOBRtXcHT4LD3wbcvAk5BwHz2CmKrYrRDqpHazWz/T5u6Q ApGA== X-Gm-Message-State: AMCzsaXh3d/Hz9H+F/4WZyL0UYDpvEzspBZIG9EXrEB6lJbmS+5GthsL PcGUV+gTzBJ8dubxLIrKkqusqGgUOmQ= X-Google-Smtp-Source: AOwi7QAIx9W38VlUsMcEGlRKPGBEt1Wz3L1L93h3c/MGIYwqNFvnHXJZ+GaNUdSO2FzQcDRf7I89ow== X-Received: by 10.200.46.188 with SMTP id h57mr22484985qta.9.1507141745950; Wed, 04 Oct 2017 11:29:05 -0700 (PDT) Received: from [10.33.192.12] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id t65sm10229221qke.12.2017.10.04.11.29.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 11:29:04 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_891724C8-0FE8-4FF5-97E8-D989DEC82680" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 4 Oct 2017 14:29:02 -0400 References: To: sipcore@ietf.org In-Reply-To: Message-Id: <3A02C487-C2A0-48E1-AB31-6DCB618E96AD@brianrosen.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:29:09 -0000 --Apple-Mail=_891724C8-0FE8-4FF5-97E8-D989DEC82680 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There were quite a few messages in support and no opposed. Chairs will = request the item be added to our work, and a new milestone be created. = The author is requested to submit the draft as draft-ietf-sipcore=E2=80=A6= Brian > On Sep 19, 2017, at 9:33 AM, Brian Rosen wrote: >=20 > We propose to adopt draft-holmberg-sipcore-sessiontimer-race as a = sipcore document. Please provide comments by October 3. >=20 > Brian --Apple-Mail=_891724C8-0FE8-4FF5-97E8-D989DEC82680 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There were quite a few messages in support and no opposed. =  Chairs will request the item be added to our work, and a new = milestone be created.  The author is requested to submit the draft = as draft-ietf-sipcore=E2=80=A6

Brian

On Sep 19, 2017, at 9:33 AM, = Brian Rosen <br@brianrosen.net> wrote:

We propose to = adopt draft-holmberg-sipcore-sessiontimer-race as a sipcore = document.  Please provide comments by October 3.

Brian <as = co-chair>

= --Apple-Mail=_891724C8-0FE8-4FF5-97E8-D989DEC82680-- From nobody Wed Oct 4 11:57:53 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F70512008A; Wed, 4 Oct 2017 11:57:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150714347137.24171.15578541201861207553@ietfa.amsl.com> Date: Wed, 04 Oct 2017 11:57:51 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:57:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Session Initiation Protocol (SIP) Session Timer Glare Handling Author : Christer Holmberg Filename : draft-ietf-sipcore-sessiontimer-race-00.txt Pages : 8 Date : 2017-10-04 Abstract: This document updates RFC 4028, by clarifying the procedures for negotiating usage of the Session Initiation Protocol (SIP) session timer mechansim, in order to avoid a race condition where both endpoints trigger simultaneous negotiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontimer-race/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-race-00 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sessiontimer-race-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 4 11:59:18 2017 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 1EDD8134338 for ; Wed, 4 Oct 2017 11:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5uOL_4XH6BA for ; Wed, 4 Oct 2017 11:59:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2973A1321C9 for ; Wed, 4 Oct 2017 11:59:14 -0700 (PDT) X-AuditID: c1b4fb3a-0c5ff70000003fec-43-59d52f81ad0d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F3.17.16364.18F25D95; Wed, 4 Oct 2017 20:59:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Wed, 4 Oct 2017 20:59:12 +0200 From: Christer Holmberg To: Brian Rosen , "sipcore@ietf.org" Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race Thread-Index: AQHTMUvatfgcPPT9aUGtL1H2aON7xqLT+S4AgAAo9UA= Date: Wed, 4 Oct 2017 18:59:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56313C88@ESESSMB109.ericsson.se> References: <3A02C487-C2A0-48E1-AB31-6DCB618E96AD@brianrosen.net> In-Reply-To: <3A02C487-C2A0-48E1-AB31-6DCB618E96AD@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B56313C88ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdVLdR/2qkweZTUhZP709js/j6YxOb A5PH/W9/2T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx40YLa8Eah4o1Dw8wNjAeseti5OSQEDCR aDrdyNzFyMUhJHCEUeL42ZWMEM5CRolJFyeydzFycLAJWEh0/9MGaRAR8JK4e/M4G4gtLBAs ce7FQ2aIeIjEhdtr2SFsK4mJx+aA2SwCKhIHf15lAbF5BXwlbm2aA2YLCVRKHNzYyApicwo4 SdzvagKrZxQQk/h+ag0TiM0sIC5x68l8JohDBSSW7DnPDGGLSrx8/I8VwlaSWLH9EiNEfb7E 4ie3GSF2CUqcnPmEZQKj8Cwko2YhKZuFpGwW0JfMApoS63fpQ5QoSkzpfsgOYWtItM6Zy44s voCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYPQc3PLbagfjweeOhxgFOBiVeHjvyl+N FGJNLCuuzD3EKMHBrCTCm8kAFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZq akFqEUyWiYNTqoFxdbvG5XJtcbM1DRN/vC+a9e/cyu9JIiuiSuRK+GdXbD0+a8OtubJfJ/9e Hutos1W9fx3X7GfCTmFWUotVrY+dqk6U9g567rlKr+r4hyC+5hNr2zf113DFzf8U7Hmw9P5E Ju1m5w7RKcvb3xm9vq0b3/M2ev5xuctp60odJQs1PV2rohIOLVqrxFKckWioxVxUnAgAZT0+ RJoCAAA= Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:59:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B56313C88ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uZS4NCg0KVGhlcmUgYXJlIG5vIHRlY2huaWNhbCBjaGFuZ2VzIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gb2YgdGhlIGRyYWZ0IChkcmFmdC1ob2xtYmVyZykuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDogMDQgT2N0b2JlciAyMDE3IDIwOjI5DQpU bzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBDYWxsIEZvciBBZG9w dGlvbiBkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLXNlc3Npb250aW1lci1yYWNlDQoNClRoZXJlIHdl cmUgcXVpdGUgYSBmZXcgbWVzc2FnZXMgaW4gc3VwcG9ydCBhbmQgbm8gb3Bwb3NlZC4gIENoYWly cyB3aWxsIHJlcXVlc3QgdGhlIGl0ZW0gYmUgYWRkZWQgdG8gb3VyIHdvcmssIGFuZCBhIG5ldyBt aWxlc3RvbmUgYmUgY3JlYXRlZC4gIFRoZSBhdXRob3IgaXMgcmVxdWVzdGVkIHRvIHN1Ym1pdCB0 aGUgZHJhZnQgYXMgZHJhZnQtaWV0Zi1zaXBjb3Jl4oCmDQoNCkJyaWFuDQoNCk9uIFNlcCAxOSwg MjAxNywgYXQgOTozMyBBTSwgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpi ckBicmlhbnJvc2VuLm5ldD4+IHdyb3RlOg0KDQpXZSBwcm9wb3NlIHRvIGFkb3B0IGRyYWZ0LWhv bG1iZXJnLXNpcGNvcmUtc2Vzc2lvbnRpbWVyLXJhY2UgYXMgYSBzaXBjb3JlIGRvY3VtZW50LiAg UGxlYXNlIHByb3ZpZGUgY29tbWVudHMgYnkgT2N0b2JlciAzLg0KDQpCcmlhbiA8YXMgY28tY2hh aXI+DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B56313C88ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkRvbmUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGVyZSBhcmUgbm8gdGVjaG5p Y2FsIGNoYW5nZXMgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGUgZHJhZnQgKGRyYWZ0 LWhvbG1iZXJnKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5CcmlhbiBSb3Nlbjxicj4NCjxiPlNlbnQ6PC9iPiAwNCBPY3RvYmVyIDIw MTcgMjA6Mjk8YnI+DQo8Yj5Ubzo8L2I+IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtzaXBjb3JlXSBDYWxsIEZvciBBZG9wdGlvbiBkcmFmdC1ob2xtYmVyZy1zaXBj b3JlLXNlc3Npb250aW1lci1yYWNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlcmUgd2VyZSBxdWl0ZSBhIGZldyBtZXNzYWdlcyBpbiBzdXBwb3J0IGFu ZCBubyBvcHBvc2VkLiAmbmJzcDtDaGFpcnMgd2lsbCByZXF1ZXN0IHRoZSBpdGVtIGJlIGFkZGVk IHRvIG91ciB3b3JrLCBhbmQgYSBuZXcgbWlsZXN0b25lIGJlIGNyZWF0ZWQuICZuYnNwO1RoZSBh dXRob3IgaXMgcmVxdWVzdGVkIHRvIHN1Ym1pdCB0aGUgZHJhZnQgYXMgZHJhZnQtaWV0Zi1zaXBj b3Jl4oCmPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccmlh bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gU2VwIDE5LCAyMDE3LCBhdCA5OjMzIEFNLCBCcmlhbiBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJyQGJyaWFucm9zZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5XZSBwcm9wb3NlIHRvIGFkb3B0Jm5ic3A7ZHJhZnQtaG9sbWJlcmctc2lwY29yZS1zZXNz aW9udGltZXItcmFjZSBhcyBhIHNpcGNvcmUgZG9jdW1lbnQuICZuYnNwO1BsZWFzZSBwcm92aWRl IGNvbW1lbnRzJm5ic3A7YnkgT2N0b2JlciAzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QnJpYW4gJmx0O2FzIGNv LWNoYWlyJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B56313C88ESESSMB109erics_-- From nobody Thu Oct 5 01:37:07 2017 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 30359134550 for ; Thu, 5 Oct 2017 01:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6Ory-xPubYD for ; Thu, 5 Oct 2017 01:37:03 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 4FCC91331F5 for ; Thu, 5 Oct 2017 01:37:03 -0700 (PDT) X-AuditID: c1b4fb30-e9fff7000000155f-2c-59d5ef2d7f59 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7E.18.05471.D2FE5D95; Thu, 5 Oct 2017 10:37:01 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Thu, 5 Oct 2017 10:37:00 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgA== Date: Thu, 5 Oct 2017 08:37:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7ga7u+6uRBn//yFms2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGx7+NjAV3wyveX5vH2MC40KWLkZNDQsBE 4vicZ6wgtpDAEUaJv2vVuhi5gOyFjBLzLsxg6WLk4GATsJDo/qcNUiMiEChxdckEZhBbWEBK Ytq6ZawQcXmJ9TsvM0HYehKvthxjA7FZBFQkbnyBmM8rYC0xc91TsDijgJjE91NrwOqZBcQl bj2ZzwRxj4DEkj3nmSFsUYmXj/+B9YoCzdxw4jY7RFxJ4seGSywQvQYSR87dZIWwrSWu3t7C BmFrSyxb+JoZYq+gxMmZT1gmMIrMQrJuFpL2WUjaZyFpn4WkfQEj6ypG0eLU4qTcdCMjvdSi zOTi4vw8vbzUkk2MwCg5uOW3wQ7Gl88dDzEKcDAq8fBWP7waKcSaWFZcmXuIUYKDWUmE9+UN oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFex30XIoQE0hNLUrNTUwtSi2CyTBycUg2MSdvzOtdo x138cTg/U9Nn6/YHmRVXzs/udFJMYRG5yppS0LYpxXLVZ8N1wWoHYiQSJt3OUxdmEd6w99Ku Q8YPe8skY1993S9neo3jbHuWibF07kvtrVf11lzxn3T+/p4gfq791z9Ymjbs+5gro23+aNG+ Y+/Out/78Hzl1IQF3AKxvP9u7by3TImlOCPRUIu5qDgRAEgMOXOOAgAA Archived-At: Subject: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 08:37:06 -0000 Hi, >>=85 >>=20 >>> I'll propose that the session timer negotiation never be done with an >>> UPDATE within an INVITE transaction. (Regardless of whether than INVITE >>> is negotiating a session timer or not.) I think this resolves the >>> problem that you have encountered. (Or we could require that the UPDATE >>> and response care consistent session timer signaling with what is >>> carried in the INVITE and its responses.) >>=20 >> I had a chat with some product people, and they said that there actually >> ARE cases where the session timer is negotiated using UPDATE when the >> initial INVITE transaction is still ongoing. There are cases where the >> INVITE only contains Supported:timer, but the actual negotiation is done >> using UPDATE. > >Interesting! (I wonder why.) I haven=92t been able to figure out exactly why. I was just told the use-case exists. >That sequence itself presents some ambiguities. The way I have always >described how the session timer negotiation works is that *every* INVITE >and UPDATE transaction affects s-t - it either negotiates it *on* or >else it negotiates it *off*. (IMO this makes it very easy to understand.) > >That presents issues when you have an update nested inside of an invite. >In the case you describe I might expect that the update would negotiate >the timer on, and then the completion of the invite would negotiate it >off again. > >How would the case you describe work if a proxy inserted S-E in INVITE? >In that case, the UAC doesn't know about it until the 2xx from the >invite. Before then it might try enabling a timer using UPDATE. > >I am inclined to keep things simple by saying that the 2xx response to >every INVITE or UPDATE redefines the state of the session timer, either >on or off. That will of course break the use case you describe above. The problem here is that the UAC sends INVITE with S-E, and then receives an UPDATE with S-E before it has received a 2xx response to the INVITE - making the UAC think that there is a S-E glare situation (i.e., the UAS also tries to initiate session timer negotiation). I think the RFC is pretty clear on how things work once the session timer has been negotiated (and, if it isn=92t, we for sure can clarify that too). Regards, Christer >>>> >>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >>>> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>>>> seen from my point of view the UAC should ignore the Session timer >>>>>>> proposal within the UPDATE. >>>>>>> As long as the negotiation is ongoing. >>>>>>> >>>>>>> Nevertheless we have also observed this curious session timer >>>>>>> behavior >>>>>>> in our network. >>>>>>> >>>>>>> I think we need some clarifications to the RFC. Perhaps also to >>>>>>>other >>>>>>> sections to make it more readable. >>>>>>> My experience is that people have problems in following how the >>>>>>> session timer should work within a complex SIP networks (e.g. IMS). >>>>>>> >>>>>>> What is about updating the RFC4028. >>>>>> >>>>>> Like most of the older SIP RFCs, it probably deserves an update. The >>>>>> problem is whether going to the trouble will have any effect on >>>>>> implementations. I think the most we > should hope to do is >>>>>>*clarify* >>>>>> in >>>>>> cases where there is ambiguity, so that when interoperability >>>>>>problems >>>>>> arise it is clear who needs to change. >>>>> >>>>> Yes. In my case, implementation(s) WILL be changed. The question is >>>>> WHICH >>>>> implementation(s) :) >>>>> >>>>> So, my suggestion would be: >>>>> >>>>> 1) Specify/clarify that SE must not be sent during session-timer >>>>> negotiation >>>>> 2) Specify that one must send a 491 (or some other more appropriate >>>>> code) >>>>> response if receiving SE during session-timer negotiation >>>>> >>>>> For the above, I think we can do it using an errata. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>>>> -----Urspr=FCngliche Nachricht----- >>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>>>>> Christer Holmberg >>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>>>>> An: Paul Kyzivat ; sipcore@ietf.org >>>>>>> Betreff: Re: [sipcore] Session-timer issue >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>>> The following issue has been around for some time already (there >>>>>>>>>is >>>>>>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>>>>>> rejected with a >>>>>>>>> 480 response) in deployed networks, so I think it needs to be >>>>>>>>> fixed. >>>>>>>>> People seem to have different opinions on which node is acting >>>>>>>>> wrongly, so I hope we can sort it out :) >>>>>>>> >>>>>>>> This is an interesting problem. I agree that it is unclear exactly >>>>>>>> what ought to happen in this case. (But I don't understand why >>>>>>>> someone thinks a 480 is a good way to resolve it.) >>>>>>> >>>>>>> Whether 480 is the best solution or not is not the issue, in my >>>>>>> opinion. >>>>>>> One could also claim that the UPDATE should be rejected. Etc. >>>>>>> >>>>>>> The issue is that there is a session-timer negotiation "race >>>>>>> condition", and we should forbid that (rejecting the UPDATE could >>>>>>>be >>>>>>> part of such solution). >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> Below is a call flow showing the problem: >>>>>>>>> >>>>>>>>> >>>>>>>>> UA Proxy AS >>>>>>>>> >>>>>>>>> -------------------> >>>>>>>>> INVITE (#1) >>>>>>>>> Supported:timer >>>>>>>>> SE:refresher=3Duac >>>>>>>>> >>>>>>>>> -------------------> >>>>>>>>> INVITE (#2) >>>>>>>>> Supported:timer >>>>>>>>> SE:refresher=3Duac >>>>>>>>> >>>>>>>>> >>>>>>>>> <------------------- >>>>>>>>> 18x (#3) >>>>>>>>> >>>>>>>>> <------------------- >>>>>>>>> 18x (#4) >>>>>>>>> >>>>>>>>> ++++++ early dialog established +++++++ >>>>>>>>> >>>>>>>>> <------------------- >>>>>>>>> UPDATE (#5) >>>>>>>>> Supported:timer >>>>>>>>> SE:refresher=3Duas >>>>>>>>> >>>>>>>>> <------------------- >>>>>>>>> UPDATE (#6) >>>>>>>>> Supported:timer >>>>>>>>> SE:refresher=3Duas >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------> >>>>>>>>> 200 (UPDATE) (#7) >>>>>>>>> >>>>>>>>> -------------------> >>>>>>>>> 200 (UPDATE) (#8) >>>>>>>>> Require:timer >>>>>>>>> SE:refresher=3Duac >>>>>>>>> >>>>>>>>> >>>>>>>>> <------------------- >>>>>>>>> 480 (INVITE) (#9) >>>>>>>>> >>>>>>>>> <------------------- >>>>>>>>> 480 (INVITE (#10) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A few things to note: >>>>>>>>> >>>>>>>>> >>>>>>>>> N1: The 18x does not contain the SE (Session-Expires) header >>>>>>>>>field, >>>>>>>>> because according to section 4 of RFC 4028 the header >>>>>>>>> field is only >>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the >>>>>>>>>UPDATE >>>>>>>>> request >>>>>>>>> (#5) is sent, the initial session timer negotiation >>>>>>>>>is >>>>>>>>> still >>>>>>>>> ongoing. >>>>>>>>> >>>>>>>>> >>>>>>>>> N2: The UPDATE request (#5) contains a Session-Expires header >>>>>>>>> field. >>>>>>>>> Section 7.4 of RFC 4028 says: >>>>>>>>> >>>>>>>>> "In a session refresh request sent within a dialog with an >>>>>>>>> active >>>>>>>>> session timer, the Session-Expires header field SHOULD be >>>>>>>>> present." >>>>>>>>> >>>>>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>>>>> request is >>>>>>>>> sent, but as the initial session timer negotiation is >>>>>>>>> still >>>>>>>>> ongoing, I assume the session timer isn=B9t yet >>>>>>>>>"active"? >>>>>>>>> >>>>>>>>> >>>>>>>>> N3: The UPDATE 200 response (#7) does not contain the >>>>>>>>> Session-Expires >>>>>>>>> header field. It is added by the proxy, based on the >>>>>>>>> procedures in >>>>>>>>> Section 8.2 of RFC 4028: >>>>>>>>> >>>>>>>>> "Because there is no Session-Expires or Require >>>>>>>>> header field >>>>>>>>> in the response, the proxy knows that it is the >>>>>>>>> first >>>>>>>>> session-timer-aware proxy to receive the >>>>>>>>>response. >>>>>>>>> This proxy >>>>>>>>> MUST insert a Session-Expires header field into >>>>>>>>> the >>>>>>>>> response >>>>>>>>> with the value it remembered from the forwarded >>>>>>>>> request. >>>>>>>>> It >>>>>>>>> MUST >>>>>>>>> set the value of The 'refresher' parameter to >>>>>>>>> 'uac'. >>>>>>>>> The proxy MUST >>>>>>>>> add the 'timer' option tag to any Require >>>>>>>>>header >>>>>>>>> field in the >>>>>>>>> response, and if none was present, add the >>>>>>>>>Require >>>>>>>>> header field with >>>>>>>>> that value before forwarding it upstream." >>>>>>>>> >>>>>>>>> >>>>>>>>> Now, one could argue that the UA should include something in the >>>>>>>>> UPDATE response (#7), but I think that is not a solution as the >>>>>>>>>UA >>>>>>>>> may be confused. >>>>>>>>> Instead, based on my understanding of the text in section 7.4 >>>>>>>>>(see >>>>>>>>> above) the UPDATE request (#5) should not contain any session >>>>>>>>>timer >>>>>>>>> information. This is also more or less what the errata suggests. >>>>>>>>> >>>>>>>>> Comments? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Christer >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >>=20 > From nobody Sun Oct 8 15:11:54 2017 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 1EFB513486F for ; Sun, 8 Oct 2017 15:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gy09YucDv2e for ; Sun, 8 Oct 2017 15:11:52 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC327133075 for ; Sun, 8 Oct 2017 15:11:51 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id 1JmseC3kL91wb1JnaevwBv; Sun, 08 Oct 2017 22:11:50 +0000 Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-14v.sys.comcast.net with SMTP id 1JnZex0h6CzrX1Jnaejldi; Sun, 08 Oct 2017 22:11:50 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: From: Paul Kyzivat Message-ID: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> Date: Sun, 8 Oct 2017 18:11:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfLRb5ajdZ2oqdpVYlJgBYvmjeIuA7E4ONzUjYazjPvhvaRPPr+Ogc5BCjg1HUoNzMzCZgI+ZHHIYobv8nboG6+YPwgeGWcwRCqEU0tFA9Baoxe7MU63T 99t4aYeo+PIkXrbBnFGDBsHOHN1uGa8cxJAU+3cGB74YXr7w4zdEP3/mNml0NJP5bBiLslocqCyAs34vGQ5YUuvLXVYAnJHzR4mkV6wvgdlszLm0mbt+KQaD Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 22:11:53 -0000 On 10/5/17 4:37 AM, Christer Holmberg wrote: > Hi, > >>> … >>> >>>> I'll propose that the session timer negotiation never be done with an >>>> UPDATE within an INVITE transaction. (Regardless of whether than INVITE >>>> is negotiating a session timer or not.) I think this resolves the >>>> problem that you have encountered. (Or we could require that the UPDATE >>>> and response care consistent session timer signaling with what is >>>> carried in the INVITE and its responses.) >>> >>> I had a chat with some product people, and they said that there actually >>> ARE cases where the session timer is negotiated using UPDATE when the >>> initial INVITE transaction is still ongoing. There are cases where the >>> INVITE only contains Supported:timer, but the actual negotiation is done >>> using UPDATE. >> >> Interesting! (I wonder why.) > > I haven’t been able to figure out exactly why. I was just told the > use-case exists. > > >> That sequence itself presents some ambiguities. The way I have always >> described how the session timer negotiation works is that *every* INVITE >> and UPDATE transaction affects s-t - it either negotiates it *on* or >> else it negotiates it *off*. (IMO this makes it very easy to understand.) >> >> That presents issues when you have an update nested inside of an invite. >> In the case you describe I might expect that the update would negotiate >> the timer on, and then the completion of the invite would negotiate it >> off again. >> >> How would the case you describe work if a proxy inserted S-E in INVITE? >> In that case, the UAC doesn't know about it until the 2xx from the >> invite. Before then it might try enabling a timer using UPDATE. >> >> I am inclined to keep things simple by saying that the 2xx response to >> every INVITE or UPDATE redefines the state of the session timer, either >> on or off. That will of course break the use case you describe above. > > The problem here is that the UAC sends INVITE with S-E, and then receives > an UPDATE with S-E before it has received a 2xx response to the INVITE - > making the UAC think that there is a S-E glare situation (i.e., the UAS > also tries to initiate session timer negotiation). Yes, I understand that is the case you are thinking of. But I was raising a different case: - the UAC sends an invite without a S-E. - a proxy along the path includes an S-E. (The UAC is unaware.) - later, the UAC sends an UPDATE with S-E. That violates the rule in your draft, but the UAC doesn't know it has violated it. So your rule for avoiding the problem in this case doesn't work. Thanks, Paul > I think the RFC is pretty clear on how things work once the session timer > has been negotiated (and, if it isn’t, we for sure can clarify that too). > > Regards, > > Christer > > > > > >>>>> >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>>>> seen from my point of view the UAC should ignore the Session timer >>>>>>>> proposal within the UPDATE. >>>>>>>> As long as the negotiation is ongoing. >>>>>>>> >>>>>>>> Nevertheless we have also observed this curious session timer >>>>>>>> behavior >>>>>>>> in our network. >>>>>>>> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also to >>>>>>>> other >>>>>>>> sections to make it more readable. >>>>>>>> My experience is that people have problems in following how the >>>>>>>> session timer should work within a complex SIP networks (e.g. IMS). >>>>>>>> >>>>>>>> What is about updating the RFC4028. >>>>>>> >>>>>>> Like most of the older SIP RFCs, it probably deserves an update. The >>>>>>> problem is whether going to the trouble will have any effect on >>>>>>> implementations. I think the most we > should hope to do is >>>>>>> *clarify* >>>>>>> in >>>>>>> cases where there is ambiguity, so that when interoperability >>>>>>> problems >>>>>>> arise it is clear who needs to change. >>>>>> >>>>>> Yes. In my case, implementation(s) WILL be changed. The question is >>>>>> WHICH >>>>>> implementation(s) :) >>>>>> >>>>>> So, my suggestion would be: >>>>>> >>>>>> 1) Specify/clarify that SE must not be sent during session-timer >>>>>> negotiation >>>>>> 2) Specify that one must send a 491 (or some other more appropriate >>>>>> code) >>>>>> response if receiving SE during session-timer negotiation >>>>>> >>>>>> For the above, I think we can do it using an errata. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>>>>>> Christer Holmberg >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>>>>>> An: Paul Kyzivat ; sipcore@ietf.org >>>>>>>> Betreff: Re: [sipcore] Session-timer issue >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>>> The following issue has been around for some time already (there >>>>>>>>>> is >>>>>>>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>>>>>>> rejected with a >>>>>>>>>> 480 response) in deployed networks, so I think it needs to be >>>>>>>>>> fixed. >>>>>>>>>> People seem to have different opinions on which node is acting >>>>>>>>>> wrongly, so I hope we can sort it out :) >>>>>>>>> >>>>>>>>> This is an interesting problem. I agree that it is unclear exactly >>>>>>>>> what ought to happen in this case. (But I don't understand why >>>>>>>>> someone thinks a 480 is a good way to resolve it.) >>>>>>>> >>>>>>>> Whether 480 is the best solution or not is not the issue, in my >>>>>>>> opinion. >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. >>>>>>>> >>>>>>>> The issue is that there is a session-timer negotiation "race >>>>>>>> condition", and we should forbid that (rejecting the UPDATE could >>>>>>>> be >>>>>>>> part of such solution). >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> Below is a call flow showing the problem: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> UA Proxy AS >>>>>>>>>> >>>>>>>>>> -------------------> >>>>>>>>>> INVITE (#1) >>>>>>>>>> Supported:timer >>>>>>>>>> SE:refresher=uac >>>>>>>>>> >>>>>>>>>> -------------------> >>>>>>>>>> INVITE (#2) >>>>>>>>>> Supported:timer >>>>>>>>>> SE:refresher=uac >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <------------------- >>>>>>>>>> 18x (#3) >>>>>>>>>> >>>>>>>>>> <------------------- >>>>>>>>>> 18x (#4) >>>>>>>>>> >>>>>>>>>> ++++++ early dialog established +++++++ >>>>>>>>>> >>>>>>>>>> <------------------- >>>>>>>>>> UPDATE (#5) >>>>>>>>>> Supported:timer >>>>>>>>>> SE:refresher=uas >>>>>>>>>> >>>>>>>>>> <------------------- >>>>>>>>>> UPDATE (#6) >>>>>>>>>> Supported:timer >>>>>>>>>> SE:refresher=uas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -------------------> >>>>>>>>>> 200 (UPDATE) (#7) >>>>>>>>>> >>>>>>>>>> -------------------> >>>>>>>>>> 200 (UPDATE) (#8) >>>>>>>>>> Require:timer >>>>>>>>>> SE:refresher=uac >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <------------------- >>>>>>>>>> 480 (INVITE) (#9) >>>>>>>>>> >>>>>>>>>> <------------------- >>>>>>>>>> 480 (INVITE (#10) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A few things to note: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> N1: The 18x does not contain the SE (Session-Expires) header >>>>>>>>>> field, >>>>>>>>>> because according to section 4 of RFC 4028 the header >>>>>>>>>> field is only >>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the >>>>>>>>>> UPDATE >>>>>>>>>> request >>>>>>>>>> (#5) is sent, the initial session timer negotiation >>>>>>>>>> is >>>>>>>>>> still >>>>>>>>>> ongoing. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> N2: The UPDATE request (#5) contains a Session-Expires header >>>>>>>>>> field. >>>>>>>>>> Section 7.4 of RFC 4028 says: >>>>>>>>>> >>>>>>>>>> "In a session refresh request sent within a dialog with an >>>>>>>>>> active >>>>>>>>>> session timer, the Session-Expires header field SHOULD be >>>>>>>>>> present." >>>>>>>>>> >>>>>>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>>>>>> request is >>>>>>>>>> sent, but as the initial session timer negotiation is >>>>>>>>>> still >>>>>>>>>> ongoing, I assume the session timer isnąt yet >>>>>>>>>> "active"? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain the >>>>>>>>>> Session-Expires >>>>>>>>>> header field. It is added by the proxy, based on the >>>>>>>>>> procedures in >>>>>>>>>> Section 8.2 of RFC 4028: >>>>>>>>>> >>>>>>>>>> "Because there is no Session-Expires or Require >>>>>>>>>> header field >>>>>>>>>> in the response, the proxy knows that it is the >>>>>>>>>> first >>>>>>>>>> session-timer-aware proxy to receive the >>>>>>>>>> response. >>>>>>>>>> This proxy >>>>>>>>>> MUST insert a Session-Expires header field into >>>>>>>>>> the >>>>>>>>>> response >>>>>>>>>> with the value it remembered from the forwarded >>>>>>>>>> request. >>>>>>>>>> It >>>>>>>>>> MUST >>>>>>>>>> set the value of The 'refresher' parameter to >>>>>>>>>> 'uac'. >>>>>>>>>> The proxy MUST >>>>>>>>>> add the 'timer' option tag to any Require >>>>>>>>>> header >>>>>>>>>> field in the >>>>>>>>>> response, and if none was present, add the >>>>>>>>>> Require >>>>>>>>>> header field with >>>>>>>>>> that value before forwarding it upstream." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now, one could argue that the UA should include something in the >>>>>>>>>> UPDATE response (#7), but I think that is not a solution as the >>>>>>>>>> UA >>>>>>>>>> may be confused. >>>>>>>>>> Instead, based on my understanding of the text in section 7.4 >>>>>>>>>> (see >>>>>>>>>> above) the UPDATE request (#5) should not contain any session >>>>>>>>>> timer >>>>>>>>>> information. This is also more or less what the errata suggests. >>>>>>>>>> >>>>>>>>>> Comments? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Christer >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> > > From nobody Mon Oct 9 02:34:26 2017 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 4B28E1331D9 for ; Mon, 9 Oct 2017 02:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=FKTK1jwZ; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=CYmA2OiE 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 q3JHiaXoNgC0 for ; Mon, 9 Oct 2017 02:34:20 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 A4865134E5C for ; Mon, 9 Oct 2017 02:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1507541658; x=1539077658; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=YsPIwrgTyAuyu0y6fX6x8uZSgAY4nLVkbAtmY95j15k=; b=FKTK1jwZPZqSH13+Jxl2krwRNNpFEEfPRM27+eAfD26gUkJsxkJw7KSv KZFoXNFDSnQAyarIrmw7GOfnTxldNr290fmziO1/Iyex3YLdoQGzh7C28 k07O/tGMP/qADDxoPVLQCFy2get+gY286Me6YeIrcLgnrbr8ikgPMSBGG bR4Qp3Frn9ZQvzZ3boT9RD6yo5jibhGF/XzIiklte3YixXKJ75Lu8m6p+ vl1VVassAq5QqoM/ayOHAwwmNbMnTahqIHWBCaSdC6vP9NMjp1m28OwSL 1oEy3QO4G538wqd+nGT3UNXTupOiELwq4Mk3y71e8PnKzTvVhCEiXXp57 A==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2017 11:34:16 +0200 X-IronPort-AV: E=Sophos;i="5.42,500,1500933600"; d="scan'208,217";a="745689395" Received: from he105700.emea1.cds.t-internal.com ([10.169.119.29]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 09 Oct 2017 11:34:15 +0200 Received: from HE105661.EMEA1.cds.t-internal.com (10.169.119.57) by HE105700.emea1.cds.t-internal.com (10.169.119.29) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 11:34:15 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105661.EMEA1.cds.t-internal.com (10.169.119.57) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 11:34:15 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.19) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 9 Oct 2017 11:33:43 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YsPIwrgTyAuyu0y6fX6x8uZSgAY4nLVkbAtmY95j15k=; b=CYmA2OiElKPYJsfayd2J3wyU40kQLJ8xMlZNLKQucllUy7LM3a2ggCmFrqQKiKjUIBaaXg3+FskxAKbq5IFI49T3eKKyFG6bFL/zdRjGcZssnO1B+rKdDFLsx5LPB4pBgC6H6V7tc/ba6iUO/F1VRKra1AdZEv8t+ADBEMdRbj0= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0484.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 9 Oct 2017 09:34:13 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Mon, 9 Oct 2017 09:34:13 +0000 From: "Jesske, Roland" To: Paul Kyzivat , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaiXWAgACzC3A= Date: Mon, 9 Oct 2017 09:34:13 +0000 Message-ID: References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> In-Reply-To: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0484; 6:eCscr0EKs1hN+ovE89nYj7webxiJj+U2Vag0BIjvAiXsyN1Bn1/3OvpgtTLI3xnPRu9s/XX24Y9doUnIqrZ/+wnmegyTVcifZajRk6JfCBvSQY8Hf82bk4ctoc+E/JgcIVz+AGaCpix+p1USeYhHoaRy9lmBuI2NEKBsY6tTw8oU2oW7CKsTGe5Tm8BPpyPYJyms/QegWDgXx/u4Lz39GdUDmQ5gwZVWWLp8S5mf2DdP/xeyBiPj562NxzN8JcvmDYqvG7WekzRjqj5qePeQ3osP6hN5f8fsGOGyHv/7IxdToPsZFmI7wjUfn0sWIYE+tyWl7UPuAmvK9VxEGd3DFg==; 5:lQj0nv1bTfV51hnX3uQTamDoVDbPZ5bOQz2f8j1eWIRmExwt0TR37fVVpWFWlL4aXlHg4GIj5cIKvROmr9uIJW0830KpaZeqkYxJhWp+Sk3hZCx13CHfTpO1f1z2tjB7gz4SXi/JOCvh9yMTjWlVOA==; 24:BKap4c+nX42F8WWzIRjTcpDyZKHpl8e3I0riC1Jp6zZjZpRrYs2k0lOEKHgscyoiXqmrAcElxyO66bOtgn0kqZSq08U6BumtRBGOlVMzVxo=; 7:xgv62C2oig5C5AGU/TA8i4NF0cGIup3WScQeqz4YweBn6c+JXwoi08i08ZT/zKo+tCUCumsS44/oj0QEZBzh/VtUhje3mOs69/hOu56iT8FHIEWvZ8rxVJezSkJaD6bIT4fxqUa7sI0hmnPATnc3sAf5GuKScN+Ar+AmQ8SnKAYUYcMD/AyxABDXsTmeBEes0N5MNyBNChjE6EZRNrn0z7g3Q5+T4wETQQKr51yA3Z4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 467a3c79-1b17-4c92-0a9b-08d50ef8e719 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0484; x-ms-traffictypediagnostic: FRAPR01MB0484: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0484; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0484; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(51444003)(24454002)(199003)(377454003)(14454004)(53546010)(97736004)(316002)(76176999)(54356999)(3846002)(74482002)(6116002)(102836003)(110136005)(2906002)(106356001)(966005)(3660700001)(68736007)(8676002)(72206003)(8936002)(3280700002)(305945005)(478600001)(81156014)(50986999)(551934003)(81166006)(2171002)(2501003)(101416001)(9686003)(6306002)(53936002)(66066001)(86362001)(2950100002)(5660300001)(561944003)(7696004)(2900100001)(189998001)(7736002)(105586002)(5250100002)(55016002)(53946003)(33656002)(75402003)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0484; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB04830A7FAA98113B6B5C71A2F9740FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 09:34:13.3243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0484 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 09:34:25 -0000 --_000_FRAPR01MB04830A7FAA98113B6B5C71A2F9740FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, sorry but I have an further issue where we have problems with session timer= . It is the procedures of stateful Proxy Servers where we can cause a race co= ndition. We have made the observation that due to the rules we have race conditions = with using the session timer. The case is where we have transfer of SIP messages through an network that = is not supporting session timer. Originating network and UAC does support session timer. Intermediate network does not support session timer And the terminating network does support session timer. This may result with the following call flow. UAC Proxy Proxy UAS_2 | | | |-- INVITE -->| | | | SE; supp |-- INVITE -->|-- INVITE (2) ->| | | none | SE; supp | | | | | | |<-- 200 (2) ----| |<- 18x (2) --|<- 18x (2) --| SE 1800; | SE 1800; | | UAS | | UAC | | | |-- UPDATE -->| | | | |-- UPDATE -->| <-- UPDATE ----| | | | | | |<- UPDATE ---| --- UPDATE --->| |<- UPDATE ---| | | |-- 491 --->| |<-- 491 ----| | |-- 491 --->| | | |<-- 491 ----|--- 491 --->| |<-- 491 ----| | | This will happen when the session timer has the same length. How do we can solve such race conditions. I see the main problem within the= proxy behavior and the Forwarding of the UPDATE (or re-INVITE) for session refresh. Of course also the choice when the refresher shall sent the refresh may sol= ve the problem. But if the originating and terminating network is using the same software v= endor the refresh time will be the same. So seen from that kind of algorithm is needed to generate different session= refresh times. Do you see the same problems? Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Montag, 9. Oktober 2017 00:12 > An: Christer Holmberg ; sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix > > On 10/5/17 4:37 AM, Christer Holmberg wrote: > > Hi, > > > >>> ... > >>> > >>>> I'll propose that the session timer negotiation never be done with > >>>> an UPDATE within an INVITE transaction. (Regardless of whether than > >>>> INVITE is negotiating a session timer or not.) I think this > >>>> resolves the problem that you have encountered. (Or we could > >>>> require that the UPDATE and response care consistent session timer > >>>> signaling with what is carried in the INVITE and its responses.) > >>> > >>> I had a chat with some product people, and they said that there > >>> actually ARE cases where the session timer is negotiated using > >>> UPDATE when the initial INVITE transaction is still ongoing. There > >>> are cases where the INVITE only contains Supported:timer, but the > >>> actual negotiation is done using UPDATE. > >> > >> Interesting! (I wonder why.) > > > > I haven't been able to figure out exactly why. I was just told the > > use-case exists. > > > > > >> That sequence itself presents some ambiguities. The way I have always > >> described how the session timer negotiation works is that *every* > >> INVITE and UPDATE transaction affects s-t - it either negotiates it > >> *on* or else it negotiates it *off*. (IMO this makes it very easy to > >> understand.) > >> > >> That presents issues when you have an update nested inside of an invit= e. > >> In the case you describe I might expect that the update would > >> negotiate the timer on, and then the completion of the invite would > >> negotiate it off again. > >> > >> How would the case you describe work if a proxy inserted S-E in INVITE= ? > >> In that case, the UAC doesn't know about it until the 2xx from the > >> invite. Before then it might try enabling a timer using UPDATE. > >> > >> I am inclined to keep things simple by saying that the 2xx response > >> to every INVITE or UPDATE redefines the state of the session timer, > >> either on or off. That will of course break the use case you describe > above. > > > > The problem here is that the UAC sends INVITE with S-E, and then > > receives an UPDATE with S-E before it has received a 2xx response to > > the INVITE - making the UAC think that there is a S-E glare situation > > (i.e., the UAS also tries to initiate session timer negotiation). > > Yes, I understand that is the case you are thinking of. But I was raising= a > different case: > > - the UAC sends an invite without a S-E. > - a proxy along the path includes an S-E. (The UAC is unaware.) > - later, the UAC sends an UPDATE with S-E. > > That violates the rule in your draft, but the UAC doesn't know it has vio= lated > it. So your rule for avoiding the problem in this case doesn't work. > > Thanks, > Paul > > > I think the RFC is pretty clear on how things work once the session > > timer has been negotiated (and, if it isn't, we for sure can clarify th= at too). > > > > Regards, > > > > Christer > > > > > > > > > > > >>>>> > >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > >>>>> >>>>> mailto:christer.holmberg@ericsson.com> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>>>> seen from my point of view the UAC should ignore the Session > >>>>>>>> timer proposal within the UPDATE. > >>>>>>>> As long as the negotiation is ongoing. > >>>>>>>> > >>>>>>>> Nevertheless we have also observed this curious session timer > >>>>>>>> behavior in our network. > >>>>>>>> > >>>>>>>> I think we need some clarifications to the RFC. Perhaps also to > >>>>>>>> other sections to make it more readable. > >>>>>>>> My experience is that people have problems in following how the > >>>>>>>> session timer should work within a complex SIP networks (e.g. > IMS). > >>>>>>>> > >>>>>>>> What is about updating the RFC4028. > >>>>>>> > >>>>>>> Like most of the older SIP RFCs, it probably deserves an update. > >>>>>>> The problem is whether going to the trouble will have any effect > >>>>>>> on implementations. I think the most we > should hope to do is > >>>>>>> *clarify* > >>>>>>> in > >>>>>>> cases where there is ambiguity, so that when interoperability > >>>>>>> problems arise it is clear who needs to change. > >>>>>> > >>>>>> Yes. In my case, implementation(s) WILL be changed. The question > >>>>>> is WHICH > >>>>>> implementation(s) :) > >>>>>> > >>>>>> So, my suggestion would be: > >>>>>> > >>>>>> 1) Specify/clarify that SE must not be sent during session-tim= er > >>>>>> negotiation > >>>>>> 2) Specify that one must send a 491 (or some other more > appropriate > >>>>>> code) > >>>>>> response if receiving SE during session-timer negotiation > >>>>>> > >>>>>> For the above, I think we can do it using an errata. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Christer > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von > >>>>>>>> Christer Holmberg > >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 > >>>>>>>> An: Paul Kyzivat ; mailto:sipcore@= ietf.org > >>>>>>>> Betreff: Re: [sipcore] Session-timer issue > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>>>> The following issue has been around for some time already > >>>>>>>>>> (there is also an errata #4744), and as it causes problems > >>>>>>>>>> (the INVITE is rejected with a > >>>>>>>>>> 480 response) in deployed networks, so I think it needs to be > >>>>>>>>>> fixed. > >>>>>>>>>> People seem to have different opinions on which node is > >>>>>>>>>> acting wrongly, so I hope we can sort it out :) > >>>>>>>>> > >>>>>>>>> This is an interesting problem. I agree that it is unclear > >>>>>>>>> exactly what ought to happen in this case. (But I don't > >>>>>>>>> understand why someone thinks a 480 is a good way to resolve > >>>>>>>>> it.) > >>>>>>>> > >>>>>>>> Whether 480 is the best solution or not is not the issue, in my > >>>>>>>> opinion. > >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. > >>>>>>>> > >>>>>>>> The issue is that there is a session-timer negotiation "race > >>>>>>>> condition", and we should forbid that (rejecting the UPDATE > >>>>>>>> could be part of such solution). > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Christer > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>>> Below is a call flow showing the problem: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> UA Proxy AS > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> INVITE (#1) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> INVITE (#2) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 18x (#3) > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 18x (#4) > >>>>>>>>>> > >>>>>>>>>> ++++++ early dialog established +++++++ > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> UPDATE (#5) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duas > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> UPDATE (#6) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duas > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> 200 (UPDATE) (#7) > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> 200 (UPDATE) (#8) > >>>>>>>>>> Require:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 480 (INVITE) (#9) > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 480 (INVITE (#10) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> A few things to note: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N1: The 18x does not contain the SE (Session-Expires) > header > >>>>>>>>>> field, > >>>>>>>>>> because according to section 4 of RFC 4028 the > >>>>>>>>>> header field is only > >>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the > >>>>>>>>>> UPDATE request > >>>>>>>>>> (#5) is sent, the initial session timer > >>>>>>>>>> negotiation is still > >>>>>>>>>> ongoing. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N2: The UPDATE request (#5) contains a Session-Expires > header > >>>>>>>>>> field. > >>>>>>>>>> Section 7.4 of RFC 4028 says: > >>>>>>>>>> > >>>>>>>>>> "In a session refresh request sent within a dialog wit= h > >>>>>>>>>> an active > >>>>>>>>>> session timer, the Session-Expires header field SHOUL= D > >>>>>>>>>> be present." > >>>>>>>>>> > >>>>>>>>>> Now, a dialog (early) HAS been established when the UPDATE > >>>>>>>> request is > >>>>>>>>>> sent, but as the initial session timer > >>>>>>>>>> negotiation is still > >>>>>>>>>> ongoing, I assume the session timer isn=B9t yet > >>>>>>>>>> "active"? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain the > >>>>>>>>>> Session-Expires > >>>>>>>>>> header field. It is added by the proxy, based on > >>>>>>>>>> the procedures in > >>>>>>>>>> Section 8.2 of RFC 4028: > >>>>>>>>>> > >>>>>>>>>> "Because there is no Session-Expires or > >>>>>>>>>> Require header field > >>>>>>>>>> in the response, the proxy knows that it > >>>>>>>>>> is the first > >>>>>>>>>> session-timer-aware proxy to receive the > >>>>>>>>>> response. > >>>>>>>>>> This proxy > >>>>>>>>>> MUST insert a Session-Expires header field > >>>>>>>>>> into the response > >>>>>>>>>> with the value it remembered from the > >>>>>>>>>> forwarded request. > >>>>>>>>>> It > >>>>>>>>>> MUST > >>>>>>>>>> set the value of The 'refresher' parameter > >>>>>>>>>> to 'uac'. > >>>>>>>>>> The proxy MUST > >>>>>>>>>> add the 'timer' option tag to any Require > >>>>>>>>>> header field in the > >>>>>>>>>> response, and if none was present, add the > >>>>>>>>>> Require header field with > >>>>>>>>>> that value before forwarding it upstream." > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Now, one could argue that the UA should include something in > >>>>>>>>>> the UPDATE response (#7), but I think that is not a solution > >>>>>>>>>> as the UA may be confused. > >>>>>>>>>> Instead, based on my understanding of the text in section 7.4 > >>>>>>>>>> (see > >>>>>>>>>> above) the UPDATE request (#5) should not contain any > session > >>>>>>>>>> timer information. This is also more or less what the errata > >>>>>>>>>> suggests. > >>>>>>>>>> > >>>>>>>>>> Comments? > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Christer > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> sipcore mailing list > >>>>>>>>>> mailto:sipcore@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> sipcore mailing list > >>>>>>>>> mailto:sipcore@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> sipcore mailing list > >>>>>>>> mailto:sipcore@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sipcore mailing list > >>>>>> mailto:sipcore@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> mailto:sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> mailto:sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > >> > > > > > > _______________________________________________ > sipcore mailing list > mailto:sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_FRAPR01MB04830A7FAA98113B6B5C71A2F9740FRAPR01MB0483DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
sorry but I have an further issue where we have problems with session = timer.
It is the procedures of stateful Proxy Servers where we can cause a ra= ce condition.
 
We have made the observation that due to the rules we have race condit= ions with using the session timer.
 
The case is where we have transfer of SIP messages through an network = that is not supporting session timer.
 
Originating network and UAC does support session timer.
Intermediate network does not support session timer
And the terminating network does support session timer.
 
This may result with the following call flow.
 
UAC           Proxy&= nbsp;          Proxy  &nb= sp;      UAS_2  
   |         &n= bsp;             &nb= sp;   |         &nbs= p;      |       &nbs= p;       
   |-- INVITE -->|      &nb= sp;      |      &nbs= p;         |    = ; 
   |    SE; supp |-- INVITE -->|-- INVITE = (2) ->|      
   |         &n= bsp;   |    none     | &n= bsp;  SE; supp   
   |         &n= bsp;   |         &nb= sp;   |         &nbs= p;      |
   |         &n= bsp;   |         &nb= sp;   |<-- 200 (2) ----|       <= /div>
   |<- 18x (2) --|<- 18x (2) --|    SE = 1800;
   |   SE 1800;  |     &n= bsp;       |      UAS&nbs= p;      |   
   |     UAC     |&n= bsp;            |&nb= sp;            =    |      
   |-- UPDATE -->|      &nb= sp;      |      &nbs= p;         |    = ; 
   |          &= nbsp; |-- UPDATE -->| <-- UPDATE ----|     =    
   |         &n= bsp;   |         &nb= sp;   |         &nbs= p;      |
  |           = |<- UPDATE ---| --- UPDATE --->|
   |<- UPDATE ---|      &nb= sp;      |      &nbs= p;         |    = ;  
   |-- 491   --->|     &nbs= p;       |<-- 491     ----|=             &nb= sp;
   |         &n= bsp;   |-- 491   --->|      = ;          |
   |         &n= bsp;   |<-- 491 ----|--- 491   --->|
   |<-- 491 ----|      &nb= sp;      |      &nbs= p;         |
 
 
 
This will happen when the session timer has the same length.
How do we can solve such race conditions. I see the main problem withi= n the proxy behavior and the
Forwarding of the UPDATE (or re-INVITE) for session refresh.
 
Of course also the choice when the refresher shall sent the refresh ma= y solve the problem.
But if the originating and terminating network is using the same softw= are vendor the refresh time will be the same.
So seen from that kind of algorithm is needed to generate different se= ssion refresh times.
 
Do you see the same problems?
 
Thank you and Best Regards
 
Roland
 
 
 
 
 
 
        
 
> -----Urspr=FCngliche Nachricht-----=
> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Ky= zivat
> Gesendet: Montag, 9. Oktober 2017 00:12
> An: Christer Holmberg <christer.holmber= g@ericsson.com>; sipcore@ietf.org
> Betreff: Re: [sipcore] Session timer fix
>
> On 10/5/17 4:37 AM, Christer Holmberg wrot= e:
> > Hi,
> >
> >>> …
> >>>
> >>>> I'll propose that the ses= sion timer negotiation never be done with
> >>>> an UPDATE within an INVIT= E transaction. (Regardless of whether than
> >>>> INVITE is negotiating a s= ession timer or not.) I think this
> >>>> resolves the problem that= you have encountered. (Or we could
> >>>> require that the UPDATE a= nd response care consistent session timer
> >>>> signaling with what is ca= rried in the INVITE and its responses.)
> >>>
> >>> I had a chat with some produc= t people, and they said that there
> >>> actually ARE cases where the = session timer is negotiated using
> >>> UPDATE when the initial INVIT= E transaction is still ongoing. There
> >>> are cases where the INVITE on= ly contains Supported:timer, but the
> >>> actual negotiation is done us= ing UPDATE.
> >>
> >> Interesting! (I wonder why.)
> >
> > I haven’t been able to figure o= ut exactly why. I was just told the
> > use-case exists.
> >
> >
> >> That sequence itself presents som= e ambiguities. The way I have always
> >> described how the session timer n= egotiation works is that *every*
> >> INVITE and UPDATE transaction aff= ects s-t - it either negotiates it
> >> *on* or else it negotiates it *of= f*. (IMO this makes it very easy to
> >> understand.)
> >>
> >> That presents issues when you hav= e an update nested inside of an invite.
> >> In the case you describe I might = expect that the update would
> >> negotiate the timer on, and then = the completion of the invite would
> >> negotiate it off again.
> >>
> >> How would the case you describe w= ork if a proxy inserted S-E in INVITE?
> >> In that case, the UAC doesn't kno= w about it until the 2xx from the
> >> invite. Before then it might try = enabling a timer using UPDATE.
> >>
> >> I am inclined to keep things simp= le by saying that the 2xx response
> >> to every INVITE or UPDATE redefin= es the state of the session timer,
> >> either on or off. That will of co= urse break the use case you describe
> above.
> >
> > The problem here is that the UAC send= s INVITE with S-E, and then
> > receives an UPDATE with S-E before it= has received a 2xx response to
> > the INVITE - making the UAC think tha= t there is a S-E glare situation
> > (i.e., the UAS also tries to initiate= session timer negotiation).
>
> Yes, I understand that is the case you are= thinking of. But I was raising a
> different case:
>
> - the UAC sends an invite without a S-E.
> - a proxy along the path includes an S-E. = (The UAC is unaware.)
> - later, the UAC sends an UPDATE with S-E.=
>
> That violates the rule in your draft, but = the UAC doesn't know it has violated
> it. So your rule for avoiding the problem = in this case doesn't work.
>
>        = Thanks,
>        = Paul
>
> > I think the RFC is pretty clear on ho= w things work once the session
> > timer has been negotiated (and, if it= isn’t, we for sure can clarify that too).
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >>>>>
> >>>>> On 07/09/17 19:38, &q= uot;sipcore on behalf of Christer Holmberg"
> >>>>> <sipcore-bounces@i= etf.org on behalf of
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>>> seen from= my point of view the UAC should ignore the Session
> >>>>>>>> timer pro= posal within the UPDATE.
> >>>>>>>> As long a= s the negotiation is  ongoing.
> >>>>>>>>
> >>>>>>>> Neverthel= ess we have also observed this curious session timer
> >>>>>>>> behavior = in our network.
> >>>>>>>>
> >>>>>>>> I think w= e need some clarifications to the RFC. Perhaps also to
> >>>>>>>> other sec= tions to make it more readable.
> >>>>>>>> My experi= ence is that people have problems in following how the
> >>>>>>>> session t= imer should work within a complex SIP networks (e.g.
> IMS).
> >>>>>>>>
> >>>>>>>> What is a= bout updating the RFC4028.
> >>>>>>>
> >>>>>>> Like most of = the older SIP RFCs, it probably deserves an update.
> >>>>>>> The problem i= s whether going to the trouble will have any effect
> >>>>>>> on implementa= tions. I think the most we > should hope to do is
> >>>>>>> *clarify*
> >>>>>>> in
> >>>>>>> cases where t= here is ambiguity, so that when interoperability
> >>>>>>> problems aris= e it is clear who needs to change.
> >>>>>>
> >>>>>> Yes. In my case, = implementation(s) WILL be changed. The question
> >>>>>> is WHICH
> >>>>>> implementation(s)= :)
> >>>>>>
> >>>>>> So, my suggestion= would be:
> >>>>>>
> >>>>>> 1)  &nb= sp;  Specify/clarify that SE must not be sent during session-timer
> >>>>>> negotiation
> >>>>>> 2)  &nb= sp;  Specify that one must send a 491 (or some other more
> appropriate
> >>>>>> code)
> >>>>>> response if recei= ving SE during session-timer negotiation
> >>>>>>
> >>>>>> For the above, I = think we can do it using an errata.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Christer
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> -----Ursp= r=FCngliche Nachricht-----
> >>>>>>>> Von: sipc= ore [mailto:sipcore-bounces@iet= f.org] Im Auftrag von
> >>>>>>>> Christer = Holmberg
> >>>>>>>> Gesendet:= Donnerstag, 7. September 2017 11:34
> >>>>>>>> An: Paul = Kyzivat <mailto:pkyzivat@alum.m= it.edu>; mailto:sipcore@ietf.org
> >>>>>>>> Betreff: = Re: [sipcore] Session-timer issue
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>>>> T= he following issue has been around for some time already
> >>>>>>>>>> (= there is also  an errata #4744), and as it causes problems
> >>>>>>>>>> (= the INVITE is rejected with a
> >>>>>>>>>> 4= 80 response) in deployed networks, so I think it needs to be
> >>>>>>>>>> f= ixed.
> >>>>>>>>>> P= eople seem to have different opinions on which node is
> >>>>>>>>>> a= cting wrongly, so  I hope we can sort it out :)
> >>>>>>>>>
> >>>>>>>>> This = is an interesting problem. I agree that it is unclear
> >>>>>>>>> exact= ly what ought to happen in this case. (But I don't
> >>>>>>>>> under= stand why someone thinks a 480 is a good way to resolve
> >>>>>>>>> it.)<= /font>
> >>>>>>>>
> >>>>>>>> Whether 4= 80 is the best solution or not is not the issue, in my
> >>>>>>>> opinion.<= /font>
> >>>>>>>> One could= also claim that the UPDATE should be rejected. Etc.
> >>>>>>>>
> >>>>>>>> The issue= is that there is a session-timer negotiation "race
> >>>>>>>> condition= ", and we should forbid that (rejecting the UPDATE
> >>>>>>>> could be = part of such solution).
> >>>>>>>>
> >>>>>>>> Regards,<= /font>
> >>>>>>>>
> >>>>>>>> Christer<= /font>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> =      Thanks,
> >>>>>>>>> =      Paul
> >>>>>>>>>
> >>>>>>>>>> B= elow is a call flow showing the problem:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> U= A            &n= bsp;   Proxy         = ;       AS
> >>>>>>>>>>
> >>>>>>>>>> -= ------------------>
> >>>>>>>>>> I= NVITE (#1)
> >>>>>>>>>> S= upported:timer
> >>>>>>>>>> S= E:refresher=3Duac
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             -= ------------------>
> >>>>>>>>>>&n= bsp;            = ;             I= NVITE (#2)
> >>>>>>>>>>&n= bsp;            = ;             S= upported:timer
> >>>>>>>>>>&n= bsp;            = ;             S= E:refresher=3Duac
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             &= lt;-------------------
> >>>>>>>>>>&n= bsp;            = ;             1= 8x (#3)
> >>>>>>>>>>
> >>>>>>>>>> &= lt;-------------------
> >>>>>>>>>> 1= 8x (#4)
> >>>>>>>>>>
> >>>>>>>>>> &= #43;+++++ early dialog established ++++= +++
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             &= lt;-------------------
> >>>>>>>>>>&n= bsp;            = ;             U= PDATE (#5)
> >>>>>>>>>>&n= bsp;            = ;             S= upported:timer
> >>>>>>>>>>&n= bsp;            = ;             S= E:refresher=3Duas
> >>>>>>>>>>
> >>>>>>>>>> &= lt;-------------------
> >>>>>>>>>> U= PDATE (#6)
> >>>>>>>>>> S= upported:timer
> >>>>>>>>>> S= E:refresher=3Duas
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -= ------------------>
> >>>>>>>>>> 2= 00 (UPDATE) (#7)
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             -= ------------------>
> >>>>>>>>>>&n= bsp;            = ;             2= 00 (UPDATE) (#8)
> >>>>>>>>>>&n= bsp;            = ;             R= equire:timer
> >>>>>>>>>>&n= bsp;            = ;             S= E:refresher=3Duac
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             &= lt;-------------------
> >>>>>>>>>>&n= bsp;            = ;             4= 80 (INVITE) (#9)
> >>>>>>>>>>
> >>>>>>>>>> &= lt;-------------------
> >>>>>>>>>> 4= 80 (INVITE (#10)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> A= few things to note:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N= 1:        The 18x does not contain the S= E (Session-Expires)
> header
> >>>>>>>>>> f= ield,
> >>>>>>>>>>&n= bsp;            = ; because according to section 4 of RFC 4028 the
> >>>>>>>>>> h= eader field is only
> >>>>>>>>>>&n= bsp;            = ; allowed in INVITE, UPDATE and 2xx. So, when the
> >>>>>>>>>> U= PDATE request
> >>>>>>>>>>&n= bsp;            = ; (#5) is sent, the initial session timer
> >>>>>>>>>> n= egotiation is still
> >>>>>>>>>>&n= bsp;            = ; ongoing.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N= 2:        The UPDATE request (#5) contai= ns a Session-Expires
> header
> >>>>>>>>>> f= ield.
> >>>>>>>>>>&n= bsp;            = ; Section 7.4 of RFC 4028 says:
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;         "In a session ref= resh request sent within a dialog with
> >>>>>>>>>> a= n active
> >>>>>>>>>>&n= bsp;          session timer, t= he Session-Expires header field SHOULD
> >>>>>>>>>> b= e present."
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;    Now, a dialog (early) HAS been established when the = UPDATE
> >>>>>>>> request i= s
> >>>>>>>>>>&n= bsp;            = ; sent, but as the initial session timer
> >>>>>>>>>> n= egotiation is still
> >>>>>>>>>>&n= bsp;            = ; ongoing, I assume the session timer isn=B9t yet
> >>>>>>>>>> &= quot;active"?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N= 3:        The UPDATE 200 response (#7) d= oes not contain the
> >>>>>>>>>> S= ession-Expires
> >>>>>>>>>>&n= bsp;            = ; header field. It is added by the proxy, based on
> >>>>>>>>>> t= he procedures in
> >>>>>>>>>>&n= bsp;            = ; Section 8.2 of RFC 4028:
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;      "Because there is no Session-Expires o= r
> >>>>>>>>>> R= equire header field
> >>>>>>>>>>&n= bsp;            = ;       in the response, the proxy knows that= it
> >>>>>>>>>> i= s the first
> >>>>>>>>>>&n= bsp;            = ;       session-timer-aware proxy to receive = the
> >>>>>>>>>> r= esponse.
> >>>>>>>>>> T= his  proxy
> >>>>>>>>>>&n= bsp;            = ;       MUST insert a Session-Expires header = field
> >>>>>>>>>> i= nto the response
> >>>>>>>>>>&n= bsp;            = ;       with the value it remembered from the=
> >>>>>>>>>> f= orwarded request.
> >>>>>>>>>> I= t
> >>>>>>>>>> M= UST
> >>>>>>>>>>&n= bsp;            = ;       set the value of The 'refresher' para= meter
> >>>>>>>>>> t= o 'uac'.
> >>>>>>>>>> T= he  proxy MUST
> >>>>>>>>>>&n= bsp;            = ;       add the 'timer' option tag to any Req= uire
> >>>>>>>>>> h= eader field in  the
> >>>>>>>>>>&n= bsp;            = ;       response, and if none was present, ad= d the
> >>>>>>>>>> R= equire header  field with
> >>>>>>>>>>&n= bsp;            = ;       that value before forwarding it upstr= eam."
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N= ow, one could argue that the UA should include something in
> >>>>>>>>>> t= he UPDATE response (#7), but I think that is not a solution
> >>>>>>>>>> a= s the UA may be confused.
> >>>>>>>>>> I= nstead, based on my understanding of the text in section 7.4
> >>>>>>>>>> (= see
> >>>>>>>>>> a= bove) the UPDATE request (#5) should not contain any
> session
> >>>>>>>>>> t= imer information. This is also more or less what the errata
> >>>>>>>>>> s= uggests.
> >>>>>>>>>>
> >>>>>>>>>> C= omments?
> >>>>>>>>>>
> >>>>>>>>>> R= egards,
> >>>>>>>>>>
> >>>>>>>>>> C= hrister
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _= ______________________________________________
> >>>>>>>>>> s= ipcore mailing list
> >>>>>>>>>> <= a href=3D"mailto:sipcore@ietf.org">mailto:sipcore@ietf.org
> >>>>>>>>>> <= a href=3D"https://www.ietf.org/mailman/listinfo/sipcore"> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _____= __________________________________________
> >>>>>>>>> sipco= re mailing list
> >>>>>>>>
> >>>>>>>> _________= ______________________________________
> >>>>>>>> sipcore m= ailing list
> >>>>>>>
> >>>>>>
> >>>>>> _________________= ______________________________
> >>>>>> sipcore mailing l= ist
> >>>>>
> >>>>> _____________________= __________________________
> >>>>> sipcore mailing list<= /font>
> >>>>>
> >>>>
> >>>> _________________________= ______________________
> >>>> sipcore mailing list
> >>>
> >>>
> >>
> >
> >
>
> __________________________________________= _____
> sipcore mailing list
 
 --_000_FRAPR01MB04830A7FAA98113B6B5C71A2F9740FRAPR01MB0483DEUP_-- From nobody Mon Oct 9 03:31:20 2017 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 C594413336A for ; Mon, 9 Oct 2017 03:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIQl65yGVrOQ for ; Mon, 9 Oct 2017 03:31:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 970901344B0 for ; Mon, 9 Oct 2017 03:31:14 -0700 (PDT) X-AuditID: c1b4fb30-a2f809c0000033c8-4c-59db4ff0ee9e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4F.FB.13256.0FF4BD95; Mon, 9 Oct 2017 12:31:12 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 12:31:05 +0200 From: Christer Holmberg To: "Jesske, Roland" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: AW: [sipcore] Session timer fix Thread-Index: AQHTQOm2oSMfVjmoRUiXQCsnsdtf3g== Date: Mon, 9 Oct 2017 10:31:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D6012B9E2382Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7ru4H/9uRBk1/dS1WbDjAatF0p4vN 4uuPTWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6MbWtfsRR872Kp2LvwF1MD 4+2TzF2MnBwSAiYSE2ddZ+1i5OIQEjjCKHHl/DdmCGcho8TjqS+BMhwcbAIWEt3/tEEaRAQq JY7/n8QGYgsL6Ejs/HqcBSKuK/Go5Q0TSLmIgJ5E72URkDCLgIrEjVfTwEp4Bawl7s7tZASx GQXEJL6fWsMEYjMLiEvcejKfCeIeAYkle85D3SYq8fLxP1YQWxRo5IYTt9kh4ooS7U8bGCF6 EyTOPexhhJgvKHFy5hOWCYxCs5CMnYWkbBaSMoi4gcSRczdZIWxtiWULXzND2PoS8xZsgKqx lvj2YhkTspoFjByrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQJj6uCW3wY7GF8+dzzEKMDB qMTDu8TydqQQa2JZcWXuIUYJDmYlEd5l5kAh3pTEyqrUovz4otKc1OJDjNIcLErivI77LkQI CaQnlqRmp6YWpBbBZJk4OKUaGDmOX52x9sadC545E+fJ1nXOP1cmyXhr8bN3l5seXJerueyV PGvm7dnFWVx2bZIRv2q3pLz8/6+2P+tskAjTi3cxhxemaN3365O4+679sZC8tojP6UCeoB1H FbOFO+zD55YlG3EVCj95I7v/ysFtTFzGt7ZnlbWzikkmZ7poTzO9JrN1ue75WCWW4oxEQy3m ouJEAE2l61ClAgAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 10:31:20 -0000 --_000_D6012B9E2382Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable Hi Roland, Since the originating Proxy is anyway going to forward the Session-Timer UP= DATE requests, why does it remove =93SE; supp=94? Regards, Christer From: "R.Jesske@telekom.de" > Date: Monday 9 October 2017 at 12:34 To: "pkyzivat@alum.mit.edu" >, Christer Holmberg >, "sipcore@ietf.org" > Subject: AW: [sipcore] Session timer fix Hi, sorry but I have an further issue where we have problems with session timer= . It is the procedures of stateful Proxy Servers where we can cause a race co= ndition. We have made the observation that due to the rules we have race conditions = with using the session timer. The case is where we have transfer of SIP messages through an network that = is not supporting session timer. Originating network and UAC does support session timer. Intermediate network does not support session timer And the terminating network does support session timer. This may result with the following call flow. UAC Proxy Proxy UAS_2 | | | |-- INVITE -->| | | | SE; supp |-- INVITE -->|-- INVITE (2) ->| | | none | SE; supp | | | | | | |<-- 200 (2) ----| |<- 18x (2) --|<- 18x (2) --| SE 1800; | SE 1800; | | UAS | | UAC | | | |-- UPDATE -->| | | | |-- UPDATE -->| <-- UPDATE ----| | | | | | |<- UPDATE ---| --- UPDATE --->| |<- UPDATE ---| | | |-- 491 --->| |<-- 491 ----| | |-- 491 --->| | | |<-- 491 ----|--- 491 --->| |<-- 491 ----| | | This will happen when the session timer has the same length. How do we can solve such race conditions. I see the main problem within the= proxy behavior and the Forwarding of the UPDATE (or re-INVITE) for session refresh. Of course also the choice when the refresher shall sent the refresh may sol= ve the problem. But if the originating and terminating network is using the same software v= endor the refresh time will be the same. So seen from that kind of algorithm is needed to generate different session= refresh times. Do you see the same problems? Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Montag, 9. Oktober 2017 00:12 > An: Christer Holmberg >; sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix > > On 10/5/17 4:37 AM, Christer Holmberg wrote: > > Hi, > > > >>> =85 > >>> > >>>> I'll propose that the session timer negotiation never be done with > >>>> an UPDATE within an INVITE transaction. (Regardless of whether than > >>>> INVITE is negotiating a session timer or not.) I think this > >>>> resolves the problem that you have encountered. (Or we could > >>>> require that the UPDATE and response care consistent session timer > >>>> signaling with what is carried in the INVITE and its responses.) > >>> > >>> I had a chat with some product people, and they said that there > >>> actually ARE cases where the session timer is negotiated using > >>> UPDATE when the initial INVITE transaction is still ongoing. There > >>> are cases where the INVITE only contains Supported:timer, but the > >>> actual negotiation is done using UPDATE. > >> > >> Interesting! (I wonder why.) > > > > I haven=92t been able to figure out exactly why. I was just told the > > use-case exists. > > > > > >> That sequence itself presents some ambiguities. The way I have always > >> described how the session timer negotiation works is that *every* > >> INVITE and UPDATE transaction affects s-t - it either negotiates it > >> *on* or else it negotiates it *off*. (IMO this makes it very easy to > >> understand.) > >> > >> That presents issues when you have an update nested inside of an invit= e. > >> In the case you describe I might expect that the update would > >> negotiate the timer on, and then the completion of the invite would > >> negotiate it off again. > >> > >> How would the case you describe work if a proxy inserted S-E in INVITE= ? > >> In that case, the UAC doesn't know about it until the 2xx from the > >> invite. Before then it might try enabling a timer using UPDATE. > >> > >> I am inclined to keep things simple by saying that the 2xx response > >> to every INVITE or UPDATE redefines the state of the session timer, > >> either on or off. That will of course break the use case you describe > above. > > > > The problem here is that the UAC sends INVITE with S-E, and then > > receives an UPDATE with S-E before it has received a 2xx response to > > the INVITE - making the UAC think that there is a S-E glare situation > > (i.e., the UAS also tries to initiate session timer negotiation). > > Yes, I understand that is the case you are thinking of. But I was raising= a > different case: > > - the UAC sends an invite without a S-E. > - a proxy along the path includes an S-E. (The UAC is unaware.) > - later, the UAC sends an UPDATE with S-E. > > That violates the rule in your draft, but the UAC doesn't know it has vio= lated > it. So your rule for avoiding the problem in this case doesn't work. > > Thanks, > Paul > > > I think the RFC is pretty clear on how things work once the session > > timer has been negotiated (and, if it isn=92t, we for sure can clarify = that too). > > > > Regards, > > > > Christer > > > > > > > > > > > >>>>> > >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > >>>>> on behal= f of > >>>>> mailto:christer.holmberg@ericsson.com> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>>>> seen from my point of view the UAC should ignore the Session > >>>>>>>> timer proposal within the UPDATE. > >>>>>>>> As long as the negotiation is ongoing. > >>>>>>>> > >>>>>>>> Nevertheless we have also observed this curious session timer > >>>>>>>> behavior in our network. > >>>>>>>> > >>>>>>>> I think we need some clarifications to the RFC. Perhaps also to > >>>>>>>> other sections to make it more readable. > >>>>>>>> My experience is that people have problems in following how the > >>>>>>>> session timer should work within a complex SIP networks (e.g. > IMS). > >>>>>>>> > >>>>>>>> What is about updating the RFC4028. > >>>>>>> > >>>>>>> Like most of the older SIP RFCs, it probably deserves an update. > >>>>>>> The problem is whether going to the trouble will have any effect > >>>>>>> on implementations. I think the most we > should hope to do is > >>>>>>> *clarify* > >>>>>>> in > >>>>>>> cases where there is ambiguity, so that when interoperability > >>>>>>> problems arise it is clear who needs to change. > >>>>>> > >>>>>> Yes. In my case, implementation(s) WILL be changed. The question > >>>>>> is WHICH > >>>>>> implementation(s) :) > >>>>>> > >>>>>> So, my suggestion would be: > >>>>>> > >>>>>> 1) Specify/clarify that SE must not be sent during session-tim= er > >>>>>> negotiation > >>>>>> 2) Specify that one must send a 491 (or some other more > appropriate > >>>>>> code) > >>>>>> response if receiving SE during session-timer negotiation > >>>>>> > >>>>>> For the above, I think we can do it using an errata. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Christer > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von > >>>>>>>> Christer Holmberg > >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 > >>>>>>>> An: Paul Kyzivat ; mailto:sipcore@= ietf.org > >>>>>>>> Betreff: Re: [sipcore] Session-timer issue > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>>>> The following issue has been around for some time already > >>>>>>>>>> (there is also an errata #4744), and as it causes problems > >>>>>>>>>> (the INVITE is rejected with a > >>>>>>>>>> 480 response) in deployed networks, so I think it needs to be > >>>>>>>>>> fixed. > >>>>>>>>>> People seem to have different opinions on which node is > >>>>>>>>>> acting wrongly, so I hope we can sort it out :) > >>>>>>>>> > >>>>>>>>> This is an interesting problem. I agree that it is unclear > >>>>>>>>> exactly what ought to happen in this case. (But I don't > >>>>>>>>> understand why someone thinks a 480 is a good way to resolve > >>>>>>>>> it.) > >>>>>>>> > >>>>>>>> Whether 480 is the best solution or not is not the issue, in my > >>>>>>>> opinion. > >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. > >>>>>>>> > >>>>>>>> The issue is that there is a session-timer negotiation "race > >>>>>>>> condition", and we should forbid that (rejecting the UPDATE > >>>>>>>> could be part of such solution). > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Christer > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>>> Below is a call flow showing the problem: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> UA Proxy AS > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> INVITE (#1) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> INVITE (#2) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 18x (#3) > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 18x (#4) > >>>>>>>>>> > >>>>>>>>>> ++++++ early dialog established +++++++ > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> UPDATE (#5) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duas > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> UPDATE (#6) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duas > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> 200 (UPDATE) (#7) > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> 200 (UPDATE) (#8) > >>>>>>>>>> Require:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 480 (INVITE) (#9) > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 480 (INVITE (#10) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> A few things to note: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N1: The 18x does not contain the SE (Session-Expires) > header > >>>>>>>>>> field, > >>>>>>>>>> because according to section 4 of RFC 4028 the > >>>>>>>>>> header field is only > >>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the > >>>>>>>>>> UPDATE request > >>>>>>>>>> (#5) is sent, the initial session timer > >>>>>>>>>> negotiation is still > >>>>>>>>>> ongoing. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N2: The UPDATE request (#5) contains a Session-Expires > header > >>>>>>>>>> field. > >>>>>>>>>> Section 7.4 of RFC 4028 says: > >>>>>>>>>> > >>>>>>>>>> "In a session refresh request sent within a dialog wi= th > >>>>>>>>>> an active > >>>>>>>>>> session timer, the Session-Expires header field SHOU= LD > >>>>>>>>>> be present." > >>>>>>>>>> > >>>>>>>>>> Now, a dialog (early) HAS been established when the UPDATE > >>>>>>>> request is > >>>>>>>>>> sent, but as the initial session timer > >>>>>>>>>> negotiation is still > >>>>>>>>>> ongoing, I assume the session timer isn=B9t yet > >>>>>>>>>> "active"? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain the > >>>>>>>>>> Session-Expires > >>>>>>>>>> header field. It is added by the proxy, based on > >>>>>>>>>> the procedures in > >>>>>>>>>> Section 8.2 of RFC 4028: > >>>>>>>>>> > >>>>>>>>>> "Because there is no Session-Expires or > >>>>>>>>>> Require header field > >>>>>>>>>> in the response, the proxy knows that it > >>>>>>>>>> is the first > >>>>>>>>>> session-timer-aware proxy to receive the > >>>>>>>>>> response. > >>>>>>>>>> This proxy > >>>>>>>>>> MUST insert a Session-Expires header field > >>>>>>>>>> into the response > >>>>>>>>>> with the value it remembered from the > >>>>>>>>>> forwarded request. > >>>>>>>>>> It > >>>>>>>>>> MUST > >>>>>>>>>> set the value of The 'refresher' parameter > >>>>>>>>>> to 'uac'. > >>>>>>>>>> The proxy MUST > >>>>>>>>>> add the 'timer' option tag to any Require > >>>>>>>>>> header field in the > >>>>>>>>>> response, and if none was present, add the > >>>>>>>>>> Require header field with > >>>>>>>>>> that value before forwarding it upstream." > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Now, one could argue that the UA should include something in > >>>>>>>>>> the UPDATE response (#7), but I think that is not a solution > >>>>>>>>>> as the UA may be confused. > >>>>>>>>>> Instead, based on my understanding of the text in section 7.4 > >>>>>>>>>> (see > >>>>>>>>>> above) the UPDATE request (#5) should not contain any > session > >>>>>>>>>> timer information. This is also more or less what the errata > >>>>>>>>>> suggests. > >>>>>>>>>> > >>>>>>>>>> Comments? > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Christer > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> sipcore mailing list > >>>>>>>>>> mailto:sipcore@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> sipcore mailing list > >>>>>>>>> mailto:sipcore@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> sipcore mailing list > >>>>>>>> mailto:sipcore@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sipcore mailing list > >>>>>> mailto:sipcore@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> mailto:sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> mailto:sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > >> > > > > > > _______________________________________________ > sipcore mailing list > mailto:sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_D6012B9E2382Bchristerholmbergericssoncom_ Content-Type: text/html; charset="windows-1254" Content-ID: <84CD0E43A88712479DDA497884956336@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Roland,

Since the originating Proxy is anyw= ay going to forward the Session-Timer UPDATE requests, why does it r= emove =93SE; supp=94? 

Regards,

Christer

From: "R.Jesske@telekom.de" <R.Jesske@telekom.de>
Date: Monday 9 October 2017 at 12:3= 4
To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.co= m>, "sipcore@ietf.org" <<= a href=3D"mailto:sipcore@ietf.org">sipcore@ietf.org>
Subject: AW: [sipcore] Session time= r fix

Hi,
sorry but I have an further issue where we have problems with session = timer.
It is the procedures of stateful Proxy Servers where we can cause a ra= ce condition.
 
We have made the observation that due to the rules we have race condit= ions with using the session timer.
 
The case is where we have transfer of SIP messages through an network = that is not supporting session timer.
 
Originating network and UAC does support session timer.
Intermediate network does not support session timer
And the terminating network does support session timer.
 
This may result with the following call flow.
 
UAC           Proxy&= nbsp;          Proxy  &nb= sp;      UAS_2  
   |         &n= bsp;             &nb= sp;   |         &nbs= p;      |       &nbs= p;       
   |-- INVITE -->|      &nb= sp;      |      &nbs= p;         |    = ; 
   |    SE; supp |-- INVITE -->|-- INVITE = (2) ->|      
   |         &n= bsp;   |    none     | &n= bsp;  SE; supp   
   |         &n= bsp;   |         &nb= sp;   |         &nbs= p;      |
   |         &n= bsp;   |         &nb= sp;   |<-- 200 (2) ----|       <= /div>
   |<- 18x (2) --|<- 18x (2) --|    SE = 1800;
   |   SE 1800;  |     &n= bsp;       |      UAS&nbs= p;      |   
   |     UAC     |&n= bsp;            |&nb= sp;            =    |      
   |-- UPDATE -->|      &nb= sp;      |      &nbs= p;         |    = ; 
   |          &= nbsp; |-- UPDATE -->| <-- UPDATE ----|     &= nbsp;  
   |         &n= bsp;   |         &nb= sp;   |         &nbs= p;      |
  |            = |<- UPDATE ---| --- UPDATE --->|
   |<- UPDATE ---|      &nb= sp;      |      &nbs= p;         |    = ;  
   |-- 491   --->|     &nbs= p;       |<-- 491     ----|=             &nb= sp;
   |         &n= bsp;   |-- 491   --->|      = ;          |
   |         &n= bsp;   |<-- 491 ----|--- 491   --->|
   |<-- 491 ----|      &nbs= p;      |       = ;         |
 
 
 
This will happen when the session timer has the same length.
How do we can solve such race conditions. I see the main problem withi= n the proxy behavior and the
Forwarding of the UPDATE (or re-INVITE) for session refresh.
 
Of course also the choice when the refresher shall sent the refresh ma= y solve the problem.
But if the originating and terminating network is using the same softw= are vendor the refresh time will be the same.
So seen from that kind of algorithm is needed to generate different se= ssion refresh times.
 
Do you see the same problems?
 
Thank you and Best Regards
 
Roland
 
 
 
 
 
 
        
 
> -----Urspr=FCngliche Nachricht-----=
> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Ky= zivat
> Gesendet: Montag, 9. Oktober 2017 00:12
> Betreff: Re: [sipcore] Session timer fix
>
> On 10/5/17 4:37 AM, Christer Holmberg wrot= e:
> > Hi,
> >
> >>> =85
> >>>
> >>>> I'll propose that the ses= sion timer negotiation never be done with
> >>>> an UPDATE within an INVIT= E transaction. (Regardless of whether than
> >>>> INVITE is negotiating a s= ession timer or not.) I think this
> >>>> resolves the problem that= you have encountered. (Or we could
> >>>> require that the UPDATE a= nd response care consistent session timer
> >>>> signaling with what is ca= rried in the INVITE and its responses.)
> >>>
> >>> I had a chat with some produc= t people, and they said that there
> >>> actually ARE cases where the = session timer is negotiated using
> >>> UPDATE when the initial INVIT= E transaction is still ongoing. There
> >>> are cases where the INVITE on= ly contains Supported:timer, but the
> >>> actual negotiation is done us= ing UPDATE.
> >>
> >> Interesting! (I wonder why.)
> >
> > I haven=92t been able to figure out e= xactly why. I was just told the
> > use-case exists.
> >
> >
> >> That sequence itself presents som= e ambiguities. The way I have always
> >> described how the session timer n= egotiation works is that *every*
> >> INVITE and UPDATE transaction aff= ects s-t - it either negotiates it
> >> *on* or else it negotiates it *of= f*. (IMO this makes it very easy to
> >> understand.)
> >>
> >> That presents issues when you hav= e an update nested inside of an invite.
> >> In the case you describe I might = expect that the update would
> >> negotiate the timer on, and then = the completion of the invite would
> >> negotiate it off again.
> >>
> >> How would the case you describe w= ork if a proxy inserted S-E in INVITE?
> >> In that case, the UAC doesn't kno= w about it until the 2xx from the
> >> invite. Before then it might try = enabling a timer using UPDATE.
> >>
> >> I am inclined to keep things simp= le by saying that the 2xx response
> >> to every INVITE or UPDATE redefin= es the state of the session timer,
> >> either on or off. That will of co= urse break the use case you describe
> above.
> >
> > The problem here is that the UAC send= s INVITE with S-E, and then
> > receives an UPDATE with S-E before it= has received a 2xx response to
> > the INVITE - making the UAC think tha= t there is a S-E glare situation
> > (i.e., the UAS also tries to initiate= session timer negotiation).
>
> Yes, I understand that is the case you are= thinking of. But I was raising a
> different case:
>
> - the UAC sends an invite without a S-E.
> - a proxy along the path includes an S-E. = (The UAC is unaware.)
> - later, the UAC sends an UPDATE with S-E.=
>
> That violates the rule in your draft, but = the UAC doesn't know it has violated
> it. So your rule for avoiding the problem = in this case doesn't work.
>
>        = Thanks,
>        = Paul
>
> > I think the RFC is pretty clear on ho= w things work once the session
> > timer has been negotiated (and, if it= isn=92t, we for sure can clarify that too).
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >>>>>
> >>>>> On 07/09/17 19:38, &q= uot;sipcore on behalf of Christer Holmberg"
> >>>>> <sipcore-bounces@ietf.org on behalf of=
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>>> seen from= my point of view the UAC should ignore the Session
> >>>>>>>> timer pro= posal within the UPDATE.
> >>>>>>>> As long a= s the negotiation is  ongoing.
> >>>>>>>>
> >>>>>>>> Neverthel= ess we have also observed this curious session timer
> >>>>>>>> behavior = in our network.
> >>>>>>>>
> >>>>>>>> I think w= e need some clarifications to the RFC. Perhaps also to
> >>>>>>>> other sec= tions to make it more readable.
> >>>>>>>> My experi= ence is that people have problems in following how the
> >>>>>>>> session t= imer should work within a complex SIP networks (e.g.
> IMS).
> >>>>>>>>
> >>>>>>>> What is a= bout updating the RFC4028.
> >>>>>>>
> >>>>>>> Like most of = the older SIP RFCs, it probably deserves an update.
> >>>>>>> The problem i= s whether going to the trouble will have any effect
> >>>>>>> on implementa= tions. I think the most we > should hope to do is
> >>>>>>> *clarify*
> >>>>>>> in
> >>>>>>> cases where t= here is ambiguity, so that when interoperability
> >>>>>>> problems aris= e it is clear who needs to change.
> >>>>>>
> >>>>>> Yes. In my case, = implementation(s) WILL be changed. The question
> >>>>>> is WHICH
> >>>>>> implementation(s)= :)
> >>>>>>
> >>>>>> So, my suggestion= would be:
> >>>>>>
> >>>>>> 1)  &nb= sp;  Specify/clarify that SE must not be sent during session-timer
> >>>>>> negotiation
> >>>>>> 2)  &nb= sp;  Specify that one must send a 491 (or some other more
> appropriate
> >>>>>> code)
> >>>>>> response if recei= ving SE during session-timer negotiation
> >>>>>>
> >>>>>> For the above, I = think we can do it using an errata.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Christer
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> -----Ursp= r=FCngliche Nachricht-----
> >>>>>>>> Von: sipc= ore [mailto:sipcore-bounces@iet= f.org] Im Auftrag von
> >>>>>>>> Christer = Holmberg
> >>>>>>>> Gesendet:= Donnerstag, 7. September 2017 11:34
> >>>>>>>> An: Paul = Kyzivat <mailto:pkyzivat@alum.m= it.edu>; mailto:sipcore@ietf.org
> >>>>>>>> Betreff: = Re: [sipcore] Session-timer issue
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>>>> T= he following issue has been around for some time already
> >>>>>>>>>> (= there is also  an errata #4744), and as it causes problems
> >>>>>>>>>> (= the INVITE is rejected with a
> >>>>>>>>>> 4= 80 response) in deployed networks, so I think it needs to be
> >>>>>>>>>> f= ixed.
> >>>>>>>>>> P= eople seem to have different opinions on which node is
> >>>>>>>>>> a= cting wrongly, so  I hope we can sort it out :)
> >>>>>>>>>
> >>>>>>>>> This = is an interesting problem. I agree that it is unclear
> >>>>>>>>> exact= ly what ought to happen in this case. (But I don't
> >>>>>>>>> under= stand why someone thinks a 480 is a good way to resolve
> >>>>>>>>> it.)<= /font>
> >>>>>>>>
> >>>>>>>> Whether 4= 80 is the best solution or not is not the issue, in my
> >>>>>>>> opinion.<= /font>
> >>>>>>>> One could= also claim that the UPDATE should be rejected. Etc.
> >>>>>>>>
> >>>>>>>> The issue= is that there is a session-timer negotiation "race
> >>>>>>>> condition= ", and we should forbid that (rejecting the UPDATE
> >>>>>>>> could be = part of such solution).
> >>>>>>>>
> >>>>>>>> Regards,<= /font>
> >>>>>>>>
> >>>>>>>> Christer<= /font>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> =      Thanks,
> >>>>>>>>> =      Paul
> >>>>>>>>>
> >>>>>>>>>> B= elow is a call flow showing the problem:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> U= A            &n= bsp;   Proxy         = ;       AS
> >>>>>>>>>>
> >>>>>>>>>> -= ------------------>
> >>>>>>>>>> I= NVITE (#1)
> >>>>>>>>>> S= upported:timer
> >>>>>>>>>> S= E:refresher=3Duac
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             -= ------------------>
> >>>>>>>>>>&n= bsp;            = ;             I= NVITE (#2)
> >>>>>>>>>>&n= bsp;            = ;             S= upported:timer
> >>>>>>>>>>&n= bsp;            = ;             S= E:refresher=3Duac
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             &= lt;-------------------
> >>>>>>>>>>&n= bsp;            = ;             1= 8x (#3)
> >>>>>>>>>>
> >>>>>>>>>> &= lt;-------------------
> >>>>>>>>>> 1= 8x (#4)
> >>>>>>>>>>
> >>>>>>>>>> &= #43;+++++ early dialog established ++++= +++
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             &= lt;-------------------
> >>>>>>>>>>&n= bsp;            = ;             U= PDATE (#5)
> >>>>>>>>>>&n= bsp;            = ;             S= upported:timer
> >>>>>>>>>>&n= bsp;            = ;             S= E:refresher=3Duas
> >>>>>>>>>>
> >>>>>>>>>> &= lt;-------------------
> >>>>>>>>>> U= PDATE (#6)
> >>>>>>>>>> S= upported:timer
> >>>>>>>>>> S= E:refresher=3Duas
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -= ------------------>
> >>>>>>>>>> 2= 00 (UPDATE) (#7)
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             -= ------------------>
> >>>>>>>>>>&n= bsp;            = ;             2= 00 (UPDATE) (#8)
> >>>>>>>>>>&n= bsp;            = ;             R= equire:timer
> >>>>>>>>>>&n= bsp;            = ;             S= E:refresher=3Duac
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;             &= lt;-------------------
> >>>>>>>>>>&n= bsp;            = ;             4= 80 (INVITE) (#9)
> >>>>>>>>>>
> >>>>>>>>>> &= lt;-------------------
> >>>>>>>>>> 4= 80 (INVITE (#10)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> A= few things to note:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N= 1:        The 18x does not contain the S= E (Session-Expires)
> header
> >>>>>>>>>> f= ield,
> >>>>>>>>>>&n= bsp;            = ; because according to section 4 of RFC 4028 the
> >>>>>>>>>> h= eader field is only
> >>>>>>>>>>&n= bsp;            = ; allowed in INVITE, UPDATE and 2xx. So, when the
> >>>>>>>>>> U= PDATE request
> >>>>>>>>>>&n= bsp;            = ; (#5) is sent, the initial session timer
> >>>>>>>>>> n= egotiation is still
> >>>>>>>>>>&n= bsp;            = ; ongoing.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N= 2:        The UPDATE request (#5) contai= ns a Session-Expires
> header
> >>>>>>>>>> f= ield.
> >>>>>>>>>>&n= bsp;            = ; Section 7.4 of RFC 4028 says:
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;         "In a session ref= resh request sent within a dialog with
> >>>>>>>>>> a= n active
> >>>>>>>>>>&n= bsp;          session timer, t= he Session-Expires header field SHOULD
> >>>>>>>>>> b= e present."
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;    Now, a dialog (early) HAS been established when the = UPDATE
> >>>>>>>> request i= s
> >>>>>>>>>>&n= bsp;            = ; sent, but as the initial session timer
> >>>>>>>>>> n= egotiation is still
> >>>>>>>>>>&n= bsp;            = ; ongoing, I assume the session timer isn=B9t yet
> >>>>>>>>>> &= quot;active"?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N= 3:        The UPDATE 200 response (#7) d= oes not contain the
> >>>>>>>>>> S= ession-Expires
> >>>>>>>>>>&n= bsp;            = ; header field. It is added by the proxy, based on
> >>>>>>>>>> t= he procedures in
> >>>>>>>>>>&n= bsp;            = ; Section 8.2 of RFC 4028:
> >>>>>>>>>>
> >>>>>>>>>>&n= bsp;            = ;      "Because there is no Session-Expires o= r
> >>>>>>>>>> R= equire header field
> >>>>>>>>>>&n= bsp;            = ;       in the response, the proxy knows that= it
> >>>>>>>>>> i= s the first
> >>>>>>>>>>&n= bsp;            = ;       session-timer-aware proxy to receive = the
> >>>>>>>>>> r= esponse.
> >>>>>>>>>> T= his  proxy
> >>>>>>>>>>&n= bsp;            = ;       MUST insert a Session-Expires header = field
> >>>>>>>>>> i= nto the response
> >>>>>>>>>>&n= bsp;            = ;       with the value it remembered from the=
> >>>>>>>>>> f= orwarded request.
> >>>>>>>>>> I= t
> >>>>>>>>>> M= UST
> >>>>>>>>>>&n= bsp;            = ;       set the value of The 'refresher' para= meter
> >>>>>>>>>> t= o 'uac'.
> >>>>>>>>>> T= he  proxy MUST
> >>>>>>>>>>&n= bsp;            = ;       add the 'timer' option tag to any Req= uire
> >>>>>>>>>> h= eader field in  the
> >>>>>>>>>>&n= bsp;            = ;       response, and if none was present, ad= d the
> >>>>>>>>>> R= equire header  field with
> >>>>>>>>>>&n= bsp;            = ;       that value before forwarding it upstr= eam."
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N= ow, one could argue that the UA should include something in
> >>>>>>>>>> t= he UPDATE response (#7), but I think that is not a solution
> >>>>>>>>>> a= s the UA may be confused.
> >>>>>>>>>> I= nstead, based on my understanding of the text in section 7.4
> >>>>>>>>>> (= see
> >>>>>>>>>> a= bove) the UPDATE request (#5) should not contain any
> session
> >>>>>>>>>> t= imer information. This is also more or less what the errata
> >>>>>>>>>> s= uggests.
> >>>>>>>>>>
> >>>>>>>>>> C= omments?
> >>>>>>>>>>
> >>>>>>>>>> R= egards,
> >>>>>>>>>>
> >>>>>>>>>> C= hrister
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _= ______________________________________________
> >>>>>>>>>> s= ipcore mailing list
> >>>>>>>>>> <= a href=3D"mailto:sipcore@ietf.org">mailto:sipcore@ietf.org
> >>>>>>>>>> <= a href=3D"https://www.ietf.org/mailman/listinfo/sipcore"> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _____= __________________________________________
> >>>>>>>>> sipco= re mailing list
> >>>>>>>>
> >>>>>>>> _________= ______________________________________
> >>>>>>>> sipcore m= ailing list
> >>>>>>>
> >>>>>>
> >>>>>> _________________= ______________________________
> >>>>>> sipcore mailing l= ist
> >>>>>
> >>>>> _____________________= __________________________
> >>>>> sipcore mailing list<= /font>
> >>>>>
> >>>>
> >>>> _________________________= ______________________
> >>>> sipcore mailing list
> >>>
> >>>
> >>
> >
> >
>
> __________________________________________= _____
> sipcore mailing list
 
--_000_D6012B9E2382Bchristerholmbergericssoncom_-- From nobody Mon Oct 9 03:54:55 2017 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 5A1B11344C9 for ; Mon, 9 Oct 2017 03:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzlz98R2-TRS for ; Mon, 9 Oct 2017 03:54:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 2D4411344E4 for ; Mon, 9 Oct 2017 03:54:47 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-e8-59db55764047 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.A8.03220.6755BD95; Mon, 9 Oct 2017 12:54:46 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 12:54:45 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaZ+6AgAEJNoA= Date: Mon, 9 Oct 2017 10:54:45 +0000 Message-ID: References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> In-Reply-To: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="windows-1254" Content-ID: <6C6C7C1E07C68F459DAA9B9CCAAE4478@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7vW5Z6O1Ig742CYsVGw6wWnz9sYnN gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYd/QlS8GE5IqnHX1sDYwNfl2MnBwSAiYS qx9eY+li5OIQEjjCKHGxdwY7hLOQUeJu33/WLkYODjYBC4nuf9ogDSICgRJXl0xgBrGFBeQk XndeYYWIy0us33mZCcK2kjizbBuYzSKgIvH5aAsbyBheAWuJCxtlQMJCAoUSTxuPgI3hFHCQ aFw6nxHEZhQQk/h+ag1YK7OAuMStJ/OZIO4UkFiy5zwzhC0q8fLxP7C1ogJ6EhtO3GYHGS8h oCQxbWsaRKuBxJFzN1khbGuJqQfWQ9naEssWvgYbwysgKHFy5hOWCYxis5Bsm4WkfRaS9llI 2mchaV/AyLqKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCmDm75rbqD8fIbx0OMAhyMSjy8 T6xuRwqxJpYVV+YeYpTgYFYS4V1mDhTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67jvQoSQQHpi SWp2ampBahFMlomDU6qBMY872+SNoYFGaebTLOX/uUEqn9TC/1ZO7/0b7XO5uXHxhdg/Wdxt Rh/z5R4r8ne89O3m8Beds+JcXIqkO9cDz4meSRyru9YmdhZHqmre2786/5z0zWkMkXmn3naf dnx+9pvr5Jpv5uarVCX3L/i55Def69Ltd46sVWtYdfNa17ToE+fy7rpVKrEUZyQaajEXFScC AFF0v16lAgAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 10:54:53 -0000 Hi Paul, >>>>>I'll propose that the session timer negotiation never be done with an >>>>> UPDATE within an INVITE transaction. (Regardless of whether than >>>>>INVITE >>>>> is negotiating a session timer or not.) I think this resolves the >>>>> problem that you have encountered. (Or we could require that the >>>>>UPDATE >>>>> and response care consistent session timer signaling with what is >>>>> carried in the INVITE and its responses.) >>>> >>>> I had a chat with some product people, and they said that there >>>>actually >>>> ARE cases where the session timer is negotiated using UPDATE when the >>>> initial INVITE transaction is still ongoing. There are cases where the >>>> INVITE only contains Supported:timer, but the actual negotiation is >>>>done >>>> using UPDATE. >>> >>> Interesting! (I wonder why.) >>=20 >> I haven=92t been able to figure out exactly why. I was just told the >> use-case exists. >>=20 >>=20 >>> That sequence itself presents some ambiguities. The way I have always >>> described how the session timer negotiation works is that *every* >>>INVITE >>> and UPDATE transaction affects s-t - it either negotiates it *on* or >>> else it negotiates it *off*. (IMO this makes it very easy to >>>understand.) >>> >>> That presents issues when you have an update nested inside of an >>>invite. >>> In the case you describe I might expect that the update would negotiate >>> the timer on, and then the completion of the invite would negotiate it >>> off again. >>> >>> How would the case you describe work if a proxy inserted S-E in INVITE? >>> In that case, the UAC doesn't know about it until the 2xx from the >>> invite. Before then it might try enabling a timer using UPDATE. >>> >>> I am inclined to keep things simple by saying that the 2xx response to >>> every INVITE or UPDATE redefines the state of the session timer, either >>> on or off. That will of course break the use case you describe above. >>=20 >> The problem here is that the UAC sends INVITE with S-E, and then >>receives >> an UPDATE with S-E before it has received a 2xx response to the INVITE - >> making the UAC think that there is a S-E glare situation (i.e., the UAS >> also tries to initiate session timer negotiation). > >Yes, I understand that is the case you are thinking of. But I was >raising a different case: > >- the UAC sends an invite without a S-E. >- a proxy along the path includes an S-E. (The UAC is unaware.) >- later, the UAC sends an UPDATE with S-E. > >That violates the rule in your draft, but the UAC doesn't know it has >violated it. So your rule for avoiding the problem in this case doesn't >work. Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I understand the proxy will never remove S-E from a response. So, we could say that the UAC must not send UPDATE with S-E until it has received a response to the INVITE. Regards, Christer >>>>>> >>>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >>>>>> >>>>>christer.holmberg@ericsson.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>>> seen from my point of view the UAC should ignore the Session >>>>>>>>>timer >>>>>>>>> proposal within the UPDATE. >>>>>>>>> As long as the negotiation is ongoing. >>>>>>>>> >>>>>>>>> Nevertheless we have also observed this curious session timer >>>>>>>>> behavior >>>>>>>>> in our network. >>>>>>>>> >>>>>>>>> I think we need some clarifications to the RFC. Perhaps also to >>>>>>>>> other >>>>>>>>> sections to make it more readable. >>>>>>>>> My experience is that people have problems in following how the >>>>>>>>> session timer should work within a complex SIP networks (e.g. >>>>>>>>>IMS). >>>>>>>>> >>>>>>>>> What is about updating the RFC4028. >>>>>>>> >>>>>>>> Like most of the older SIP RFCs, it probably deserves an update. >>>>>>>>The >>>>>>>> problem is whether going to the trouble will have any effect on >>>>>>>> implementations. I think the most we > should hope to do is >>>>>>>> *clarify* >>>>>>>> in >>>>>>>> cases where there is ambiguity, so that when interoperability >>>>>>>> problems >>>>>>>> arise it is clear who needs to change. >>>>>>> >>>>>>> Yes. In my case, implementation(s) WILL be changed. The question is >>>>>>> WHICH >>>>>>> implementation(s) :) >>>>>>> >>>>>>> So, my suggestion would be: >>>>>>> >>>>>>> 1) Specify/clarify that SE must not be sent during session-timer >>>>>>> negotiation >>>>>>> 2) Specify that one must send a 491 (or some other more appropriate >>>>>>> code) >>>>>>> response if receiving SE during session-timer negotiation >>>>>>> >>>>>>> For the above, I think we can do it using an errata. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> -----Urspr=FCngliche Nachricht----- >>>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>>>>>>> Christer Holmberg >>>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>>>>>>> An: Paul Kyzivat ; sipcore@ietf.org >>>>>>>>> Betreff: Re: [sipcore] Session-timer issue >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>>> The following issue has been around for some time already >>>>>>>>>>>(there >>>>>>>>>>> is >>>>>>>>>>> also an errata #4744), and as it causes problems (the INVITE >>>>>>>>>>>is >>>>>>>>>>> rejected with a >>>>>>>>>>> 480 response) in deployed networks, so I think it needs to be >>>>>>>>>>> fixed. >>>>>>>>>>> People seem to have different opinions on which node is acting >>>>>>>>>>> wrongly, so I hope we can sort it out :) >>>>>>>>>> >>>>>>>>>> This is an interesting problem. I agree that it is unclear >>>>>>>>>>exactly >>>>>>>>>> what ought to happen in this case. (But I don't understand why >>>>>>>>>> someone thinks a 480 is a good way to resolve it.) >>>>>>>>> >>>>>>>>> Whether 480 is the best solution or not is not the issue, in my >>>>>>>>> opinion. >>>>>>>>> One could also claim that the UPDATE should be rejected. Etc. >>>>>>>>> >>>>>>>>> The issue is that there is a session-timer negotiation "race >>>>>>>>> condition", and we should forbid that (rejecting the UPDATE could >>>>>>>>> be >>>>>>>>> part of such solution). >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Christer >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>>> Below is a call flow showing the problem: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> UA Proxy AS >>>>>>>>>>> >>>>>>>>>>> -------------------> >>>>>>>>>>> INVITE (#1) >>>>>>>>>>> Supported:timer >>>>>>>>>>> SE:refresher=3Duac >>>>>>>>>>> >>>>>>>>>>> -------------------> >>>>>>>>>>> INVITE (#2) >>>>>>>>>>> Supported:timer >>>>>>>>>>> SE:refresher=3Duac >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <------------------- >>>>>>>>>>> 18x (#3) >>>>>>>>>>> >>>>>>>>>>> <------------------- >>>>>>>>>>> 18x (#4) >>>>>>>>>>> >>>>>>>>>>> ++++++ early dialog established +++++++ >>>>>>>>>>> >>>>>>>>>>> <------------------- >>>>>>>>>>> UPDATE (#5) >>>>>>>>>>> Supported:timer >>>>>>>>>>> SE:refresher=3Duas >>>>>>>>>>> >>>>>>>>>>> <------------------- >>>>>>>>>>> UPDATE (#6) >>>>>>>>>>> Supported:timer >>>>>>>>>>> SE:refresher=3Duas >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------------------> >>>>>>>>>>> 200 (UPDATE) (#7) >>>>>>>>>>> >>>>>>>>>>> -------------------> >>>>>>>>>>> 200 (UPDATE) (#8) >>>>>>>>>>> Require:timer >>>>>>>>>>> SE:refresher=3Duac >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <------------------- >>>>>>>>>>> 480 (INVITE) (#9) >>>>>>>>>>> >>>>>>>>>>> <------------------- >>>>>>>>>>> 480 (INVITE (#10) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A few things to note: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> N1: The 18x does not contain the SE (Session-Expires) header >>>>>>>>>>> field, >>>>>>>>>>> because according to section 4 of RFC 4028 the >>>>>>>>>>>header >>>>>>>>>>> field is only >>>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the >>>>>>>>>>> UPDATE >>>>>>>>>>> request >>>>>>>>>>> (#5) is sent, the initial session timer >>>>>>>>>>>negotiation >>>>>>>>>>> is >>>>>>>>>>> still >>>>>>>>>>> ongoing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> N2: The UPDATE request (#5) contains a Session-Expires header >>>>>>>>>>> field. >>>>>>>>>>> Section 7.4 of RFC 4028 says: >>>>>>>>>>> >>>>>>>>>>> "In a session refresh request sent within a dialog with >>>>>>>>>>>an >>>>>>>>>>> active >>>>>>>>>>> session timer, the Session-Expires header field SHOULD >>>>>>>>>>>be >>>>>>>>>>> present." >>>>>>>>>>> >>>>>>>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>>>>>>> request is >>>>>>>>>>> sent, but as the initial session timer >>>>>>>>>>>negotiation is >>>>>>>>>>> still >>>>>>>>>>> ongoing, I assume the session timer isn=B9t yet >>>>>>>>>>> "active"? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain the >>>>>>>>>>> Session-Expires >>>>>>>>>>> header field. It is added by the proxy, based on >>>>>>>>>>>the >>>>>>>>>>> procedures in >>>>>>>>>>> Section 8.2 of RFC 4028: >>>>>>>>>>> >>>>>>>>>>> "Because there is no Session-Expires or >>>>>>>>>>>Require >>>>>>>>>>> header field >>>>>>>>>>> in the response, the proxy knows that it is >>>>>>>>>>>the >>>>>>>>>>> first >>>>>>>>>>> session-timer-aware proxy to receive the >>>>>>>>>>> response. >>>>>>>>>>> This proxy >>>>>>>>>>> MUST insert a Session-Expires header field >>>>>>>>>>>into >>>>>>>>>>> the >>>>>>>>>>> response >>>>>>>>>>> with the value it remembered from the >>>>>>>>>>>forwarded >>>>>>>>>>> request. >>>>>>>>>>> It >>>>>>>>>>> MUST >>>>>>>>>>> set the value of The 'refresher' parameter >>>>>>>>>>>to >>>>>>>>>>> 'uac'. >>>>>>>>>>> The proxy MUST >>>>>>>>>>> add the 'timer' option tag to any Require >>>>>>>>>>> header >>>>>>>>>>> field in the >>>>>>>>>>> response, and if none was present, add the >>>>>>>>>>> Require >>>>>>>>>>> header field with >>>>>>>>>>> that value before forwarding it upstream." >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now, one could argue that the UA should include something in >>>>>>>>>>>the >>>>>>>>>>> UPDATE response (#7), but I think that is not a solution as the >>>>>>>>>>> UA >>>>>>>>>>> may be confused. >>>>>>>>>>> Instead, based on my understanding of the text in section 7.4 >>>>>>>>>>> (see >>>>>>>>>>> above) the UPDATE request (#5) should not contain any session >>>>>>>>>>> timer >>>>>>>>>>> information. This is also more or less what the errata >>>>>>>>>>>suggests. >>>>>>>>>>> >>>>>>>>>>> Comments? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Christer >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>> >>=20 >>=20 > From nobody Mon Oct 9 04:36:17 2017 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 A863A13450A for ; Mon, 9 Oct 2017 04:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=8E3rtZtI; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=Byml+xoo 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 IlTq2ZH9IhwA for ; Mon, 9 Oct 2017 04:36:09 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 6DB19134504 for ; Mon, 9 Oct 2017 04:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1507548968; x=1539084968; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pIJfln0y8nrXqxXTv1n4AbpQJsdCMKW8drNiVao/3ic=; b=8E3rtZtIbPy9/BiIUQbTuaIM2l//YshRErk5snGlu5FeMarYSrdPDPbv +FwKlBXca5yPBpnXRA0u96jFKnhvi3q7GMarfQQ+1Nzjpa7J2msbhWHcd NzZeVfa1epyjskDleBUyEhkBwRCy/sv9KvlqGqZAtA1iMqwvEKfjLbPdh hRUWHybZR0Er0oCB/BLhBxWFZ4x+Cl+iWEhBwBHRewIdND6pZimRX9S08 BOMJhHsgXVo2JPwxe7NtjWiNFWRHhhaNw2kYmsGVVFyNeU+4EbInM1xqV 89smgGqQ4AXsHu1qhUQQWLZmeBytW3dXYvFQOEbajBvrETX9r9dIU9THz w==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2017 13:36:05 +0200 X-IronPort-AV: E=Sophos;i="5.42,500,1500933600"; d="scan'208,217";a="1400959705" Received: from he106157.emea1.cds.t-internal.com ([10.169.119.87]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 09 Oct 2017 13:36:00 +0200 Received: from HE106138.EMEA1.cds.t-internal.com (10.169.119.71) by HE106157.emea1.cds.t-internal.com (10.169.119.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 13:35:59 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE106138.EMEA1.cds.t-internal.com (10.169.119.71) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 13:35:59 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.18) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 9 Oct 2017 13:35:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pIJfln0y8nrXqxXTv1n4AbpQJsdCMKW8drNiVao/3ic=; b=Byml+xoo/UXaqNG7OllwvWEvJsdzmMG1qIswTl8dteBjB5uhHK0K5D3/SICYo4hZS20QtycTlJG/SA0FSBOp63+GF+lBpXQ11aPbWRPnu/54ODfsX+rGaRFNe0UyRyIkhdJvjT2I6tbAYMSZn4P241bYiviqFlhtnQr2B/GR1bM= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 9 Oct 2017 11:35:58 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Mon, 9 Oct 2017 11:35:58 +0000 From: "Jesske, Roland" To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: AW: [sipcore] Session timer fix Thread-Index: AQHTQOm2oSMfVjmoRUiXQCsnsdtf3qLbUicA Date: Mon, 9 Oct 2017 11:35:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.68] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0483; 6:OyM9us1Ts3+An6ckNJI/1wIqldqqlMU1gmjr3HErzITfUt505D7PasC4BsG32wzINFneYASxOQmK0BF+oKu5R566gO4Juwt5tYmbq8L/RO6J+OSSjE2nwEd06LdeZHpvtKkBAmwAxmk0rB6gyqetq93DgraWKuzf+KDDDFUXtZ1liJc0EBbk7qg7KVK75k3AClsXwZCAtqPzG2UffbcDe52gOOzZ/jYpsvTHquAgR5ij00XXgnLj9J68hiLBsr8zRRduNw3ikv3ulpFb19EbENmiKy68k+rHXAEVCWUGpka5ApPFoF4J4wS/dDTepTTiZYNLHgVE+Ho4PZSbNOFCCA==; 5:KXBU/Nc+8E5t/fWGqCis/ZtLRaLIJTIZjse5XUEBKzOu5HO3iTSn/Xsmm370Q+PZH8vl8PNj0mTxoaaMtVaTHo1AW22xvvgo1nTMnIlvYQix/X/gUtM33ocUGwsg/yKITz/a47MTSDVWQ7UYCjPlRSQA0R0jt977eSF9c87Hujw=; 24:1A+uF/Le5+J8pPOH4m5yaCyz5hDqRakKFWGpMhE+TZrZ+mSF51CodZ6j+63pYirdYAITOHvetRWBqKKjcksbV034dFl04TmJ/NnnbLez99E=; 7:bv+SUYcO/V3h8DhWdUaQBUoGEfGSFGWWN4ANahZJ9Q4xaTuTVadTwGat0YxMmnxQAlwR3F+xpKisvOe8450agTnAUDStEM7OKq/4xb0Z4X94UW4IKUfMJlPdHu922mQ5ZhtDsbS64/9UtImklIP+kCcFRPu7KYJ8g1LG134b+gPkgTYgTzyHjLHjSA5tr6zKEMqQZ2raf+XHQdn71br0Ws+J5KCCULHtDtIUsuyavkM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0972cb07-89e3-4181-d526-08d50f09e8f6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0483; x-ms-traffictypediagnostic: FRAPR01MB0483: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0483; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0483; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(24454002)(377454003)(199003)(189002)(51444003)(110136005)(7696004)(16200700003)(561944003)(2171002)(478600001)(551934003)(606006)(5660300001)(966005)(53546010)(5250100002)(76176999)(50986999)(189998001)(106356001)(236005)(33656002)(2950100002)(55016002)(7736002)(105586002)(3280700002)(8676002)(97736004)(101416001)(3846002)(790700001)(102836003)(2900100001)(2501003)(6116002)(68736007)(14454004)(86362001)(53936002)(72206003)(8936002)(3660700001)(9686003)(75402003)(54896002)(6306002)(316002)(81156014)(54356999)(66066001)(81166006)(2906002)(53946003)(74482002)(559001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0483; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB04830E177CDF6CA24FBE7FF1F9740FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 11:35:57.9624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0483 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 11:36:16 -0000 --_000_FRAPR01MB04830E177CDF6CA24FBE7FF1F9740FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christer, Ok it is not the outgoing proxy of the originating network that deletes the= supported header. The outgoing proxy of the orig. network will keep the supported timer. But = the incoming proxy of the intermediate network, which is also statefull wil= l delete the supported timer. Same apply for the backward direction. This is the typical interconnection usage. So as I said this is a real issue we have. Originating | transit | terminating UAC Proxy | Proxy Proxy | Proxy UAS_2 Session timer sup | no sup | Session timer sup Best Regards Roland Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Gesendet: Montag, 9. Oktober 2017 12:31 An: Jesske, Roland ; Paul Kyzivat ; sipcore@ietf.org Betreff: Re: AW: [sipcore] Session timer fix Hi Roland, Since the originating Proxy is anyway going to forward the Session-Timer UP= DATE requests, why does it remove "SE; supp"? Regards, Christer From: "R.Jesske@telekom.de" > Date: Monday 9 October 2017 at 12:34 To: "pkyzivat@alum.mit.edu" >, Christer Holmberg >, "sipcore@ietf.org" > Subject: AW: [sipcore] Session timer fix Hi, sorry but I have an further issue where we have problems with session timer= . It is the procedures of stateful Proxy Servers where we can cause a race co= ndition. We have made the observation that due to the rules we have race conditions = with using the session timer. The case is where we have transfer of SIP messages through an network that = is not supporting session timer. Originating network and UAC does support session timer. Intermediate network does not support session timer And the terminating network does support session timer. This may result with the following call flow. UAC Proxy Proxy UAS_2 | | | |-- INVITE -->| | | | SE; supp |-- INVITE -->|-- INVITE (2) ->| | | none | SE; supp | | | | | | |<-- 200 (2) ----| |<- 18x (2) --|<- 18x (2) --| SE 1800; | SE 1800; | | UAS | | UAC | | | |-- UPDATE -->| | | | |-- UPDATE -->| <-- UPDATE ----| | | | | | |<- UPDATE ---| --- UPDATE --->| |<- UPDATE ---| | | |-- 491 --->| |<-- 491 ----| | |-- 491 --->| | | |<-- 491 ----|--- 491 --->| |<-- 491 ----| | | This will happen when the session timer has the same length. How do we can solve such race conditions. I see the main problem within the= proxy behavior and the Forwarding of the UPDATE (or re-INVITE) for session refresh. Of course also the choice when the refresher shall sent the refresh may sol= ve the problem. But if the originating and terminating network is using the same software v= endor the refresh time will be the same. So seen from that kind of algorithm is needed to generate different session= refresh times. Do you see the same problems? Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Montag, 9. Oktober 2017 00:12 > An: Christer Holmberg >; sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix > > On 10/5/17 4:37 AM, Christer Holmberg wrote: > > Hi, > > > >>> ... > >>> > >>>> I'll propose that the session timer negotiation never be done with > >>>> an UPDATE within an INVITE transaction. (Regardless of whether than > >>>> INVITE is negotiating a session timer or not.) I think this > >>>> resolves the problem that you have encountered. (Or we could > >>>> require that the UPDATE and response care consistent session timer > >>>> signaling with what is carried in the INVITE and its responses.) > >>> > >>> I had a chat with some product people, and they said that there > >>> actually ARE cases where the session timer is negotiated using > >>> UPDATE when the initial INVITE transaction is still ongoing. There > >>> are cases where the INVITE only contains Supported:timer, but the > >>> actual negotiation is done using UPDATE. > >> > >> Interesting! (I wonder why.) > > > > I haven't been able to figure out exactly why. I was just told the > > use-case exists. > > > > > >> That sequence itself presents some ambiguities. The way I have always > >> described how the session timer negotiation works is that *every* > >> INVITE and UPDATE transaction affects s-t - it either negotiates it > >> *on* or else it negotiates it *off*. (IMO this makes it very easy to > >> understand.) > >> > >> That presents issues when you have an update nested inside of an invit= e. > >> In the case you describe I might expect that the update would > >> negotiate the timer on, and then the completion of the invite would > >> negotiate it off again. > >> > >> How would the case you describe work if a proxy inserted S-E in INVITE= ? > >> In that case, the UAC doesn't know about it until the 2xx from the > >> invite. Before then it might try enabling a timer using UPDATE. > >> > >> I am inclined to keep things simple by saying that the 2xx response > >> to every INVITE or UPDATE redefines the state of the session timer, > >> either on or off. That will of course break the use case you describe > above. > > > > The problem here is that the UAC sends INVITE with S-E, and then > > receives an UPDATE with S-E before it has received a 2xx response to > > the INVITE - making the UAC think that there is a S-E glare situation > > (i.e., the UAS also tries to initiate session timer negotiation). > > Yes, I understand that is the case you are thinking of. But I was raising= a > different case: > > - the UAC sends an invite without a S-E. > - a proxy along the path includes an S-E. (The UAC is unaware.) > - later, the UAC sends an UPDATE with S-E. > > That violates the rule in your draft, but the UAC doesn't know it has vio= lated > it. So your rule for avoiding the problem in this case doesn't work. > > Thanks, > Paul > > > I think the RFC is pretty clear on how things work once the session > > timer has been negotiated (and, if it isn't, we for sure can clarify th= at too). > > > > Regards, > > > > Christer > > > > > > > > > > > >>>>> > >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > >>>>> on behal= f of > >>>>> mailto:christer.holmberg@ericsson.com> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>>>> seen from my point of view the UAC should ignore the Session > >>>>>>>> timer proposal within the UPDATE. > >>>>>>>> As long as the negotiation is ongoing. > >>>>>>>> > >>>>>>>> Nevertheless we have also observed this curious session timer > >>>>>>>> behavior in our network. > >>>>>>>> > >>>>>>>> I think we need some clarifications to the RFC. Perhaps also to > >>>>>>>> other sections to make it more readable. > >>>>>>>> My experience is that people have problems in following how the > >>>>>>>> session timer should work within a complex SIP networks (e.g. > IMS). > >>>>>>>> > >>>>>>>> What is about updating the RFC4028. > >>>>>>> > >>>>>>> Like most of the older SIP RFCs, it probably deserves an update. > >>>>>>> The problem is whether going to the trouble will have any effect > >>>>>>> on implementations. I think the most we > should hope to do is > >>>>>>> *clarify* > >>>>>>> in > >>>>>>> cases where there is ambiguity, so that when interoperability > >>>>>>> problems arise it is clear who needs to change. > >>>>>> > >>>>>> Yes. In my case, implementation(s) WILL be changed. The question > >>>>>> is WHICH > >>>>>> implementation(s) :) > >>>>>> > >>>>>> So, my suggestion would be: > >>>>>> > >>>>>> 1) Specify/clarify that SE must not be sent during session-tim= er > >>>>>> negotiation > >>>>>> 2) Specify that one must send a 491 (or some other more > appropriate > >>>>>> code) > >>>>>> response if receiving SE during session-timer negotiation > >>>>>> > >>>>>> For the above, I think we can do it using an errata. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Christer > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von > >>>>>>>> Christer Holmberg > >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 > >>>>>>>> An: Paul Kyzivat ; mailto:sipcore@= ietf.org > >>>>>>>> Betreff: Re: [sipcore] Session-timer issue > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>>>> The following issue has been around for some time already > >>>>>>>>>> (there is also an errata #4744), and as it causes problems > >>>>>>>>>> (the INVITE is rejected with a > >>>>>>>>>> 480 response) in deployed networks, so I think it needs to be > >>>>>>>>>> fixed. > >>>>>>>>>> People seem to have different opinions on which node is > >>>>>>>>>> acting wrongly, so I hope we can sort it out :) > >>>>>>>>> > >>>>>>>>> This is an interesting problem. I agree that it is unclear > >>>>>>>>> exactly what ought to happen in this case. (But I don't > >>>>>>>>> understand why someone thinks a 480 is a good way to resolve > >>>>>>>>> it.) > >>>>>>>> > >>>>>>>> Whether 480 is the best solution or not is not the issue, in my > >>>>>>>> opinion. > >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. > >>>>>>>> > >>>>>>>> The issue is that there is a session-timer negotiation "race > >>>>>>>> condition", and we should forbid that (rejecting the UPDATE > >>>>>>>> could be part of such solution). > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Christer > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>>> Below is a call flow showing the problem: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> UA Proxy AS > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> INVITE (#1) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> INVITE (#2) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 18x (#3) > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 18x (#4) > >>>>>>>>>> > >>>>>>>>>> ++++++ early dialog established +++++++ > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> UPDATE (#5) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duas > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> UPDATE (#6) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duas > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> 200 (UPDATE) (#7) > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> 200 (UPDATE) (#8) > >>>>>>>>>> Require:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 480 (INVITE) (#9) > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 480 (INVITE (#10) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> A few things to note: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N1: The 18x does not contain the SE (Session-Expires) > header > >>>>>>>>>> field, > >>>>>>>>>> because according to section 4 of RFC 4028 the > >>>>>>>>>> header field is only > >>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the > >>>>>>>>>> UPDATE request > >>>>>>>>>> (#5) is sent, the initial session timer > >>>>>>>>>> negotiation is still > >>>>>>>>>> ongoing. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N2: The UPDATE request (#5) contains a Session-Expires > header > >>>>>>>>>> field. > >>>>>>>>>> Section 7.4 of RFC 4028 says: > >>>>>>>>>> > >>>>>>>>>> "In a session refresh request sent within a dialog wi= th > >>>>>>>>>> an active > >>>>>>>>>> session timer, the Session-Expires header field SHOU= LD > >>>>>>>>>> be present." > >>>>>>>>>> > >>>>>>>>>> Now, a dialog (early) HAS been established when the UPDATE > >>>>>>>> request is > >>>>>>>>>> sent, but as the initial session timer > >>>>>>>>>> negotiation is still > >>>>>>>>>> ongoing, I assume the session timer isn=B9t yet > >>>>>>>>>> "active"? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain the > >>>>>>>>>> Session-Expires > >>>>>>>>>> header field. It is added by the proxy, based on > >>>>>>>>>> the procedures in > >>>>>>>>>> Section 8.2 of RFC 4028: > >>>>>>>>>> > >>>>>>>>>> "Because there is no Session-Expires or > >>>>>>>>>> Require header field > >>>>>>>>>> in the response, the proxy knows that it > >>>>>>>>>> is the first > >>>>>>>>>> session-timer-aware proxy to receive the > >>>>>>>>>> response. > >>>>>>>>>> This proxy > >>>>>>>>>> MUST insert a Session-Expires header field > >>>>>>>>>> into the response > >>>>>>>>>> with the value it remembered from the > >>>>>>>>>> forwarded request. > >>>>>>>>>> It > >>>>>>>>>> MUST > >>>>>>>>>> set the value of The 'refresher' parameter > >>>>>>>>>> to 'uac'. > >>>>>>>>>> The proxy MUST > >>>>>>>>>> add the 'timer' option tag to any Require > >>>>>>>>>> header field in the > >>>>>>>>>> response, and if none was present, add the > >>>>>>>>>> Require header field with > >>>>>>>>>> that value before forwarding it upstream." > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Now, one could argue that the UA should include something in > >>>>>>>>>> the UPDATE response (#7), but I think that is not a solution > >>>>>>>>>> as the UA may be confused. > >>>>>>>>>> Instead, based on my understanding of the text in section 7.4 > >>>>>>>>>> (see > >>>>>>>>>> above) the UPDATE request (#5) should not contain any > session > >>>>>>>>>> timer information. This is also more or less what the errata > >>>>>>>>>> suggests. > >>>>>>>>>> > >>>>>>>>>> Comments? > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Christer > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> sipcore mailing list > >>>>>>>>>> mailto:sipcore@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> sipcore mailing list > >>>>>>>>> mailto:sipcore@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> sipcore mailing list > >>>>>>>> mailto:sipcore@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sipcore mailing list > >>>>>> mailto:sipcore@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> mailto:sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> mailto:sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > >> > > > > > > _______________________________________________ > sipcore mailing list > mailto:sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_FRAPR01MB04830E177CDF6CA24FBE7FF1F9740FRAPR01MB0483DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Christer,<= /p>

Ok it is not the outgoing proxy= of the originating network that deletes the supported header.

The outgoing proxy of the orig.= network will keep the supported timer. But the incoming proxy of the inter= mediate network, which is also statefull will delete the supported timer. Same apply for the backward direction.

 

This is the typical interconnec= tion usage.

So as I said this is a real iss= ue we have.

&nbs= p;

   Originating  =      |  transit    | terminati= ng

UAC    &nbs= p;      Proxy  | Proxy Proxy | Prox= y         UAS_2  

Session timer sup   &= nbsp;|    no sup   | Session timer sup   = ; 

&nbs= p;

&nbs= p;

 

Best Regards<= /p>

 

Roland

 

Von: Christer Holmberg [mailto:chris= ter.holmberg@ericsson.com]
Gesendet: Montag, 9. Oktober 2017 12:31
An: Jesske, Roland <R.Jesske@telekom.de>; Paul Kyzivat <pky= zivat@alum.mit.edu>; sipcore@ietf.org
Betreff: Re: AW: [sipcore] Session timer fix

 

Hi Roland,

 =

Since the originating Pr= oxy is anyway going to forward the Session-Timer UPDATE requests, why does = it remove “SE; supp”? 

 =

Regards,

 =

Christer

 =

From: "R.Jesske@telekom.de" <R.Jesske= @telekom.de>
Date: Monday 9 October 2017 at 12:34
To: "pkyzivat@alum.mit.edu" <pkyziv= at@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>, "sipcore@i= etf.org" <sipcore@ietf.org>
Subject: AW: [sipcore] Session timer fix

 =

Hi,

sorry but I have an further iss= ue where we have problems with session timer.

It is the procedures of statefu= l Proxy Servers where we can cause a race condition.

 

We have made the observation th= at due to the rules we have race conditions with using the session timer.

 

The case is where we have trans= fer of SIP messages through an network that is not supporting session timer= .

 

Originating network and UAC doe= s support session timer.

Intermediate network does not s= upport session timer

And the terminating network doe= s support session timer.

 

This may result with the follow= ing call flow.

 

UAC    &nbs= p;      Proxy       =     Proxy         UAS_2&n= bsp; 

   |   = ;             &= nbsp;          |   &= nbsp;            | &= nbsp;           &nbs= p; 

   |-- INVITE -->|=              |&= nbsp;           &nbs= p;   |     

   |   = ; SE; supp |-- INVITE -->|-- INVITE (2) ->|    &n= bsp; 

   |   = ;          |   = none     |    SE; supp   = ;

   |   = ;          |   =           |   &= nbsp;            |

   |   = ;          |   =           |<-- 200 (2) ----= |      

   |<- 18x (2) --|= <- 18x (2) --|    SE 1800;

   |   SE 1800;&= nbsp; |             = |      UAS       |&n= bsp;  

   |   = ;  UAC     |      &n= bsp;      |      &nb= sp;         |   &nbs= p;  

   |-- UPDATE -->|=              |&= nbsp;           &nbs= p;   |     

   |   = ;         |-- UPDATE -->| <-- UPDA= TE ----|        

   |   = ;          |   =           |   &= nbsp;            |

  |    &nbs= p;       |<- UPDATE ---| --- UPDATE --->= ;|

   |<- UPDATE ---|=              |&= nbsp;           &nbs= p;   |      

   |-- 491   ---= >|           &nbs= p; |<-- 491     ----|      =        

   |   = ;          |-- 491   ---&= gt;|            = ;    |

   |   = ;          |<-- 491 ----|--= - 491   --->|

   |<-- 491 ----|&= nbsp;            |&n= bsp;            = ;   |

 

 

 

This will happen when the sessi= on timer has the same length.

How do we can solve such race c= onditions. I see the main problem within the proxy behavior and the

Forwarding of the UPDATE (or re= -INVITE) for session refresh.

 

Of course also the choice when = the refresher shall sent the refresh may solve the problem.

But if the originating and term= inating network is using the same software vendor the refresh time will be = the same.

So seen from that kind of algor= ithm is needed to generate different session refresh times.

 

Do you see the same problems?

 

Thank you and Best Regards=

 

Roland

 

 

 

 

 

 

     &= nbsp;  

 

> -----Urspr=FCngliche Nachricht----= -

> Von: sipcore [mailto:sipcore-bounces@ietf.org<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:black">] Im Auftrag von Paul Kyzivat

> Gesendet: Montag, 9. Oktober 2017 = 00:12

> An: Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsso= n.com>; sipcore@ietf.org> Betreff: Re: [sipco= re] Session timer fix

>

> On 10/5/17 4:37 AM,= Christer Holmberg wrote:

> > Hi,

> >

> >>> …= ;

> >>>=

> >>>> I'= ll propose that the session timer negotiation never be done with

> >>>> an= UPDATE within an INVITE transaction. (Regardless of whether than

> >>>> IN= VITE is negotiating a session timer or not.) I think this

> >>>> re= solves the problem that you have encountered. (Or we could

> >>>> re= quire that the UPDATE and response care consistent session timer

> >>>> si= gnaling with what is carried in the INVITE and its responses.)

> >>>=

> >>> I had = a chat with some product people, and they said that there

> >>> actual= ly ARE cases where the session timer is negotiated using

> >>> UPDATE= when the initial INVITE transaction is still ongoing. There

> >>> are ca= ses where the INVITE only contains Supported:timer, but the

> >>> actual= negotiation is done using UPDATE.

> >>

> >> Interestin= g! (I wonder why.)

> >

> > I haven’= t been able to figure out exactly why. I was just told the

> > use-case exist= s.

> >

> >

> >> That seque= nce itself presents some ambiguities. The way I have always

> >> described = how the session timer negotiation works is that *every*

> >> INVITE and= UPDATE transaction affects s-t - it either negotiates it

> >> *on* or el= se it negotiates it *off*. (IMO this makes it very easy to

> >> understand= .)

> >>

> >> That prese= nts issues when you have an update nested inside of an invite.

> >> In the cas= e you describe I might expect that the update would

> >> negotiate = the timer on, and then the completion of the invite would

> >> negotiate = it off again.

> >>

> >> How would = the case you describe work if a proxy inserted S-E in INVITE?

> >> In that ca= se, the UAC doesn't know about it until the 2xx from the

> >> invite. Be= fore then it might try enabling a timer using UPDATE.

> >>

> >> I am incli= ned to keep things simple by saying that the 2xx response

> >> to every I= NVITE or UPDATE redefines the state of the session timer,

> >> either on = or off. That will of course break the use case you describe

> above.

> >

> > The problem he= re is that the UAC sends INVITE with S-E, and then

> > receives an UP= DATE with S-E before it has received a 2xx response to

> > the INVITE - m= aking the UAC think that there is a S-E glare situation

> > (i.e., the UAS= also tries to initiate session timer negotiation).

>

> Yes, I understand t= hat is the case you are thinking of. But I was raising a

> different case:

>

> - the UAC sends an = invite without a S-E.

> - a proxy along the= path includes an S-E. (The UAC is unaware.)

> - later, the UAC se= nds an UPDATE with S-E.

>

> That violates the r= ule in your draft, but the UAC doesn't know it has violated

> it. So your rule fo= r avoiding the problem in this case doesn't work.>

>   &n= bsp;    Thanks,

>   &n= bsp;    Paul

>

> > I think the RF= C is pretty clear on how things work once the session

> > timer has been= negotiated (and, if it isn’t, we for sure can clarify that too).

> >

> > Regards,

> >

> > Christer

> >

> >

> >

> >

> >

> >>>>>= ;

> >>>>>= ; On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg"

> >>>>>= ; <si= pcore-bounces@ietf.org on behalf of

> >>>>>= ; wrote:

> >>>>>= ;

> >>>>>= ;> Hi,

> >>>>>= ;>

> >>>>>= ;>>> seen from my point of view the UAC should ignore the Session<= /span>

> >>>>>= ;>>> timer proposal within the UPDATE.=

> >>>>>= ;>>> As long as the negotiation is  ongoing.

> >>>>>= ;>>>

> >>>>>= ;>>> Nevertheless we have also observed this curious session timer=

> >>>>>= ;>>> behavior in our network.

> >>>>>= ;>>>

> >>>>>= ;>>> I think we need some clarifications to the RFC. Perhaps also = to

> >>>>>= ;>>> other sections to make it more readable.

> >>>>>= ;>>> My experience is that people have problems in following how t= he

> >>>>>= ;>>> session timer should work within a complex SIP networks (e.g.=

> IMS).

> >>>>>= ;>>>

> >>>>>= ;>>> What is about updating the RFC4028.> >>>>>= ;>>

> >>>>>= ;>> Like most of the older SIP RFCs, it probably deserves an update.<= /span>

> >>>>>= ;>> The problem is whether going to the trouble will have any effect<= /span>

> >>>>>= ;>> on implementations. I think the most we > should hope to do is=

> >>>>>= ;>> *clarify*

> >>>>>= ;>> in

> >>>>>= ;>> cases where there is ambiguity, so that when interoperability

> >>>>>= ;>> problems arise it is clear who needs to change.

> >>>>>= ;>

> >>>>>= ;> Yes. In my case, implementation(s) WILL be changed. The question

> >>>>>= ;> is WHICH

> >>>>>= ;> implementation(s) :)

> >>>>>= ;>

> >>>>>= ;> So, my suggestion would be:

> >>>>>= ;>

> >>>>>= ;> 1)     Specify/clarify that SE must not be sent d= uring session-timer

> >>>>>= ;> negotiation

> >>>>>= ;> 2)     Specify that one must send a 491 (or some = other more

> appropriate<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Courier New= ";color:black">

> >>>>>= ;> code)

> >>>>>= ;> response if receiving SE during session-timer negotiation

> >>>>>= ;>

> >>>>>= ;> For the above, I think we can do it using an errata.

> >>>>>>

> >>>>>> Regards,<= /span>

> >>>>>>

> >>>>>> Christer<= /span>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>>> -= ----Urspr=FCngliche Nachricht-----

> >>>>>>>> V= on: sipcore [mailto:sip= core-bounces@ietf.org] Im Auftrag von

> >>>>>>>> C= hrister Holmberg

> >>>>>>>> G= esendet: Donnerstag, 7. September 2017 11:34=

> >>>>>= ;>>> Betreff: Re: [sipcore] Session-timer issue

> >>>>>= ;>>>

> >>>>>= ;>>> Hi,

> >>>>>= ;>>>

> >>>>>= ;>>>>> The following issue has been around for some time alr= eady

> >>>>>= ;>>>>> (there is also  an errata #4744), and as it caus= es problems

> >>>>>= ;>>>>> (the INVITE is rejected with a

> >>>>>= ;>>>>> 480 response) in deployed networks, so I think it nee= ds to be

> >>>>>= ;>>>>> fixed.<= /p>

> >>>>>= ;>>>>> People seem to have different opinions on which node = is

> >>>>>= ;>>>>> acting wrongly, so  I hope we can sort it out :)=

> >>>>>= ;>>>>

> >>>>>= ;>>>> This is an interesting problem. I agree that it is unclea= r

> >>>>>= ;>>>> exactly what ought to happen in this case. (But I don't

> >>>>>= ;>>>> understand why someone thinks a 480 is a good way to reso= lve

> >>>>>= ;>>>> it.)

> >>>>>= ;>>>

> >>>>>= ;>>> Whether 480 is the best solution or not is not the issue, in = my

> >>>>>= ;>>> opinion.

> >>>>>= ;>>> One could also claim that the UPDATE should be rejected. Etc.=

> >>>>>= ;>>>

> >>>>>= ;>>> The issue is that there is a session-timer negotiation "= race

> >>>>>= ;>>> condition", and we should forbid that (rejecting the UPD= ATE

> >>>>>= ;>>> could be part of such solution).<= o:p>

> >>>>>= ;>>>

> >>>>>= ;>>> Regards,

> >>>>>= ;>>>

> >>>>>= ;>>> Christer

> >>>>>= ;>>>

> >>>>>= ;>>>

> >>>>>= ;>>>

> >>>>>= ;>>>

> >>>>>= ;>>>

> >>>>>= ;>>>>

> >>>>>= ;>>>>      Thanks,

> >>>>>= ;>>>>      Paul

> >>>>>= ;>>>>

> >>>>>= ;>>>>> Below is a call flow showing the problem:

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> UA        &nb= sp;       Proxy     =            AS

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> ------------------->

> >>>>>= ;>>>>> INVITE (#1)

> >>>>>= ;>>>>> Supported:timer

> >>>>>&g= t;>>>> SE:refresher=3Duac

> >>>>>&g= t;>>>>

> >>>>>&g= t;>>>>         &nb= sp;            =     ------------------->

> >>>>>&g= t;>>>>         &nb= sp;            =     INVITE (#2)

> >>>>>&g= t;>>>>         &nb= sp;            =     Supported:timer

> >>>>>&g= t;>>>>         &nb= sp;            =     SE:refresher=3Duac

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =             &nb= sp;    <-------------------

> >>>>>= ;>>>>>         =             &nb= sp;    18x (#3)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> <-------------------

> >>>>>= ;>>>>> 18x (#4)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> ++++++ early dialog establish= ed +++++++

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =             &nb= sp;    <-------------------

> >>>>>= ;>>>>>         =             &nb= sp;    UPDATE (#5)

> >>>>>= ;>>>>>         =             &nb= sp;    Supported:timer

> >>>>>= ;>>>>>         =             &nb= sp;    SE:refresher=3Duas=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> <-------------------

> >>>>>= ;>>>>> UPDATE (#6)

> >>>>>= ;>>>>> Supported:timer

> >>>>>= ;>>>>> SE:refresher=3Duas=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> ------------------->

> >>>>>= ;>>>>> 200 (UPDATE) (#7)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =             &nb= sp;    ------------------->

> >>>>>= ;>>>>>         =             &nb= sp;    200 (UPDATE) (#8)

> >>>>>= ;>>>>>         =             &nb= sp;    Require:timer<= /span>

> >>>>>= ;>>>>>         =             &nb= sp;    SE:refresher=3Duac=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =             &nb= sp;    <-------------------

> >>>>>= ;>>>>>         =             &nb= sp;    480 (INVITE) (#9)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> <-------------------

> >>>>>= ;>>>>> 480 (INVITE (#10)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> A few things to note:

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> N1:        The 18x= does not contain the SE (Session-Expires)=

> header

> >>>>>= ;>>>>> field,<= /p>

> >>>>>= ;>>>>>         =      because according to section 4 of RFC 4028 the

> >>>>>= ;>>>>> header field is only=

> >>>>>= ;>>>>>         =      allowed in INVITE, UPDATE and 2xx. So, when the

> >>>>>= ;>>>>> UPDATE request=

> >>>>>= ;>>>>>         =      (#5) is sent, the initial session timer

> >>>>>= ;>>>>> negotiation is still=

> >>>>>= ;>>>>>         =      ongoing.

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> N2:        The UPD= ATE request (#5) contains a Session-Expires

> header

> >>>>>= ;>>>>> field.<= /p>

> >>>>>= ;>>>>>         =      Section 7.4 of RFC 4028 says:

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         = "In a session refresh request sent within a dialog with

> >>>>>= ;>>>>> an active

> >>>>>= ;>>>>>         =   session timer, the Session-Expires header field SHOULD

> >>>>>= ;>>>>> be present."

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>     Now, a dialog (early) HAS bee= n established when the UPDATE=

> >>>>>= ;>>> request is

> >>>>>= ;>>>>>         =      sent, but as the initial session timer

> >>>>>= ;>>>>> negotiation is still=

> >>>>>= ;>>>>>         =      ongoing, I assume the session timer isn=B9t yet

> >>>>>= ;>>>>> "active"?=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> N3:        The UPD= ATE 200 response (#7) does not contain the=

> >>>>>= ;>>>>> Session-Expires

> >>>>>= ;>>>>>         =      header field. It is added by the proxy, based on

> >>>>>= ;>>>>> the procedures in

> >>>>>= ;>>>>>         =      Section 8.2 of RFC 4028:> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =           "Because there = is no Session-Expires or

> >>>>>= ;>>>>> Require header field=

> >>>>>= ;>>>>>         =            in the respons= e, the proxy knows that it

> >>>>>= ;>>>>> is the first

> >>>>>= ;>>>>>         =            session-timer-= aware proxy to receive the

> >>>>>= ;>>>>> response.

> >>>>>= ;>>>>> This  proxy

> >>>>>= ;>>>>>         =            MUST insert a = Session-Expires header field<= /p>

> >>>>>= ;>>>>> into the response

> >>>>>= ;>>>>>         =            with the value= it remembered from the

> >>>>>= ;>>>>> forwarded request.=

> >>>>>= ;>>>>> It

> >>>>>= ;>>>>> MUST

> >>>>>= ;>>>>>         =            set the value = of The 'refresher' parameter<= /p>

> >>>>>= ;>>>>> to 'uac'.

> >>>>>= ;>>>>> The  proxy MUST=

> >>>>>= ;>>>>>         =            add the 'timer= ' option tag to any Require

> >>>>>= ;>>>>> header field in  the=

> >>>>>= ;>>>>>         =            response, and = if none was present, add the<= /p>

> >>>>>= ;>>>>> Require header  field with

> >>>>>= ;>>>>>         =            that value bef= ore forwarding it upstream."

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> Now, one could argue that the UA should include somet= hing in

> >>>>>= ;>>>>> the UPDATE response (#7), but I think that is not a s= olution

> >>>>>= ;>>>>> as the UA may be confused.

> >>>>>= ;>>>>> Instead, based on my understanding of the text in sec= tion 7.4

> >>>>>= ;>>>>> (see

> >>>>>= ;>>>>> above) the UPDATE request (#5) should not contain any=

> session

> >>>>>= ;>>>>> timer information. This is also more or less what the= errata

> >>>>>= ;>>>>> suggests.

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> Comments?

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> Regards,

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> Christer

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> _______________________________________________

> >>>>>= ;>>>>> sipcore mailing list=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>

> >>>>>= ;>>>> _______________________________________________

> >>>>>= ;>>>> sipcore mailing list

> >>>>>= ;>>>> mailto:sipcore@i= etf.org

> >>>>>= ;>>>

> >>>>>= ;>>> _______________________________________________

> >>>>>= ;>>> sipcore mailing list

> >>>>>= ;>>

> >>>>>= ;>

> >>>>>= ;> _______________________________________________

> >>>>>= ;> sipcore mailing list

> >>>>>= ;

> >>>>>= ; _______________________________________________> >>>>>= ; sipcore mailing list

> >>>>>= ;

> >>>>

> >>>> __= _____________________________________________

> >>>> si= pcore mailing list

> >>>=

> >>>=

> >>

> >

> >

>

> ___________________= ____________________________<= /p>

> sipcore mailing lis= t

 

--_000_FRAPR01MB04830E177CDF6CA24FBE7FF1F9740FRAPR01MB0483DEUP_-- From nobody Mon Oct 9 05:21:25 2017 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 2EEDD13451F for ; Mon, 9 Oct 2017 05:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnrrvZChK-Ds for ; Mon, 9 Oct 2017 05:21:18 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A3813451E for ; Mon, 9 Oct 2017 05:21:11 -0700 (PDT) X-AuditID: c1b4fb2d-fc3a89c00000268d-c2-59db69b509c1 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C2.3C.09869.5B96BD95; Mon, 9 Oct 2017 14:21:10 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 14:21:07 +0200 From: Christer Holmberg To: "Jesske, Roland" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: AW: AW: [sipcore] Session timer fix Thread-Index: AQHTQPkV+yv59qL0gUe+n7eLvKvq8A== Date: Mon, 9 Oct 2017 12:21:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D6013FFF2384Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdTHdb5u1Ig6OdzBYrNhxgtWi608Vm 8fXHJjYHZo+/7z8weSxZ8pPJo+2lQgBzFJdNSmpOZllqkb5dAlfG3h+r2Qq6V3JV3Hv5irmB cfFmzi5GTg4JAROJlu4DzF2MXBxCAkcYJea3LmYCSQgJLGSUOLlRq4uRg4NNwEKi+582SFhE oFLi+P9JbCC2sICBxPVFc5hBSkQEDCXm7uOEKNGT+PD6DjOIzSKgIvFs41ywcl4Ba4mVO76A xRkFxCS+n1oDtolZQFzi1pP5TBDnCEgs2XOeGcIWlXj5+B8riC0KNHPDidvsIKskBBQllvfL QbQmSPzf2QQ1XlDi5MwnLBMYhWYhmToLSdksJGUQcQOJI+duskLY2hLLFr5mhrD1JeYt2ABU wwFkW0t0z0tDVrKAkWMVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmA0HdzyW3cH4+rXjocY BTgYlXh4jVNuRwqxJpYVV+YeYpTgYFYS4V1mDhTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67Dv QoSQQHpiSWp2ampBahFMlomDU6qBUa/4isojA+kdisuSHyrcE+bcd9z/2af69vDHujt+lZ4v 2l7SWqfe1Fgg9/pM6b3o47+ea3iz121RdrHlq91iG/llU7rCvqgjVw/4clio7E9S3VP//saV h3sfhvLP33GNxyLrjZi8y5/+GYum/7tnnyeVVeeTOVHvXOktba2ZBof7dvMKOM30VmIpzkg0 1GIuKk4EAAoFspWiAgAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 12:21:24 -0000 --_000_D6013FFF2384Achristerholmbergericssoncom_ Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable Hi, >Ok it is not the outgoing proxy of the originating network that deletes th= e supported header. > >The outgoing proxy of the orig. network will keep the supported timer. But= the incoming proxy of the >intermediate network, which is also statefull will delete the supported ti= mer. Same apply for the backward direction. > >This is the typical interconnection usage. >So as I said this is a real issue we have. I understand. I just wonder why the Proxy removes the session-timer from si= gnalling, but still allows the session-timer UPDATE requests to pass. Norma= lly you remove something because you want to disable the functionality. But, in any case, I am not sure what can be done to solve the problem. Both= the UAC and UAS are told to generate session-timer updates. Regards, Christer Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Gesendet: Montag, 9. Oktober 2017 12:31 An: Jesske, Roland >; Paul = Kyzivat >; sipcore@ietf= .org Betreff: Re: AW: [sipcore] Session timer fix Hi Roland, Since the originating Proxy is anyway going to forward the Session-Timer UP= DATE requests, why does it remove =93SE; supp=94? Regards, Christer From: "R.Jesske@telekom.de" > Date: Monday 9 October 2017 at 12:34 To: "pkyzivat@alum.mit.edu" >, Christer Holmberg >, "sipcore@ietf.org" > Subject: AW: [sipcore] Session timer fix Hi, sorry but I have an further issue where we have problems with session timer= . It is the procedures of stateful Proxy Servers where we can cause a race co= ndition. We have made the observation that due to the rules we have race conditions = with using the session timer. The case is where we have transfer of SIP messages through an network that = is not supporting session timer. Originating network and UAC does support session timer. Intermediate network does not support session timer And the terminating network does support session timer. This may result with the following call flow. UAC Proxy Proxy UAS_2 | | | |-- INVITE -->| | | | SE; supp |-- INVITE -->|-- INVITE (2) ->| | | none | SE; supp | | | | | | |<-- 200 (2) ----| |<- 18x (2) --|<- 18x (2) --| SE 1800; | SE 1800; | | UAS | | UAC | | | |-- UPDATE -->| | | | |-- UPDATE -->| <-- UPDATE ----| | | | | | |<- UPDATE ---| --- UPDATE --->| |<- UPDATE ---| | | |-- 491 --->| |<-- 491 ----| | |-- 491 --->| | | |<-- 491 ----|--- 491 --->| |<-- 491 ----| | | This will happen when the session timer has the same length. How do we can solve such race conditions. I see the main problem within the= proxy behavior and the Forwarding of the UPDATE (or re-INVITE) for session refresh. Of course also the choice when the refresher shall sent the refresh may sol= ve the problem. But if the originating and terminating network is using the same software v= endor the refresh time will be the same. So seen from that kind of algorithm is needed to generate different session= refresh times. Do you see the same problems? Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Montag, 9. Oktober 2017 00:12 > An: Christer Holmberg >; sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix > > On 10/5/17 4:37 AM, Christer Holmberg wrote: > > Hi, > > > >>> =85 > >>> > >>>> I'll propose that the session timer negotiation never be done with > >>>> an UPDATE within an INVITE transaction. (Regardless of whether than > >>>> INVITE is negotiating a session timer or not.) I think this > >>>> resolves the problem that you have encountered. (Or we could > >>>> require that the UPDATE and response care consistent session timer > >>>> signaling with what is carried in the INVITE and its responses.) > >>> > >>> I had a chat with some product people, and they said that there > >>> actually ARE cases where the session timer is negotiated using > >>> UPDATE when the initial INVITE transaction is still ongoing. There > >>> are cases where the INVITE only contains Supported:timer, but the > >>> actual negotiation is done using UPDATE. > >> > >> Interesting! (I wonder why.) > > > > I haven=92t been able to figure out exactly why. I was just told the > > use-case exists. > > > > > >> That sequence itself presents some ambiguities. The way I have always > >> described how the session timer negotiation works is that *every* > >> INVITE and UPDATE transaction affects s-t - it either negotiates it > >> *on* or else it negotiates it *off*. (IMO this makes it very easy to > >> understand.) > >> > >> That presents issues when you have an update nested inside of an invit= e. > >> In the case you describe I might expect that the update would > >> negotiate the timer on, and then the completion of the invite would > >> negotiate it off again. > >> > >> How would the case you describe work if a proxy inserted S-E in INVITE= ? > >> In that case, the UAC doesn't know about it until the 2xx from the > >> invite. Before then it might try enabling a timer using UPDATE. > >> > >> I am inclined to keep things simple by saying that the 2xx response > >> to every INVITE or UPDATE redefines the state of the session timer, > >> either on or off. That will of course break the use case you describe > above. > > > > The problem here is that the UAC sends INVITE with S-E, and then > > receives an UPDATE with S-E before it has received a 2xx response to > > the INVITE - making the UAC think that there is a S-E glare situation > > (i.e., the UAS also tries to initiate session timer negotiation). > > Yes, I understand that is the case you are thinking of. But I was raising= a > different case: > > - the UAC sends an invite without a S-E. > - a proxy along the path includes an S-E. (The UAC is unaware.) > - later, the UAC sends an UPDATE with S-E. > > That violates the rule in your draft, but the UAC doesn't know it has vio= lated > it. So your rule for avoiding the problem in this case doesn't work. > > Thanks, > Paul > > > I think the RFC is pretty clear on how things work once the session > > timer has been negotiated (and, if it isn=92t, we for sure can clarify = that too). > > > > Regards, > > > > Christer > > > > > > > > > > > >>>>> > >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > >>>>> on behal= f of > >>>>> mailto:christer.holmberg@ericsson.com> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>>>> seen from my point of view the UAC should ignore the Session > >>>>>>>> timer proposal within the UPDATE. > >>>>>>>> As long as the negotiation is ongoing. > >>>>>>>> > >>>>>>>> Nevertheless we have also observed this curious session timer > >>>>>>>> behavior in our network. > >>>>>>>> > >>>>>>>> I think we need some clarifications to the RFC. Perhaps also to > >>>>>>>> other sections to make it more readable. > >>>>>>>> My experience is that people have problems in following how the > >>>>>>>> session timer should work within a complex SIP networks (e.g. > IMS). > >>>>>>>> > >>>>>>>> What is about updating the RFC4028. > >>>>>>> > >>>>>>> Like most of the older SIP RFCs, it probably deserves an update. > >>>>>>> The problem is whether going to the trouble will have any effect > >>>>>>> on implementations. I think the most we > should hope to do is > >>>>>>> *clarify* > >>>>>>> in > >>>>>>> cases where there is ambiguity, so that when interoperability > >>>>>>> problems arise it is clear who needs to change. > >>>>>> > >>>>>> Yes. In my case, implementation(s) WILL be changed. The question > >>>>>> is WHICH > >>>>>> implementation(s) :) > >>>>>> > >>>>>> So, my suggestion would be: > >>>>>> > >>>>>> 1) Specify/clarify that SE must not be sent during session-tim= er > >>>>>> negotiation > >>>>>> 2) Specify that one must send a 491 (or some other more > appropriate > >>>>>> code) > >>>>>> response if receiving SE during session-timer negotiation > >>>>>> > >>>>>> For the above, I think we can do it using an errata. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Christer > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von > >>>>>>>> Christer Holmberg > >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 > >>>>>>>> An: Paul Kyzivat ; mailto:sipcore@= ietf.org > >>>>>>>> Betreff: Re: [sipcore] Session-timer issue > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>>>> The following issue has been around for some time already > >>>>>>>>>> (there is also an errata #4744), and as it causes problems > >>>>>>>>>> (the INVITE is rejected with a > >>>>>>>>>> 480 response) in deployed networks, so I think it needs to be > >>>>>>>>>> fixed. > >>>>>>>>>> People seem to have different opinions on which node is > >>>>>>>>>> acting wrongly, so I hope we can sort it out :) > >>>>>>>>> > >>>>>>>>> This is an interesting problem. I agree that it is unclear > >>>>>>>>> exactly what ought to happen in this case. (But I don't > >>>>>>>>> understand why someone thinks a 480 is a good way to resolve > >>>>>>>>> it.) > >>>>>>>> > >>>>>>>> Whether 480 is the best solution or not is not the issue, in my > >>>>>>>> opinion. > >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. > >>>>>>>> > >>>>>>>> The issue is that there is a session-timer negotiation "race > >>>>>>>> condition", and we should forbid that (rejecting the UPDATE > >>>>>>>> could be part of such solution). > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Christer > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>>> Below is a call flow showing the problem: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> UA Proxy AS > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> INVITE (#1) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> INVITE (#2) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 18x (#3) > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 18x (#4) > >>>>>>>>>> > >>>>>>>>>> ++++++ early dialog established +++++++ > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> UPDATE (#5) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duas > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> UPDATE (#6) > >>>>>>>>>> Supported:timer > >>>>>>>>>> SE:refresher=3Duas > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> 200 (UPDATE) (#7) > >>>>>>>>>> > >>>>>>>>>> -------------------> > >>>>>>>>>> 200 (UPDATE) (#8) > >>>>>>>>>> Require:timer > >>>>>>>>>> SE:refresher=3Duac > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 480 (INVITE) (#9) > >>>>>>>>>> > >>>>>>>>>> <------------------- > >>>>>>>>>> 480 (INVITE (#10) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> A few things to note: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N1: The 18x does not contain the SE (Session-Expires) > header > >>>>>>>>>> field, > >>>>>>>>>> because according to section 4 of RFC 4028 the > >>>>>>>>>> header field is only > >>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the > >>>>>>>>>> UPDATE request > >>>>>>>>>> (#5) is sent, the initial session timer > >>>>>>>>>> negotiation is still > >>>>>>>>>> ongoing. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N2: The UPDATE request (#5) contains a Session-Expires > header > >>>>>>>>>> field. > >>>>>>>>>> Section 7.4 of RFC 4028 says: > >>>>>>>>>> > >>>>>>>>>> "In a session refresh request sent within a dialog wi= th > >>>>>>>>>> an active > >>>>>>>>>> session timer, the Session-Expires header field SHOU= LD > >>>>>>>>>> be present." > >>>>>>>>>> > >>>>>>>>>> Now, a dialog (early) HAS been established when the UPDATE > >>>>>>>> request is > >>>>>>>>>> sent, but as the initial session timer > >>>>>>>>>> negotiation is still > >>>>>>>>>> ongoing, I assume the session timer isn=B9t yet > >>>>>>>>>> "active"? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain the > >>>>>>>>>> Session-Expires > >>>>>>>>>> header field. It is added by the proxy, based on > >>>>>>>>>> the procedures in > >>>>>>>>>> Section 8.2 of RFC 4028: > >>>>>>>>>> > >>>>>>>>>> "Because there is no Session-Expires or > >>>>>>>>>> Require header field > >>>>>>>>>> in the response, the proxy knows that it > >>>>>>>>>> is the first > >>>>>>>>>> session-timer-aware proxy to receive the > >>>>>>>>>> response. > >>>>>>>>>> This proxy > >>>>>>>>>> MUST insert a Session-Expires header field > >>>>>>>>>> into the response > >>>>>>>>>> with the value it remembered from the > >>>>>>>>>> forwarded request. > >>>>>>>>>> It > >>>>>>>>>> MUST > >>>>>>>>>> set the value of The 'refresher' parameter > >>>>>>>>>> to 'uac'. > >>>>>>>>>> The proxy MUST > >>>>>>>>>> add the 'timer' option tag to any Require > >>>>>>>>>> header field in the > >>>>>>>>>> response, and if none was present, add the > >>>>>>>>>> Require header field with > >>>>>>>>>> that value before forwarding it upstream." > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Now, one could argue that the UA should include something in > >>>>>>>>>> the UPDATE response (#7), but I think that is not a solution > >>>>>>>>>> as the UA may be confused. > >>>>>>>>>> Instead, based on my understanding of the text in section 7.4 > >>>>>>>>>> (see > >>>>>>>>>> above) the UPDATE request (#5) should not contain any > session > >>>>>>>>>> timer information. This is also more or less what the errata > >>>>>>>>>> suggests. > >>>>>>>>>> > >>>>>>>>>> Comments? > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> Christer > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> sipcore mailing list > >>>>>>>>>> mailto:sipcore@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> sipcore mailing list > >>>>>>>>> mailto:sipcore@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> sipcore mailing list > >>>>>>>> mailto:sipcore@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sipcore mailing list > >>>>>> mailto:sipcore@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> mailto:sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> mailto:sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > >> > > > > > > _______________________________________________ > sipcore mailing list > mailto:sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_D6013FFF2384Achristerholmbergericssoncom_ Content-Type: text/html; charset="windows-1254" Content-ID: <9CB4D4F2E3954E4993396A4D49BB71EA@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>Ok it= is not the outgoing proxy of the originating network that deletes the supp= orted header.
>

>The outgoing proxy of the o= rig. network will keep the supported timer. But the incoming proxy of the
>inter= mediate network, which is also statefull will delete the supported timer. S= ame apply for the backward direction.

> 

>This is the typical interco= nnection usage.

>So as I said this is a real= issue we have.

&nbs= p;
I understand. I just wonder why the Proxy removes the session-timer fr= om signalling, but still allows the session-timer UPDATE requests to pass. = Normally you remove something because you want to disable the functionality= .

But, in any case, I am not sure what can be done to solve the problem.= Both the UAC and UAS are told to generate session-timer updates.

Regards,

Christer


Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com= ]
Gesendet: Montag, 9. Oktober 2017 12:31
An: Jesske, Roland <R.Jess= ke@telekom.de>; Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
Betreff: Re: AW: [sipcore] Session timer fix

 

Hi Roland,

 =

Since the originating Pr= oxy is anyway going to forward the Session-Timer UPDATE requests, why does = it remove =93SE; supp=94? 

 =

Regards,

 =

Christer

 =

From: "R.Jesske@telekom.de" <R.Jesske= @telekom.de>
Date: Monday 9 October 2017 at 12:34
To: "pkyzivat@alum.mit.edu" <pkyziv= at@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>, "sipcore@i= etf.org" <sipcore@ietf.org>
Subject: AW: [sipcore] Session timer fix

 =

Hi,

sorry but I have an further iss= ue where we have problems with session timer.

It is the procedures of statefu= l Proxy Servers where we can cause a race condition.

 

We have made the observation th= at due to the rules we have race conditions with using the session timer.

 

The case is where we have trans= fer of SIP messages through an network that is not supporting session timer= .

 

Originating network and UAC doe= s support session timer.

Intermediate network does not s= upport session timer

And the terminating network doe= s support session timer.

 

This may result with the follow= ing call flow.

 

UAC    &nbs= p;      Proxy       =     Proxy         UAS_2&n= bsp; 

   |   = ;             &= nbsp;          |   &= nbsp;            | &= nbsp;           &nbs= p; 

   |-- INVITE -->|=              |&= nbsp;           &nbs= p;   |     

   |   = ; SE; supp |-- INVITE -->|-- INVITE (2) ->|    &n= bsp; 

   |   = ;          |   = none     |    SE; supp   = ;

   |   = ;          |   =           |   &= nbsp;            |

   |   = ;          |   =           |<-- 200 (2) ----= |      

   |<- 18x (2) --|= <- 18x (2) --|    SE 1800;

   |   SE 1800;&= nbsp; |             = |      UAS       |&n= bsp;  

   |   = ;  UAC     |      &n= bsp;      |      &nb= sp;         |   &nbs= p;  

   |-- UPDATE -->|=              |&= nbsp;           &nbs= p;   |     

   |   = ;         |-- UPDATE -->| <-- UPDA= TE ----|        

   |   = ;          |   =           |   &= nbsp;            |

  |    &nbs= p;       |<- UPDATE ---| --- UPDATE --->= ;|

   |<- UPDATE ---|=              |&= nbsp;           &nbs= p;   |      

   |-- 491   ---= >|           &nbs= p; |<-- 491     ----|      =        

   |   = ;          |-- 491   ---&= gt;|            = ;    |

   |   = ;          |<-- 491 ----|--= - 491   --->|

   |<-- 491 ----|&= nbsp;            |&n= bsp;            = ;   |

 

 

 

This will happen when the sessi= on timer has the same length.

How do we can solve such race c= onditions. I see the main problem within the proxy behavior and the

Forwarding of the UPDATE (or re= -INVITE) for session refresh.

 

Of course also the choice when = the refresher shall sent the refresh may solve the problem.

But if the originating and term= inating network is using the same software vendor the refresh time will be = the same.

So seen from that kind of algor= ithm is needed to generate different session refresh times.

 

Do you see the same problems?

 

Thank you and Best Regards=

 

Roland

 

 

 

 

 

 

     &= nbsp;  

 

> -----Urspr=FCngliche Nachricht----= -

> Von: sipcore [mailto:sipcore-bounces@ietf.org<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:black">] Im Auftrag von Paul Kyzivat

> Gesendet: Montag, 9. Oktober 2017 = 00:12

> An: Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsso= n.com>; sipcore@ietf.org> Betreff: Re: [sipco= re] Session timer fix

>

> On 10/5/17 4:37 AM,= Christer Holmberg wrote:

> > Hi,

> >

> >>> =85

> >>>=

> >>>> I'= ll propose that the session timer negotiation never be done with

> >>>> an= UPDATE within an INVITE transaction. (Regardless of whether than

> >>>> IN= VITE is negotiating a session timer or not.) I think this

> >>>> re= solves the problem that you have encountered. (Or we could

> >>>> re= quire that the UPDATE and response care consistent session timer

> >>>> si= gnaling with what is carried in the INVITE and its responses.)

> >>>=

> >>> I had = a chat with some product people, and they said that there

> >>> actual= ly ARE cases where the session timer is negotiated using

> >>> UPDATE= when the initial INVITE transaction is still ongoing. There

> >>> are ca= ses where the INVITE only contains Supported:timer, but the

> >>> actual= negotiation is done using UPDATE.

> >>

> >> Interestin= g! (I wonder why.)

> >

> > I haven=92t be= en able to figure out exactly why. I was just told the

> > use-case exist= s.

> >

> >

> >> That seque= nce itself presents some ambiguities. The way I have always

> >> described = how the session timer negotiation works is that *every*

> >> INVITE and= UPDATE transaction affects s-t - it either negotiates it

> >> *on* or el= se it negotiates it *off*. (IMO this makes it very easy to

> >> understand= .)

> >>

> >> That prese= nts issues when you have an update nested inside of an invite.

> >> In the cas= e you describe I might expect that the update would

> >> negotiate = the timer on, and then the completion of the invite would

> >> negotiate = it off again.

> >>

> >> How would = the case you describe work if a proxy inserted S-E in INVITE?

> >> In that ca= se, the UAC doesn't know about it until the 2xx from the

> >> invite. Be= fore then it might try enabling a timer using UPDATE.

> >>

> >> I am incli= ned to keep things simple by saying that the 2xx response

> >> to every I= NVITE or UPDATE redefines the state of the session timer,

> >> either on = or off. That will of course break the use case you describe

> above.

> >

> > The problem he= re is that the UAC sends INVITE with S-E, and then

> > receives an UP= DATE with S-E before it has received a 2xx response to

> > the INVITE - m= aking the UAC think that there is a S-E glare situation

> > (i.e., the UAS= also tries to initiate session timer negotiation).

>

> Yes, I understand t= hat is the case you are thinking of. But I was raising a

> different case:

>

> - the UAC sends an = invite without a S-E.

> - a proxy along the= path includes an S-E. (The UAC is unaware.)

> - later, the UAC se= nds an UPDATE with S-E.

>

> That violates the r= ule in your draft, but the UAC doesn't know it has violated

> it. So your rule fo= r avoiding the problem in this case doesn't work.>

>   &n= bsp;    Thanks,

>   &n= bsp;    Paul

>

> > I think the RF= C is pretty clear on how things work once the session

> > timer has been= negotiated (and, if it isn=92t, we for sure can clarify that too).<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Courier New= ";color:black">

> >

> > Regards,

> >

> > Christer

> >

> >

> >

> >

> >

> >>>>>= ;

> >>>>>= ; On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg"

> >>>>>= ; <si= pcore-bounces@ietf.org on behalf of

> >>>>>= ; wrote:

> >>>>>= ;

> >>>>>= ;> Hi,

> >>>>>= ;>

> >>>>>= ;>>> seen from my point of view the UAC should ignore the Session<= /span>

> >>>>>= ;>>> timer proposal within the UPDATE.=

> >>>>>= ;>>> As long as the negotiation is  ongoing.

> >>>>>= ;>>>

> >>>>>= ;>>> Nevertheless we have also observed this curious session timer=

> >>>>>= ;>>> behavior in our network.

> >>>>>= ;>>>

> >>>>>= ;>>> I think we need some clarifications to the RFC. Perhaps also = to

> >>>>>= ;>>> other sections to make it more readable.

> >>>>>= ;>>> My experience is that people have problems in following how t= he

> >>>>>= ;>>> session timer should work within a complex SIP networks (e.g.=

> IMS).

> >>>>>= ;>>>

> >>>>>= ;>>> What is about updating the RFC4028.> >>>>>= ;>>

> >>>>>= ;>> Like most of the older SIP RFCs, it probably deserves an update.<= /span>

> >>>>>= ;>> The problem is whether going to the trouble will have any effect<= /span>

> >>>>>= ;>> on implementations. I think the most we > should hope to do is=

> >>>>>= ;>> *clarify*

> >>>>>= ;>> in

> >>>>>= ;>> cases where there is ambiguity, so that when interoperability

> >>>>>= ;>> problems arise it is clear who needs to change.

> >>>>>= ;>

> >>>>>= ;> Yes. In my case, implementation(s) WILL be changed. The question

> >>>>>= ;> is WHICH

> >>>>>= ;> implementation(s) :)

> >>>>>= ;>

> >>>>>= ;> So, my suggestion would be:

> >>>>>= ;>

> >>>>>= ;> 1)     Specify/clarify that SE must not be sent d= uring session-timer

> >>>>>= ;> negotiation

> >>>>>= ;> 2)     Specify that one must send a 491 (or some = other more

> appropriate<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Courier New= ";color:black">

> >>>>>= ;> code)

> >>>>>= ;> response if receiving SE during session-timer negotiation

> >>>>>= ;>

> >>>>>= ;> For the above, I think we can do it using an errata.

> >>>>>>

> >>>>>> Regards,<= /span>

> >>>>>>

> >>>>>> Christer<= /span>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>>> -= ----Urspr=FCngliche Nachricht-----

> >>>>>>>> V= on: sipcore [mailto:sip= core-bounces@ietf.org] Im Auftrag von

> >>>>>>>> C= hrister Holmberg

> >>>>>>>> G= esendet: Donnerstag, 7. September 2017 11:34=

> >>>>>= ;>>> Betreff: Re: [sipcore] Session-timer issue

> >>>>>= ;>>>

> >>>>>= ;>>> Hi,

> >>>>>= ;>>>

> >>>>>= ;>>>>> The following issue has been around for some time alr= eady

> >>>>>= ;>>>>> (there is also  an errata #4744), and as it caus= es problems

> >>>>>= ;>>>>> (the INVITE is rejected with a

> >>>>>= ;>>>>> 480 response) in deployed networks, so I think it nee= ds to be

> >>>>>= ;>>>>> fixed.<= /p>

> >>>>>= ;>>>>> People seem to have different opinions on which node = is

> >>>>>= ;>>>>> acting wrongly, so  I hope we can sort it out :)=

> >>>>>= ;>>>>

> >>>>>= ;>>>> This is an interesting problem. I agree that it is unclea= r

> >>>>>= ;>>>> exactly what ought to happen in this case. (But I don't

> >>>>>= ;>>>> understand why someone thinks a 480 is a good way to reso= lve

> >>>>>= ;>>>> it.)

> >>>>>= ;>>>

> >>>>>= ;>>> Whether 480 is the best solution or not is not the issue, in = my

> >>>>>= ;>>> opinion.

> >>>>>= ;>>> One could also claim that the UPDATE should be rejected. Etc.=

> >>>>>= ;>>>

> >>>>>= ;>>> The issue is that there is a session-timer negotiation "= race

> >>>>>= ;>>> condition", and we should forbid that (rejecting the UPD= ATE

> >>>>>= ;>>> could be part of such solution).<= o:p>

> >>>>>= ;>>>

> >>>>>= ;>>> Regards,

> >>>>>= ;>>>

> >>>>>= ;>>> Christer

> >>>>>= ;>>>

> >>>>>= ;>>>

> >>>>>= ;>>>

> >>>>>= ;>>>

> >>>>>= ;>>>

> >>>>>= ;>>>>

> >>>>>= ;>>>>      Thanks,

> >>>>>= ;>>>>      Paul

> >>>>>= ;>>>>

> >>>>>= ;>>>>> Below is a call flow showing the problem:

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> UA        &nb= sp;       Proxy     =            AS

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> ------------------->

> >>>>>= ;>>>>> INVITE (#1)

> >>>>>= ;>>>>> Supported:timer

> >>>>>&g= t;>>>> SE:refresher=3Duac

> >>>>>&g= t;>>>>

> >>>>>&g= t;>>>>         &nb= sp;            =     ------------------->

> >>>>>&g= t;>>>>         &nb= sp;            =     INVITE (#2)

> >>>>>&g= t;>>>>         &nb= sp;            =     Supported:timer

> >>>>>&g= t;>>>>         &nb= sp;            =     SE:refresher=3Duac

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =             &nb= sp;    <-------------------

> >>>>>= ;>>>>>         =             &nb= sp;    18x (#3)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> <-------------------

> >>>>>= ;>>>>> 18x (#4)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> ++++++ early dialog establish= ed +++++++

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =             &nb= sp;    <-------------------

> >>>>>= ;>>>>>         =             &nb= sp;    UPDATE (#5)

> >>>>>= ;>>>>>         =             &nb= sp;    Supported:timer

> >>>>>= ;>>>>>         =             &nb= sp;    SE:refresher=3Duas=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> <-------------------

> >>>>>= ;>>>>> UPDATE (#6)

> >>>>>= ;>>>>> Supported:timer

> >>>>>= ;>>>>> SE:refresher=3Duas=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> ------------------->

> >>>>>= ;>>>>> 200 (UPDATE) (#7)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =             &nb= sp;    ------------------->

> >>>>>= ;>>>>>         =             &nb= sp;    200 (UPDATE) (#8)

> >>>>>= ;>>>>>         =             &nb= sp;    Require:timer<= /span>

> >>>>>= ;>>>>>         =             &nb= sp;    SE:refresher=3Duac=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =             &nb= sp;    <-------------------

> >>>>>= ;>>>>>         =             &nb= sp;    480 (INVITE) (#9)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> <-------------------

> >>>>>= ;>>>>> 480 (INVITE (#10)

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> A few things to note:

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> N1:        The 18x= does not contain the SE (Session-Expires)=

> header

> >>>>>= ;>>>>> field,<= /p>

> >>>>>= ;>>>>>         =      because according to section 4 of RFC 4028 the

> >>>>>= ;>>>>> header field is only=

> >>>>>= ;>>>>>         =      allowed in INVITE, UPDATE and 2xx. So, when the

> >>>>>= ;>>>>> UPDATE request=

> >>>>>= ;>>>>>         =      (#5) is sent, the initial session timer

> >>>>>= ;>>>>> negotiation is still=

> >>>>>= ;>>>>>         =      ongoing.

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> N2:        The UPD= ATE request (#5) contains a Session-Expires

> header

> >>>>>= ;>>>>> field.<= /p>

> >>>>>= ;>>>>>         =      Section 7.4 of RFC 4028 says:

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         = "In a session refresh request sent within a dialog with

> >>>>>= ;>>>>> an active

> >>>>>= ;>>>>>         =   session timer, the Session-Expires header field SHOULD

> >>>>>= ;>>>>> be present."

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>     Now, a dialog (early) HAS bee= n established when the UPDATE=

> >>>>>= ;>>> request is

> >>>>>= ;>>>>>         =      sent, but as the initial session timer

> >>>>>= ;>>>>> negotiation is still=

> >>>>>= ;>>>>>         =      ongoing, I assume the session timer isn=B9t yet

> >>>>>= ;>>>>> "active"?=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> N3:        The UPD= ATE 200 response (#7) does not contain the=

> >>>>>= ;>>>>> Session-Expires

> >>>>>= ;>>>>>         =      header field. It is added by the proxy, based on

> >>>>>= ;>>>>> the procedures in

> >>>>>= ;>>>>>         =      Section 8.2 of RFC 4028:> >>>>>= ;>>>>>

> >>>>>= ;>>>>>         =           "Because there = is no Session-Expires or

> >>>>>= ;>>>>> Require header field=

> >>>>>= ;>>>>>         =            in the respons= e, the proxy knows that it

> >>>>>= ;>>>>> is the first

> >>>>>= ;>>>>>         =            session-timer-= aware proxy to receive the

> >>>>>= ;>>>>> response.

> >>>>>= ;>>>>> This  proxy

> >>>>>= ;>>>>>         =            MUST insert a = Session-Expires header field<= /p>

> >>>>>= ;>>>>> into the response

> >>>>>= ;>>>>>         =            with the value= it remembered from the

> >>>>>= ;>>>>> forwarded request.=

> >>>>>= ;>>>>> It

> >>>>>= ;>>>>> MUST

> >>>>>= ;>>>>>         =            set the value = of The 'refresher' parameter<= /p>

> >>>>>= ;>>>>> to 'uac'.

> >>>>>= ;>>>>> The  proxy MUST=

> >>>>>= ;>>>>>         =            add the 'timer= ' option tag to any Require

> >>>>>= ;>>>>> header field in  the=

> >>>>>= ;>>>>>         =            response, and = if none was present, add the<= /p>

> >>>>>= ;>>>>> Require header  field with

> >>>>>= ;>>>>>         =            that value bef= ore forwarding it upstream."

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> Now, one could argue that the UA should include somet= hing in

> >>>>>= ;>>>>> the UPDATE response (#7), but I think that is not a s= olution

> >>>>>= ;>>>>> as the UA may be confused.

> >>>>>= ;>>>>> Instead, based on my understanding of the text in sec= tion 7.4

> >>>>>= ;>>>>> (see

> >>>>>= ;>>>>> above) the UPDATE request (#5) should not contain any=

> session

> >>>>>= ;>>>>> timer information. This is also more or less what the= errata

> >>>>>= ;>>>>> suggests.

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> Comments?

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> Regards,

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> Christer

> >>>>>= ;>>>>>

> >>>>>= ;>>>>>

> >>>>>= ;>>>>> _______________________________________________

> >>>>>= ;>>>>> sipcore mailing list=

> >>>>>= ;>>>>>

> >>>>>= ;>>>>

> >>>>>= ;>>>> _______________________________________________

> >>>>>= ;>>>> sipcore mailing list

> >>>>>= ;>>>> mailto:sipcore@i= etf.org

> >>>>>= ;>>>

> >>>>>= ;>>> _______________________________________________

> >>>>>= ;>>> sipcore mailing list

> >>>>>= ;>>

> >>>>>= ;>

> >>>>>= ;> _______________________________________________

> >>>>>= ;> sipcore mailing list

> >>>>>= ;

> >>>>>= ; _______________________________________________> >>>>>= ; sipcore mailing list

> >>>>>= ;

> >>>>

> >>>> __= _____________________________________________

> >>>> si= pcore mailing list

> >>>=

> >>>=

> >>

> >

> >

>

> ___________________= ____________________________<= /p>

> sipcore mailing lis= t

 

 --_000_D6013FFF2384Achristerholmbergericssoncom_-- From nobody Mon Oct 9 06:49:00 2017 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 A576D134220 for ; Mon, 9 Oct 2017 06:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9GW2w-ELK5g for ; Mon, 9 Oct 2017 06:48:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6F4D0134531 for ; Mon, 9 Oct 2017 06:48:56 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-29-59db7e4697c6 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.F0.03220.64E7BD95; Mon, 9 Oct 2017 15:48:54 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 15:48:54 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new: draft-sip-push-00 Thread-Index: AQHTQQVYKHAx7ZVjvkqN9Wloadjynw== Date: Mon, 9 Oct 2017 13:48:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2J7lK5b3e1Igx0P1Cy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujInNZxgLNrNUHJ55g6mB8ThzFyMnh4SAicSpRcuYuhi5OIQE jjBKLG87yQrhLGSUWLL4K1CGg4NNwEKi+582SIOIgKbE8m9b2UHCwgKqEsufS0KEtSRezprK CmHrSaybdI0dxGYRUJG4/+UXWJxXwFri/ax7YHFGATGJ76fWMIHYzALiEreezGeCuEdAYsme 81C3iUq8fPwPrFcUaOaGE7fZIeJKEj82XGKB6NWTuDF1ChuEbS2xdt89KFtbYtnC18wQewUl Ts58wjKBUWQWknWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIE RsTBLb9VdzBefuN4iFGAg1GJh7cs/XakEGtiWXFl7iFGCQ5mJRHe6kqgEG9KYmVValF+fFFp TmrxIUZpDhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYzm6yTdX69dtZ05dJngs3z74snu fDsZ45xYQuK3L9DYFF1ocPX5DLk/PIXFidMWLL2cft2TL0EnfXJj4oZodZ2tGje++Dp/lBUK 1Mzd7Gb3uLuj72NDw2u1mkpeKSf1nUx2tdGrTPwVzXwDPQ95uxzl8qrLmV/iNrF2gsnaYI4L j7aentkwR4mlOCPRUIu5qDgRAOQdsE+EAgAA Archived-At: Subject: [sipcore] Draft new: draft-sip-push-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 13:48:59 -0000 Hi, Since I did not hear anything from the author of draft-ivanov-sipcore-pnsip, I=B9ve submitted a draft (draft-holmberg-sipcore-sip-push) which is based on that draft. The holmberg draft contains more text, based on the list discussions and comments. One thing to note: while looking into different push notification services, at least 2 commonly used ones do NOT provide a URI as the subscription token. So, I=B9ve kept the pn-type parameter, in order to provide guidance on which push notification service is used. Regards, Christer From nobody Mon Oct 9 07:18:52 2017 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 9E9E11321AC for ; Mon, 9 Oct 2017 07:18:50 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH1T04yGjAod for ; Mon, 9 Oct 2017 07:18:48 -0700 (PDT) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7A1342D4 for ; Mon, 9 Oct 2017 07:18:47 -0700 (PDT) X-AuditID: 12074414-0ebff70000006ddf-84-59db85452d80 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B7.87.28127.5458BD95; Mon, 9 Oct 2017 10:18:45 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v99EIhvU006097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Oct 2017 10:18:44 -0400 To: "Jesske, Roland" , Christer Holmberg , "sipcore@ietf.org" References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> From: Paul Kyzivat Message-ID: <9cd95809-7388-9b8c-8070-83a1ba918b53@alum.mit.edu> Date: Mon, 9 Oct 2017 10:18:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 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-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYndR1HVtvR1psOm4osWFmYcZLZrudLFZ fP2xic2B2ePX16tsHkuW/GTyaHupEMAcxWWTkpqTWZZapG+XwJUx/+B99oLX9RW//l1gaWBc nNnFyMkhIWAiceHFdtYuRi4OIYEdTBLLD/WyQzgPmCT2PexiBKkSFtCR2Pn1OAtIQkRgOqPE hreH2EASQgKHGSWefEoCsdkEtCTmHPrPAmLzCthLLJl6AKyGRUBF4t31PcwgtqhAmsS/3WcZ IWoEJU7OfAJWzykQI7H+3WV2EJtZwFbiztzdzBC2uMStJ/OZIGx5ieats5knMPLPQtI+C0nL LCQts5C0LGBkWcUol5hTmqubm5iZU5yarFucnJiXl1qka6GXm1mil5pSuokREr4iOxiPnJQ7 xCjAwajEw9sw7VakEGtiWXFl7iFGSQ4mJVHe+c23I4X4kvJTKjMSizPii0pzUosPMUpwMCuJ 8D5pAsrxpiRWVqUW5cOkpDlYlMR5vy1W9xMSSE8sSc1OTS1ILYLJynBwKEnwqrYANQoWpaan VqRl5pQgpJk4OEGG8wANtwap4S0uSMwtzkyHyJ9i1OXo6bnxh0mIJS8/L1VKnLcJpEgApCij NA9uDiztvGIUB3pLmHc+SBUPMGXBTXoFtIQJaAlj8Q2QJSWJCCmpBsa43q0RXe+aPjeednCP 9/h2xeL/Ht2nTnLGolfMKlSn9DsoZiQInrHZ4soZ+/uxxtVz+05Vlfl2bz3711D2dfHEw5KO 037rylbbLq0L7P5/qSG7p0wlqSih+begdeXJExs0Jm+afYRp0w2HR3P0E89tMGJi2hDE9jvg 8PwiDdu5CRe/LtWaY6vEUpyRaKjFXFScCABYBNsqFgMAAA== Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 14:18:50 -0000 On 10/9/17 5:34 AM, Jesske, Roland wrote: > Hi, > sorry but I have an further issue where we have problems with session timer. > It is the procedures of stateful Proxy Servers where we can cause a race > condition. > We have made the observation that due to the rules we have race > conditions with using the session timer. > The case is where we have transfer of SIP messages through an network > that is not supporting session timer. > Originating network and UAC does support session timer. > Intermediate network does not support session timer > And the terminating network does support session timer. > This may result with the following call flow. > UAC           Proxy           Proxy         UAS_2 >    |                           |                | >    |-- INVITE -->|             |                | >    |    SE; supp |-- INVITE -->|-- INVITE (2) ->| >    |             |    none     |    SE; supp IIUC you are saying that Proxy1 *removes* the SE and the timer option from the request before forwarding it. Do I have that right? That is more that "not supporting" session timer - that is actively interfering with the feature. This is non-compliant behavior for a proxy. A correctly functioning proxy will, if it doesn't understand the option and the header, just pass them along as received. The procedures specified for session timer will work properly in that case. Thanks, Paul >    |             |             |                | >    |             |             |<-- 200 (2) ----| >    |<- 18x (2) --|<- 18x (2) --|    SE 1800; >    |   SE 1800;  |             |      UAS       | >    |     UAC     |             |                | >    |-- UPDATE -->|             |                | >    |            |-- UPDATE -->| <-- UPDATE ----| >    |             |             |                | >   |            |<- UPDATE ---| --- UPDATE --->| >    |<- UPDATE ---|             |                | >    |-- 491   --->|             |<-- 491     ----| >    |             |-- 491   --->|                | >    |             |<-- 491 ----|--- 491   --->| >    |<-- 491 ----|             |                | > This will happen when the session timer has the same length. > How do we can solve such race conditions. I see the main problem within > the proxy behavior and the > Forwarding of the UPDATE (or re-INVITE) for session refresh. > Of course also the choice when the refresher shall sent the refresh may > solve the problem. > But if the originating and terminating network is using the same > software vendor the refresh time will be the same. > So seen from that kind of algorithm is needed to generate different > session refresh times. > Do you see the same problems? > Thank you and Best Regards > Roland >> -----Ursprüngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat >> Gesendet: Montag, 9. Oktober 2017 00:12 >> An: Christer Holmberg ; sipcore@ietf.org >> Betreff: Re: [sipcore] Session timer fix >> >> On 10/5/17 4:37 AM, Christer Holmberg wrote: >> > Hi, >> > >> >>> … >> >>> >> >>>> I'll propose that the session timer negotiation never be done with >> >>>> an UPDATE within an INVITE transaction. (Regardless of whether than >> >>>> INVITE is negotiating a session timer or not.) I think this >> >>>> resolves the problem that you have encountered. (Or we could >> >>>> require that the UPDATE and response care consistent session timer >> >>>> signaling with what is carried in the INVITE and its responses.) >> >>> >> >>> I had a chat with some product people, and they said that there >> >>> actually ARE cases where the session timer is negotiated using >> >>> UPDATE when the initial INVITE transaction is still ongoing. There >> >>> are cases where the INVITE only contains Supported:timer, but the >> >>> actual negotiation is done using UPDATE. >> >> >> >> Interesting! (I wonder why.) >> > >> > I haven’t been able to figure out exactly why. I was just told the >> > use-case exists. >> > >> > >> >> That sequence itself presents some ambiguities. The way I have always >> >> described how the session timer negotiation works is that *every* >> >> INVITE and UPDATE transaction affects s-t - it either negotiates it >> >> *on* or else it negotiates it *off*. (IMO this makes it very easy to >> >> understand.) >> >> >> >> That presents issues when you have an update nested inside of an invite. >> >> In the case you describe I might expect that the update would >> >> negotiate the timer on, and then the completion of the invite would >> >> negotiate it off again. >> >> >> >> How would the case you describe work if a proxy inserted S-E in INVITE? >> >> In that case, the UAC doesn't know about it until the 2xx from the >> >> invite. Before then it might try enabling a timer using UPDATE. >> >> >> >> I am inclined to keep things simple by saying that the 2xx response >> >> to every INVITE or UPDATE redefines the state of the session timer, >> >> either on or off. That will of course break the use case you describe >> above. >> > >> > The problem here is that the UAC sends INVITE with S-E, and then >> > receives an UPDATE with S-E before it has received a 2xx response to >> > the INVITE - making the UAC think that there is a S-E glare situation >> > (i.e., the UAS also tries to initiate session timer negotiation). >> >> Yes, I understand that is the case you are thinking of. But I was raising a >> different case: >> >> - the UAC sends an invite without a S-E. >> - a proxy along the path includes an S-E. (The UAC is unaware.) >> - later, the UAC sends an UPDATE with S-E. >> >> That violates the rule in your draft, but the UAC doesn't know it has violated >> it. So your rule for avoiding the problem in this case doesn't work. >> >>        Thanks, >>        Paul >> >> > I think the RFC is pretty clear on how things work once the session >> > timer has been negotiated (and, if it isn’t, we for sure can clarify that too). >> > >> > Regards, >> > >> > Christer >> > >> > >> > >> > >> > >> >>>>> >> >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >> >>>>> > >>>>> mailto:christer.holmberg@ericsson.com> >> >>>>> wrote: >> >>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>>>> seen from my point of view the UAC should ignore the Session >> >>>>>>>> timer proposal within the UPDATE. >> >>>>>>>> As long as the negotiation is  ongoing. >> >>>>>>>> >> >>>>>>>> Nevertheless we have also observed this curious session timer >> >>>>>>>> behavior in our network. >> >>>>>>>> >> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also to >> >>>>>>>> other sections to make it more readable. >> >>>>>>>> My experience is that people have problems in following how the >> >>>>>>>> session timer should work within a complex SIP networks (e.g. >> IMS). >> >>>>>>>> >> >>>>>>>> What is about updating the RFC4028. >> >>>>>>> >> >>>>>>> Like most of the older SIP RFCs, it probably deserves an update. >> >>>>>>> The problem is whether going to the trouble will have any effect >> >>>>>>> on implementations. I think the most we > should hope to do is >> >>>>>>> *clarify* >> >>>>>>> in >> >>>>>>> cases where there is ambiguity, so that when interoperability >> >>>>>>> problems arise it is clear who needs to change. >> >>>>>> >> >>>>>> Yes. In my case, implementation(s) WILL be changed. The question >> >>>>>> is WHICH >> >>>>>> implementation(s) :) >> >>>>>> >> >>>>>> So, my suggestion would be: >> >>>>>> >> >>>>>> 1)     Specify/clarify that SE must not be sent during session-timer >> >>>>>> negotiation >> >>>>>> 2)     Specify that one must send a 491 (or some other more >> appropriate >> >>>>>> code) >> >>>>>> response if receiving SE during session-timer negotiation >> >>>>>> >> >>>>>> For the above, I think we can do it using an errata. >> >>>>>> >> >>>>>> Regards, >> >>>>>> >> >>>>>> Christer >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>>> -----Ursprüngliche Nachricht----- >> >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >> >>>>>>>> Christer Holmberg >> >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >> >>>>>>>> An: Paul Kyzivat ; mailto:sipcore@ietf.org >> >>>>>>>> Betreff: Re: [sipcore] Session-timer issue >> >>>>>>>> >> >>>>>>>> Hi, >> >>>>>>>> >> >>>>>>>>>> The following issue has been around for some time already >> >>>>>>>>>> (there is also  an errata #4744), and as it causes problems >> >>>>>>>>>> (the INVITE is rejected with a >> >>>>>>>>>> 480 response) in deployed networks, so I think it needs to be >> >>>>>>>>>> fixed. >> >>>>>>>>>> People seem to have different opinions on which node is >> >>>>>>>>>> acting wrongly, so  I hope we can sort it out :) >> >>>>>>>>> >> >>>>>>>>> This is an interesting problem. I agree that it is unclear >> >>>>>>>>> exactly what ought to happen in this case. (But I don't >> >>>>>>>>> understand why someone thinks a 480 is a good way to resolve >> >>>>>>>>> it.) >> >>>>>>>> >> >>>>>>>> Whether 480 is the best solution or not is not the issue, in my >> >>>>>>>> opinion. >> >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. >> >>>>>>>> >> >>>>>>>> The issue is that there is a session-timer negotiation "race >> >>>>>>>> condition", and we should forbid that (rejecting the UPDATE >> >>>>>>>> could be part of such solution). >> >>>>>>>> >> >>>>>>>> Regards, >> >>>>>>>> >> >>>>>>>> Christer >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>>      Thanks, >> >>>>>>>>>      Paul >> >>>>>>>>> >> >>>>>>>>>> Below is a call flow showing the problem: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> UA                Proxy                AS >> >>>>>>>>>> >> >>>>>>>>>> -------------------> >> >>>>>>>>>> INVITE (#1) >> >>>>>>>>>> Supported:timer >> >>>>>>>>>> SE:refresher=uac >> >>>>>>>>>> >> >>>>>>>>>>                          -------------------> >> >>>>>>>>>>                          INVITE (#2) >> >>>>>>>>>>                          Supported:timer >> >>>>>>>>>>                          SE:refresher=uac >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>                          <------------------- >> >>>>>>>>>>                          18x (#3) >> >>>>>>>>>> >> >>>>>>>>>> <------------------- >> >>>>>>>>>> 18x (#4) >> >>>>>>>>>> >> >>>>>>>>>> ++++++ early dialog established +++++++ >> >>>>>>>>>> >> >>>>>>>>>>                          <------------------- >> >>>>>>>>>>                          UPDATE (#5) >> >>>>>>>>>>                          Supported:timer >> >>>>>>>>>>                          SE:refresher=uas >> >>>>>>>>>> >> >>>>>>>>>> <------------------- >> >>>>>>>>>> UPDATE (#6) >> >>>>>>>>>> Supported:timer >> >>>>>>>>>> SE:refresher=uas >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> -------------------> >> >>>>>>>>>> 200 (UPDATE) (#7) >> >>>>>>>>>> >> >>>>>>>>>>                          -------------------> >> >>>>>>>>>>                          200 (UPDATE) (#8) >> >>>>>>>>>>                          Require:timer >> >>>>>>>>>>                          SE:refresher=uac >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>                          <------------------- >> >>>>>>>>>>                          480 (INVITE) (#9) >> >>>>>>>>>> >> >>>>>>>>>> <------------------- >> >>>>>>>>>> 480 (INVITE (#10) >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> A few things to note: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> N1:        The 18x does not contain the SE (Session-Expires) >> header >> >>>>>>>>>> field, >> >>>>>>>>>>              because according to section 4 of RFC 4028 the >> >>>>>>>>>> header field is only >> >>>>>>>>>>              allowed in INVITE, UPDATE and 2xx. So, when the >> >>>>>>>>>> UPDATE request >> >>>>>>>>>>              (#5) is sent, the initial session timer >> >>>>>>>>>> negotiation is still >> >>>>>>>>>>              ongoing. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> N2:        The UPDATE request (#5) contains a Session-Expires >> header >> >>>>>>>>>> field. >> >>>>>>>>>>              Section 7.4 of RFC 4028 says: >> >>>>>>>>>> >> >>>>>>>>>>          "In a session refresh request sent within a dialog with >> >>>>>>>>>> an active >> >>>>>>>>>>           session timer, the Session-Expires header field SHOULD >> >>>>>>>>>> be present." >> >>>>>>>>>> >> >>>>>>>>>>     Now, a dialog (early) HAS been established when the UPDATE >> >>>>>>>> request is >> >>>>>>>>>>              sent, but as the initial session timer >> >>>>>>>>>> negotiation is still >> >>>>>>>>>>              ongoing, I assume the session timer isnąt yet >> >>>>>>>>>> "active"? >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> N3:        The UPDATE 200 response (#7) does not contain the >> >>>>>>>>>> Session-Expires >> >>>>>>>>>>              header field. It is added by the proxy, based on >> >>>>>>>>>> the procedures in >> >>>>>>>>>>              Section 8.2 of RFC 4028: >> >>>>>>>>>> >> >>>>>>>>>>                   "Because there is no Session-Expires or >> >>>>>>>>>> Require header field >> >>>>>>>>>>                    in the response, the proxy knows that it >> >>>>>>>>>> is the first >> >>>>>>>>>>                    session-timer-aware proxy to receive the >> >>>>>>>>>> response. >> >>>>>>>>>> This  proxy >> >>>>>>>>>>                    MUST insert a Session-Expires header field >> >>>>>>>>>> into the response >> >>>>>>>>>>                    with the value it remembered from the >> >>>>>>>>>> forwarded request. >> >>>>>>>>>> It >> >>>>>>>>>> MUST >> >>>>>>>>>>                    set the value of The 'refresher' parameter >> >>>>>>>>>> to 'uac'. >> >>>>>>>>>> The  proxy MUST >> >>>>>>>>>>                    add the 'timer' option tag to any Require >> >>>>>>>>>> header field in  the >> >>>>>>>>>>                    response, and if none was present, add the >> >>>>>>>>>> Require header  field with >> >>>>>>>>>>                    that value before forwarding it upstream." >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Now, one could argue that the UA should include something in >> >>>>>>>>>> the UPDATE response (#7), but I think that is not a solution >> >>>>>>>>>> as the UA may be confused. >> >>>>>>>>>> Instead, based on my understanding of the text in section 7.4 >> >>>>>>>>>> (see >> >>>>>>>>>> above) the UPDATE request (#5) should not contain any >> session >> >>>>>>>>>> timer information. This is also more or less what the errata >> >>>>>>>>>> suggests. >> >>>>>>>>>> >> >>>>>>>>>> Comments? >> >>>>>>>>>> >> >>>>>>>>>> Regards, >> >>>>>>>>>> >> >>>>>>>>>> Christer >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> sipcore mailing list >> >>>>>>>>>> mailto:sipcore@ietf.org >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> sipcore mailing list >> >>>>>>>>> mailto:sipcore@ietf.org >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> sipcore mailing list >> >>>>>>>> mailto:sipcore@ietf.org >> >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >> >>>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> sipcore mailing list >> >>>>>> mailto:sipcore@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >> >>>>> >> >>>>> _______________________________________________ >> >>>>> sipcore mailing list >> >>>>> mailto:sipcore@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/sipcore >> >>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> sipcore mailing list >> >>>> mailto:sipcore@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/sipcore >> >>> >> >>> >> >> >> > >> > >> >> _______________________________________________ >> sipcore mailing list >> mailto:sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Oct 9 07:27:01 2017 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 2C95F1321AC for ; Mon, 9 Oct 2017 07:27:00 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPa1aA0h3zg0 for ; Mon, 9 Oct 2017 07:26:59 -0700 (PDT) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6CE132944 for ; Mon, 9 Oct 2017 07:26:59 -0700 (PDT) X-AuditID: 12074411-f95ff70000007f0a-06-59db87325851 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id D8.1C.32522.2378BD95; Mon, 9 Oct 2017 10:26:58 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v99EQv6a006569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Oct 2017 10:26:58 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> From: Paul Kyzivat Message-ID: <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> Date: Mon, 9 Oct 2017 10:26:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixO6iqGvUfjvSYNI5RYsLMw8zWnz9sYnN gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYdl+64DlnxYTeI+wNjBfYuxg5OSQETCQ6 X75m6mLk4hAS2MEksXFTGzuE84BJYtu5+UwgVcICchKvO6+wgtgiAmkSPRP7oYoWM0ocvf6B ESTBJqAlMefQfxYQm1fAXuJ93yFmEJtFQEXi+cYLYLYoUPO/3WcZIWoEJU7OfAJWzylgI7F7 xzWwZcwCthIvFkxghrDFJW49mQ8Vl5fY/nYO8wRG/llI2mchaZmFpGUWkpYFjCyrGOUSc0pz dXMTM3OKU5N1i5MT8/JSi3RN9XIzS/RSU0o3MUJCVXAH44yTcocYBTgYlXh4G6bdihRiTSwr rsw9xCjJwaQkyju/+XakEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeJ01AOd6UxMqq1KJ8mJQ0 B4uSOC/fEnU/IYH0xJLU7NTUgtQimKwMB4eSBC9vG1CjYFFqempFWmZOCUKaiYMTZDgP0HAp kBre4oLE3OLMdIj8KUZdjp6eG3+YhFjy8vNSpcR5v7cCFQmAFGWU5sHNgaWYV4ziQG8J8zqB jOIBpie4Sa+AljABLWEsvgGypCQRISXVwNh9o9d1T5rNxPlrjsWqfMg+WHBh8e6fYl6Fr/ol ep0yntvdOzHzcYfZuecKX32Om/6Y8Oqkb1WuaFN7O1vP7T3Wb6dd1BWqv5Hl5eVx7/7OP8K6 MzrflLDVPfzd8FJ8iYLDi0KWzH4l9UgFjrse8zdejA7TW/PT8VR/zQemk70i/M9VnqQpmCqx FGckGmoxFxUnAgCmZmxSDAMAAA== Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 14:27:00 -0000 Hi Christer, On 10/9/17 6:54 AM, Christer Holmberg wrote: >> Yes, I understand that is the case you are thinking of. But I was >> raising a different case: >> >> - the UAC sends an invite without a S-E. >> - a proxy along the path includes an S-E. (The UAC is unaware.) >> - later, the UAC sends an UPDATE with S-E. >> >> That violates the rule in your draft, but the UAC doesn't know it has >> violated it. So your rule for avoiding the problem in this case doesn't >> work. > > Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I > understand the proxy will never remove S-E from a response. So, we could > say that the UAC must not send UPDATE with S-E until it has received a > response to the INVITE. The problem is that the rfc only talks about the *final* (2xx) response. It has no provision for including the S-E in provisional responses. (It doesn't mention provisional responses, and the Table 1 update in section 4 shows the intent is to exclude it. Hence, if the S-E is inserted into the INVITE by a proxy, the UAC won't know that a session timer has been requested until it receives the final response to the invite. Meanwhile it might decide send an UPDATE with S-E. Thanks, Paul From nobody Mon Oct 9 07:30:39 2017 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 6CB561342CD for ; Mon, 9 Oct 2017 07:30:38 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgMbmtwnrHaC for ; Mon, 9 Oct 2017 07:30:35 -0700 (PDT) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 04D49132930 for ; Mon, 9 Oct 2017 07:30:34 -0700 (PDT) X-AuditID: 1207440f-a5bff70000007960-98-59db88097848 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 90.6E.31072.9088BD95; Mon, 9 Oct 2017 10:30:33 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v99EUWnF006714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Oct 2017 10:30:33 -0400 To: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" References: From: Paul Kyzivat Message-ID: <9a3a0107-4e0f-9f26-dec6-0d9d741004ab@alum.mit.edu> Date: Mon, 9 Oct 2017 10:30:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYndR1OXquB1pcHM5p8WFmYcZLZrudLFZ fP2xic2B2ePX16tsHkuW/GTyaHupEMAcxWWTkpqTWZZapG+XwJXR/+UJa8HnmYwVNyZtZWpg /FrexcjJISFgIvHjyz/mLkYuDiGBHUwSe2f0MUI4D5gkurc3MYFUCQsYSFxfNAesSkRgOqPE 8RUdrCAJIQFrifsfr4MVsQloScw59J8FxOYVsJdYMmEhmM0ioCJxt7mDGcQWFUiT+Lf7LCNE jaDEyZlPgGo4ODgFbCQu3wsHCTML2Eq8WDCBGcIWl7j1ZD4ThC0v0bx1NvMERv5ZSLpnIWmZ haRlFpKWBYwsqxjlEnNKc3VzEzNzilOTdYuTE/PyUot0TfRyM0v0UlNKNzFCwpd/B2PXeplD jAIcjEo8vA3TbkUKsSaWFVfmHmKU5GBSEuVNab8dKcSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE 90kTUI43JbGyKrUoHyYlzcGiJM6rvkTdT0ggPbEkNTs1tSC1CCYrw8GhJMFbBTJUsCg1PbUi LTOnBCHNxMEJMpwHaPjUNpDhxQWJucWZ6RD5U4y6HD09N/4wCbHk5eelSonzloAMEgApyijN g5sDSzuvGMWB3hLmLQap4gGmLLhJr4CWMAEtYSy+AbKkJBEhJdXAGNx3tKpF467vtUm7jz8o XFb3/ojW5DlL2TQWrJkj01C3X/XMySdHYrbclXiquyngl4kN5/+Tgidub3bZcitt287JRye+ +22cKpM684KC98FFT/g1eMotD7JVvpNTe3r/zK9Itw9dCx12TFvaM/kF7/qIWFfDW10P3q/n Y4+4wjVv/vv1ApsSPXYrsRRnJBpqMRcVJwIA8h2KfxYDAAA= Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 14:30:38 -0000 On 10/9/17 8:21 AM, Christer Holmberg wrote: > Hi, > >>Ok it is not the outgoing proxy of the originating network that deletes the supported header. >> > >>The outgoing proxy of the orig. network will keep the supported timer. But the incoming proxy of the > > >intermediate network, which is also statefull will delete the > supported timer. Same apply for the backward direction. > >> > >>This is the typical interconnection usage. > >>So as I said this is a real issue we have. > > I understand. I just wonder why the Proxy removes the session-timer from > signalling, but still allows the session-timer UPDATE requests to pass. > Normally you remove something because you want to disable the functionality. > > But, in any case, I am not sure what can be done to solve the problem. > Both the UAC and UAS are told to generate session-timer updates. What can be done is to tell the implementer of Proxy1 to fix their broken implementation. If it feels a need to remove header fields then it must declare itself a B2BUA and follow the rules that it then inherits. Thanks, Paul > Regards, > > Christer > > > *Von:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Gesendet:* Montag, 9. Oktober 2017 12:31 > *An:* Jesske, Roland >; > Paul Kyzivat >; > sipcore@ietf.org > *Betreff:* Re: AW: [sipcore] Session timer fix > > Hi Roland, > > Since the originating Proxy is *anyway* going to forward the > Session-Timer UPDATE requests, why does it remove “SE; supp”? > > Regards, > > Christer > > *From: *"R.Jesske@telekom.de " > > > *Date: *Monday 9 October 2017 at 12:34 > *To: *"pkyzivat@alum.mit.edu " > >, Christer > Holmberg >, "sipcore@ietf.org > " > > *Subject: *AW: [sipcore] Session timer fix > > Hi, > > sorry but I have an further issue where we have problems with session timer. > > It is the procedures of stateful Proxy Servers where we can cause a race > condition. > > We have made the observation that due to the rules we have race > conditions with using the session timer. > > The case is where we have transfer of SIP messages through an network > that is not supporting session timer. > > Originating network and UAC does support session timer. > > Intermediate network does not support session timer > > And the terminating network does support session timer. > > This may result with the following call flow. > > UAC           Proxy           Proxy         UAS_2 > >    |                           |                | > >    |-- INVITE -->|             |                | > >    |    SE; supp |-- INVITE -->|-- INVITE (2) ->| > >    |             |    none     |    SE; supp > >    |             |             |                | > >    |             |             |<-- 200 (2) ----| > >    |<- 18x (2) --|<- 18x (2) --|    SE 1800; > >    |   SE 1800;  |             |      UAS       | > >    |     UAC     |             |                | > >    |-- UPDATE -->|             |                | > >    |            |-- UPDATE -->| <-- UPDATE ----| > >    |             |             |                | > >   |            |<- UPDATE ---| --- UPDATE --->| > >    |<- UPDATE ---|             |                | > >    |-- 491   --->|             |<-- 491     ----| > >    |             |-- 491   --->|                | > >    |             |<-- 491 ----|--- 491   --->| > >    |<-- 491 ----|             |                | > > This will happen when the session timer has the same length. > > How do we can solve such race conditions. I see the main problem within > the proxy behavior and the > > Forwarding of the UPDATE (or re-INVITE) for session refresh. > > Of course also the choice when the refresher shall sent the refresh may > solve the problem. > > But if the originating and terminating network is using the same > software vendor the refresh time will be the same. > > So seen from that kind of algorithm is needed to generate different > session refresh times. > > Do you see the same problems? > > Thank you and Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- > >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > >> Gesendet: Montag, 9. Oktober 2017 00:12 > >> An: Christer Holmberg >; > sipcore@ietf.org > >> Betreff: Re: [sipcore] Session timer fix > >> > >> On 10/5/17 4:37 AM, Christer Holmberg wrote: > >> > Hi, > >> > > >> >>> … > >> >>> > >> >>>> I'll propose that the session timer negotiation never be done with > >> >>>> an UPDATE within an INVITE transaction. (Regardless of whether than > >> >>>> INVITE is negotiating a session timer or not.) I think this > >> >>>> resolves the problem that you have encountered. (Or we could > >> >>>> require that the UPDATE and response care consistent session timer > >> >>>> signaling with what is carried in the INVITE and its responses.) > >> >>> > >> >>> I had a chat with some product people, and they said that there > >> >>> actually ARE cases where the session timer is negotiated using > >> >>> UPDATE when the initial INVITE transaction is still ongoing. There > >> >>> are cases where the INVITE only contains Supported:timer, but the > >> >>> actual negotiation is done using UPDATE. > >> >> > >> >> Interesting! (I wonder why.) > >> > > >> > I haven’t been able to figure out exactly why. I was just told the > >> > use-case exists. > >> > > >> > > >> >> That sequence itself presents some ambiguities. The way I have always > >> >> described how the session timer negotiation works is that *every* > >> >> INVITE and UPDATE transaction affects s-t - it either negotiates it > >> >> *on* or else it negotiates it *off*. (IMO this makes it very easy to > >> >> understand.) > >> >> > >> >> That presents issues when you have an update nested inside of an invite. > >> >> In the case you describe I might expect that the update would > >> >> negotiate the timer on, and then the completion of the invite would > >> >> negotiate it off again. > >> >> > >> >> How would the case you describe work if a proxy inserted S-E in INVITE? > >> >> In that case, the UAC doesn't know about it until the 2xx from the > >> >> invite. Before then it might try enabling a timer using UPDATE. > >> >> > >> >> I am inclined to keep things simple by saying that the 2xx response > >> >> to every INVITE or UPDATE redefines the state of the session timer, > >> >> either on or off. That will of course break the use case you describe > >> above. > >> > > >> > The problem here is that the UAC sends INVITE with S-E, and then > >> > receives an UPDATE with S-E before it has received a 2xx response to > >> > the INVITE - making the UAC think that there is a S-E glare situation > >> > (i.e., the UAS also tries to initiate session timer negotiation). > >> > >> Yes, I understand that is the case you are thinking of. But I was raising a > >> different case: > >> > >> - the UAC sends an invite without a S-E. > >> - a proxy along the path includes an S-E. (The UAC is unaware.) > >> - later, the UAC sends an UPDATE with S-E. > >> > >> That violates the rule in your draft, but the UAC doesn't know it has violated > >> it. So your rule for avoiding the problem in this case doesn't work. > >> > >>        Thanks, > >>        Paul > >> > >> > I think the RFC is pretty clear on how things work once the session > >> > timer has been negotiated (and, if it isn’t, we for sure can clarify that too). > >> > > >> > Regards, > >> > > >> > Christer > >> > > >> > > >> > > >> > > >> > > >> >>>>> > >> >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > >> >>>>> on behalf of > >> >>>>> mailto:christer.holmberg@ericsson.com> > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>>>> seen from my point of view the UAC should ignore the Session > >> >>>>>>>> timer proposal within the UPDATE. > >> >>>>>>>> As long as the negotiation is  ongoing. > >> >>>>>>>> > >> >>>>>>>> Nevertheless we have also observed this curious session timer > >> >>>>>>>> behavior in our network. > >> >>>>>>>> > >> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also to > >> >>>>>>>> other sections to make it more readable. > >> >>>>>>>> My experience is that people have problems in following how the > >> >>>>>>>> session timer should work within a complex SIP networks (e.g. > >> IMS). > >> >>>>>>>> > >> >>>>>>>> What is about updating the RFC4028. > >> >>>>>>> > >> >>>>>>> Like most of the older SIP RFCs, it probably deserves an update. > >> >>>>>>> The problem is whether going to the trouble will have any effect > >> >>>>>>> on implementations. I think the most we > should hope to do is > >> >>>>>>> *clarify* > >> >>>>>>> in > >> >>>>>>> cases where there is ambiguity, so that when interoperability > >> >>>>>>> problems arise it is clear who needs to change. > >> >>>>>> > >> >>>>>> Yes. In my case, implementation(s) WILL be changed. The question > >> >>>>>> is WHICH > >> >>>>>> implementation(s) :) > >> >>>>>> > >> >>>>>> So, my suggestion would be: > >> >>>>>> > >> >>>>>> 1)     Specify/clarify that SE must not be sent during session-timer > >> >>>>>> negotiation > >> >>>>>> 2)     Specify that one must send a 491 (or some other more > >> appropriate > >> >>>>>> code) > >> >>>>>> response if receiving SE during session-timer negotiation > >> >>>>>> > >> >>>>>> For the above, I think we can do it using an errata. > >> >>>>>> > >> >>>>>> Regards, > >> >>>>>> > >> >>>>>> Christer > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>>>> -----Ursprüngliche Nachricht----- > >> >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von > >> >>>>>>>> Christer Holmberg > >> >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 > >> >>>>>>>> An: Paul Kyzivat ; mailto:sipcore@ietf.org > >> >>>>>>>> Betreff: Re: [sipcore] Session-timer issue > >> >>>>>>>> > >> >>>>>>>> Hi, > >> >>>>>>>> > >> >>>>>>>>>> The following issue has been around for some time already > >> >>>>>>>>>> (there is also  an errata #4744), and as it causes problems > >> >>>>>>>>>> (the INVITE is rejected with a > >> >>>>>>>>>> 480 response) in deployed networks, so I think it needs to be > >> >>>>>>>>>> fixed. > >> >>>>>>>>>> People seem to have different opinions on which node is > >> >>>>>>>>>> acting wrongly, so  I hope we can sort it out :) > >> >>>>>>>>> > >> >>>>>>>>> This is an interesting problem. I agree that it is unclear > >> >>>>>>>>> exactly what ought to happen in this case. (But I don't > >> >>>>>>>>> understand why someone thinks a 480 is a good way to resolve > >> >>>>>>>>> it.) > >> >>>>>>>> > >> >>>>>>>> Whether 480 is the best solution or not is not the issue, in my > >> >>>>>>>> opinion. > >> >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. > >> >>>>>>>> > >> >>>>>>>> The issue is that there is a session-timer negotiation "race > >> >>>>>>>> condition", and we should forbid that (rejecting the UPDATE > >> >>>>>>>> could be part of such solution). > >> >>>>>>>> > >> >>>>>>>> Regards, > >> >>>>>>>> > >> >>>>>>>> Christer > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>>      Thanks, > >> >>>>>>>>>      Paul > >> >>>>>>>>> > >> >>>>>>>>>> Below is a call flow showing the problem: > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> UA                Proxy                AS > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> INVITE (#1) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=uac > >> >>>>>>>>>> > >> >>>>>>>>>>                          -------------------> > >> >>>>>>>>>>                          INVITE (#2) > >> >>>>>>>>>>                          Supported:timer > >> >>>>>>>>>>                          SE:refresher=uac > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>>                          <------------------- > >> >>>>>>>>>>                          18x (#3) > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 18x (#4) > >> >>>>>>>>>> > >> >>>>>>>>>> ++++++ early dialog established +++++++ > >> >>>>>>>>>> > >> >>>>>>>>>>                          <------------------- > >> >>>>>>>>>>                          UPDATE (#5) > >> >>>>>>>>>>                          Supported:timer > >> >>>>>>>>>>                          SE:refresher=uas > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> UPDATE (#6) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=uas > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> 200 (UPDATE) (#7) > >> >>>>>>>>>> > >> >>>>>>>>>>                          -------------------> > >> >>>>>>>>>>                          200 (UPDATE) (#8) > >> >>>>>>>>>>                          Require:timer > >> >>>>>>>>>>                          SE:refresher=uac > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>>                          <------------------- > >> >>>>>>>>>>                          480 (INVITE) (#9) > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 480 (INVITE (#10) > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> A few things to note: > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N1:        The 18x does not contain the SE (Session-Expires) > >> header > >> >>>>>>>>>> field, > >> >>>>>>>>>>              because according to section 4 of RFC 4028 the > >> >>>>>>>>>> header field is only > >> >>>>>>>>>>              allowed in INVITE, UPDATE and 2xx. So, when the > >> >>>>>>>>>> UPDATE request > >> >>>>>>>>>>              (#5) is sent, the initial session timer > >> >>>>>>>>>> negotiation is still > >> >>>>>>>>>>              ongoing. > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N2:        The UPDATE request (#5) contains a Session-Expires > >> header > >> >>>>>>>>>> field. > >> >>>>>>>>>>              Section 7.4 of RFC 4028 says: > >> >>>>>>>>>> > >> >>>>>>>>>>          "In a session refresh request sent within a dialog with > >> >>>>>>>>>> an active > >> >>>>>>>>>>           session timer, the Session-Expires header field SHOULD > >> >>>>>>>>>> be present." > >> >>>>>>>>>> > >> >>>>>>>>>>     Now, a dialog (early) HAS been established when the UPDATE > >> >>>>>>>> request is > >> >>>>>>>>>>              sent, but as the initial session timer > >> >>>>>>>>>> negotiation is still > >> >>>>>>>>>>              ongoing, I assume the session timer isnąt yet > >> >>>>>>>>>> "active"? > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N3:        The UPDATE 200 response (#7) does not contain the > >> >>>>>>>>>> Session-Expires > >> >>>>>>>>>>              header field. It is added by the proxy, based on > >> >>>>>>>>>> the procedures in > >> >>>>>>>>>>              Section 8.2 of RFC 4028: > >> >>>>>>>>>> > >> >>>>>>>>>>                   "Because there is no Session-Expires or > >> >>>>>>>>>> Require header field > >> >>>>>>>>>>                    in the response, the proxy knows that it > >> >>>>>>>>>> is the first > >> >>>>>>>>>>                    session-timer-aware proxy to receive the > >> >>>>>>>>>> response. > >> >>>>>>>>>> This  proxy > >> >>>>>>>>>>                    MUST insert a Session-Expires header field > >> >>>>>>>>>> into the response > >> >>>>>>>>>>                    with the value it remembered from the > >> >>>>>>>>>> forwarded request. > >> >>>>>>>>>> It > >> >>>>>>>>>> MUST > >> >>>>>>>>>>                    set the value of The 'refresher' parameter > >> >>>>>>>>>> to 'uac'. > >> >>>>>>>>>> The  proxy MUST > >> >>>>>>>>>>                    add the 'timer' option tag to any Require > >> >>>>>>>>>> header field in  the > >> >>>>>>>>>>                    response, and if none was present, add the > >> >>>>>>>>>> Require header  field with > >> >>>>>>>>>>                    that value before forwarding it upstream." > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> Now, one could argue that the UA should include something in > >> >>>>>>>>>> the UPDATE response (#7), but I think that is not a solution > >> >>>>>>>>>> as the UA may be confused. > >> >>>>>>>>>> Instead, based on my understanding of the text in section 7.4 > >> >>>>>>>>>> (see > >> >>>>>>>>>> above) the UPDATE request (#5) should not contain any > >> session > >> >>>>>>>>>> timer information. This is also more or less what the errata > >> >>>>>>>>>> suggests. > >> >>>>>>>>>> > >> >>>>>>>>>> Comments? > >> >>>>>>>>>> > >> >>>>>>>>>> Regards, > >> >>>>>>>>>> > >> >>>>>>>>>> Christer > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> _______________________________________________ > >> >>>>>>>>>> sipcore mailing list > >> >>>>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> _______________________________________________ > >> >>>>>>>>> sipcore mailing list > >> >>>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>>> > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> sipcore mailing list > >> >>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> sipcore mailing list > >> >>>>>> mailto:sipcore@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> sipcore mailing list > >> >>>>> mailto:sipcore@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> sipcore mailing list > >> >>>> mailto:sipcore@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>> > >> >>> > >> >> > >> > > >> > > >> > >> _______________________________________________ > >> sipcore mailing list > >> mailto:sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Oct 9 07:41:27 2017 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 4CAC51344C2 for ; Mon, 9 Oct 2017 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=4OdbKtdy; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=0RTGxnfD 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 R9fN7QKr_HRX for ; Mon, 9 Oct 2017 07:41:16 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 10D1A133187 for ; Mon, 9 Oct 2017 07:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1507560075; x=1539096075; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=gfSKosyl5fXeA6EbF906bOvfD5Do/WSR54Uzr+SgyVM=; b=4OdbKtdymBADFHuK7i7zUq49z7+N8cTNbNZK3FWltgJ2YT3tFzoyjdfP t21gAUhRPd9U3YzmmzWHn1Kjs017w/RqulO2sK3wd+cquQ7Heuhpqui/6 9kiIKnQy0rpoyrp4yOZfywqi63anMVsrxgyMYef2MzB3xp9InoUSRi5Gp oc1c9/rJJc9NfHmzoq5za2jmVHHIE+WkZuYCk3UMuqz6rlV8B7U5nbdex gP4w2e+AY1NXBwL/o6jSxJCNaW7ahDre8DvQSgxcbnbAaZEti5ojHISYe PxhVpch8+h/W6wyi2/pGbBNkiTZs5GOxJidLH+PrTaXK1ec3u4Jbnn8kv A==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2017 16:41:12 +0200 X-IronPort-AV: E=Sophos;i="5.42,500,1500933600"; d="scan'208,217";a="676067616" Received: from he105711.emea1.cds.t-internal.com ([10.169.118.42]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 09 Oct 2017 16:41:11 +0200 Received: from HE105761.EMEA1.cds.t-internal.com (10.169.118.57) by HE105711.emea1.cds.t-internal.com (10.169.118.42) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 16:41:11 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105761.EMEA1.cds.t-internal.com (10.169.118.57) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Oct 2017 16:41:11 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.24) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Oct 2017 16:41:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gfSKosyl5fXeA6EbF906bOvfD5Do/WSR54Uzr+SgyVM=; b=0RTGxnfDnlgiYE4ywH20qJ+bkhApnI7gB8UIPI5e/wzDQETSEqeTOCEgTwPwYY3yXDDy3OKm0EueW4PwFlkAVS4T5g28PdfYAZp2uRomfJ2S3dnD1zrJu+Di1Ah7YO3P6hD4C4WSM+S3AoF8WGPxZqgNFxwxWRoRmcH/U1ZIOs4= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0481.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 9 Oct 2017 14:41:09 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Mon, 9 Oct 2017 14:41:09 +0000 From: "Jesske, Roland" To: Paul Kyzivat , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaiXWAgACzC3CAAFsbgIAAAIZQ Date: Mon, 9 Oct 2017 14:41:09 +0000 Message-ID: References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <9cd95809-7388-9b8c-8070-83a1ba918b53@alum.mit.edu> In-Reply-To: <9cd95809-7388-9b8c-8070-83a1ba918b53@alum.mit.edu> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.68] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0481; 6:A+LGZ9jLrsC4JLJ5o3sMC+AQUVPqXLR0n0YCzRFVP7gjKsNPtqZrYKdkxdrRZN2+MtSfqPaGD7JOk5C/15SC+QaBxPtkQlRJXQdN1whYGNGKNilOHMUJEnm65Frp9raDNkNckfi5Zaztsj9n42opifpwz4dfY9DTKIEO4Waev5fMzm0OfridyugMzLU6AW0sBZomw5QF2mKtrnIVMadpeL6nQ8FLH/hnQOi1d0abPN4il0QXQxjXF4yImDr4XNWzthD9cyGViTxm4PCVqAfOmfkbOWu9wtK5RthdOwcDMFjxVJ/+ue411ISGG3f4yIHE9gc3OGciXBuYbS0LLreLdg==; 5:DkKoab1dDmdH65wM5FEx6wrx+beGuP27AvbI/Z5IzwbXW+cPryzfOCpXz7TYApDPg9dZ6/DKqvNfgBKht9CdFglohZiB6tZ1wkeSYbQIDXOKxVEGoa2ApLZXRkwwWC8hKGT8NBvvyeOELaUbNt+5kg==; 24:VjA7XhiiuFPvTlxI118J82jO+5gwMaWwVMlVScUFr3cEcFL2+WmmJaS1ZrIEWWW3OMqJ1GqjXSQN5VhJQF9i0mRl/mWU9h2mvynUQdzIDno=; 7:mTXgPUxgF7Pou37LEuWga5U0lzp1kdzjpXajSXxf1lfAL88geBJH1vIy0mYCy0HYlAjOSEATqxzpw1Oi2gtHGc2i5Ow6x+Kx+n6rCSD+FKIqy8YJzuZA0MGLrNAzk40PktNag/H+Vo4H0cy0jH30nC/FQ2QyEJNp3Fj/ivCpPJZi0s1oP6jaKdFa4klTgnyj4RkcGO3zPLibjrD9U7ijxFyysezgNzyC0PfVU0mbnZc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7e0edc5a-16b7-4b25-92b0-08d50f23c7f5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0481; x-ms-traffictypediagnostic: FRAPR01MB0481: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0481; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0481; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(51444003)(377454003)(199003)(24454002)(3660700001)(68736007)(966005)(93886005)(8936002)(14454004)(86362001)(50986999)(2906002)(16200700003)(2501003)(7696004)(6306002)(75402003)(7736002)(8676002)(81156014)(54356999)(305945005)(81166006)(74482002)(189998001)(3846002)(5250100002)(102836003)(316002)(2950100002)(76176999)(53936002)(33656002)(66066001)(110136005)(53946003)(6116002)(561944003)(105586002)(55016002)(101416001)(72206003)(551934003)(3280700002)(106356001)(2171002)(478600001)(9686003)(5660300001)(2900100001)(97736004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0481; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB04835AFDD1E0A59A0AE37CFCF9740FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 14:41:09.5043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0481 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 14:41:26 -0000 --_000_FRAPR01MB04835AFDD1E0A59A0AE37CFCF9740FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, Of course I follow your argumentation. i.E. either act properly or forward = the Session timer as received. For the described scenario sorry that I confused everybody with an incomplete picture. I missed to state that the transit network which is passing through the cal= l is deleting the session timer since it does not support it. Originating transit terminati= ng UAC Proxy1 netA Proxy2 netB Proxy3 netB Proxy4 netC = UAS | | | | = | |-- INVITE -->| | | | = | | SE; supp |-- INVITE -->|-- INVITE ----->|-- INVITE -->|-- INVITE (2= ) ->| | | SE; supp | none | none | SE; supp= | | | | | | = | | | |<-- 200 (2) ----|<-- 200 (2) -|<--- 200 (2)= ---| |<- 18x (2) --|<- 18x (2) --| | SE 1800; | SE 1800; = | | SE 1800; | | | UAS | UAS = | | UAC | | | | = | |-- UPDATE -->| | | | = | | |-- UPDATE -->| <-- UPDATE ----|<-- UPDATE --|<-- UPDATE -= ----| | | | | | |<- UPDATE ---| --- UPDATE --->|--- UPDATE ->|--- UPDATE -= --->| |<- UPDATE ---| | | | = | |-- 491 --->| |<-- 491 ----|<-- 491 ----|<-- 491 ---= ----| | |-- 491 --->| | | = | | |<-- 491 ----|--- 491 --->|<-- 491 --->|--- 491 ---= --->| |<-- 491 ----| | | | = | NetA and NetC does support session timer. NetB does not. So Proxy 2 netB will delete the session timer while Proxy 4 netC will inclu= de it again since this is allowed by RFC4028. On the other way back Proxy3 NetB will delete the information and Proxy1 Ne= tA will include it again. This will happen when the statefull Proxy rule with session timer support w= ill be implemented. I hope now it is clear about what scenario I'm talking Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Montag, 9. Oktober 2017 16:19 > An: Jesske, Roland ; Christer Holmberg > ; sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix > > On 10/9/17 5:34 AM, Jesske, Roland wrote: > > Hi, > > sorry but I have an further issue where we have problems with session > timer. > > It is the procedures of stateful Proxy Servers where we can cause a > > race condition. > > We have made the observation that due to the rules we have race > > conditions with using the session timer. > > The case is where we have transfer of SIP messages through an network > > that is not supporting session timer. > > Originating network and UAC does support session timer. > > Intermediate network does not support session timer And the > > terminating network does support session timer. > > This may result with the following call flow. > > UAC Proxy Proxy UAS_2 > > | | | > > |-- INVITE -->| | | > > | SE; supp |-- INVITE -->|-- INVITE (2) ->| > > | | none | SE; supp > > IIUC you are saying that Proxy1 *removes* the SE and the timer option fro= m > the request before forwarding it. Do I have that right? > > That is more that "not supporting" session timer - that is actively inter= fering > with the feature. This is non-compliant behavior for a proxy. > > A correctly functioning proxy will, if it doesn't understand the option a= nd the > header, just pass them along as received. The procedures specified for > session timer will work properly in that case. > > Thanks, > Paul > > > > | | | | > > | | |<-- 200 (2) ----| > > |<- 18x (2) --|<- 18x (2) --| SE 1800; > > | SE 1800; | | UAS | > > | UAC | | | > > |-- UPDATE -->| | | > > | |-- UPDATE -->| <-- UPDATE ----| > > | | | | > > | |<- UPDATE ---| --- UPDATE --->| > > |<- UPDATE ---| | | > > |-- 491 --->| |<-- 491 ----| > > | |-- 491 --->| | > > | |<-- 491 ----|--- 491 --->| > > |<-- 491 ----| | | This will happen > > when the session timer has the same length. > > How do we can solve such race conditions. I see the main problem > > within the proxy behavior and the Forwarding of the UPDATE (or > > re-INVITE) for session refresh. > > Of course also the choice when the refresher shall sent the refresh > > may solve the problem. > > But if the originating and terminating network is using the same > > software vendor the refresh time will be the same. > > So seen from that kind of algorithm is needed to generate different > > session refresh times. > > Do you see the same problems? > > Thank you and Best Regards > > Roland > >> -----Urspr=FCngliche Nachricht----- > >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul > >> Kyzivat > >> Gesendet: Montag, 9. Oktober 2017 00:12 > >> An: Christer Holmberg >; > >> sipcore@ietf.org > >> Betreff: Re: [sipcore] Session timer fix > >> > >> On 10/5/17 4:37 AM, Christer Holmberg wrote: > >> > Hi, > >> > > >> >>> ... > >> >>> > >> >>>> I'll propose that the session timer negotiation never be done > >> >>>> with an UPDATE within an INVITE transaction. (Regardless of > >> >>>> whether than INVITE is negotiating a session timer or not.) I > >> >>>> think this resolves the problem that you have encountered. (Or > >> >>>> we could require that the UPDATE and response care consistent > >> >>>> session timer signaling with what is carried in the INVITE and > >> >>>> its responses.) > >> >>> > >> >>> I had a chat with some product people, and they said that there > >> >>> actually ARE cases where the session timer is negotiated using > >> >>> UPDATE when the initial INVITE transaction is still ongoing. > >> >>> There are cases where the INVITE only contains Supported:timer, > >> >>> but the actual negotiation is done using UPDATE. > >> >> > >> >> Interesting! (I wonder why.) > >> > > >> > I haven't been able to figure out exactly why. I was just told the > >> > use-case exists. > >> > > >> > > >> >> That sequence itself presents some ambiguities. The way I have > >> >> always described how the session timer negotiation works is that > >> >> *every* INVITE and UPDATE transaction affects s-t - it either > >> >> negotiates it > >> >> *on* or else it negotiates it *off*. (IMO this makes it very easy > >> >> to > >> >> understand.) > >> >> > >> >> That presents issues when you have an update nested inside of an > invite. > >> >> In the case you describe I might expect that the update would > >> >> negotiate the timer on, and then the completion of the invite > >> >> would negotiate it off again. > >> >> > >> >> How would the case you describe work if a proxy inserted S-E in > INVITE? > >> >> In that case, the UAC doesn't know about it until the 2xx from the > >> >> invite. Before then it might try enabling a timer using UPDATE. > >> >> > >> >> I am inclined to keep things simple by saying that the 2xx > >> >> response to every INVITE or UPDATE redefines the state of the > >> >> session timer, either on or off. That will of course break the use > >> >> case you describe > >> above. > >> > > >> > The problem here is that the UAC sends INVITE with S-E, and then > >> > receives an UPDATE with S-E before it has received a 2xx response > >> > to the INVITE - making the UAC think that there is a S-E glare > >> > situation (i.e., the UAS also tries to initiate session timer negoti= ation). > >> > >> Yes, I understand that is the case you are thinking of. But I was > >> raising a different case: > >> > >> - the UAC sends an invite without a S-E. > >> - a proxy along the path includes an S-E. (The UAC is unaware.) > >> - later, the UAC sends an UPDATE with S-E. > >> > >> That violates the rule in your draft, but the UAC doesn't know it has > >> violated it. So your rule for avoiding the problem in this case doesn'= t work. > >> > >> Thanks, > >> Paul > >> > >> > I think the RFC is pretty clear on how things work once the session > >> > timer has been negotiated (and, if it isn't, we for sure can clarify= that > too). > >> > > >> > Regards, > >> > > >> > Christer > >> > > >> > > >> > > >> > > >> > > >> >>>>> > >> >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > >> >>>>> >> >>>>> mailto:christer.holmberg@ericsson.com> > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>>>> seen from my point of view the UAC should ignore the Session > >> >>>>>>>> timer proposal within the UPDATE. > >> >>>>>>>> As long as the negotiation is ongoing. > >> >>>>>>>> > >> >>>>>>>> Nevertheless we have also observed this curious session > >> >>>>>>>> timer behavior in our network. > >> >>>>>>>> > >> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also > >> >>>>>>>> to other sections to make it more readable. > >> >>>>>>>> My experience is that people have problems in following how > >> >>>>>>>> the session timer should work within a complex SIP networks > (e.g. > >> IMS). > >> >>>>>>>> > >> >>>>>>>> What is about updating the RFC4028. > >> >>>>>>> > >> >>>>>>> Like most of the older SIP RFCs, it probably deserves an updat= e. > >> >>>>>>> The problem is whether going to the trouble will have any > >> >>>>>>> effect on implementations. I think the most we > should hope > >> >>>>>>> to do is > >> >>>>>>> *clarify* > >> >>>>>>> in > >> >>>>>>> cases where there is ambiguity, so that when interoperability > >> >>>>>>> problems arise it is clear who needs to change. > >> >>>>>> > >> >>>>>> Yes. In my case, implementation(s) WILL be changed. The > >> >>>>>> question is WHICH > >> >>>>>> implementation(s) :) > >> >>>>>> > >> >>>>>> So, my suggestion would be: > >> >>>>>> > >> >>>>>> 1) Specify/clarify that SE must not be sent during > >> >>>>>> session-timer negotiation > >> >>>>>> 2) Specify that one must send a 491 (or some other more > >> appropriate > >> >>>>>> code) > >> >>>>>> response if receiving SE during session-timer negotiation > >> >>>>>> > >> >>>>>> For the above, I think we can do it using an errata. > >> >>>>>> > >> >>>>>> Regards, > >> >>>>>> > >> >>>>>> Christer > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>>>> -----Urspr=FCngliche Nachricht----- > >> >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag > >> >>>>>>>> von Christer Holmberg > >> >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 > >> >>>>>>>> An: Paul Kyzivat ; > >> >>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>> Betreff: Re: [sipcore] Session-timer issue > >> >>>>>>>> > >> >>>>>>>> Hi, > >> >>>>>>>> > >> >>>>>>>>>> The following issue has been around for some time already > >> >>>>>>>>>> (there is also an errata #4744), and as it causes > >> >>>>>>>>>> problems (the INVITE is rejected with a > >> >>>>>>>>>> 480 response) in deployed networks, so I think it needs to > >> >>>>>>>>>> be fixed. > >> >>>>>>>>>> People seem to have different opinions on which node is > >> >>>>>>>>>> acting wrongly, so I hope we can sort it out :) > >> >>>>>>>>> > >> >>>>>>>>> This is an interesting problem. I agree that it is unclear > >> >>>>>>>>> exactly what ought to happen in this case. (But I don't > >> >>>>>>>>> understand why someone thinks a 480 is a good way to > >> >>>>>>>>> resolve > >> >>>>>>>>> it.) > >> >>>>>>>> > >> >>>>>>>> Whether 480 is the best solution or not is not the issue, in > >> >>>>>>>> my opinion. > >> >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. > >> >>>>>>>> > >> >>>>>>>> The issue is that there is a session-timer negotiation "race > >> >>>>>>>> condition", and we should forbid that (rejecting the UPDATE > >> >>>>>>>> could be part of such solution). > >> >>>>>>>> > >> >>>>>>>> Regards, > >> >>>>>>>> > >> >>>>>>>> Christer > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> Thanks, > >> >>>>>>>>> Paul > >> >>>>>>>>> > >> >>>>>>>>>> Below is a call flow showing the problem: > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> UA Proxy AS > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> INVITE (#1) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> INVITE (#2) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 18x (#3) > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 18x (#4) > >> >>>>>>>>>> > >> >>>>>>>>>> ++++++ early dialog established +++++++ > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> UPDATE (#5) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duas > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> UPDATE (#6) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duas > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> 200 (UPDATE) (#7) > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> 200 (UPDATE) (#8) > >> >>>>>>>>>> Require:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 480 (INVITE) (#9) > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 480 (INVITE (#10) > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> A few things to note: > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N1: The 18x does not contain the SE > >> >>>>>>>>>> (Session-Expires) > >> header > >> >>>>>>>>>> field, > >> >>>>>>>>>> because according to section 4 of RFC 4028 > >> >>>>>>>>>>the header field is only > >> >>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when > >> >>>>>>>>>>the UPDATE request > >> >>>>>>>>>> (#5) is sent, the initial session timer > >> >>>>>>>>>>negotiation is still > >> >>>>>>>>>> ongoing. > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N2: The UPDATE request (#5) contains a > >> >>>>>>>>>> Session-Expires > >> header > >> >>>>>>>>>> field. > >> >>>>>>>>>> Section 7.4 of RFC 4028 says: > >> >>>>>>>>>> > >> >>>>>>>>>> "In a session refresh request sent within a > >> >>>>>>>>>>dialog with an active > >> >>>>>>>>>> session timer, the Session-Expires header field > >> >>>>>>>>>>SHOULD be present." > >> >>>>>>>>>> > >> >>>>>>>>>> Now, a dialog (early) HAS been established when the > >> >>>>>>>>>>UPDATE > >> >>>>>>>> request is > >> >>>>>>>>>> sent, but as the initial session timer > >> >>>>>>>>>>negotiation is still > >> >>>>>>>>>> ongoing, I assume the session timer isn=B9t ye= t > >> >>>>>>>>>>"active"? > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain > >> >>>>>>>>>>the Session-Expires > >> >>>>>>>>>> header field. It is added by the proxy, based > >> >>>>>>>>>>on the procedures in > >> >>>>>>>>>> Section 8.2 of RFC 4028: > >> >>>>>>>>>> > >> >>>>>>>>>> "Because there is no Session-Expires or > >> >>>>>>>>>>Require header field > >> >>>>>>>>>> in the response, the proxy knows that > >> >>>>>>>>>>it is the first > >> >>>>>>>>>> session-timer-aware proxy to receive > >> >>>>>>>>>>the response. > >> >>>>>>>>>> This proxy > >> >>>>>>>>>> MUST insert a Session-Expires header > >> >>>>>>>>>>field into the response > >> >>>>>>>>>> with the value it remembered from the > >> >>>>>>>>>>forwarded request. > >> >>>>>>>>>> It > >> >>>>>>>>>> MUST > >> >>>>>>>>>> set the value of The 'refresher' > >> >>>>>>>>>>parameter to 'uac'. > >> >>>>>>>>>> The proxy MUST > >> >>>>>>>>>> add the 'timer' option tag to any > >> >>>>>>>>>>Require header field in the > >> >>>>>>>>>> response, and if none was present, add > >> >>>>>>>>>>the Require header field with > >> >>>>>>>>>> that value before forwarding it upstream= ." > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> Now, one could argue that the UA should include something > >> >>>>>>>>>> in the UPDATE response (#7), but I think that is not a > >> >>>>>>>>>> solution as the UA may be confused. > >> >>>>>>>>>> Instead, based on my understanding of the text in section > >> >>>>>>>>>> 7.4 (see > >> >>>>>>>>>> above) the UPDATE request (#5) should not contain any > >> session > >> >>>>>>>>>> timer information. This is also more or less what the > >> >>>>>>>>>> errata suggests. > >> >>>>>>>>>> > >> >>>>>>>>>> Comments? > >> >>>>>>>>>> > >> >>>>>>>>>> Regards, > >> >>>>>>>>>> > >> >>>>>>>>>> Christer > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > _______________________________________________ > >> >>>>>>>>>> sipcore mailing list > >> >>>>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> _______________________________________________ > >> >>>>>>>>> sipcore mailing list > >> >>>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>>> > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> sipcore mailing list > >> >>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> sipcore mailing list > >> >>>>>> mailto:sipcore@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> sipcore mailing list > >> >>>>> mailto:sipcore@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> sipcore mailing list > >> >>>> mailto:sipcore@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>> > >> >>> > >> >> > >> > > >> > > >> > >> _______________________________________________ > >> sipcore mailing list > >> mailto:sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_FRAPR01MB04835AFDD1E0A59A0AE37CFCF9740FRAPR01MB0483DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Paul,
Of course I follow your argumentation. i.E. either act properly or for= ward the Session timer as received.
For the described scenario
sorry that I confused everybody with an incomplete picture.
I missed to state that the transit network which is passing through th= e call is deleting the session timer since it does not support it.
 
 
     Originating     &nbs= p;            &= nbsp;  transit         &n= bsp;            term= inating
UAC           Proxy1= netA   Proxy2 netB    Proxy3 netB    Pr= oxy4 netC         UAS  
   |         &n= bsp;            = ;     |        =         |     &= nbsp;       |     &n= bsp;          |  
   |-- INVITE -->|      &nb= sp;      |      &nbs= p;         |    &nbs= p;        |     = ;           |  =   
   |    SE; supp |-- INVITE -->|-- INVITE = ----->|-- INVITE -->|-- INVITE (2) ->|    &nbs= p;        
   |         &n= bsp;   |    SE; supp |    none = ;       |  none      = ; |    SE; supp    |
   |         &n= bsp;   |         &nb= sp;   |         &nbs= p;      |       &nbs= p;     |        = ;        |
   |         &n= bsp;   |         &nb= sp;   |<-- 200 (2) ----|<-- 200 (2) -|<--- 200 (2) ---|&= nbsp;    
   |<- 18x (2) --|<- 18x (2) --|    &nb= sp;           |  SE = 1800;   |   SE 1800;     |
   |   SE 1800;  |    &nb= sp;        |    &nbs= p;           |   UAS &nbs= p;     |      UAS   =     |
   |     UAC     |&n= bsp;            |&nb= sp;            =    |           =   |           &= nbsp;    |
   |-- UPDATE -->|      &nb= sp;      |      &nbs= p;         |    = ;         |     = ;           |
   |         &n= bsp;   |-- UPDATE -->| <-- UPDATE ----|<-- UPDATE --|<= ;-- UPDATE -----|          &nb= sp;     
   |         &n= bsp;   |         &nb= sp;   |         &nbs= p;      |
   |         &n= bsp;   |<- UPDATE ---| --- UPDATE --->|--- UPDATE ->|---= UPDATE ---->|
   |<- UPDATE ---|      &nb= sp;      |      &nbs= p;         |    &nbs= p;        |     = ;           |   = ;   
   |-- 491   --->|     = ;        |<-- 491   &n= bsp; ----|<-- 491  ----|<-- 491  -------|   =             &nb= sp;             = ;             <= /div>
   |         &n= bsp;   |-- 491   --->|     =            |  &= nbsp;          |  &n= bsp;            = ; |
   |         &n= bsp;   |<-- 491  ----|--- 491     ---= >|<-- 491  --->|--- 491  ------>|
   |<-- 491  ----|     &nbs= p;       |      = ;          |   =           |   &= nbsp;            |
 
 
NetA and NetC does support session timer.
NetB does not.
So Proxy 2 netB will delete the session timer while Proxy 4 netC will = include it again since this is allowed by RFC4028.
On the other way back Proxy3 NetB will delete the information and Prox= y1 NetA will include it again.
 
This will happen when the statefull Proxy rule with session timer supp= ort will be implemented.
 
I hope now it is clear about what scenario I’m talking
 
Best Regards
 
Roland
 
 
> -----Urspr=FCngliche Nachricht-----=
> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Ky= zivat
> Gesendet: Montag, 9. Oktober 2017 16:19
> An: Jesske, Roland <R.Jesske@telekom.de= >; Christer Holmberg
> <christer.holmberg@ericsson.com>; si= pcore@ietf.org
> Betreff: Re: [sipcore] Session timer fix
>
> On 10/9/17 5:34 AM, Jesske, Roland wrote:<= /font>
> > Hi,
> > sorry but I have an further issue whe= re we have problems with session
> timer.
> > It is the procedures of stateful Prox= y Servers where we can cause a
> > race condition.
> > We have made the observation that due= to the rules we have race
> > conditions with using the session tim= er.
> > The case is where we have transfer of= SIP messages through an network
> > that is not supporting session timer.=
> > Originating network and UAC does supp= ort session timer.
> > Intermediate network does not support= session timer And the
> > terminating network does support sess= ion timer.
> > This may result with the following ca= ll flow.
> > UAC     &nbs= p;     Proxy        =    Proxy         UAS_2<= /div>
> >     |   = ;             &= nbsp;          |   &= nbsp;            |=
> >     |-- INVITE -->|=              |&= nbsp;           &nbs= p;   |
> >     |   = ; SE; supp |-- INVITE -->|-- INVITE (2) ->|
> >     |   = ;          |   = none     |    SE; supp
>
> IIUC you are saying that Proxy1 *removes* = the SE and the timer option from
> the request before forwarding it. Do I hav= e that right?
>
> That is more that "not supporting&quo= t; session timer - that is actively interfering
> with the feature. This is non-compliant be= havior for a proxy.
>
> A correctly functioning proxy will, if it = doesn't understand the option and the
> header, just pass them along as received. = The procedures specified for
> session timer will work properly in that c= ase.
>
>        = Thanks,
>        = Paul
>
>
> >     |   = ;          |   =           |   &= nbsp;            |
> >     |   = ;          |   =           |<-- 200 (2) ----= |
> >     |<- 18x (2) --|= <- 18x (2) --|    SE 1800;
> >     |   SE 1800;&= nbsp; |             = |      UAS       |
> >     |   = ;  UAC     |      &n= bsp;      |      &nb= sp;         |
> >     |-- UPDATE -->|=              |&= nbsp;           &nbs= p;   |
> >     |   = ;         |-- UPDATE -->| <-- UPDA= TE ----|
> >     |   = ;          |   =           |   &= nbsp;            |
> >    |    &nbs= p;       |<- UPDATE ---| --- UPDATE --->= ;|
> >     |<- UPDATE ---|=              |&= nbsp;           &nbs= p;   |
> >     |-- 491   ---= >|           &nbs= p; |<-- 491     ----|
> >     |   = ;          |-- 491   ---&= gt;|            = ;    |
> >     |   = ;          |<-- 491 ----|--= - 491   --->|
> >     |<-- 491 ----|&= nbsp;            |&n= bsp;            = ;   | This will happen
> > when the session timer has the same l= ength.
> > How do we can solve such race conditi= ons. I see the main problem
> > within the proxy behavior and the For= warding of the UPDATE (or
> > re-INVITE) for session refresh.
> > Of course also the choice when the re= fresher shall sent the refresh
> > may solve the problem.
> > But if the originating and terminatin= g network is using the same
> > software vendor the refresh time will= be the same.
> > So seen from that kind of algorithm i= s needed to generate different
> > session refresh times.
> > Do you see the same problems?<= /div>
> > Thank you and Best Regards
> > Roland
> >> -----Urspr=FCngliche Nachricht---= --
> >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag vo= n Paul
> >> Kyzivat
> >> Gesendet: Montag, 9. Oktober 2017= 00:12
> >> An: Christer Holmberg <christer.holmberg@ericsson.com>;
> >> Betreff: Re: [sipcore] Session ti= mer fix
> >>
> >> On 10/5/17 4:37 AM, Christer Holm= berg wrote:
> >> > Hi,
> >> >
> >> >>> …
> >> >>>
> >> >>>> I'll propose tha= t the session timer negotiation never be done
> >> >>>> with an UPDATE w= ithin an INVITE transaction. (Regardless of
> >> >>>> whether than INV= ITE is negotiating a session timer or not.) I
> >> >>>> think this resol= ves the problem that you have encountered. (Or
> >> >>>> we could require= that the UPDATE and response care consistent
> >> >>>> session timer si= gnaling with what is carried in the INVITE and
> >> >>>> its responses.)<= /font>
> >> >>>
> >> >>> I had a chat with so= me product people, and they said that there
> >> >>> actually ARE cases w= here the session timer is negotiated using
> >> >>> UPDATE when the init= ial INVITE transaction is still ongoing.
> >> >>> There are cases wher= e the INVITE only contains Supported:timer,
> >> >>> but the actual negot= iation is done using UPDATE.
> >> >>
> >> >> Interesting! (I wonder w= hy.)
> >> >
> >> > I haven’t been able to= figure out exactly why. I was just told the
> >> > use-case exists.
> >> >
> >> >
> >> >> That sequence itself pre= sents some ambiguities. The way I have
> >> >> always described how the= session timer negotiation works is that
> >> >> *every* INVITE and UPDAT= E transaction affects s-t - it either
> >> >> negotiates it
> >> >> *on* or else it negotiat= es it *off*. (IMO this makes it very easy
> >> >> to
> >> >> understand.)
> >> >>
> >> >> That presents issues whe= n you have an update nested inside of an
> invite.
> >> >> In the case you describe= I might expect that the update would
> >> >> negotiate the timer on, = and then the completion of the invite
> >> >> would negotiate it off a= gain.
> >> >>
> >> >> How would the case you d= escribe work if a proxy inserted S-E in
> INVITE?
> >> >> In that case, the UAC do= esn't know about it until the 2xx from the
> >> >> invite. Before then it m= ight try enabling a timer using UPDATE.
> >> >>
> >> >> I am inclined to keep th= ings simple by saying that the 2xx
> >> >> response to every INVITE= or UPDATE redefines the state of the
> >> >> session timer, either on= or off. That will of course break the use
> >> >> case you describe=
> >> above.
> >> >
> >> > The problem here is that the= UAC sends INVITE with S-E, and then
> >> > receives an UPDATE with S-E = before it has received a 2xx response
> >> > to the INVITE - making the U= AC think that there is a S-E glare
> >> > situation (i.e., the UAS als= o tries to initiate session timer negotiation).
> >>
> >> Yes, I understand that is the cas= e you are thinking of. But I was
> >> raising a different case:<= /div>
> >>
> >> - the UAC sends an invite without= a S-E.
> >> - a proxy along the path includes= an S-E. (The UAC is unaware.)
> >> - later, the UAC sends an UPDATE = with S-E.
> >>
> >> That violates the rule in your dr= aft, but the UAC doesn't know it has
> >> violated it. So your rule for avo= iding the problem in this case doesn't work.
> >>
> >>     &nbs= p;  Thanks,
> >>     &nbs= p;  Paul
> >>
> >> > I think the RFC is pretty cl= ear on how things work once the session
> >> > timer has been negotiated (a= nd, if it isn’t, we for sure can clarify that
> too).
> >> >
> >> > Regards,
> >> >
> >> > Christer
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >>>>>
> >> >>>>> On 07/09/17 = 19:38, "sipcore on behalf of Christer Holmberg"
> >> >>>>> <sipcore-= bounces@ietf.org on behalf of
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>>>> = seen from my point of view the UAC should ignore the Session
> >> >>>>>>>> = timer proposal within the UPDATE.
> >> >>>>>>>> = As long as the negotiation is  ongoing.
> >> >>>>>>>><= /font>
> >> >>>>>>>> = Nevertheless we have also observed this curious session
> >> >>>>>>>> = timer behavior in our network.
> >> >>>>>>>><= /font>
> >> >>>>>>>> = I think we need some clarifications to the RFC. Perhaps also
> >> >>>>>>>> = to other sections to make it more readable.
> >> >>>>>>>> = My experience is that people have problems in following how
> >> >>>>>>>> = the session timer should work within a complex SIP networks
> (e.g.
> >> IMS).
> >> >>>>>>>><= /font>
> >> >>>>>>>> = What is about updating the RFC4028.
> >> >>>>>>>
> >> >>>>>>> Like= most of the older SIP RFCs, it probably deserves an update.
> >> >>>>>>> The = problem is whether going to the trouble will have any
> >> >>>>>>> effe= ct on implementations. I think the most we > should hope
> >> >>>>>>> to d= o is
> >> >>>>>>> *cla= rify*
> >> >>>>>>> in
> >> >>>>>>> case= s where there is ambiguity, so that when interoperability
> >> >>>>>>> prob= lems arise it is clear who needs to change.
> >> >>>>>>
> >> >>>>>> Yes. In = my case, implementation(s) WILL be changed. The
> >> >>>>>> question= is WHICH
> >> >>>>>> implemen= tation(s) :)
> >> >>>>>>
> >> >>>>>> So, my s= uggestion would be:
> >> >>>>>>
> >> >>>>>> 1) =     Specify/clarify that SE must not be sent during
> >> >>>>>> session-= timer negotiation
> >> >>>>>> 2) =     Specify that one must send a 491 (or some other more
> >> appropriate
> >> >>>>>> code)
> >> >>>>>> response= if receiving SE during session-timer negotiation
> >> >>>>>>
> >> >>>>>> For the = above, I think we can do it using an errata.
> >> >>>>>>
> >> >>>>>> Regards,=
> >> >>>>>>
> >> >>>>>> Christer=
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>>> = -----Urspr=FCngliche Nachricht-----
> >> >>>>>>>> = Von: sipcore [mailto:sipcore-bo= unces@ietf.org] Im Auftrag
> >> >>>>>>>> = von Christer Holmberg
> >> >>>>>>>> = Gesendet: Donnerstag, 7. September 2017 11:34
> >> >>>>>>>> = An: Paul Kyzivat <mailto:pkyziv= at@alum.mit.edu>;
> >> >>>>>>>> = mailto:sipcore@ietf.org
> >> >>>>>>>> = Betreff: Re: [sipcore] Session-timer issue
> >> >>>>>>>><= /font>
> >> >>>>>>>> = Hi,
> >> >>>>>>>><= /font>
> >> >>>>>>>>&= gt;> The following issue has been around for some time already
> >> >>>>>>>>&= gt;> (there is also  an errata #4744), and as it causes
> >> >>>>>>>>&= gt;> problems (the INVITE is rejected with a
> >> >>>>>>>>&= gt;> 480 response) in deployed networks, so I think it needs to
> >> >>>>>>>>&= gt;> be fixed.
> >> >>>>>>>>&= gt;> People seem to have different opinions on which node is
> >> >>>>>>>>&= gt;> acting wrongly, so  I hope we can sort it out :)
> >> >>>>>>>>&= gt;
> >> >>>>>>>>&= gt; This is an interesting problem. I agree that it is unclear
> >> >>>>>>>>&= gt; exactly what ought to happen in this case. (But I don't
> >> >>>>>>>>&= gt; understand why someone thinks a 480 is a good way to
> >> >>>>>>>>&= gt; resolve
> >> >>>>>>>>&= gt; it.)
> >> >>>>>>>><= /font>
> >> >>>>>>>> = Whether 480 is the best solution or not is not the issue, in
> >> >>>>>>>> = my opinion.
> >> >>>>>>>> = One could also claim that the UPDATE should be rejected. Etc.
> >> >>>>>>>><= /font>
> >> >>>>>>>> = The issue is that there is a session-timer negotiation "race
> >> >>>>>>>> = condition", and we should forbid that (rejecting the UPDATE
> >> >>>>>>>> = could be part of such solution).
> >> >>>>>>>><= /font>
> >> >>>>>>>> = Regards,
> >> >>>>>>>><= /font>
> >> >>>>>>>> = Christer
> >> >>>>>>>><= /font>
> >> >>>>>>>><= /font>
> >> >>>>>>>><= /font>
> >> >>>>>>>><= /font>
> >> >>>>>>>><= /font>
> >> >>>>>>>>&= gt;
> >> >>>>>>>>&= gt;      Thanks,
> >> >>>>>>>>&= gt;      Paul
> >> >>>>>>>>&= gt;
> >> >>>>>>>>&= gt;> Below is a call flow showing the problem:
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> UA           = ;     Proxy       &n= bsp;        AS
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> ------------------->
> >> >>>>>>>>&= gt;> INVITE (#1)
> >> >>>>>>>>&= gt;> Supported:timer
> >> >>>>>>>>&= gt;> SE:refresher=3Duac
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  ------------------->
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  INVITE (#2)
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  Supported:timer
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  SE:refresher=3Duac
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  <-------------------
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  18x (#3)
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> <-------------------
> >> >>>>>>>>&= gt;> 18x (#4)
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> ++++++ early dialog established ++&= #43;++++
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  <-------------------
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  UPDATE (#5)
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  Supported:timer
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  SE:refresher=3Duas
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> <-------------------
> >> >>>>>>>>&= gt;> UPDATE (#6)
> >> >>>>>>>>&= gt;> Supported:timer
> >> >>>>>>>>&= gt;> SE:refresher=3Duas
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> ------------------->
> >> >>>>>>>>&= gt;> 200 (UPDATE) (#7)
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  ------------------->
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  200 (UPDATE) (#8)
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  Require:timer
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  SE:refresher=3Duac
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  <-------------------
> >> >>>>>>>>&= gt;>           &n= bsp;            = ;  480 (INVITE) (#9)
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> <-------------------
> >> >>>>>>>>&= gt;> 480 (INVITE (#10)
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> A few things to note:
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> N1:        The 18x does not cont= ain the SE
> >> >>>>>>>>&= gt;> (Session-Expires)
> >> header
> >> >>>>>>>>&= gt;> field,
> >> >>>>>>>>&= gt;>           &n= bsp;  because according to section 4 of RFC 4028
> >> >>>>>>>>&= gt;>the  header field is only
> >> >>>>>>>>&= gt;>           &n= bsp;  allowed in INVITE, UPDATE and 2xx. So, when
> >> >>>>>>>>&= gt;>the  UPDATE request
> >> >>>>>>>>&= gt;>           &n= bsp;  (#5) is sent, the initial session timer
> >> >>>>>>>>&= gt;>negotiation is still
> >> >>>>>>>>&= gt;>           &n= bsp;  ongoing.
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> N2:        The UPDATE request (#= 5) contains a
> >> >>>>>>>>&= gt;> Session-Expires
> >> header
> >> >>>>>>>>&= gt;> field.
> >> >>>>>>>>&= gt;>           &n= bsp;  Section 7.4 of RFC 4028 says:
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>          "In a se= ssion refresh request sent within a
> >> >>>>>>>>&= gt;>dialog with  an active
> >> >>>>>>>>&= gt;>           session= timer, the Session-Expires header field
> >> >>>>>>>>&= gt;>SHOULD  be present."
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>     Now, a dialog (early) HAS been established = when the
> >> >>>>>>>>&= gt;>UPDATE
> >> >>>>>>>> = request is
> >> >>>>>>>>&= gt;>           &n= bsp;  sent, but as the initial session timer
> >> >>>>>>>>&= gt;>negotiation is still
> >> >>>>>>>>&= gt;>           &n= bsp;  ongoing, I assume the session timer isn=B9t yet
> >> >>>>>>>>&= gt;>"active"?
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> N3:        The UPDATE 200 respon= se (#7) does not contain
> >> >>>>>>>>&= gt;>the  Session-Expires
> >> >>>>>>>>&= gt;>           &n= bsp;  header field. It is added by the proxy, based
> >> >>>>>>>>&= gt;>on  the procedures in
> >> >>>>>>>>&= gt;>           &n= bsp;  Section 8.2 of RFC 4028:
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>           &n= bsp;       "Because there is no Session-= Expires or
> >> >>>>>>>>&= gt;>Require header field
> >> >>>>>>>>&= gt;>           &n= bsp;        in the response, the proxy k= nows that
> >> >>>>>>>>&= gt;>it  is the first
> >> >>>>>>>>&= gt;>           &n= bsp;        session-timer-aware proxy to= receive
> >> >>>>>>>>&= gt;>the  response.
> >> >>>>>>>>&= gt;> This  proxy
> >> >>>>>>>>&= gt;>           &n= bsp;        MUST insert a Session-Expire= s header
> >> >>>>>>>>&= gt;>field  into the response
> >> >>>>>>>>&= gt;>           &n= bsp;        with the value it remembered= from the
> >> >>>>>>>>&= gt;>forwarded request.
> >> >>>>>>>>&= gt;> It
> >> >>>>>>>>&= gt;> MUST
> >> >>>>>>>>&= gt;>           &n= bsp;        set the value of The 'refres= her'
> >> >>>>>>>>&= gt;>parameter  to 'uac'.
> >> >>>>>>>>&= gt;> The  proxy MUST
> >> >>>>>>>>&= gt;>           &n= bsp;        add the 'timer' option tag t= o any
> >> >>>>>>>>&= gt;>Require  header field in  the
> >> >>>>>>>>&= gt;>           &n= bsp;        response, and if none was pr= esent, add
> >> >>>>>>>>&= gt;>the  Require header  field with
> >> >>>>>>>>&= gt;>           &n= bsp;        that value before forwarding= it upstream."
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> Now, one could argue that the UA should include something
> >> >>>>>>>>&= gt;> in the UPDATE response (#7), but I think that is not a
> >> >>>>>>>>&= gt;> solution as the UA may be confused.
> >> >>>>>>>>&= gt;> Instead, based on my understanding of the text in section
> >> >>>>>>>>&= gt;> 7.4 (see
> >> >>>>>>>>&= gt;> above) the UPDATE request (#5) should not contain any
> >> session
> >> >>>>>>>>&= gt;> timer information. This is also more or less what the
> >> >>>>>>>>&= gt;> errata suggests.
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> Comments?
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> Regards,
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;> Christer
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;>
> __________________________________________= _____
> >> >>>>>>>>&= gt;> sipcore mailing list
> >> >>>>>>>>&= gt;> mailto:sipcore@ietf.org
> >> >>>>>>>>&= gt;>
> >> >>>>>>>>&= gt;
> >> >>>>>>>>&= gt; _______________________________________________
> >> >>>>>>>>&= gt; sipcore mailing list
> >> >>>>>>>>&= gt; mailto:sipcore@ietf.org<= /div>
> >> >>>>>>>><= /font>
> >> >>>>>>>> = _______________________________________________
> >> >>>>>>>> = sipcore mailing list
> >> >>>>>>>> = mailto:sipcore@ietf.org
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> ________= _______________________________________
> >> >>>>>> sipcore = mailing list
> >> >>>>>
> >> >>>>> ____________= ___________________________________
> >> >>>>> sipcore mail= ing list
> >> >>>>>
> >> >>>>
> >> >>>> ________________= _______________________________
> >> >>>> sipcore mailing = list
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >>
> >> _________________________________= ______________
> >> sipcore mailing list
>
> __________________________________________= _____
> sipcore mailing list
> https://www.ietf.org/mailman/listinfo/sipcore
 
 --_000_FRAPR01MB04835AFDD1E0A59A0AE37CFCF9740FRAPR01MB0483DEUP_-- From nobody Mon Oct 9 08:57:36 2017 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 EDBEA134E7E for ; Mon, 9 Oct 2017 08:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMklQepzFGii for ; Mon, 9 Oct 2017 08:57:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 8E3AC134F03 for ; Mon, 9 Oct 2017 08:55:47 -0700 (PDT) X-AuditID: c1b4fb30-a2f809c0000033c8-ae-59db9c0143a9 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4D.01.13256.10C9BD95; Mon, 9 Oct 2017 17:55:45 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 17:55:45 +0200 From: Christer Holmberg To: Paul Kyzivat , "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: AW: AW: [sipcore] Session timer fix Thread-Index: AQHTQPkV+yv59qL0gUe+n7eLvKvq8KLbctkAgAA4+IA= Date: Mon, 9 Oct 2017 15:55:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B563209DD@ESESSMB109.ericsson.se> References: <9a3a0107-4e0f-9f26-dec6-0d9d741004ab@alum.mit.edu> In-Reply-To: <9a3a0107-4e0f-9f26-dec6-0d9d741004ab@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2J7iC7jnNuRBg1TzCxWbDjAatF0p4vN 4uuPTWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6Mgy83MhU82MpYMam3k7WB sW0aYxcjJ4eEgInEq6dLWUFsIYEjjBKzT1Z1MXIB2QsZJV7tvA9UxMHBJmAh0f1PG6RGRKBS onv3QTYQW1jAQOLt+SlsICUiAoYSc/dxQpRYSVya+ZodxGYRUJFYumg2WDmvgK/E8/db2SFW FUocu3GPCcTmFHCQ6Lj/hRnEZhQQk/h+ag1YnFlAXOLWk/lMEGcKSCzZc54ZwhaVePn4HyuE rSSx6PZnqHo9iRtTp7BB2NoSyxa+ZobYKyhxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYhQt Ti1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMkINbfhvsYHz53PEQowAHoxIPb03n7Ugh1sSy4src Q4wSHMxKIrxPmoBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJx cEo1MFrVr26rarQOTk7fNqfefZOS3Xerx0rv9p8uSLv4Sub51CBX3ZiNG4W26AeJr9tx2Pzc W89NVZW3+zYZlEvbnDtc+F7W+VkL9x+NHZWzWDNcE+d/qWc641Tj8EXUas75CzdnSRjd/uEt wxUkmr6zPLP7Z+q6xE1NlqtnmcjN/pyz3vdFV+m7TUosxRmJhlrMRcWJAMHfmsyMAgAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 15:57:35 -0000 Hi, ... >> But, in any case, I am not sure what can be done to solve the problem.=20 >> Both the UAC and UAS are told to generate session-timer updates. > > What can be done is to tell the implementer of Proxy1 to fix their broken= implementation. What I meant is that I don't know what can be done in the spec. Also, if two endpoints send UPDATE at the same time, 491 is the correct way= to handle that. Regards, Christer > *Von:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Gesendet:* Montag, 9. Oktober 2017 12:31 > *An:* Jesske, Roland >; Paul Kyzivat >; sipcore@ietf.org=20 > > *Betreff:* Re: AW: [sipcore] Session timer fix >=20 > Hi Roland, >=20 > Since the originating Proxy is *anyway* going to forward the=20 > Session-Timer UPDATE requests, why does it remove "SE; supp"? >=20 > Regards, >=20 > Christer >=20 > *From: *"R.Jesske@telekom.de "=20 > > > *Date: *Monday 9 October 2017 at 12:34 > *To: *"pkyzivat@alum.mit.edu "=20 > >, Christer=20 > Holmberg >, "sipcore@ietf.org=20 > " > > *Subject: *AW: [sipcore] Session timer fix >=20 > Hi, >=20 > sorry but I have an further issue where we have problems with session tim= er. >=20 > It is the procedures of stateful Proxy Servers where we can cause a=20 > race condition. >=20 > We have made the observation that due to the rules we have race=20 > conditions with using the session timer. >=20 > The case is where we have transfer of SIP messages through an network=20 > that is not supporting session timer. >=20 > Originating network and UAC does support session timer. >=20 > Intermediate network does not support session timer >=20 > And the terminating network does support session timer. >=20 > This may result with the following call flow. >=20 > UAC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Proxy=A0=A0=A0 =A0=A0=A0=A0=A0=A0 Proxy= =A0=A0=A0=A0=A0 =A0=A0 UAS_2 >=20 > =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0 | >=20 > =A0=A0 |-- INVITE -->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=20 > =A0=A0 |=A0=A0=A0 SE; supp |-- INVITE -->|-- INVITE (2) ->| >=20 > =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 none=A0=A0=A0=A0= |=A0=A0=A0 SE; supp >=20 > =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=20 > =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |<-- 200 (2) ----| >=20 > =A0=A0 |<- 18x (2) --|<- 18x (2) --|=A0=A0=A0 SE 1800; >=20 > =A0=A0 | =A0 SE 1800;=A0 |=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 |=A0=A0=A0= =A0=A0 UAS=A0=A0=A0=A0=A0=A0 | >=20 > =A0=A0 |=A0=A0=A0=A0 UAC=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=20 > =A0=A0 |-- UPDATE -->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=20 > =A0=A0 |=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 |-- UPDATE -->| <-- UPDATE ----| >=20 > =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=20 > =A0 |=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 |<- UPDATE ---| --- UPDATE --->| >=20 > =A0=A0 |<- UPDATE ---|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=20 > =A0=A0 |-- 491 =A0 --->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<-- 491 = =A0=A0=A0 ----| >=20 > =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |-- 491 =A0 --->|=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=20 > =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |<-- 491 ----|--- 491 =A0 -= -->| >=20 > =A0=A0 |<-- 491 ----|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >=20 > This will happen when the session timer has the same length. >=20 > How do we can solve such race conditions. I see the main problem=20 > within the proxy behavior and the >=20 > Forwarding of the UPDATE (or re-INVITE) for session refresh. >=20 > Of course also the choice when the refresher shall sent the refresh=20 > may solve the problem. >=20 > But if the originating and terminating network is using the same=20 > software vendor the refresh time will be the same. >=20 > So seen from that kind of algorithm is needed to generate different=20 > session refresh times. >=20 > Do you see the same problems? >=20 > Thank you and Best Regards >=20 > Roland >=20 >> -----Urspr=FCngliche Nachricht----- >=20 >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul=20 >> Kyzivat >=20 >> Gesendet: Montag, 9. Oktober 2017 00:12 >=20 >> An: Christer Holmberg > >; > sipcore@ietf.org >=20 >> Betreff: Re: [sipcore] Session timer fix >=20 >> >=20 >> On 10/5/17 4:37 AM, Christer Holmberg wrote: >=20 >> > Hi, >=20 >> > >=20 >> >>> . >=20 >> >>> >=20 >> >>>> I'll propose that the session timer negotiation never be done=20 >> >>>> with >=20 >> >>>> an UPDATE within an INVITE transaction. (Regardless of whether=20 >> >>>> than >=20 >> >>>> INVITE is negotiating a session timer or not.) I think this >=20 >> >>>> resolves the problem that you have encountered. (Or we could >=20 >> >>>> require that the UPDATE and response care consistent session=20 >> >>>> timer >=20 >> >>>> signaling with what is carried in the INVITE and its responses.) >=20 >> >>> >=20 >> >>> I had a chat with some product people, and they said that there >=20 >> >>> actually ARE cases where the session timer is negotiated using >=20 >> >>> UPDATE when the initial INVITE transaction is still ongoing.=20 >> >>> There >=20 >> >>> are cases where the INVITE only contains Supported:timer, but the >=20 >> >>> actual negotiation is done using UPDATE. >=20 >> >> >=20 >> >> Interesting! (I wonder why.) >=20 >> > >=20 >> > I haven't been able to figure out exactly why. I was just told the >=20 >> > use-case exists. >=20 >> > >=20 >> > >=20 >> >> That sequence itself presents some ambiguities. The way I have=20 >> >> always >=20 >> >> described how the session timer negotiation works is that *every* >=20 >> >> INVITE and UPDATE transaction affects s-t - it either negotiates=20 >> >> it >=20 >> >> *on* or else it negotiates it *off*. (IMO this makes it very easy=20 >> >> to >=20 >> >> understand.) >=20 >> >> >=20 >> >> That presents issues when you have an update nested inside of an invi= te. >=20 >> >> In the case you describe I might expect that the update would >=20 >> >> negotiate the timer on, and then the completion of the invite=20 >> >> would >=20 >> >> negotiate it off again. >=20 >> >> >=20 >> >> How would the case you describe work if a proxy inserted S-E in INVIT= E? >=20 >> >> In that case, the UAC doesn't know about it until the 2xx from the >=20 >> >> invite. Before then it might try enabling a timer using UPDATE. >=20 >> >> >=20 >> >> I am inclined to keep things simple by saying that the 2xx=20 >> >> response >=20 >> >> to every INVITE or UPDATE redefines the state of the session=20 >> >> timer, >=20 >> >> either on or off. That will of course break the use case you=20 >> >> describe >=20 >> above. >=20 >> > >=20 >> > The problem here is that the UAC sends INVITE with S-E, and then >=20 >> > receives an UPDATE with S-E before it has received a 2xx response=20 >> > to >=20 >> > the INVITE - making the UAC think that there is a S-E glare=20 >> > situation >=20 >> > (i.e., the UAS also tries to initiate session timer negotiation). >=20 >> >=20 >> Yes, I understand that is the case you are thinking of. But I was=20 >> raising a >=20 >> different case: >=20 >> >=20 >> - the UAC sends an invite without a S-E. >=20 >> - a proxy along the path includes an S-E. (The UAC is unaware.) >=20 >> - later, the UAC sends an UPDATE with S-E. >=20 >> >=20 >> That violates the rule in your draft, but the UAC doesn't know it has=20 >> violated >=20 >> it. So your rule for avoiding the problem in this case doesn't work. >=20 >> >=20 >>=A0=A0=A0=A0=A0=A0=A0 Thanks, >=20 >>=A0=A0=A0=A0=A0=A0=A0 Paul >=20 >> >=20 >> > I think the RFC is pretty clear on how things work once the session >=20 >> > timer has been negotiated (and, if it isn't, we for sure can clarify t= hat too). >=20 >> > >=20 >> > Regards, >=20 >> > >=20 >> > Christer >=20 >> > >=20 >> > >=20 >> > >=20 >> > >=20 >> > >=20 >> >>>>> >=20 >> >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >=20 >> >>>>> on=20 >> >>>>> behalf of >=20 >> >>>>> mailto:christer.holmberg@ericsson.com> >=20 >> >>>>> wrote: >=20 >> >>>>> >=20 >> >>>>>> Hi, >=20 >> >>>>>> >=20 >> >>>>>>>> seen from my point of view the UAC should ignore the Session >=20 >> >>>>>>>> timer proposal within the UPDATE. >=20 >> >>>>>>>> As long as the negotiation is=A0 ongoing. >=20 >> >>>>>>>> >=20 >> >>>>>>>> Nevertheless we have also observed this curious session=20 >> >>>>>>>> timer >=20 >> >>>>>>>> behavior in our network. >=20 >> >>>>>>>> >=20 >> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also=20 >> >>>>>>>> to >=20 >> >>>>>>>> other sections to make it more readable. >=20 >> >>>>>>>> My experience is that people have problems in following how=20 >> >>>>>>>> the >=20 >> >>>>>>>> session timer should work within a complex SIP networks (e.g. >=20 >> IMS). >=20 >> >>>>>>>> >=20 >> >>>>>>>> What is about updating the RFC4028. >=20 >> >>>>>>> >=20 >> >>>>>>> Like most of the older SIP RFCs, it probably deserves an update. >=20 >> >>>>>>> The problem is whether going to the trouble will have any=20 >> >>>>>>> effect >=20 >> >>>>>>> on implementations. I think the most we > should hope to do=20 >> >>>>>>> is >=20 >> >>>>>>> *clarify* >=20 >> >>>>>>> in >=20 >> >>>>>>> cases where there is ambiguity, so that when interoperability >=20 >> >>>>>>> problems arise it is clear who needs to change. >=20 >> >>>>>> >=20 >> >>>>>> Yes. In my case, implementation(s) WILL be changed. The=20 >> >>>>>> question >=20 >> >>>>>> is WHICH >=20 >> >>>>>> implementation(s) :) >=20 >> >>>>>> >=20 >> >>>>>> So, my suggestion would be: >=20 >> >>>>>> >=20 >> >>>>>> 1)=A0=A0=A0=A0 Specify/clarify that SE must not be sent during=20 >> >>>>>> session-timer >=20 >> >>>>>> negotiation >=20 >> >>>>>> 2)=A0=A0=A0=A0 Specify that one must send a 491 (or some other mo= re >=20 >> appropriate >=20 >> >>>>>> code) >=20 >> >>>>>> response if receiving SE during session-timer negotiation >=20 >> >>>>>> >=20 >> >>>>>> For the above, I think we can do it using an errata. >=20 >> >>>>>> >=20 >> >>>>>> Regards, >=20 >> >>>>>> >=20 >> >>>>>> Christer >=20 >> >>>>>> >=20 >> >>>>>> >=20 >> >>>>>> >=20 >> >>>>>>>> -----Urspr=FCngliche Nachricht----- >=20 >> >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag=20 >> >>>>>>>> von >=20 >> >>>>>>>> Christer Holmberg >=20 >> >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >=20 >> >>>>>>>> An: Paul Kyzivat ;=20 >> >>>>>>>> mailto:sipcore@ietf.org >=20 >> >>>>>>>> Betreff: Re: [sipcore] Session-timer issue >=20 >> >>>>>>>> >=20 >> >>>>>>>> Hi, >=20 >> >>>>>>>> >=20 >> >>>>>>>>>> The following issue has been around for some time already >=20 >> >>>>>>>>>> (there is also=A0 an errata #4744), and as it causes=20 >> >>>>>>>>>> problems >=20 >> >>>>>>>>>> (the INVITE is rejected with a >=20 >> >>>>>>>>>> 480 response) in deployed networks, so I think it needs to=20 >> >>>>>>>>>> be >=20 >> >>>>>>>>>> fixed. >=20 >> >>>>>>>>>> People seem to have different opinions on which node is >=20 >> >>>>>>>>>> acting wrongly, so=A0 I hope we can sort it out :) >=20 >> >>>>>>>>> >=20 >> >>>>>>>>> This is an interesting problem. I agree that it is unclear >=20 >> >>>>>>>>> exactly what ought to happen in this case. (But I don't >=20 >> >>>>>>>>> understand why someone thinks a 480 is a good way to=20 >> >>>>>>>>> resolve >=20 >> >>>>>>>>> it.) >=20 >> >>>>>>>> >=20 >> >>>>>>>> Whether 480 is the best solution or not is not the issue, in=20 >> >>>>>>>> my >=20 >> >>>>>>>> opinion. >=20 >> >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. >=20 >> >>>>>>>> >=20 >> >>>>>>>> The issue is that there is a session-timer negotiation "race >=20 >> >>>>>>>> condition", and we should forbid that (rejecting the UPDATE >=20 >> >>>>>>>> could be part of such solution). >=20 >> >>>>>>>> >=20 >> >>>>>>>> Regards, >=20 >> >>>>>>>> >=20 >> >>>>>>>> Christer >=20 >> >>>>>>>> >=20 >> >>>>>>>> >=20 >> >>>>>>>> >=20 >> >>>>>>>> >=20 >> >>>>>>>> >=20 >> >>>>>>>>> >=20 >> >>>>>>>>>=A0=A0=A0=A0=A0 Thanks, >=20 >> >>>>>>>>>=A0=A0=A0=A0=A0 Paul >=20 >> >>>>>>>>> >=20 >> >>>>>>>>>> Below is a call flow showing the problem: >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> UA=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Proxy=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AS >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> -------------------> >=20 >> >>>>>>>>>> INVITE (#1) >=20 >> >>>>>>>>>> Supported:timer >=20 >> >>>>>>>>>> SE:refresher=3Duac >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -------------------> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 INVITE (#2) >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Supported:timer >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 SE:refresher=3Duac >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 <------------------- >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 18x (#3) >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> <------------------- >=20 >> >>>>>>>>>> 18x (#4) >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> ++++++ early dialog established +++++++ >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 <------------------- >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 UPDATE (#5) >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Supported:timer >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 SE:refresher=3Duas >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> <------------------- >=20 >> >>>>>>>>>> UPDATE (#6) >=20 >> >>>>>>>>>> Supported:timer >=20 >> >>>>>>>>>> SE:refresher=3Duas >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> -------------------> >=20 >> >>>>>>>>>> 200 (UPDATE) (#7) >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -------------------> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 200 (UPDATE) (#8) >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Require:timer >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 SE:refresher=3Duac >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 <------------------- >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 480 (INVITE) (#9) >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> <------------------- >=20 >> >>>>>>>>>> 480 (INVITE (#10) >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> A few things to note: >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> N1:=A0=A0=A0=A0=A0=A0=A0 The 18x does not contain the SE=20 >> >>>>>>>>>> (Session-Expires) >=20 >> header >=20 >> >>>>>>>>>> field, >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 because according to s= ection 4 of RFC 4028=20 >> >>>>>>>>>>the >=20 >> >>>>>>>>>> header field is only >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 allowed in INVITE, UPD= ATE and 2xx. So, when=20 >> >>>>>>>>>>the >=20 >> >>>>>>>>>> UPDATE request >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (#5) is sent, the init= ial session timer >=20 >> >>>>>>>>>> negotiation is still >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ongoing. >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> N2:=A0=A0=A0=A0=A0=A0=A0 The UPDATE request (#5) contains a=20 >> >>>>>>>>>> Session-Expires >=20 >> header >=20 >> >>>>>>>>>> field. >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 7.4 of RFC 402= 8 says: >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0 "In a session refresh request sent= within a=20 >> >>>>>>>>>>dialog with >=20 >> >>>>>>>>>> an active >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session timer, the Session-Expi= res header field=20 >> >>>>>>>>>>SHOULD >=20 >> >>>>>>>>>> be present." >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>>=A0=A0=A0=A0 Now, a dialog (early) HAS been established when t= he=20 >> >>>>>>>>>>UPDATE >=20 >> >>>>>>>> request is >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sent, but as the initi= al session timer >=20 >> >>>>>>>>>> negotiation is still >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ongoing, I assume the = session timer isn=B9t yet >=20 >> >>>>>>>>>> "active"? >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> N3:=A0=A0=A0=A0=A0=A0=A0 The UPDATE 200 response (#7) does no= t contain=20 >> >>>>>>>>>> the >=20 >> >>>>>>>>>> Session-Expires >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 header field. It is ad= ded by the proxy, based=20 >> >>>>>>>>>>on >=20 >> >>>>>>>>>> the procedures in >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 8.2 of RFC 402= 8: >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "Becaus= e there is no Session-Expires or >=20 >> >>>>>>>>>> Require header field >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in t= he response, the proxy knows that=20 >> >>>>>>>>>>it >=20 >> >>>>>>>>>> is the first >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sess= ion-timer-aware proxy to receive=20 >> >>>>>>>>>>the >=20 >> >>>>>>>>>> response. >=20 >> >>>>>>>>>> This=A0 proxy >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST= insert a Session-Expires header=20 >> >>>>>>>>>>field >=20 >> >>>>>>>>>> into the response >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 with= the value it remembered from the >=20 >> >>>>>>>>>> forwarded request. >=20 >> >>>>>>>>>> It >=20 >> >>>>>>>>>> MUST >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 set = the value of The 'refresher'=20 >> >>>>>>>>>>parameter >=20 >> >>>>>>>>>> to 'uac'. >=20 >> >>>>>>>>>> The=A0 proxy MUST >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 add = the 'timer' option tag to any=20 >> >>>>>>>>>>Require >=20 >> >>>>>>>>>> header field in=A0 the >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 resp= onse, and if none was present, add=20 >> >>>>>>>>>>the >=20 >> >>>>>>>>>> Require header=A0 field with >=20 >> >>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 that= value before forwarding it upstream." >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> Now, one could argue that the UA should include something=20 >> >>>>>>>>>> in >=20 >> >>>>>>>>>> the UPDATE response (#7), but I think that is not a=20 >> >>>>>>>>>> solution >=20 >> >>>>>>>>>> as the UA may be confused. >=20 >> >>>>>>>>>> Instead, based on my understanding of the text in section=20 >> >>>>>>>>>> 7.4 >=20 >> >>>>>>>>>> (see >=20 >> >>>>>>>>>> above) the UPDATE request (#5) should not contain any >=20 >> session >=20 >> >>>>>>>>>> timer information. This is also more or less what the=20 >> >>>>>>>>>> errata >=20 >> >>>>>>>>>> suggests. >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> Comments? >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> Regards, >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> Christer >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>>> _______________________________________________ >=20 >> >>>>>>>>>> sipcore mailing list >=20 >> >>>>>>>>>> mailto:sipcore@ietf.org >=20 >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >=20 >> >>>>>>>>>> >=20 >> >>>>>>>>> >=20 >> >>>>>>>>> _______________________________________________ >=20 >> >>>>>>>>> sipcore mailing list >=20 >> >>>>>>>>> mailto:sipcore@ietf.org >=20 >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >=20 >> >>>>>>>> >=20 >> >>>>>>>> _______________________________________________ >=20 >> >>>>>>>> sipcore mailing list >=20 >> >>>>>>>> mailto:sipcore@ietf.org >=20 >> >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >=20 >> >>>>>>> >=20 >> >>>>>> >=20 >> >>>>>> _______________________________________________ >=20 >> >>>>>> sipcore mailing list >=20 >> >>>>>> mailto:sipcore@ietf.org >=20 >> >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >=20 >> >>>>> >=20 >> >>>>> _______________________________________________ >=20 >> >>>>> sipcore mailing list >=20 >> >>>>> mailto:sipcore@ietf.org >=20 >> >>>>> https://www.ietf.org/mailman/listinfo/sipcore >=20 >> >>>>> >=20 >> >>>> >=20 >> >>>> _______________________________________________ >=20 >> >>>> sipcore mailing list >=20 >> >>>> mailto:sipcore@ietf.org >=20 >> >>>> https://www.ietf.org/mailman/listinfo/sipcore >=20 >> >>> >=20 >> >>> >=20 >> >> >=20 >> > >=20 >> > >=20 >> >=20 >> _______________________________________________ >=20 >> sipcore mailing list >=20 >> mailto:sipcore@ietf.org >=20 >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From nobody Mon Oct 9 09:04:53 2017 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 4AF10134714 for ; Mon, 9 Oct 2017 09:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2hjU3PVlR7O for ; Mon, 9 Oct 2017 09:04:46 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 7733113463F for ; Mon, 9 Oct 2017 09:01:24 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-ac-59db9d5253a8 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.4A.03220.25D9BD95; Mon, 9 Oct 2017 18:01:22 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 18:01:21 +0200 From: Christer Holmberg To: "Jesske, Roland" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTQQyohPRgLg6aqEWU+W2OdQNl3qLbrRWg Date: Mon, 9 Oct 2017 16:01:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56320A39@ESESSMB109.ericsson.se> References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <9cd95809-7388-9b8c-8070-83a1ba918b53@alum.mit.edu> 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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B56320A39ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7um7Q3NuRBkuWK1us2HCA1aLpTheb xdcfm9gcmD3+vv/A5LFkyU8mj7aXCgHMUVw2Kak5mWWpRfp2CVwZ8xc3MhVMvcBVcWbnfKYG xuUnObsYOTkkBEwk3hxdwwpiCwkcYZRo/lzSxcgFZC9klPgwbz57FyMHB5uAhUT3P22QGhGB Sonj/yexgdjCAhoSn+deZoaIa0pcPLWMCcI2krjZOhcsziKgItF69RTYfF4BX4lJm24yQew6 zSRxsLECxOYUiJE4sP4zI4jNKCAm8f3UGrAaZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/rBC2 ksSi25+h6vMl3j74xwyxS1Di5MwnLBMYhWchGTULSdksJGUQcT2JG1OnsEHY2hLLFr5mhrB1 JWb8O8SCLL6AkX0Vo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBMHdzyW3UH4+U3jocYBTgY lXh4V3fdjhRiTSwrrsw9xCjBwawkwvukCSjEm5JYWZValB9fVJqTWnyIUZqDRUmc13HfhQgh gfTEktTs1NSC1CKYLBMHp1QDo7X1pCLzZ8/nTP77eMqKXUlGStcVby+PODePZdGZt4nBS8xq HnVsDTCW9dzgs747b82kGJFVUec1S6fsr5Zm+BprGSXF1+tz0mr+NlP+7BmnZROz+y0Xxr1U MHr/Lyntkm7OYWu/C6x2V5ZsCVgtPfW+xTzT2dZq2+3UBfeXfw999T7F+MGkF0osxRmJhlrM RcWJAEL6GvGlAgAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 16:04:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B56320A39ESESSMB109erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roland, I don't think it was unclear that S-E is removed by the transit network - a= t least it was not unclear to me :) However, your latest call flow is confusing. First, there is a 18x with S-E= , which is not allowed. Second, the UPDATEs and 491 seem messed up, so it's really difficult to par= se what is going on, and in what order. Regards, Christer From: Jesske, Roland [mailto:R.Jesske@telekom.de] Sent: 09 October 2017 16:41 To: Paul Kyzivat ; Christer Holmberg ; sipcore@ietf.org Subject: AW: [sipcore] Session timer fix Hi Paul, Of course I follow your argumentation. i.E. either act properly or forward = the Session timer as received. For the described scenario sorry that I confused everybody with an incomplete picture. I missed to state that the transit network which is passing through the cal= l is deleting the session timer since it does not support it. Originating transit terminati= ng UAC Proxy1 netA Proxy2 netB Proxy3 netB Proxy4 netC = UAS | | | | = | |-- INVITE -->| | | | = | | SE; supp |-- INVITE -->|-- INVITE ----->|-- INVITE -->|-- INVITE (2= ) ->| | | SE; supp | none | none | SE; supp= | | | | | | = | | | |<-- 200 (2) ----|<-- 200 (2) -|<--- 200 (2)= ---| |<- 18x (2) --|<- 18x (2) --| | SE 1800; | SE 1800; = | | SE 1800; | | | UAS | UAS = | | UAC | | | | = | |-- UPDATE -->| | | | = | | |-- UPDATE -->| <-- UPDATE ----|<-- UPDATE --|<-- UPDATE -= ----| | | | | | |<- UPDATE ---| --- UPDATE --->|--- UPDATE ->|--- UPDATE -= --->| |<- UPDATE ---| | | | = | |-- 491 --->| |<-- 491 ----|<-- 491 ----|<-- 491 ---= ----| | |-- 491 --->| | | = | | |<-- 491 ----|--- 491 --->|<-- 491 --->|--- 491 ---= --->| |<-- 491 ----| | | | = | NetA and NetC does support session timer. NetB does not. So Proxy 2 netB will delete the session timer while Proxy 4 netC will inclu= de it again since this is allowed by RFC4028. On the other way back Proxy3 NetB will delete the information and Proxy1 Ne= tA will include it again. This will happen when the statefull Proxy rule with session timer support w= ill be implemented. I hope now it is clear about what scenario I'm talking Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Montag, 9. Oktober 2017 16:19 > An: Jesske, Roland >; Chr= ister Holmberg > >; = sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix > > On 10/9/17 5:34 AM, Jesske, Roland wrote: > > Hi, > > sorry but I have an further issue where we have problems with session > timer. > > It is the procedures of stateful Proxy Servers where we can cause a > > race condition. > > We have made the observation that due to the rules we have race > > conditions with using the session timer. > > The case is where we have transfer of SIP messages through an network > > that is not supporting session timer. > > Originating network and UAC does support session timer. > > Intermediate network does not support session timer And the > > terminating network does support session timer. > > This may result with the following call flow. > > UAC Proxy Proxy UAS_2 > > | | | > > |-- INVITE -->| | | > > | SE; supp |-- INVITE -->|-- INVITE (2) ->| > > | | none | SE; supp > > IIUC you are saying that Proxy1 *removes* the SE and the timer option fro= m > the request before forwarding it. Do I have that right? > > That is more that "not supporting" session timer - that is actively inter= fering > with the feature. This is non-compliant behavior for a proxy. > > A correctly functioning proxy will, if it doesn't understand the option a= nd the > header, just pass them along as received. The procedures specified for > session timer will work properly in that case. > > Thanks, > Paul > > > > | | | | > > | | |<-- 200 (2) ----| > > |<- 18x (2) --|<- 18x (2) --| SE 1800; > > | SE 1800; | | UAS | > > | UAC | | | > > |-- UPDATE -->| | | > > | |-- UPDATE -->| <-- UPDATE ----| > > | | | | > > | |<- UPDATE ---| --- UPDATE --->| > > |<- UPDATE ---| | | > > |-- 491 --->| |<-- 491 ----| > > | |-- 491 --->| | > > | |<-- 491 ----|--- 491 --->| > > |<-- 491 ----| | | This will happen > > when the session timer has the same length. > > How do we can solve such race conditions. I see the main problem > > within the proxy behavior and the Forwarding of the UPDATE (or > > re-INVITE) for session refresh. > > Of course also the choice when the refresher shall sent the refresh > > may solve the problem. > > But if the originating and terminating network is using the same > > software vendor the refresh time will be the same. > > So seen from that kind of algorithm is needed to generate different > > session refresh times. > > Do you see the same problems? > > Thank you and Best Regards > > Roland > >> -----Urspr=FCngliche Nachricht----- > >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul > >> Kyzivat > >> Gesendet: Montag, 9. Oktober 2017 00:12 > >> An: Christer Holmberg >; > >> sipcore@ietf.org > >> Betreff: Re: [sipcore] Session timer fix > >> > >> On 10/5/17 4:37 AM, Christer Holmberg wrote: > >> > Hi, > >> > > >> >>> ... > >> >>> > >> >>>> I'll propose that the session timer negotiation never be done > >> >>>> with an UPDATE within an INVITE transaction. (Regardless of > >> >>>> whether than INVITE is negotiating a session timer or not.) I > >> >>>> think this resolves the problem that you have encountered. (Or > >> >>>> we could require that the UPDATE and response care consistent > >> >>>> session timer signaling with what is carried in the INVITE and > >> >>>> its responses.) > >> >>> > >> >>> I had a chat with some product people, and they said that there > >> >>> actually ARE cases where the session timer is negotiated using > >> >>> UPDATE when the initial INVITE transaction is still ongoing. > >> >>> There are cases where the INVITE only contains Supported:timer, > >> >>> but the actual negotiation is done using UPDATE. > >> >> > >> >> Interesting! (I wonder why.) > >> > > >> > I haven't been able to figure out exactly why. I was just told the > >> > use-case exists. > >> > > >> > > >> >> That sequence itself presents some ambiguities. The way I have > >> >> always described how the session timer negotiation works is that > >> >> *every* INVITE and UPDATE transaction affects s-t - it either > >> >> negotiates it > >> >> *on* or else it negotiates it *off*. (IMO this makes it very easy > >> >> to > >> >> understand.) > >> >> > >> >> That presents issues when you have an update nested inside of an > invite. > >> >> In the case you describe I might expect that the update would > >> >> negotiate the timer on, and then the completion of the invite > >> >> would negotiate it off again. > >> >> > >> >> How would the case you describe work if a proxy inserted S-E in > INVITE? > >> >> In that case, the UAC doesn't know about it until the 2xx from the > >> >> invite. Before then it might try enabling a timer using UPDATE. > >> >> > >> >> I am inclined to keep things simple by saying that the 2xx > >> >> response to every INVITE or UPDATE redefines the state of the > >> >> session timer, either on or off. That will of course break the use > >> >> case you describe > >> above. > >> > > >> > The problem here is that the UAC sends INVITE with S-E, and then > >> > receives an UPDATE with S-E before it has received a 2xx response > >> > to the INVITE - making the UAC think that there is a S-E glare > >> > situation (i.e., the UAS also tries to initiate session timer negoti= ation). > >> > >> Yes, I understand that is the case you are thinking of. But I was > >> raising a different case: > >> > >> - the UAC sends an invite without a S-E. > >> - a proxy along the path includes an S-E. (The UAC is unaware.) > >> - later, the UAC sends an UPDATE with S-E. > >> > >> That violates the rule in your draft, but the UAC doesn't know it has > >> violated it. So your rule for avoiding the problem in this case doesn'= t work. > >> > >> Thanks, > >> Paul > >> > >> > I think the RFC is pretty clear on how things work once the session > >> > timer has been negotiated (and, if it isn't, we for sure can clarify= that > too). > >> > > >> > Regards, > >> > > >> > Christer > >> > > >> > > >> > > >> > > >> > > >> >>>>> > >> >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > >> >>>>> >> >>>>> mailto:christer.holmberg@ericsson.com> > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>>>> seen from my point of view the UAC should ignore the Session > >> >>>>>>>> timer proposal within the UPDATE. > >> >>>>>>>> As long as the negotiation is ongoing. > >> >>>>>>>> > >> >>>>>>>> Nevertheless we have also observed this curious session > >> >>>>>>>> timer behavior in our network. > >> >>>>>>>> > >> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also > >> >>>>>>>> to other sections to make it more readable. > >> >>>>>>>> My experience is that people have problems in following how > >> >>>>>>>> the session timer should work within a complex SIP networks > (e.g. > >> IMS). > >> >>>>>>>> > >> >>>>>>>> What is about updating the RFC4028. > >> >>>>>>> > >> >>>>>>> Like most of the older SIP RFCs, it probably deserves an updat= e. > >> >>>>>>> The problem is whether going to the trouble will have any > >> >>>>>>> effect on implementations. I think the most we > should hope > >> >>>>>>> to do is > >> >>>>>>> *clarify* > >> >>>>>>> in > >> >>>>>>> cases where there is ambiguity, so that when interoperability > >> >>>>>>> problems arise it is clear who needs to change. > >> >>>>>> > >> >>>>>> Yes. In my case, implementation(s) WILL be changed. The > >> >>>>>> question is WHICH > >> >>>>>> implementation(s) :) > >> >>>>>> > >> >>>>>> So, my suggestion would be: > >> >>>>>> > >> >>>>>> 1) Specify/clarify that SE must not be sent during > >> >>>>>> session-timer negotiation > >> >>>>>> 2) Specify that one must send a 491 (or some other more > >> appropriate > >> >>>>>> code) > >> >>>>>> response if receiving SE during session-timer negotiation > >> >>>>>> > >> >>>>>> For the above, I think we can do it using an errata. > >> >>>>>> > >> >>>>>> Regards, > >> >>>>>> > >> >>>>>> Christer > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>>>> -----Urspr=FCngliche Nachricht----- > >> >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag > >> >>>>>>>> von Christer Holmberg > >> >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 > >> >>>>>>>> An: Paul Kyzivat ; > >> >>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>> Betreff: Re: [sipcore] Session-timer issue > >> >>>>>>>> > >> >>>>>>>> Hi, > >> >>>>>>>> > >> >>>>>>>>>> The following issue has been around for some time already > >> >>>>>>>>>> (there is also an errata #4744), and as it causes > >> >>>>>>>>>> problems (the INVITE is rejected with a > >> >>>>>>>>>> 480 response) in deployed networks, so I think it needs to > >> >>>>>>>>>> be fixed. > >> >>>>>>>>>> People seem to have different opinions on which node is > >> >>>>>>>>>> acting wrongly, so I hope we can sort it out :) > >> >>>>>>>>> > >> >>>>>>>>> This is an interesting problem. I agree that it is unclear > >> >>>>>>>>> exactly what ought to happen in this case. (But I don't > >> >>>>>>>>> understand why someone thinks a 480 is a good way to > >> >>>>>>>>> resolve > >> >>>>>>>>> it.) > >> >>>>>>>> > >> >>>>>>>> Whether 480 is the best solution or not is not the issue, in > >> >>>>>>>> my opinion. > >> >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. > >> >>>>>>>> > >> >>>>>>>> The issue is that there is a session-timer negotiation "race > >> >>>>>>>> condition", and we should forbid that (rejecting the UPDATE > >> >>>>>>>> could be part of such solution). > >> >>>>>>>> > >> >>>>>>>> Regards, > >> >>>>>>>> > >> >>>>>>>> Christer > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> Thanks, > >> >>>>>>>>> Paul > >> >>>>>>>>> > >> >>>>>>>>>> Below is a call flow showing the problem: > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> UA Proxy AS > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> INVITE (#1) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> INVITE (#2) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 18x (#3) > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 18x (#4) > >> >>>>>>>>>> > >> >>>>>>>>>> ++++++ early dialog established +++++++ > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> UPDATE (#5) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duas > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> UPDATE (#6) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duas > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> 200 (UPDATE) (#7) > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> 200 (UPDATE) (#8) > >> >>>>>>>>>> Require:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 480 (INVITE) (#9) > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 480 (INVITE (#10) > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> A few things to note: > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N1: The 18x does not contain the SE > >> >>>>>>>>>> (Session-Expires) > >> header > >> >>>>>>>>>> field, > >> >>>>>>>>>> because according to section 4 of RFC 4028 > >> >>>>>>>>>>the header field is only > >> >>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when > >> >>>>>>>>>>the UPDATE request > >> >>>>>>>>>> (#5) is sent, the initial session timer > >> >>>>>>>>>>negotiation is still > >> >>>>>>>>>> ongoing. > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N2: The UPDATE request (#5) contains a > >> >>>>>>>>>> Session-Expires > >> header > >> >>>>>>>>>> field. > >> >>>>>>>>>> Section 7.4 of RFC 4028 says: > >> >>>>>>>>>> > >> >>>>>>>>>> "In a session refresh request sent within a > >> >>>>>>>>>>dialog with an active > >> >>>>>>>>>> session timer, the Session-Expires header field > >> >>>>>>>>>>SHOULD be present." > >> >>>>>>>>>> > >> >>>>>>>>>> Now, a dialog (early) HAS been established when the > >> >>>>>>>>>>UPDATE > >> >>>>>>>> request is > >> >>>>>>>>>> sent, but as the initial session timer > >> >>>>>>>>>>negotiation is still > >> >>>>>>>>>> ongoing, I assume the session timer isn=B9t ye= t > >> >>>>>>>>>>"active"? > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain > >> >>>>>>>>>>the Session-Expires > >> >>>>>>>>>> header field. It is added by the proxy, based > >> >>>>>>>>>>on the procedures in > >> >>>>>>>>>> Section 8.2 of RFC 4028: > >> >>>>>>>>>> > >> >>>>>>>>>> "Because there is no Session-Expires or > >> >>>>>>>>>>Require header field > >> >>>>>>>>>> in the response, the proxy knows that > >> >>>>>>>>>>it is the first > >> >>>>>>>>>> session-timer-aware proxy to receive > >> >>>>>>>>>>the response. > >> >>>>>>>>>> This proxy > >> >>>>>>>>>> MUST insert a Session-Expires header > >> >>>>>>>>>>field into the response > >> >>>>>>>>>> with the value it remembered from the > >> >>>>>>>>>>forwarded request. > >> >>>>>>>>>> It > >> >>>>>>>>>> MUST > >> >>>>>>>>>> set the value of The 'refresher' > >> >>>>>>>>>>parameter to 'uac'. > >> >>>>>>>>>> The proxy MUST > >> >>>>>>>>>> add the 'timer' option tag to any > >> >>>>>>>>>>Require header field in the > >> >>>>>>>>>> response, and if none was present, add > >> >>>>>>>>>>the Require header field with > >> >>>>>>>>>> that value before forwarding it upstream= ." > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> Now, one could argue that the UA should include something > >> >>>>>>>>>> in the UPDATE response (#7), but I think that is not a > >> >>>>>>>>>> solution as the UA may be confused. > >> >>>>>>>>>> Instead, based on my understanding of the text in section > >> >>>>>>>>>> 7.4 (see > >> >>>>>>>>>> above) the UPDATE request (#5) should not contain any > >> session > >> >>>>>>>>>> timer information. This is also more or less what the > >> >>>>>>>>>> errata suggests. > >> >>>>>>>>>> > >> >>>>>>>>>> Comments? > >> >>>>>>>>>> > >> >>>>>>>>>> Regards, > >> >>>>>>>>>> > >> >>>>>>>>>> Christer > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > _______________________________________________ > >> >>>>>>>>>> sipcore mailing list > >> >>>>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> _______________________________________________ > >> >>>>>>>>> sipcore mailing list > >> >>>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>>> > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> sipcore mailing list > >> >>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> sipcore mailing list > >> >>>>>> mailto:sipcore@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> sipcore mailing list > >> >>>>> mailto:sipcore@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> sipcore mailing list > >> >>>> mailto:sipcore@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>> > >> >>> > >> >> > >> > > >> > > >> > >> _______________________________________________ > >> sipcore mailing list > >> mailto:sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B56320A39ESESSMB109erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roland,=

 = ;

I don̵= 7;t think it was unclear that S-E is removed by the transit network –= at least it was not unclear to me :)

 = ;

However, y= our latest call flow is confusing. First, there is a 18x with S-E, which is= not allowed.

 = ;

Second, th= e UPDATEs and 491 seem messed up, so it’s really difficult to parse w= hat is going on, and in what order.

 = ;

Regards,

 = ;

Christer

 = ;

 

From: = Jesske, Roland [mailto:R.Jesske@telekom.de]
Sent: 09 October 2017 16:41
To: Paul Kyzivat <pkyzivat@alum.mit.edu>; Christer Holmberg &l= t;christer.holmberg@ericsson.com>; sipcore@ietf.org
Subject: AW: [sipcore] Session timer fix

 

Hi Paul,

Of course I follow your argumentation. i.E. either act pro= perly or forward the Session timer as received.

For the described scenario

sorry that I confused everybody with an incomplete picture= .

I missed to state that the transit network which is passin= g through the call is deleting the session timer since it does not support = it.

 

 

     Originating   &nbs= p;            &= nbsp;    transit       &n= bsp;            = ;  terminating

UAC         &= nbsp; Proxy1 netA   Proxy2 netB    Proxy3 netB&nbs= p;   Proxy4 netC         UAS &= nbsp;

   |       &n= bsp;            = ;       |      =           |   &= nbsp;         |   &n= bsp;            |&nb= sp; 

   |-- INVITE -->|    &nb= sp;        |    &nbs= p;           |  &nbs= p;          |   = ;             |=     

   |    SE; supp |-- INVITE -->= ;|-- INVITE ----->|-- INVITE -->|-- INVITE (2) ->|  &nbs= p;          

   |       &n= bsp;     |    SE; supp |  &nbs= p; none        |  none   =    |    SE; supp    |

   |       &n= bsp;     |       &nb= sp;     |       &nbs= p;        |     &nbs= p;       |      = ;          |

   |       &n= bsp;     |       &nb= sp;     |<-- 200 (2) ----|<-- 200 (2) -|<--- 2= 00 (2) ---|     

   |<- 18x (2) --|<- 18x (2) --| &nbs= p;             = |  SE 1800;   |   SE 1800;    = ; |

   |   SE 1800;  |  &nb= sp;          |  &nbs= p;             |   U= AS       |      UAS =       |

   |     UAC  &nbs= p;  |           = ;  |           =      |         =     |         &= nbsp;      |

   |-- UPDATE -->|    &nb= sp;        |    &nbs= p;           |  = ;           |   = ;             |=

   |       &n= bsp;     |-- UPDATE -->| <-- UPDATE ----|<-- U= PDATE --|<-- UPDATE -----|       &nbs= p;        

   |       &n= bsp;     |       &nb= sp;     |       &nbs= p;        |

   |       &n= bsp;     |<- UPDATE ---| --- UPDATE --->|--- UPDA= TE ->|--- UPDATE ---->|

   |<- UPDATE ---|    &nb= sp;        |    &nbs= p;           |  &nbs= p;          |   = ;             |=      

   |-- 491   --->|   = ;          |<-- 491 &n= bsp;   ----|<-- 491  ----|<-- 491  -------| =             &nb= sp;            =              &n= bsp; 

   |       &n= bsp;     |-- 491   --->|   =              |&= nbsp;            |&n= bsp;            = ;   |

   |       &n= bsp;     |<-- 491  ----|--- 491  &nbs= p;  --->|<-- 491  --->|--- 491  ------>|

   |<-- 491  ----|   &nbs= p;         |    = ;            | =             | &= nbsp;           &nbs= p;  |

 

 

NetA and NetC does support session timer.

NetB does not.

So Proxy 2 netB will delete the session timer while Proxy = 4 netC will include it again since this is allowed by RFC4028.

On the other way back Proxy3 NetB will delete the informat= ion and Proxy1 NetA will include it again.

 

This will happen when the statefull Proxy rule with sessio= n timer support will be implemented.

 

I hope now it is clear about what scenario I’m talki= ng

 

Best Regards

 

Roland

 

 

> -----Urspr=FCngliche Nachricht-----

> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t> Gesendet: Montag, 9. Oktober 2017 16:19= <= /o:p>

> An: Jesske, Roland <R.Jesske@telekom.de>; Christer Holmberg<= /span>

> Betreff: Re: [sipcore] Session timer fix=

>

> On 10/9/17 5:34 AM, Jesske, Roland wrote:

> > Hi,

> > sorry but I have an further issue where w= e have problems with session

> timer.

> > It is the procedures of stateful Proxy Se= rvers where we can cause a

> > race condition.

> > We have made the observation that due to = the rules we have race

> > conditions with using the session timer.<= /span>=

> > The case is where we have transfer of SIP= messages through an network

> > that is not supporting session timer.

> > Originating network and UAC does support = session timer.

> > Intermediate network does not support ses= sion timer And the

> > terminating network does support session = timer.

> > This may result with the following call f= low.

> > UAC      &n= bsp;    Proxy        &nbs= p;  Proxy         UAS_2=

> >     |   &nb= sp;             = ;          |    = ;            |

> >     |-- INVITE -->|&nbs= p;            | = ;            &n= bsp;  |

> >     |    SE= ; supp |-- INVITE -->|-- INVITE (2) ->|

> >     |   &nb= sp;         |    non= e     |    SE; supp

>

> IIUC you are saying that Proxy1 *removes* the = SE and the timer option from

> the request before forwarding it. Do I have th= at right?

>

> That is more that "not supporting" s= ession timer - that is actively interfering

> with the feature. This is non-compliant behavi= or for a proxy.

>

> A correctly functioning proxy will, if it does= n't understand the option and the

> header, just pass them along as received. The = procedures specified for

> session timer will work properly in that case.=

>

>        Than= ks,

>        Paul=

>

>

> >     |   &nb= sp;         |   &nbs= p;         |    = ;            |=

> >     |   &nb= sp;         |   &nbs= p;         |<-- 200 (2) ----|

> >     |<- 18x (2) --|<= - 18x (2) --|    SE 1800;

> >     |   SE 1800; = ; |             |&nb= sp;     UAS       |=

> >     |   &nb= sp; UAC     |       =       |       &= nbsp;        |

> >     |-- UPDATE -->|&nbs= p;            | = ;            &n= bsp;  |

> >     |    &n= bsp;       |-- UPDATE -->| <-- UPDATE -= ---|

> >     |   &nb= sp;         |   &nbs= p;         |    = ;            |=

> >    |     &n= bsp;      |<- UPDATE ---| --- UPDATE --->|<= o:p>

> >     |<- UPDATE ---|&nbs= p;            | = ;            &n= bsp;  |

> >     |-- 491   --->= |             |= <-- 491     ----|

> >     |   &nb= sp;         |-- 491   --->|=             &nb= sp;   |

> >     |   &nb= sp;         |<-- 491 ----|--- 49= 1   --->|

> >     |<-- 491 ----| = ;            | =             &nb= sp;  | This will happen

> > when the session timer has the same lengt= h.

> > How do we can solve such race conditions.= I see the main problem

> > within the proxy behavior and the Forward= ing of the UPDATE (or

> > re-INVITE) for session refresh.

> > Of course also the choice when the refres= her shall sent the refresh

> > may solve the problem.

> > But if the originating and terminating ne= twork is using the same

> > software vendor the refresh time will be = the same.

> > So seen from that kind of algorithm is ne= eded to generate different

> > session refresh times.

> > Do you see the same problems?=

> > Thank you and Best Regards

> > Roland

> >> -----Urspr=FCngliche Nachricht-----<= o:p>

> >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Pa= ul

> >> Kyzivat

> >> Gesendet: Montag, 9. Oktober 2017 00:= 12

> >> An: Christer Holmberg <christer.holmberg@ericsson.com&g= t;;

> >> Betreff: Re: [sipcore] Session timer = fix

> >>

> >> On 10/5/17 4:37 AM, Christer Holmberg= wrote:

> >> > Hi,

> >> >

> >> >>> …

> >> >>>

> >> >>>> I'll propose that th= e session timer negotiation never be done

> >> >>>> with an UPDATE withi= n an INVITE transaction. (Regardless of

> >> >>>> whether than INVITE = is negotiating a session timer or not.) I

> >> >>>> think this resolves = the problem that you have encountered. (Or

> >> >>>> we could require tha= t the UPDATE and response care consistent

> >> >>>> session timer signal= ing with what is carried in the INVITE and

> >> >>>> its responses.)

> >> >>>

> >> >>> I had a chat with some p= roduct people, and they said that there

> >> >>> actually ARE cases where= the session timer is negotiated using

> >> >>> UPDATE when the initial = INVITE transaction is still ongoing.

> >> >>> There are cases where th= e INVITE only contains Supported:timer,

> >> >>> but the actual negotiati= on is done using UPDATE.

> >> >>

> >> >> Interesting! (I wonder why.)=

> >> >

> >> > I haven’t been able to fig= ure out exactly why. I was just told the

> >> > use-case exists.

> >> >

> >> >

> >> >> That sequence itself present= s some ambiguities. The way I have

> >> >> always described how the ses= sion timer negotiation works is that

> >> >> *every* INVITE and UPDATE tr= ansaction affects s-t - it either

> >> >> negotiates it

> >> >> *on* or else it negotiates i= t *off*. (IMO this makes it very easy

> >> >> to

> >> >> understand.)

> >> >>

> >> >> That presents issues when yo= u have an update nested inside of an

> invite.

> >> >> In the case you describe I m= ight expect that the update would

> >> >> negotiate the timer on, and = then the completion of the invite

> >> >> would negotiate it off again= .> >> >>

> >> >> How would the case you descr= ibe work if a proxy inserted S-E in

> INVITE?

> >> >> In that case, the UAC doesn'= t know about it until the 2xx from the

> >> >> invite. Before then it might= try enabling a timer using UPDATE.

> >> >>

> >> >> I am inclined to keep things= simple by saying that the 2xx

> >> >> response to every INVITE or = UPDATE redefines the state of the

> >> >> session timer, either on or = off. That will of course break the use

> >> >> case you describe

> >> above.

> >> >

> >> > The problem here is that the UAC= sends INVITE with S-E, and then

> >> > receives an UPDATE with S-E befo= re it has received a 2xx response

> >> > to the INVITE - making the UAC t= hink that there is a S-E glare

> >> > situation (i.e., the UAS also tr= ies to initiate session timer negotiation).

> >>

> >> Yes, I understand that is the case yo= u are thinking of. But I was

> >> raising a different case:=

> >>

> >> - the UAC sends an invite without a S= -E.

> >> - a proxy along the path includes an = S-E. (The UAC is unaware.)

> >> - later, the UAC sends an UPDATE with= S-E.

> >>

> >> That violates the rule in your draft,= but the UAC doesn't know it has

> >> violated it. So your rule for avoidin= g the problem in this case doesn't work.

> >>

> >>      &n= bsp; Thanks,

> >>      &n= bsp; Paul

> >>

> >> > I think the RFC is pretty clear = on how things work once the session

> >> > timer has been negotiated (and, = if it isn’t, we for sure can clarify that

> too).

> >> >

> >> > Regards,

> >> >

> >> > Christer

> >> >

> >> >

> >> >

> >> >

> >> >

> >> >>>>>

> >> >>>>> On 07/09/17 19:3= 8, "sipcore on behalf of Christer Holmberg"

> >> >>>>> <sipcore-boun= ces@ietf.org on behalf of

> >> >>>>> wrote:

> >> >>>>>

> >> >>>>>> Hi,

> >> >>>>>><= /span>

> >> >>>>>>>> seen= from my point of view the UAC should ignore the Session

> >> >>>>>>>> time= r proposal within the UPDATE.

> >> >>>>>>>> As l= ong as the negotiation is  ongoing.

> >> >>>>>>>>

> >> >>>>>>>> Neve= rtheless we have also observed this curious session

> >> >>>>>>>> time= r behavior in our network.

> >> >>>>>>>>

> >> >>>>>>>> I th= ink we need some clarifications to the RFC. Perhaps also

> >> >>>>>>>> to o= ther sections to make it more readable.

> >> >>>>>>>> My e= xperience is that people have problems in following how

> >> >>>>>>>> the = session timer should work within a complex SIP networks

> (e.g.

> >> IMS).

> >> >>>>>>>>

> >> >>>>>>>> What= is about updating the RFC4028.

> >> >>>>>>>

> >> >>>>>>> Like mos= t of the older SIP RFCs, it probably deserves an update.

> >> >>>>>>> The prob= lem is whether going to the trouble will have any

> >> >>>>>>> effect o= n implementations. I think the most we > should hope

> >> >>>>>>> to do is=

> >> >>>>>>> *clarify= *> >> >>>>>>> in=

> >> >>>>>>> cases wh= ere there is ambiguity, so that when interoperability

> >> >>>>>>> problems= arise it is clear who needs to change.

> >> >>>>>><= /span>

> >> >>>>>> Yes. In my c= ase, implementation(s) WILL be changed. The

> >> >>>>>> question is = WHICH

> >> >>>>>> implementati= on(s) :)

> >> >>>>>><= /span>

> >> >>>>>> So, my sugge= stion would be:

> >> >>>>>><= /span>

> >> >>>>>> 1) &nbs= p;   Specify/clarify that SE must not be sent during<= /span>

> >> >>>>>> session-time= r negotiation

> >> >>>>>> 2) &nbs= p;   Specify that one must send a 491 (or some other more<= span style=3D"font-size:11.0pt;font-family:"Courier New"">

> >> appropriate

> >> >>>>>> code)= <= /o:p>

> >> >>>>>> response if = receiving SE during session-timer negotiation

> >> >>>>>><= /span>

> >> >>>>>> For the abov= e, I think we can do it using an errata.

> >> >>>>>><= /span>

> >> >>>>>> Regards,

> >> >>>>>><= /span>

> >> >>>>>> Christer

> >> >>>>>><= /span>

> >> >>>>>><= /span>

> >> >>>>>><= /span>

> >> >>>>>>>> ----= -Urspr=FCngliche Nachricht-----

> >> >>>>>>>> Von:= sipcore [mailto:sipcore-bounce= s@ietf.org] Im Auftrag

> >> >>>>>>>> von = Christer Holmberg

> >> >>>>>>>> Gese= ndet: Donnerstag, 7. September 2017 11:34

> >> >>>>>>>> An: = Paul Kyzivat <mailto:pkyzivat@a= lum.mit.edu>;

> >> >>>>>>>> mailto:sipcore@ietf.org=

> >> >>>>>>>> Betr= eff: Re: [sipcore] Session-timer issue

> >> >>>>>>>>

> >> >>>>>>>> Hi,<= /span>=

> >> >>>>>>>>

> >> >>>>>>>>>&= gt; The following issue has been around for some time already

> >> >>>>>>>>>&= gt; (there is also  an errata #4744), and as it causes

> >> >>>>>>>>>&= gt; problems (the INVITE is rejected with a

> >> >>>>>>>>>&= gt; 480 response) in deployed networks, so I think it needs to<= /span>

> >> >>>>>>>>>&= gt; be fixed.

> >> >>>>>>>>>&= gt; People seem to have different opinions on which node is

> >> >>>>>>>>>&= gt; acting wrongly, so  I hope we can sort it out :)

> >> >>>>>>>>><= /span>=

> >> >>>>>>>>> = This is an interesting problem. I agree that it is unclear

> >> >>>>>>>>> = exactly what ought to happen in this case. (But I don't

> >> >>>>>>>>> = understand why someone thinks a 480 is a good way to

> >> >>>>>>>>> = resolve

> >> >>>>>>>>> = it.)

> >> >>>>>>>>

> >> >>>>>>>> Whet= her 480 is the best solution or not is not the issue, in

> >> >>>>>>>> my o= pinion.

> >> >>>>>>>> One = could also claim that the UPDATE should be rejected. Etc.

> >> >>>>>>>>

> >> >>>>>>>> The = issue is that there is a session-timer negotiation "race

> >> >>>>>>>> cond= ition", and we should forbid that (rejecting the UPDATE

> >> >>>>>>>> coul= d be part of such solution).

> >> >>>>>>>>

> >> >>>>>>>> Rega= rds,

> >> >>>>>>>>

> >> >>>>>>>> Chri= ster

> >> >>>>>>>>

> >> >>>>>>>>

> >> >>>>>>>>

> >> >>>>>>>>

> >> >>>>>>>>

> >> >>>>>>>>><= /span>=

> >> >>>>>>>>>&= nbsp;     Thanks,

> >> >>>>>>>>>&= nbsp;     Paul

> >> >>>>>>>>><= /span>=

> >> >>>>>>>>>&= gt; Below is a call flow showing the problem:

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; UA           &nb= sp;    Proxy        =         AS

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; ------------------->

> >> >>>>>>>>>&= gt; INVITE (#1)

> >> >>>>>>>>>&= gt; Supported:timer

> >> >>>>>>>>>&= gt; SE:refresher=3Duac

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; ------------------->

> >> >>>>>>>>>&= gt;            =             &nb= sp; INVITE (#2)

> >> >>>>>>>>>&= gt;            =             &nb= sp; Supported:timer

> >> >>>>>>>>>&= gt;            =             &nb= sp; SE:refresher=3Duac

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; <-------------------

> >> >>>>>>>>>&= gt;            =             &nb= sp; 18x (#3)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; <-------------------

> >> >>>>>>>>>&= gt; 18x (#4)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; ++++++ early dialog established +++= ++++

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; <-------------------

> >> >>>>>>>>>&= gt;            =             &nb= sp; UPDATE (#5)

> >> >>>>>>>>>&= gt;            =             &nb= sp; Supported:timer

> >> >>>>>>>>>&= gt;            =             &nb= sp; SE:refresher=3Duas

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; <-------------------

> >> >>>>>>>>>&= gt; UPDATE (#6)

> >> >>>>>>>>>&= gt; Supported:timer

> >> >>>>>>>>>&= gt; SE:refresher=3Duas

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; ------------------->

> >> >>>>>>>>>&= gt; 200 (UPDATE) (#7)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; ------------------->

> >> >>>>>>>>>&= gt;            =             &nb= sp; 200 (UPDATE) (#8)

> >> >>>>>>>>>&= gt;            =             &nb= sp; Require:timer

> >> >>>>>>>>>&= gt;            =             &nb= sp; SE:refresher=3Duac

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; <-------------------

> >> >>>>>>>>>&= gt;            =             &nb= sp; 480 (INVITE) (#9)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; <-------------------

> >> >>>>>>>>>&= gt; 480 (INVITE (#10)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; A few things to note:

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; N1:        The 18x does not contain = the SE

> >> >>>>>>>>>&= gt; (Session-Expires)

> >> header

> >> >>>>>>>>>&= gt; field,

> >> >>>>>>>>>&= gt;            =   because according to section 4 of RFC 4028

> >> >>>>>>>>>&= gt;the  header field is only

> >> >>>>>>>>>&= gt;            =   allowed in INVITE, UPDATE and 2xx. So, when

> >> >>>>>>>>>&= gt;the  UPDATE request

> >> >>>>>>>>>&= gt;            =   (#5) is sent, the initial session timer

> >> >>>>>>>>>&= gt;negotiation is still

> >> >>>>>>>>>&= gt;            =   ongoing.

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; N2:        The UPDATE request (#5) c= ontains a

> >> >>>>>>>>>&= gt; Session-Expires

> >> header

> >> >>>>>>>>>&= gt; field.

> >> >>>>>>>>>&= gt;            =   Section 7.4 of RFC 4028 says:

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;          "In a sessio= n refresh request sent within a

> >> >>>>>>>>>&= gt;dialog with  an active

> >> >>>>>>>>>&= gt;           session tim= er, the Session-Expires header field

> >> >>>>>>>>>&= gt;SHOULD  be present."

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;     Now, a dialog (early) HAS been established when= the

> >> >>>>>>>>>&= gt;UPDATE

> >> >>>>>>>> requ= est is

> >> >>>>>>>>>&= gt;            =   sent, but as the initial session timer

> >> >>>>>>>>>&= gt;negotiation is still

> >> >>>>>>>>>&= gt;            =   ongoing, I assume the session timer isn=B9t yet

> >> >>>>>>>>>&= gt;"active"?

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; N3:        The UPDATE 200 response (= #7) does not contain

> >> >>>>>>>>>&= gt;the  Session-Expires

> >> >>>>>>>>>&= gt;            =   header field. It is added by the proxy, based

> >> >>>>>>>>>&= gt;on  the procedures in

> >> >>>>>>>>>&= gt;            =   Section 8.2 of RFC 4028:

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =        "Because there is no Session-Expi= res or

> >> >>>>>>>>>&= gt;Require header field

> >> >>>>>>>>>&= gt;            =         in the response, the proxy knows= that

> >> >>>>>>>>>&= gt;it  is the first

> >> >>>>>>>>>&= gt;            =         session-timer-aware proxy to rec= eive

> >> >>>>>>>>>&= gt;the  response.

> >> >>>>>>>>>&= gt; This  proxy

> >> >>>>>>>>>&= gt;            =         MUST insert a Session-Expires he= ader

> >> >>>>>>>>>&= gt;field  into the response

> >> >>>>>>>>>&= gt;            =         with the value it remembered fro= m the

> >> >>>>>>>>>&= gt;forwarded request.

> >> >>>>>>>>>&= gt; It

> >> >>>>>>>>>&= gt; MUST

> >> >>>>>>>>>&= gt;            =         set the value of The 'refresher'=

> >> >>>>>>>>>&= gt;parameter  to 'uac'.

> >> >>>>>>>>>&= gt; The  proxy MUST

> >> >>>>>>>>>&= gt;            =         add the 'timer' option tag to an= y> >> >>>>>>>>>&= gt;Require  header field in  the

> >> >>>>>>>>>&= gt;            =         response, and if none was presen= t, add

> >> >>>>>>>>>&= gt;the  Require header  field with

> >> >>>>>>>>>&= gt;            =         that value before forwarding it = upstream."

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; Now, one could argue that the UA should include something

> >> >>>>>>>>>&= gt; in the UPDATE response (#7), but I think that is not a

> >> >>>>>>>>>&= gt; solution as the UA may be confused.

> >> >>>>>>>>>&= gt; Instead, based on my understanding of the text in section

> >> >>>>>>>>>&= gt; 7.4 (see

> >> >>>>>>>>>&= gt; above) the UPDATE request (#5) should not contain any

> >> session

> >> >>>>>>>>>&= gt; timer information. This is also more or less what the

> >> >>>>>>>>>&= gt; errata suggests.

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; Comments?

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; Regards,

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; Christer

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> ______________________________________________= _> >> >>>>>>>>>&= gt; sipcore mailing list

> >> >>>>>>>>>&= gt; mailto:sipcore@ietf.org=

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>><= /span>=

> >> >>>>>>>>> = _______________________________________________

> >> >>>>>>>>> = sipcore mailing list

> >> >>>>>>>>> mailto:sipcore@ietf.org=

> >> >>>>>>>>

> >> >>>>>>>> ____= ___________________________________________

> >> >>>>>>>> sipc= ore mailing list

> >> >>>>>>>> mailto:sipcore@ietf.org=

> >> >>>>>>>

> >> >>>>>><= /span>

> >> >>>>>> ____________= ___________________________________

> >> >>>>>> sipcore mail= ing list

> >> >>>>>

> >> >>>>> ________________= _______________________________

> >> >>>>> sipcore mailing = list

> >> >>>>>

> >> >>>>

> >> >>>> ____________________= ___________________________

> >> >>>> sipcore mailing list=

> >> >>>

> >> >>>

> >> >>

> >> >

> >> >

> >>

> >> _____________________________________= __________

> >> sipcore mailing list

>

> ______________________________________________= _> sipcore mailing list

 

--_000_7594FB04B1934943A5C02806D1A2204B56320A39ESESSMB109erics_-- From nobody Mon Oct 9 09:08:42 2017 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 2E8A4134E82 for ; Mon, 9 Oct 2017 09:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpHGyBVpPGRw for ; Mon, 9 Oct 2017 09:08:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 52619134F92 for ; Mon, 9 Oct 2017 09:05:18 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-39-59db9e3cecdc Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.EA.03220.C3E9BD95; Mon, 9 Oct 2017 18:05:16 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 18:05:15 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaZ+6AgAEJNoCAAAc9gIAAPEsg Date: Mon, 9 Oct 2017 16:05:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> In-Reply-To: <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2J7lK7NvNuRBnOPaVis2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGk68XWAu+cVVc+3KbsYHxOEcXIweHhICJ xLtXwl2MXBxCAkcYJZ43/WaBcBYySmy6cYIJpIhNwEKi+592FyMnh4hAoMTVJROYQcLCAnIS 7YcsIcLyEut3XmaCsN0kTr+cyAhiswioSDTfn84OYvMK+Ep0r5/IDjH+JqPEhSd72EASnAIO Emte3mYGsRkFxCS+n1oDNohZQFzi1pP5YLaEgIDEkj3nmSFsUYmXj/+xQthKEotuf4aq15FY sPsTG4StLbFs4WtmiMWCEidnPmGZwCgyC8nYWUhaZiFpmYWkZQEjyypG0eLU4qTcdCNjvdSi zOTi4vw8vbzUkk2MwGg4uOW36g7Gy28cDzEKcDAq8fCu7rodKcSaWFZcmXuIUYKDWUmE90kT UIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6YklqdmpqQWpRTBZJg5OqQZG7Q03yhsX fQ6cPsNJgIXf+/JmxnVCrWvnlfjvec663eDE+VCm0Ht1Id6/UlaYWnA/k36yWfjug+uLDOM+ XzV78PtimqZo6+mgzDM2Z8M2ivKt5z66qj26asHiLJ07uWVW0aJ/zW8XH50gdduXlevx+6W3 rsTKvEnZNXty9KYPyROUD522OWj+V4mlOCPRUIu5qDgRAI6WlfqCAgAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 16:08:41 -0000 Hi, >>> Yes, I understand that is the case you are thinking of. But I was=20 >>> raising a different case: >>> >>> - the UAC sends an invite without a S-E. >>> - a proxy along the path includes an S-E. (The UAC is unaware.) >>> - later, the UAC sends an UPDATE with S-E. >>> >>> That violates the rule in your draft, but the UAC doesn't know it has=20 >>> violated it. So your rule for avoiding the problem in this case=20 >>> doesn't work. >>=20 >> Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I=20 >> understand the proxy will never remove S-E from a response. So, we=20 >> could say that the UAC must not send UPDATE with S-E until it has=20 >> received a response to the INVITE. > > The problem is that the rfc only talks about the *final* (2xx) response.= =20 > It has no provision for including the S-E in provisional responses. (It d= oesn't mention provisional responses, and the Table 1 update in section > 4 shows the intent is to exclude it. Hence, if the S-E is inserted into t= he INVITE by a proxy, the UAC won't know that a session timer has been requ= ested until it receives the > final response to the invite. Meanwhile it mi= ght decide send an UPDATE with S-E. My suggestion is that the UAC would not be allowed to send UPDATE with S-E = until it has received the final response for the INVITE.=20 Regards, Christer From nobody Mon Oct 9 09:09:55 2017 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 97A45134662 for ; Mon, 9 Oct 2017 09:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3y7BOuMzfPx for ; Mon, 9 Oct 2017 09:09:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EB1134644 for ; Mon, 9 Oct 2017 09:06:13 -0700 (PDT) X-AuditID: c1b4fb3a-dffff70000006897-f5-59db9e73fa07 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.1F.26775.37E9BD95; Mon, 9 Oct 2017 18:06:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 18:06:10 +0200 From: Christer Holmberg To: Christer Holmberg , "Jesske, Roland" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTQQyohPRgLg6aqEWU+W2OdQNl3qLbrRWggAABsAA= Date: Mon, 9 Oct 2017 16:06:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56320A89@ESESSMB109.ericsson.se> References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <9cd95809-7388-9b8c-8070-83a1ba918b53@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A39@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56320A39@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B56320A89ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7hG7xvNuRBpNmKFms2HCA1aLpTheb xdcfm9gcmD3+vv/A5LFkyU8mj7aXCgHMUVw2Kak5mWWpRfp2CVwZW2afYyw4fZGj4lfnZbYG xpfX2LsYOTkkBEwketcfZ+xi5OIQEjjCKPH3bAMbSEJIYCGjxPXJXF2MHBxsAhYS3f+0QWpE BNYzSiw7vIYZpEZYQEPi89zLYLaIgKbExVPLmCBsK4mz+xcwgtgsAioSux4eYgKZwyvgK/Hl sTnErn5miekLX7CAxDkF/CRe3/QBKWcUEJP4fmoN2BhmAXGJW0/mM0HcKSCxZM95ZghbVOLl 43+sELaSxKLbn6Hq8yUeXegCq+EVEJQ4OfMJywRG4VlIRs1CUjYLSRlEXE/ixtQpbBC2tsSy ha+ZIWxdiRn/DrEgiy9gZF/FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERhTB7f8ttrBePC5 4yFGAQ5GJR7eKV23I4VYE8uKK3MPMUpwMCuJ8D5pAgrxpiRWVqUW5ccXleakFh9ilOZgURLn ddh3IUJIID2xJDU7NbUgtQgmy8TBKdXA6JT9aCdDAl+z/06pdXF/Kt/XSh6M+vNS7Yfmiaxy waetV5cWBwoqioe90DDkOivF0ugRwPVirV/R5pkHmzzPKD1i1HwcyH5ISy9l6oWeop+zOx4G 3WU+Ey6dmHOWdWLR8+fz5m9/57mXMdZEXeDyJqNrmw5pOXXL7fsatnCZ1I0up1Mr5EL9lFiK MxINtZiLihMBQzkdZqUCAAA= Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 16:09:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B56320A89ESESSMB109erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok, when looking at your flow, I assume that the UPDATEs pass each other, h= ence creating the race condition. But, still, are you sending S-E in 18x, or is that a mistake in the flow? From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 09 October 2017 18:01 To: Jesske, Roland ; Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] Session timer fix Hi Roland, I don't think it was unclear that S-E is removed by the transit network - a= t least it was not unclear to me :) However, your latest call flow is confusing. First, there is a 18x with S-E= , which is not allowed. Second, the UPDATEs and 491 seem messed up, so it's really difficult to par= se what is going on, and in what order. Regards, Christer From: Jesske, Roland [mailto:R.Jesske@telekom.de] Sent: 09 October 2017 16:41 To: Paul Kyzivat >; Chr= ister Holmberg >; sipcore@ietf.org Subject: AW: [sipcore] Session timer fix Hi Paul, Of course I follow your argumentation. i.E. either act properly or forward = the Session timer as received. For the described scenario sorry that I confused everybody with an incomplete picture. I missed to state that the transit network which is passing through the cal= l is deleting the session timer since it does not support it. Originating transit terminati= ng UAC Proxy1 netA Proxy2 netB Proxy3 netB Proxy4 netC = UAS | | | | = | |-- INVITE -->| | | | = | | SE; supp |-- INVITE -->|-- INVITE ----->|-- INVITE -->|-- INVITE (2= ) ->| | | SE; supp | none | none | SE; supp= | | | | | | = | | | |<-- 200 (2) ----|<-- 200 (2) -|<--- 200 (2)= ---| |<- 18x (2) --|<- 18x (2) --| | SE 1800; | SE 1800; = | | SE 1800; | | | UAS | UAS = | | UAC | | | | = | |-- UPDATE -->| | | | = | | |-- UPDATE -->| <-- UPDATE ----|<-- UPDATE --|<-- UPDATE -= ----| | | | | | |<- UPDATE ---| --- UPDATE --->|--- UPDATE ->|--- UPDATE -= --->| |<- UPDATE ---| | | | = | |-- 491 --->| |<-- 491 ----|<-- 491 ----|<-- 491 ---= ----| | |-- 491 --->| | | = | | |<-- 491 ----|--- 491 --->|<-- 491 --->|--- 491 ---= --->| |<-- 491 ----| | | | = | NetA and NetC does support session timer. NetB does not. So Proxy 2 netB will delete the session timer while Proxy 4 netC will inclu= de it again since this is allowed by RFC4028. On the other way back Proxy3 NetB will delete the information and Proxy1 Ne= tA will include it again. This will happen when the statefull Proxy rule with session timer support w= ill be implemented. I hope now it is clear about what scenario I'm talking Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Montag, 9. Oktober 2017 16:19 > An: Jesske, Roland >; Chr= ister Holmberg > >; = sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix > > On 10/9/17 5:34 AM, Jesske, Roland wrote: > > Hi, > > sorry but I have an further issue where we have problems with session > timer. > > It is the procedures of stateful Proxy Servers where we can cause a > > race condition. > > We have made the observation that due to the rules we have race > > conditions with using the session timer. > > The case is where we have transfer of SIP messages through an network > > that is not supporting session timer. > > Originating network and UAC does support session timer. > > Intermediate network does not support session timer And the > > terminating network does support session timer. > > This may result with the following call flow. > > UAC Proxy Proxy UAS_2 > > | | | > > |-- INVITE -->| | | > > | SE; supp |-- INVITE -->|-- INVITE (2) ->| > > | | none | SE; supp > > IIUC you are saying that Proxy1 *removes* the SE and the timer option fro= m > the request before forwarding it. Do I have that right? > > That is more that "not supporting" session timer - that is actively inter= fering > with the feature. This is non-compliant behavior for a proxy. > > A correctly functioning proxy will, if it doesn't understand the option a= nd the > header, just pass them along as received. The procedures specified for > session timer will work properly in that case. > > Thanks, > Paul > > > > | | | | > > | | |<-- 200 (2) ----| > > |<- 18x (2) --|<- 18x (2) --| SE 1800; > > | SE 1800; | | UAS | > > | UAC | | | > > |-- UPDATE -->| | | > > | |-- UPDATE -->| <-- UPDATE ----| > > | | | | > > | |<- UPDATE ---| --- UPDATE --->| > > |<- UPDATE ---| | | > > |-- 491 --->| |<-- 491 ----| > > | |-- 491 --->| | > > | |<-- 491 ----|--- 491 --->| > > |<-- 491 ----| | | This will happen > > when the session timer has the same length. > > How do we can solve such race conditions. I see the main problem > > within the proxy behavior and the Forwarding of the UPDATE (or > > re-INVITE) for session refresh. > > Of course also the choice when the refresher shall sent the refresh > > may solve the problem. > > But if the originating and terminating network is using the same > > software vendor the refresh time will be the same. > > So seen from that kind of algorithm is needed to generate different > > session refresh times. > > Do you see the same problems? > > Thank you and Best Regards > > Roland > >> -----Urspr=FCngliche Nachricht----- > >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul > >> Kyzivat > >> Gesendet: Montag, 9. Oktober 2017 00:12 > >> An: Christer Holmberg >; > >> sipcore@ietf.org > >> Betreff: Re: [sipcore] Session timer fix > >> > >> On 10/5/17 4:37 AM, Christer Holmberg wrote: > >> > Hi, > >> > > >> >>> ... > >> >>> > >> >>>> I'll propose that the session timer negotiation never be done > >> >>>> with an UPDATE within an INVITE transaction. (Regardless of > >> >>>> whether than INVITE is negotiating a session timer or not.) I > >> >>>> think this resolves the problem that you have encountered. (Or > >> >>>> we could require that the UPDATE and response care consistent > >> >>>> session timer signaling with what is carried in the INVITE and > >> >>>> its responses.) > >> >>> > >> >>> I had a chat with some product people, and they said that there > >> >>> actually ARE cases where the session timer is negotiated using > >> >>> UPDATE when the initial INVITE transaction is still ongoing. > >> >>> There are cases where the INVITE only contains Supported:timer, > >> >>> but the actual negotiation is done using UPDATE. > >> >> > >> >> Interesting! (I wonder why.) > >> > > >> > I haven't been able to figure out exactly why. I was just told the > >> > use-case exists. > >> > > >> > > >> >> That sequence itself presents some ambiguities. The way I have > >> >> always described how the session timer negotiation works is that > >> >> *every* INVITE and UPDATE transaction affects s-t - it either > >> >> negotiates it > >> >> *on* or else it negotiates it *off*. (IMO this makes it very easy > >> >> to > >> >> understand.) > >> >> > >> >> That presents issues when you have an update nested inside of an > invite. > >> >> In the case you describe I might expect that the update would > >> >> negotiate the timer on, and then the completion of the invite > >> >> would negotiate it off again. > >> >> > >> >> How would the case you describe work if a proxy inserted S-E in > INVITE? > >> >> In that case, the UAC doesn't know about it until the 2xx from the > >> >> invite. Before then it might try enabling a timer using UPDATE. > >> >> > >> >> I am inclined to keep things simple by saying that the 2xx > >> >> response to every INVITE or UPDATE redefines the state of the > >> >> session timer, either on or off. That will of course break the use > >> >> case you describe > >> above. > >> > > >> > The problem here is that the UAC sends INVITE with S-E, and then > >> > receives an UPDATE with S-E before it has received a 2xx response > >> > to the INVITE - making the UAC think that there is a S-E glare > >> > situation (i.e., the UAS also tries to initiate session timer negoti= ation). > >> > >> Yes, I understand that is the case you are thinking of. But I was > >> raising a different case: > >> > >> - the UAC sends an invite without a S-E. > >> - a proxy along the path includes an S-E. (The UAC is unaware.) > >> - later, the UAC sends an UPDATE with S-E. > >> > >> That violates the rule in your draft, but the UAC doesn't know it has > >> violated it. So your rule for avoiding the problem in this case doesn'= t work. > >> > >> Thanks, > >> Paul > >> > >> > I think the RFC is pretty clear on how things work once the session > >> > timer has been negotiated (and, if it isn't, we for sure can clarify= that > too). > >> > > >> > Regards, > >> > > >> > Christer > >> > > >> > > >> > > >> > > >> > > >> >>>>> > >> >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > >> >>>>> >> >>>>> mailto:christer.holmberg@ericsson.com> > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>>>> seen from my point of view the UAC should ignore the Session > >> >>>>>>>> timer proposal within the UPDATE. > >> >>>>>>>> As long as the negotiation is ongoing. > >> >>>>>>>> > >> >>>>>>>> Nevertheless we have also observed this curious session > >> >>>>>>>> timer behavior in our network. > >> >>>>>>>> > >> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also > >> >>>>>>>> to other sections to make it more readable. > >> >>>>>>>> My experience is that people have problems in following how > >> >>>>>>>> the session timer should work within a complex SIP networks > (e.g. > >> IMS). > >> >>>>>>>> > >> >>>>>>>> What is about updating the RFC4028. > >> >>>>>>> > >> >>>>>>> Like most of the older SIP RFCs, it probably deserves an updat= e. > >> >>>>>>> The problem is whether going to the trouble will have any > >> >>>>>>> effect on implementations. I think the most we > should hope > >> >>>>>>> to do is > >> >>>>>>> *clarify* > >> >>>>>>> in > >> >>>>>>> cases where there is ambiguity, so that when interoperability > >> >>>>>>> problems arise it is clear who needs to change. > >> >>>>>> > >> >>>>>> Yes. In my case, implementation(s) WILL be changed. The > >> >>>>>> question is WHICH > >> >>>>>> implementation(s) :) > >> >>>>>> > >> >>>>>> So, my suggestion would be: > >> >>>>>> > >> >>>>>> 1) Specify/clarify that SE must not be sent during > >> >>>>>> session-timer negotiation > >> >>>>>> 2) Specify that one must send a 491 (or some other more > >> appropriate > >> >>>>>> code) > >> >>>>>> response if receiving SE during session-timer negotiation > >> >>>>>> > >> >>>>>> For the above, I think we can do it using an errata. > >> >>>>>> > >> >>>>>> Regards, > >> >>>>>> > >> >>>>>> Christer > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>>>> -----Urspr=FCngliche Nachricht----- > >> >>>>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag > >> >>>>>>>> von Christer Holmberg > >> >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 > >> >>>>>>>> An: Paul Kyzivat ; > >> >>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>> Betreff: Re: [sipcore] Session-timer issue > >> >>>>>>>> > >> >>>>>>>> Hi, > >> >>>>>>>> > >> >>>>>>>>>> The following issue has been around for some time already > >> >>>>>>>>>> (there is also an errata #4744), and as it causes > >> >>>>>>>>>> problems (the INVITE is rejected with a > >> >>>>>>>>>> 480 response) in deployed networks, so I think it needs to > >> >>>>>>>>>> be fixed. > >> >>>>>>>>>> People seem to have different opinions on which node is > >> >>>>>>>>>> acting wrongly, so I hope we can sort it out :) > >> >>>>>>>>> > >> >>>>>>>>> This is an interesting problem. I agree that it is unclear > >> >>>>>>>>> exactly what ought to happen in this case. (But I don't > >> >>>>>>>>> understand why someone thinks a 480 is a good way to > >> >>>>>>>>> resolve > >> >>>>>>>>> it.) > >> >>>>>>>> > >> >>>>>>>> Whether 480 is the best solution or not is not the issue, in > >> >>>>>>>> my opinion. > >> >>>>>>>> One could also claim that the UPDATE should be rejected. Etc. > >> >>>>>>>> > >> >>>>>>>> The issue is that there is a session-timer negotiation "race > >> >>>>>>>> condition", and we should forbid that (rejecting the UPDATE > >> >>>>>>>> could be part of such solution). > >> >>>>>>>> > >> >>>>>>>> Regards, > >> >>>>>>>> > >> >>>>>>>> Christer > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> Thanks, > >> >>>>>>>>> Paul > >> >>>>>>>>> > >> >>>>>>>>>> Below is a call flow showing the problem: > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> UA Proxy AS > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> INVITE (#1) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> INVITE (#2) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 18x (#3) > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 18x (#4) > >> >>>>>>>>>> > >> >>>>>>>>>> ++++++ early dialog established +++++++ > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> UPDATE (#5) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duas > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> UPDATE (#6) > >> >>>>>>>>>> Supported:timer > >> >>>>>>>>>> SE:refresher=3Duas > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> 200 (UPDATE) (#7) > >> >>>>>>>>>> > >> >>>>>>>>>> -------------------> > >> >>>>>>>>>> 200 (UPDATE) (#8) > >> >>>>>>>>>> Require:timer > >> >>>>>>>>>> SE:refresher=3Duac > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 480 (INVITE) (#9) > >> >>>>>>>>>> > >> >>>>>>>>>> <------------------- > >> >>>>>>>>>> 480 (INVITE (#10) > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> A few things to note: > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N1: The 18x does not contain the SE > >> >>>>>>>>>> (Session-Expires) > >> header > >> >>>>>>>>>> field, > >> >>>>>>>>>> because according to section 4 of RFC 4028 > >> >>>>>>>>>>the header field is only > >> >>>>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when > >> >>>>>>>>>>the UPDATE request > >> >>>>>>>>>> (#5) is sent, the initial session timer > >> >>>>>>>>>>negotiation is still > >> >>>>>>>>>> ongoing. > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N2: The UPDATE request (#5) contains a > >> >>>>>>>>>> Session-Expires > >> header > >> >>>>>>>>>> field. > >> >>>>>>>>>> Section 7.4 of RFC 4028 says: > >> >>>>>>>>>> > >> >>>>>>>>>> "In a session refresh request sent within a > >> >>>>>>>>>>dialog with an active > >> >>>>>>>>>> session timer, the Session-Expires header field > >> >>>>>>>>>>SHOULD be present." > >> >>>>>>>>>> > >> >>>>>>>>>> Now, a dialog (early) HAS been established when the > >> >>>>>>>>>>UPDATE > >> >>>>>>>> request is > >> >>>>>>>>>> sent, but as the initial session timer > >> >>>>>>>>>>negotiation is still > >> >>>>>>>>>> ongoing, I assume the session timer isn=B9t ye= t > >> >>>>>>>>>>"active"? > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> N3: The UPDATE 200 response (#7) does not contain > >> >>>>>>>>>>the Session-Expires > >> >>>>>>>>>> header field. It is added by the proxy, based > >> >>>>>>>>>>on the procedures in > >> >>>>>>>>>> Section 8.2 of RFC 4028: > >> >>>>>>>>>> > >> >>>>>>>>>> "Because there is no Session-Expires or > >> >>>>>>>>>>Require header field > >> >>>>>>>>>> in the response, the proxy knows that > >> >>>>>>>>>>it is the first > >> >>>>>>>>>> session-timer-aware proxy to receive > >> >>>>>>>>>>the response. > >> >>>>>>>>>> This proxy > >> >>>>>>>>>> MUST insert a Session-Expires header > >> >>>>>>>>>>field into the response > >> >>>>>>>>>> with the value it remembered from the > >> >>>>>>>>>>forwarded request. > >> >>>>>>>>>> It > >> >>>>>>>>>> MUST > >> >>>>>>>>>> set the value of The 'refresher' > >> >>>>>>>>>>parameter to 'uac'. > >> >>>>>>>>>> The proxy MUST > >> >>>>>>>>>> add the 'timer' option tag to any > >> >>>>>>>>>>Require header field in the > >> >>>>>>>>>> response, and if none was present, add > >> >>>>>>>>>>the Require header field with > >> >>>>>>>>>> that value before forwarding it upstream= ." > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> Now, one could argue that the UA should include something > >> >>>>>>>>>> in the UPDATE response (#7), but I think that is not a > >> >>>>>>>>>> solution as the UA may be confused. > >> >>>>>>>>>> Instead, based on my understanding of the text in section > >> >>>>>>>>>> 7.4 (see > >> >>>>>>>>>> above) the UPDATE request (#5) should not contain any > >> session > >> >>>>>>>>>> timer information. This is also more or less what the > >> >>>>>>>>>> errata suggests. > >> >>>>>>>>>> > >> >>>>>>>>>> Comments? > >> >>>>>>>>>> > >> >>>>>>>>>> Regards, > >> >>>>>>>>>> > >> >>>>>>>>>> Christer > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > _______________________________________________ > >> >>>>>>>>>> sipcore mailing list > >> >>>>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> _______________________________________________ > >> >>>>>>>>> sipcore mailing list > >> >>>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>>> > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> sipcore mailing list > >> >>>>>>>> mailto:sipcore@ietf.org > >> >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> sipcore mailing list > >> >>>>>> mailto:sipcore@ietf.org > >> >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> sipcore mailing list > >> >>>>> mailto:sipcore@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> sipcore mailing list > >> >>>> mailto:sipcore@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/sipcore > >> >>> > >> >>> > >> >> > >> > > >> > > >> > >> _______________________________________________ > >> sipcore mailing list > >> mailto:sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B56320A89ESESSMB109erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ok, when l= ooking at your flow, I assume that the UPDATEs pass each other, hence creat= ing the race condition.

 = ;

But, still= , are you sending S-E in 18x, or is that a mistake in the flow?<= /span>

 

From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 09 October 2017 18:01
To: Jesske, Roland <R.Jesske@telekom.de>; Paul Kyzivat <pky= zivat@alum.mit.edu>; sipcore@ietf.org
Subject: Re: [sipcore] Session timer fix

 

Hi Roland,=

 

I don̵= 7;t think it was unclear that S-E is removed by the transit network –= at least it was not unclear to me :)

 

However, y= our latest call flow is confusing. First, there is a 18x with S-E, which is= not allowed.

 

Second, th= e UPDATEs and 491 seem messed up, so it’s really difficult to parse w= hat is going on, and in what order.

 

Regards,

 

Christer

 

 

From: = Jesske, Roland [mailto:R.Jesske@tele= kom.de]
Sent: 09 October 2017 16:41
To: Paul Kyzivat <pkyziv= at@alum.mit.edu>; Christer Holmberg <christer.holmberg@ericsson.com>; sipcore@ietf.org
Subject: AW: [sipcore] Session timer fix

 

Hi Paul,

Of course I follow your argumentation. i.E. either act pro= perly or forward the Session timer as received.

For the described scenario

sorry that I confused everybody with an incomplete picture= .

I missed to state that the transit network which is passin= g through the call is deleting the session timer since it does not support = it.

 

 

     Originating   &nbs= p;            &= nbsp;    transit       &n= bsp;            = ;  terminating

UAC         &= nbsp; Proxy1 netA   Proxy2 netB    Proxy3 netB&nbs= p;   Proxy4 netC         UAS &= nbsp;

   |       &n= bsp;            = ;       |      =           |   &= nbsp;         |   &n= bsp;            |&nb= sp; 

   |-- INVITE -->|    &nb= sp;        |    &nbs= p;           |  &nbs= p;          |   = ;             |=     

   |    SE; supp |-- INVITE -->= ;|-- INVITE ----->|-- INVITE -->|-- INVITE (2) ->|  &nbs= p;          

   |       &n= bsp;     |    SE; supp |  &nbs= p; none        |  none   =    |    SE; supp    |<= /o:p>

   |       &n= bsp;     |       &nb= sp;     |       &nbs= p;        |     &nbs= p;       |      = ;          |

   |       &n= bsp;     |       &nb= sp;     |<-- 200 (2) ----|<-- 200 (2) -|<--- 2= 00 (2) ---|     

   |<- 18x (2) --|<- 18x (2) --| &nbs= p;             = |  SE 1800;   |   SE 1800;    = ; |

   |   SE 1800;  |  &nb= sp;          |  &nbs= p;             |   U= AS       |      UAS =       |

   |     UAC  &nbs= p;  |           = ;  |           =      |         =     |         &= nbsp;      |

   |-- UPDATE -->|    &nb= sp;        |    &nbs= p;           |  = ;           |   = ;             |=

   |       &n= bsp;     |-- UPDATE -->| <-- UPDATE ----|<-- U= PDATE --|<-- UPDATE -----|       &nbs= p;        

   |       &n= bsp;     |       &nb= sp;     |       &nbs= p;        |

   |       &n= bsp;     |<- UPDATE ---| --- UPDATE --->|--- UPDA= TE ->|--- UPDATE ---->|

   |<- UPDATE ---|    &nb= sp;        |    &nbs= p;           |  &nbs= p;          |   = ;             |=      

   |-- 491   --->|   = ;          |<-- 491 &n= bsp;   ----|<-- 491  ----|<-- 491  -------| =             &nb= sp;            =              &n= bsp; 

   |       &n= bsp;     |-- 491   --->|   =              |&= nbsp;            |&n= bsp;            = ;   |

   |       &n= bsp;     |<-- 491  ----|--- 491  &nbs= p;  --->|<-- 491  --->|--- 491  ------>|<= o:p>

   |<-- 491  ----|   &nbs= p;         |    = ;            | =             | &= nbsp;           &nbs= p;  |

 

 

NetA and NetC does support session timer.

NetB does not.

So Proxy 2 netB will delete the session timer while Proxy = 4 netC will include it again since this is allowed by RFC4028.<= /o:p>

On the other way back Proxy3 NetB will delete the informat= ion and Proxy1 NetA will include it again.

 

This will happen when the statefull Proxy rule with sessio= n timer support will be implemented.

 

I hope now it is clear about what scenario I’m talki= ng

 

Best Regards

 

Roland

 

 

> -----Urspr=FCngliche Nachricht-----

> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t

> Gesendet: Montag, 9. Oktober 2017 16:19=

> An: Jesske, Roland <R.Jesske@telekom.de>; Christer Holmberg<= /o:p>

> Betreff: Re: [sipcore] Session timer fix

>

> On 10/9/17 5:34 AM, Jesske, Roland wrote:

> > Hi,

> > sorry but I have an further issue where w= e have problems with session

> timer.

> > It is the procedures of stateful Proxy Se= rvers where we can cause a

> > race condition.

> > We have made the observation that due to = the rules we have race

> > conditions with using the session timer.<= /span>

> > The case is where we have transfer of SIP= messages through an network

> > that is not supporting session timer.

> > Originating network and UAC does support = session timer.

> > Intermediate network does not support ses= sion timer And the

> > terminating network does support session = timer.

> > This may result with the following call f= low.

> > UAC      &n= bsp;    Proxy        &nbs= p;  Proxy         UAS_2=

> >     |   &nb= sp;             = ;          |    = ;            |

> >     |-- INVITE -->|&nbs= p;            | = ;            &n= bsp;  |

> >     |    SE= ; supp |-- INVITE -->|-- INVITE (2) ->|

> >     |   &nb= sp;         |    non= e     |    SE; supp

>

> IIUC you are saying that Proxy1 *removes* the = SE and the timer option from

> the request before forwarding it. Do I have th= at right?

>

> That is more that "not supporting" s= ession timer - that is actively interfering

> with the feature. This is non-compliant behavi= or for a proxy.

>

> A correctly functioning proxy will, if it does= n't understand the option and the

> header, just pass them along as received. The = procedures specified for

> session timer will work properly in that case.=

>

>        Than= ks,

>        Paul=

>

>

> >     |   &nb= sp;         |   &nbs= p;         |    = ;            |

> >     |   &nb= sp;         |   &nbs= p;         |<-- 200 (2) ----|

> >     |<- 18x (2) --|<= - 18x (2) --|    SE 1800;

> >     |   SE 1800; = ; |             |&nb= sp;     UAS       |

> >     |   &nb= sp; UAC     |       =       |       &= nbsp;        |

> >     |-- UPDATE -->|&nbs= p;            | = ;            &n= bsp;  |

> >     |    &n= bsp;       |-- UPDATE -->| <-- UPDATE -= ---|

> >     |   &nb= sp;         |   &nbs= p;         |    = ;            |

> >    |     &n= bsp;      |<- UPDATE ---| --- UPDATE --->|

> >     |<- UPDATE ---|&nbs= p;            | = ;            &n= bsp;  |

> >     |-- 491   --->= |             |= <-- 491     ----|

> >     |   &nb= sp;         |-- 491   --->|=             &nb= sp;   |

> >     |   &nb= sp;         |<-- 491 ----|--- 49= 1   --->|

> >     |<-- 491 ----| = ;            | =             &nb= sp;  | This will happen

> > when the session timer has the same lengt= h.

> > How do we can solve such race conditions.= I see the main problem

> > within the proxy behavior and the Forward= ing of the UPDATE (or

> > re-INVITE) for session refresh.

> > Of course also the choice when the refres= her shall sent the refresh

> > may solve the problem.<= /p>

> > But if the originating and terminating ne= twork is using the same

> > software vendor the refresh time will be = the same.

> > So seen from that kind of algorithm is ne= eded to generate different

> > session refresh times.<= /p>

> > Do you see the same problems?=

> > Thank you and Best Regards

> > Roland

> >> -----Urspr=FCngliche Nachricht-----

> >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Pa= ul

> >> Kyzivat

> >> Gesendet: Montag, 9. Oktober 2017 00:= 12

> >> An: Christer Holmberg <christer.holmberg@ericsson.com&g= t;;

> >> sipcore@ietf.org<= /p>

> >> Betreff: Re: [sipcore] Session timer = fix

> >>

> >> On 10/5/17 4:37 AM, Christer Holmberg= wrote:

> >> > Hi,

> >> >

> >> >>> …

> >> >>>

> >> >>>> I'll propose that th= e session timer negotiation never be done

> >> >>>> with an UPDATE withi= n an INVITE transaction. (Regardless of

> >> >>>> whether than INVITE = is negotiating a session timer or not.) I

> >> >>>> think this resolves = the problem that you have encountered. (Or

> >> >>>> we could require tha= t the UPDATE and response care consistent

> >> >>>> session timer signal= ing with what is carried in the INVITE and

> >> >>>> its responses.)

> >> >>>

> >> >>> I had a chat with some p= roduct people, and they said that there

> >> >>> actually ARE cases where= the session timer is negotiated using

> >> >>> UPDATE when the initial = INVITE transaction is still ongoing.

> >> >>> There are cases where th= e INVITE only contains Supported:timer,

> >> >>> but the actual negotiati= on is done using UPDATE.

> >> >>

> >> >> Interesting! (I wonder why.)=

> >> >

> >> > I haven’t been able to fig= ure out exactly why. I was just told the

> >> > use-case exists.

> >> >

> >> >

> >> >> That sequence itself present= s some ambiguities. The way I have

> >> >> always described how the ses= sion timer negotiation works is that

> >> >> *every* INVITE and UPDATE tr= ansaction affects s-t - it either

> >> >> negotiates it

> >> >> *on* or else it negotiates i= t *off*. (IMO this makes it very easy

> >> >> to

> >> >> understand.)

> >> >>

> >> >> That presents issues when yo= u have an update nested inside of an

> invite.

> >> >> In the case you describe I m= ight expect that the update would

> >> >> negotiate the timer on, and = then the completion of the invite

> >> >> would negotiate it off again= .

> >> >>

> >> >> How would the case you descr= ibe work if a proxy inserted S-E in

> INVITE?

> >> >> In that case, the UAC doesn'= t know about it until the 2xx from the

> >> >> invite. Before then it might= try enabling a timer using UPDATE.

> >> >>

> >> >> I am inclined to keep things= simple by saying that the 2xx

> >> >> response to every INVITE or = UPDATE redefines the state of the

> >> >> session timer, either on or = off. That will of course break the use

> >> >> case you describe

> >> above.

> >> >

> >> > The problem here is that the UAC= sends INVITE with S-E, and then

> >> > receives an UPDATE with S-E befo= re it has received a 2xx response

> >> > to the INVITE - making the UAC t= hink that there is a S-E glare

> >> > situation (i.e., the UAS also tr= ies to initiate session timer negotiation).

> >>

> >> Yes, I understand that is the case yo= u are thinking of. But I was

> >> raising a different case:=

> >>

> >> - the UAC sends an invite without a S= -E.

> >> - a proxy along the path includes an = S-E. (The UAC is unaware.)

> >> - later, the UAC sends an UPDATE with= S-E.

> >>

> >> That violates the rule in your draft,= but the UAC doesn't know it has

> >> violated it. So your rule for avoidin= g the problem in this case doesn't work.

> >>

> >>      &n= bsp; Thanks,

> >>      &n= bsp; Paul

> >>

> >> > I think the RFC is pretty clear = on how things work once the session

> >> > timer has been negotiated (and, = if it isn’t, we for sure can clarify that

> too).

> >> >

> >> > Regards,

> >> >

> >> > Christer

> >> >

> >> >

> >> >

> >> >

> >> >

> >> >>>>>

> >> >>>>> On 07/09/17 19:3= 8, "sipcore on behalf of Christer Holmberg"

> >> >>>>> <sipcore-boun= ces@ietf.org on behalf of

> >> >>>>> wrote:

> >> >>>>>

> >> >>>>>> Hi,

> >> >>>>>><= /o:p>

> >> >>>>>>>> seen= from my point of view the UAC should ignore the Session<= /p>

> >> >>>>>>>> time= r proposal within the UPDATE.

> >> >>>>>>>> As l= ong as the negotiation is  ongoing.

> >> >>>>>>>>

> >> >>>>>>>> Neve= rtheless we have also observed this curious session

> >> >>>>>>>> time= r behavior in our network.

> >> >>>>>>>>

> >> >>>>>>>> I th= ink we need some clarifications to the RFC. Perhaps also<= /p>

> >> >>>>>>>> to o= ther sections to make it more readable.

> >> >>>>>>>> My e= xperience is that people have problems in following how

> >> >>>>>>>> the = session timer should work within a complex SIP networks

> (e.g.

> >> IMS).

> >> >>>>>>>>

> >> >>>>>>>> What= is about updating the RFC4028.

> >> >>>>>>>

> >> >>>>>>> Like mos= t of the older SIP RFCs, it probably deserves an update.<= /p>

> >> >>>>>>> The prob= lem is whether going to the trouble will have any

> >> >>>>>>> effect o= n implementations. I think the most we > should hope

> >> >>>>>>> to do is=

> >> >>>>>>> *clarify= *

> >> >>>>>>> in

> >> >>>>>>> cases wh= ere there is ambiguity, so that when interoperability

> >> >>>>>>> problems= arise it is clear who needs to change.

> >> >>>>>><= /o:p>

> >> >>>>>> Yes. In my c= ase, implementation(s) WILL be changed. The

> >> >>>>>> question is = WHICH

> >> >>>>>> implementati= on(s) :)

> >> >>>>>><= /o:p>

> >> >>>>>> So, my sugge= stion would be:

> >> >>>>>><= /o:p>

> >> >>>>>> 1) &nbs= p;   Specify/clarify that SE must not be sent during<= /o:p>

> >> >>>>>> session-time= r negotiation

> >> >>>>>> 2) &nbs= p;   Specify that one must send a 491 (or some other more<= o:p>

> >> appropriate

> >> >>>>>> code)=

> >> >>>>>> response if = receiving SE during session-timer negotiation

> >> >>>>>><= /o:p>

> >> >>>>>> For the abov= e, I think we can do it using an errata.

> >> >>>>>><= /o:p>

> >> >>>>>> Regards,

> >> >>>>>><= /o:p>

> >> >>>>>> Christer

> >> >>>>>><= /o:p>

> >> >>>>>><= /o:p>

> >> >>>>>><= /o:p>

> >> >>>>>>>> ----= -Urspr=FCngliche Nachricht-----

> >> >>>>>>>> Von:= sipcore [mailto:sipcore-bounce= s@ietf.org] Im Auftrag

> >> >>>>>>>> von = Christer Holmberg

> >> >>>>>>>> Gese= ndet: Donnerstag, 7. September 2017 11:34

> >> >>>>>>>> An: = Paul Kyzivat <mailto:pkyzivat@a= lum.mit.edu>;

> >> >>>>>>>> mailto:sipcore@ietf.org=

> >> >>>>>>>> Betr= eff: Re: [sipcore] Session-timer issue

> >> >>>>>>>>

> >> >>>>>>>> Hi,<= /span>

> >> >>>>>>>>

> >> >>>>>>>>>&= gt; The following issue has been around for some time already

> >> >>>>>>>>>&= gt; (there is also  an errata #4744), and as it causes

> >> >>>>>>>>>&= gt; problems (the INVITE is rejected with a

> >> >>>>>>>>>&= gt; 480 response) in deployed networks, so I think it needs to<= /o:p>

> >> >>>>>>>>>&= gt; be fixed.

> >> >>>>>>>>>&= gt; People seem to have different opinions on which node is

> >> >>>>>>>>>&= gt; acting wrongly, so  I hope we can sort it out :)=

> >> >>>>>>>>><= /span>

> >> >>>>>>>>> = This is an interesting problem. I agree that it is unclear

> >> >>>>>>>>> = exactly what ought to happen in this case. (But I don't

> >> >>>>>>>>> = understand why someone thinks a 480 is a good way to

> >> >>>>>>>>> = resolve

> >> >>>>>>>>> = it.)

> >> >>>>>>>>

> >> >>>>>>>> Whet= her 480 is the best solution or not is not the issue, in<= /p>

> >> >>>>>>>> my o= pinion.

> >> >>>>>>>> One = could also claim that the UPDATE should be rejected. Etc.=

> >> >>>>>>>>

> >> >>>>>>>> The = issue is that there is a session-timer negotiation "race

> >> >>>>>>>> cond= ition", and we should forbid that (rejecting the UPDATE

> >> >>>>>>>> coul= d be part of such solution).

> >> >>>>>>>>

> >> >>>>>>>> Rega= rds,

> >> >>>>>>>>

> >> >>>>>>>> Chri= ster

> >> >>>>>>>>

> >> >>>>>>>>

> >> >>>>>>>>

> >> >>>>>>>>

> >> >>>>>>>>

> >> >>>>>>>>><= /span>

> >> >>>>>>>>>&= nbsp;     Thanks,

> >> >>>>>>>>>&= nbsp;     Paul

> >> >>>>>>>>><= /span>

> >> >>>>>>>>>&= gt; Below is a call flow showing the problem:

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; UA           &nb= sp;    Proxy        =         AS

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; ------------------->

> >> >>>>>>>>>&= gt; INVITE (#1)

> >> >>>>>>>>>&= gt; Supported:timer

> >> >>>>>>>>>&= gt; SE:refresher=3Duac

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; ------------------->

> >> >>>>>>>>>&= gt;            =             &nb= sp; INVITE (#2)

> >> >>>>>>>>>&= gt;            =             &nb= sp; Supported:timer

> >> >>>>>>>>>&= gt;            =             &nb= sp; SE:refresher=3Duac

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; <-------------------

> >> >>>>>>>>>&= gt;            =             &nb= sp; 18x (#3)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; <-------------------

> >> >>>>>>>>>&= gt; 18x (#4)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; ++++++ early dialog established +++= ++++

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; <-------------------

> >> >>>>>>>>>&= gt;            =             &nb= sp; UPDATE (#5)

> >> >>>>>>>>>&= gt;            =             &nb= sp; Supported:timer

> >> >>>>>>>>>&= gt;            =             &nb= sp; SE:refresher=3Duas

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; <-------------------

> >> >>>>>>>>>&= gt; UPDATE (#6)

> >> >>>>>>>>>&= gt; Supported:timer

> >> >>>>>>>>>&= gt; SE:refresher=3Duas

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; ------------------->

> >> >>>>>>>>>&= gt; 200 (UPDATE) (#7)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; ------------------->

> >> >>>>>>>>>&= gt;            =             &nb= sp; 200 (UPDATE) (#8)

> >> >>>>>>>>>&= gt;            =             &nb= sp; Require:timer

> >> >>>>>>>>>&= gt;            =             &nb= sp; SE:refresher=3Duac

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =             &nb= sp; <-------------------

> >> >>>>>>>>>&= gt;            =             &nb= sp; 480 (INVITE) (#9)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; <-------------------

> >> >>>>>>>>>&= gt; 480 (INVITE (#10)

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; A few things to note:

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; N1:        The 18x does not contain = the SE

> >> >>>>>>>>>&= gt; (Session-Expires)

> >> header

> >> >>>>>>>>>&= gt; field,

> >> >>>>>>>>>&= gt;            =   because according to section 4 of RFC 4028

> >> >>>>>>>>>&= gt;the  header field is only

> >> >>>>>>>>>&= gt;            =   allowed in INVITE, UPDATE and 2xx. So, when

> >> >>>>>>>>>&= gt;the  UPDATE request

> >> >>>>>>>>>&= gt;            =   (#5) is sent, the initial session timer

> >> >>>>>>>>>&= gt;negotiation is still

> >> >>>>>>>>>&= gt;            =   ongoing.

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; N2:        The UPDATE request (#5) c= ontains a

> >> >>>>>>>>>&= gt; Session-Expires

> >> header

> >> >>>>>>>>>&= gt; field.

> >> >>>>>>>>>&= gt;            =   Section 7.4 of RFC 4028 says:

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;          "In a sessio= n refresh request sent within a

> >> >>>>>>>>>&= gt;dialog with  an active

> >> >>>>>>>>>&= gt;           session tim= er, the Session-Expires header field

> >> >>>>>>>>>&= gt;SHOULD  be present."

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;     Now, a dialog (early) HAS been established when= the

> >> >>>>>>>>>&= gt;UPDATE

> >> >>>>>>>> requ= est is

> >> >>>>>>>>>&= gt;            =   sent, but as the initial session timer

> >> >>>>>>>>>&= gt;negotiation is still

> >> >>>>>>>>>&= gt;            =   ongoing, I assume the session timer isn=B9t yet

> >> >>>>>>>>>&= gt;"active"?

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; N3:        The UPDATE 200 response (= #7) does not contain

> >> >>>>>>>>>&= gt;the  Session-Expires

> >> >>>>>>>>>&= gt;            =   header field. It is added by the proxy, based

> >> >>>>>>>>>&= gt;on  the procedures in

> >> >>>>>>>>>&= gt;            =   Section 8.2 of RFC 4028:

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;            =        "Because there is no Session-Expi= res or

> >> >>>>>>>>>&= gt;Require header field

> >> >>>>>>>>>&= gt;            =         in the response, the proxy knows= that

> >> >>>>>>>>>&= gt;it  is the first

> >> >>>>>>>>>&= gt;            =         session-timer-aware proxy to rec= eive

> >> >>>>>>>>>&= gt;the  response.

> >> >>>>>>>>>&= gt; This  proxy

> >> >>>>>>>>>&= gt;            =         MUST insert a Session-Expires he= ader

> >> >>>>>>>>>&= gt;field  into the response

> >> >>>>>>>>>&= gt;            =         with the value it remembered fro= m the

> >> >>>>>>>>>&= gt;forwarded request.

> >> >>>>>>>>>&= gt; It

> >> >>>>>>>>>&= gt; MUST

> >> >>>>>>>>>&= gt;            =         set the value of The 'refresher'=

> >> >>>>>>>>>&= gt;parameter  to 'uac'.

> >> >>>>>>>>>&= gt; The  proxy MUST

> >> >>>>>>>>>&= gt;            =         add the 'timer' option tag to an= y

> >> >>>>>>>>>&= gt;Require  header field in  the

> >> >>>>>>>>>&= gt;            =         response, and if none was presen= t, add

> >> >>>>>>>>>&= gt;the  Require header  field with

> >> >>>>>>>>>&= gt;            =         that value before forwarding it = upstream."

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; Now, one could argue that the UA should include something

> >> >>>>>>>>>&= gt; in the UPDATE response (#7), but I think that is not a

> >> >>>>>>>>>&= gt; solution as the UA may be confused.

> >> >>>>>>>>>&= gt; Instead, based on my understanding of the text in section

> >> >>>>>>>>>&= gt; 7.4 (see

> >> >>>>>>>>>&= gt; above) the UPDATE request (#5) should not contain any=

> >> session

> >> >>>>>>>>>&= gt; timer information. This is also more or less what the=

> >> >>>>>>>>>&= gt; errata suggests.

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; Comments?

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; Regards,

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt; Christer

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>>&= gt;

> ______________________________________________= _

> >> >>>>>>>>>&= gt; sipcore mailing list

> >> >>>>>>>>>&= gt; mailto:sipcore@ietf.org=

> >> >>>>>>>>>&= gt;

> >> >>>>>>>>><= /span>

> >> >>>>>>>>> = _______________________________________________

> >> >>>>>>>>> = sipcore mailing list

> >> >>>>>>>>> mailto:sipcore@ietf.org=

> >> >>>>>>>>

> >> >>>>>>>> ____= ___________________________________________

> >> >>>>>>>> sipc= ore mailing list

> >> >>>>>>>> mailto:sipcore@ietf.org=

> >> >>>>>>>

> >> >>>>>><= /o:p>

> >> >>>>>> ____________= ___________________________________

> >> >>>>>> sipcore mail= ing list

> >> >>>>>

> >> >>>>> ________________= _______________________________

> >> >>>>> sipcore mailing = list

> >> >>>>>

> >> >>>>

> >> >>>> ____________________= ___________________________

> >> >>>> sipcore mailing list=

> >> >>>

> >> >>>

> >> >>

> >> >

> >> >

> >>

> >> _____________________________________= __________

> >> sipcore mailing list

>

> ______________________________________________= _

> sipcore mailing list

 

--_000_7594FB04B1934943A5C02806D1A2204B56320A89ESESSMB109erics_-- From nobody Mon Oct 9 09:17:59 2017 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 940EE13465D for ; Mon, 9 Oct 2017 09:17:57 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWphDqTueIkC for ; Mon, 9 Oct 2017 09:17:56 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 49121134660 for ; Mon, 9 Oct 2017 09:17:56 -0700 (PDT) X-AuditID: 12074413-3a3ff70000007929-13-59dba133f194 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 36.3A.31017.331ABD95; Mon, 9 Oct 2017 12:17:55 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v99GHr74012795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Oct 2017 12:17:54 -0400 To: "Jesske, Roland" , Christer Holmberg , "sipcore@ietf.org" References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <9cd95809-7388-9b8c-8070-83a1ba918b53@alum.mit.edu> From: Paul Kyzivat Message-ID: <8cd70a3c-b19b-fc07-3644-cc49fef0eead@alum.mit.edu> Date: Mon, 9 Oct 2017 12:17:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IRYndR1DVeeDvSYMN/FYsLMw8zWjTd6WKz +PpjE5sDs8evr1fZPJYs+cnk0fZSIYA5issmJTUnsyy1SN8ugSvj+JMW5oJjTBUT3k5mbmD8 ytjFyMEhIWAi0fustouRi0NIYAeTxLumXlYI5wGTxO9z84CKODmEBXQkdn49zgKSEBGYziix 4e0hNpCEkMBpJomDjRUgNpuAlsScQ/9ZQGxeAXuJYxNmsILYLAIqEk8mrGQHsUUF0iT+7T7L CFEjKHFy5hOwek6BGIkD6z+DxZkFbCXuzN3NDGGLS9x6Mp8JwpaX2P52DvMERv5ZSNpnIWmZ haRlFpKWBYwsqxjlEnNKc3VzEzNzilOTdYuTE/PyUot0zfVyM0v0UlNKNzFCgld4B+Ouk3KH GAU4GJV4eBdMvh0pxJpYVlyZe4hRkoNJSZR3/XygEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe J01AOd6UxMqq1KJ8mJQ0B4uSOK/aEnU/IYH0xJLU7NTUgtQimKwMB4eSBG/2AqBGwaLU9NSK tMycEoQ0EwcnyHAeoOFhIDW8xQWJucWZ6RD5U4zGHDceXv/DxNHTc+MPkxBLXn5eqpQ4ry1I qQBIaUZpHtw0WAJ6xSgO9Jww7yOQT3iAyQtu3iugVUxAqxiLb4CsKklESEk1MJp/+nMldwGT nFv/rE7GfvXThex7K9+ZzZkt/qnjVu7qdWw+5jO/Lkle88BL7d9Gte8l2Y8Tw2VKLEvqzadk y4seNwlhCN2tLjlB4/iL3/+UV83TXPEp3Xz1LwuB409S/wgrcUfIKOVe5u46Zuy6V2Ual+P8 Qq3rGgbeQreePFEyscvyjlFlVGIpzkg01GIuKk4EAIkgYJgbAwAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 16:17:57 -0000 Hi Roland, On 10/9/17 10:41 AM, Jesske, Roland wrote: > NetA and NetC does support session timer. > NetB does not. > So Proxy 2 netB will delete the session timer Let me repeat: this is not valid behavior for a proxy. The proper fix is for Proxy 2 to do what it is required to do by the specs. Thanks, Paul From nobody Mon Oct 9 11:04:17 2017 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 48AF513475B for ; Mon, 9 Oct 2017 11:04:14 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnDx6E_WJ2c4 for ; Mon, 9 Oct 2017 11:04:13 -0700 (PDT) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 00F4D1345FD for ; Mon, 9 Oct 2017 11:04:12 -0700 (PDT) X-AuditID: 1207440f-a43ff70000007960-cb-59dbba1cdbd5 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0A.E5.31072.C1ABBD95; Mon, 9 Oct 2017 14:04:12 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v99I4ATT018762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Oct 2017 14:04:11 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> Date: Mon, 9 Oct 2017 14:04:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixO6iqCuz63akwZW1ohYXZh5mtPj6YxOb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJVxZk8rY0EPb8X+3TfYGhiXcHUxcnJICJhI vHs3j7WLkYtDSGAHk0TL1G5mCOcBk8T8FU2sIFXCAnISrzuvgNkiAmkSPRP72SGK5jJJ9M04 yAySYBPQkphz6D8LiM0rYC9x4ucWNhCbRUBF4tOmw4wgtihQ87/dZxkhagQlTs58AlbPKeAn 8fXXeTCbWcBMYt7mh8wQtrjErSfzmSBseYntb+cwT2Dkn4WkfRaSlllIWmYhaVnAyLKKUS4x pzRXNzcxM6c4NVm3ODkxLy+1SNdELzezRC81pXQTIyRY+Xcwdq2XOcQowMGoxMO7YPLtSCHW xLLiytxDjJIcTEqivCc3AoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8F7dBpTjTUmsrEotyodJ SXOwKInzqi9R9xMSSE8sSc1OTS1ILYLJynBwKEnw3t4B1ChYlJqeWpGWmVOCkGbi4AQZzgM0 fPZ2kOHFBYm5xZnpEPlTjLocPT03/jAJseTl56VKifMWgAwSACnKKM2DmwNLMq8YxYHeEubt 2glUxQNMUHCTXgEtYQJawlh8A2RJSSJCSqqBsTxj9wc/k4vlMo6+lTFHHyxSKtd7MLkk/oHg 2htGSzZXTHrPfuPYY+cX4n9bVu++LqpUsFvr8GcJ322vHRk23kvePCXLz0wx+oC48735J0z2 6/+sl1oVJflcvvHJiwbJYFHf7AmsEiu8zdP6di4x+HDeSuvuvdI7AgcPhDaLVrft/ei53Z/r ihJLcUaioRZzUXEiAMME44kNAwAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 18:04:14 -0000 Christer, On 10/9/17 12:05 PM, Christer Holmberg wrote: > Hi, > >>>> Yes, I understand that is the case you are thinking of. But I was >>>> raising a different case: >>>> >>>> - the UAC sends an invite without a S-E. >>>> - a proxy along the path includes an S-E. (The UAC is unaware.) >>>> - later, the UAC sends an UPDATE with S-E. >>>> >>>> That violates the rule in your draft, but the UAC doesn't know it has >>>> violated it. So your rule for avoiding the problem in this case >>>> doesn't work. >>> >>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I >>> understand the proxy will never remove S-E from a response. So, we >>> could say that the UAC must not send UPDATE with S-E until it has >>> received a response to the INVITE. >> >> The problem is that the rfc only talks about the *final* (2xx) response. >> It has no provision for including the S-E in provisional responses. (It doesn't mention provisional responses, and the Table 1 update in section >> 4 shows the intent is to exclude it. Hence, if the S-E is inserted into the INVITE by a proxy, the UAC won't know that a session timer has been requested until it receives the > final response to the invite. Meanwhile it might decide send an UPDATE with S-E. > > My suggestion is that the UAC would not be allowed to send UPDATE with S-E until it has received the final response for the INVITE. This is more or less the original proposal that was shot down. Or do you mean that the *UAC* is restricted that way, but the *UAS* is permitted to use S-E to negotiate session timer in the midst of the INVITE, at least in some cases? Thanks, Paul From nobody Mon Oct 9 11:36:25 2017 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 4AF3C13454C for ; Mon, 9 Oct 2017 11:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJillL8G2iHi for ; Mon, 9 Oct 2017 11:36:22 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 95E131320DC for ; Mon, 9 Oct 2017 11:36:21 -0700 (PDT) X-AuditID: c1b4fb30-659ff700000033c8-e4-59dbc1a32c4c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.63.13256.3A1CBD95; Mon, 9 Oct 2017 20:36:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 20:36:19 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaZ+6AgAEJNoCAAAc9gIAAPEsggAAAZQCAACh7gA== Date: Mon, 9 Oct 2017 18:36:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56321059@ESESSMB109.ericsson.se> References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> In-Reply-To: <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2K7je7ig7cjDWbuNrRYseEAq8XXH5vY HJg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6M+9vDCj4JV2zdldrAuEG4i5GTQ0LARGL2 +Xa2LkYuDiGBI4wSXfv+M0E4CxklNq77z9rFyMHBJmAh0f1PG6RBRCBQ4uqSCcwgYWEBOYn2 Q5YQYXmJ9TsvM0HYYRKtW++ygtgsAioSP59cYwexeQV8JVYfu80MMf4yk8TG1/1gRZwCDhKr Z30BK2IUEJP4fmoN2CBmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELaSxIrtlxhB7mEW0JRY v0sfolVRYkr3Q6i9ghInZz5hmcAoMgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRkV5qUWZy cXF+nl5easkmRmAcHNzy22AH48vnjocYBTgYlXh4s3fcjhRiTSwrrsw9xCjBwawkwmt1ACjE m5JYWZValB9fVJqTWnyIUZqDRUmc13HfhQghgfTEktTs1NSC1CKYLBMHp1QD4071LDYftT7e i+af2QN/nVH0WTlZZJNTyb/s95tex8umH6hO32HY9vTwYaGLS578+vJW0pKTdV6HZ87OPJ/Q vCndBo+LLwfuU2C4W2OvqzN1l4JEzz3H2hn7lt7jnPj+n/yrsDeGzB6PvDTNHViSqkIEf/1b fmTGjDPchSE8lyasbw94FbD+pBJLcUaioRZzUXEiAE0VLkV/AgAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 18:36:23 -0000 SGksDQoNCj4+Pj4+IFllcywgSSB1bmRlcnN0YW5kIHRoYXQgaXMgdGhlIGNhc2UgeW91IGFyZSB0 aGlua2luZyBvZi4gQnV0IEkgd2FzIA0KPj4+Pj4gcmFpc2luZyBhIGRpZmZlcmVudCBjYXNlOg0K Pj4+Pj4NCj4+Pj4+IC0gdGhlIFVBQyBzZW5kcyBhbiBpbnZpdGUgd2l0aG91dCBhIFMtRS4NCj4+ Pj4+IC0gYSBwcm94eSBhbG9uZyB0aGUgcGF0aCBpbmNsdWRlcyBhbiBTLUUuIChUaGUgVUFDIGlz IHVuYXdhcmUuKQ0KPj4+Pj4gLSBsYXRlciwgdGhlIFVBQyBzZW5kcyBhbiBVUERBVEUgd2l0aCBT LUUuDQo+Pj4+Pg0KPj4+Pj4gVGhhdCB2aW9sYXRlcyB0aGUgcnVsZSBpbiB5b3VyIGRyYWZ0LCBi dXQgdGhlIFVBQyBkb2Vzbid0IGtub3cgaXQgDQo+Pj4+PiBoYXMgdmlvbGF0ZWQgaXQuIFNvIHlv dXIgcnVsZSBmb3IgYXZvaWRpbmcgdGhlIHByb2JsZW0gaW4gdGhpcyBjYXNlIA0KPj4+Pj4gZG9l c24ndCB3b3JrLg0KPj4+Pg0KPj4+PiBTZWN0aW9uIDguMiBpbiB0aGUgUkZDIGlzIChpbiBteSBv cGlub24pIHF1aXRlIG1lc3N5LCBidXQgYXMgZmFyIGFzIA0KPj4+PiBJIHVuZGVyc3RhbmQgdGhl IHByb3h5IHdpbGwgbmV2ZXIgcmVtb3ZlIFMtRSBmcm9tIGEgcmVzcG9uc2UuIFNvLCB3ZSANCj4+ Pj4gY291bGQgc2F5IHRoYXQgdGhlIFVBQyBtdXN0IG5vdCBzZW5kIFVQREFURSB3aXRoIFMtRSB1 bnRpbCBpdCBoYXMgDQo+Pj4+IHJlY2VpdmVkIGEgcmVzcG9uc2UgdG8gdGhlIElOVklURS4NCj4+ Pg0KPj4+IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHJmYyBvbmx5IHRhbGtzIGFib3V0IHRoZSAq ZmluYWwqICgyeHgpIHJlc3BvbnNlLg0KPj4+IEl0IGhhcyBubyBwcm92aXNpb24gZm9yIGluY2x1 ZGluZyB0aGUgUy1FIGluIHByb3Zpc2lvbmFsIHJlc3BvbnNlcy4gDQo+Pj4gKEl0IGRvZXNuJ3Qg bWVudGlvbiBwcm92aXNpb25hbCByZXNwb25zZXMsIGFuZCB0aGUgVGFibGUgMSB1cGRhdGUgaW4g DQo+Pj4gc2VjdGlvbg0KPj4+IDQgc2hvd3MgdGhlIGludGVudCBpcyB0byBleGNsdWRlIGl0LiBI ZW5jZSwgaWYgdGhlIFMtRSBpcyBpbnNlcnRlZCBpbnRvIHRoZSBJTlZJVEUgYnkgYSBwcm94eSwg dGhlIFVBQyB3b24ndCANCj4+PiBrbm93IHRoYXQgYSBzZXNzaW9uIHRpbWVyIGhhcyBiZWVuIHJl cXVlc3RlZCB1bnRpbCBpdCByZWNlaXZlcyB0aGUgZmluYWwgcmVzcG9uc2UgdG8gdGhlIGludml0 ZS4gTWVhbndoaWxlIA0KPj4+IGl0IG1pZ2h0IGRlY2lkZSBzZW5kIGFuIFVQREFURSB3aXRoIFMt RS4NCj4+IA0KPj4gTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IHRoZSBVQUMgd291bGQgbm90IGJlIGFs bG93ZWQgdG8gc2VuZCBVUERBVEUgd2l0aCBTLUUgdW50aWwgaXQgaGFzIHJlY2VpdmVkIHRoZSBm aW5hbCByZXNwb25zZSBmb3IgdGhlIElOVklURS4NCj4NCj4gVGhpcyBpcyBtb3JlIG9yIGxlc3Mg dGhlIG9yaWdpbmFsIHByb3Bvc2FsIHRoYXQgd2FzIHNob3QgZG93bi4gDQoNCkRPSCEgWW91J3Jl IHJpZ2h0IDopDQoNCj4gT3IgZG8geW91IG1lYW4gdGhhdCB0aGUgKlVBQyogaXMgcmVzdHJpY3Rl ZCB0aGF0IHdheSwgYnV0IHRoZSAqVUFTKiBpcyBwZXJtaXR0ZWQgdG8gdXNlIFMtRSB0byBuZWdv dGlhdGUgDQo+IHNlc3Npb24gdGltZXIgaW4gdGhlIG1pZHN0IG9mIHRoZSBJTlZJVEUsIGF0IGxl YXN0IGluIHNvbWUgY2FzZXM/DQoNCkkgd2FzIG1vc3RseSB0aGlua2luZyBhYm91dCB0aGUgVUFD LCBidXQgSSB0aGluayBpdCBjb3VsZCBhcHBseSB0byB0aGUgVUFTIHRvby4NCg0KT25lIG9wdGlv biB3b3VsZCBiZSB0byBhbGxvdyBTLUUgaW4gMTh4Lg0KDQpOZWVkIHRvIHRoaW5rIGEgbGl0dGxl IG1vcmUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Tue Oct 10 08:03:32 2017 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 1E095134E1B for ; Tue, 10 Oct 2017 08:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRcQm6xE1zjf for ; Tue, 10 Oct 2017 08:03:26 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0D14E134E3A for ; Tue, 10 Oct 2017 08:01:58 -0700 (PDT) X-AuditID: 12074413-38bff70000007929-d2-59dce0e55af6 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 73.7B.31017.5E0ECD95; Tue, 10 Oct 2017 11:01:58 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9AF1vQM016297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Oct 2017 11:01:57 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <23ff228f-934b-d5cf-1b2e-92d664d5f0a0@alum.mit.edu> Date: Tue, 10 Oct 2017 11:01:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqPvswZ1Ig9eT+Cy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGcLlzMWdHBX3Fj7l62B8RlHFyMnh4SAiUTH5M3sXYxcHEIC O5gkWs90skE4P5gkLiw/wwhSJSxgLPH6/Dp2EFtEQETi2fR/bCC2kIC1xLqnLawgNpuAlsSc Q/9ZQGxeAXuJnpabYDUsAqoSX7f2g9miAmkS/3afZYSoEZQ4OfMJWD2ngI3E4slPmEFsZgEz iXmbH0LZ4hK3nsxngrDlJZq3zmaewMg/C0n7LCQts5C0zELSsoCRZRWjXGJOaa5ubmJmTnFq sm5xcmJeXmqRrrlebmaJXmpK6SZGSFgK72DcdVLuEKMAB6MSD6/A9TuRQqyJZcWVuYcYJTmY lER5i28DhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwvr4IlONNSaysSi3Kh0lJc7AoifOqLVH3 ExJITyxJzU5NLUgtgsnKcHAoSfDuvA/UKFiUmp5akZaZU4KQZuLgBBnOAzT8CkgNb3FBYm5x ZjpE/hSjLkdPz40/TEIsefl5qVLivL9AigRAijJK8+DmwNLJK0ZxoLeEeaeAVPEAUxHcpFdA S5iAloimgS0pSURISTUwrr2Xpi5eeeKMXVyOVR7HtKfNP1LSOBZ/UVm+/9Uy028TXisdLi/b 8J/7R9AeY/NGIb+Us3kRhQKyyyRnf+RcLRgb922For9r3YPF8rc/1Km3lKp/tup65KPxOpNf fNV7k6WTJ4szTOWamBfXzXyCdUnNfI+Na9K5hAzc3GvX+TaseCaj+rtDiaU4I9FQi7moOBEA KrJ4wAIDAAA= Archived-At: Subject: Re: [sipcore] Draft new: draft-sip-push-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 15:03:31 -0000 A couple of comments on this: 1) I'm a bit confused about the intended use of the URI parameters. On one hand these are included in the Contact-URI during registration. On the other hand, section 5 talks about the proxy checking for these parameters in the Request-URI, which in this case I take to mean the AoR. I would not expect to see these in the AoR. Please be more specific if the intent is that the proxy first does the request URI translation and *then* checks for these parameters. 2) Nowhere in here do I see any feedback mechanism from the proxy/registrar to the UA indicating that it actually supports this mechanism. ISTM that this calls for an option tag mechanism, with Require:push in the register request and a Supported:push in the response. Thanks, Paul On 10/9/17 9:48 AM, Christer Holmberg wrote: > Hi, > > Since I did not hear anything from the author of > draft-ivanov-sipcore-pnsip, IÂąve submitted a draft > (draft-holmberg-sipcore-sip-push) which is based on that draft. > > The holmberg draft contains more text, based on the list discussions and > comments. > > One thing to note: while looking into different push notification > services, at least 2 commonly used ones do NOT provide a URI as the > subscription token. So, IÂąve kept the pn-type parameter, in order to > provide guidance on which push notification service is used. From nobody Tue Oct 10 10:12:18 2017 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 9629D134695 for ; Tue, 10 Oct 2017 10:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE-WupeDnKXZ for ; Tue, 10 Oct 2017 10:12:09 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 B6903134ED2 for ; Tue, 10 Oct 2017 10:07:59 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-8d-59dcfe6dab62 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D0.82.03220.D6EFCD95; Tue, 10 Oct 2017 19:07:58 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Tue, 10 Oct 2017 19:07:57 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-sip-push-00 Thread-Index: AQHTQQVYKHAx7ZVjvkqN9Wloadjyn6LdDdsAgABB5oA= Date: Tue, 10 Oct 2017 17:07:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56323BAF@ESESSMB109.ericsson.se> References: <23ff228f-934b-d5cf-1b2e-92d664d5f0a0@alum.mit.edu> In-Reply-To: <23ff228f-934b-d5cf-1b2e-92d664d5f0a0@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7rm7evzuRBjMnMFus2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGl8mPWAvuiFT8X3SEpYFxhkgXIyeHhICJ xIo3d5m6GLk4hASOMEp82bKQDcJZxCjROvsFYxcjBwebgIVE9z9tkAYRgUCJq0smMIPYwgLG EltngtSDxE0kFjYfYoawrSTenn3PAmKzCKhKvN1zBczmFfCV+Hd8DSOILSRQKDF3yhtWEJtT wEFie3MXWC+jgJjE91NrmEBsZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2kkTjkiesIGcy C2hKrN+lD9GqKDGl+yE7xFpBiZMzn7BMYBSZhWTqLISOWUg6ZiHpWMDIsopRtDi1OCk33chY L7UoM7m4OD9PLy+1ZBMjMBYObvmtuoPx8hvHQ4wCHIxKPLwNV+9ECrEmlhVX5h5ilOBgVhLh df0BFOJNSaysSi3Kjy8qzUktPsQozcGiJM7ruO9ChJBAemJJanZqakFqEUyWiYNTqoExNz1p 0sN9iv077kl33vB/ylG/wHWXwr39ax+Hy0ku+fn4l8AEbvujfd9SLN3nF2g9OpXburRLpsXS N6LyYNLXHu0Pu7W02Z5vDJo6I8h85RYlsafZv3fEd/gZPdJoWV2ipLV8/uIFaSZXb7UqqAQn PHhttFFwzYFWlmffL/3vjwk5Pjmi0mSyEktxRqKhFnNRcSIAKuiSu4ECAAA= Archived-At: Subject: Re: [sipcore] Draft new: draft-sip-push-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 17:12:17 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzISBTZWUgaW5saW5lLg0KDQo+IDEp IEknbSBhIGJpdCBjb25mdXNlZCBhYm91dCB0aGUgaW50ZW5kZWQgdXNlIG9mIHRoZSBVUkkgcGFy YW1ldGVycy4gT24gb25lIGhhbmQgdGhlc2UgYXJlIGluY2x1ZGVkIGluIHRoZSANCj4gQ29udGFj dC1VUkkgZHVyaW5nIHJlZ2lzdHJhdGlvbi4gT24gdGhlIG90aGVyIGhhbmQsIHNlY3Rpb24gNSB0 YWxrcyBhYm91dCB0aGUgcHJveHkgY2hlY2tpbmcgZm9yIHRoZXNlIHBhcmFtZXRlcnMgDQo+IGlu IHRoZSBSZXF1ZXN0LVVSSSwgd2hpY2ggaW4gdGhpcyBjYXNlIEkgdGFrZSB0byBtZWFuIHRoZSBB b1IuIEkgd291bGQgbm90IGV4cGVjdCB0byBzZWUgdGhlc2UgaW4gdGhlIEFvUi4gDQo+IFBsZWFz ZSBiZSBtb3JlIHNwZWNpZmljIGlmIHRoZSBpbnRlbnQgaXMgdGhhdCB0aGUgcHJveHkgZmlyc3Qg ZG9lcyB0aGUgcmVxdWVzdCBVUkkgdHJhbnNsYXRpb24gYW5kICp0aGVuKiBjaGVja3MgZm9yIHRo ZXNlIHBhcmFtZXRlcnMuDQoNCkkgcmVmZXIgdG8gdGhlIFJlcXVlc3QtVVJJIG9mIHRoZSBJTlZJ VEUgcmVxdWVzdCwgd2hpY2ggd2lsbCBiZSB0aGUgQ29udGFjdC1VUkkgZnJvbSB0aGUgUkVHSVNU RVIuIEkgd2lsbCBtYWtlIHN1cmUgdGhhdCBpcyBjbGVhciBpbiB0aGUgdGV4dC4NCg0KPiAyKSBO b3doZXJlIGluIGhlcmUgZG8gSSBzZWUgYW55IGZlZWRiYWNrIG1lY2hhbmlzbSBmcm9tIHRoZSBw cm94eS9yZWdpc3RyYXIgdG8gdGhlIFVBIGluZGljYXRpbmcgDQo+IHRoYXQgaXQgYWN0dWFsbHkg c3VwcG9ydHMgdGhpcyBtZWNoYW5pc20uIElTVE0gdGhhdCB0aGlzIGNhbGxzIGZvciBhbiBvcHRp b24gdGFnIG1lY2hhbmlzbSwgd2l0aCANCj4gUmVxdWlyZTpwdXNoIGluIHRoZSByZWdpc3RlciBy ZXF1ZXN0IGFuZCBhIFN1cHBvcnRlZDpwdXNoIGluIHRoZSByZXNwb25zZS4NCg0KSSB3YXMgdGhp bmtpbmcgb2YgZGVmaW5pbmcgZmVhdHVyZSBjYXBhYmlsaXR5IGluZGljYXRvcnMgZm9yIHRoYXQu IEhvd2V2ZXIsIEkgd2FudGVkIHRvIHN1Ym1pdCB0aGUgaW5pdGlhbCB2ZXJzaW9uLCB0byBzZWUg d2hldGhlciBwZW9wbGUgaGF2ZSBhbnkgaW50ZXJlc3QgdG8gd29yayBvbiB0aGlzIGluIElFVEYg dG8gYmVnaW4gd2l0aC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCk9uIDEwLzkvMTcg OTo0OCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+IEhpLA0KPiANCj4gU2luY2UgSSBk aWQgbm90IGhlYXIgYW55dGhpbmcgZnJvbSB0aGUgYXV0aG9yIG9mIA0KPiBkcmFmdC1pdmFub3Yt c2lwY29yZS1wbnNpcCwgScK5dmUgc3VibWl0dGVkIGEgZHJhZnQNCj4gKGRyYWZ0LWhvbG1iZXJn LXNpcGNvcmUtc2lwLXB1c2gpIHdoaWNoIGlzIGJhc2VkIG9uIHRoYXQgZHJhZnQuDQo+IA0KPiBU aGUgaG9sbWJlcmcgZHJhZnQgY29udGFpbnMgbW9yZSB0ZXh0LCBiYXNlZCBvbiB0aGUgbGlzdCBk aXNjdXNzaW9ucyANCj4gYW5kIGNvbW1lbnRzLg0KPiANCj4gT25lIHRoaW5nIHRvIG5vdGU6IHdo aWxlIGxvb2tpbmcgaW50byBkaWZmZXJlbnQgcHVzaCBub3RpZmljYXRpb24gDQo+IHNlcnZpY2Vz LCBhdCBsZWFzdCAyIGNvbW1vbmx5IHVzZWQgb25lcyBkbyBOT1QgcHJvdmlkZSBhIFVSSSBhcyB0 aGUgDQo+IHN1YnNjcmlwdGlvbiB0b2tlbi4gU28sIEnCuXZlIGtlcHQgdGhlIHBuLXR5cGUgcGFy YW1ldGVyLCBpbiBvcmRlciB0byANCj4gcHJvdmlkZSBndWlkYW5jZSBvbiB3aGljaCBwdXNoIG5v dGlmaWNhdGlvbiBzZXJ2aWNlIGlzIHVzZWQuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Tue Oct 10 11:43:47 2017 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 3A16B134648 for ; Tue, 10 Oct 2017 11:43:38 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJyj-cVEQT9a for ; Tue, 10 Oct 2017 11:41:35 -0700 (PDT) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 06A7013309C for ; Tue, 10 Oct 2017 11:41:34 -0700 (PDT) X-AuditID: 12074414-0d3ff70000006ddf-82-59dd145ec86b Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C1.C5.28127.E541DD95; Tue, 10 Oct 2017 14:41:34 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9AIfX8l028645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Oct 2017 14:41:33 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <23ff228f-934b-d5cf-1b2e-92d664d5f0a0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56323BAF@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <040189d8-c763-8164-3cba-0aae0cddd5f7@alum.mit.edu> Date: Tue, 10 Oct 2017 14:41:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56323BAF@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixO6iqBsncjfS4MlBYYsLMw8zWnz9sYnN gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYc+8ve0GPUMWr3neMDYy7+LoYOTkkBEwk Hl+fw9TFyMUhJLCDSeLW0tOMEM5DJom9p/pYQaqEBYwlXp9fxw5iiwikSfRM7GeHKNrKKHG3 rY8ZJMEmoCUx59B/FhCbV8Be4v/8qWA2i4CqxPWfTxlBbFGg5n+7zzJC1AhKnJz5BKyGU8BP YtLcU2A2s4CZxLzND5khbHGJW0/mM0HY8hLNW2czT2Dkn4WkfRaSlllIWmYhaVnAyLKKUS4x pzRXNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIyRYRXYwHjkpd4hRgINRiYdX4PqdSCHW xLLiytxDjJIcTEqivEp/gEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeF1/AOV4UxIrq1KL8mFS 0hwsSuK83xar+wkJpCeWpGanphakFsFkZTg4lCR4q4TvRgoJFqWmp1akZeaUIKSZODhBhvMA DU8BqeEtLkjMLc5Mh8ifYtTl6Om58YdJiCUvPy9VSpz3mhBQkQBIUUZpHtwcWJJ5xSgO9JYw ryHIKB5ggoKb9ApoCRPQEtE0kA+KSxIRUlINjB4sAmfYEucuWS/vdqxK3TJawaA9TvOHkah+ GntWs5j8q9JYhuc5JafDrxxwbleoq86p9+v6y3tu+eSjnJeT6zZcifm8+fb5Jb8tTmuaHT1y V++Ty+YfHFNkz1VO1Be40ujBePDwW5n7FsJ5NiFmPPzr5FaGGfXJH2b0jOX2CWJpfsbzREVT iaU4I9FQi7moOBEAclpWVw0DAAA= Archived-At: Subject: Re: [sipcore] Draft new: draft-sip-push-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 18:43:38 -0000 Hi Christer, On 10/10/17 1:07 PM, Christer Holmberg wrote: > Hi Paul, > > Thanks for your comments! See inline. > >> 1) I'm a bit confused about the intended use of the URI parameters. On one hand these are included in the >> Contact-URI during registration. On the other hand, section 5 talks about the proxy checking for these parameters >> in the Request-URI, which in this case I take to mean the AoR. I would not expect to see these in the AoR. >> Please be more specific if the intent is that the proxy first does the request URI translation and *then* checks for these parameters. > > I refer to the Request-URI of the INVITE request, which will be the Contact-URI from the REGISTER. I will make sure that is clear in the text. Thanks. >> 2) Nowhere in here do I see any feedback mechanism from the proxy/registrar to the UA indicating >> that it actually supports this mechanism. ISTM that this calls for an option tag mechanism, with >> Require:push in the register request and a Supported:push in the response. > > I was thinking of defining feature capability indicators for that. However, I wanted to submit the initial version, to see whether people have any interest to work on this in IETF to begin with. IMO an options tag works better here. Presumably the UA will be requesting this with the initial REGISTER, and won't be able to function if the feature isn't supported. The use of Require does exactly the right thing here. Thanks, Paul > Regards, > > Christer > > > > On 10/9/17 9:48 AM, Christer Holmberg wrote: >> Hi, >> >> Since I did not hear anything from the author of >> draft-ivanov-sipcore-pnsip, IÂąve submitted a draft >> (draft-holmberg-sipcore-sip-push) which is based on that draft. >> >> The holmberg draft contains more text, based on the list discussions >> and comments. >> >> One thing to note: while looking into different push notification >> services, at least 2 commonly used ones do NOT provide a URI as the >> subscription token. So, IÂąve kept the pn-type parameter, in order to >> provide guidance on which push notification service is used. > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Oct 11 00:54:11 2017 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 43EAC128D0D for ; Wed, 11 Oct 2017 00:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyfgTZczjy45 for ; Wed, 11 Oct 2017 00:54:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 67E2C13202D for ; Wed, 11 Oct 2017 00:54:07 -0700 (PDT) X-AuditID: c1b4fb25-dd3ff70000000c94-2f-59ddce1dc111 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 70.40.03220.D1ECDD95; Wed, 11 Oct 2017 09:54:05 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Wed, 11 Oct 2017 09:54:04 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-sip-push-00 Thread-Index: AQHTQQVYKHAx7ZVjvkqN9Wloadjyn6LdDdsAgABB5oD///t3gIABEYEA Date: Wed, 11 Oct 2017 07:54:04 +0000 Message-ID: References: <23ff228f-934b-d5cf-1b2e-92d664d5f0a0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56323BAF@ESESSMB109.ericsson.se> <040189d8-c763-8164-3cba-0aae0cddd5f7@alum.mit.edu> In-Reply-To: <040189d8-c763-8164-3cba-0aae0cddd5f7@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="euc-kr" Content-ID: <4664DF5D36EB67428A369A3DE33D5D8C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7sa7subuRBgtPSlms2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGp5eXmQrOiVcsfHCBsYGxQbyLkZNDQsBE 4uTKP+xdjFwcQgJHGCX2z7kC5SxilOi6N5O5i5GDg03AQqL7nzZIg4hAoMTVJROYQWxhAWOJ 1+fXsUPETSQWNh9ihrDdJO513QSLswioSuzt+8gGYvMKWEusnzqDCWL+a0aJ3+9OsYDM5xRw kJhwFOwgRgExie+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1hBbFEBPYkNJ26zg4yR EFCUWN4vB9GqJfHlxz42CNtaYsaPFewQtqLElO6H7BDnCEqcnPmEZQKj2Cwk22YhaZ+FpH0W kvZZSNoXMLKuYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMqoNbfqvuYLz8xvEQowAHoxIP b+vuu5FCrIllxZW5hxglOJiVRHi3nAIK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9 sSQ1OzW1ILUIJsvEwSnVwGhnVLCjQFR4u85y73PPG7Q3VV6oT2uLbGOU2fo4e/m9VsEY9SdT nnLZ6Bzn+XF63UQdt+/3vq5vc2bRyt584YTxo1tfs16ptiwy+d01j1Gn1sFKQVF9ucg8u5z6 rPJ5K6fWaqy8mn1UbdIL35rIdysdRGqaKneFzZu52CF4wULbR0wfmr+3RCuxFGckGmoxFxUn AgAS3izApgIAAA== Archived-At: Subject: Re: [sipcore] Draft new: draft-sip-push-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 07:54:09 -0000 SGkgUGF1bCwNCg0KoaYNCg0KPj4+IDIpIE5vd2hlcmUgaW4gaGVyZSBkbyBJIHNlZSBhbnkgZmVl ZGJhY2sgbWVjaGFuaXNtIGZyb20gdGhlDQo+Pj5wcm94eS9yZWdpc3RyYXIgdG8gdGhlIFVBIGlu ZGljYXRpbmcNCj4+PiB0aGF0IGl0IGFjdHVhbGx5IHN1cHBvcnRzIHRoaXMgbWVjaGFuaXNtLiBJ U1RNIHRoYXQgdGhpcyBjYWxscyBmb3IgYW4NCj4+Pm9wdGlvbiB0YWcgbWVjaGFuaXNtLCB3aXRo DQo+Pj4gUmVxdWlyZTpwdXNoIGluIHRoZSByZWdpc3RlciByZXF1ZXN0IGFuZCBhIFN1cHBvcnRl ZDpwdXNoIGluIHRoZQ0KPj4+cmVzcG9uc2UuDQo+PiANCj4+IEkgd2FzIHRoaW5raW5nIG9mIGRl ZmluaW5nIGZlYXR1cmUgY2FwYWJpbGl0eSBpbmRpY2F0b3JzIGZvciB0aGF0Lg0KPj5Ib3dldmVy LCBJIHdhbnRlZCB0byBzdWJtaXQgdGhlIGluaXRpYWwgdmVyc2lvbiwgdG8gc2VlIHdoZXRoZXIg cGVvcGxlDQo+PmhhdmUgYW55IGludGVyZXN0IHRvIHdvcmsgb24gdGhpcyBpbiBJRVRGIHRvIGJl Z2luIHdpdGguDQo+DQo+SU1PIGFuIG9wdGlvbnMgdGFnIHdvcmtzIGJldHRlciBoZXJlLiBQcmVz dW1hYmx5IHRoZSBVQSB3aWxsIGJlDQo+cmVxdWVzdGluZyB0aGlzIHdpdGggdGhlIGluaXRpYWwg UkVHSVNURVIsIGFuZCB3b24ndCBiZSBhYmxlIHRvIGZ1bmN0aW9uDQo+aWYgdGhlIGZlYXR1cmUg aXNuJ3Qgc3VwcG9ydGVkLiBUaGUgdXNlIG9mIFJlcXVpcmUgZG9lcyBleGFjdGx5IHRoZQ0KPnJp Z2h0IHRoaW5nIGhlcmUuDQoNCldlIG5lZWQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgaXQgaXMgbm90 IGVub3VnaCB0byBpbmRpY2F0ZSBzdXBwb3J0IG9mIHRoZQ0KbWVjaGFuaXNtIGFzIHN1Y2gsIHlv dSBhbHNvIG5lZWQgdG8gaW5kaWNhdGUgd2hpY2ggcHVzaCBub3RpZmljYXRpb24NCnByb3ZpZGVy cyAoQXBwbGUsIEZpcmViYXNlIGV0YykgeW91IHN1cHBvcnQsIGFzIHRoZSBwdXNoIHJlcXVlc3Qg c2VudCBieQ0KdGhlIHByb3h5IGxvb2tzIGRpZmZlcmVudCBmb3IgZWFjaCBvZiB0aGVtLg0KDQpT bywgSSBoYXZlIGJlZW4gdGhpbmtpbmcgdGhhdCB3ZSBwcm9iYWJseSB3b3VsZCBuZWVkIGEgcmVn aXN0cnkgZm9yIHRoZQ0KdHlwZSwgd2hpY2ggY29udGFpbnMgdGhlIHR5cGUgdmFsdWUgKGUuZy4s IKGwQVBOU6GxIGZvciBBcHBsZSkgdG9nZXRoZXIgd2l0aA0KYSByZWZlcmVuY2UgdG8gdGhlIHBy b2NlZHVyZXMuIEFsc28sIGluIGFkZGl0aW9uIHRvIHRoZSB0b2tlbiwgc29tZQ0KcHJvdmlkZXJz IG1heSByZXF1aXJlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gYmUgc2VudCBmcm9tIHRoZSBk ZXZpY2UgdG8NCnRoZSBwcm94eSwgc28gd2UgbWF5IG5lZWQgYW4gYXR0cmlidXRlIHRvIGFsbG93 IGZvciB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCj4+T24gMTAvOS8xNyA5OjQ4 IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4+PiBIaSwNCj4+Pg0KPj4+IFNpbmNlIEkg ZGlkIG5vdCBoZWFyIGFueXRoaW5nIGZyb20gdGhlIGF1dGhvciBvZg0KPj4+IGRyYWZ0LWl2YW5v di1zaXBjb3JlLXBuc2lwLCBJqfZ2ZSBzdWJtaXR0ZWQgYSBkcmFmdA0KPj4+IChkcmFmdC1ob2xt YmVyZy1zaXBjb3JlLXNpcC1wdXNoKSB3aGljaCBpcyBiYXNlZCBvbiB0aGF0IGRyYWZ0Lg0KPj4+ DQo+Pj4gVGhlIGhvbG1iZXJnIGRyYWZ0IGNvbnRhaW5zIG1vcmUgdGV4dCwgYmFzZWQgb24gdGhl IGxpc3QgZGlzY3Vzc2lvbnMNCj4+PiBhbmQgY29tbWVudHMuDQo+Pj4NCj4+PiBPbmUgdGhpbmcg dG8gbm90ZTogd2hpbGUgbG9va2luZyBpbnRvIGRpZmZlcmVudCBwdXNoIG5vdGlmaWNhdGlvbg0K Pj4+IHNlcnZpY2VzLCBhdCBsZWFzdCAyIGNvbW1vbmx5IHVzZWQgb25lcyBkbyBOT1QgcHJvdmlk ZSBhIFVSSSBhcyB0aGUNCj4+PiBzdWJzY3JpcHRpb24gdG9rZW4uIFNvLCBJqfZ2ZSBrZXB0IHRo ZSBwbi10eXBlIHBhcmFtZXRlciwgaW4gb3JkZXIgdG8NCj4+PiBwcm92aWRlIGd1aWRhbmNlIG9u IHdoaWNoIHB1c2ggbm90aWZpY2F0aW9uIHNlcnZpY2UgaXMgdXNlZC4NCj4+IA0KPj4gDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4gDQo+DQoNCg== From nobody Wed Oct 11 09:07:50 2017 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 1794C133224 for ; Wed, 11 Oct 2017 09:07:48 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxtdu7PCFG_k for ; Wed, 11 Oct 2017 09:07:42 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id D54F113202D for ; Wed, 11 Oct 2017 09:07:41 -0700 (PDT) X-AuditID: 1207440e-be1ff70000007085-15-59de41cdbfdf Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 67.24.28805.DC14ED95; Wed, 11 Oct 2017 12:07:41 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9BG7dVG029892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Oct 2017 12:07:40 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <23ff228f-934b-d5cf-1b2e-92d664d5f0a0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56323BAF@ESESSMB109.ericsson.se> <040189d8-c763-8164-3cba-0aae0cddd5f7@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Wed, 11 Oct 2017 12:07:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixO6iqHvW8V6kwd85ghYXZh5mtPj6YxOb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJWxd91/poJrQhUHJko0MD7i62Lk5JAQMJE4 cWI1YxcjF4eQwA4miX2tv5lAEkICD5kk3p5MB7GFBYwlXp9fxw5iiwikSfRM7GeHaJjLJLG3 ZwkbSIJNQEtizqH/LCA2r4C9xP4bD4GmcnCwCKhKHN7gDxIWBer9t/ssI0SJoMTJmU/AyjkF bCRWrF0DtpdZwFzi0oYP7BC2uMStJ/Oh4vISzVtnM09g5J+FpH0WkpZZSFpmIWlZwMiyilEu Mac0Vzc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0EyMkTPl2MLavlznEKMDBqMTD+0LrXqQQ a2JZcWXuIUZJDiYlUd5gPaAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd5gXaAcb0piZVVqUT5M SpqDRUmcV22Jup+QQHpiSWp2ampBahFMVoaDQ0mClxMYj0KCRanpqRVpmTklCGkmDk6Q4TxA w984gAwvLkjMLc5Mh8ifYtTl6Om58YdJiCUvPy9VSpz3LUiRAEhRRmke3BxYennFKA70ljDv BZAqHmBqgpv0CmgJE9AS0bQ7IEtKEhFSUg2MG/q/npNnmPbA5L5OfcnmmTtLbnK8279X3PTS ZMYVe+3SvZLvXlzDEc4kO2H385s6UTyCFbclXGwYztb9PGsxa1pvdqgSQ2GPyyzzouQLb/IZ fevMBNIP3Fza4a7m8MRbtz735eUzL+JWC7DsuxpkJ8PSfSX93senAecXFNiGf8yLP/X0z817 SizFGYmGWsxFxYkA/89N0woDAAA= Archived-At: Subject: Re: [sipcore] Draft new: draft-sip-push-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 16:07:49 -0000 On 10/11/17 3:54 AM, Christer Holmberg wrote: > Hi Paul, > > ˇ¦ > >>>> 2) Nowhere in here do I see any feedback mechanism from the >>>> proxy/registrar to the UA indicating >>>> that it actually supports this mechanism. ISTM that this calls for an >>>> option tag mechanism, with >>>> Require:push in the register request and a Supported:push in the >>>> response. >>> >>> I was thinking of defining feature capability indicators for that. >>> However, I wanted to submit the initial version, to see whether people >>> have any interest to work on this in IETF to begin with. >> >> IMO an options tag works better here. Presumably the UA will be >> requesting this with the initial REGISTER, and won't be able to function >> if the feature isn't supported. The use of Require does exactly the >> right thing here. > > We need to keep in mind that it is not enough to indicate support of the > mechanism as such, you also need to indicate which push notification > providers (Apple, Firebase etc) you support, as the push request sent by > the proxy looks different for each of them. > > So, I have been thinking that we probably would need a registry for the > type, which contains the type value (e.g., ˇ°APNSˇ± for Apple) together with > a reference to the procedures. Also, in addition to the token, some > providers may require additional information to be sent from the device to > the proxy, so we may need an attribute to allow for that. That would make sense to me if the intent is that the client is going to search for a proxy to use that will support his need. But I doubt that is the use case. Rather, I infer that the client will typically have no choice in what proxy is used, and so will be stuck with whatever it supports. Hence what is really important is just to indicate what he needs and get feedback as to whether it is supported. The option tag mechanism, together with the parameters indicating the desired push service, will achieve that. The advantage over feature tags is that the REGISTER can outright fail if the feature isn't supported, in a way that can be understood by the UA. Using feature tags I think the REGISTER will succeed and then the UA will have to decide whether it can proceed without push support. If that is the desired outcome then feature tags may be fine. Thanks, Paul From nobody Wed Oct 11 10:44:18 2017 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 775F013306A for ; Wed, 11 Oct 2017 10:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgxdl1QHNJRl for ; Wed, 11 Oct 2017 10:44:15 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F40126BF0 for ; Wed, 11 Oct 2017 10:44:14 -0700 (PDT) X-AuditID: c1b4fb2d-fc3a89c00000268d-b1-59de586cfc96 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.AD.09869.C685ED95; Wed, 11 Oct 2017 19:44:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Wed, 11 Oct 2017 19:43:37 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-sip-push-00 Thread-Index: AQHTQQVYKHAx7ZVjvkqN9Wloadjyn6LdDdsAgABB5oD///t3gIABEYEAgABV1ICAADejwA== Date: Wed, 11 Oct 2017 17:43:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56325C02@ESESSMB109.ericsson.se> References: <23ff228f-934b-d5cf-1b2e-92d664d5f0a0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56323BAF@ESESSMB109.ericsson.se> <040189d8-c763-8164-3cba-0aae0cddd5f7@alum.mit.edu> 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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7jW5uxL1IgyfnOC1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj+MF97AVnhCtaP35namC8yt/FyMkhIWAi sXvaIqYuRi4OIYEjjBLzb11hhHAWMUpcn/EDKMPBwSZgIdH9TxukQUQgUOLqkgnMILawgLHE 1pkL2SDiJhILmw8xQ9hhEptPzmUBaWURUJX4dFgdJMwr4Cvx4EMHG8T4y0wS95+3gfVyCjhI 7JzaA9bLKCAm8f3UGiYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSSxYvslRoh6HYkF uz+xQdjaEssWvmaGWCwocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3K TC4uzs/Ty0st2cQIjIeDW37r7mBc/drxEKMAB6MSDy+Xz71IIdbEsuLK3EOMEhzMSiK8D0OA QrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJzU5NLUgtgskycXBKNTAql+RKt3+7 6ZO1S+KpxvyMssJDlff372m2do6t989aceL4IfkcBYObeoprJx0smfMyb/fqkvemz5/FSc90 v5HTIrRB6LvJbeeTGtPSvzCsV3a/tOneG9FfCh1h3YX5W2qLXAJ5V61Vbcpm32T+RiXtvvje izOuHzPIqWi2+td9Vm/1NVHB/GAlluKMREMt5qLiRAA9OBgBgwIAAA== Archived-At: Subject: Re: [sipcore] Draft new: draft-sip-push-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 17:44:16 -0000 Hi, >>>>> 2) Nowhere in here do I see any feedback mechanism from the=20 >>>>> proxy/registrar to the UA indicating that it actually supports this=20 >>>>> mechanism. ISTM that this calls for an option tag mechanism, with=20 >>>>> Require:push in the register request and a Supported:push in the=20 >>>>> response. >>>> >>>> I was thinking of defining feature capability indicators for that. >>>> However, I wanted to submit the initial version, to see whether=20 >>>> people have any interest to work on this in IETF to begin with. >>> >>> IMO an options tag works better here. Presumably the UA will be=20 >>> requesting this with the initial REGISTER, and won't be able to=20 >>> function if the feature isn't supported. The use of Require does=20 >>> exactly the right thing here. >>=20 >> We need to keep in mind that it is not enough to indicate support of=20 >> the mechanism as such, you also need to indicate which push=20 >> notification providers (Apple, Firebase etc) you support, as the push=20 >> request sent by the proxy looks different for each of them. >>=20 >> So, I have been thinking that we probably would need a registry for=20 >> the type, which contains the type value (e.g., "APNS" for Apple)=20 >> together with a reference to the procedures. Also, in addition to the=20 >> token, some providers may require additional information to be sent=20 >> from the device to the proxy, so we may need an attribute to allow for t= hat. > > That would make sense to me if the intent is that the client is going to = search for a proxy to use that=20 > will support his need. But I doubt that is the use case. > > Rather, I infer that the client will typically have no choice in what pro= xy is used, and so will be stuck with whatever it supports. Clients can typically not choose what notification service to use. For exam= ple, an iOS device can only register to, and receive push notifications fro= m, the Apple APNS. So, it's not about choosing a proxy, but the client needs to know whether t= he proxy supports a particular push service. Of course, if the proxy does not support the push service indicated by the = client, it could reject the REGISTER request, but I am not sure we want to = mandate that. For example, the operator may still want to allow the client= to register, and being able to make outgoing calls (e.g., emergency calls)= , even if the device won't be able to receive incoming calls. Regards, Christer From nobody Thu Oct 12 08:52:07 2017 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 DF6A9134528 for ; Thu, 12 Oct 2017 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 opmiKLYl90NQ for ; Thu, 12 Oct 2017 08:52:03 -0700 (PDT) Received: from know-smtprelay-omc-10.server.virginmedia.net (know-smtprelay-omc-10.server.virginmedia.net [80.0.253.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A83613451F for ; Thu, 12 Oct 2017 08:52:01 -0700 (PDT) Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-10-imp with bizsmtp id Lfrr1w0043hDt9d01frzVE; Thu, 12 Oct 2017 16:51:59 +0100 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.1 cv=SeoKDalu c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=48vgC7mUAAAA:8 a=w-9iXJHnM1ginIWIlLQA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 To: sipcore@ietf.org References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <9cd95809-7388-9b8c-8070-83a1ba918b53@alum.mit.edu> <8cd70a3c-b19b-fc07-3644-cc49fef0eead@alum.mit.edu> From: Keith Drage Message-ID: Date: Thu, 12 Oct 2017 16:51:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8cd70a3c-b19b-fc07-3644-cc49fef0eead@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1507823519; bh=drvXvSJ2QV4GRQO44MaW4EUUQRIgOgBjoa0M4wj2RB8=; h=Subject:To:References:From:Date:In-Reply-To; b=K/Qp+oLeQ3B20SCLo8ce9AqSIzZFo0uvclk9Wch4RLHuQ1XP2MBedG9Tc0R1FkPlx 3uMEGMA7rnjiaSn+OnKc/UroVxzxGCNNMV1ggmvXyZ9YpDtimAXczUfHTD+9XgoRE3 L2twpUfj6Cqb9sg52pVS+OAcdwq41LcbPEl0xdgSTkMJ6B9PxU0SyQifeBJJ0UWCoK EKqmu/dqybHbi93R0rfMGLE6bEgTKmmHBEf409R6taSiWKIYLfwUKtqk0DqnVbmxVG RVv5S1BtwdBzSsjrF60zifefnT23ZmsxJrlA9Qc+Uyysnn66bxdAXMbVDeRfcIu6hW azyNR1fVWYbIw== Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 15:52:06 -0000 On this specific point I agree with Paul. If you want to describe a problem for a B2BUA then do so, but the proper behaviour for a proxy is to pass the information on, whether it supports the feature, or does not and therefore does not recognise the information. In regard to the Supported header, this is meant to be a statement about what the original generator of the header supports, not some intermediate along the path (although I know Supported header fields can be generated along the path). Therefore I do not believe there is a case for a proxy deleting information from such a header field. regards Keith On 09-Oct-17 5:17 PM, Paul Kyzivat wrote: > Hi Roland, > > On 10/9/17 10:41 AM, Jesske, Roland wrote: > >> NetA and NetC does support session timer. >> NetB does not. >> So Proxy 2 netB will delete the session timer > > Let me repeat: this is not valid behavior for a proxy. > The proper fix is for Proxy 2 to do what it is required to do by the > specs. > >     Thanks, >     Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Oct 12 10:46:32 2017 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 98E2113454F for ; Thu, 12 Oct 2017 10:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id louS3MTHjyqm for ; Thu, 12 Oct 2017 10:46:22 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404C813420D for ; Thu, 12 Oct 2017 10:46:22 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id r64so2140107qkc.1 for ; Thu, 12 Oct 2017 10:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=N07iDpdNGrnlqEmonGAlEVbtsW5WEK+CHTIaVbAaTjg=; b=c285+VirzcWS9qFti8ghXwEYBv9Ak4nhla3xOLWzCo55Mc94o7L+S6Ud57evWZFy3r 4Ohev9Fki2L7NB2UaCGlPw/13G8zgZ6IjVE2sm4oxfKWpUnC2U8byyFHJKW/VHyGAtSc VJXdNrfZAkNr6oMvo0GeIE4HYQFQXbyra7irZvvikeD5h/YuQOHtftTtnliAE/UaOjR0 C1o6dwdlac3Ta7gMKgTZMRhQoczVSOHtCgtMtB583NQKtw41TDBqw5d7hdAVOgY367OY pZnxyW+XGRb4JxCCztTxodWuY8p5Im/ZVQUQ9yXGPymlLNrzNMFsJ1ZKiURrbGJy4044 8RCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=N07iDpdNGrnlqEmonGAlEVbtsW5WEK+CHTIaVbAaTjg=; b=hWZbQ/248R2YHhWohjes4AOCWawdUOTIfa72WNRMEME1DXG6k6S4EglfrHa14aKseh 34KFqCOiADOo4ZQHBbVQByiV4E3ZMNz0ESgGOxyIumJstgroOizLeOwBINWy5BqW9zkF 7MXXG+vhvqrH18zBMJy2t6FZ7U2WFps9cVYZr5tCOhZBHedcu6z77fts8hGsue5opVd9 D1sQAUd9HKBwCIVZWTPB3cP5mgTcho0Y13asAONSQiQuVdKtCx30O7RTPrh46OCCMg47 MYwk9puvyp92fuRFGpKloP8V91wkbUvhkRvBn8Pl9UQAuEIvdSd4kAlxt7KAMmOjYyqJ AmKA== X-Gm-Message-State: AMCzsaVVjJpkZnz3sqhqqU6B1908KIihcWjSvsQd83ljtNiZu8HNcY6y T9Tmjf1ROWcW6n8ghX9E1EFhmxfCpys= X-Google-Smtp-Source: ABhQp+TokQ6YEjT6m9CJGKGVkHleZ5q+loc64fe9F31ZE35PUtXUFjukaj5srpVWOPp2nkUD/Bup1w== X-Received: by 10.55.53.202 with SMTP id c193mr1693011qka.110.1507830380910; Thu, 12 Oct 2017 10:46:20 -0700 (PDT) Received: from [10.33.193.3] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id x21sm9765198qkb.82.2017.10.12.10.46.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Oct 2017 10:46:19 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 12 Oct 2017 13:46:17 -0400 To: sipcore@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sipcore] draft-holmberg-sipcore-sip-push X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 17:46:25 -0000 Chairs would like to know if we should work on this. Right at the = moment, we=E2=80=99re not having a formal request to adopt. This is = just a question of whether work group members think this is a good thing = to do, as well as fit in our charter. We can also have a discussion on it in Singapore. Brian= From nobody Fri Oct 13 00:29:23 2017 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 85CEE126B7E for ; Fri, 13 Oct 2017 00:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=proximus.com header.b=obJZ0CQa; dkim=pass (1024-bit key) header.d=proximuscorp.onmicrosoft.com header.b=NvsFfei0 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 LJYLEWbbO9-9 for ; Fri, 13 Oct 2017 00:29:18 -0700 (PDT) Received: from mx18.belgacom.be (mx18.belgacom.be [195.13.15.238]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFAE126CB6 for ; Fri, 13 Oct 2017 00:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=proximus.com; i=@proximus.com; q=dns/txt; s=dkim; t=1507879757; x=1539415757; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6PveTfit3Z9c4cbKhtVmPW/eaL7pjumLsR+A6lEUTfY=; b=obJZ0CQaxfyoVCUy+NcRsUePh1YBYxK7ob5Bk8omJiFKEjQD7IIrhV1z /MTULjWXg9wZGOhWydfSvccgY9YN59PtJHmPMMaAgdy0Vk8U+rwTmoP9N 7yff7caAv4R1AU+5rTJh2TVd/urkU5lxrh4zrpP82Swj2m9zGeMLFXZdQ A=; X-IronPort-AV: E=Sophos;i="5.43,369,1503352800"; d="scan'208";a="26644223" Received: from a07584.bgc.net ([10.120.80.100]) by mx18.belgacom.be with ESMTP; 13 Oct 2017 09:29:14 +0200 X-TM-IMSS-Message-ID: <741d42ee001edd80@proximus.com> Received: from A04027.BGC.NET ([10.121.135.24]) by proximus.com ([10.120.80.100]) with ESMTP (TREND IMSS SMTP Service 7.5) id 741d42ee001edd80 ; Fri, 13 Oct 2017 09:29:13 +0200 Received: from A07615.BGC.NET (10.121.135.4) by A04027.BGC.NET (10.121.135.24) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 13 Oct 2017 09:29:13 +0200 Received: from A07615.BGC.NET (10.121.135.4) by A07615.BGC.NET (10.121.135.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Fri, 13 Oct 2017 09:29:13 +0200 Received: from A07624.bgc.net (10.28.29.230) by A07615.BGC.NET (10.121.135.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32 via Frontend Transport; Fri, 13 Oct 2017 09:29:13 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.28.31.158) by outlook.proximus.com (10.28.31.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Fri, 13 Oct 2017 09:29:05 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ProximusCorp.onmicrosoft.com; s=selector1-proximus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6PveTfit3Z9c4cbKhtVmPW/eaL7pjumLsR+A6lEUTfY=; b=NvsFfei0Hr0dAKkDcWXA5NX5T+DUN4S2PP+/FRV9gdIbQVMgOSIEqRNw1/bPn70bYz9I0omE888tb41vo+Cx1B4st94SLSBX6TJ4XO7LgGaZNIXdbnhOOpkwwVwCDk5UhalCGy9DHNBxMdK4AYfSrZjfsrYGLB9BXSM7CksEX6k= Received: from DB6PR0801MB1365.eurprd08.prod.outlook.com (10.168.11.141) by DB6PR0801MB1366.eurprd08.prod.outlook.com (10.168.11.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 13 Oct 2017 07:29:05 +0000 Received: from DB6PR0801MB1365.eurprd08.prod.outlook.com ([fe80::f540:9bcd:71c4:ec01]) by DB6PR0801MB1365.eurprd08.prod.outlook.com ([fe80::f540:9bcd:71c4:ec01%14]) with mapi id 15.20.0077.021; Fri, 13 Oct 2017 07:29:05 +0000 From: "VAN GEEL Jan (SPC/CSP)" To: Brian Rosen , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-holmberg-sipcore-sip-push Thread-Index: AQHTQ4IQNtF9yZaKdkyZc5d582Nfg6LhYsUg Date: Fri, 13 Oct 2017 07:29:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jan.van.geel@proximus.com; x-originating-ip: [195.238.28.16] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0801MB1366; 6:iwAgxvaM/YVwxv4TZQ3+VJt0F+zn0MFRE2FRDCXNOVrwFgnU7mmogSkKZtg1p/j9N0q9gL/Bpb3FpBdiwqcgEnd6OuEDyR1DZGC5zKVot0E+cuk2qBvlDZJPuOdFMtOMburlviYh4R1Oice5WswHc9dX1BkmyZGBX8lU2eELNbnUpbYjIUpoDbpjgEepyHs2NLbhQwOQF/odwLL4mVs6QeJzryvc66SAsm8Zkk5gFqb1Es2CgTyPuxmH6Umhy9ULWpCKeb7PnZ1rvZVr6CHdiPR6fJABMhrgUwgkhQDOqHJKOIERC8/XOcVLoe7mJEeVm/Ph07OZ+Wn39FsTGXUxLA==; 5:vgQnbdWk0/md63FVPE7GN0J/uVHoRiVaEAaPLfzX9xEYBCILXRK/khm0GrLk85/IwNXJK4LcXoRwp/TMPoxdI3yUoaWFPMjlGKxXBpgORRNC5TiD3VbTkEktCAogySaTahe3z25EE98Dz3gO5GzSkni3hGT6l12njQvrXoPYHFw=; 24:EFHE/RhrTKrWJ1AGYUtTnkt11xLzRgrKnOTwJvsfLE3KB14cT75SdLx2981Ffec9cCbkplehPiKymeJ88vDsmS1ey1XHthsKqVOIvpR6d2A=; 7:TAjXALZXHvg9php8YmfnF4ufFtPx82jtBREuzhUT3Lf7PLThJZFJHUOL1HibdrfV3l9P2oElERX9bfOlBgHV+1YiWjekFF1YOj1gswi//I16jat7SaEQ6msB825/ljHtQMbgqnkXyhQBFxhTvqlKJmhzwBqAwrotyU/6BkKoxhjstOV26UeomDEsZOMmERzO0PyNs92klXPd2AHcmhmaPDhfbYBV859QeoOVt0+GgOw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bba8e02f-d82e-4a53-e072-08d5120c1581 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR0801MB1366; x-ms-traffictypediagnostic: DB6PR0801MB1366: x-exchange-antispam-report-test: UriScan:(174211160506117); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0801MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0801MB1366; x-forefront-prvs: 04599F3534 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(13464003)(68736007)(97736004)(2900100001)(229853002)(33656002)(6306002)(9686003)(478600001)(101416001)(55016002)(1720100001)(966005)(6506006)(76176999)(3660700001)(99286003)(189998001)(54356999)(86362001)(53936002)(5250100002)(305945005)(2501003)(7736002)(2906002)(3280700002)(8676002)(74316002)(102836003)(81156014)(3846002)(6116002)(230783001)(8936002)(6246003)(50986999)(316002)(110136005)(6436002)(7696004)(105586002)(2950100002)(5660300001)(53546010)(106356001)(81166006)(14454004)(66066001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0801MB1366; H:DB6PR0801MB1365.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 07:29:05.1127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e7ab81b2-1e84-4bf7-9dcb-b6fec01ed138 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1366 X-TM-AS-MatchedID: 150567-705388-139006-854212-700473-106660-301016-707163-7 00869-700752-700049-710970-700571-701249-139703-708196-700047-700607-139702 -148004-148046-148133-10019-41000-42000-42003 X-OriginatorOrg: proximus.com X-TM-AS-MML: disable Archived-At: Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 07:29:21 -0000 SSBzdXBwb3J0IHRoaXMgd29yaw0KDQpLaW5kIHJlZ2FyZHMNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDogVGh1cnNkYXkgMTIgT2N0b2JlciAyMDE3 IDE5OjQ2DQpUbzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogW3NpcGNvcmVdIGRyYWZ0LWhv bG1iZXJnLXNpcGNvcmUtc2lwLXB1c2gNCg0KQ2hhaXJzIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB3 ZSBzaG91bGQgd29yayBvbiB0aGlzLiAgUmlnaHQgYXQgdGhlIG1vbWVudCwgd2XigJlyZSBub3Qg aGF2aW5nIGEgZm9ybWFsIHJlcXVlc3QgdG8gYWRvcHQuICBUaGlzIGlzIGp1c3QgYSBxdWVzdGlv biBvZiB3aGV0aGVyIHdvcmsgZ3JvdXAgbWVtYmVycyB0aGluayB0aGlzIGlzIGEgZ29vZCB0aGlu ZyB0byBkbywgYXMgd2VsbCBhcyBmaXQgaW4gb3VyIGNoYXJ0ZXIuDQoNCldlIGNhbiBhbHNvIGhh dmUgYSBkaXNjdXNzaW9uIG9uIGl0IGluIFNpbmdhcG9yZS4NCg0KQnJpYW4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlz dA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXBjb3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCioqKioqIERp c2NsYWltZXIgKioqKioNCmh0dHA6Ly93d3cucHJveGltdXMuYmUvbWFpbGRpc2NsYWltZXINCg== From nobody Fri Oct 13 00:33:22 2017 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 A6AF5126CB6 for ; Fri, 13 Oct 2017 00:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaZfBZ9VstGt for ; Fri, 13 Oct 2017 00:33:19 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDDE128D0D for ; Fri, 13 Oct 2017 00:33:19 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v9D7VvlA030300; Fri, 13 Oct 2017 03:33:16 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2djj45a3s2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Oct 2017 03:33:15 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v9D7XEr6005119; Fri, 13 Oct 2017 03:33:15 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v9D7X6Oa005004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Oct 2017 03:33:07 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 13 Oct 2017 07:32:59 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.122]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0361.001; Fri, 13 Oct 2017 03:32:59 -0400 From: "DOLLY, MARTIN C" To: "VAN GEEL Jan (SPC/CSP)" CC: Brian Rosen , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-holmberg-sipcore-sip-push Thread-Index: AQHTQ4IQ+vHqMSbLW0a1Q1l5AO58xqLhYsUggAABM3M= Date: Fri, 13 Oct 2017 07:32:59 +0000 Message-ID: <0849339E-63E3-499C-A17A-58D80D3AA1C6@att.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0849339E63E3499CA17A58D80D3AA1C6attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-13_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710130105 Archived-At: Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 07:33:22 -0000 --_000_0849339E63E3499CA17A58D80D3AA1C6attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support as well Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 13, 2017, at 3:29 AM, VAN GEEL Jan (SPC/CSP) > wrote: I support this work Kind regards -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday 12 October 2017 19:46 To: sipcore@ietf.org Subject: [sipcore] draft-holmberg-sipcore-sip-push Chairs would like to know if we should work on this. Right at the moment, = we=92re not having a formal request to adopt. This is just a question of w= hether work group members think this is a good thing to do, as well as fit = in our charter. We can also have a discussion on it in Singapore. Brian _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DiQg4x3W2NlXFwJU= F9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D ________________________________ ***** Disclaimer ***** https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.proximus.be_maild= isclaimer&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&= m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DEWP_Ve3ez3PwmmUVZ35E8ih= tlOIICsVWm8tzNU9vM1M&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DiQg4x3W2NlXFwJU= F9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D --_000_0849339E63E3499CA17A58D80D3AA1C6attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I support as well

Martin C. Dolly Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com

On Oct 13, 2017, at 3:29 AM, VAN GEEL Jan (SPC/CSP) <jan.van.geel@proximus.com> wrote:

I support this work

Kind regards

-----Original Message-----
From: sipcore [mailto:sip= core-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday 12 October 2017 19:46
To: sipcore@ietf.org Subject: [sipcore] draft-holmberg-sipcore-sip-push

Chairs would like to know if we should work on this.  Right at t= he moment, we=92re not having a formal request to adopt.  This is just= a question of whether work group members think this is a good thing to do,= as well as fit in our charter.

We can also have a discussion on it in Singapore.

Brian
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9= v8uCSSQhCmpw7ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&am= p;s=3DiQg4x3W2NlXFwJUF9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D

________________________________

***** Disclaimer *****
https:/= /urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.proximus.be_maildisclaim= er&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG= 0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DEWP_Ve3ez3= PwmmUVZ35E8ihtlOIICsVWm8tzNU9vM1M&e=3D
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9= v8uCSSQhCmpw7ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&am= p;s=3DiQg4x3W2NlXFwJUF9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D
--_000_0849339E63E3499CA17A58D80D3AA1C6attcom_-- From nobody Fri Oct 13 07:34:36 2017 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 0414E120720 for ; Fri, 13 Oct 2017 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax5N9Mi2ur5D for ; Fri, 13 Oct 2017 07:34:33 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD25E13295C for ; Fri, 13 Oct 2017 07:34:32 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 1DC56120598 for ; Fri, 13 Oct 2017 16:34:31 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 015A580068 for ; Fri, 13 Oct 2017 16:34:31 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0361.001; Fri, 13 Oct 2017 16:34:30 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] draft-holmberg-sipcore-sip-push Thread-Index: AQHTQ4IMb+LVNcrURUauhG/y8G9eU6LhQVqAgAABF4CAAJcmQA== Date: Fri, 13 Oct 2017 14:34:29 +0000 Message-ID: <734_1507905271_59E0CEF7_734_44_1_8B970F90C584EA4E97D5BAAC9172DBB81D62895F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: , <0849339E-63E3-499C-A17A-58D80D3AA1C6@att.com> In-Reply-To: <0849339E-63E3-499C-A17A-58D80D3AA1C6@att.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81D62895FOPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:34:35 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB81D62895FOPEXCLILMA4corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Marianne De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : vendredi 13 octobre 2017 09:33 =C0 : VAN GEEL Jan (SPC/CSP) Cc : sipcore@ietf.org Objet : Re: [sipcore] draft-holmberg-sipcore-sip-push I support as well Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 13, 2017, at 3:29 AM, VAN GEEL Jan (SPC/CSP) > wrote: I support this work Kind regards -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday 12 October 2017 19:46 To: sipcore@ietf.org Subject: [sipcore] draft-holmberg-sipcore-sip-push Chairs would like to know if we should work on this. Right at the moment, = we're not having a formal request to adopt. This is just a question of whe= ther work group members think this is a good thing to do, as well as fit in= our charter. We can also have a discussion on it in Singapore. Brian _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DiQg4x3W2NlXFwJU= F9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D ________________________________ ***** Disclaimer ***** https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.proximus.be_maild= isclaimer&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&= m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DEWP_Ve3ez3PwmmUVZ35E8ih= tlOIICsVWm8tzNU9vM1M&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DiQg4x3W2NlXFwJU= F9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB81D62895FOPEXCLILMA4corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1

 

Marianne

 

De : sipc= ore [mailto:sipcore-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : vendredi 13 octobre 2017 09:33
=C0 : VAN GEEL Jan (SPC/CSP)
Cc : sipcore@ietf.org
Objet : Re: [sipcore] draft-holmberg-sipcore-sip-push

 

I support as well

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com=


On Oct 13, 2017, at 3:29 AM, VAN GEEL Jan (SPC/CSP) <jan.van.geel@proximus.com> wrote:

I support this work

Kind regards

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday 12 October 2017 19:46
To: sipcore@ietf.org
Subject: [sipcore] draft-holmberg-sipcore-sip-push

Chairs would like to know if we should work on this.  Right at the mom= ent, we’re not having a formal request to adopt.  This is just a= question of whether work group members think this is a good thing to do, a= s well as fit in our charter.

We can also have a discussion on it in Singapore.

Brian
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3D= iQg4x3W2NlXFwJUF9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D

________________________________

***** Disclaimer *****
https://urlde= fense.proofpoint.com/v2/url?u=3Dhttp-3A__www.proximus.be_maildisclaimer&= ;d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&a= mp;m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DEWP_Ve3ez3PwmmUV= Z35E8ihtlOIICsVWm8tzNU9vM1M&e=3D
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3D= iQg4x3W2NlXFwJUF9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB81D62895FOPEXCLILMA4corp_-- From nobody Tue Oct 17 00:07:44 2017 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 E12751332E1 for ; Tue, 17 Oct 2017 00:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er9hnnaP2A98 for ; Tue, 17 Oct 2017 00:07:39 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44121332D5 for ; Tue, 17 Oct 2017 00:07:39 -0700 (PDT) Received: from [192.168.40.19] (h-205-12.A165.corp.bahnhof.se [176.10.205.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id A09B2B20; Tue, 17 Oct 2017 09:07:35 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <70F63F58-40A5-4337-95EA-01B36260FD05@edvina.net> Date: Tue, 17 Oct 2017 09:07:34 +0200 Cc: Olle E Johansson To: sipcore@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sipcore] SIP timer B in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 07:07:42 -0000 Hi! Section 17.1.1.2 of 3261 says: "For any transport, the client transaction MUST start timer B with a = value of 64*T1 seconds (Timer B controls transaction timeouts).=E2=80=9D This MUST surprised me when someone pointed at it recently. For a very = long time, almost all SIP implementations has a user-configurable setting for Timer B, so there must be a reason why this MUST is ignored. = Many web pages found with my friends at G talk about a default setting being 64*T1, but the RFC is quite clear that it=E2=80=99s not = something one should not modify. In my experience there are plenty of situations where you want to modify = T1 to set the number of retransmissions and speed of them independently of the end of transaction. The user = experience comes first and you want SRV failover to be quite quick. Lowering the T1 will generate more of a packet storm = which in many cases doesn=E2=80=99t help. Anyone from that time long ago when this was written that remembers why = there is a MUST here? Was the MUST just indicating =E2=80=9Cstart timer B=E2=80=9D or was it really a MUST = on 64*T1? Could be an edit that made this turn out wrong... Do we have any other documents (or part of 3261) that makes Timer B = configurable? Thank you for your feedback! /Olle From nobody Tue Oct 17 03:12:32 2017 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 792CD133245 for ; Tue, 17 Oct 2017 03:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku4Y28nVa5l5 for ; Tue, 17 Oct 2017 03:12:23 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25121126BF0 for ; Tue, 17 Oct 2017 03:12:22 -0700 (PDT) X-AuditID: c1b4fb3a-de7ff70000006897-fc-59e5d78328de Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 82.6A.26775.387D5E95; Tue, 17 Oct 2017 12:12:20 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 17 Oct 2017 12:12:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C9myqwNtSdRHXWobkyBHwIUQLujrIyE3wqrY6iQ5e4o=; b=H4V6sjywrXHKaMb/XLncVC61a7UbPB+d/unzFuQnN+maqsFB5MOkhbPPOQI+lBuHcJtxvQ2uQLECpYFOLz5rfIxLbJHRuT2IBQDy29higc9lGrOL4YNnan/OxzzXxCQWffNm4ABqszxDgTXU3jnwOx0xKtZHIe6c+Gfptl/0Ojg= Received: from HE1PR07MB3180.eurprd07.prod.outlook.com (10.170.245.30) by HE1PR07MB3180.eurprd07.prod.outlook.com (10.170.245.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 17 Oct 2017 10:12:18 +0000 Received: from HE1PR07MB3180.eurprd07.prod.outlook.com ([fe80::24b7:6f37:5d3b:f12a]) by HE1PR07MB3180.eurprd07.prod.outlook.com ([fe80::24b7:6f37:5d3b:f12a%13]) with mapi id 15.20.0077.022; Tue, 17 Oct 2017 10:12:18 +0000 From: Ivo Sedlacek To: "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-holmberg-sipcore-sip-push Thread-Index: AQHTQ4IhFZgtozaI20+QA8vdhdjLqKLhYuGAgAABF4CAAHXEgIAF/6ZQ Date: Tue, 17 Oct 2017 10:12:18 +0000 Message-ID: References: , <0849339E-63E3-499C-A17A-58D80D3AA1C6@att.com> <734_1507905271_59E0CEF7_734_44_1_8B970F90C584EA4E97D5BAAC9172DBB81D62895F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <734_1507905271_59E0CEF7_734_44_1_8B970F90C584EA4E97D5BAAC9172DBB81D62895F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com; x-originating-ip: [88.208.76.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3180; 6:fG+YqiVGCj27K+qmwtl9bs16MjJR5K7Q0tm1KgOdFtLgASjA2FrlgmN21zq+c/wQfizO86otZC7xzr217Tl7JVaRtJ+6IPgFWhcYBkc1QX6tH+2+yQaJWtJ/vDRAQn2NBRra+HWRXPZZnQN/pmZTDPwoIPjE3GVqr15DleG7lDsGVpo5pCXeSmR9yR4B6cc5xgiBn+CfMNAoKOG4TQtMmg0fno4iihD7D3rPOljrAT+whCDBswvWJw8TMJpLdVIrnuTs5BuaqZeZdvtupySBP6ud9Cf4cj39iA6sMdDF4YFXmABIfLjL9tZ22Osvq8V0p6bSAHxPFjR56+vXe3P9lA==; 5:wn/i0XHxzeyTgiBq3K0gI0CfwRfqdCKCXnqt+ii1AhpRchNArK4QZOFYo+jmnOFCNxFJoa+VQnLSz2DOxong5JWIalHiOVgTuoyGvSZmz2nI7zYegex45IlOzG2+BJhOUa54MImnoYpvgj2O3Oc7xg==; 24:6IpaYjOjSx6GCs9un6IeyHDS3oQEB4LXg4XT/BLG43jremHwuyUcjShd/uIiRXXIBBT6Q50AvDwLL/47ywnB9P3LthEyElc6eY1PwWnAE/Y=; 7:K30mI3JQRmjCvQB7UXnLeTOZY0NT9X/HhkoI+GRTP1ZebZoKrwuOFGH0IASkOgRYXcyEBE9CNF7bITn2P/hmoDETNG0okN/c/IgnPJNO8bSAAI64uFysxQPR3ng+Jj5N7wIf3B3Hh//GRrPTSkmxMFdSAlVjsn4f9lyOLl3UoF+5RbbP0Eaj6RIr2+IJkIJVDsiwvLU50hzhBt2GbNv6vGYdsWrY7BP/mcmhkYrY2zQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 872d8237-78b8-4ab9-4e52-08d515478c68 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB3180; x-ms-traffictypediagnostic: HE1PR07MB3180: x-exchange-antispam-report-test: UriScan:(10436049006162)(97927398514766)(18271650672692)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3180; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3180; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(13464003)(377454003)(189002)(252514010)(199003)(24454002)(2950100002)(3660700001)(55016002)(9686003)(99286003)(86362001)(76176999)(790700001)(54356999)(6116002)(54896002)(74316002)(606006)(102836003)(101416001)(66066001)(8676002)(8936002)(50986999)(68736007)(6246003)(81156014)(3280700002)(110136005)(7696004)(6306002)(3846002)(25786009)(14454004)(105586002)(106356001)(229853002)(81166006)(6506006)(53936002)(5660300001)(6436002)(189998001)(2900100001)(33656002)(7736002)(5250100002)(325944009)(316002)(478600001)(2501003)(2906002)(575784001)(236005)(5890100001)(966005)(230783001)(97736004)(93886005)(53546010); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3180; H:HE1PR07MB3180.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3180A4301214D9C348C06DE5E54C0HE1PR07MB3180eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 10:12:18.3581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3180 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe885286s0evUfLAiGkiiuMqkRCvsS5kQ9S0tsYYer3PTc7yk H2qlVl5qWd7TpjhMWoGXWd7L5T0otWTLDyJ5TxQx1C5guZ0Ffvv9///n/T888NKk9JXAjY5V JTOsSqGUCR2ospA3h7yzzDOhR3KaxH6vM7sIv7WfjcJAIkiv/0UEZc0OCi8RVxxORjLK2FSG PXz6ukNMy3wNlVh7B91orwvUoOXkXCSmAfvC985WUS5yoKW4B0FDqcEuBhAULZUSVkHhBySU Vy+TfFJEwFxlsYAXUwgqswtJa5kQy6HA2COwsjOOAstGg42d8HGY1eYQvH8CZvosW0xv8Vno vBdotSnsDnmTk0IrS3AY3F7QIL7/PQFfDa02IcaZCDq1JbZShPfAxtBLWymJXWF8WkfwF2HQ d3wieXaBhalN+3wY/M37IeD9g6DN1op43g+jujzbAsB3RZA/tmEP5NBcsIR4vgD6FTPFDz1D UF83ax/yhPbfE3aOg3XDqv1BPFR8NthbPwhgvmDdHuyDqo1FER90CGHN8Fj0CHmVbzuDZzXk vDPYWIIdYbBsmuJ9OViKCoU8e0Ft9SLJszeUbpqo7X4VEr1ALhzDcQnRPj5yho2N4Di1Sq5i khvR1ifqNv7xb0Hdc2dMCNNItkuS3jwTKhUoUrn0BBMCmpQ5SzZHtixJpCI9g2HV19gUJcOZ 0F6akrlKAruGQ6Q4WpHMxDNMIsP+Twla7KZBTknTEeGpKwFx2RXe96OSdi/PehYN+zRzaR9b zlP4ucW3dnI9Xxy1QwkVjQOXR9KQbnNkqu+iR4r5VjErDfabWM0v7/XQZLzVh5sl35Zr3I2n bvYH1ztnsWPGuCHdQMwT8VN/1XBBSRvq8h9/6KgO+LLzwLm2rmNNo7398VcrZBQXozjqSbKc 4h8kNL5nQAMAAA== Archived-At: Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 10:12:30 -0000 --_000_HE1PR07MB3180A4301214D9C348C06DE5E54C0HE1PR07MB3180eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, > Chairs would like to know if we should work on this. I support sipcore working on this draft. Kind regards Ivo From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of marianne.mohal= i@orange.com Sent: Friday, October 13, 2017 4:34 PM To: sipcore@ietf.org Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push +1 Marianne De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de DOLLY, MARTIN = C Envoy=E9 : vendredi 13 octobre 2017 09:33 =C0 : VAN GEEL Jan (SPC/CSP) Cc : sipcore@ietf.org Objet : Re: [sipcore] draft-holmberg-sipcore-sip-push I support as well Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 13, 2017, at 3:29 AM, VAN GEEL Jan (SPC/CSP) > wrote: I support this work Kind regards -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday 12 October 2017 19:46 To: sipcore@ietf.org Subject: [sipcore] draft-holmberg-sipcore-sip-push Chairs would like to know if we should work on this. Right at the moment, = we're not having a formal request to adopt. This is just a question of whe= ther work group members think this is a good thing to do, as well as fit in= our charter. We can also have a discussion on it in Singapore. Brian _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DiQg4x3W2NlXFwJU= F9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D ________________________________ ***** Disclaimer ***** https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.proximus.be_maild= isclaimer&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&= m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DEWP_Ve3ez3PwmmUVZ35E8ih= tlOIICsVWm8tzNU9vM1M&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DiQg4x3W2NlXFwJU= F9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_HE1PR07MB3180A4301214D9C348C06DE5E54C0HE1PR07MB3180eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

> Chairs would like to know if we should work on thi= s.

 

I support sipcore working on this draft.

 

Kind regards

 

Ivo

 

From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of marianne.mohali@orange.com
Sent: Friday, October 13, 2017 4:34 PM
To: sipcore@ietf.org
Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push

 

+1

 

Marianne

 

De : sipc= ore [mailto:sipcore-bounces@iet= f.org] De la part de DOLLY, MARTIN C
Envoy=E9 : vendredi 13 octobre 2017 09:33
=C0 : VAN GEEL Jan (SPC/CSP)
Cc : sipcore@ietf.org Objet : Re: [sipcore] draft-holmberg-sipcore-sip-push

 

I support as well

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com=

On Oct 13, 2017, at 3:29 AM, VAN GEEL Jan (SPC/CSP) <jan.van.geel@proximus.com> wrote:

I support this work

Kind regards

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday 12 October 2017 19:46
To: sipcore@ietf.org
Subject: [sipcore] draft-holmberg-sipcore-sip-push

Chairs would like to know if we should work on this.  Right at the mom= ent, we’re not having a formal request to adopt.  This is just a= question of whether work group members think this is a good thing to do, a= s well as fit in our charter.

We can also have a discussion on it in Singapore.

Brian
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3D= iQg4x3W2NlXFwJUF9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D

________________________________

***** Disclaimer *****
https://urlde= fense.proofpoint.com/v2/url?u=3Dhttp-3A__www.proximus.be_maildisclaimer&= ;d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&a= mp;m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DEWP_Ve3ez3PwmmUV= Z35E8ihtlOIICsVWm8tzNU9vM1M&e=3D
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3D= iQg4x3W2NlXFwJUF9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_HE1PR07MB3180A4301214D9C348C06DE5E54C0HE1PR07MB3180eurp_-- From nobody Tue Oct 17 14:59:30 2017 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 3D44E126B7E for ; Tue, 17 Oct 2017 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 L_bIYMU7ye1T for ; Tue, 17 Oct 2017 14:59:26 -0700 (PDT) Received: from know-smtprelay-omc-10.server.virginmedia.net (know-smtprelay-omc-10.server.virginmedia.net [80.0.253.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E84133085 for ; Tue, 17 Oct 2017 14:59:24 -0700 (PDT) Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-10-imp with bizsmtp id NlzM1w00b3hDt9d01lzP63; Tue, 17 Oct 2017 22:59:23 +0100 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.1 cv=SeoKDalu c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=48vgC7mUAAAA:8 a=--M0ZSKxwo2SvMkeg6AA:9 a=EjYSXI93-bUTKF6Z:21 a=EESo2ZuaL2sf2yV1:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 To: sipcore@ietf.org References: <70F63F58-40A5-4337-95EA-01B36260FD05@edvina.net> From: Keith Drage Message-ID: <22017c1f-9639-9b5a-4a74-ef6a3335ec07@ntlworld.com> Date: Tue, 17 Oct 2017 22:59:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <70F63F58-40A5-4337-95EA-01B36260FD05@edvina.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1508277563; bh=uueWFP8kb7+GXfVWt6foBQrY45glbvgxHOjzD/gVCKI=; h=Subject:To:References:From:Date:In-Reply-To; b=NOAjvFEqr6X28kLTemsjhKA/SRihtqOyMIv/6C6ZHbXKtgdJtxmqnEEUTw46pS+38 dLoJ8TjHzGk+3pufFcigDejFgwQJbMTaV4vJkb4QRG7CNceYdN5VQnmBGQ+cFNjiyd lFLTqLzVh3/gt2UMN2bIg/9jGsceEg6u52fseSj3xiT0Fga4EUckMJgLwlf/Pb8I3v 6RAkEcC5y/wVyy+BTmzaUwet8KqleWJUlkdWpWnzJdw/g0TwmgcTX+3hE2Ijshga5R RgBNOK52ZhftGIopsbCVdhTWehDuSVb2M7HgiS+4f7SH4w2/ohg++qWEHxsj4qyIGL B8IRlzRuyHpjw== Archived-At: Subject: Re: [sipcore] SIP timer B in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 21:59:29 -0000 I don't go back far enough to have the history of this - it is well over 17 years ago, but: My perspective has always been that these timers are the protocol protection timers, i.e. those that prevent the protocol getting locked up and the protocol disappearing into a state that it cannot get out of, particularly when it is running over UDP where it also needs to provide a mechanism for giving some reliability to messages. There is nothing to stop the user implementing timers at an application level that are shorter than this, and running in parallel to the protocol level timers, and then using the cancellation mechanisms as appropriate within the protocol to clear the protocol. Those timers could depend on the needs of the application, and the needs of human user interaction, therefore applications supporting a voice call might take a different approach to one running MSRP. Therefore timer B is not shorter in this viewpoint, merely never expires because something else at the application layer gets there first. I would add that anyone designing an application with such shorter timers needs to ensure that they are not creating a mechanism for a denial of service attack using this application. regards Keith On 17-Oct-17 8:07 AM, Olle E. Johansson wrote: > Hi! > > Section 17.1.1.2 of 3261 says: > "For any transport, the client transaction MUST start timer B with a value > of 64*T1 seconds (Timer B controls transaction timeouts).” > > This MUST surprised me when someone pointed at it recently. For a very long time, almost all SIP implementations has a user-configurable > setting for Timer B, so there must be a reason why this MUST is ignored. Many web pages found with my friends at G talk about a default > setting being 64*T1, but the RFC is quite clear that it’s not something one should not modify. > > In my experience there are plenty of situations where you want to modify T1 to set the number of retransmissions and > speed of them independently of the end of transaction. The user experience comes first and you want SRV failover to > be quite quick. Lowering the T1 will generate more of a packet storm which in many cases doesn’t help. > > Anyone from that time long ago when this was written that remembers why there is a MUST here? Was the MUST > just indicating “start timer B” or was it really a MUST on 64*T1? Could be an edit that made this turn out wrong... > > Do we have any other documents (or part of 3261) that makes Timer B configurable? > > Thank you for your feedback! > > /Olle > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Oct 18 19:38:03 2017 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 2DBBC132076 for ; Wed, 18 Oct 2017 19:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 KgI5uOS3pDvz for ; Wed, 18 Oct 2017 19:37:54 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 1107A13301C for ; Wed, 18 Oct 2017 19:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1508380674; x=1539916674; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=a+wyI8we3bpoqQboFNB83xlBAITma6542MuZ4qulbf4=; b=XlcEa0vM0QgAVzjZm6wEzv3n09HBtrKgTYnDPB2erb+u5tWtc21Ez3mW xSQnJw/GjnGEMaEb16wRK57NhU0awWcL14QMcxO2z0PXAeYMbqMzKY5rs AOxHWf33CXnBj2qTrUQsCo+6Bwvh9DiA50YcJZHlKTBx6VpGTVvqPCfoR TXbCtXFb9TlH7SymZb/iiykGuvAt1dyg4KWG/fgpM7Zhbc4YsRHRUaZJn ENIAB/pVk0gx07cIDJmtElMNrle/wWXfC4g8S7dxTQhG73KQlc4ux3HX3 hrc7LZZfl9KB3MUQGYAzFk9HVSuo5esOqk2OGTyd8P13LDfv5DojErhNj A==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2017 04:37:51 +0200 X-IronPort-AV: E=Sophos;i="5.43,399,1503352800"; d="scan'208";a="751176625" Received: from he101943.emea1.cds.t-internal.com ([10.169.119.83]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 19 Oct 2017 04:37:51 +0200 Received: from HE106143.EMEA1.cds.t-internal.com (10.169.119.77) by HE101943.emea1.cds.t-internal.com (10.169.119.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 19 Oct 2017 04:37:50 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE106143.EMEA1.cds.t-internal.com (10.169.119.77) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 19 Oct 2017 04:37:50 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 19 Oct 2017 04:37:16 +0200 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 19 Oct 2017 02:37:49 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Thu, 19 Oct 2017 02:37:49 +0000 From: "Jesske, Roland" To: Keith Drage , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP timer B in RFC 3261 Thread-Index: AQHTRxalYBg/87hv1kW0z2/860bkuaLomDSAgAHfbnA= Date: Thu, 19 Oct 2017 02:37:49 +0000 Message-ID: References: <70F63F58-40A5-4337-95EA-01B36260FD05@edvina.net> <22017c1f-9639-9b5a-4a74-ef6a3335ec07@ntlworld.com> In-Reply-To: <22017c1f-9639-9b5a-4a74-ef6a3335ec07@ntlworld.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.196] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0483; 6:d3AAdlzeTLwOvSTTZGmyaxH7w5iyqUEEWIMvxnNg178HZCaq5xdp4YdaD20NAikz5b0HxinJXPrNl/iTaK7XnfFSC4YSt18DMjHmKCy7dflGUxlOp5L+6UKXFvPq4qMDQEoilBIpNavU/1I74l8Seg761m6KUB5SiedYb+9WXNMzTBOmbglqxflJKGyveVCBV0aTu2DXelK1gwW4fN0fA6inbDmif85LMdi0sSZztvLPVToXX8uXwG6U1qLlImobUFKGX0AkG6bMq25w9cVF45+WWOcIxsJzoQXu42HaHSU59wt11Og14sdOqKlONfGs5sTmnGWiIz/11gurmQ3lIQ==; 5:CbhRsng0yM8eQWIXoZVWN/n33fDRc3eqU3UBRy9Z4FrCW/eVSsb4NdKkStuzH4f0REWhC/PAYxMkfTj2hprX+tBx/ODHxKJHBRvfF3YNFEo+z0qzk5NKAPCSJXBT1EsdRIeludCvyXU2QmB1S5MhIQ==; 24:zecV2OIzj2vmB7ahfHrzcDk/jBsOW/fmVxYqe56+P6M6CC8nxwR7ioxq2glE/Xh3waWyyQvyIAuAjdbEbfdaimc3tqbmSMzy7m6lIZGZb4U=; 7:8x8UjLfbtF1ELvIiea9PVL6n2r+KA36xXsvPXFKLdk25iNoGZzf5uFmnpAyqDH0yImSFc+lgq1PUzhIU3IfZSwRFFr8Aaj9bQJZPfBVDzoAeWvpiTOeFq+DZ0Gfkle3Fm+XUct1rkk1j6jRIkJqXPBUmTBGHN/2oR2DidZg0FRipCTqjxKu02uY87DJ2Hzf5bKtllkhacT0IamEj2CFALiXukUaSxXk42P+ncOuWZZ8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ea951970-6bbb-4238-6485-08d5169a63ab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0483; x-ms-traffictypediagnostic: FRAPR01MB0483: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(131327999870524); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0483; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0483; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(24454002)(199003)(189002)(377454003)(81156014)(551934003)(3660700001)(305945005)(86362001)(66066001)(75402003)(5250100002)(2501003)(54356999)(50986999)(101416001)(2950100002)(76176999)(106356001)(105586002)(345774005)(316002)(110136005)(102836003)(6116002)(3846002)(55016002)(189998001)(68736007)(6306002)(2906002)(74482002)(72206003)(53546010)(9686003)(14454004)(8676002)(81166006)(5660300001)(478600001)(8936002)(7736002)(7696004)(97736004)(33656002)(3280700002)(966005)(53936002)(8656005)(8656005)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0483; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 02:37:49.4182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0483 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] SIP timer B in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 02:37:57 -0000 SGkgS2VpdGgsDQpZb3UgY2FuICJjb25maWd1cmUiICBUaW1lciBCLiBCdXQgeW91IGNhbiBkbyBp dCBvbmx5IHZpYSBUMSwgc2luY2UgVDEgbWF5IGJlIGNob29zZSBpdCBzaG9ydGVyIChub3QgcmVj b21tZW5kZWQpIG9yIGxvbmdlciBhcyBkZWZpbmVkIGluIHNlY3Rpb24gDQoxNy4xLjEuMiBGb3Jt YWwgRGVzY3JpcHRpb24NClRoZSBkZWZhdWx0IHZhbHVlIGZvciBUMSBpcyA1MDAgbXMuICBUMSBp cyBhbiBlc3RpbWF0ZSBvZiB0aGUgUlRUDQogICBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHNlcnZl ciB0cmFuc2FjdGlvbnMuICBFbGVtZW50cyBNQVkgKHRob3VnaCBpdA0KICAgaXMgTk9UIFJFQ09N TUVOREVEKSB1c2Ugc21hbGxlciB2YWx1ZXMgb2YgVDEgd2l0aGluIGNsb3NlZCwgcHJpdmF0ZQ0K ICAgbmV0d29ya3MgdGhhdCBkbyBub3QgcGVybWl0IGdlbmVyYWwgSW50ZXJuZXQgY29ubmVjdGlv bi4gIFQxIE1BWSBiZQ0KICAgY2hvc2VuIGxhcmdlciwgYW5kIHRoaXMgaXMgUkVDT01NRU5ERUQg aWYgaXQgaXMga25vd24gaW4gYWR2YW5jZQ0KICAgKHN1Y2ggYXMgb24gaGlnaCBsYXRlbmN5IGFj Y2VzcyBsaW5rcykgdGhhdCB0aGUgUlRUIGlzIGxhcmdlci4NCiAgIFdoYXRldmVyIHRoZSB2YWx1 ZSBvZiBUMSwgdGhlIGV4cG9uZW50aWFsIGJhY2tvZmZzIG9uIHJldHJhbnNtaXNzaW9ucw0KICAg ZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBNVVNUIGJlIHVzZWQuDQoNCkJ1dCBrZWVwIGluIG1p bmQgIGlmIHlvdSBjaGFuZ2UgVDEgdGhlbiB5b3UgY2hhbmdlIGFsbCBUMSBkZXBlbmRlbnQgdGlt ZXJzLg0KDQpCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQoNCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBO YWNocmljaHQtLS0tLQ0KPiBWb246IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIEltIEF1ZnRyYWcgdm9uIEtlaXRoIERyYWdlDQo+IEdlc2VuZGV0OiBEaWVuc3RhZywg MTcuIE9rdG9iZXIgMjAxNyAyMzo1OQ0KPiBBbjogc2lwY29yZUBpZXRmLm9yZw0KPiBCZXRyZWZm OiBSZTogW3NpcGNvcmVdIFNJUCB0aW1lciBCIGluIFJGQyAzMjYxDQo+IA0KPiBJIGRvbid0IGdv IGJhY2sgZmFyIGVub3VnaCB0byBoYXZlIHRoZSBoaXN0b3J5IG9mIHRoaXMgLSBpdCBpcyB3ZWxs IG92ZXINCj4gMTcgeWVhcnMgYWdvLCBidXQ6DQo+IA0KPiBNeSBwZXJzcGVjdGl2ZSBoYXMgYWx3 YXlzIGJlZW4gdGhhdCB0aGVzZSB0aW1lcnMgYXJlIHRoZSBwcm90b2NvbA0KPiBwcm90ZWN0aW9u IHRpbWVycywgaS5lLiB0aG9zZSB0aGF0IHByZXZlbnQgdGhlIHByb3RvY29sIGdldHRpbmcgbG9j a2VkIHVwIGFuZA0KPiB0aGUgcHJvdG9jb2wgZGlzYXBwZWFyaW5nIGludG8gYSBzdGF0ZSB0aGF0 IGl0IGNhbm5vdCBnZXQgb3V0IG9mLCBwYXJ0aWN1bGFybHkNCj4gd2hlbiBpdCBpcyBydW5uaW5n IG92ZXIgVURQIHdoZXJlIGl0IGFsc28gbmVlZHMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IN Cj4gZ2l2aW5nIHNvbWUgcmVsaWFiaWxpdHkgdG8gbWVzc2FnZXMuDQo+IA0KPiBUaGVyZSBpcyBu b3RoaW5nIHRvIHN0b3AgdGhlIHVzZXIgaW1wbGVtZW50aW5nIHRpbWVycyBhdCBhbiBhcHBsaWNh dGlvbiBsZXZlbA0KPiB0aGF0IGFyZSBzaG9ydGVyIHRoYW4gdGhpcywgYW5kIHJ1bm5pbmcgaW4g cGFyYWxsZWwgdG8gdGhlIHByb3RvY29sIGxldmVsIHRpbWVycywNCj4gYW5kIHRoZW4gdXNpbmcg dGhlIGNhbmNlbGxhdGlvbiBtZWNoYW5pc21zIGFzIGFwcHJvcHJpYXRlIHdpdGhpbiB0aGUNCj4g cHJvdG9jb2wgdG8gY2xlYXIgdGhlIHByb3RvY29sLiBUaG9zZSB0aW1lcnMgY291bGQgZGVwZW5k IG9uIHRoZSBuZWVkcyBvZg0KPiB0aGUgYXBwbGljYXRpb24sIGFuZCB0aGUgbmVlZHMgb2YgaHVt YW4gdXNlciBpbnRlcmFjdGlvbiwgdGhlcmVmb3JlDQo+IGFwcGxpY2F0aW9ucyBzdXBwb3J0aW5n IGEgdm9pY2UgY2FsbCBtaWdodCB0YWtlIGEgZGlmZmVyZW50IGFwcHJvYWNoIHRvIG9uZQ0KPiBy dW5uaW5nIE1TUlAuDQo+IA0KPiBUaGVyZWZvcmUgdGltZXIgQiBpcyBub3Qgc2hvcnRlciBpbiB0 aGlzIHZpZXdwb2ludCwgbWVyZWx5IG5ldmVyIGV4cGlyZXMNCj4gYmVjYXVzZSBzb21ldGhpbmcg ZWxzZSBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgZ2V0cyB0aGVyZSBmaXJzdC4NCj4gDQo+IEkg d291bGQgYWRkIHRoYXQgYW55b25lIGRlc2lnbmluZyBhbiBhcHBsaWNhdGlvbiB3aXRoIHN1Y2gg c2hvcnRlciB0aW1lcnMNCj4gbmVlZHMgdG8gZW5zdXJlIHRoYXQgdGhleSBhcmUgbm90IGNyZWF0 aW5nIGEgbWVjaGFuaXNtIGZvciBhIGRlbmlhbCBvZg0KPiBzZXJ2aWNlIGF0dGFjayB1c2luZyB0 aGlzIGFwcGxpY2F0aW9uLg0KPiANCj4gcmVnYXJkcw0KPiANCj4gS2VpdGgNCj4gDQo+IA0KPiAN Cj4gT24gMTctT2N0LTE3IDg6MDcgQU0sIE9sbGUgRS4gSm9oYW5zc29uIHdyb3RlOg0KPiA+IEhp IQ0KPiA+DQo+ID4gU2VjdGlvbiAxNy4xLjEuMiBvZiAzMjYxIHNheXM6DQo+ID4gIkZvciBhbnkg dHJhbnNwb3J0LCB0aGUgY2xpZW50IHRyYW5zYWN0aW9uIE1VU1Qgc3RhcnQgdGltZXIgQiB3aXRo IGEgdmFsdWUNCj4gPiAgICAgb2YgNjQqVDEgc2Vjb25kcyAoVGltZXIgQiBjb250cm9scyB0cmFu c2FjdGlvbiB0aW1lb3V0cyku4oCdDQo+ID4NCj4gPiBUaGlzIE1VU1Qgc3VycHJpc2VkIG1lIHdo ZW4gc29tZW9uZSBwb2ludGVkIGF0IGl0IHJlY2VudGx5LiBGb3IgYSB2ZXJ5DQo+ID4gbG9uZyB0 aW1lLCBhbG1vc3QgYWxsIFNJUCBpbXBsZW1lbnRhdGlvbnMgaGFzIGEgdXNlci1jb25maWd1cmFi bGUNCj4gPiBzZXR0aW5nIGZvciBUaW1lciBCLCBzbyB0aGVyZSBtdXN0IGJlIGEgcmVhc29uIHdo eSB0aGlzIE1VU1QgaXMgaWdub3JlZC4NCj4gTWFueSB3ZWIgcGFnZXMgZm91bmQgd2l0aCBteSBm cmllbmRzIGF0IEcgdGFsayBhYm91dCBhIGRlZmF1bHQgc2V0dGluZw0KPiBiZWluZyA2NCpUMSwg YnV0IHRoZSBSRkMgaXMgcXVpdGUgY2xlYXIgdGhhdCBpdOKAmXMgbm90IHNvbWV0aGluZyBvbmUg c2hvdWxkIG5vdA0KPiBtb2RpZnkuDQo+ID4NCj4gPiBJbiBteSBleHBlcmllbmNlIHRoZXJlIGFy ZSBwbGVudHkgb2Ygc2l0dWF0aW9ucyB3aGVyZSB5b3Ugd2FudCB0bw0KPiA+IG1vZGlmeSBUMSB0 byBzZXQgdGhlIG51bWJlciBvZiByZXRyYW5zbWlzc2lvbnMgYW5kIHNwZWVkIG9mIHRoZW0NCj4g PiBpbmRlcGVuZGVudGx5IG9mIHRoZSBlbmQgb2YgdHJhbnNhY3Rpb24uIFRoZSB1c2VyIGV4cGVy aWVuY2UgY29tZXMgZmlyc3QNCj4gYW5kIHlvdSB3YW50IFNSViBmYWlsb3ZlciB0byBiZSBxdWl0 ZSBxdWljay4gTG93ZXJpbmcgdGhlIFQxIHdpbGwgZ2VuZXJhdGUNCj4gbW9yZSBvZiBhIHBhY2tl dCBzdG9ybSB3aGljaCBpbiBtYW55IGNhc2VzIGRvZXNu4oCZdCBoZWxwLg0KPiA+DQo+ID4gQW55 b25lIGZyb20gdGhhdCB0aW1lIGxvbmcgYWdvIHdoZW4gdGhpcyB3YXMgd3JpdHRlbiB0aGF0IHJl bWVtYmVycw0KPiA+IHdoeSB0aGVyZSBpcyBhIE1VU1QgaGVyZT8gIFdhcyB0aGUgTVVTVCBqdXN0 IGluZGljYXRpbmcg4oCcc3RhcnQgdGltZXIgQuKAnSBvcg0KPiB3YXMgaXQgcmVhbGx5IGEgTVVT VCBvbiA2NCpUMT8gQ291bGQgYmUgYW4gZWRpdCB0aGF0IG1hZGUgdGhpcyB0dXJuIG91dA0KPiB3 cm9uZy4uLg0KPiA+DQo+ID4gRG8gd2UgaGF2ZSBhbnkgb3RoZXIgZG9jdW1lbnRzIChvciBwYXJ0 IG9mIDMyNjEpIHRoYXQgbWFrZXMgVGltZXIgQg0KPiBjb25maWd1cmFibGU/DQo+ID4NCj4gPiBU aGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2shDQo+ID4NCj4gPiAvT2xsZQ0KPiA+DQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXBjb3Jl IG1haWxpbmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0K PiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0K From nobody Wed Oct 18 19:41:15 2017 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 748B7132397 for ; Wed, 18 Oct 2017 19:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 v7Ms79_jujDs for ; Wed, 18 Oct 2017 19:41:12 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 351DA132198 for ; Wed, 18 Oct 2017 19:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1508380872; x=1539916872; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kY5GPFBH8qFD5QxNt+cu41/HyP994N8hwrlSeKYiEDk=; b=3ahw7KlaaHHSjATRYsPDVlgDEej3gjErOjDR0W1nuNJCqif8qZpGq7q7 W/Cf94Pm6g+9hF7hNHr2UW25I4GTNsY9sbuRF4Iyw4Ugj5W8eUGGX45mK LPHwT6w7Y+F74yqgYjk7ooW7nupWy7hcGEb1Px7rTQKVya5SEgvJ0SfWB ADNQtieAmlcX53aUo39FDHN49P+SfB+l6nq1fK9FROERyjnI6Z1IdtRS3 oIbZoMC1ax2Pyas1C4Ra9RI2wLMeY1VbDGDqGO+pByRcwQr+m4qGoG1oU 0z9F/ICtqnUyhg5N/O3rIuTdKOs0cd6zZfTyNTfmq/yRQQ1Wmitvz1XBn w==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2017 04:41:10 +0200 X-IronPort-AV: E=Sophos;i="5.43,399,1503352800"; d="scan'208";a="681071610" Received: from he105824.emea1.cds.t-internal.com ([10.169.118.46]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 19 Oct 2017 04:41:10 +0200 Received: from HE105777.EMEA1.cds.t-internal.com (10.169.118.37) by HE105824.emea1.cds.t-internal.com (10.169.118.46) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 19 Oct 2017 04:41:07 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105777.EMEA1.cds.t-internal.com (10.169.118.37) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 19 Oct 2017 04:41:07 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.15) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 19 Oct 2017 04:40:59 +0200 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 19 Oct 2017 02:41:06 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Thu, 19 Oct 2017 02:41:06 +0000 From: "Jesske, Roland" To: Keith Drage , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaiXWAgACzC3CAAFsbgIAAAIZQgAAgxYCABK+7gIAKIrcg Date: Thu, 19 Oct 2017 02:41:06 +0000 Message-ID: References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <9cd95809-7388-9b8c-8070-83a1ba918b53@alum.mit.edu> <8cd70a3c-b19b-fc07-3644-cc49fef0eead@alum.mit.edu> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.196] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0483; 6:A03++2luckdvV0cSAOYfFSDhxDeSrfjf1bBEo3ZLURHu2hp/mzifhjMQQpd3TCYJVYNZxNjK7+pTHr7Smd3VKil55vgIvDO4nPfx8kO8fOJELez9IYwe8a2PuT3frna9Pu51TX8tantx+1wbuHqCZXgPNfyStoNTeNDKRWOWrT/mYdZDNZZPhxfQiUI841URBzYavVV+2uMK1VQxHn7xjn9BGXOBcxQQcfrKOI888HZavxwoRB1UjcfZHJ73WDT28KMVmRJvzDRO9xfwf/qU6O1Z4gIAPOo5wffRTz6MB8YO+dQlR1Y4YqNqG133mKFMwC2jGP7Y4FbuluY/rktMhw==; 5:Z/ZQBcCTlnGfMQcyTa2+qlDAe5vNSBvINMvzgb+PmnJmQJu0j62VOkRV03i2qE24+sKEmmne87OWe2azssCDy1AYgqvXJoN93HBcau5m4qY1kbc8cdKnk/L3ywfiB0lioBJwiPQ6sT708JwxCygXcg==; 24:juUXlJzAbPyffWLShcnSCjnKmzHwfNCsiA4hJ9DbrX8i1pKlT1TJc8XtDIVqayPjaXcmP/wf37EoIJSHIUupKTbxf+jsph0KK50zykUcJ1M=; 7:TCf2NoGJfVeRN9sElZNiAmdl2w6kvXPDk9HJI8Fd60o1SFDSbDvcQ7nKx4zcW787mIIWbUVpoSFPXUyL4wADjzzZ5E/cKfy66lEcNAqEyPi8LGoNQqBSuJF2UMM2lWVvBmMTCwG/5AaAz3qjP2d3GEW8ziF7Mztk/7gjQSimzF1R6MwQ4v0dCTtuKm4vQshe7DY1TxW7DfM2oL9lPTv2QeL1i77iTmaqYO/wkS0MgAM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a0036081-4e09-4916-f306-08d5169ad8f1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0483; x-ms-traffictypediagnostic: FRAPR01MB0483: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0483; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0483; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(24454002)(199003)(189002)(377454003)(81156014)(3660700001)(305945005)(86362001)(66066001)(75402003)(93886005)(5250100002)(2501003)(54356999)(50986999)(101416001)(2950100002)(76176999)(106356001)(105586002)(345774005)(316002)(110136005)(102836003)(6116002)(3846002)(55016002)(189998001)(68736007)(6306002)(2906002)(74482002)(72206003)(53546010)(9686003)(14454004)(8676002)(81166006)(5660300001)(478600001)(8936002)(7736002)(7696004)(97736004)(33656002)(3280700002)(966005)(53936002)(8656005)(8656005)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0483; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 02:41:06.2052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0483 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 02:41:14 -0000 VGhhbmsgeW91IGZvciB5b3VyIGRpc2N1c3Npb24uDQpZZXMgdGhpcyBpcyB0cnVlLCBsb29raW5n IGludG8gdGhlIHNjZW5hcmlvIGFnYWluIGl0IGlzIHBhc3NlZCB0aHJvdWdoIGFuIEIyQlVBLg0K QW5kIG5vdCB2aWEgYSBwcm94eS4NCg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0t LS0tDQo+IFZvbjogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gSW0g QXVmdHJhZyB2b24gS2VpdGggRHJhZ2UNCj4gR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDEyLiBPa3Rv YmVyIDIwMTcgMTc6NTINCj4gQW46IHNpcGNvcmVAaWV0Zi5vcmcNCj4gQmV0cmVmZjogUmU6IFtz aXBjb3JlXSBTZXNzaW9uIHRpbWVyIGZpeA0KPiANCj4gT24gdGhpcyBzcGVjaWZpYyBwb2ludCBJ IGFncmVlIHdpdGggUGF1bC4NCj4gDQo+IElmIHlvdSB3YW50IHRvIGRlc2NyaWJlIGEgcHJvYmxl bSBmb3IgYSBCMkJVQSB0aGVuIGRvIHNvLCBidXQgdGhlIHByb3Blcg0KPiBiZWhhdmlvdXIgZm9y IGEgcHJveHkgaXMgdG8gcGFzcyB0aGUgaW5mb3JtYXRpb24gb24sIHdoZXRoZXIgaXQgc3VwcG9y dHMgdGhlDQo+IGZlYXR1cmUsIG9yIGRvZXMgbm90IGFuZCB0aGVyZWZvcmUgZG9lcyBub3QgcmVj b2duaXNlIHRoZSBpbmZvcm1hdGlvbi4NCj4gDQo+IEluIHJlZ2FyZCB0byB0aGUgU3VwcG9ydGVk IGhlYWRlciwgdGhpcyBpcyBtZWFudCB0byBiZSBhIHN0YXRlbWVudCBhYm91dCB3aGF0DQo+IHRo ZSBvcmlnaW5hbCBnZW5lcmF0b3Igb2YgdGhlIGhlYWRlciBzdXBwb3J0cywgbm90IHNvbWUgaW50 ZXJtZWRpYXRlIGFsb25nIHRoZQ0KPiBwYXRoIChhbHRob3VnaCBJIGtub3cgU3VwcG9ydGVkIGhl YWRlciBmaWVsZHMgY2FuIGJlIGdlbmVyYXRlZCBhbG9uZyB0aGUNCj4gcGF0aCkuIFRoZXJlZm9y ZSBJIGRvIG5vdCBiZWxpZXZlIHRoZXJlIGlzIGEgY2FzZSBmb3IgYSBwcm94eSBkZWxldGluZw0K PiBpbmZvcm1hdGlvbiBmcm9tIHN1Y2ggYSBoZWFkZXIgZmllbGQuDQo+IA0KPiByZWdhcmRzDQo+ IA0KPiBLZWl0aA0KPiANCj4gT24gMDktT2N0LTE3IDU6MTcgUE0sIFBhdWwgS3l6aXZhdCB3cm90 ZToNCj4gPiBIaSBSb2xhbmQsDQo+ID4NCj4gPiBPbiAxMC85LzE3IDEwOjQxIEFNLCBKZXNza2Us IFJvbGFuZCB3cm90ZToNCj4gPg0KPiA+PiBOZXRBIGFuZCBOZXRDIGRvZXMgc3VwcG9ydCBzZXNz aW9uIHRpbWVyLg0KPiA+PiBOZXRCIGRvZXMgbm90Lg0KPiA+PiBTbyBQcm94eSAyIG5ldEIgd2ls bCBkZWxldGUgdGhlIHNlc3Npb24gdGltZXINCj4gPg0KPiA+IExldCBtZSByZXBlYXQ6IHRoaXMg aXMgbm90IHZhbGlkIGJlaGF2aW9yIGZvciBhIHByb3h5Lg0KPiA+IFRoZSBwcm9wZXIgZml4IGlz IGZvciBQcm94eSAyIHRvIGRvIHdoYXQgaXQgaXMgcmVxdWlyZWQgdG8gZG8gYnkgdGhlDQo+ID4g c3BlY3MuDQo+ID4NCj4gPiDCoMKgwqDCoFRoYW5rcywNCj4gPiDCoMKgwqDCoFBhdWwNCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g c2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPiBzaXBjb3JlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID4NCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGlu ZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXBjb3JlDQo= From nobody Wed Oct 18 22:17:19 2017 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 18854132396 for ; Wed, 18 Oct 2017 22:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 4xwqudBqYPev for ; Wed, 18 Oct 2017 22:17:14 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 CC40C132198 for ; Wed, 18 Oct 2017 22:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1508390234; x=1539926234; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=wxjnae3k0NYvyV2y1cEaonQ5WoqB6uQ5/iJUnkTXeZE=; b=MB0rwE9PEAapZtyn3qqAt+IHCQ0Tg8Tp0G99jqg/TCPI+Vc8dHZ8iSWu XgY0gN6QJhoezsVgv7psqzpeOh/WOQJpwFvbS0ag6GXNbuW0VlEMnjTGQ WjhZo2PnMcWYswl7C8ZR0YHLcMyyMWLBMtO/HipZE+JxobuOQcWPxynwB pxBazz2hIUo7GAnHobvCGBJh1lGPI1WyNA65h6s9qC/1uauaZO1p1JLNz Meara2oIrFTs5T/LBkxC7cYw83/rMIMizkZz+8qRRwEIr/ih/QMpBEAp+ a8HI1kMG9DdU+ApST6g8mVGH/kVCof3qGbuzczsvL7frHe9f9hVD7TAsz g==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2017 07:17:11 +0200 X-IronPort-AV: E=Sophos; i="5.43,400,1503352800"; d="scan'208,217"; a="51804081" Received: from he105717.emea1.cds.t-internal.com ([10.169.118.53]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 19 Oct 2017 07:17:10 +0200 Received: from HE101949.EMEA1.cds.t-internal.com (10.169.118.76) by HE105717.emea1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 19 Oct 2017 07:17:10 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101949.EMEA1.cds.t-internal.com (10.169.118.76) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 19 Oct 2017 07:17:10 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.24) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 19 Oct 2017 07:17:02 +0200 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0482.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 19 Oct 2017 05:17:09 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Thu, 19 Oct 2017 05:17:09 +0000 From: "Jesske, Roland" To: Ivo Sedlacek , "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-holmberg-sipcore-sip-push Thread-Index: AQHTQ4IPoxTk0kRdlESa3BdZ+M6wHqLhYuGAgAABF4CAAHXEgIAGABMAgALSKuA= Date: Thu, 19 Oct 2017 05:17:09 +0000 Message-ID: References: , <0849339E-63E3-499C-A17A-58D80D3AA1C6@att.com> <734_1507905271_59E0CEF7_734_44_1_8B970F90C584EA4E97D5BAAC9172DBB81D62895F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.196] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:7rphw3rKolSI7BHO0H3sLB9FhRKVn07DMi7TzAzy9n3Jwq+J8JEp9d6qwiHcAxJ7V2YhkVxi4DgGgp2ennghfdENg9K9opDQukpmlxlX/V+47CV41BfVIYyE+1T88ecDhXeu5VWbuvSQWOf29QTAgMsOEb2EJBtHxu6VMLEZ/FieQ+6gZKjj5ZW407SlX7O/hBOEsx2vY3PiTKD68Kdv0T79uzSKerXWztb4VVWhFA2lXDZ+2+1eSb81peGqltyySuiihAAh/ZB9h9Y4d1lI4bd9idLfSdZIf1agIdi/gKizG9Wy4A30wsFnZLmOGnoq45oauMeSXbzTRVouDYjBDw==; 5:P0o7xQ73Rb8kYUZSVmMkdoQAXsaLw7a/F5SJxyi3N/cwGB/5yxxDZB+UVO1/Ti9PekSsmtlX1Q6ZHP48gXf/5yaPOfSzEaUB7isPLIMB5bFU3A8jzf5htUtmF00PryZ2W0N3FKZUt6wBrL5Hh4mlIA==; 24:pMRXUgoxHfXD5KilNVdETN6tVFgeWzFlRQCHensBVBue2Z/WfqWeen+ySPt7SDYby/6KdWJ3ttOBqkQO0w1a2ukhdPvyo8GvaaxbA5Vi4xI=; 7:3wVLlSKwJmAWS05dNhYkQxw9tspQlOFrYJ2L81zGraw9/MvLYA07JEXYe60AfFxu3Wr9dbkD2MAM7K+hYrU9hqfSgUG22EQ8ryJ1iSery+IK1f7GnVt8BQC7mu6TeqYtGy5mOiaRqlsNBPAJDrLBiwv20Di7WHkIDYqddwBBZfaciSXfrwV7ZAnvMaSd2uY+Fh7wG7ecT33J42vfbwYQ4s7zTv7z0PZ4mgLIw+ftdGI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4aba4980-c840-4f8d-70c1-08d516b0a5e9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: x-exchange-antispam-report-test: UriScan:(10436049006162)(97927398514766)(18271650672692)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0482; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0482; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(377454003)(199003)(13464003)(189002)(252514010)(24454002)(33656002)(8676002)(106356001)(3660700001)(68736007)(478600001)(230783001)(14454004)(110136005)(81166006)(2906002)(75402003)(74482002)(54356999)(101416001)(50986999)(316002)(55016002)(81156014)(76176999)(97736004)(3280700002)(5660300001)(105586002)(6116002)(72206003)(575784001)(2201001)(966005)(3846002)(102836003)(7736002)(54896002)(66066001)(790700001)(5890100001)(6306002)(8936002)(9686003)(325944009)(236005)(5250100002)(2950100002)(189998001)(2501003)(93886005)(53546010)(606006)(7696004)(53936002)(86362001)(2900100001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0482; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB04838092092DA51308C285BBF9420FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 05:17:09.5450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0482 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 05:17:18 -0000 --_000_FRAPR01MB04838092092DA51308C285BBF9420FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Ivo Sedlacek Gesendet: Dienstag, 17. Oktober 2017 12:12 An: marianne.mohali@orange.com; sipcore@ietf.org Betreff: Re: [sipcore] draft-holmberg-sipcore-sip-push Hello, > Chairs would like to know if we should work on this. I support sipcore working on this draft. Kind regards Ivo From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of marianne.mohal= i@orange.com Sent: Friday, October 13, 2017 4:34 PM To: sipcore@ietf.org Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push +1 Marianne De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de DOLLY, MARTIN = C Envoy=E9 : vendredi 13 octobre 2017 09:33 =C0 : VAN GEEL Jan (SPC/CSP) Cc : sipcore@ietf.org Objet : Re: [sipcore] draft-holmberg-sipcore-sip-push I support as well Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 13, 2017, at 3:29 AM, VAN GEEL Jan (SPC/CSP) > wrote: I support this work Kind regards -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday 12 October 2017 19:46 To: sipcore@ietf.org Subject: [sipcore] draft-holmberg-sipcore-sip-push Chairs would like to know if we should work on this. Right at the moment, = we're not having a formal request to adopt. This is just a question of whe= ther work group members think this is a good thing to do, as well as fit in= our charter. We can also have a discussion on it in Singapore. Brian _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DiQg4x3W2NlXFwJU= F9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D ________________________________ ***** Disclaimer ***** https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.proximus.be_maild= isclaimer&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&= m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DEWP_Ve3ez3PwmmUVZ35E8ih= tlOIICsVWm8tzNU9vM1M&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DiQg4x3W2NlXFwJU= F9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_FRAPR01MB04838092092DA51308C285BBF9420FRAPR01MB0483DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1=

&nbs= p;

Von: sipcore [mailto:sipcore-bounces= @ietf.org] Im Auftrag von Ivo Sedlacek
Gesendet: Dienstag, 17. Oktober 2017 12:12
An: marianne.mohali@orange.com; sipcore@ietf.org
Betreff: Re: [sipcore] draft-holmberg-sipcore-sip-push

 

Hello,

 

> Chairs would like to know if we should work on thi= s.

 

I support sipcore working on this draft.=

 

Kind regards

 

Ivo

 

From: = sipcore [mailto:sipcore-bounces= @ietf.org] On Behalf Of marianne.= mohali@orange.com
Sent: Friday, October 13, 2017 4:34 PM
To: sipcore@ietf.org
Subject: Re: [sipcore] draft-holmberg-sipcore-sip-push

 

+1

 

Marianne

 

De : sipc= ore [mailto:sipcore-bounces@iet= f.org] De la part de DOLLY, MARTIN C
Envoy=E9 : vendredi 13 octobre 2017 09:33
=C0 : VAN GEEL Jan (SPC/CSP)
Cc : sipcore@ietf.org Objet : Re: [sipcore] draft-holmberg-sipcore-sip-push

 

I support as well

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com

On Oct 13, 2017, at 3:29 AM, VAN GEEL Jan (SPC/CSP) <jan.van.geel@proximus.com> wrote:

I support this work

Kind regards

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday 12 October 2017 19:46
To: sipcore@ietf.org
Subject: [sipcore] draft-holmberg-sipcore-sip-push

Chairs would like to know if we should work on this.  Right at the mom= ent, we’re not having a formal request to adopt.  This is just a= question of whether work group members think this is a good thing to do, a= s well as fit in our charter.

We can also have a discussion on it in Singapore.

Brian
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3D= iQg4x3W2NlXFwJUF9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D

________________________________

***** Disclaimer *****
https://urlde= fense.proofpoint.com/v2/url?u=3Dhttp-3A__www.proximus.be_maildisclaimer&= ;d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&a= mp;m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3DEWP_Ve3ez3PwmmUV= Z35E8ihtlOIICsVWm8tzNU9vM1M&e=3D
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DH2XfFeHUr0pDctooFb3H-9VMvetMaz1R3avY6lD5wxM&s=3D= iQg4x3W2NlXFwJUF9Sm2iWQ3S1Ks-7-pkYeOE8fXUB0&e=3D 

____________________________________________________=
_____________________________________________________________________
 

Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
span lang=3D"CS">


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
span lang=3D"CS">


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.=



 

This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.


Thank you.
--_000_FRAPR01MB04838092092DA51308C285BBF9420FRAPR01MB0483DEUP_-- From nobody Fri Oct 20 11:21:17 2017 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 94BDE1342FC for ; Fri, 20 Oct 2017 11:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr_EK3WFNa3l for ; Fri, 20 Oct 2017 11:21:14 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EE313234B for ; Fri, 20 Oct 2017 11:21:14 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l32so7120299ywh.13 for ; Fri, 20 Oct 2017 11:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=pngU7QF04nkFaiRi8Lx4q9cI/8puPnvwPY5KyeCSYag=; b=KEadScfMMooqOWHTtRDrgDcTn+slGbOUyIuxX+X+VLQYq5GngOt8XRLoDVbZrFvhWH cjV/st/fAZQ3p04r0jEXPttIacLHwlpht8557wVX1UlhLSmkApNSxgfh3/Qkomj7CC61 5ZaePJz8XB2HJALihO+HhY5UPIq3I10y/qFAiuFIy5LPU7QRDeyL2XDpz1NyZ3pySZOA 96zJzSO4AO0vbZquMpEa4MaH6iLBSzFO8mWDK/pdNjAlEOgClA1l6eLZevAx68HRNof0 DRsjjqnWqQ4Cba5hRZj7zG8AIHNOmLRqCBFjnQ22u6G9yJNsQ+xb4qwBCfPZLyEcKtIW 0CuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=pngU7QF04nkFaiRi8Lx4q9cI/8puPnvwPY5KyeCSYag=; b=qIEaUkYIlCrfpykJU70W8lvgokUWccl63WaTLuy9GVAV9A7+ZaUS7eDVAs8ye1xM+Y CXxiopwkWt8CmpA/1WvJz3Bu6dqUpe3xpjw2IknQxHR/5iCgBpnnWwq7ibrDGJOl47LT c6cGZBN4fybr+/VIJXxI+kR60AZEGhMxqrzbVu3nk9oUkJgQt9hmSXSw5G3ojw4gOnhQ 1vt2/OMPTkY2qvDXRIu4BYJNeiRY9gVNXxEbZGBJLEVuAs4AZ6Yayw1r8Cg/ZKLSw9TZ R++beNYz/1lQ8vzJXgemiocrkqD9zqE1FJvXyF9Y9t6tNlUg1x2kFoGy8MR6TFOcK3fa HlwA== X-Gm-Message-State: AMCzsaWdLmcIdk5ZRwO04jDOY07FfMdtK58ECQiMt8yozB1mX9D2FLqI eFnbzLbgy2s6l5w8xR3Lv23w4pQjcsM= X-Google-Smtp-Source: ABhQp+QcXXo1Up5zFw76gpNu+2ZUovppPd5CPvgHzLmbJYZzn5iqgpNbRlUkkNaKoLSvhP21GQS+yw== X-Received: by 10.13.255.199 with SMTP id p190mr4004271ywf.180.1508523673286; Fri, 20 Oct 2017 11:21:13 -0700 (PDT) Received: from [10.96.10.21] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id d140sm584303ywh.54.2017.10.20.11.21.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 11:21:12 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <3D79AD45-1508-42D2-802F-C2BC49F79AFA@brianrosen.net> Date: Fri, 20 Oct 2017 11:21:10 -0700 To: sipcore@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sipcore] Agenda Items for IETF 100 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:21:15 -0000 We have scheduled a short meeting slot (1 hour). Chairs will prioritize = agenda requests to drafts receiving list discussion, but we would really = like to get some of our older work items finished. If you want agenda = time, please let us know soon. Brian= From nobody Fri Oct 20 17:28:38 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE79134511; Fri, 20 Oct 2017 17:24:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ben@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546317.20809.16580768028338215378.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:23 -0700 Archived-At: Subject: [sipcore] sipcore - Requested session has been scheduled for IETF 100 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:23 -0000 Dear Brian Rosen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sipcore Session 1 (1:00:00) Monday, Afternoon Session III 1740-1840 Room Name: Olivia size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Brian Rosen Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: stir perc dispatch rtcweb ice modern mmusic Second Priority: fud oauth netvc Third Priority: acme avtcore sipbrandy People who must be present: Ben Campbell Brian Rosen Jean Mahoney Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Oct 22 04:25:25 2017 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 D4051138344 for ; Sun, 22 Oct 2017 04:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 867Yf9ywOw0G for ; Sun, 22 Oct 2017 04:25:21 -0700 (PDT) Received: from know-smtprelay-omc-1.server.virginmedia.net (know-smtprelay-omc-1.server.virginmedia.net [80.0.253.65]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34770138342 for ; Sun, 22 Oct 2017 04:25:20 -0700 (PDT) Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-1-imp with bizsmtp id QbRH1w0043hDt9d01bRJFL; Sun, 22 Oct 2017 12:25:18 +0100 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.1 cv=NqQsCJpJ c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=48vgC7mUAAAA:8 a=siVFFLLkP3kKaLmQ1V4A:9 a=qrdn-JgqMbuV2DB9:21 a=Zt2HREjY-Zqg6zUE:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 To: "Jesske, Roland" , "sipcore@ietf.org" References: <70F63F58-40A5-4337-95EA-01B36260FD05@edvina.net> <22017c1f-9639-9b5a-4a74-ef6a3335ec07@ntlworld.com> From: Keith Drage Message-ID: <00ae0436-6110-1195-2e56-98279b45b367@ntlworld.com> Date: Sun, 22 Oct 2017 12:25:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1508671518; bh=xg2vBJ5ns0abf1Cb6+gCUK8egSnONXL1tMulRR9QFOQ=; h=Subject:To:References:From:Date:In-Reply-To; b=pxw6UjaBWpEkgjnBIr9f7ySj5uOvJPlE9C1HNcEf44PrjWalOZcJAkDycn8Tn8sKs FhEwqbN6Lht1ATxT1mgLuSPJzVZNB7ApwTLtCzUUbv8iHCpipHHVJY6pCcSUsQ9Qeg iSwRikxR6lBeLZKkgKBd4/8EbuhH0qVQrmUleRgFR8wSDvxiUoyJWW/FqbRy9fmha3 0qoZDXwtpJGgLjB2MRSh0Qie2cu35DPyo7qRzc73aghrxa+G9slkrv4WKxFjWB0m3g ZI/SnzJuUPfvqVSY+lbTFaqPn7YR0yigmuApvMooHumMAXOsAD8+KCpmRu27et7BN1 OebXH+Vf5Ak4g== Archived-At: Subject: Re: [sipcore] SIP timer B in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 11:25:25 -0000 I am not sure this answers the point of the original poster, and in many ways, just reinforces my argument that these are protocol protection timers. What the application does over the top is entirely up to the application, and should not directly interfere with these timers, because underlying these timers are the physical characteristics of the link itself. However, in the same way as if a human user decides that setting up a call is taking too long and manually clears it down, there is nothing to stop the application using SIP from running a timer to do the same thing. Keith On 19-Oct-17 3:37 AM, Jesske, Roland wrote: > Hi Keith, > You can "configure" Timer B. But you can do it only via T1, since T1 may be choose it shorter (not recommended) or longer as defined in section > 17.1.1.2 Formal Description > The default value for T1 is 500 ms. T1 is an estimate of the RTT > between the client and server transactions. Elements MAY (though it > is NOT RECOMMENDED) use smaller values of T1 within closed, private > networks that do not permit general Internet connection. T1 MAY be > chosen larger, and this is RECOMMENDED if it is known in advance > (such as on high latency access links) that the RTT is larger. > Whatever the value of T1, the exponential backoffs on retransmissions > described in this section MUST be used. > > But keep in mind if you change T1 then you change all T1 dependent timers. > > Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Keith Drage >> Gesendet: Dienstag, 17. Oktober 2017 23:59 >> An: sipcore@ietf.org >> Betreff: Re: [sipcore] SIP timer B in RFC 3261 >> >> I don't go back far enough to have the history of this - it is well over >> 17 years ago, but: >> >> My perspective has always been that these timers are the protocol >> protection timers, i.e. those that prevent the protocol getting locked up and >> the protocol disappearing into a state that it cannot get out of, particularly >> when it is running over UDP where it also needs to provide a mechanism for >> giving some reliability to messages. >> >> There is nothing to stop the user implementing timers at an application level >> that are shorter than this, and running in parallel to the protocol level timers, >> and then using the cancellation mechanisms as appropriate within the >> protocol to clear the protocol. Those timers could depend on the needs of >> the application, and the needs of human user interaction, therefore >> applications supporting a voice call might take a different approach to one >> running MSRP. >> >> Therefore timer B is not shorter in this viewpoint, merely never expires >> because something else at the application layer gets there first. >> >> I would add that anyone designing an application with such shorter timers >> needs to ensure that they are not creating a mechanism for a denial of >> service attack using this application. >> >> regards >> >> Keith >> >> >> >> On 17-Oct-17 8:07 AM, Olle E. Johansson wrote: >>> Hi! >>> >>> Section 17.1.1.2 of 3261 says: >>> "For any transport, the client transaction MUST start timer B with a value >>> of 64*T1 seconds (Timer B controls transaction timeouts).” >>> >>> This MUST surprised me when someone pointed at it recently. For a very >>> long time, almost all SIP implementations has a user-configurable >>> setting for Timer B, so there must be a reason why this MUST is ignored. >> Many web pages found with my friends at G talk about a default setting >> being 64*T1, but the RFC is quite clear that it’s not something one should not >> modify. >>> In my experience there are plenty of situations where you want to >>> modify T1 to set the number of retransmissions and speed of them >>> independently of the end of transaction. The user experience comes first >> and you want SRV failover to be quite quick. Lowering the T1 will generate >> more of a packet storm which in many cases doesn’t help. >>> Anyone from that time long ago when this was written that remembers >>> why there is a MUST here? Was the MUST just indicating “start timer B” or >> was it really a MUST on 64*T1? Could be an edit that made this turn out >> wrong... >>> Do we have any other documents (or part of 3261) that makes Timer B >> configurable? >>> Thank you for your feedback! >>> >>> /Olle >>> >>> _______________________________________________ >>> 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 Oct 24 02:25:25 2017 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 3C14B13D4D3 for ; Tue, 24 Oct 2017 02:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 fG9alNlaqnUB for ; Tue, 24 Oct 2017 02:25:21 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 2799413D0FA for ; Tue, 24 Oct 2017 02:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1508837121; x=1540373121; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EghclgBGSlAe20p/7p3EqtKiRd6bmipxv6QYw9jr5DY=; b=M8640FIgsnNIsL1g1NR1NZ4RHQNLdLPICs2PeGeB+EFpKdxUZn/rKEJ4 +uMrI9p4Llf7TPtKPk0rYe7qTkS/xVhp8Sal5FtYmXBC5XzhRvOg5jG4N rXhioLHQ1fcoKjMT3uULFT6gdIKGd946Da0enD0TwUjY5LS6zxXBXP3SM cIcPpWDK49LVgLSUI/z3ED4pMjuTm4Ngwa8FQUhIb8UGhEYwXOlajUJ5U IHvxyAYXKTQw42kBNSu+aEivvYcQ1q1UHCo4rRwjOtDduvOLe/60AgRwq KOOKeg/EDKOQtDjV6eoGefbSTsPMORuji6ZERUTZ5ZKf9ROKo5ifRzs2o w==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 11:25:18 +0200 X-IronPort-AV: E=Sophos;i="5.43,427,1503352800"; d="scan'208";a="1409913505" Received: from he101941.emea1.cds.t-internal.com ([10.169.119.81]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 24 Oct 2017 11:25:17 +0200 Received: from HE106144.EMEA1.cds.t-internal.com (10.169.119.78) by HE101941.emea1.cds.t-internal.com (10.169.119.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 24 Oct 2017 11:25:17 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE106144.EMEA1.cds.t-internal.com (10.169.119.78) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 24 Oct 2017 11:25:17 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.18) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 24 Oct 2017 11:24:44 +0200 Received: from LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.14) by LEXPR01MB0496.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 24 Oct 2017 09:25:16 +0000 Received: from LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE ([fe80::605e:e45f:65a5:d5db]) by LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE ([fe80::605e:e45f:65a5:d5db%14]) with mapi id 15.20.0077.023; Tue, 24 Oct 2017 09:25:16 +0000 From: "Jesske, Roland" To: "sipcore@ietf.org" Thread-Topic: New Version Notification for draft-winterbottom-sipcore-locparam-02.txt Thread-Index: AQHTSIyCShmGYDH9NU+jyalmJJwJvqLywkmQ Date: Tue, 24 Oct 2017 09:25:16 +0000 Message-ID: References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> In-Reply-To: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.96] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LEXPR01MB0496; 6:2Qh3VV/47kudUAPI++I/n1efrr0i+kvcy+NuoggP1/9yvvQzjWATGqsQLD6/hSDt4YqVxXs1Sio1d7vz9ejhXmgZk0Vxpoi2D6GXF9DGvZJlCUvAY9juR0jcKNE5Rvd3G9z4L2D2ugdtJGYktsppprUeamRyWZrfIshtKIOjyig7KdXqgt12ZWNYQG84ueSvnxzLjhRgH2WA8Kqm9KAO2RQxA6lzJaxvIHXin9YVKqsni2In+908r77s4cZylE0B/OcVvaMwAi/KesUjB1vqjXwtX5gUNV+Esg7wfmX9iE2nq9Fp64Oc0VSz50sIrBMaix2DO8LWvkb+HUvaat2+Qw==; 5:JjQsONFj6Sfkg4Sbmn7F6XystSv2mpBpx9LyxkucpGUWDzSRy9jMXWav+ff/Kam0RF883kutzkfGThgKNeKRUuT14H4EDtdfd6Nwj2LDrZL4g4dBVTrEXP760NyfwIPEkzs+53pc4RHBmoKUUT/VPGQbMQw/9J/FJ5hQFWj/nqM=; 24:HxMdlq6asMP3DCeCih4M0lX1TZPylws4P3C3hlUyTTXEbs/Oyk8opJK1ej1Z8TMfQn9SVBDLIqMJsuGAu1mkYKwdagxsdDRR2RakwNxUT2k=; 7:Fdx0x7N7uEMyD8o/hvGCGQUS1kqBqcitlClrS+wQgbCFzfC+0LEDDLxKkMpVUNyU1knrlL2NNnJVQXlHAOFWMozmYw1gJUtyHWaP4lLAxmAUsRjMXBeTqmHW3lZhyfSM2AI1KtKlG/ahks1w//dL71H/BZkB0fjJmRErjYqXtdL53OtkpFyfxyxZ4kHsrlSZJdoM5qVwC7nLq6C6DhytkrLrw//Ldp3MsivU2CH4+TY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f4c752d8-b110-44a1-1fc1-08d51ac1235e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:LEXPR01MB0496; x-ms-traffictypediagnostic: LEXPR01MB0496: x-exchange-antispam-report-test: UriScan:(120809045254105)(187470562142495)(18271650672692); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231020)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LEXPR01MB0496; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LEXPR01MB0496; x-forefront-prvs: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(377424004)(199003)(2351001)(81166006)(6916009)(55016002)(2950100002)(8936002)(413944005)(6306002)(8676002)(1730700003)(81156014)(66066001)(86362001)(14454004)(316002)(7696004)(53936002)(9686003)(72206003)(68736007)(966005)(15650500001)(101416001)(33656002)(74482002)(7736002)(3660700001)(478600001)(76176999)(54356999)(105586002)(4001150100001)(305945005)(5250100002)(106356001)(2501003)(5660300001)(3846002)(189998001)(2900100001)(50986999)(2906002)(102836003)(230783001)(6116002)(75402003)(3280700002)(5640700003)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0496; H:LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2017 09:25:16.5924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0496 X-OriginatorOrg: telekom.de Archived-At: Subject: [sipcore] WG: New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 09:25:24 -0000 RGVhciBhbGwsDQpsYXN0IHdlZWsgSSBoYXZlIHVwZGF0ZWQgZHJhZnQtd2ludGVyYm90dG9tLXNp cGNvcmUtbG9jcGFyYW0gZHVlIHRvIHRoZSBkaXNjdXNzaW9ucyBtYWRlLg0KU28gYWxsIGNvbW1l bnRzIG1hZGUgYXJlIG5vdyByZWZsZWN0ZWQuDQpJIGRpZCBzb21lIGltcHJvdmVtZW50IG9mIHRo ZSB0ZXh0IHdpdGggcmVnYXJkIHRvIHRoZSB1c2Ugb2YgdGhlIGxvY3BhcmFtIHdpdGhpbiB0aGUg dHJ1c3RlZCBkb21haW4uDQpUaGlzIHJlZmxlY3RzIHRoZSB1c2UgdG8gYmUgaW50ZW5kZWQgd2l0 aGluIGEgdHJ1c3QgZG9tYWluLg0KDQpUaGFuayB5b3UgYW5kIEJlc3QgUmVnYXJkcw0KDQpSb2xh bmQgDQoNCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCkdlc2Vu ZGV0OiBEb25uZXJzdGFnLCAxOS4gT2t0b2JlciAyMDE3IDA1OjQ0DQpBbjogQW5kcmV3IEh1dHRv biA8YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20+OyBKZXNza2UsIFJvbGFuZCA8Ui5KZXNza2VAdGVs ZWtvbS5kZT47IEphbWVzIFdpbnRlcmJvdHRvbSA8YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwu Y29tPjsgQnJ1bm8gQ2hhdHJhcyA8YnJ1bm8uY2hhdHJhc0BvcmFuZ2UuY29tPg0KQmV0cmVmZjog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13aW50ZXJib3R0b20tc2lwY29yZS1s b2NwYXJhbS0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2ludGVyYm90 dG9tLXNpcGNvcmUtbG9jcGFyYW0tMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFJvbGFuZCBKZXNza2UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtbG9jcGFyYW0NClJldmlzaW9uOgkw Mg0KVGl0bGU6CQlMb2NhdGlvbiBTb3VyY2UgUGFyYW1ldGVyIGZvciB0aGUgU0lQIEdlb2xvY2F0 aW9uIEhlYWRlciBGaWVsZA0KRG9jdW1lbnQgZGF0ZToJMjAxNy0xMC0xOA0KR3JvdXA6CQlJbmRp dmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13aW50ZXJib3R0b20tc2lwY29yZS1sb2Nw YXJhbS0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC13aW50ZXJib3R0b20tc2lwY29yZS1sb2NwYXJhbS8NCkh0bWxpemVkOiAgICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2ludGVyYm90dG9tLXNpcGNvcmUt bG9jcGFyYW0tMDINCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LXdpbnRlcmJvdHRvbS1zaXBjb3JlLWxvY3BhcmFtLTAyDQpEaWZmOiAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXdpbnRlcmJv dHRvbS1zaXBjb3JlLWxvY3BhcmFtLTAyDQoNCkFic3RyYWN0Og0KICAgVGhlcmUgYXJlIHNvbWUg Y2lyY3Vtc3RhbmNlcyB3aGVyZSBhIGdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZCBtYXkNCiAgIGNv bnRhaW4gbW9yZSB0aGFuIG9uZSBsb2NhdGlvbiB2YWx1ZS4gIEtub3dpbmcgdGhlIGlkZW50aXR5 IG9mIHRoZQ0KICAgbm9kZSBhZGRpbmcgdGhlIGxvY2F0aW9uIHZhbHVlIGFsbG93cyB0aGUgcmVj aXBpZW50IG1vcmUgZnJlZWRvbSBpbg0KICAgc2VsZWN0aW5nIHRoZSB2YWx1ZSB0byBsb29rIGF0 IGZpcnN0IHJhdGhlciB0aGFuIHJlbHlpbmcgc29sZWx5IG9uDQogICB0aGUgb3JkZXIgb2YgdGhl IGxvY2F0aW9uIHZhbHVlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Oct 25 17:22:29 2017 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 2832E13F4F1; Wed, 25 Oct 2017 17:22:22 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-SSArORY4Hg; Wed, 25 Oct 2017 17:22:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EAB13968C; Wed, 25 Oct 2017 17:22:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DF193B80DE1; Wed, 25 Oct 2017 17:22:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sipcore@ietf.org Message-Id: <20171026002216.DF193B80DE1@rfc-editor.org> Date: Wed, 25 Oct 2017 17:22:16 -0700 (PDT) Archived-At: Subject: [sipcore] RFC 8262 on Content-ID Header Field in the Session Initiation Protocol (SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 00:22:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8262 Title: Content-ID Header Field in the Session Initiation Protocol (SIP) Author: C. Holmberg, I. Sedlacek Status: Standards Track Stream: IETF Date: October 2017 Mailbox: christer.holmberg@ericsson.com, ivo.sedlacek@ericsson.com Pages: 14 Characters: 26427 Updates: RFC 5621, RFC 5368, RFC 6442 I-D Tag: draft-ietf-sipcore-content-id-10.txt URL: https://www.rfc-editor.org/info/rfc8262 DOI: 10.17487/RFC8262 This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). This document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Oct 26 03:25:16 2017 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 234CB13F54D for ; Thu, 26 Oct 2017 03:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5sXiS8ABrQk for ; Thu, 26 Oct 2017 03:25:13 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D72413F54C for ; Thu, 26 Oct 2017 03:25:13 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id DAE83C0974; Thu, 26 Oct 2017 12:25:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id C0FB94005C; Thu, 26 Oct 2017 12:25:11 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Thu, 26 Oct 2017 12:25:11 +0200 From: To: "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: New Version Notification for draft-winterbottom-sipcore-locparam-02.txt Thread-Index: AQHTSIyCShmGYDH9NU+jyalmJJwJvqLywkmQgAM1jWA= Date: Thu, 26 Oct 2017 10:25:10 +0000 Message-ID: <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 10:25:15 -0000 V2hhdCBhcmUgdGhlIG5leHQgc3RlcHMgdG8gZ2V0IHRoaXMgZG9jdW1lbnQgYXBwcm92ZWQgYXMg YW4gUkZDPyBJcyB0aGVyZSBhbnl0aGluZyBtaXNzaW5nPyBPbiB0aGUgRVRTSSBzaWRlIHdlIGRv IG5lZWQgdG8gcmVmZXJlbmNlIHRoaXMgZG9jdW1lbnQgZnJvbSBhbiBFVFNJIHN0YW5kYXJkIHRo YXQgd2lsbCBiZSBwdWJsaXNoZWQgdmVyeSBzb29uLg0KQnJ1bm8NCi0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KRGXCoDogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBKZXNza2UsIFJvbGFuZA0KRW52b3nDqcKgOiBtYXJkaSAyNCBvY3Rv YnJlIDIwMTcgMTE6MjUNCsOAwqA6IHNpcGNvcmVAaWV0Zi5vcmcNCk9iamV0wqA6IFtzaXBjb3Jl XSBXRzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13aW50ZXJib3R0b20tc2lw Y29yZS1sb2NwYXJhbS0wMi50eHQNCg0KRGVhciBhbGwsDQpsYXN0IHdlZWsgSSBoYXZlIHVwZGF0 ZWQgZHJhZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtbG9jcGFyYW0gZHVlIHRvIHRoZSBkaXNjdXNz aW9ucyBtYWRlLg0KU28gYWxsIGNvbW1lbnRzIG1hZGUgYXJlIG5vdyByZWZsZWN0ZWQuDQpJIGRp ZCBzb21lIGltcHJvdmVtZW50IG9mIHRoZSB0ZXh0IHdpdGggcmVnYXJkIHRvIHRoZSB1c2Ugb2Yg dGhlIGxvY3BhcmFtIHdpdGhpbiB0aGUgdHJ1c3RlZCBkb21haW4uDQpUaGlzIHJlZmxlY3RzIHRo ZSB1c2UgdG8gYmUgaW50ZW5kZWQgd2l0aGluIGEgdHJ1c3QgZG9tYWluLg0KDQpUaGFuayB5b3Ug YW5kIEJlc3QgUmVnYXJkcw0KDQpSb2xhbmQgDQoNCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJp Y2h0LS0tLS0NClZvbjogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANCkdlc2VuZGV0OiBEb25uZXJzdGFnLCAxOS4gT2t0b2JlciAyMDE3 IDA1OjQ0DQpBbjogQW5kcmV3IEh1dHRvbiA8YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20+OyBKZXNz a2UsIFJvbGFuZCA8Ui5KZXNza2VAdGVsZWtvbS5kZT47IEphbWVzIFdpbnRlcmJvdHRvbSA8YS5q YW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPjsgQnJ1bm8gQ2hhdHJhcyA8YnJ1bm8uY2hhdHJh c0BvcmFuZ2UuY29tPg0KQmV0cmVmZjogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC13aW50ZXJib3R0b20tc2lwY29yZS1sb2NwYXJhbS0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtbG9jcGFyYW0tMDIudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJvbGFuZCBKZXNza2UgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtd2ludGVyYm90dG9tLXNpcGNv cmUtbG9jcGFyYW0NClJldmlzaW9uOgkwMg0KVGl0bGU6CQlMb2NhdGlvbiBTb3VyY2UgUGFyYW1l dGVyIGZvciB0aGUgU0lQIEdlb2xvY2F0aW9uIEhlYWRlciBGaWVsZA0KRG9jdW1lbnQgZGF0ZToJ MjAxNy0xMC0xOA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOA0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13 aW50ZXJib3R0b20tc2lwY29yZS1sb2NwYXJhbS0wMi50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW50ZXJib3R0b20tc2lwY29yZS1s b2NwYXJhbS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtbG9jcGFyYW0tMDINCkh0bWxpemVkOiAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdpbnRlcmJvdHRvbS1zaXBj b3JlLWxvY3BhcmFtLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXdpbnRlcmJvdHRvbS1zaXBjb3JlLWxvY3BhcmFtLTAyDQoNCkFic3Ry YWN0Og0KICAgVGhlcmUgYXJlIHNvbWUgY2lyY3Vtc3RhbmNlcyB3aGVyZSBhIGdlb2xvY2F0aW9u IGhlYWRlciBmaWVsZCBtYXkNCiAgIGNvbnRhaW4gbW9yZSB0aGFuIG9uZSBsb2NhdGlvbiB2YWx1 ZS4gIEtub3dpbmcgdGhlIGlkZW50aXR5IG9mIHRoZQ0KICAgbm9kZSBhZGRpbmcgdGhlIGxvY2F0 aW9uIHZhbHVlIGFsbG93cyB0aGUgcmVjaXBpZW50IG1vcmUgZnJlZWRvbSBpbg0KICAgc2VsZWN0 aW5nIHRoZSB2YWx1ZSB0byBsb29rIGF0IGZpcnN0IHJhdGhlciB0aGFuIHJlbHlpbmcgc29sZWx5 IG9uDQogICB0aGUgb3JkZXIgb2YgdGhlIGxvY2F0aW9uIHZhbHVlcy4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMK cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5r IHlvdS4KCg== From nobody Thu Oct 26 06:01:15 2017 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 4F6A81394FB for ; Thu, 26 Oct 2017 06:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCoaXDMrGucK for ; Thu, 26 Oct 2017 06:01:12 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAAD213F581 for ; Thu, 26 Oct 2017 06:01:09 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id n137so5154490iod.6 for ; Thu, 26 Oct 2017 06:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vQvbHKzpOiKpCBwZPu7kjicHdJNkk7iruv6hoGLr/2A=; b=D83oKVxkHxswWs3a2K+7KwRoUysDbosTjdhjnPbatwZPn+FnGMwE/+lLVaujbPo87z y6hzQPCh68eyAbb4PXeFM4sU6vuanPWbu8BeXYJhOf94i42an33IHUE6qqcwJA5DWIvJ fpCG6te+XP1+D66NhDpPhhHdXtmI/K843trxYS0beV5+vs8HShcVwM6llZrbtm8/XBLe p57sxOs7n1DVPK3Ea2IAOrvFAwVlNP37XmHAR5KpRPCntDD8XjxPkUJnUlocoyg3bqqO LyDgEGYCiGrgmWRQlldQmUicpcv7TT+fBRg2YrUp78TuTffx9hUcvulp4W9fpnPoRunP ucVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vQvbHKzpOiKpCBwZPu7kjicHdJNkk7iruv6hoGLr/2A=; b=gkV/z9yY36LwYgDkqB6MaY8MHUuFceDKDjtPr8GqToGpbh8EHvw3zQeDYHMA8h+k7p YJ+FfgqgiyeoCNf3FYrCoPpNZX4g/umNJH5FHOTiR425A9VzwHLQDBM8i3/JTOr+81AH ybRBqlc93jDalBDv0m6zKKC7fvoV4WCfe2gsK4WQUEwBqQPNyjKMqHkOFP+20SuDzArR gj7jqYqP9g6vPHhnj0nvp65HWyGOziPK1Srq2ob7PbowxxLAjGtbLz8XwZpalXa+Q7Fj IO5uK/AeKuyNgqPJRfsIJbvths4mmaP8ohvqXsLtzv29Ae5U0xZBAm3m3bwESafGegnQ QR8w== X-Gm-Message-State: AMCzsaWof7PrPzJIpACM1Ys38tEG2HfrTFJz8aunDGq44xMsD4YTWKcf bPSBdkXmhSUjJZFEVfyZ9lV4vw== X-Google-Smtp-Source: ABhQp+SNhDi8PyY+QlCvV7cB+LO9G3lEoqfKQcivvmBT1XhB9HuIzVQTpbBLZ8pe5YPlS+QPMrmZFg== X-Received: by 10.36.118.81 with SMTP id z78mr2254776itb.97.1509022868796; Thu, 26 Oct 2017 06:01:08 -0700 (PDT) Received: from [10.33.193.2] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id r124sm700737ita.13.2017.10.26.06.01.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 06:01:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Thu, 26 Oct 2017 09:01:05 -0400 Cc: "Jesske, Roland" , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> To: bruno.chatras@orange.com X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:01:14 -0000 We need reviews: we need people to carefully look at the document and = send comments (if they have any). If the previous commenters signal their concerns are addressed, chairs = will issue a working group last call soon, but getting reviews is = critical to getting the document approved. Brian > On Oct 26, 2017, at 6:25 AM, bruno.chatras@orange.com wrote: >=20 > What are the next steps to get this document approved as an RFC? Is = there anything missing? On the ETSI side we do need to reference this = document from an ETSI standard that will be published very soon. > Bruno > -----Message d'origine----- > De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de Jesske, = Roland > Envoy=C3=A9 : mardi 24 octobre 2017 11:25 > =C3=80 : sipcore@ietf.org > Objet : [sipcore] WG: New Version Notification for = draft-winterbottom-sipcore-locparam-02.txt >=20 > Dear all, > last week I have updated draft-winterbottom-sipcore-locparam due to = the discussions made. > So all comments made are now reflected. > I did some improvement of the text with regard to the use of the = locparam within the trusted domain. > This reflects the use to be intended within a trust domain. >=20 > Thank you and Best Regards >=20 > Roland=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Gesendet: Donnerstag, 19. Oktober 2017 05:44 > An: Andrew Hutton ; Jesske, Roland = ; James Winterbottom = ; Bruno Chatras = > Betreff: New Version Notification for = draft-winterbottom-sipcore-locparam-02.txt >=20 >=20 > A new version of I-D, draft-winterbottom-sipcore-locparam-02.txt > has been successfully submitted by Roland Jesske and posted to the = IETF repository. >=20 > Name: draft-winterbottom-sipcore-locparam > Revision: 02 > Title: Location Source Parameter for the SIP = Geolocation Header Field > Document date: 2017-10-18 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-winterbottom-sipcore-locparam-0= 2.txt > Status: = https://datatracker.ietf.org/doc/draft-winterbottom-sipcore-locparam/ > Htmlized: = https://tools.ietf.org/html/draft-winterbottom-sipcore-locparam-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-winterbottom-sipcore-locparam-= 02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-winterbottom-sipcore-locparam-02= >=20 > Abstract: > There are some circumstances where a geolocation header field may > contain more than one location value. Knowing the identity of the > node adding the location value allows the recipient more freedom in > selecting the value to look at first rather than relying solely on > the order of the location values. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Oct 26 06:09:16 2017 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 5575E13F58D for ; Thu, 26 Oct 2017 06:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doMH1kDuwMYT for ; Thu, 26 Oct 2017 06:09:13 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73DB137A70 for ; Thu, 26 Oct 2017 06:09:11 -0700 (PDT) Received: from [192.168.40.79] (h-205-12.A165.corp.bahnhof.se [176.10.205.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 31F593205; Thu, 26 Oct 2017 15:09:08 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_FE4C4923-8693-4D53-83EE-859CB27726E1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 26 Oct 2017 15:09:07 +0200 In-Reply-To: <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> Cc: Olle E Johansson , bruno.chatras@orange.com, "sipcore@ietf.org" , "Jesske, Roland" To: Brian Rosen References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:09:15 -0000 --Apple-Mail=_FE4C4923-8693-4D53-83EE-859CB27726E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Some quick comments to version -02: in section 4, you refer to =E2=80=9Cother-loc-src=E2=80=9D as a token. = That=E2=80=99s not clearly specified. WIll there be a registry for = =E2=80=9Ctokens=E2=80=9D? I am afraid that this is an opening for private tokens that hinders = interoperability. In =E2=80=9CPrivacy considerations=E2=80=9D - should you not discuss = what happens with my privacy if an entity in the network, but not my phone, adds a location? In =E2=80=9Csecurity considerations=E2=80=9D there=E2=80=99s a = discussion about a =E2=80=9Ctrusted network=E2=80=9D - but that is not = defined. What is a trusted network? There=E2=80=99s no mention on how to apply trust, = privacy, confidentiality. There is a typo as well: "when passed to an other domain.=E2=80=9D =20 s/an other/another/ Cheers, /O= --Apple-Mail=_FE4C4923-8693-4D53-83EE-859CB27726E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Some quick comments to version -02:

in section 4, you refer to = =E2=80=9Cother-loc-src=E2=80=9D as a token. That=E2=80=99s not clearly = specified. WIll there be a registry for =E2=80=9Ctokens=E2=80=9D?
I am afraid that this is an opening for private tokens that = hinders interoperability.

In =E2=80=9CPrivacy considerations=E2=80=9D - should you not = discuss what happens with my privacy if an entity in the = network,
but not my phone, adds a = location?

In = =E2=80=9Csecurity considerations=E2=80=9D there=E2=80=99s a discussion = about a =E2=80=9Ctrusted network=E2=80=9D - but that is not defined. = What is
a trusted network? There=E2=80=99s no = mention on how to apply trust, privacy, confidentiality.

There is a typo as well: = "when passed to an other domain.=E2=80=9D =  
s/an = other/another/
Cheers,
/O
= --Apple-Mail=_FE4C4923-8693-4D53-83EE-859CB27726E1-- From nobody Thu Oct 26 06:14:09 2017 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 6598413F588 for ; Thu, 26 Oct 2017 06:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrLkIuV-GBW2 for ; Thu, 26 Oct 2017 06:14:05 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75EA913F589 for ; Thu, 26 Oct 2017 06:14:05 -0700 (PDT) Received: from [192.168.40.79] (h-205-12.A165.corp.bahnhof.se [176.10.205.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id DC64F3205; Thu, 26 Oct 2017 15:14:02 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E9181AD2-DF0C-4C97-A152-691A99958FE3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 26 Oct 2017 15:14:02 +0200 In-Reply-To: <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> Cc: Olle E Johansson , bruno.chatras@orange.com, "Jesske, Roland" To: Brian Rosen , "sipcore@ietf.org" References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:14:07 -0000 --Apple-Mail=_E9181AD2-DF0C-4C97-A152-691A99958FE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Went back to the RFC you are updating. The security considerations there = are very much out of date with current IETF practise in my opinion. If you update 6442, the security = section would benefit from an update. Referring to S/MIME (not really implemented much) and SIPS: (which is = totally out-of-date) is not acceptable any more.=20 /O > On 26 Oct 2017, at 15:09, Olle E. Johansson wrote: >=20 > Some quick comments to version -02: >=20 > in section 4, you refer to =E2=80=9Cother-loc-src=E2=80=9D as a token. = That=E2=80=99s not clearly specified. WIll there be a registry for = =E2=80=9Ctokens=E2=80=9D? > I am afraid that this is an opening for private tokens that hinders = interoperability. >=20 > In =E2=80=9CPrivacy considerations=E2=80=9D - should you not discuss = what happens with my privacy if an entity in the network, > but not my phone, adds a location? >=20 > In =E2=80=9Csecurity considerations=E2=80=9D there=E2=80=99s a = discussion about a =E2=80=9Ctrusted network=E2=80=9D - but that is not = defined. What is > a trusted network? There=E2=80=99s no mention on how to apply trust, = privacy, confidentiality. >=20 > There is a typo as well: "when passed to an other domain.=E2=80=9D =20 > s/an other/another/ >=20 > Cheers, > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_E9181AD2-DF0C-4C97-A152-691A99958FE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Went back to the RFC you are updating. The security = considerations there are very much out of date with
current= IETF practise in my opinion. If you update 6442, the security section = would benefit from an update.

Referring to S/MIME (not really = implemented much) and SIPS: (which is totally out-of-date) is not = acceptable
any more. 

/O

On = 26 Oct 2017, at 15:09, Olle E. Johansson <oej@edvina.net> = wrote:

Some quick = comments to version -02:

in section 4, you refer to =E2=80=9Cother-loc-src=E2=80=9D as = a token. That=E2=80=99s not clearly specified. WIll there be a registry = for =E2=80=9Ctokens=E2=80=9D?
I am afraid that this = is an opening for private tokens that hinders = interoperability.

In =E2=80=9CPrivacy considerations=E2=80=9D - should you not = discuss what happens with my privacy if an entity in the = network,
but not my phone, adds a = location?

In = =E2=80=9Csecurity considerations=E2=80=9D there=E2=80=99s a discussion = about a =E2=80=9Ctrusted network=E2=80=9D - but that is not defined. = What is
a trusted network? There=E2=80=99s no = mention on how to apply trust, privacy, confidentiality.

There is a typo as well: = "when passed to an other domain.=E2=80=9D =  
s/an = other/another/
Cheers,
/O
__________________________________________= _____
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_E9181AD2-DF0C-4C97-A152-691A99958FE3-- From nobody Thu Oct 26 06:21:35 2017 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 2D2A813F589 for ; Thu, 26 Oct 2017 06:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KIEOX5Babzb for ; Thu, 26 Oct 2017 06:21:32 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90B913F58D for ; Thu, 26 Oct 2017 06:21:30 -0700 (PDT) Received: from [192.168.40.79] (h-205-12.A165.corp.bahnhof.se [176.10.205.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 3DBC43205; Thu, 26 Oct 2017 15:21:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Olle E. Johansson" In-Reply-To: <00ae0436-6110-1195-2e56-98279b45b367@ntlworld.com> Date: Thu, 26 Oct 2017 15:21:27 +0200 Cc: Olle E Johansson , "Jesske, Roland" , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <70F63F58-40A5-4337-95EA-01B36260FD05@edvina.net> <22017c1f-9639-9b5a-4a74-ef6a3335ec07@ntlworld.com> <00ae0436-6110-1195-2e56-98279b45b367@ntlworld.com> To: Keith Drage X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] SIP timer B in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:21:34 -0000 > On 22 Oct 2017, at 13:25, Keith Drage wrote: >=20 > I am not sure this answers the point of the original poster, and in = many ways, just reinforces my argument that these are protocol = protection timers. >=20 > What the application does over the top is entirely up to the = application, and should not directly interfere with these timers, = because underlying these timers are the physical characteristics of the = link itself. >=20 > However, in the same way as if a human user decides that setting up a = call is taking too long and manually clears it down, there is nothing to = stop the application using SIP from running a timer to do the same = thing. Well, there that matter of a MUST for timer B being 64*T1. T1 determines the number of retransmissions until timer B fires. In some = cases, like when using a satellite link, this doesn=E2=80=99t work. I = have a long latency and don=E2=80=99t need a lot of retransmissions. I need timer T1 to be = 700 ms, but don=E2=80=99t want to wait 64*T1 for failover. It does not = make sense. It seems like Keith agrees with me that 64*T1 should be a =E2=80=9Cdefault= =E2=80=9D value and timer B should be configurable in the software. The way I parse RFC 3261 this breaks SIP compliance and we will need to = update in order to get this setting - which again exists in almost every SIP implementation - SIP compliant. /O >=20 > Keith >=20 > On 19-Oct-17 3:37 AM, Jesske, Roland wrote: >> Hi Keith, >> You can "configure" Timer B. But you can do it only via T1, since T1 = may be choose it shorter (not recommended) or longer as defined in = section >> 17.1.1.2 Formal Description >> The default value for T1 is 500 ms. T1 is an estimate of the RTT >> between the client and server transactions. Elements MAY (though = it >> is NOT RECOMMENDED) use smaller values of T1 within closed, = private >> networks that do not permit general Internet connection. T1 MAY = be >> chosen larger, and this is RECOMMENDED if it is known in advance >> (such as on high latency access links) that the RTT is larger. >> Whatever the value of T1, the exponential backoffs on = retransmissions >> described in this section MUST be used. >>=20 >> But keep in mind if you change T1 then you change all T1 dependent = timers. >>=20 >> Best Regards >>=20 >> Roland >>=20 >>> -----Urspr=C3=BCngliche Nachricht----- >>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Keith = Drage >>> Gesendet: Dienstag, 17. Oktober 2017 23:59 >>> An: sipcore@ietf.org >>> Betreff: Re: [sipcore] SIP timer B in RFC 3261 >>>=20 >>> I don't go back far enough to have the history of this - it is well = over >>> 17 years ago, but: >>>=20 >>> My perspective has always been that these timers are the protocol >>> protection timers, i.e. those that prevent the protocol getting = locked up and >>> the protocol disappearing into a state that it cannot get out of, = particularly >>> when it is running over UDP where it also needs to provide a = mechanism for >>> giving some reliability to messages. >>>=20 >>> There is nothing to stop the user implementing timers at an = application level >>> that are shorter than this, and running in parallel to the protocol = level timers, >>> and then using the cancellation mechanisms as appropriate within the >>> protocol to clear the protocol. Those timers could depend on the = needs of >>> the application, and the needs of human user interaction, therefore >>> applications supporting a voice call might take a different approach = to one >>> running MSRP. >>>=20 >>> Therefore timer B is not shorter in this viewpoint, merely never = expires >>> because something else at the application layer gets there first. >>>=20 >>> I would add that anyone designing an application with such shorter = timers >>> needs to ensure that they are not creating a mechanism for a denial = of >>> service attack using this application. >>>=20 >>> regards >>>=20 >>> Keith >>>=20 >>>=20 >>>=20 >>> On 17-Oct-17 8:07 AM, Olle E. Johansson wrote: >>>> Hi! >>>>=20 >>>> Section 17.1.1.2 of 3261 says: >>>> "For any transport, the client transaction MUST start timer B with = a value >>>> of 64*T1 seconds (Timer B controls transaction timeouts).=E2=80=9D= >>>>=20 >>>> This MUST surprised me when someone pointed at it recently. For a = very >>>> long time, almost all SIP implementations has a user-configurable >>>> setting for Timer B, so there must be a reason why this MUST is = ignored. >>> Many web pages found with my friends at G talk about a default = setting >>> being 64*T1, but the RFC is quite clear that it=E2=80=99s not = something one should not >>> modify. >>>> In my experience there are plenty of situations where you want to >>>> modify T1 to set the number of retransmissions and speed of them >>>> independently of the end of transaction. The user experience comes = first >>> and you want SRV failover to be quite quick. Lowering the T1 will = generate >>> more of a packet storm which in many cases doesn=E2=80=99t help. >>>> Anyone from that time long ago when this was written that remembers >>>> why there is a MUST here? Was the MUST just indicating =E2=80=9Cstar= t timer B=E2=80=9D or >>> was it really a MUST on 64*T1? Could be an edit that made this turn = out >>> wrong... >>>> Do we have any other documents (or part of 3261) that makes Timer B >>> configurable? >>>> Thank you for your feedback! >>>>=20 >>>> /Olle >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Oct 26 06:47:45 2017 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 BE1F413F589 for ; Thu, 26 Oct 2017 06:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ihxKRqrRdGX for ; Thu, 26 Oct 2017 06:47:42 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D882313F4A9 for ; Thu, 26 Oct 2017 06:47:41 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id h70so5484929ioi.4 for ; Thu, 26 Oct 2017 06:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zI8jP6fJOA0frMt9D/rBm+Llops93/8bs40p29IsL9Q=; b=sdzwnJgz1hnNd2qF3/Ipl1QoSPws1hfFO+5iYWW168iULWFcFVdlRiNPiet1s/u5ha nmL8ZFrGRccKvn6kY/ZPXqCZSvOd3WfzUgto7T6xKA7Uh8nNzpOOJLuxysddZOzzmKhW l4kV/BLBh0ahQdOR6GxIxUAnkMfcoaLo+NKhMHfKGpLRe0ifvCEyVg9pW9655IO5PuoQ UcruBnFKZQMfLGUIaItSMlEatylVU8Q0BFjHBwbyzEwJSMd3Bc5vx0oj+uA7O3ocerjW KeNDn3fTMDnSmf7XcbctOftv50BTbqJ4/GF1cuWAVkgUDfEdJaIfaabyRaakUHBI9sa9 aN/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zI8jP6fJOA0frMt9D/rBm+Llops93/8bs40p29IsL9Q=; b=J6oMRwKM9tvmfJi9AGoFLVUS5jBIPkzD+vp48bCREqrMEUz6geSh8myYNRDpDXTrv6 CyhkewJXuRQuH5JA2rAXmrEEUdvuVsRBJvzRU8oN4G4US+XwJmze+wdTqCjzdyCbTaWR I+61SmguSL/N3MqxhyzEo++Xnlvo8T0SRRGsVCtBqV6SmSMc+uQsD3OYW69Rk3nIXkbM u7dGXEyE+1vMm6N7L8Thcs7B+oeGUbN5VI4u5baE5OqGvecL6Zk5rCzK7puX4gpEq0sg AM2TuTWygzQ/MDf1wXw3RdLZFIPlT9PnJ5Bh1q7QwhOi2WMHhfde00n/3EMNSPAKzhm0 F4Jg== X-Gm-Message-State: AMCzsaXIGgHb7dHgXu2NDeOsyiuIvXi3WsZxG/oYJG8VtLGf7mpy2yDy Y2XOwMV1XwaaBHEk7CPQtrw9ag== X-Google-Smtp-Source: ABhQp+S7w1LZUyKQea5Nao32eo0T7pFIWg6Ru7bSUX8NXzwQZipiN0nZs3rz2TNnPyq9g2dk3pgbhw== X-Received: by 10.107.102.14 with SMTP id a14mr31728148ioc.60.1509025661068; Thu, 26 Oct 2017 06:47:41 -0700 (PDT) Received: from [10.33.193.2] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id 137sm737696itb.42.2017.10.26.06.47.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 06:47:39 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1CBED8BC-FF53-46B9-B478-527FE3EEAAA9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 26 Oct 2017 09:47:38 -0400 In-Reply-To: Cc: "sipcore@ietf.org" , bruno.chatras@orange.com, "Jesske, Roland" To: Olle E Johansson References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:47:44 -0000 --Apple-Mail=_1CBED8BC-FF53-46B9-B478-527FE3EEAAA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for noticing this. Any way we could convince you to draft a = paragraph that could be included with this document that will do that = update to security for 6442? Brian > On Oct 26, 2017, at 9:14 AM, Olle E. Johansson wrote: >=20 > Went back to the RFC you are updating. The security considerations = there are very much out of date with > current IETF practise in my opinion. If you update 6442, the security = section would benefit from an update. >=20 > Referring to S/MIME (not really implemented much) and SIPS: (which is = totally out-of-date) is not acceptable > any more.=20 >=20 > /O >=20 >> On 26 Oct 2017, at 15:09, Olle E. Johansson > wrote: >>=20 >> Some quick comments to version -02: >>=20 >> in section 4, you refer to =E2=80=9Cother-loc-src=E2=80=9D as a = token. That=E2=80=99s not clearly specified. WIll there be a registry = for =E2=80=9Ctokens=E2=80=9D? >> I am afraid that this is an opening for private tokens that hinders = interoperability. >>=20 >> In =E2=80=9CPrivacy considerations=E2=80=9D - should you not discuss = what happens with my privacy if an entity in the network, >> but not my phone, adds a location? >>=20 >> In =E2=80=9Csecurity considerations=E2=80=9D there=E2=80=99s a = discussion about a =E2=80=9Ctrusted network=E2=80=9D - but that is not = defined. What is >> a trusted network? There=E2=80=99s no mention on how to apply trust, = privacy, confidentiality. >>=20 >> There is a typo as well: "when passed to an other domain.=E2=80=9D =20= >> s/an other/another/ >>=20 >> Cheers, >> /O >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 --Apple-Mail=_1CBED8BC-FF53-46B9-B478-527FE3EEAAA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for noticing this.  Any way we could convince you = to draft a paragraph that could be included with this document that will = do that update to security for 6442?

Brian

On = Oct 26, 2017, at 9:14 AM, Olle E. Johansson <oej@edvina.net> = wrote:

Went back to = the RFC you are updating. The security considerations there are very = much out of date with
current IETF practise in my = opinion. If you update 6442, the security section would benefit from an = update.

Referring to S/MIME (not really implemented much) and SIPS: = (which is totally out-of-date) is not acceptable
any = more. 

/O

On 26 = Oct 2017, at 15:09, Olle E. Johansson <oej@edvina.net> = wrote:

Some quick = comments to version -02:

in section 4, you refer to =E2=80=9Cother-loc-src=E2=80=9D as = a token. That=E2=80=99s not clearly specified. WIll there be a registry = for =E2=80=9Ctokens=E2=80=9D?
I am afraid that this = is an opening for private tokens that hinders = interoperability.

In =E2=80=9CPrivacy considerations=E2=80=9D - should you not = discuss what happens with my privacy if an entity in the = network,
but not my phone, adds a = location?

In = =E2=80=9Csecurity considerations=E2=80=9D there=E2=80=99s a discussion = about a =E2=80=9Ctrusted network=E2=80=9D - but that is not defined. = What is
a trusted network? There=E2=80=99s no = mention on how to apply trust, privacy, confidentiality.

There is a typo as well: = "when passed to an other domain.=E2=80=9D =  
s/an = other/another/
Cheers,
/O
__________________________________________= _____
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


= --Apple-Mail=_1CBED8BC-FF53-46B9-B478-527FE3EEAAA9-- From nobody Thu Oct 26 12:34:06 2017 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 C3F891389AC for ; Thu, 26 Oct 2017 12:34:04 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmOr07lzDD7p for ; Thu, 26 Oct 2017 12:34:03 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 305FD13871A for ; Thu, 26 Oct 2017 12:34:02 -0700 (PDT) X-AuditID: 12074412-1fdff7000000748d-33-59f238aaa8ff Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B7.22.29837.AA832F95; Thu, 26 Oct 2017 15:34:02 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9QJY0L5001075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Oct 2017 15:34:01 -0400 To: sipcore@ietf.org References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> From: Paul Kyzivat Message-ID: <43d0afd7-1cc5-cc8c-ccdd-a87653503f90@alum.mit.edu> Date: Thu, 26 Oct 2017 15:34:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixO6iqLvK4lOkwfFePouvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48rmaUwFb9kq+ptsGhg3sXYxcnJICJhI3O/ay9bFyMUhJLCD SeLMnw4WkISQwA8miU/7jUBsYYEEiY2Pu5lAbBEBEYln0/9BNXQwS6x7PANsEpuAlsScQ//B mnkF7CXOnG0Hi7MIqEpsP3CfDcQWFUiTuDPjIRNEjaDEyZlPwOo5BewkTndPYgaxmQXMJOZt fghli0vcejKfCcKWl2jeOpt5AiP/LCTts5C0zELSMgtJywJGllWMcok5pbm6uYmZOcWpybrF yYl5ealFumZ6uZkleqkppZsYIUEptINx/Um5Q4wCHIxKPLwrND9FCrEmlhVX5h5ilORgUhLl ZdjzIVKILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO9cfaBy3pTEyqrUonyYlDQHi5I478/F6n5C AumJJanZqakFqUUwWRkODiUJ3jxzoEbBotT01Iq0zJwShDQTByfIcB6g4SdAaniLCxJzizPT IfKnGC05bjy8/oeJo6fnBpB8NvN1A7MQS15+XqqUOG82SIMASENGaR7cTFiSecUoDvSiMO8z kCoeYIKCm/oKaCET0MIm1Q8gC0sSEVJSDYyphy/MMD5z5qxtV+OxjYWrjyhKyRrtSLfddlZi R2CGyTE297ezLx5a6xl+sZnHQItNd8J1xbimagbBV6/PNKTsSboX/UpC7OKWvMwp/E+FQ9du SzZu/aMWOTm2eWrgV94FreEX9X5LrRM4yP/879YFGovfHRWZmudYdjjg0/qX4twrrf5fEwpQ YinOSDTUYi4qTgQALSq25A0DAAA= Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 19:34:05 -0000 On 10/26/17 9:09 AM, Olle E. Johansson wrote: > Some quick comments to version -02: > > in section 4, you refer to “other-loc-src” as a token. That’s not > clearly specified. WIll there be a registry for “tokens”? > I am afraid that this is an opening for private tokens that hinders > interoperability. Agree. A simply way out of this is to leave use of this for future definition, so that, for now, it can't be used, but with default processing on reception being defined to ignore. There are other problems with this as well. Syntactically, 'token' isn't defined. I trust what is intended is 'token' as defined in 3261. If so that needs to be specified. But that presents a further problem - ambiguity. A token is a superset of hostname. There needs to be a way to distinguish an 'other-loc-src' from a hostname. Thanks, Paul From nobody Thu Oct 26 23:53:28 2017 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 52E1213B10E for ; Thu, 26 Oct 2017 23:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGCDzPyLIPPl for ; Thu, 26 Oct 2017 23:53:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC90513B10F for ; Thu, 26 Oct 2017 23:53:24 -0700 (PDT) X-AuditID: c1b4fb2d-bf5ff7000000268d-4d-59f2d7e2c00c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.62.09869.2E7D2F95; Fri, 27 Oct 2017 08:53:22 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Fri, 27 Oct 2017 08:53:22 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: draft-sip-push-01 Thread-Index: AQHTTvBHLyywS3X2LE6SM4z0ppMbCA== Date: Fri, 27 Oct 2017 06:53:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D618B43D24E56christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7qO6j658iDbY361l8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGReO9TMVzOKpWHwpt4HxOFcXIyeHhICJxPp1/9m7GLk4hASO MErMu3uPDcJZzCjxZcYq1i5GDg42AQuJ7n/aIA0iApoSy79tZQexhQV0JU79nMIEETeSeDp7 CzOErSexa2UnK4jNIqAqMeHPTbB6XgFriVm/L7OB2IwCYhLfT60B62UWEJe49WQ+E8RBAhJL 9pxnhrBFJV4+/gc2RxRo5oYTt9lBzpEQUJRY3i8H0Zog8ez/EUaI8YISJ2c+YZnAKDQLydRZ SMpmISmDiBtIvD83nxnC1pZYtvA1lK0vsfHLWUYI21pi7eLXjMhqFjByrGIULU4tLs5NNzLW Sy3KTC4uzs/Ty0st2cQIjJODW37r7mBc/drxEKMAB6MSD+/yy58ihVgTy4orcw8xSnAwK4nw Gh0DCvGmJFZWpRblxxeV5qQWH2KU5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cDYf/TP 3BPHZjL09BmGfyrdxL7H7Zznuf9vDm3TXmfSGKIwbfVJPtWHrbW9+3VmZxUa5xns2/3H65fh gytvthv8/Kvr+Dzg9DJpY8MZlxy3vxD856wYbzRf84XYTL1wr9/iFUw31UPZ5YLFDOJd71b8 DHbNap2u5L6cceVtZb7yhwflsliKz8QrsRRnJBpqMRcVJwIANF1iSI8CAAA= Archived-At: Subject: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 06:53:26 -0000 --_000_D618B43D24E56christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-01) of draft-holmberg-sipcore-sip-push. The new version contain more text, including the creation of an IANA regist= ry for pn-type values. The draft also adds two values to the new registry: = =93apns=94 (Apple Push Notification service) and =93fcm=94 (Firebase Cloud = Messaging). Regards, Christer --_000_D618B43D24E56christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve submitted a new version (-01) of draft-holmberg-sipcore-sip-pus= h.

The new version contain more text, including the creation of an IANA r= egistry for pn-type values. The draft also adds two values to the new regis= try: =93apns=94 (Apple Push Notification service) and =93fcm=94 (Firebase C= loud Messaging).

Regards,

Christer 
--_000_D618B43D24E56christerholmbergericssoncom_-- From nobody Fri Oct 27 01:22:45 2017 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 E31A7138FA0 for ; Fri, 27 Oct 2017 01:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 8V3apdEAFAPy for ; Fri, 27 Oct 2017 01:22:42 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 E8B9713F602 for ; Fri, 27 Oct 2017 01:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1509092562; x=1540628562; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ELB27G4WfCtpJ5XiZdUnHs4/vZ2O0+cOiVnlqDtzHL0=; b=1hYQYnJsBXNvqRNLMJjSngWcefi50weuofdyVHDkCStpCFZmoL9trJaY SqwOK78I2tyimAWRLs8OisL32HAZ3o2B85pp9asYp7ZxJrLqfI6EpXvOZ pEfuFTRpxQ30NTx0r0uCEELBw3A4VWKVHWjh4+j/6PEMTJwA7BtoE80QF aekIADu9mBr9y+Kc68GooSpe2raUmmPXq/G7iXyYrVkSfGK987CqGuT21 AJWKyMUwgKkp70jUvc1JooqFa3a8PNowWLbGmnUPifjW2ReepuTbvz9Ov OZ1ql9P6JU1WW3Jn6kfGSnJiMTcd/NBJmatbWhBo4PNKDOLAVaEiRMMrG w==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 10:22:40 +0200 X-IronPort-AV: E=Sophos;i="5.44,304,1505772000"; d="scan'208";a="755860062" Received: from he105704.emea1.cds.t-internal.com ([10.169.119.21]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 27 Oct 2017 10:22:30 +0200 Received: from HE104848.EMEA1.cds.t-internal.com (10.169.119.17) by HE105704.emea1.cds.t-internal.com (10.169.119.21) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 10:22:12 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE104848.EMEA1.cds.t-internal.com (10.169.119.17) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 27 Oct 2017 10:22:12 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.23) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 10:21:39 +0200 Received: from LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.14) by LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 27 Oct 2017 08:22:11 +0000 Received: from LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE ([fe80::605e:e45f:65a5:d5db]) by LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE ([fe80::605e:e45f:65a5:d5db%14]) with mapi id 15.20.0077.023; Fri, 27 Oct 2017 08:22:11 +0000 From: "Jesske, Roland" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt Thread-Index: AQHTSIyCShmGYDH9NU+jyalmJJwJvqLywkmQgAM1jWCAACwHgIAAAj+AgABriQCAANVWsA== Date: Fri, 27 Oct 2017 08:22:11 +0000 Message-ID: References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> <43d0afd7-1cc5-cc8c-ccdd-a87653503f90@alum.mit.edu> In-Reply-To: <43d0afd7-1cc5-cc8c-ccdd-a87653503f90@alum.mit.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LEXPR01MB0494; 6:S+uNBEqVmjbrYcNuv1WBsjClI1Ly+bOtIHeDP777nhQVRb5JKGos+IwpUy0yJ76QN9hIweeOYUJNLWiVAH2VlakpqdTI9wUFRs66vxdsIpK3Sky1vE9tCwqwsfb59vujOdhwRqnsMngN1WnG+j48t9zRvEyXNkFQc3Awdmb6eptftLJtdJ3ZmlgLJNaE+mkaL+nz3VXvTcQsQXtLj3bjU9ceRwI0zTDKUmyCOwQ0inRzRVvZv+jxM6L8dNfdhIC2oztu3jht0Mcy+a4pfjsfoh5E8EwjYQcfjKNF/IhFLXHk3Sldm1ZrpTt4IIjHEoEGmBc87QCYjSWtDjdu8Iy2hw==; 5:Z7sZHT6jEWMmD4LWVfOJhMH8xGx51xMY2a8S7j9dK0yz5T9/z1MnThdv4irvQM8PAbh3GDbb4OhNNF3Tu+IcnH/8NXhqabswDxrw4JvoTKhnhJy9Fo/FA8v0+pHlcm6XLNPKniYJ/LBpfYKKj2oddw==; 24:2iFujJkjhKPbbU0sTNurXEGnPVn7w2dkAcJlQRsN1zjYJCYHX7V9IltQeWo92ix5iKEfnV78Of7FOiRsFk2sODP+nHyQyrTdqr+XGjXkZps=; 7:J34K/xT3d6cyh/AIGaFm+SMEUcP/hKEGFPpoTZTPgh/21z9HWD10bM+WpI1lpHnynmDaqn7bTTEn6rC7zpaJL97w036ml/C1RUhgnk2j/HeTUjjRlguYNXjDmymGOO4mP5XMMsfqEtgNTSyo/x2LUAAZ6E4oQ3WjCq01wFk3nFx3zYIKXBM6MyfNtp39m2b+I8ht44N0E/oqfs28WO65TMXYY7qypyFWczwjQ9/yCZY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f7191e08-08d2-416e-022f-08d51d13d2b4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:LEXPR01MB0494; x-ms-traffictypediagnostic: LEXPR01MB0494: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LEXPR01MB0494; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LEXPR01MB0494; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(24454002)(189002)(478600001)(81166006)(74482002)(76176999)(5250100002)(81156014)(86362001)(53546010)(106356001)(72206003)(230783001)(101416001)(2906002)(33656002)(3280700002)(8676002)(105586002)(53936002)(2171002)(966005)(50986999)(9686003)(15650500001)(55016002)(2501003)(2900100001)(345774005)(3846002)(14454004)(110136005)(54356999)(189998001)(75402003)(5660300001)(6116002)(97736004)(6306002)(93886005)(102836003)(3660700001)(8936002)(316002)(66066001)(305945005)(7736002)(2950100002)(68736007)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0494; H:LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 08:22:11.8608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0494 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 08:22:45 -0000 VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLg0KV2UgaGFkIHRoZSBkaXNjdXNzaW9uIGEgY291 cGxlIG9mIHdlZWtzIGFnby4NCkkgaGFkIGxldCBpbiB0aGUgdG9rZW4gZHVlIHRvIHNvbWUgY29t bWVudC4gSXQgd2FzIHN0YXRlZCB0aGUgdGkgd291bGQgYmUgZ29vZCB0byBoYXZlIHRoZSBwb3Nz aWJpbGl0eSBvZiBleHRlbmRpbmcgdGhlIG1lY2hhbmlzbS4NCkVUU0kgZG9lcyBvbmx5IG5lZWQg b25seSB0aGUgbG9jLXNyYy4NClNvIGJlZm9yZSBvcGVuaW5nIFBhbmRvcmEncyBib3ggSSB3aWxs IGRlbGV0ZSB0aGUgb3RoZXItbG9jLXNyYy4NCg0KSXMgdGhpcyBPSyBmb3IgZXZlcnlib2R5Pw0K DQpCZXN0IHJlZ2FyZHMNCg0KUm9sYW5kDQoNCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmlj aHQtLS0tLQ0KPiBWb246IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IEltIEF1ZnRyYWcgdm9uIFBhdWwgS3l6aXZhdA0KPiBHZXNlbmRldDogRG9ubmVyc3RhZywgMjYu IE9rdG9iZXIgMjAxNyAyMTozNA0KPiBBbjogc2lwY29yZUBpZXRmLm9yZw0KPiBCZXRyZWZmOiBS ZTogW3NpcGNvcmVdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2ludGVyYm90 dG9tLXNpcGNvcmUtDQo+IGxvY3BhcmFtLTAyLnR4dA0KPiANCj4gT24gMTAvMjYvMTcgOTowOSBB TSwgT2xsZSBFLiBKb2hhbnNzb24gd3JvdGU6DQo+ID4gU29tZSBxdWljayBjb21tZW50cyB0byB2 ZXJzaW9uIC0wMjoNCj4gPg0KPiA+IGluIHNlY3Rpb24gNCwgeW91IHJlZmVyIHRvIOKAnG90aGVy LWxvYy1zcmPigJ0gYXMgYSB0b2tlbi4gVGhhdOKAmXMgbm90DQo+ID4gY2xlYXJseSBzcGVjaWZp ZWQuIFdJbGwgdGhlcmUgYmUgYSByZWdpc3RyeSBmb3Ig4oCcdG9rZW5z4oCdPw0KPiA+IEkgYW0g YWZyYWlkIHRoYXQgdGhpcyBpcyBhbiBvcGVuaW5nIGZvciBwcml2YXRlIHRva2VucyB0aGF0IGhp bmRlcnMNCj4gPiBpbnRlcm9wZXJhYmlsaXR5Lg0KPiANCj4gQWdyZWUuIEEgc2ltcGx5IHdheSBv dXQgb2YgdGhpcyBpcyB0byBsZWF2ZSB1c2Ugb2YgdGhpcyBmb3IgZnV0dXJlIGRlZmluaXRpb24s IHNvDQo+IHRoYXQsIGZvciBub3csIGl0IGNhbid0IGJlIHVzZWQsIGJ1dCB3aXRoIGRlZmF1bHQg cHJvY2Vzc2luZyBvbiByZWNlcHRpb24gYmVpbmcNCj4gZGVmaW5lZCB0byBpZ25vcmUuDQo+IA0K PiBUaGVyZSBhcmUgb3RoZXIgcHJvYmxlbXMgd2l0aCB0aGlzIGFzIHdlbGwuDQo+IA0KPiBTeW50 YWN0aWNhbGx5LCAndG9rZW4nIGlzbid0IGRlZmluZWQuIEkgdHJ1c3Qgd2hhdCBpcyBpbnRlbmRl ZCBpcyAndG9rZW4nIGFzIGRlZmluZWQNCj4gaW4gMzI2MS4gSWYgc28gdGhhdCBuZWVkcyB0byBi ZSBzcGVjaWZpZWQuDQo+IA0KPiBCdXQgdGhhdCBwcmVzZW50cyBhIGZ1cnRoZXIgcHJvYmxlbSAt IGFtYmlndWl0eS4gQSB0b2tlbiBpcyBhIHN1cGVyc2V0IG9mDQo+IGhvc3RuYW1lLiBUaGVyZSBu ZWVkcyB0byBiZSBhIHdheSB0byBkaXN0aW5ndWlzaCBhbiAnb3RoZXItbG9jLXNyYycNCj4gZnJv bSBhIGhvc3RuYW1lLg0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBs aXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXBjb3JlDQo= From nobody Fri Oct 27 01:25:18 2017 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 27D941394E4 for ; Fri, 27 Oct 2017 01:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 I1Y_-Lr07d49 for ; Fri, 27 Oct 2017 01:25:15 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 32690138FA0 for ; Fri, 27 Oct 2017 01:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1509092714; x=1540628714; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=G7f1JZRfnLelIvtbRctM4K04uuFKE/MX4mqOj/vDBQU=; b=ZPeEkTkP2fnmVmQcwmDG/IFUQ15EMbRbVbFJbmXz6idW6pjGhm9n0kLC hn/bKRxRDSalq6c+/kne9GaSYP7+KKXLctYnr+bx0nlt+4pIZ/0LkE1bT yX49C4hVF6Euxwj6Iwpyx0Qvwyg5gJyFFTZS7NjV1ZWOF6NDAtJTedHX+ Vipgxs6Vh3Vy1pdnGHqJfqxfRUdDBCVNMUt4MfC+/Ibd+tw+UvPI2IgJV sNsQ4Gb0MW/M+Ha1A59QavtoekkOM8YDi9B1elrW/QETRkGdNsTWk56nY Wn2eX5X1ttbJ7t6UjyIc3Ye/E+BPmDrGjX7RZu+9Koxw+WM1vC1+TbCAl Q==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 10:25:11 +0200 X-IronPort-AV: E=Sophos;i="5.44,304,1505772000"; d="scan'208,217";a="103645938" Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 27 Oct 2017 10:25:11 +0200 Received: from HE101942.EMEA1.cds.t-internal.com (10.169.119.82) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 10:25:11 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE101942.EMEA1.cds.t-internal.com (10.169.119.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 27 Oct 2017 10:25:11 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.20) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Oct 2017 10:24:37 +0200 Received: from LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.14) by LEXPR01MB0493.DEUPRD01.PROD.OUTLOOK.DE (10.158.166.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 27 Oct 2017 08:25:10 +0000 Received: from LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE ([fe80::605e:e45f:65a5:d5db]) by LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE ([fe80::605e:e45f:65a5:d5db%14]) with mapi id 15.20.0077.023; Fri, 27 Oct 2017 08:25:10 +0000 From: "Jesske, Roland" To: Brian Rosen , Olle E Johansson CC: "sipcore@ietf.org" , "bruno.chatras@orange.com" Thread-Topic: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt Thread-Index: AQHTSIyCShmGYDH9NU+jyalmJJwJvqLywkmQgAM1jWCAACwHgIAAAj+AgAABYACAAAljAIABMktQ Date: Fri, 27 Oct 2017 08:25:10 +0000 Message-ID: References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LEXPR01MB0493; 6:0b9euKQf885SAkTKcHTnJLa8ETic2o5Y7dIqfWUtT7erRaBo8JmU9UUAL7ylzkdKUz2F9tOHmBr48aFGb0bRGNqXF4weHU5BAIQ+s4arZ02LOnWNq49PfaeNuKle0t4jNt3bMieX1yb8QjQ8HlBoSwfsg7NadvGtkdxrCoNm0G5wowpDy9Xz+Y4RxVZ8nzTWSR4YbPgaP0dlwWRVpd+9hORQ+CJQMTlpwCe7OqnPpTH+YuB/Ye6jZYkiMcA3CgDjI9Xi92hH+cjN5TtDLelOCiZMWtPk39Y/sE8nHCa5JEkWFiGL2dxzTp1O0Wds2Fzgn5ByDj5is1NwYI7r2fsSGg==; 5:LTgUuD67tEQkE1O5xLA57Ogv/W/y60ZAO5DL9o/WizbwXMpmXXRigF+/Gg4aISsfRxI5IfNGVPF2uEdAFkN0j0djtPVuPvtJb5Grj4QA2b+7A7oQejc7VjWDk942AugBrkGlvl7xvA2q9HpFXks0ZA==; 24:/w/JxtryXeQbdGRXQ4FXlJD1NU91FkNLjVG9oQ/icHqNheuedA1Bq/8sUIhdMc2dvi02SrsJYYzKipzTvYPD0FkpdeF6bmyXcyvPkHlzRz0=; 7:N1Hp+q2wBtIAVXFngOS21kFuLF6mDRgKv+mWGigWsLyEHlBA+p4uPeZMUqPL7S83/qvbkmBlBXNeNKb/zWV4Y53NnlJh7doNJqib3g263DYCiYSmo2066Og5ckrcw191PRF3iBFVQEcFQWwsfazqhAvxacxBQgSRUaZKRVRG4crRQyctn+T8FLI8UFQEPSkjXkt56zLdwME/Wbu0L0YMVwzAvl1Pi0jx6V9d7xOqjqQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0907a830-266e-4d48-1dc3-08d51d143cef x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:LEXPR01MB0493; x-ms-traffictypediagnostic: LEXPR01MB0493: x-exchange-antispam-report-test: UriScan:(192374486261705)(18271650672692)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LEXPR01MB0493; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LEXPR01MB0493; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(24454002)(189002)(199003)(81166006)(8936002)(75402003)(72206003)(236005)(97736004)(93886005)(8676002)(966005)(54906003)(53546010)(33656002)(55016002)(81156014)(316002)(2900100001)(6306002)(7696004)(9686003)(106356001)(66066001)(86362001)(105586002)(54896002)(606006)(189998001)(50986999)(14454004)(2950100002)(5660300001)(54356999)(230783001)(15650500001)(68736007)(5250100002)(790700001)(478600001)(7110500001)(110136005)(76176999)(4326008)(3280700002)(101416001)(3660700001)(10710500007)(74482002)(345774005)(3846002)(7736002)(6116002)(53936002)(2906002)(2420400007)(102836003)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0493; H:LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LEXPR01MB04942F39269598DFBA385816F95A0LEXPR01MB0494DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 08:25:10.0398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0493 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 08:25:17 -0000 --_000_LEXPR01MB04942F39269598DFBA385816F95A0LEXPR01MB0494DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQpUaGFuayB5b3UgZm9yIHRoZSBoaW50LCBJIHdpbGwgdXBkYXRlIHRoZSBzZWN1 cml0eSBzZWN0aW9uLg0KDQpCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQoNClZvbjogc2lwY29yZSBb bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQnJpYW4gUm9z ZW4NCkdlc2VuZGV0OiBEb25uZXJzdGFnLCAyNi4gT2t0b2JlciAyMDE3IDE1OjQ4DQpBbjogT2xs ZSBFIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+DQpDYzogc2lwY29yZUBpZXRmLm9yZzsgYnJ1 bm8uY2hhdHJhc0BvcmFuZ2UuY29tOyBKZXNza2UsIFJvbGFuZCA8Ui5KZXNza2VAdGVsZWtvbS5k ZT4NCkJldHJlZmY6IFJlOiBbc2lwY29yZV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC13aW50ZXJib3R0b20tc2lwY29yZS1sb2NwYXJhbS0wMi50eHQNCg0KVGhhbmtzIGZvciBu b3RpY2luZyB0aGlzLiAgQW55IHdheSB3ZSBjb3VsZCBjb252aW5jZSB5b3UgdG8gZHJhZnQgYSBw YXJhZ3JhcGggdGhhdCBjb3VsZCBiZSBpbmNsdWRlZCB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB3 aWxsIGRvIHRoYXQgdXBkYXRlIHRvIHNlY3VyaXR5IGZvciA2NDQyPw0KDQpCcmlhbg0KDQpPbiBP Y3QgMjYsIDIwMTcsIGF0IDk6MTQgQU0sIE9sbGUgRS4gSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5l dDxtYWlsdG86b2VqQGVkdmluYS5uZXQ+PiB3cm90ZToNCg0KV2VudCBiYWNrIHRvIHRoZSBSRkMg eW91IGFyZSB1cGRhdGluZy4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRoZXJlIGFyZSB2 ZXJ5IG11Y2ggb3V0IG9mIGRhdGUgd2l0aA0KY3VycmVudCBJRVRGIHByYWN0aXNlIGluIG15IG9w aW5pb24uIElmIHlvdSB1cGRhdGUgNjQ0MiwgdGhlIHNlY3VyaXR5IHNlY3Rpb24gd291bGQgYmVu ZWZpdCBmcm9tIGFuIHVwZGF0ZS4NCg0KUmVmZXJyaW5nIHRvIFMvTUlNRSAobm90IHJlYWxseSBp bXBsZW1lbnRlZCBtdWNoKSBhbmQgU0lQUzogKHdoaWNoIGlzIHRvdGFsbHkgb3V0LW9mLWRhdGUp IGlzIG5vdCBhY2NlcHRhYmxlDQphbnkgbW9yZS4NCg0KL08NCg0KT24gMjYgT2N0IDIwMTcsIGF0 IDE1OjA5LCBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ8bWFpbHRvOm9lakBlZHZp bmEubmV0Pj4gd3JvdGU6DQoNClNvbWUgcXVpY2sgY29tbWVudHMgdG8gdmVyc2lvbiAtMDI6DQoN CmluIHNlY3Rpb24gNCwgeW91IHJlZmVyIHRvIOKAnG90aGVyLWxvYy1zcmPigJ0gYXMgYSB0b2tl bi4gVGhhdOKAmXMgbm90IGNsZWFybHkgc3BlY2lmaWVkLiBXSWxsIHRoZXJlIGJlIGEgcmVnaXN0 cnkgZm9yIOKAnHRva2Vuc+KAnT8NCkkgYW0gYWZyYWlkIHRoYXQgdGhpcyBpcyBhbiBvcGVuaW5n IGZvciBwcml2YXRlIHRva2VucyB0aGF0IGhpbmRlcnMgaW50ZXJvcGVyYWJpbGl0eS4NCg0KSW4g 4oCcUHJpdmFjeSBjb25zaWRlcmF0aW9uc+KAnSAtIHNob3VsZCB5b3Ugbm90IGRpc2N1c3Mgd2hh dCBoYXBwZW5zIHdpdGggbXkgcHJpdmFjeSBpZiBhbiBlbnRpdHkgaW4gdGhlIG5ldHdvcmssDQpi dXQgbm90IG15IHBob25lLCBhZGRzIGEgbG9jYXRpb24/DQoNCkluIOKAnHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25z4oCdIHRoZXJl4oCZcyBhIGRpc2N1c3Npb24gYWJvdXQgYSDigJx0cnVzdGVkIG5l dHdvcmvigJ0gLSBidXQgdGhhdCBpcyBub3QgZGVmaW5lZC4gV2hhdCBpcw0KYSB0cnVzdGVkIG5l dHdvcms/IFRoZXJl4oCZcyBubyBtZW50aW9uIG9uIGhvdyB0byBhcHBseSB0cnVzdCwgcHJpdmFj eSwgY29uZmlkZW50aWFsaXR5Lg0KDQpUaGVyZSBpcyBhIHR5cG8gYXMgd2VsbDogIndoZW4gcGFz c2VkIHRvIGFuIG90aGVyIGRvbWFpbi7igJ0NCnMvYW4gb3RoZXIvYW5vdGhlci8NCg0KQ2hlZXJz LA0KL08NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz aXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoN Cg== --_000_LEXPR01MB04942F39269598DFBA385816F95A0LEXPR01MB0494DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFn ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEJy aWFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rIHlvdSBm b3IgdGhlIGhpbnQsIEkgd2lsbCB1cGRhdGUgdGhlIHNlY3VyaXR5IHNlY3Rpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVzdCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Um9sYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Wb246PC9iPiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5J bSBBdWZ0cmFnIHZvbg0KPC9iPkJyaWFuIFJvc2VuPGJyPg0KPGI+R2VzZW5kZXQ6PC9iPiBEb25u ZXJzdGFnLCAyNi4gT2t0b2JlciAyMDE3IDE1OjQ4PGJyPg0KPGI+QW46PC9iPiBPbGxlIEUgSm9o YW5zc29uICZsdDtvZWpAZWR2aW5hLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IHNpcGNvcmVAaWV0 Zi5vcmc7IGJydW5vLmNoYXRyYXNAb3JhbmdlLmNvbTsgSmVzc2tlLCBSb2xhbmQgJmx0O1IuSmVz c2tlQHRlbGVrb20uZGUmZ3Q7PGJyPg0KPGI+QmV0cmVmZjo8L2I+IFJlOiBbc2lwY29yZV0gTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13aW50ZXJib3R0b20tc2lwY29yZS1sb2Nw YXJhbS0wMi50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGFua3MgZm9yIG5vdGljaW5nIHRoaXMuICZuYnNwO0FueSB3YXkgd2Ug Y291bGQgY29udmluY2UgeW91IHRvIGRyYWZ0IGEgcGFyYWdyYXBoIHRoYXQgY291bGQgYmUgaW5j bHVkZWQgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgd2lsbCBkbyB0aGF0IHVwZGF0ZSB0byBzZWN1 cml0eSBmb3IgNjQ0Mj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5C cmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u IE9jdCAyNiwgMjAxNywgYXQgOToxNCBBTSwgT2xsZSBFLiBKb2hhbnNzb24gJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86b2VqQGVkdmluYS5uZXQiPjxzcGFuIGxhbmc9IkVOLVVTIj5vZWpAZWR2 aW5hLm5ldDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2VudCBiYWNrIHRvIHRoZSBSRkMgeW91 IGFyZSB1cGRhdGluZy4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRoZXJlIGFyZSB2ZXJ5 IG11Y2ggb3V0IG9mIGRhdGUgd2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Y3VycmVudCBJRVRGIHByYWN0aXNl IGluIG15IG9waW5pb24uIElmIHlvdSB1cGRhdGUgNjQ0MiwgdGhlIHNlY3VyaXR5IHNlY3Rpb24g d291bGQgYmVuZWZpdCBmcm9tIGFuIHVwZGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZmVycmluZyB0byBTL01JTUUgKG5vdCByZWFsbHkgaW1w bGVtZW50ZWQgbXVjaCkgYW5kIFNJUFM6ICh3aGljaCBpcyB0b3RhbGx5IG91dC1vZi1kYXRlKSBp cyBub3QgYWNjZXB0YWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hbnkgbW9yZS4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi9PPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDI2IE9jdCAyMDE3LCBhdCAxNTow OSwgT2xsZSBFLiBKb2hhbnNzb24gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2VqQGVkdmlu YS5uZXQiPjxzcGFuIGxhbmc9IkVOLVVTIj5vZWpAZWR2aW5hLm5ldDwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+U29tZSBxdWljayBjb21tZW50cyB0byB2ZXJzaW9uIC0wMjo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5pbiBzZWN0aW9uIDQsIHlvdSByZWZlciB0byDi gJxvdGhlci1sb2Mtc3Jj4oCdIGFzIGEgdG9rZW4uIFRoYXTigJlzIG5vdCBjbGVhcmx5IHNwZWNp ZmllZC4gV0lsbCB0aGVyZSBiZSBhIHJlZ2lzdHJ5IGZvciDigJx0b2tlbnPigJ0/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkkgYW0gYWZyYWlkIHRoYXQgdGhpcyBpcyBhbiBvcGVuaW5nIGZvciBwcml2 YXRlIHRva2VucyB0aGF0IGhpbmRlcnMgaW50ZXJvcGVyYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIOKAnFByaXZhY3kgY29uc2lkZXJh dGlvbnPigJ0gLSBzaG91bGQgeW91IG5vdCBkaXNjdXNzIHdoYXQgaGFwcGVucyB3aXRoIG15IHBy aXZhY3kgaWYgYW4gZW50aXR5IGluIHRoZSBuZXR3b3JrLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5i dXQgbm90IG15IHBob25lLCBhZGRzIGEgbG9jYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiDigJxzZWN1cml0eSBjb25zaWRlcmF0aW9uc+KA nSB0aGVyZeKAmXMgYSBkaXNjdXNzaW9uIGFib3V0IGEg4oCcdHJ1c3RlZCBuZXR3b3Jr4oCdIC0g YnV0IHRoYXQgaXMgbm90IGRlZmluZWQuIFdoYXQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YSB0 cnVzdGVkIG5ldHdvcms/IFRoZXJl4oCZcyBubyBtZW50aW9uIG9uIGhvdyB0byBhcHBseSB0cnVz dCwgcHJpdmFjeSwgY29uZmlkZW50aWFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgaXMgYSB0eXBvIGFzIHdlbGw6ICZxdW90Ozwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPndoZW4gcGFzc2Vk IHRvIGFuIG90aGVyIGRvbWFpbi7igJ0gJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnMvYW4gb3RoZXIv YW5vdGhlci88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNoZWVy cyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4vTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVA aWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LEXPR01MB04942F39269598DFBA385816F95A0LEXPR01MB0494DEUP_-- From nobody Fri Oct 27 05:31:58 2017 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 2BECE13F4CE for ; Fri, 27 Oct 2017 05:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYYzCuXwWufA for ; Fri, 27 Oct 2017 05:31:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 9C46F13B262 for ; Fri, 27 Oct 2017 05:31:55 -0700 (PDT) X-AuditID: c1b4fb25-dd3ff70000000c94-25-59f32739d887 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.BD.03220.93723F95; Fri, 27 Oct 2017 14:31:53 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Fri, 27 Oct 2017 14:31:53 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaZ+6AgAEJNoCAAAc9gIAAPEsggAAAZQCAHCFoAA== Date: Fri, 27 Oct 2017 12:31:52 +0000 Message-ID: References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> In-Reply-To: <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <0222A25A0BE88B478CD9E66AF255DB82@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7uq6l+udIgwl79CxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj9dsq5oJTfBWTd0xmb2A8yt3FyMkhIWAi sf37NrYuRi4OIYEjjBKNE46xQjiLGSXeb2sGynBwsAlYSHT/0wZpEBEIlLi6ZAIziC0sICfx uvMKK0RcXmL9zstMEHaYxPeZF5lBWlkEVCXad+aAhHkFrCWWX/3HDDH+MpPExtf9YL2cAg4S q2d9YQexGQXEJL6fWgM2h1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4H1ivqICexIYTt9kh4ooS O8+2M0P06kgs2P2JDcK2lvh2bT47hK0tsWzha2aIgwQlTs58wjKBUWwWknWzkLTPQtI+C0n7 LCTtCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtXBLb9VdzBefuN4iFGAg1GJhzdb 9HOkEGtiWXFl7iFGCQ5mJRHeHzxAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryO+y5ECAmkJ5ak ZqemFqQWwWSZODilGhjFprL0fa8417dqoacyx+a+gxdEmqf1m0gpG3wRnbdhy9+d7EoqvLxZ y54e+jtBTKFHT87bJ3iarGKUWDorMDwq+1TjC5dYO2lpl/f9Vjjg41Mv/MdFXEvoxu89EuuW cOS2t+ztsk4xbtVudnZSbHzhbPvK1/Pox9AktfKMZykWzMK/dtkpsRRnJBpqMRcVJwIAx8ci AKcCAAA= Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:31:57 -0000 Hi, >>>>>Yes, I understand that is the case you are thinking of. But I was >>>>> raising a different case: >>>>> >>>>> - the UAC sends an invite without a S-E. >>>>> - a proxy along the path includes an S-E. (The UAC is unaware.) >>>>> - later, the UAC sends an UPDATE with S-E. >>>>> >>>>> That violates the rule in your draft, but the UAC doesn't know it has >>>>> violated it. So your rule for avoiding the problem in this case >>>>> doesn't work. >>>> >>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I >>>> understand the proxy will never remove S-E from a response. So, we >>>> could say that the UAC must not send UPDATE with S-E until it has >>>> received a response to the INVITE. >>> >>> The problem is that the rfc only talks about the *final* (2xx) >>>response. >>> It has no provision for including the S-E in provisional responses. >>>(It doesn't mention provisional responses, and the Table 1 update in >>>section >>> 4 shows the intent is to exclude it. Hence, if the S-E is inserted >>>into the INVITE by a proxy, the UAC won't know that a session timer has >>>been requested until it receives the > final response to the invite. >>>Meanwhile it might decide send an UPDATE with S-E. >>=20 >> My suggestion is that the UAC would not be allowed to send UPDATE with >>S-E until it has received the final response for the INVITE. > >This is more or less the original proposal that was shot down. Or do you >mean that the *UAC* is restricted that way, but the *UAS* is permitted >to use S-E to negotiate session timer in the midst of the INVITE, at >least in some cases? I have been thinking about this, talked to some people etc, and perhaps the easiest solution would be to now allow UPDATE with S-E during an active INVITE transaction (as suggested above). Regards, Christer From nobody Fri Oct 27 07:47:46 2017 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 6B8CE13F54A for ; Fri, 27 Oct 2017 07:47:44 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pah0Qq-TrwTZ for ; Fri, 27 Oct 2017 07:47:42 -0700 (PDT) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF9413F516 for ; Fri, 27 Oct 2017 07:47:42 -0700 (PDT) X-AuditID: 1207440c-7e5ff7000000143e-a7-59f3470ba84b Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E7.96.05182.C0743F95; Fri, 27 Oct 2017 10:47:40 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9RElc7w023982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Oct 2017 10:47:38 -0400 To: "Jesske, Roland" , "sipcore@ietf.org" References: <150838463846.18684.496033948454208375.idtracker@ietfa.amsl.com> <29299_1509013511_59F1B807_29299_392_1_88CAD1D4E8773F42858B58CAA28272A02AF91BFE@OPEXCLILM23.corporate.adroot.infra.ftgroup> <0FA1051A-D2A5-4273-8AF3-B1C9E6543361@brianrosen.net> <728862D5-566F-4A2F-80E6-99F623046F36@edvina.net> <43d0afd7-1cc5-cc8c-ccdd-a87653503f90@alum.mit.edu> From: Paul Kyzivat Message-ID: <46dd9ddc-60dd-3dbd-1974-f638898ea68d@alum.mit.edu> Date: Fri, 27 Oct 2017 10:47:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixO6iqMvj/jnSoLXP0KLpThebxdcfm9gc mDyWLPnJ5NH2UiGAKYrLJiU1J7MstUjfLoErY27TDqaCY/wVz05tYWtg3M/TxcjBISFgInFs p0QXIyeHkMAOJon5a1W7GLmA7IdMErtOTWYFSQgLpEicPXGbGaReRCBK4s5ZbYj6CSwSk3aJ g9hsAloScw79ZwEp4RWwl9j2XgMkzCKgKrF09092EFtUIE3izoyHTCA2r4CgxMmZT1hAbE6B GImd81czgtjMAmYS8zY/ZIawxSVuPZnPBGHLSzRvnc08gZF/FpL2WUhaZiFpmYWkZQEjyypG ucSc0lzd3MTMnOLUZN3i5MS8vNQiXUO93MwSvdSU0k2MkADl2cH4bZ3MIUYBDkYlHt4Vmp8i hVgTy4orcw8xSnIwKYny7jsPFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC+8P6c6QQb0piZVVq UT5MSpqDRUmcV3WJup+QQHpiSWp2ampBahFMVoaDQ0mCt90NqFGwKDU9tSItM6cEIc3EwQky nAdo+GxXkOHFBYm5xZnpEPlTjMYcPT03/jBxPJv5uoFZiCUvPy9VSpxXFGScAEhpRmke3DRY knnFKA70nDAvH0gVDzBBwc17BbSKCWhVk+oHkFUliQgpqQZGMy+PC1+/sl+Ktq3abKp02T58 ujUP7ysnpxcO7Frmdypvv9g43dDgi4Ll0vxDfhFrrRwMpjYbe2hq7JQNm+Vl7flK4Uyx8753 LGEOJxkm/GTY6bal6ZT61k+aj9v+Tz9uvLo99M7548Xfd661bQkreBR+8fDv3e9frqpLj/yU vyNI79yaZeY1SizFGYmGWsxFxYkAfDSQeQ0DAAA= Archived-At: Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 14:47:44 -0000 On 10/27/17 4:22 AM, Jesske, Roland wrote: > Thank you for your comments. > We had the discussion a couple of weeks ago. > I had let in the token due to some comment. It was stated the ti would be good to have the possibility of extending the mechanism. > ETSI does only need only the loc-src. > So before opening Pandora's box I will delete the other-loc-src. OK, that solves the problems. If there is future need to convey location in some other form all you need to do is define another parameter for that. Thanks, Paul > Is this OK for everybody? > > Best regards > > Roland > >> -----UrsprĂĽngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat >> Gesendet: Donnerstag, 26. Oktober 2017 21:34 >> An: sipcore@ietf.org >> Betreff: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore- >> locparam-02.txt >> >> On 10/26/17 9:09 AM, Olle E. Johansson wrote: >>> Some quick comments to version -02: >>> >>> in section 4, you refer to “other-loc-src” as a token. That’s not >>> clearly specified. WIll there be a registry for “tokens”? >>> I am afraid that this is an opening for private tokens that hinders >>> interoperability. >> >> Agree. A simply way out of this is to leave use of this for future definition, so >> that, for now, it can't be used, but with default processing on reception being >> defined to ignore. >> >> There are other problems with this as well. >> >> Syntactically, 'token' isn't defined. I trust what is intended is 'token' as defined >> in 3261. If so that needs to be specified. >> >> But that presents a further problem - ambiguity. A token is a superset of >> hostname. There needs to be a way to distinguish an 'other-loc-src' >> from a hostname. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Oct 27 07:52:08 2017 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 CCF0813F579 for ; Fri, 27 Oct 2017 07:52:06 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH_DBcqUExvc for ; Fri, 27 Oct 2017 07:52:05 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id EC00F13F58B for ; Fri, 27 Oct 2017 07:51:56 -0700 (PDT) X-AuditID: 1207440d-853ff70000000f42-77-59f3480a5229 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 02.40.03906.A0843F95; Fri, 27 Oct 2017 10:51:55 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9REpqUd024308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Oct 2017 10:51:53 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 27 Oct 2017 10:51:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYndR1OX2+Bxp8OyTmsWFmYcZLb7+2MTm wOTx6+tVNo8lS34yBTBFcdmkpOZklqUW6dslcGXMmtnPVDBHoOLy4lPMDYwveboYOTkkBEwk ZqzuZOpi5OIQEtjBJLFgYx8bhPOQSWLeoXYWkCphATmJ151XWEFsEYE0iZ6J/ewQRa3MEptn f2IDSbAJaEnMOfQfrIFXwF5i1sozTCA2i4CqxM63V8HiokDNd2Y8ZIKoEZQ4OfMJWJxTwEZi +qvZ7CA2s4CZxLzND5khbHGJW0/mM0HY8hLb385hnsDIPwtJ+ywkLbOQtMxC0rKAkWUVo1xi Tmmubm5iZk5xarJucXJiXl5qka6RXm5miV5qSukmRkiw8u5g/L9O5hCjAAejEg/vCs1PkUKs iWXFlbmHGCU5mJREefedBwrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4f1h/TlSiDclsbIqtSgf JiXNwaIkzqu2RN1PSCA9sSQ1OzW1ILUIJivDwaEkwWvjDtQoWJSanlqRlplTgpBm4uAEGc4D NJwNpIa3uCAxtzgzHSJ/itGYo6fnxh8mjmczXzcwC7Hk5eelSonzGoCUCoCUZpTmwU2DJZxX jOJAzwnzOoBU8QCTFdy8V0CrmIBWNal+AFlVkoiQkmpgrDMvORjPq3yLz/H7l4AK00usHw7l JDy8fOvutZMxJ5Yyxd9KSI7JXfgtIEyvg/VKxU7l2GvzjgTfYea+kyXa1Xyqtm53fdO5OS65 rWwrP2pcFOmQEmXdY/zmgM7Xpdc3f/VbUv315xtrhtiLl3dMms7nruD19cC/iNpzWYvmHi0L fhV7I+zdJiWW4oxEQy3mouJEANVBoeITAwAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 14:52:07 -0000 On 10/27/17 8:31 AM, Christer Holmberg wrote: > Hi, > >>>>>> Yes, I understand that is the case you are thinking of. But I was >>>>>> raising a different case: >>>>>> >>>>>> - the UAC sends an invite without a S-E. >>>>>> - a proxy along the path includes an S-E. (The UAC is unaware.) >>>>>> - later, the UAC sends an UPDATE with S-E. >>>>>> >>>>>> That violates the rule in your draft, but the UAC doesn't know it has >>>>>> violated it. So your rule for avoiding the problem in this case >>>>>> doesn't work. >>>>> >>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I >>>>> understand the proxy will never remove S-E from a response. So, we >>>>> could say that the UAC must not send UPDATE with S-E until it has >>>>> received a response to the INVITE. >>>> >>>> The problem is that the rfc only talks about the *final* (2xx) >>>> response. >>>> It has no provision for including the S-E in provisional responses. >>>> (It doesn't mention provisional responses, and the Table 1 update in >>>> section >>>> 4 shows the intent is to exclude it. Hence, if the S-E is inserted >>>> into the INVITE by a proxy, the UAC won't know that a session timer has >>>> been requested until it receives the > final response to the invite. >>>> Meanwhile it might decide send an UPDATE with S-E. >>> >>> My suggestion is that the UAC would not be allowed to send UPDATE with >>> S-E until it has received the final response for the INVITE. >> >> This is more or less the original proposal that was shot down. Or do you >> mean that the *UAC* is restricted that way, but the *UAS* is permitted >> to use S-E to negotiate session timer in the midst of the INVITE, at >> least in some cases? > > I have been thinking about this, talked to some people etc, and perhaps > the easiest solution would be to now allow UPDATE with S-E during an > active INVITE transaction (as suggested above). I have now gotten lost in the propossals and counter proposals. Can you explicitly state what you are proposing? Thanks, Paul From nobody Fri Oct 27 09:05:42 2017 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 DE45713F63C for ; Fri, 27 Oct 2017 09:05:40 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt4m11kTV4Go for ; Fri, 27 Oct 2017 09:05:39 -0700 (PDT) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id B935F13F62C for ; Fri, 27 Oct 2017 09:05:39 -0700 (PDT) X-AuditID: 12074411-f95ff70000007f0a-58-59f3595211ee Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.D7.32522.25953F95; Fri, 27 Oct 2017 12:05:38 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9RG5b0F028306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 27 Oct 2017 12:05:38 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> Date: Fri, 27 Oct 2017 12:05:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 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-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqBsc+TnS4P9OFouvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+qDEywFJwUq3t//yNzA2MTTxcjJISFgInHo5QrmLkYuDiGB HUwSe09tZANJCAn8YJJoW8QMYgsLWEv8/bGXFcQWERCReDb9H1SNtUTD2RawGjYBLYk5h/6z gNi8AvYSix9NAathEVCV6FjfDhYXFUiTuDPjIRNEjaDEyZlPwOKcAjYSS9deA5vDLGArcWfu bihbXOLWk/lMELa8RPPW2cwTGPlnIWmfhaRlFpKWWUhaFjCyrGKUS8wpzdXNTczMKU5N1i1O TszLSy3SNdXLzSzRS00p3cQICUrBHYwzTsodYhTgYFTi4V2h+SlSiDWxrLgy9xCjJAeTkijv vvNAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8BhGfI4V4UxIrq1KL8mFS0hwsSuK8fEvU/YQE 0hNLUrNTUwtSi2CyMhwcShK8WSCNgkWp6akVaZk5JQhpJg5OkOE8QMMtwYYXFyTmFmemQ+RP MRpz9PTc+MPE8Wzm6wZmIZa8/LxUKXHeDJBSAZDSjNI8uGmwxPKKURzoOWHedSBVPMCkBDfv FdAqJqBVTaofQFaVJCKkpBoYua+V7r8RYMs99/trLb3H9cXVAtMOKs46m/wzd29u9m429R/C N1+JV985cezV5E7B99/uTr3QNmFyQHVf2xmhU03XzKbqG3KIbjlcEOm14yn3xDRRkcbFh3ed /+HqyZx8tKj93d9CB1Peo/Fcoc/u/GpNdPi/JGxPnpjnDonTu94paJw5Ibf3gRJLcUaioRZz UXEiACNUQXUHAwAA Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 16:05:41 -0000 On 10/27/17 2:53 AM, Christer Holmberg wrote: > Hi, > > I’ve submitted a new version (-01) of draft-holmberg-sipcore-sip-push. > > The new version contain more text, including the creation of an IANA > registry for pn-type values. The draft also adds two values to the new > registry: “apns” (Apple Push Notification service) and “fcm” (Firebase > Cloud Messaging). Thanks for adding the registry. I have a few other concerns: The parameters pn-enckey and pn-enccode appear in the syntax but have no semantics defined. That needs to be added. And then the use (or non-use) and form for each of pn-prid, pn-enckey, and pn-enccode for a particular pn-type ought to be specified in the pn-type registry, or in the document referenced from there. Why is it that there are four related parameters that are used in concert to provide pieces of the required information, and then pn-type has a two-part value? ISTM it would make more sense to either: 1) make the two parts of pn-type be separate parameters, uri-parameter =/ pn-type / pn-param /pn-prid / pn-enccode / pn-enckey pn-type = "pn-type" EQUAL pns-provider pn-param = "pn-param" EQUAL pns-param pn-prid = "pn-prid" EQUAL pvalue pn-enccode = "pn-enccode" EQUAL pvalue pn-enckey = "pn-enckey" EQUAL pvalue pns-provider = 1*alphanum pns-param = pvalue 2) OR else combine all of pns-param, pn-enckey value and pn-enccode value into a single parameter with detailed syntax defined on a per-pn-type basis, uri-parameter =/ pn-type / pn-value pn-type = "pn-type" EQUAL pns-provider pns-provider = 1*alphanum pn-value = "pn-value" EQUAL pvalue 3) OR it could even be made into a single parameter. uri-parameter =/ pn-param pn-param = "pn" EQUAL pns-provider COLON pn-value pns-provider = 1*alphanum pn-value = pvalue Of all those I prefer (3), but this is a matter of taste. Thanks, Paul From nobody Fri Oct 27 09:06:45 2017 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 E86EC13F649 for ; Fri, 27 Oct 2017 09:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otGAgF_vdf3L for ; Fri, 27 Oct 2017 09:06:39 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA1213F63C for ; Fri, 27 Oct 2017 09:06:38 -0700 (PDT) X-AuditID: c1b4fb2d-bddff7000000268d-49-59f3598c9850 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.28.09869.C8953F95; Fri, 27 Oct 2017 18:06:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Fri, 27 Oct 2017 18:06:35 +0200 From: Christer Holmberg To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaZ+6AgAEJNoCAAAc9gIAAPEsggAAAZQCAHCFoAP//8tUAgAAU2AA= Date: Fri, 27 Oct 2017 16:06:35 +0000 Message-ID: <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-1AF80FDC-9583-4607-80C0-D2EB68EEABB4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUyM2K7pW5P5OdIgysHDS1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjx9ROtoJz8xkrXnztYG5gvDGdsYuRk0NC wERictsepi5GLg4hgSOMEjfe3WeBcBYzSnx7u5i5i5GDg03AQqL7nzaIKSKgITFpqxpIL7OA psSjnXuZQGxhATmJ151XWEFsEQF5ifU7LzNB2EkSu5png+1iEVCV6P/9iQXE5hWwlzj28Dw7 xKrdzBJ75veBNXAKOEi8fbMUrIhRQEzi+6k1TBDLxCVuPZnPBHG0iMTDi6fZIGxRiZeP/7GC DGIWmMwo0bFnMdQGQYmTM5+wTGAUnoWkfxayullI6iCK4iWm/W6FsuUltr+dwzwL6GlmAR2J yQsZIcLaEssWvmaGsDUkOr9NZIWwFSWmdD9kh7CtJWb8OsgGYZtKvD76kRFZzQJGnlWMosWp xcW56UbGeqlFmcnFxfl5enmpJZsYgdF7cMtv3R2Mq187HmIU4GBU4uFNC/ocKcSaWFZcmXuI UQVozqMNqy8wSrHk5eelKonwGkQApXlTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQnliS mp2aWpBaBJNl4uCUamD0kw96etFlqeLj7MtFC8UmzDU+IJs9ZW3zmQmfjRoWBt+8fHX/Bu4T i+ZMecCROSl4X1hdXtfbt8mC22bkea1jY887euLViZ+7Zc5seGvSeSeWuWXCRrs8278Ke6Lk zQ0VHFxvsaUv2N91xUL5qMM+tyebrOeFXrNZP6k6U/xWvqGpnd7jmVz1SizFGYmGWsxFxYkA d0cf8eYCAAA= Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 16:06:43 -0000 --Apple-Mail-1AF80FDC-9583-4607-80C0-D2EB68EEABB4 Content-Type: multipart/alternative; boundary=Apple-Mail-CB87528D-B9FA-428F-B55C-1F0E716565F4 Content-Transfer-Encoding: 7bit --Apple-Mail-CB87528D-B9FA-428F-B55C-1F0E716565F4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I am proposing that it is not allowed to include S-E in an UPDATE while ther= e is an ongoing INVITE transaction. Regards, Christer=20 Sent from my iPhone > On 27 Oct 2017, at 17.51, Paul Kyzivat wrote: >=20 >> On 10/27/17 8:31 AM, Christer Holmberg wrote: >> Hi, >>>>>>> Yes, I understand that is the case you are thinking of. But I was >>>>>>> raising a different case: >>>>>>>=20 >>>>>>> - the UAC sends an invite without a S-E. >>>>>>> - a proxy along the path includes an S-E. (The UAC is unaware.) >>>>>>> - later, the UAC sends an UPDATE with S-E. >>>>>>>=20 >>>>>>> That violates the rule in your draft, but the UAC doesn't know it ha= s >>>>>>> violated it. So your rule for avoiding the problem in this case >>>>>>> doesn't work. >>>>>>=20 >>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I= >>>>>> understand the proxy will never remove S-E from a response. So, we >>>>>> could say that the UAC must not send UPDATE with S-E until it has >>>>>> received a response to the INVITE. >>>>>=20 >>>>> The problem is that the rfc only talks about the *final* (2xx) >>>>> response. >>>>> It has no provision for including the S-E in provisional responses. >>>>> (It doesn't mention provisional responses, and the Table 1 update in >>>>> section >>>>> 4 shows the intent is to exclude it. Hence, if the S-E is inserted >>>>> into the INVITE by a proxy, the UAC won't know that a session timer ha= s >>>>> been requested until it receives the > final response to the invite. >>>>> Meanwhile it might decide send an UPDATE with S-E. >>>>=20 >>>> My suggestion is that the UAC would not be allowed to send UPDATE with >>>> S-E until it has received the final response for the INVITE. >>>=20 >>> This is more or less the original proposal that was shot down. Or do you= >>> mean that the *UAC* is restricted that way, but the *UAS* is permitted >>> to use S-E to negotiate session timer in the midst of the INVITE, at >>> least in some cases? >> I have been thinking about this, talked to some people etc, and perhaps >> the easiest solution would be to now allow UPDATE with S-E during an >> active INVITE transaction (as suggested above). >=20 > I have now gotten lost in the propossals and counter proposals. Can you ex= plicitly state what you are proposing? >=20 > Thanks, > Paul --Apple-Mail-CB87528D-B9FA-428F-B55C-1F0E716565F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpLDxkaXY+PGJy PjwvZGl2PjxkaXY+SSBhbSBwcm9wb3NpbmcgdGhhdCBpdCBpcyBub3QgYWxsb3dlZCB0byBpbmNs dWRlIFMtRSBpbiBhbiBVUERBVEUgd2hpbGUgdGhlcmUgaXMgYW4gb25nb2luZyBJTlZJVEUgdHJh bnNhY3Rpb24uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5SZWdhcmRzLDwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+Q2hyaXN0ZXImbmJzcDs8YnI+PGJyPjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h dHVyZSI+U2VudCBmcm9tIG15IGlQaG9uZTwvZGl2PjxkaXY+PGJyPk9uIDI3IE9jdCAyMDE3LCBh dCAxNy41MSwgUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5t aXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2 PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+T24gMTAvMjcvMTcgODozMSBBTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6PC9zcGFuPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj5IaSw8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48c3Bhbj5ZZXMsIEkgdW5kZXJzdGFuZCB0aGF0IGlzIHRoZSBjYXNlIHlvdSBhcmUg dGhpbmtpbmcgb2YuIEJ1dCBJIHdhczwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90 ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+cmFpc2luZyBhIGRpZmZlcmVudCBjYXNl Ojwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9j a3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4tIHRoZSBVQUMgc2VuZHMgYW4gaW52aXRlIHdpdGhvdXQg YSBTLUUuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48 L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48c3Bhbj4tIGEgcHJveHkgYWxvbmcgdGhlIHBhdGggaW5jbHVkZXMgYW4gUy1F LiAoVGhlIFVBQyBpcyB1bmF3YXJlLik8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0gbGF0ZXIsIHRoZSBVQUMgc2VuZHMg YW4gVVBEQVRFIHdpdGggUy1FLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48 L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9i bG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGF0IHZpb2xhdGVzIHRo ZSBydWxlIGluIHlvdXIgZHJhZnQsIGJ1dCB0aGUgVUFDIGRvZXNuJ3Qga25vdyBpdCBoYXM8L3Nw YW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90 ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPnZpb2xhdGVkIGl0LiBTbyB5b3VyIHJ1bGUgZm9yIGF2b2lkaW5nIHRoZSBwcm9ibGVt IGluIHRoaXMgY2FzZTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ZG9lc24ndCB3b3JrLjwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1 b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlNl Y3Rpb24gOC4yIGluIHRoZSBSRkMgaXMgKGluIG15IG9waW5vbikgcXVpdGUgbWVzc3ksIGJ1dCBh cyBmYXIgYXMgSTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj51bmRlcnN0YW5kIHRoZSBw cm94eSB3aWxsIG5ldmVyIHJlbW92ZSBTLUUgZnJvbSBhIHJlc3BvbnNlLiBTbywgd2U8L3NwYW4+ PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Y291bGQgc2F5IHRoYXQgdGhlIFVBQyBtdXN0IG5vdCBz ZW5kIFVQREFURSB3aXRoIFMtRSB1bnRpbCBpdCBoYXM8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48 L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHNwYW4+cmVjZWl2ZWQgYSByZXNwb25zZSB0byB0aGUgSU5WSVRFLjwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGUgcHJvYmxlbSBpcyB0 aGF0IHRoZSByZmMgb25seSB0YWxrcyBhYm91dCB0aGUgKmZpbmFsKiAoMnh4KTwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPnJlc3BvbnNlLjwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkl0IGhhcyBubyBwcm92 aXNpb24gZm9yIGluY2x1ZGluZyB0aGUgUy1FIGluIHByb3Zpc2lvbmFsIHJlc3BvbnNlcy48L3Nw YW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4oSXQgZG9lc24n dCBtZW50aW9uIHByb3Zpc2lvbmFsIHJlc3BvbnNlcywgYW5kIHRoZSBUYWJsZSAxIHVwZGF0ZSBp bjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPnNlY3Rp b248L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj40IHNo b3dzIHRoZSBpbnRlbnQgaXMgdG8gZXhjbHVkZSBpdC4gSGVuY2UsIGlmIHRoZSBTLUUgaXMgaW5z ZXJ0ZWQ8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5p bnRvIHRoZSBJTlZJVEUgYnkgYSBwcm94eSwgdGhlIFVBQyB3b24ndCBrbm93IHRoYXQgYSBzZXNz aW9uIHRpbWVyIGhhczwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPmJlZW4gcmVxdWVzdGVkIHVudGlsIGl0IHJlY2VpdmVzIHRoZSAmZ3Q7IGZpbmFsIHJl c3BvbnNlIHRvIHRoZSBpbnZpdGUuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+TWVhbndoaWxlIGl0IG1pZ2h0IGRlY2lkZSBzZW5kIGFuIFVQREFURSB3 aXRoIFMtRS48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90 ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk15IHN1Z2dl c3Rpb24gaXMgdGhhdCB0aGUgVUFDIHdvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIHNlbmQgVVBEQVRF IHdpdGg8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPlMtRSB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgdGhlIGZpbmFsIHJl c3BvbnNlIGZvciB0aGUgSU5WSVRFLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90 ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlRoaXMgaXMgbW9y ZSBvciBsZXNzIHRoZSBvcmlnaW5hbCBwcm9wb3NhbCB0aGF0IHdhcyBzaG90IGRvd24uIE9yIGRv IHlvdTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5tZWFuIHRoYXQgdGhlICpVQUMq IGlzIHJlc3RyaWN0ZWQgdGhhdCB3YXksIGJ1dCB0aGUgKlVBUyogaXMgcGVybWl0dGVkPC9zcGFu Pjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPnRvIHVzZSBTLUUgdG8gbmVnb3RpYXRlIHNlc3Np b24gdGltZXIgaW4gdGhlIG1pZHN0IG9mIHRoZSBJTlZJVEUsIGF0PC9zcGFuPjxicj48L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPmxlYXN0IGluIHNvbWUgY2FzZXM/PC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkkgaGF2ZSBiZWVu IHRoaW5raW5nIGFib3V0IHRoaXMsIHRhbGtlZCB0byBzb21lIHBlb3BsZSBldGMsIGFuZCBwZXJo YXBzPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ dGhlIGVhc2llc3Qgc29sdXRpb24gd291bGQgYmUgdG8gbm93IGFsbG93IFVQREFURSB3aXRoIFMt RSBkdXJpbmcgYW48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj5hY3RpdmUgSU5WSVRFIHRyYW5zYWN0aW9uIChhcyBzdWdnZXN0ZWQgYWJvdmUpLjwv c3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+SSBoYXZlIG5vdyBn b3R0ZW4gbG9zdCBpbiB0aGUgcHJvcG9zc2FscyBhbmQgY291bnRlciBwcm9wb3NhbHMuIENhbiB5 b3UgZXhwbGljaXRseSBzdGF0ZSB3aGF0IHlvdSBhcmUgcHJvcG9zaW5nPzwvc3Bhbj48YnI+PHNw YW4+PC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7ICZuYnNwO1RoYW5rcyw8L3NwYW4+PGJyPjxzcGFu PiAmbmJzcDsgJm5ic3A7UGF1bDwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjwv Ym9keT48L2h0bWw+ --Apple-Mail-CB87528D-B9FA-428F-B55C-1F0E716565F4-- --Apple-Mail-1AF80FDC-9583-4607-80C0-D2EB68EEABB4 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBfkw ggPhoAMCAQICEDENcj3BkzWA84WFoa5BUMgwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMTA0MTIy ODE5WhcNMTcxMTA0MTIyODE4WjBvMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0 ZXIgSG9sbWJlcmcxLTArBgkqhkiG9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTEPMA0GA1UEBRMGTE1GQ0hIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjG+3x1iF fQiBWGKL/OjUf+om3VVdCPmalSxNtc0Ae6LRb+g0ypVVxO4oguBwrzIZRpIN/6hZgIQLYuWdWe/u XhDBCD+SSRGe3zJugTBN9wZHYIOBHya6uBVBtvB8Nv/9Ksd42Vrytlu+dQJhLlCeZ5GehdNBp8yZ joW73mnQvBOZHqsKMPa4mtP1msx4it8Mc422p6EGmSAPqAio+WMgr/HAk2kpOKRAG18MbYSfewWm T2obJ2+BGRD9PIMUeSBPTUYuOxKoei7QY4lqWgeNhJghAcXNriEPO7ZSdHtkrwqO+K6sZ3V7VHml mrjI47eA54SXYl2WNuOA+SdYFrLERQIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgG CCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRp dmlkdWFsY2F2Mi5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjAdBgNVHQ4EFgQUVKNN/w60QFtsaTJoTdrhpLw4MeowHwYDVR0jBBgwFoAUsQ3K1Ea3r4YC wy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQC28KhuYp4Zf8T8 bLkFnB+xjlGSDwMNCZSpbVUP05bBe4oNCdYss2qOhrFyLSfR91mT6wsuREHISZu6nJ9pCl/Dhm/m K+dxYrC0doMfqpK0DAznYsfVmrNHLyIw1owEJxGW8c/2vnc3QD9E68Dbw/NvNmyMtHwrf97qAX8z J70BvuMBtNfGw7p3PjQo9RZEipEkW/Xz9mdpYuuaXyXMbRiH2+c7FyWRuBrW3tP4cZY9zXHIwf81 Tzuz0PpZ1psbToiUNpaAPutr0K3lEK99vFyuCBxZ6FPs14lX1Ddrq774q0B+x2u9EwTGttCfDZ9m hL2OkGDBECYQIlZjU4r+BBhr+YXl+b2/Mmo+6a+GCL2+g9K/qcKb3xBPGIQBFiYAmT+5Oc0MIa6b khf7PsBK7l6OfbKvWzgnn4IZLXOX8A7vL3nffHIn0T1J7k/3ObJSSfC4xZ/Hfi5xpJVHRQPZC4yC VVcfkzOA/zk2kRvpjxW2NqU8kdFfODxuxy3pLqTbBc3JnuyAZEPtc5G/YY8+qcoqHX+q4e6YfvFx 1jYM2wuT3RggDYPH1Vq8aqjqBM73FHDzMul1ybNCVoVmrPJiXR6tpBgwxKQOwWwWrZrRKs4l0Z2B iXkCt3jA117ZjngUgOMu2GeO8vgsb25J0kOXcoIcJBKvmuzkTxlY7I7ViWCenTCCBrYwggSeoAMC AQICEQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29u ZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0 MDUyNzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+J OOqjddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2a vWWXhPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvM iZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtk dldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1 EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3W AEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJ DxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiA SHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCC AbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFz b25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbK DnZxf0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4IC AQBuByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9 IewyaV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYV Cd+xhsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1 qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhG WHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qh tu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVw GB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP 4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TG bTGCApYwggKSAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjICEDENcj3BkzWA84WFoa5BUMgwCQYFKw4DAhoFAKCCAR0wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDI3MTYwNjI4WjAjBgkqhkiG 9w0BCQQxFgQUyl/UUU6Sa6SK2hqAQCO9JpJ8MpowXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGT NYDzhYWhrkFQyDBfBgsqhkiG9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEDENcj3BkzWA84WFoa5BUMgwDQYJKoZI hvcNAQEBBQAEggEAfpAqd/WBCuG2LfFIKz9b3OekjeEZ2s21tSXl5uZqr5hK04cOSNobjlDIuDsw /je44hFJi0P5AVxMFcyxAQ+X0Alj0pjpvp1fftLncB1/XN1HvBIpEPx+bBiu6GP9ZjZEG4K4EeSZ hBy5gZGgJnWHHn/ayJg/xJeEYTH9C7rtLLYtLRlR6Vc/8EXIn1ybL4fpCGHnyFVeIuIg6F4SA2OB tDbobkTCizMdSSAOLunBsMCRe6/PvHSSr7Zibg/4xbZ8AzTzsCpA5Bk1BwXQGwdFLy8p3Hdlmvmw bicW8+JqkACndsgKyfoXRyPPf+fZCHXDLEcnPCRkLsB6d4x84sqamAAAAAAAAA== --Apple-Mail-1AF80FDC-9583-4607-80C0-D2EB68EEABB4-- From nobody Fri Oct 27 10:15:47 2017 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 86C141384B5 for ; Fri, 27 Oct 2017 10:15:46 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKwq2i_zwouk for ; Fri, 27 Oct 2017 10:15:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A2213A0AA for ; Fri, 27 Oct 2017 10:15:43 -0700 (PDT) X-AuditID: c1b4fb3a-dffff70000006897-cc-59f369bd77cf Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 82.62.26775.DB963F95; Fri, 27 Oct 2017 19:15:42 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Fri, 27 Oct 2017 19:15:41 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-sip-push-01 Thread-Index: AQHTTvBHLyywS3X2LE6SM4z0ppMbCKL3u3OAgAAue9A= Date: Fri, 27 Oct 2017 17:15:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C671DA8@ESESSMB109.ericsson.se> References: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> In-Reply-To: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7pe6+zM+RBqvNLFZsOMBq8fXHJjYH Jo+/7z8weSxZ8pMpgCmKyyYlNSezLLVI3y6BK+PztsfsBeslKia3zGFpYFwl1MXIySEhYCJx r28TYxcjF4eQwBFGiYNbD7JAOIsZJV5dnc7axcjBwSZgIdH9TxukQUQgUOLqkgnMILawgLXE jY7zbCAlIgI2Eh/eM0OUWEk8OHKHHcRmEVCVOHxrLyuIzSvgK7H96yWwGiGBQokHHR/A4pwC DhKLGr6DxRkFxCS+n1rDBGIzC4hL3HoynwniTgGJJXvOM0PYohIvH/9jhbCVJBbd/gxVryOx YPcnNghbW2LZwtfMEHsFJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWMosWpxcW56UZGeqlF mcnFxfl5enmpJZsYgbFwcMtvqx2MB587HmIU4GBU4uGdHvQ5Uog1say4MvcQowQHs5II755E oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNLUrNTUwtSi2CyTBycUg2MCV/TJq8X ETYr/pvMde/XRxlVlzMrdy69HhS3a2pcns4+beWJ799czPvSMbl/yz/3s1LmuWqPeX5zMK/r Oit7pYH95/u5vz5fWr6pt0Hl87GnmtbmBc6zz55MP/BPXmMfx9/65fs1vrrdysgo1GP40C7o 9vP8PzuVBy83/JoobzX3cM6W5Y8nfVNiKc5INNRiLipOBAAKwZi6gQIAAA== Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:15:46 -0000 Hi, >> I've submitted a new version (-01) of draft-holmberg-sipcore-sip-push. >>=20 >> The new version contain more text, including the creation of an IANA=20 >> registry for pn-type values. The draft also adds two values to the new >> registry: "apns" (Apple Push Notification service) and "fcm" (Firebase=20 >> Cloud Messaging). > > Thanks for adding the registry. > > I have a few other concerns: > > The parameters pn-enckey and pn-enccode appear in the syntax but have no = semantics defined. That needs to be added. pn-enckey and pn-enccode are not needed by the push notification service me= chanism as such, and are therefore independent of the pn-type.=20 Section 4 says: "The pn-enckey URI parameter contains the public key, and the pn-encsec URI= parameter contains the authentication secret [I-D.ietf-webpush-encryption]= ." But, they may not be feasible in all cases, if e.g., the payload contains i= nformation that needs to be accessible by the push notification server, so = it would be good to mention that. > And then the use (or non-use) and form for each of pn-prid, pn-enckey, an= d pn-enccode for a particular pn-type ought > to be specified in the pn-type registry, or in the document referenced fr= om there. Sections 8 and 9 do define the use and form for pn-prid and pn-type for "ap= ns" and "fcm".=20 But, I realize there is no text saying it has to be done, so it needs to be= added. The idea is that it has to be specified in the referenced document. >Why is it that there are four related parameters that are used in concert = to provide pieces of the required information, and=20 >then pn-type has a two-part value? ISTM it would make more sense to either= : > > 1) make the two parts of pn-type be separate parameters, > > uri-parameter =3D/ pn-type / pn-param /pn-prid > / pn-enccode / pn-enckey > pn-type =3D "pn-type" EQUAL pns-provider > pn-param =3D "pn-param" EQUAL pns-param > pn-prid =3D "pn-prid" EQUAL pvalue > pn-enccode =3D "pn-enccode" EQUAL pvalue > pn-enckey =3D "pn-enckey" EQUAL pvalue > > pns-provider =3D 1*alphanum > pns-param =3D pvalue > > 2) OR else combine all of pns-param, pn-enckey value and pn-enccode value= into a single parameter with detailed syntax defined on a per-pn-type basi= s, > > uri-parameter =3D/ pn-type / pn-value > pn-type =3D "pn-type" EQUAL pns-provider > pns-provider =3D 1*alphanum > pn-value =3D "pn-value" EQUAL pvalue > > 3) OR it could even be made into a single parameter. > > uri-parameter =3D/ pn-param > pn-param =3D "pn" EQUAL pns-provider COLON pn-value > pns-provider =3D 1*alphanum > pn-value =3D pvalue > > Of all those I prefer (3), but this is a matter of taste. Isn't 3) more or less identical to the current syntax? The only difference = is that the encoded value of the parameter name is "pn" instead of "pn-type= ". Regards, Christer From nobody Fri Oct 27 12:34:53 2017 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 C5D62139612 for ; Fri, 27 Oct 2017 12:34:51 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4M_s6skCNbz for ; Fri, 27 Oct 2017 12:34:50 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 026EA13942C for ; Fri, 27 Oct 2017 12:34:49 -0700 (PDT) X-AuditID: 1207440d-853ff70000000f42-c7-59f38a57cbc0 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B5.8B.03906.75A83F95; Fri, 27 Oct 2017 15:34:48 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9RJYj2N008064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Oct 2017 15:34:46 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C671DA8@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <97385a1f-45f8-d81d-a56b-c1851ed33fbb@alum.mit.edu> Date: Fri, 27 Oct 2017 15:34:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C671DA8@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixO6iqBvR9TnS4MJNSYsLMw8zWnz9sYnN gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4O1mm4KB0RfPBDcwNjHdFuhg5OSQETCTe nTnJ3sXIxSEksINJ4sqS46wgCSGBh0wS3/t8QGxhAWuJvz/2gsVFBNIkeib2QzVsZZS4e+kC O0iCTUBLYs6h/ywgNq+AvcSHnQ/YQGwWAVWJ109WgzWLAjXfmfGQCaJGUOLkzCdg9ZwCfhKn 7p0AizMLmEnM2/yQGcIWl7j1ZD5UXF5i+9s5zBMY+WchaZ+FpGUWkpZZSFoWMLKsYpRLzCnN 1c1NzMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAgJVN4djP/XyRxiFOBgVOLhlcj9HCnEmlhW XJl7iFGSg0lJlHff+U+RQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4L+QDlfOmJFZWpRblw6Sk OViUxHnVlqj7CQmkJ5akZqemFqQWwWRlODiUJHjPdAI1ChalpqdWpGXmlCCkmTg4QYbzAA0v AanhLS5IzC3OTIfIn2I05ujpufGHiePZzNcNzEIsefl5qVLivJNASgVASjNK8+CmwZLNK0Zx oOeEeatBqniAiQpu3iugVUxAq5pUP4CsKklESEk1MDqmH2soETcy6tbZvUxSyWe1wbOrC8QK mS5d1+l2drtcd1my4URpXdaEXXbMlmUd/LXHE83Cjita9y79V+5x/3aN4ouWoq1Hr0QxuuTN LY2TaFQVYS4Se+e8fvV2lSQzS66d+uVzZGXUZOdIlL+xT00RKdKs/lUieeGPd8syv5WHZ+R3 PWFTYinOSDTUYi4qTgQA2U70BhEDAAA= Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 19:34:52 -0000 On 10/27/17 1:15 PM, Christer Holmberg wrote: > Hi, > >>> I've submitted a new version (-01) of draft-holmberg-sipcore-sip-push. >>> >>> The new version contain more text, including the creation of an IANA >>> registry for pn-type values. The draft also adds two values to the new >>> registry: "apns" (Apple Push Notification service) and "fcm" (Firebase >>> Cloud Messaging). >> >> Thanks for adding the registry. >> >> I have a few other concerns: >> >> The parameters pn-enckey and pn-enccode appear in the syntax but have no semantics defined. That needs to be added. > > pn-enckey and pn-enccode are not needed by the push notification service mechanism as such, and are therefore independent of the pn-type. > > Section 4 says: > > "The pn-enckey URI parameter contains the public key, and the pn-encsec URI parameter contains the authentication secret [I-D.ietf-webpush-encryption]." > > But, they may not be feasible in all cases, if e.g., the payload contains information that needs to be accessible by the push notification server, so it would be good to mention that. > >> And then the use (or non-use) and form for each of pn-prid, pn-enckey, and pn-enccode for a particular pn-type ought >> to be specified in the pn-type registry, or in the document referenced from there. > > Sections 8 and 9 do define the use and form for pn-prid and pn-type for "apns" and "fcm". > > But, I realize there is no text saying it has to be done, so it needs to be added. The idea is that it has to be specified in the referenced document. Just a few words about what the document must include should do the trick. >> Why is it that there are four related parameters that are used in concert to provide pieces of the required information, and >> then pn-type has a two-part value? ISTM it would make more sense to either: >> >> 1) make the two parts of pn-type be separate parameters, >> >> uri-parameter =/ pn-type / pn-param /pn-prid >> / pn-enccode / pn-enckey >> pn-type = "pn-type" EQUAL pns-provider >> pn-param = "pn-param" EQUAL pns-param >> pn-prid = "pn-prid" EQUAL pvalue >> pn-enccode = "pn-enccode" EQUAL pvalue >> pn-enckey = "pn-enckey" EQUAL pvalue >> >> pns-provider = 1*alphanum >> pns-param = pvalue >> >> 2) OR else combine all of pns-param, pn-enckey value and pn-enccode value into a single parameter with detailed syntax defined on a per-pn-type basis, >> >> uri-parameter =/ pn-type / pn-value >> pn-type = "pn-type" EQUAL pns-provider >> pns-provider = 1*alphanum >> pn-value = "pn-value" EQUAL pvalue >> >> 3) OR it could even be made into a single parameter. >> >> uri-parameter =/ pn-param >> pn-param = "pn" EQUAL pns-provider COLON pn-value >> pns-provider = 1*alphanum >> pn-value = pvalue >> >> Of all those I prefer (3), but this is a matter of taste. > > Isn't 3) more or less identical to the current syntax? The only difference is that the encoded value of the parameter name is "pn" instead of "pn-type". No, because it is assuming that pn-value includes all the information that the other syntaxes include in all the other parameters. The form for packing whatever it is into the value would be specified by the document for the provider. Thanks, Paul > Regards, > > Christer > > From nobody Fri Oct 27 12:41:27 2017 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 98182137E0B for ; Fri, 27 Oct 2017 12:41:26 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl2gPZh2hcHK for ; Fri, 27 Oct 2017 12:41:24 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id BC69513942C for ; Fri, 27 Oct 2017 12:41:24 -0700 (PDT) X-AuditID: 12074413-3a3ff70000007929-bb-59f38be36ff1 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id B6.FB.31017.4EB83F95; Fri, 27 Oct 2017 15:41:24 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9RJfMnN008430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Oct 2017 15:41:23 -0400 To: Christer Holmberg Cc: "sipcore@ietf.org" References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> From: Paul Kyzivat Message-ID: Date: Fri, 27 Oct 2017 15:41:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixO6iqPuk+3OkwZz37BYXZh5mtPj6YxOb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJUxe/IMtoK7ohWzF19mb2CcLdjFyMkhIWAi sebxI9YuRi4OIYEdTBI7Nj6Ech4ySTw8BeJwcggLyEm87rwCZosImElc/9zLBGIzC2hKbF53 gR2i4SOzRPvji2wgCTYBLYk5h/6zgNi8AvYSz2bPB2tgEVCVmHNrA5gtKpAmcWfGQyaIGkGJ kzOfANVzcHAKOEisfAE130xi3uaHzBC2uMStJ/Oh4vISzVtnM09gFJiFpHsWkpZZSFpmIWlZ wMiyilEuMac0Vzc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyMkhIV3MO46KXeIUYCDUYmH VyL3c6QQa2JZcWXuIUZJDiYlUd595z9FCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhvZAPVM6b klhZlVqUD5OS5mBREudVW6LuJySQnliSmp2aWpBaBJOV4eBQkuDVAcaqkGBRanpqRVpmTglC momDE2Q4D9Dw+V0gw4sLEnOLM9Mh8qcYLTl6em78YeJYd/oekHw283UDsxBLXn5eqpQ4LyfI UAGQhozSPLiZsJT0ilEc6EVh3tkgY3mA6Qxu6iughUxAC5tUP4AsLElESEk1MOo8X/DtmfSa 0Lv6KXkT9rQFMgvVO5xfZWwX2LswQojh2rsLegECirdPn2ssevxfOUz6uO4Zz2e21xd4zr1b aPdi69aAwFlyRz7p+4bl/0uewhE1g8E3Mv+qWZFOxI+sA/znwn7p7X0lObPX2e6FZFGX3K/O 5Od9Ds26j9bbyYt/+XRL7r3nHiWW4oxEQy3mouJEAGmmI3gkAwAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 19:41:26 -0000 On 10/27/17 12:06 PM, Christer Holmberg wrote: > Hi, > > I am proposing that it is not allowed to include S-E in an UPDATE while > there is an ongoing INVITE transaction. I think that is a good solution as long as we can resolve any backward compatibility issues with existing deployments. I gather we have one, but it is what identified the problem and so it needs to change anyway. Thanks, Paul > Regards, > > Christer > > Sent from my iPhone > > On 27 Oct 2017, at 17.51, Paul Kyzivat > wrote: > >> On 10/27/17 8:31 AM, Christer Holmberg wrote: >>> Hi, >>>>>>>> Yes, I understand that is the case you are thinking of. But I was >>>>>>>> raising a different case: >>>>>>>> >>>>>>>> - the UAC sends an invite without a S-E. >>>>>>>> - a proxy along the path includes an S-E. (The UAC is unaware.) >>>>>>>> - later, the UAC sends an UPDATE with S-E. >>>>>>>> >>>>>>>> That violates the rule in your draft, but the UAC doesn't know >>>>>>>> it has >>>>>>>> violated it. So your rule for avoiding the problem in this case >>>>>>>> doesn't work. >>>>>>> >>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I >>>>>>> understand the proxy will never remove S-E from a response. So, we >>>>>>> could say that the UAC must not send UPDATE with S-E until it has >>>>>>> received a response to the INVITE. >>>>>> >>>>>> The problem is that the rfc only talks about the *final* (2xx) >>>>>> response. >>>>>> It has no provision for including the S-E in provisional responses. >>>>>> (It doesn't mention provisional responses, and the Table 1 update in >>>>>> section >>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is inserted >>>>>> into the INVITE by a proxy, the UAC won't know that a session >>>>>> timer has >>>>>> been requested until it receives the > final response to the invite. >>>>>> Meanwhile it might decide send an UPDATE with S-E. >>>>> >>>>> My suggestion is that the UAC would not be allowed to send UPDATE with >>>>> S-E until it has received the final response for the INVITE. >>>> >>>> This is more or less the original proposal that was shot down. Or do you >>>> mean that the *UAC* is restricted that way, but the *UAS* is permitted >>>> to use S-E to negotiate session timer in the midst of the INVITE, at >>>> least in some cases? >>> I have been thinking about this, talked to some people etc, and perhaps >>> the easiest solution would be to now allow UPDATE with S-E during an >>> active INVITE transaction (as suggested above). >> >> I have now gotten lost in the propossals and counter proposals. Can >> you explicitly state what you are proposing? >> >>    Thanks, >>    Paul From nobody Sat Oct 28 01:30:58 2017 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 35526139507 for ; Sat, 28 Oct 2017 01:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW4Cm_jLzukp for ; Sat, 28 Oct 2017 01:30:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC378139982 for ; Sat, 28 Oct 2017 01:30:54 -0700 (PDT) X-AuditID: c1b4fb2d-bddff7000000268d-c2-59f4403ca89c Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.98.09869.C3044F95; Sat, 28 Oct 2017 10:30:52 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Sat, 28 Oct 2017 10:30:52 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-sip-push-01 Thread-Index: AQHTTvBHLyywS3X2LE6SM4z0ppMbCKL3u3OAgAAue9CAAAvzgIAA+VQA Date: Sat, 28 Oct 2017 08:30:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C674993@ESESSMB109.ericsson.se> References: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C671DA8@ESESSMB109.ericsson.se> <97385a1f-45f8-d81d-a56b-c1851ed33fbb@alum.mit.edu> In-Reply-To: <97385a1f-45f8-d81d-a56b-c1851ed33fbb@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7hK6Nw5dIgzPn9SxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj++snjAVdUhXT+n0bGLdIdjFyckgImEgs OL6XpYuRi0NI4AijxLM7vYwQzmJGiZO3DwM5HBxsAhYS3f+0QRpEBAIlri6ZwAxiCwtYS9zo OM8GUiIiYCPx4T0zRImbxLzFu8BsFgFViXkPtrOD2LwCvhIzt72G2vWaUeLc4kYmkASngIPE i8kfwRoYBcQkvp9aAxZnFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSazYfgnsTGYBTYn1 u/QhWhUlpnQ/hNorKHFy5hOWCYwis5BMnYXQMQtJxywkHQsYWVYxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBEbCwS2/dXcwrn7teIhRgINRiYd3neqXSCHWxLLiytxDjBIczEoivLvtgEK8 KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUwTo1lSA2sOfP+ wrbCJ/aHFE9VLM/apRqe0h7yT7u8triauW7Cm8Y83yW746PCpU/yd+dcUfyx0+ti/V4ZnZxu 0+Z5qvP5lrCfiQ5P9VZ/aZWxd9mnzfrWf8N27l/+duouuW8MHBWP1T8svxe0VjLlYwnj7qdO nB/Ndt+bu0llz8XgJaYxlR//KLEUZyQaajEXFScCAO/dTtyAAgAA Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 08:30:56 -0000 SGksDQoNCi4uLg0KDQo+Pj4gV2h5IGlzIGl0IHRoYXQgdGhlcmUgYXJlIGZvdXIgcmVsYXRlZCBw YXJhbWV0ZXJzIHRoYXQgYXJlIHVzZWQgaW4gDQo+Pj4gY29uY2VydCB0byBwcm92aWRlIHBpZWNl cyBvZiB0aGUgcmVxdWlyZWQgaW5mb3JtYXRpb24sIGFuZCB0aGVuIHBuLXR5cGUgaGFzIGEgdHdv LXBhcnQgdmFsdWU/IElTVE0gaXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIHRvIGVpdGhlcjoNCj4+ Pg0KPj4+IDEpIG1ha2UgdGhlIHR3byBwYXJ0cyBvZiBwbi10eXBlIGJlIHNlcGFyYXRlIHBhcmFt ZXRlcnMsDQo+Pj4NCj4+PiAgICAgICB1cmktcGFyYW1ldGVyICAgPS8gcG4tdHlwZSAvIHBuLXBh cmFtIC9wbi1wcmlkDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAvIHBuLWVuY2NvZGUgLyBw bi1lbmNrZXkNCj4+PiAgICAgICBwbi10eXBlICAgICAgICAgPSAicG4tdHlwZSIgRVFVQUwgcG5z LXByb3ZpZGVyDQo+Pj4gICAgICAgcG4tcGFyYW0gICAgICAgID0gInBuLXBhcmFtIiBFUVVBTCBw bnMtcGFyYW0NCj4+PiAgICAgICBwbi1wcmlkICAgICAgICAgPSAicG4tcHJpZCIgRVFVQUwgcHZh bHVlDQo+Pj4gICAgICAgcG4tZW5jY29kZSAgICAgID0gInBuLWVuY2NvZGUiIEVRVUFMIHB2YWx1 ZQ0KPj4+ICAgICAgIHBuLWVuY2tleSAgICAgICA9ICJwbi1lbmNrZXkiIEVRVUFMIHB2YWx1ZQ0K Pj4+DQo+Pj4gICAgICAgcG5zLXByb3ZpZGVyICAgID0gMSphbHBoYW51bQ0KPj4+ICAgICAgcG5z LXBhcmFtICAgICAgID0gcHZhbHVlDQo+Pj4NCj4+PiAyKSBPUiBlbHNlIGNvbWJpbmUgYWxsIG9m IHBucy1wYXJhbSwgcG4tZW5ja2V5IHZhbHVlIGFuZCBwbi1lbmNjb2RlIA0KPj4+IHZhbHVlIGlu dG8gYSBzaW5nbGUgcGFyYW1ldGVyIHdpdGggZGV0YWlsZWQgc3ludGF4IGRlZmluZWQgb24gYSAN Cj4+PiBwZXItcG4tdHlwZSBiYXNpcywNCj4+Pg0KPj4+ICAgICAgIHVyaS1wYXJhbWV0ZXIgICA9 LyBwbi10eXBlIC8gcG4tdmFsdWUNCj4+PiAgICAgICBwbi10eXBlICAgICAgICAgPSAicG4tdHlw ZSIgRVFVQUwgcG5zLXByb3ZpZGVyDQo+Pj4gICAgICAgcG5zLXByb3ZpZGVyICAgID0gMSphbHBo YW51bQ0KPj4+ICAgICAgIHBuLXZhbHVlICAgICAgICA9ICJwbi12YWx1ZSIgRVFVQUwgcHZhbHVl DQo+Pj4NCj4+PiAzKSBPUiBpdCBjb3VsZCBldmVuIGJlIG1hZGUgaW50byBhIHNpbmdsZSBwYXJh bWV0ZXIuDQo+Pj4NCj4+PiAgICAgICB1cmktcGFyYW1ldGVyICAgPS8gcG4tcGFyYW0NCj4+PiAg ICAgICBwbi1wYXJhbSAgICAgICAgPSAicG4iIEVRVUFMIHBucy1wcm92aWRlciBDT0xPTiBwbi12 YWx1ZQ0KPj4+ICAgICAgIHBucy1wcm92aWRlciAgICA9IDEqYWxwaGFudW0NCj4+PiAgICAgICBw bi12YWx1ZSAgICAgICAgPSBwdmFsdWUNCj4+Pg0KPj4+IE9mIGFsbCB0aG9zZSBJIHByZWZlciAo MyksIGJ1dCB0aGlzIGlzIGEgbWF0dGVyIG9mIHRhc3RlLg0KPj4gDQo+PiBJc24ndCAzKSBtb3Jl IG9yIGxlc3MgaWRlbnRpY2FsIHRvIHRoZSBjdXJyZW50IHN5bnRheD8gVGhlIG9ubHkgZGlmZmVy ZW5jZSBpcyB0aGF0IHRoZSBlbmNvZGVkIHZhbHVlIG9mIHRoZSBwYXJhbWV0ZXIgbmFtZSBpcyAi cG4iIGluc3RlYWQgb2YgInBuLXR5cGUiLg0KPg0KPiBObywgYmVjYXVzZSBpdCBpcyBhc3N1bWlu ZyB0aGF0IHBuLXZhbHVlIGluY2x1ZGVzIGFsbCB0aGUgaW5mb3JtYXRpb24gdGhhdCB0aGUgb3Ro ZXIgc3ludGF4ZXMgaW5jbHVkZSBpbiBhbGwgdGhlDQo+IG90aGVyIHBhcmFtZXRlcnMuIFRoZSBm b3JtIGZvciBwYWNraW5nIHdoYXRldmVyIGl0IGlzIGludG8gdGhlIHZhbHVlIHdvdWxkIGJlIHNw ZWNpZmllZCBieSB0aGUgZG9jdW1lbnQgZm9yIHRoZSBwcm92aWRlci4NCg0KSSBhbSBzdGlsbCBu b3QgZm9sbG93aW5nIDopDQoNCllvdSBzdWdnZXN0Og0KDQpwbi1wYXJhbSAgICAgICAgPSAicG4i IEVRVUFMIHBucy1wcm92aWRlciBDT0xPTiBwbi12YWx1ZQ0KDQpUaGUgZHJhZnQgc2F5czoNCg0K cG4tdHlwZSAgICAgICAgICAgID0gInBuLXR5cGUiIEVRVUFMIHBucy1wcm92aWRlciBDT0xPTiBw bnMtcGFyYW0NCnBucy1wYXJhbSAgICAgICA9IHB2YWx1ZQ0KDQouLi5zbywgaWYgSSByZXBsYWNl IHBucy1wYXJhbSB3aWggcHZhbHVlIGl0IGJlY29tZXM6DQoNCnBuLXR5cGUgICAgICAgICAgICA9 ICJwbi10eXBlIiBFUVVBTCBwbnMtcHJvdmlkZXIgQ09MT04gcHZhbHVlDQoNCkhvdyBpcyB0aGF0 IGRpZmZlcmVudCBmcm9tIHlvdXIgc3VnZ2VzdGlvbj8gOikNCg0KKFlvdSBkb24ndCBjb21tZW50 IG9uIHBuLXByaWQsIHNvIEkgYXNzdW1lIHRoYXQgcGFyYW1ldGVyIHdvdWxkIHN0YXkgdW5jaGFu Z2VkPykNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCglUaGFua3MsDQoJUGF1 bA0KDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQoNCg== From nobody Sat Oct 28 09:02:37 2017 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 E9F7613FB15 for ; Sat, 28 Oct 2017 09:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FovL_PswPe0I for ; Sat, 28 Oct 2017 09:02:35 -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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA90313FB09 for ; Sat, 28 Oct 2017 09:02:15 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id 8TYFeqwEnxpWa8TYsemOVe; Sat, 28 Oct 2017 16:02:14 +0000 Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-20v.sys.comcast.net with SMTP id 8TYreFHB0Xtd98TYseBGc4; Sat, 28 Oct 2017 16:02:14 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C671DA8@ESESSMB109.ericsson.se> <97385a1f-45f8-d81d-a56b-c1851ed33fbb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C674993@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <0c162235-b062-7bd1-bd16-07119db29812@alum.mit.edu> Date: Sat, 28 Oct 2017 12:02:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C674993@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfOP2D5HS7PL61IwXWlScHj+/NPmjDxjEPkfKUTuLLB8rDH9bS5VLJDwHNKQTMd4dH5ce6QdojH4FVvHt9FtOghiEy8RfWNibRdpuYmNCE9utFqdGUpmy uA8oXk+65IfQne6w4oq2tvYyPDbrUl1wVX1cxxa0h4mPzgxNsTVa8hIBOnutrIk5/mI5Qtw7XZ+kT78jkbnBBjpiS/k43wpNpY0VRLADaSTbaRj177HVVOV/ Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 16:02:36 -0000 On 10/28/17 4:30 AM, Christer Holmberg wrote: > Hi, > > ... > >>>> Why is it that there are four related parameters that are used in >>>> concert to provide pieces of the required information, and then pn-type has a two-part value? ISTM it would make more sense to either: >>>> >>>> 1) make the two parts of pn-type be separate parameters, >>>> >>>> uri-parameter =/ pn-type / pn-param /pn-prid >>>> / pn-enccode / pn-enckey >>>> pn-type = "pn-type" EQUAL pns-provider >>>> pn-param = "pn-param" EQUAL pns-param >>>> pn-prid = "pn-prid" EQUAL pvalue >>>> pn-enccode = "pn-enccode" EQUAL pvalue >>>> pn-enckey = "pn-enckey" EQUAL pvalue >>>> >>>> pns-provider = 1*alphanum >>>> pns-param = pvalue >>>> >>>> 2) OR else combine all of pns-param, pn-enckey value and pn-enccode >>>> value into a single parameter with detailed syntax defined on a >>>> per-pn-type basis, >>>> >>>> uri-parameter =/ pn-type / pn-value >>>> pn-type = "pn-type" EQUAL pns-provider >>>> pns-provider = 1*alphanum >>>> pn-value = "pn-value" EQUAL pvalue >>>> >>>> 3) OR it could even be made into a single parameter. >>>> >>>> uri-parameter =/ pn-param >>>> pn-param = "pn" EQUAL pns-provider COLON pn-value >>>> pns-provider = 1*alphanum >>>> pn-value = pvalue >>>> >>>> Of all those I prefer (3), but this is a matter of taste. >>> >>> Isn't 3) more or less identical to the current syntax? The only difference is that the encoded value of the parameter name is "pn" instead of "pn-type". >> >> No, because it is assuming that pn-value includes all the information that the other syntaxes include in all the >> other parameters. The form for packing whatever it is into the value would be specified by the document for the provider. > > I am still not following :) > > You suggest: > > pn-param = "pn" EQUAL pns-provider COLON pn-value > > The draft says: > > pn-type = "pn-type" EQUAL pns-provider COLON pns-param > pns-param = pvalue > > ...so, if I replace pns-param wih pvalue it becomes: > > pn-type = "pn-type" EQUAL pns-provider COLON pvalue > > How is that different from your suggestion? :) > > (You don't comment on pn-prid, so I assume that parameter would stay unchanged?) No. In (3) there is no prid or enckey or enccode in the syntax. Instead, if those are needed for this push service then they are embedded within pn-value. It would be up to the definition of the particular pn type to specify what goes into the value. So while the names are similar to parts of the current syntax the usage is different. Thanks, Paul From nobody Sun Oct 29 03:12:14 2017 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 79CD413FAC9 for ; Sun, 29 Oct 2017 03:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD9Mx_P_ANui for ; Sun, 29 Oct 2017 03:12:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4AC6913F710 for ; Sun, 29 Oct 2017 03:12:09 -0700 (PDT) X-AuditID: c1b4fb25-dd3ff70000000c94-ee-59f5a977e588 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 76.FC.03220.779A5F95; Sun, 29 Oct 2017 11:12:07 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Sun, 29 Oct 2017 11:12:06 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-sip-push-01 Thread-Index: AQHTTvBHLyywS3X2LE6SM4z0ppMbCKL3u3OAgAAue9CAAAvzgIAA+VQAgABdn4CAAVD+YA== Date: Sun, 29 Oct 2017 10:12:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C677AAB@ESESSMB109.ericsson.se> References: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C671DA8@ESESSMB109.ericsson.se> <97385a1f-45f8-d81d-a56b-c1851ed33fbb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C674993@ESESSMB109.ericsson.se> <0c162235-b062-7bd1-bd16-07119db29812@alum.mit.edu> In-Reply-To: <0c162235-b062-7bd1-bd16-07119db29812@alum.mit.edu> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7h275yq+RBi9XWVms2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG8onrWAueyVcc+vaXvYHxj1wXIyeHhICJ xJ/jZ5m6GLk4hAQOM0r8uLCREcJZzChxaOlXti5GDg42AQuJ7n/aIA0iAoESV5dMYAaxhQWs JW50nAcrERGwkfjwnhmiJEzi8Lr/rCA2i4CqRNv8RWA2r4CvxLWvW5ghxj9lkth64zobSIJT wEHizYwXYEWMAmIS30+tYQKxmQXEJW49mc8EcaiAxJI955khbFGJl4//sULYShJrD29nAbmB WUBTYv0ufYhWRYkp3Q/ZIfYKSpyc+YRlAqPILCRTZyF0zELSMQtJxwJGllWMosWpxUm56UbG eqlFmcnFxfl5enmpJZsYgbFwcMtv1R2Ml984HmIU4GBU4uFl7P8aKcSaWFZcmXuIUYKDWUmE d9ISoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFex30XIoQE0hNLUrNTUwtSi2CyTBycUg2MMkVJ TkFfG/sr7/gFK9s1ztvttu3GtB9d12fdc5v1hcXv3NsvCkt/mm7m8eb3aW4tSg+bqS9hZ6Pp pWB34X/b7nUXJqyXafdec7xmu+SCvpCnW2sOtZv4N0s4iq9466+lm/v8PZtxdf2VvI++M77d uz0taXvazB2H+uQMO7gMK56nv9J6pDhDiaU4I9FQi7moOBEAaHrZUoECAAA= Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 10:12:13 -0000 SGksDQoNCi4uLg0KIA0KPj4+Pj4gV2h5IGlzIGl0IHRoYXQgdGhlcmUgYXJlIGZvdXIgcmVsYXRl ZCBwYXJhbWV0ZXJzIHRoYXQgYXJlIHVzZWQgaW4gDQo+Pj4+PiBjb25jZXJ0IHRvIHByb3ZpZGUg cGllY2VzIG9mIHRoZSByZXF1aXJlZCBpbmZvcm1hdGlvbiwgYW5kIHRoZW4gcG4tdHlwZSBoYXMg YSB0d28tcGFydCB2YWx1ZT8gSVNUTSBpdCB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UgdG8gZWl0aGVy Og0KPj4+Pj4NCj4+Pj4+IDEpIG1ha2UgdGhlIHR3byBwYXJ0cyBvZiBwbi10eXBlIGJlIHNlcGFy YXRlIHBhcmFtZXRlcnMsDQo+Pj4+Pg0KPj4+Pj4gICAgICAgIHVyaS1wYXJhbWV0ZXIgICA9LyBw bi10eXBlIC8gcG4tcGFyYW0gL3BuLXByaWQNCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg IC8gcG4tZW5jY29kZSAvIHBuLWVuY2tleQ0KPj4+Pj4gICAgICAgIHBuLXR5cGUgICAgICAgICA9 ICJwbi10eXBlIiBFUVVBTCBwbnMtcHJvdmlkZXINCj4+Pj4+ICAgICAgICBwbi1wYXJhbSAgICAg ICAgPSAicG4tcGFyYW0iIEVRVUFMIHBucy1wYXJhbQ0KPj4+Pj4gICAgICAgIHBuLXByaWQgICAg ICAgICA9ICJwbi1wcmlkIiBFUVVBTCBwdmFsdWUNCj4+Pj4+ICAgICAgICBwbi1lbmNjb2RlICAg ICAgPSAicG4tZW5jY29kZSIgRVFVQUwgcHZhbHVlDQo+Pj4+PiAgICAgICAgcG4tZW5ja2V5ICAg ICAgID0gInBuLWVuY2tleSIgRVFVQUwgcHZhbHVlDQo+Pj4+Pg0KPj4+Pj4gICAgICAgIHBucy1w cm92aWRlciAgICA9IDEqYWxwaGFudW0NCj4+Pj4+ICAgICAgIHBucy1wYXJhbSAgICAgICA9IHB2 YWx1ZQ0KPj4+Pj4NCj4+Pj4+IDIpIE9SIGVsc2UgY29tYmluZSBhbGwgb2YgcG5zLXBhcmFtLCBw bi1lbmNrZXkgdmFsdWUgYW5kIHBuLWVuY2NvZGUgDQo+Pj4+PiB2YWx1ZSBpbnRvIGEgc2luZ2xl IHBhcmFtZXRlciB3aXRoIGRldGFpbGVkIHN5bnRheCBkZWZpbmVkIG9uIGEgDQo+Pj4+PiBwZXIt cG4tdHlwZSBiYXNpcywNCj4+Pj4+DQo+Pj4+PiAgICAgICAgdXJpLXBhcmFtZXRlciAgID0vIHBu LXR5cGUgLyBwbi12YWx1ZQ0KPj4+Pj4gICAgICAgIHBuLXR5cGUgICAgICAgICA9ICJwbi10eXBl IiBFUVVBTCBwbnMtcHJvdmlkZXINCj4+Pj4+ICAgICAgICBwbnMtcHJvdmlkZXIgICAgPSAxKmFs cGhhbnVtDQo+Pj4+PiAgICAgICAgcG4tdmFsdWUgICAgICAgID0gInBuLXZhbHVlIiBFUVVBTCBw dmFsdWUNCj4+Pj4+DQo+Pj4+PiAzKSBPUiBpdCBjb3VsZCBldmVuIGJlIG1hZGUgaW50byBhIHNp bmdsZSBwYXJhbWV0ZXIuDQo+Pj4+Pg0KPj4+Pj4gICAgICAgIHVyaS1wYXJhbWV0ZXIgICA9LyBw bi1wYXJhbQ0KPj4+Pj4gICAgICAgIHBuLXBhcmFtICAgICAgICA9ICJwbiIgRVFVQUwgcG5zLXBy b3ZpZGVyIENPTE9OIHBuLXZhbHVlDQo+Pj4+PiAgICAgICAgcG5zLXByb3ZpZGVyICAgID0gMSph bHBoYW51bQ0KPj4+Pj4gICAgICAgIHBuLXZhbHVlICAgICAgICA9IHB2YWx1ZQ0KPj4+Pj4NCj4+ Pj4+IE9mIGFsbCB0aG9zZSBJIHByZWZlciAoMyksIGJ1dCB0aGlzIGlzIGEgbWF0dGVyIG9mIHRh c3RlLg0KPj4+DQo+Pj4+IElzbid0IDMpIG1vcmUgb3IgbGVzcyBpZGVudGljYWwgdG8gdGhlIGN1 cnJlbnQgc3ludGF4PyBUaGUgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIGVuY29kZWQgdmFs dWUgb2YgdGhlIHBhcmFtZXRlciBuYW1lIGlzICJwbiIgaW5zdGVhZCBvZiAicG4tdHlwZSIuDQo+ Pj4NCj4+PiBObywgYmVjYXVzZSBpdCBpcyBhc3N1bWluZyB0aGF0IHBuLXZhbHVlIGluY2x1ZGVz IGFsbCB0aGUgaW5mb3JtYXRpb24gDQo+Pj4gdGhhdCB0aGUgb3RoZXIgc3ludGF4ZXMgaW5jbHVk ZSBpbiBhbGwgdGhlIG90aGVyIHBhcmFtZXRlcnMuIFRoZSBmb3JtIGZvciBwYWNraW5nIHdoYXRl dmVyIGl0IGlzIGludG8gdGhlIHZhbHVlIHdvdWxkIGJlIHNwZWNpZmllZCBieSB0aGUgZG9jdW1l bnQgZm9yIHRoZSBwcm92aWRlci4NCj4+IA0KPj4gSSBhbSBzdGlsbCBub3QgZm9sbG93aW5nIDop DQo+PiANCj4+IFlvdSBzdWdnZXN0Og0KPj4gDQo+PiBwbi1wYXJhbSAgICAgICAgPSAicG4iIEVR VUFMIHBucy1wcm92aWRlciBDT0xPTiBwbi12YWx1ZQ0KPj4gDQo+PiBUaGUgZHJhZnQgc2F5czoN Cj4+IA0KPj4gcG4tdHlwZSAgICAgICAgICAgID0gInBuLXR5cGUiIEVRVUFMIHBucy1wcm92aWRl ciBDT0xPTiBwbnMtcGFyYW0NCj4+IHBucy1wYXJhbSAgICAgICA9IHB2YWx1ZQ0KPj4gDQo+PiAu Li5zbywgaWYgSSByZXBsYWNlIHBucy1wYXJhbSB3aWggcHZhbHVlIGl0IGJlY29tZXM6DQo+PiAN Cj4+IHBuLXR5cGUgICAgICAgICAgICA9ICJwbi10eXBlIiBFUVVBTCBwbnMtcHJvdmlkZXIgQ09M T04gcHZhbHVlDQo+PiANCj4+IEhvdyBpcyB0aGF0IGRpZmZlcmVudCBmcm9tIHlvdXIgc3VnZ2Vz dGlvbj8gOikNCj4+IA0KPj4gKFlvdSBkb24ndCBjb21tZW50IG9uIHBuLXByaWQsIHNvIEkgYXNz dW1lIHRoYXQgcGFyYW1ldGVyIHdvdWxkIHN0YXkgDQo+PiB1bmNoYW5nZWQ/KQ0KPg0KPiBOby4g SW4gKDMpIHRoZXJlIGlzIG5vIHByaWQgb3IgZW5ja2V5IG9yIGVuY2NvZGUgaW4gdGhlIHN5bnRh eC4gSW5zdGVhZCwgaWYgdGhvc2UgYXJlIG5lZWRlZCBmb3IgdGhpcyBwdXNoIA0KPiBzZXJ2aWNl IHRoZW4gdGhleSBhcmUgZW1iZWRkZWQgd2l0aGluIHBuLXZhbHVlLg0KDQpBYWFoLi4uIG9rLCBu b3cgSSBnZXQgaXQuDQoNClRoZSByZWFzb24gSSBoYXZlIGtlcHQgcG4tcHJpZCBzZXBhcmF0ZSBp cyBiZWNhdXNlIHRoZSB2YWx1ZSBjb3VsZCBiZSBhIFVSTCwgd2hpY2ggbWVhbnMgaXQgY291bGQg aW5jbHVkZSB0aGUgc2FtZSBjaGFyYWN0ZXIgYXMgaXMgdXNlZCBhcyBzZXBhcmF0b3IuIElmIHN1 Y2ggY2hhcmFjdGVyIG9jY3VycyB3aXRoaW4gdGhlIFVSSSBpdCB3b3VsZCBoYXZlIHRvIGJlIGVz Y2FwZWQsIGFuZCBJIHdvdWxkIGxpa2UgdG8gYXZvaWQgdGhhdC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg== From nobody Sun Oct 29 09:56:26 2017 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 BCFF413F502 for ; Sun, 29 Oct 2017 09:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahJQ039ZSAf7 for ; Sun, 29 Oct 2017 09:56:24 -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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027F513AF75 for ; Sun, 29 Oct 2017 09:56:23 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id 8qspes8YGxpWa8qspeo1Wx; Sun, 29 Oct 2017 16:56:23 +0000 Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-16v.sys.comcast.net with SMTP id 8qsoe8nbVkJdH8qsoeaNCl; Sun, 29 Oct 2017 16:56:22 +0000 From: Paul Kyzivat To: Christer Holmberg References: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C671DA8@ESESSMB109.ericsson.se> <97385a1f-45f8-d81d-a56b-c1851ed33fbb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C674993@ESESSMB109.ericsson.se> <0c162235-b062-7bd1-bd16-07119db29812@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C677AAB@ESESSMB109.ericsson.se> Cc: "sipcore@ietf.org" Message-ID: <0bd134fb-439c-44fc-414c-73fc58a48fa6@alum.mit.edu> Date: Sun, 29 Oct 2017 12:56:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C677AAB@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDvDiz4rjULfpL1qyptMSPfppviVg/r/11wjNNio5cBezoUnIMJdj1kZ4bx96eXwzGWnDwO9nAxBMqo5SSXxH9BIaTeUiYeVk8XQH5GPlOStdWst75yk JsABtSIVltX2QBgz7igaSxkU9BULn1Q3+PZQP1x/F3qj+VIW4p8D09sn1NsG4044RvnykCc7DSk0KyvSH0vLOCP0ZfwpYrnLGSRtEAjNb60GosWCDH7uV84k b8IKP2aBogBkAIVYOXIiVyQJ0D37LjeszMZwaXj7TR8= Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 16:56:25 -0000 On 10/29/17 6:12 AM, Christer Holmberg wrote: > Hi, > > ... > >>>>>> Why is it that there are four related parameters that are used in >>>>>> concert to provide pieces of the required information, and then pn-type has a two-part value? ISTM it would make more sense to either: >>>>>> >>>>>> 1) make the two parts of pn-type be separate parameters, >>>>>> >>>>>> uri-parameter =/ pn-type / pn-param /pn-prid >>>>>> / pn-enccode / pn-enckey >>>>>> pn-type = "pn-type" EQUAL pns-provider >>>>>> pn-param = "pn-param" EQUAL pns-param >>>>>> pn-prid = "pn-prid" EQUAL pvalue >>>>>> pn-enccode = "pn-enccode" EQUAL pvalue >>>>>> pn-enckey = "pn-enckey" EQUAL pvalue >>>>>> >>>>>> pns-provider = 1*alphanum >>>>>> pns-param = pvalue >>>>>> >>>>>> 2) OR else combine all of pns-param, pn-enckey value and pn-enccode >>>>>> value into a single parameter with detailed syntax defined on a >>>>>> per-pn-type basis, >>>>>> >>>>>> uri-parameter =/ pn-type / pn-value >>>>>> pn-type = "pn-type" EQUAL pns-provider >>>>>> pns-provider = 1*alphanum >>>>>> pn-value = "pn-value" EQUAL pvalue >>>>>> >>>>>> 3) OR it could even be made into a single parameter. >>>>>> >>>>>> uri-parameter =/ pn-param >>>>>> pn-param = "pn" EQUAL pns-provider COLON pn-value >>>>>> pns-provider = 1*alphanum >>>>>> pn-value = pvalue >>>>>> >>>>>> Of all those I prefer (3), but this is a matter of taste. >>>> >>>>> Isn't 3) more or less identical to the current syntax? The only difference is that the encoded value of the parameter name is "pn" instead of "pn-type". >>>> >>>> No, because it is assuming that pn-value includes all the information >>>> that the other syntaxes include in all the other parameters. The form for packing whatever it is into the value would be specified by the document for the provider. >>> >>> I am still not following :) >>> >>> You suggest: >>> >>> pn-param = "pn" EQUAL pns-provider COLON pn-value >>> >>> The draft says: >>> >>> pn-type = "pn-type" EQUAL pns-provider COLON pns-param >>> pns-param = pvalue >>> >>> ...so, if I replace pns-param wih pvalue it becomes: >>> >>> pn-type = "pn-type" EQUAL pns-provider COLON pvalue >>> >>> How is that different from your suggestion? :) >>> >>> (You don't comment on pn-prid, so I assume that parameter would stay >>> unchanged?) >> >> No. In (3) there is no prid or enckey or enccode in the syntax. Instead, if those are needed for this push >> service then they are embedded within pn-value. > > Aaah... ok, now I get it. > > The reason I have kept pn-prid separate is because the value could be a URL, which means it could include the same character as is used as separator. If such character occurs within the URI it would have to be escaped, and I would like to avoid that. If (3) were being used then I expect that the provider that needs a URI could find a way to make that work in the value syntax. But choosing an approach is at least partly an aesthetic decision. As long as whatever way you choose is well defined I won't object (much). Thanks, Paul Thanks, Paul From nobody Sun Oct 29 10:07:40 2017 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 A524C13F5C0 for ; Sun, 29 Oct 2017 10:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aghPwwDfepDz for ; Sun, 29 Oct 2017 10:07:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 002EA13F59C for ; Sun, 29 Oct 2017 10:07:36 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-c8-59f60ad6c8fb Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4E.2C.03220.6DA06F95; Sun, 29 Oct 2017 18:07:34 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Sun, 29 Oct 2017 18:07:33 +0100 From: Christer Holmberg To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-sip-push-01 Thread-Index: AQHTTvBHLyywS3X2LE6SM4z0ppMbCKL3u3OAgAAue9CAAAvzgIAA+VQAgABdn4CAAVD+YIAAYTqAgAAS7bA= Date: Sun, 29 Oct 2017 17:07:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C677ED9@ESESSMB109.ericsson.se> References: <742fa94d-c587-305c-789f-8f417d511b08@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C671DA8@ESESSMB109.ericsson.se> <97385a1f-45f8-d81d-a56b-c1851ed33fbb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C674993@ESESSMB109.ericsson.se> <0c162235-b062-7bd1-bd16-07119db29812@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B5C677AAB@ESESSMB109.ericsson.se> <0bd134fb-439c-44fc-414c-73fc58a48fa6@alum.mit.edu> In-Reply-To: <0bd134fb-439c-44fc-414c-73fc58a48fa6@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2J7lO41rm+RBvtfqVqs2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG2da5zAXXeCpOz9vF1sC4hqeLkZNDQsBE YvuBZmYQW0jgMKPE7A++XYxcQPZiRomWdzMYuxg5ONgELCS6/2mDmCICGhKTtqqBlDMLaEo8 2rmXCcQWFrCWuNFxng2ixEbiw3uwiSICSRJf939kB7FZBFQlNs2eDxbnFfCVmLv8EhPEpvvM EtvW32YDSXAKOEicm/GdEcRmFBCT+H5qDRPELnGJW0/mM0GcLCCxZM95ZghbVOLl43+sELaS xKLbn5lAbgC5bf0ufYhWRYkp3Q/ZIfYKSpyc+YRlAqPoLCRTZyF0zELSMQtJxwJGllWMosWp xUm56UbGeqlFmcnFxfl5enmpJZsYgfFxcMtv1R2Ml984HmIU4GBU4uG1eP81Uog1say4MvcQ owQHs5IIb/UzoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFex30XIoQE0hNLUrNTUwtSi2CyTByc Ug2MxhIVhdtqUttOnJVp4BFoWiB5yfun6s25Cg8eJ3pyL/DK/bMkUd6644Ph3MM2s3d//stv 4lxw9HR7i0naCf3riUdeTTR9ud4z8FjrwVW2zI0JboeWr2RaeGXG/Ydrr3mJpP67dEqp9tHy pddLc5UeGUTt/GOYLVQUW7FJ7PKntfWPwg5v8PQ/qcRSnJFoqMVcVJwIAEYJQOeLAgAA Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 17:07:39 -0000 KEkgbm90ZWQgbXkgcHJldmlvdXMgcmVwbHkgdG8gdGhpcyB3YXMgc2VudCB0byBQYXVsIG9ubHkp DQogDQpIaSwNCg0KLi4uDQoNCj4+PiBOby4gSW4gKDMpIHRoZXJlIGlzIG5vIHByaWQgb3IgZW5j a2V5IG9yIGVuY2NvZGUgaW4gdGhlIHN5bnRheC4gDQo+Pj4gSW5zdGVhZCwgaWYgdGhvc2UgYXJl IG5lZWRlZCBmb3IgdGhpcyBwdXNoIHNlcnZpY2UgdGhlbiB0aGV5IGFyZSBlbWJlZGRlZCB3aXRo aW4gcG4tdmFsdWUuDQo+PiANCj4+IEFhYWguLi4gb2ssIG5vdyBJIGdldCBpdC4NCj4+IA0KPj4g VGhlIHJlYXNvbiBJIGhhdmUga2VwdCBwbi1wcmlkIHNlcGFyYXRlIGlzIGJlY2F1c2UgdGhlIHZh bHVlIGNvdWxkIGJlIGEgVVJMLCB3aGljaCBtZWFucyBpdCANCj4+IGNvdWxkIGluY2x1ZGUgdGhl IHNhbWUgY2hhcmFjdGVyIGFzIGlzIHVzZWQgYXMgc2VwYXJhdG9yLiBJZiBzdWNoIGNoYXJhY3Rl ciBvY2N1cnMgd2l0aGluIHRoZSBVUkkgDQo+PiBpdCB3b3VsZCBoYXZlIHRvIGJlIGVzY2FwZWQs IGFuZCBJIHdvdWxkIGxpa2UgdG8gYXZvaWQgdGhhdC4NCj4NCj4gSWYgKDMpIHdlcmUgYmVpbmcg dXNlZCB0aGVuIEkgZXhwZWN0IHRoYXQgdGhlIHByb3ZpZGVyIHRoYXQgbmVlZHMgYSBVUkkgY291 bGQgZmluZCBhIHdheSB0byBtYWtlIHRoYXQgd29yayBpbiB0aGUgdmFsdWUgc3ludGF4Lg0KDQpU aGUgY2xpZW50IHdpbGwgZ2V0IHRoZSBQUklEIGZyb20gdGhlIHByb3ZpZGVyLCBhbmQgdGhlIGlk ZWEgaXMgdGhhdCBpdCB3aWxsIGNvcHkvcGFzdGUgaXQgaW50byB0aGUgU0lQIHBuLXByaWQgcGFy YW1ldGVyIHdpdGhvdXQgbW9kaWZpY2F0aW9ucyAoZXNjYXBpbmcgZXRjKS4NCg0KPiBCdXQgY2hv b3NpbmcgYW4gYXBwcm9hY2ggaXMgYXQgbGVhc3QgcGFydGx5IGFuIGFlc3RoZXRpYyBkZWNpc2lv bi4gQXMgbG9uZyBhcyB3aGF0ZXZlciB3YXkgeW91IGNob29zZSBpcyB3ZWxsIGRlZmluZWQgSSB3 b24ndCBvYmplY3QgKG11Y2gpLg0KDQpJIHdpbGwga2VlcCB0aGUgc3ludGF4IGFzIGl0IGlzIGZv ciBub3csIGJ1dCBJIHdpbGwgYWRkL21vZGlmeSB0ZXh0IGJhc2VkIG9uIHlvdXIgb3RoZXIgY29t bWVudHMuIEkgd2lsbCB0cnkgdG8gZG8gaXQgYmVmb3JlIHRoZSBTaW5nYXBvcmUgc3VibWlzc2lv biB3aW5kb3cgY2xvc2VzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Sun Oct 29 12:35:20 2017 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 2B13C13FB4A for ; Sun, 29 Oct 2017 12:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpZb1zN5vk-J for ; Sun, 29 Oct 2017 12:35:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4DA13FB61 for ; Sun, 29 Oct 2017 12:35:16 -0700 (PDT) X-AuditID: c1b4fb2d-bddff7000000268d-bc-59f62d73f9cc Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 09.25.09869.37D26F95; Sun, 29 Oct 2017 20:35:15 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Sun, 29 Oct 2017 20:35:14 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-sip-push-01 - PR based on Paul's comments Thread-Index: AdNQ7QoAhi7OpA/ZTmawhuX0SLRagQ== Date: Sun, 29 Oct 2017 19:35:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C678147@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM2K7jW6x7rdIg57V4hYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxfvU61oIrvBUnlvQyNjD+4Opi5OSQEDCR aF74lLWLkYtDSOAwo8T694+ZIJzFjBL/1iwCynBwsAlYSHT/0wZpEBEIlLi6ZAIziC0sEC3x 6Ns6Zoh4jMSdmV9ZIGw9ie7dkxhBbBYBVYldO94zgYzhFfCVeHa0FiTMKCAm8f3UGiYQm1lA XOLWk/lMEPcISCzZc54ZwhaVePn4HyuErSSx6PZnqHodiQW7P7FB2NoSyxa+BqvnFRCUODnz CcsERqFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIEBvfBLb91 dzCufu14iFGAg1GJh/ev5rdIIdbEsuLK3EOMEhzMSiK8X+SAQrwpiZVVqUX58UWlOanFhxil OViUxHkd9l2IEBJITyxJzU5NLUgtgskycXBKNTAurumarNWyTrXhdbr18YNK69QTD1fJ7X7y +ud/uawfu+edPaBz8t0nt9OCpZOPrjqptENWXupVNGPbz8MbrnTFM3mqrTprpHr/yKM1CnLG l2dHPb0f2PZh4uErc+d8M7gdZ73opNbFaTzJp+5HMcUvDX5r4br/1tMjH3jWOe5vieG5O+3X Kp4pqkosxRmJhlrMRcWJAAiH8YBqAgAA Archived-At: Subject: Re: [sipcore] Draft new version: draft-sip-push-01 - PR based on Paul's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 19:35:19 -0000 Hi, I created a PR based on Paul's comments: https://github.com/cdh4u/draft-sip-push/pull/2 Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 29 October 2017 19:08 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new version: draft-sip-push-01 (I noted my previous reply to this was sent to Paul only) =20 Hi, ... >>> No. In (3) there is no prid or enckey or enccode in the syntax.=20 >>> Instead, if those are needed for this push service then they are embedd= ed within pn-value. >>=20 >> Aaah... ok, now I get it. >>=20 >> The reason I have kept pn-prid separate is because the value could be=20 >> a URL, which means it could include the same character as is used as=20 >> separator. If such character occurs within the URI it would have to be e= scaped, and I would like to avoid that. > > If (3) were being used then I expect that the provider that needs a URI c= ould find a way to make that work in the value syntax. The client will get the PRID from the provider, and the idea is that it wil= l copy/paste it into the SIP pn-prid parameter without modifications (escap= ing etc). > But choosing an approach is at least partly an aesthetic decision. As lon= g as whatever way you choose is well defined I won't object (much). I will keep the syntax as it is for now, but I will add/modify text based o= n your other comments. I will try to do it before the Singapore submission = window closes. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Oct 29 12:47:40 2017 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 AB70F13FB6D for ; Sun, 29 Oct 2017 12:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUie7Ov4uRjX for ; Sun, 29 Oct 2017 12:47:37 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B3B13FB69 for ; Sun, 29 Oct 2017 12:47:36 -0700 (PDT) X-AuditID: c1b4fb3a-de7ff70000006897-c1-59f630563268 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.55.26775.65036F95; Sun, 29 Oct 2017 20:47:35 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Sun, 29 Oct 2017 20:47:35 +0100 From: Christer Holmberg To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaZ+6AgAEJNoCAAAc9gIAAPEsggAAAZQCAHCFoAP//8tUAgAAU2ACAADwLAIADRxHA Date: Sun, 29 Oct 2017 19:47:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C67820D@ESESSMB109.ericsson.se> References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> 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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7qG64wbdIg0VLuS1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjxtFFLAVfFCtebbjP2sDYotjFyMEhIWAi cehDVRcjF4eQwGFGiW0tK1kgnMWMEo0dl9hAitgELCS6/2mDmCICGhKTtqp1MXJyMAtoSjza uZcJJCwsICfRfsgSJCwiIC+xfudlJojqPIldU11AwiwCqhI3FxxkAbF5BXwlXv/oY4JYtJxF 4v/tY+wgCU4BB4lNC58wgdiMAmIS30+tYYJYJS5x68l8MFtCQEBiyZ7zzBC2qMTLx/9YIWwl iUW3P4PtBTlt/S59iFZFiSndD9kh9gpKnJz5hGUCo+gsJFNnIXTMQtIxC0nHAkaWVYyixanF xbnpRkZ6qUWZycXF+Xl6eaklmxiB0XFwy2+rHYwHnzseYhTgYFTi4VXS+hYpxJpYVlyZe4hR goNZSYT3ixxQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/DvgsRQgLpiSWp2ampBalFMFkmDk6p BsbpZzclTp4pMY9Fp/9R9qW3v37YWS7xr2DliE/5+kn1I3vA7e38biL78/Z86dw8XdJ868Zn 94tLGP5+5gtq6Cz+zfwwsSZv/l2/raeq27k9WEyShS4nnu/ufrHmnKlNZI/9xa/3y2r+i5q2 /nCeeLm6fPeDyPbM7YdWz2iJXrBu1cyDH/jk222VWIozEg21mIuKEwE5a5ELigIAAA== Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 19:47:39 -0000 SGksDQoNCj4+IEkgYW0gcHJvcG9zaW5nIHRoYXQgaXQgaXMgbm90IGFsbG93ZWQgdG8gaW5jbHVk ZSBTLUUgaW4gYW4gVVBEQVRFIA0KPj4gd2hpbGUgdGhlcmUgaXMgYW4gb25nb2luZyBJTlZJVEUg dHJhbnNhY3Rpb24uDQo+DQo+IEkgdGhpbmsgdGhhdCBpcyBhIGdvb2Qgc29sdXRpb24gYXMgbG9u ZyBhcyB3ZSBjYW4gcmVzb2x2ZSBhbnkgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpc3N1ZXMgDQo+ IHdpdGggZXhpc3RpbmcgZGVwbG95bWVudHMuIEkgZ2F0aGVyIHdlIGhhdmUgb25lLCBidXQgaXQg aXMgd2hhdCBpZGVudGlmaWVkIHRoZSBwcm9ibGVtIGFuZCANCj4gc28gaXQgbmVlZHMgdG8gY2hh bmdlIGFueXdheS4NCg0KV2VsbCwgdGhlIHJlYXNvbiB3ZSBkbyB0aGlzIGV4ZXJjaXNlIGlzIGJl Y2F1c2Ugc29tZSBvZiB0aGUgZXhpc3RpbmcgZGVwbG95bWVudHMgYXJlIGJyb2tlbiAob3IsIHRo ZSBzcGVjIHRoZXkgYXJlIGJhc2VkIG9uIGlzIGJyb2tlbi91bmNsZWFyKSwgc28gd2UgY2FuIG9u bHkgaG9wZSB0aGV5IHdpbGwgYmUgZml4ZWQuDQoNCkJ1dCwgYXQgbGVhc3QgYmFzZWQgb24gdGhl IG9yaWdpbmFsIHByb2JsZW0gY2FzZSBJIHNvbHZlZCwgdGhlIGZpeCB3b3VsZCBoYXZlIHRvIGJl IGRvbmUgaW4gYSBuZXR3b3JrIGRldmljZSAodGhlIG9uZSBzZW5kaW5nIFVQREFURSB3aXRoIFMt RSB3aGlsZSB0aGUgSU5WSVRFIHRyYW5zYWN0aW9uIGlzIHN0aWxsIG9uZ29pbmcpIC0gd2hpY2gg aXMgbXVjaCBlYXNpZXIgdGhhbiBoYXZpbmcgdG8gZml4IGEgbGFyZ2UgYnVuY2ggb2YgU0lQIFVB cy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo+IA0KPiBTZW50IGZyb20gbXkgaVBob25l DQo+IA0KPiBPbiAyNyBPY3QgMjAxNywgYXQgMTcuNTEsIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRA YWx1bS5taXQuZWR1IA0KPiA8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0K PiANCj4+IE9uIDEwLzI3LzE3IDg6MzEgQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4+ IEhpLA0KPj4+Pj4+Pj4gWWVzLCBJIHVuZGVyc3RhbmQgdGhhdCBpcyB0aGUgY2FzZSB5b3UgYXJl IHRoaW5raW5nIG9mLiBCdXQgSSANCj4+Pj4+Pj4+IHdhcyByYWlzaW5nIGEgZGlmZmVyZW50IGNh c2U6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLSB0aGUgVUFDIHNlbmRzIGFuIGludml0ZSB3aXRob3V0 IGEgUy1FLg0KPj4+Pj4+Pj4gLSBhIHByb3h5IGFsb25nIHRoZSBwYXRoIGluY2x1ZGVzIGFuIFMt RS4gKFRoZSBVQUMgaXMgdW5hd2FyZS4pDQo+Pj4+Pj4+PiAtIGxhdGVyLCB0aGUgVUFDIHNlbmRz IGFuIFVQREFURSB3aXRoIFMtRS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGF0IHZpb2xhdGVzIHRo ZSBydWxlIGluIHlvdXIgZHJhZnQsIGJ1dCB0aGUgVUFDIGRvZXNuJ3Qga25vdyANCj4+Pj4+Pj4+ IGl0IGhhcyB2aW9sYXRlZCBpdC4gU28geW91ciBydWxlIGZvciBhdm9pZGluZyB0aGUgcHJvYmxl bSBpbiANCj4+Pj4+Pj4+IHRoaXMgY2FzZSBkb2Vzbid0IHdvcmsuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ IFNlY3Rpb24gOC4yIGluIHRoZSBSRkMgaXMgKGluIG15IG9waW5vbikgcXVpdGUgbWVzc3ksIGJ1 dCBhcyBmYXIgDQo+Pj4+Pj4+IGFzIEkgdW5kZXJzdGFuZCB0aGUgcHJveHkgd2lsbCBuZXZlciBy ZW1vdmUgUy1FIGZyb20gYSByZXNwb25zZS4gDQo+Pj4+Pj4+IFNvLCB3ZSBjb3VsZCBzYXkgdGhh dCB0aGUgVUFDIG11c3Qgbm90IHNlbmQgVVBEQVRFIHdpdGggUy1FIA0KPj4+Pj4+PiB1bnRpbCBp dCBoYXMgcmVjZWl2ZWQgYSByZXNwb25zZSB0byB0aGUgSU5WSVRFLg0KPj4+Pj4+DQo+Pj4+Pj4g VGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgcmZjIG9ubHkgdGFsa3MgYWJvdXQgdGhlICpmaW5hbCog KDJ4eCkgDQo+Pj4+Pj4gcmVzcG9uc2UuDQo+Pj4+Pj4gSXQgaGFzIG5vIHByb3Zpc2lvbiBmb3Ig aW5jbHVkaW5nIHRoZSBTLUUgaW4gcHJvdmlzaW9uYWwgcmVzcG9uc2VzLg0KPj4+Pj4+IChJdCBk b2Vzbid0IG1lbnRpb24gcHJvdmlzaW9uYWwgcmVzcG9uc2VzLCBhbmQgdGhlIFRhYmxlIDEgdXBk YXRlIA0KPj4+Pj4+IGluIHNlY3Rpb24NCj4+Pj4+PiA0IHNob3dzIHRoZSBpbnRlbnQgaXMgdG8g ZXhjbHVkZSBpdC4gSGVuY2UsIGlmIHRoZSBTLUUgaXMgDQo+Pj4+Pj4gaW5zZXJ0ZWQgaW50byB0 aGUgSU5WSVRFIGJ5IGEgcHJveHksIHRoZSBVQUMgd29uJ3Qga25vdyB0aGF0IGEgDQo+Pj4+Pj4g c2Vzc2lvbiB0aW1lciBoYXMgYmVlbiByZXF1ZXN0ZWQgdW50aWwgaXQgcmVjZWl2ZXMgdGhlID4g ZmluYWwgDQo+Pj4+Pj4gcmVzcG9uc2UgdG8gdGhlIGludml0ZS4NCj4+Pj4+PiBNZWFud2hpbGUg aXQgbWlnaHQgZGVjaWRlIHNlbmQgYW4gVVBEQVRFIHdpdGggUy1FLg0KPj4+Pj4NCj4+Pj4+IE15 IHN1Z2dlc3Rpb24gaXMgdGhhdCB0aGUgVUFDIHdvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIHNlbmQg VVBEQVRFIA0KPj4+Pj4gd2l0aCBTLUUgdW50aWwgaXQgaGFzIHJlY2VpdmVkIHRoZSBmaW5hbCBy ZXNwb25zZSBmb3IgdGhlIElOVklURS4NCj4+Pj4NCj4+Pj4gVGhpcyBpcyBtb3JlIG9yIGxlc3Mg dGhlIG9yaWdpbmFsIHByb3Bvc2FsIHRoYXQgd2FzIHNob3QgZG93bi4gT3IgDQo+Pj4+IGRvIHlv dSBtZWFuIHRoYXQgdGhlICpVQUMqIGlzIHJlc3RyaWN0ZWQgdGhhdCB3YXksIGJ1dCB0aGUgKlVB UyogaXMgDQo+Pj4+IHBlcm1pdHRlZCB0byB1c2UgUy1FIHRvIG5lZ290aWF0ZSBzZXNzaW9uIHRp bWVyIGluIHRoZSBtaWRzdCBvZiB0aGUgDQo+Pj4+IElOVklURSwgYXQgbGVhc3QgaW4gc29tZSBj YXNlcz8NCj4+PiBJIGhhdmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzLCB0YWxrZWQgdG8gc29t ZSBwZW9wbGUgZXRjLCBhbmQgDQo+Pj4gcGVyaGFwcyB0aGUgZWFzaWVzdCBzb2x1dGlvbiB3b3Vs ZCBiZSB0byBub3cgYWxsb3cgVVBEQVRFIHdpdGggUy1FIA0KPj4+IGR1cmluZyBhbiBhY3RpdmUg SU5WSVRFIHRyYW5zYWN0aW9uIChhcyBzdWdnZXN0ZWQgYWJvdmUpLg0KPj4NCj4+IEkgaGF2ZSBu b3cgZ290dGVuIGxvc3QgaW4gdGhlIHByb3Bvc3NhbHMgYW5kIGNvdW50ZXIgcHJvcG9zYWxzLiBD YW4gDQo+PiB5b3UgZXhwbGljaXRseSBzdGF0ZSB3aGF0IHlvdSBhcmUgcHJvcG9zaW5nPw0KPj4N Cj4+IMKgIMKgVGhhbmtzLA0KPj4gwqAgwqBQYXVsDQoNCg== From nobody Sun Oct 29 14:03:34 2017 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 D647013F615 for ; Sun, 29 Oct 2017 14:03:32 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18ybBGSXa_rm for ; Sun, 29 Oct 2017 14:03:31 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 18B1413B138 for ; Sun, 29 Oct 2017 14:03:30 -0700 (PDT) X-AuditID: 1207440e-bf9ff70000007085-12-59f64220d4c2 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.9B.28805.02246F95; Sun, 29 Oct 2017 17:03:29 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9TL3REi011236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 29 Oct 2017 17:03:27 -0400 To: Christer Holmberg Cc: "sipcore@ietf.org" References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> <7594FB04B1934943A5C02806D1A2204B5C67820D@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Sun, 29 Oct 2017 17:03:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C67820D@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixO6iqKvo9C3SYOs1OYsLMw8zWnz9sYnN gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4fXktW8F9mYq3986yNDC+FOti5OSQEDCR uLDrByuILSSwg0ni88fCLkYuIPshk0TL4sXsIAlhATmJ151XwIpEBMwkrn/uZQKxmQU0JTav u8AO0fCaReLUi/tgDWwCWhJzDv1nAbF5Bewl+meeZAaxWQRUJd4+u8EIYosKpEncmfGQCaJG UOLkzCdA9RwcnAJ+EhPuq0LMN5OYt/khM4QtLnHryXyovfISzVtnM09gFJiFpHsWkpZZSFpm IWlZwMiyilEuMac0Vzc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0EyMkgPl2MLavlznEKMDB qMTDm6H1NVKINbGsuDL3EKMkB5OSKO++858ihfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwvrX/ FinEm5JYWZValA+TkuZgURLnVVui7ickkJ5YkpqdmlqQWgSTleHgUJLgFXMEahQsSk1PrUjL zClBSDNxcIIM5wEargpSw1tckJhbnJkOkT/FaMnR03PjDxPHutP3gOSzma8bmIVY8vLzUqXE eb87ADUIgDRklObBzYQlpFeM4kAvCvPeAaniASYzuKmvgBYyAS3UkPwCsrAkESEl1cDIsnLf 82VP7h/o+tXtndaqq/bqrVLVxaazl04LTilM0E3t6H4cdDC8ns0xXr9K4NXv/4v1zAJjb7D8 cGfsimuaqrefO+hXIxPvAdPiLs2GNJeVJ1Qkz7m+cBDf/PzC6gkLTARO/fi45WtmYsIyr8N2 R08Kb65zWf1h+m6PnG6Hyum7rcWVr+5UYinOSDTUYi4qTgQA+auWaCMDAAA= Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 21:03:33 -0000 On 10/29/17 3:47 PM, Christer Holmberg wrote: > Hi, > >>> I am proposing that it is not allowed to include S-E in an UPDATE >>> while there is an ongoing INVITE transaction. >> >> I think that is a good solution as long as we can resolve any backward compatibility issues >> with existing deployments. I gather we have one, but it is what identified the problem and >> so it needs to change anyway. > > Well, the reason we do this exercise is because some of the existing deployments are broken (or, the spec they are based on is broken/unclear), so we can only hope they will be fixed. > > But, at least based on the original problem case I solved, the fix would have to be done in a network device (the one sending UPDATE with S-E while the INVITE transaction is still ongoing) - which is much easier than having to fix a large bunch of SIP UAs. OK. If you go with this approach, it is important for the update to the spec to be clear that an UPDATE (without S-E) in the midst of a INVITE transaction *does not* impact the status of the the timer being negotiated by the INVITE or one that was in effect prior to the INVITE. (Because normally an UPDATE or re-INVITE without S-E removes any timer that is in effect.) Thanks, Paul > Regards, > > Christer > > >> >> Sent from my iPhone >> >> On 27 Oct 2017, at 17.51, Paul Kyzivat > > wrote: >> >>> On 10/27/17 8:31 AM, Christer Holmberg wrote: >>>> Hi, >>>>>>>>> Yes, I understand that is the case you are thinking of. But I >>>>>>>>> was raising a different case: >>>>>>>>> >>>>>>>>> - the UAC sends an invite without a S-E. >>>>>>>>> - a proxy along the path includes an S-E. (The UAC is unaware.) >>>>>>>>> - later, the UAC sends an UPDATE with S-E. >>>>>>>>> >>>>>>>>> That violates the rule in your draft, but the UAC doesn't know >>>>>>>>> it has violated it. So your rule for avoiding the problem in >>>>>>>>> this case doesn't work. >>>>>>>> >>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far >>>>>>>> as I understand the proxy will never remove S-E from a response. >>>>>>>> So, we could say that the UAC must not send UPDATE with S-E >>>>>>>> until it has received a response to the INVITE. >>>>>>> >>>>>>> The problem is that the rfc only talks about the *final* (2xx) >>>>>>> response. >>>>>>> It has no provision for including the S-E in provisional responses. >>>>>>> (It doesn't mention provisional responses, and the Table 1 update >>>>>>> in section >>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is >>>>>>> inserted into the INVITE by a proxy, the UAC won't know that a >>>>>>> session timer has been requested until it receives the > final >>>>>>> response to the invite. >>>>>>> Meanwhile it might decide send an UPDATE with S-E. >>>>>> >>>>>> My suggestion is that the UAC would not be allowed to send UPDATE >>>>>> with S-E until it has received the final response for the INVITE. >>>>> >>>>> This is more or less the original proposal that was shot down. Or >>>>> do you mean that the *UAC* is restricted that way, but the *UAS* is >>>>> permitted to use S-E to negotiate session timer in the midst of the >>>>> INVITE, at least in some cases? >>>> I have been thinking about this, talked to some people etc, and >>>> perhaps the easiest solution would be to now allow UPDATE with S-E >>>> during an active INVITE transaction (as suggested above). >>> >>> I have now gotten lost in the propossals and counter proposals. Can >>> you explicitly state what you are proposing? >>> >>>    Thanks, >>>    Paul > From nobody Sun Oct 29 14:18:58 2017 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 464DF13FC4C for ; Sun, 29 Oct 2017 14:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWNTaexMXbPO for ; Sun, 29 Oct 2017 14:18:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1DC13FC4B for ; Sun, 29 Oct 2017 14:18:54 -0700 (PDT) X-AuditID: c1b4fb2d-bddff7000000268d-50-59f645bc9a47 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.EB.09869.CB546F95; Sun, 29 Oct 2017 22:18:52 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Sun, 29 Oct 2017 22:18:52 +0100 From: Christer Holmberg To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaZ+6AgAEJNoCAAAc9gIAAPEsggAAAZQCAHCFoAP//8tUAgAAU2ACAADwLAIADRxHAgAAFSgCAABTD8A== Date: Sun, 29 Oct 2017 21:18:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C6783FC@ESESSMB109.ericsson.se> References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> <7594FB04B1934943A5C02806D1A2204B5C67820D@ESESSMB109.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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM2J7uO4e12+RBus7zCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj65zT7AXr1Cvu/VvJ3MC4Rq2LkZNDQsBE 4tymXcwgtpDAYUaJW9/duhi5gOzFjBI/zr1l62Lk4GATsJDo/qcNYooIaEhM2grWyiygKfFo 514mkLCwgJxE+yFLkLCIgLzE+p2XmSCq6ySu37IAMVkEVCUWznUEqeAV8JVY+fAkE8SehawS r3c/YgVJcAo4SNy89QLMZhQQk/h+ag0TxCZxiVtP5jNBHCwgsWTPeWYIW1Ti5eN/rBC2ksSi 25/B1oJctn6XPkSrosSU7ofsEHsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypG0eLU4uLc dCNjvdSizOTi4vw8vbzUkk2MwNg4uOW37g7G1a8dDzEKcDAq8fD+1fwWKcSaWFZcmXuIUYKD WUmEt9sFKMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+FCCGB9MSS1OzU1ILUIpgsEwenVANj RONEg40e86+uYD5g11XwWI6N85F5uPbVZwnqwiVeXyT/XHl9fW8Qr/RxpnqJdPXjshyBn74s s72Yu9Z7WWKf2w5fLjVeH/UjW1qf+3C6ZG28FrmYQ+uLjVjPMQvFx5O9lS8vNNF4niMqufKC Q8GSoN8P32zP3achFaH47N1rli9MwVZNN1YosRRnJBpqMRcVJwIAOfXLr4kCAAA= Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 21:18:57 -0000 SGksDQoNCj4+Pj4gSSBhbSBwcm9wb3NpbmcgdGhhdCBpdCBpcyBub3QgYWxsb3dlZCB0byBpbmNs dWRlIFMtRSBpbiBhbiBVUERBVEUgDQo+Pj4+IHdoaWxlIHRoZXJlIGlzIGFuIG9uZ29pbmcgSU5W SVRFIHRyYW5zYWN0aW9uLg0KPj4+DQo+Pj4gSSB0aGluayB0aGF0IGlzIGEgZ29vZCBzb2x1dGlv biBhcyBsb25nIGFzIHdlIGNhbiByZXNvbHZlIGFueSANCj4+PiBiYWNrd2FyZCBjb21wYXRpYmls aXR5IGlzc3VlcyB3aXRoIGV4aXN0aW5nIGRlcGxveW1lbnRzLiBJIGdhdGhlciB3ZSANCj4+PiBo YXZlIG9uZSwgYnV0IGl0IGlzIHdoYXQgaWRlbnRpZmllZCB0aGUgcHJvYmxlbSBhbmQgc28gaXQg bmVlZHMgdG8gY2hhbmdlIGFueXdheS4NCj4+IA0KPj4gV2VsbCwgdGhlIHJlYXNvbiB3ZSBkbyB0 aGlzIGV4ZXJjaXNlIGlzIGJlY2F1c2Ugc29tZSBvZiB0aGUgZXhpc3RpbmcgZGVwbG95bWVudHMg YXJlIGJyb2tlbiANCj4+IChvciwgdGhlIHNwZWMgdGhleSBhcmUgYmFzZWQgb24gaXMgYnJva2Vu L3VuY2xlYXIpLCBzbyB3ZSBjYW4gb25seSBob3BlIHRoZXkgd2lsbCBiZSBmaXhlZC4NCj4+IA0K Pj4gQnV0LCBhdCBsZWFzdCBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgcHJvYmxlbSBjYXNlIEkgc29s dmVkLCB0aGUgZml4IHdvdWxkIGhhdmUgdG8gYmUgZG9uZSBpbiBhIA0KPj4gbmV0d29yayBkZXZp Y2UgKHRoZSBvbmUgc2VuZGluZyBVUERBVEUgd2l0aCBTLUUgd2hpbGUgdGhlIElOVklURSB0cmFu c2FjdGlvbiBpcyBzdGlsbCBvbmdvaW5nKSAtIA0KPj4gd2hpY2ggaXMgbXVjaCBlYXNpZXIgdGhh biBoYXZpbmcgdG8gZml4IGEgbGFyZ2UgYnVuY2ggb2YgU0lQIFVBcy4NCj4NCj4gT0suIElmIHlv dSBnbyB3aXRoIHRoaXMgYXBwcm9hY2gsIGl0IGlzIGltcG9ydGFudCBmb3IgdGhlIHVwZGF0ZSB0 byB0aGUgc3BlYyB0byBiZSBjbGVhciB0aGF0IGFuIFVQREFURSAod2l0aG91dCBTLUUpIA0KPiBp biB0aGUgbWlkc3Qgb2YgYSBJTlZJVEUgdHJhbnNhY3Rpb24gKmRvZXMgbm90KiBpbXBhY3QgdGhl IHN0YXR1cyBvZiB0aGUgdGhlIHRpbWVyIGJlaW5nIG5lZ290aWF0ZWQgYnkgdGhlIElOVklURSBv ciANCj4gb25lIHRoYXQgd2FzIGluIGVmZmVjdCBwcmlvciB0byB0aGUgSU5WSVRFLg0KPg0KPiAo QmVjYXVzZSBub3JtYWxseSBhbiBVUERBVEUgb3IgcmUtSU5WSVRFIHdpdGhvdXQgUy1FIHJlbW92 ZXMgYW55IHRpbWVyIHRoYXQgaXMgaW4gZWZmZWN0LikNCg0KQ29ycmVjdC4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KDQo+IA0KPj4NCj4+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4+DQo+PiBP biAyNyBPY3QgMjAxNywgYXQgMTcuNTEsIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQu ZWR1IA0KPj4gPG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCj4+DQo+Pj4g T24gMTAvMjcvMTcgODozMSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+Pj4+IEhpLA0K Pj4+Pj4+Pj4+IFllcywgSSB1bmRlcnN0YW5kIHRoYXQgaXMgdGhlIGNhc2UgeW91IGFyZSB0aGlu a2luZyBvZi4gQnV0IEkgDQo+Pj4+Pj4+Pj4gd2FzIHJhaXNpbmcgYSBkaWZmZXJlbnQgY2FzZToN Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0gdGhlIFVBQyBzZW5kcyBhbiBpbnZpdGUgd2l0aG91dCBh IFMtRS4NCj4+Pj4+Pj4+PiAtIGEgcHJveHkgYWxvbmcgdGhlIHBhdGggaW5jbHVkZXMgYW4gUy1F LiAoVGhlIFVBQyBpcyANCj4+Pj4+Pj4+PiB1bmF3YXJlLikNCj4+Pj4+Pj4+PiAtIGxhdGVyLCB0 aGUgVUFDIHNlbmRzIGFuIFVQREFURSB3aXRoIFMtRS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRo YXQgdmlvbGF0ZXMgdGhlIHJ1bGUgaW4geW91ciBkcmFmdCwgYnV0IHRoZSBVQUMgZG9lc24ndCBr bm93IA0KPj4+Pj4+Pj4+IGl0IGhhcyB2aW9sYXRlZCBpdC4gU28geW91ciBydWxlIGZvciBhdm9p ZGluZyB0aGUgcHJvYmxlbSBpbiANCj4+Pj4+Pj4+PiB0aGlzIGNhc2UgZG9lc24ndCB3b3JrLg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IFNlY3Rpb24gOC4yIGluIHRoZSBSRkMgaXMgKGluIG15IG9waW5v bikgcXVpdGUgbWVzc3ksIGJ1dCBhcyANCj4+Pj4+Pj4+IGZhciBhcyBJIHVuZGVyc3RhbmQgdGhl IHByb3h5IHdpbGwgbmV2ZXIgcmVtb3ZlIFMtRSBmcm9tIGEgcmVzcG9uc2UuDQo+Pj4+Pj4+PiBT bywgd2UgY291bGQgc2F5IHRoYXQgdGhlIFVBQyBtdXN0IG5vdCBzZW5kIFVQREFURSB3aXRoIFMt RSANCj4+Pj4+Pj4+IHVudGlsIGl0IGhhcyByZWNlaXZlZCBhIHJlc3BvbnNlIHRvIHRoZSBJTlZJ VEUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHJmYyBvbmx5IHRh bGtzIGFib3V0IHRoZSAqZmluYWwqICgyeHgpIA0KPj4+Pj4+PiByZXNwb25zZS4NCj4+Pj4+Pj4g SXQgaGFzIG5vIHByb3Zpc2lvbiBmb3IgaW5jbHVkaW5nIHRoZSBTLUUgaW4gcHJvdmlzaW9uYWwg cmVzcG9uc2VzLg0KPj4+Pj4+PiAoSXQgZG9lc24ndCBtZW50aW9uIHByb3Zpc2lvbmFsIHJlc3Bv bnNlcywgYW5kIHRoZSBUYWJsZSAxIA0KPj4+Pj4+PiB1cGRhdGUgaW4gc2VjdGlvbg0KPj4+Pj4+ PiA0IHNob3dzIHRoZSBpbnRlbnQgaXMgdG8gZXhjbHVkZSBpdC4gSGVuY2UsIGlmIHRoZSBTLUUg aXMgDQo+Pj4+Pj4+IGluc2VydGVkIGludG8gdGhlIElOVklURSBieSBhIHByb3h5LCB0aGUgVUFD IHdvbid0IGtub3cgdGhhdCBhIA0KPj4+Pj4+PiBzZXNzaW9uIHRpbWVyIGhhcyBiZWVuIHJlcXVl c3RlZCB1bnRpbCBpdCByZWNlaXZlcyB0aGUgPiBmaW5hbCANCj4+Pj4+Pj4gcmVzcG9uc2UgdG8g dGhlIGludml0ZS4NCj4+Pj4+Pj4gTWVhbndoaWxlIGl0IG1pZ2h0IGRlY2lkZSBzZW5kIGFuIFVQ REFURSB3aXRoIFMtRS4NCj4+Pj4+Pg0KPj4+Pj4+IE15IHN1Z2dlc3Rpb24gaXMgdGhhdCB0aGUg VUFDIHdvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIHNlbmQgVVBEQVRFIA0KPj4+Pj4+IHdpdGggUy1F IHVudGlsIGl0IGhhcyByZWNlaXZlZCB0aGUgZmluYWwgcmVzcG9uc2UgZm9yIHRoZSBJTlZJVEUu DQo+Pj4+Pg0KPj4+Pj4gVGhpcyBpcyBtb3JlIG9yIGxlc3MgdGhlIG9yaWdpbmFsIHByb3Bvc2Fs IHRoYXQgd2FzIHNob3QgZG93bi4gT3IgDQo+Pj4+PiBkbyB5b3UgbWVhbiB0aGF0IHRoZSAqVUFD KiBpcyByZXN0cmljdGVkIHRoYXQgd2F5LCBidXQgdGhlICpVQVMqIA0KPj4+Pj4gaXMgcGVybWl0 dGVkIHRvIHVzZSBTLUUgdG8gbmVnb3RpYXRlIHNlc3Npb24gdGltZXIgaW4gdGhlIG1pZHN0IG9m IA0KPj4+Pj4gdGhlIElOVklURSwgYXQgbGVhc3QgaW4gc29tZSBjYXNlcz8NCj4+Pj4gSSBoYXZl IGJlZW4gdGhpbmtpbmcgYWJvdXQgdGhpcywgdGFsa2VkIHRvIHNvbWUgcGVvcGxlIGV0YywgYW5k IA0KPj4+PiBwZXJoYXBzIHRoZSBlYXNpZXN0IHNvbHV0aW9uIHdvdWxkIGJlIHRvIG5vdyBhbGxv dyBVUERBVEUgd2l0aCBTLUUgDQo+Pj4+IGR1cmluZyBhbiBhY3RpdmUgSU5WSVRFIHRyYW5zYWN0 aW9uIChhcyBzdWdnZXN0ZWQgYWJvdmUpLg0KPj4+DQo+Pj4gSSBoYXZlIG5vdyBnb3R0ZW4gbG9z dCBpbiB0aGUgcHJvcG9zc2FscyBhbmQgY291bnRlciBwcm9wb3NhbHMuIENhbiANCj4+PiB5b3Ug ZXhwbGljaXRseSBzdGF0ZSB3aGF0IHlvdSBhcmUgcHJvcG9zaW5nPw0KPj4+DQo+Pj4gIMKgIMKg VGhhbmtzLA0KPj4+ICDCoCDCoFBhdWwNCj4gDQoNCg== From nobody Mon Oct 30 01:38:54 2017 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 67601139683 for ; Mon, 30 Oct 2017 01:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiBA4VVfcyZE for ; Mon, 30 Oct 2017 01:38:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 178C413B105 for ; Mon, 30 Oct 2017 01:38:50 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-02-59f6e518710b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 79.1B.03220.815E6F95; Mon, 30 Oct 2017 09:38:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Mon, 30 Oct 2017 09:38:48 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: draft-sip-push-02 Thread-Index: AQHTUVqBK2Sbcw5IcE2Vjkk6X4xTHw== Date: Mon, 30 Oct 2017 08:38:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D61CB36A24FA5christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7h67k02+RBre2M1t8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGc3f7zIVHOSouLs5qYHxAHsXIyeHhICJxP7Gj8xdjFwcQgKH GSU2L13NBuEsZpS4t+c0UBUHB5uAhUT3P22QBhEBTYnl37aChYUFdCV+PtWHCBtJnPr2ghnC 1pN4fPgWC4jNIqAq8fBSNxNIOa+AtcS0bekgYUYBMYnvp9YwgdjMAuISt57MZ4I4R0BiyZ7z zBC2qMTLx/9YQWxRoJEbTtyGOllRYufZdmaI3gSJJ9sOgNm8AoISJ2c+YZnAKDQLydhZSMpm ISmDiBtIvD83nxnC1pZYtvA1lK0vsfHLWcZZQFczA13dcCkSWckCRo5VjKLFqcVJuelGxnqp RZnJxcX5eXp5qSWbGIExcnDLb9UdjJffOB5iFOBgVOLhnX/vW6QQa2JZcWXuIUYJDmYlEd5H N4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MPqpBs0I vxVdwx2mUxhRdLjjqwqLw8vixa/faKWzpO7cURmX5B7ibr5NQ+OX2mP+3A7PsNbAH4csDGrD z9+KXHf2wx3xrK0H9dOdzbl4Z8QIuQRuX5/Pk2VyufNg4oX6jk7/Pd+tTS6+W733pUVXf09P f0rbx+eC5wqNrvpfrfmtGP13ZyOXEktxRqKhFnNRcSIAUVl0J40CAAA= Archived-At: Subject: [sipcore] Draft new version: draft-sip-push-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 08:38:52 -0000 --_000_D61CB36A24FA5christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on Paul=92s comments, I=92ve submitted a new version (-02) of draft-h= olmberg-sipcore-sip-push. Regards, Christer --_000_D61CB36A24FA5christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <68A557337FC01245868AC5C4E8099D05@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on Paul=92s comments, I=92ve submitted a new version (-02) of dr= aft-holmberg-sipcore-sip-push.

Regards,

Christer
--_000_D61CB36A24FA5christerholmbergericssoncom_-- From nobody Mon Oct 30 05:24:10 2017 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 3F98613F7B7 for ; Mon, 30 Oct 2017 05:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjB0CPZ9_Fuj for ; Mon, 30 Oct 2017 05:24:05 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F1913F784 for ; Mon, 30 Oct 2017 05:24:05 -0700 (PDT) X-AuditID: c1b4fb3a-dffff70000006897-23-59f719e3d991 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 35.CB.26775.3E917F95; Mon, 30 Oct 2017 13:24:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Mon, 30 Oct 2017 13:24:03 +0100 From: Christer Holmberg To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTPbUcSR+zWxOj3kykL3ryN5ZUgKLaZ+6AgAEJNoCAAAc9gIAAPEsggAAAZQCAHCFoAP//8tUAgAAU2ACAADwLAIADRxHAgAAFSgCAARQBAA== Date: Mon, 30 Oct 2017 12:24:02 +0000 Message-ID: References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> <7594FB04B1934943A5C02806D1A2204B5C67820D@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <85BD8AAE0B6E9D45B5CB9D8B23FEB902@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7q+5jye+RBk9XaVus2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGx6aCgp0qFVePfGRpYHwh08XIySEhYCJx aek25i5GLg4hgcOMEtNvXoFyFjNK3L72krWLkYODTcBCovufNogpIqAhMWmrGkgvs4CmxKOd e5lAbGEBOYnXnVdYQWwRAXmJ9TsvM0HYdRLfL05mBrFZBFQlGmf9BIvzClhL7L/ZyAaxaiGr xOvdj8CaOQUcJG7eegFmMwqISXw/tYYJYpm4xK0n85kgjhaQWLLnPDOELSrx8vE/sHpRAT2J DSdus0PEFSWuTl8O1asncWPqFDYI21piX+saRghbW2LZwtfMEAcJSpyc+YRlAqP4LCTrZiFp n4WkfRaS9llI2hcwsq5iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIy2g1t+W+1gPPjc8RCj AAejEg9vHMv3SCHWxLLiytxDjBIczEoivI9ufIsU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuw 70KEkEB6YklqdmpqQWoRTJaJg1OqgXHOzsD789tqHfPjzj32r3IMf7TZQPT53TTdojWlPy0z Pnk63n+521RCqnQKd0Rx95Q9z60mu9teW2L3M/BiIG/2FbkfObce7Jmf5rcwVaLrzbq0d9cE RWbt8+fpuSM39+0OkS19G5Inz7/B/GWj1HJeuz2Os/sOLvSq5/8jZxLSZcXRfdv6l6oSS3FG oqEWc1FxIgB8fvmJsgIAAA== Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 12:24:08 -0000 Hi, >>>>I am proposing that it is not allowed to include S-E in an UPDATE >>>> while there is an ongoing INVITE transaction. >>> >>> I think that is a good solution as long as we can resolve any backward >>>compatibility issues >>> with existing deployments. I gather we have one, but it is what >>>identified the problem and >>> so it needs to change anyway. >>=20 >> Well, the reason we do this exercise is because some of the existing >>deployments are broken (or, the spec they are based on is >>broken/unclear), so we can only hope they will be fixed. >>=20 >> But, at least based on the original problem case I solved, the fix >>would have to be done in a network device (the one sending UPDATE with >>S-E while the INVITE transaction is still ongoing) - which is much >>easier than having to fix a large bunch of SIP UAs. > >OK. If you go with this approach, it is important for the update to the >spec to be clear that an UPDATE (without S-E) in the midst of a INVITE >transaction *does not* impact the status of the the timer being >negotiated by the INVITE or one that was in effect prior to the INVITE. > >(Because normally an UPDATE or re-INVITE without S-E removes any timer >that is in effect.) I am not sure that is correct. Section 4 says: "The default value of the Session-Expires header field is undefined. This means that the absence of the Session-Expires header field implies no expiration of the session, using the mechanism defined in this specification." My understanding is that the timer can only be removed by not including S-E in a response, as said in section 7.2: "If the 2xx response did not contain a Session-Expires header field, there is no session expiration. In this case, no refreshes need to be sent. A 2xx without a Session-Expires can come for both initial and subsequent session refresh requests. This means that the session timer can be 'turned-off' in mid dialog by receiving a response without a Session-Expires header field.=B2 The draft DOES update that paragraph, by saying that it only applies if the associated request did contain S-E. Regards, Christer >>> Sent from my iPhone >>> >>> On 27 Oct 2017, at 17.51, Paul Kyzivat >> > wrote: >>> >>>> On 10/27/17 8:31 AM, Christer Holmberg wrote: >>>>> Hi, >>>>>>>>>> Yes, I understand that is the case you are thinking of. But I >>>>>>>>>> was raising a different case: >>>>>>>>>> >>>>>>>>>> - the UAC sends an invite without a S-E. >>>>>>>>>> - a proxy along the path includes an S-E. (The UAC is unaware.) >>>>>>>>>> - later, the UAC sends an UPDATE with S-E. >>>>>>>>>> >>>>>>>>>> That violates the rule in your draft, but the UAC doesn't know >>>>>>>>>> it has violated it. So your rule for avoiding the problem in >>>>>>>>>> this case doesn't work. >>>>>>>>> >>>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far >>>>>>>>> as I understand the proxy will never remove S-E from a response. >>>>>>>>> So, we could say that the UAC must not send UPDATE with S-E >>>>>>>>> until it has received a response to the INVITE. >>>>>>>> >>>>>>>> The problem is that the rfc only talks about the *final* (2xx) >>>>>>>> response. >>>>>>>> It has no provision for including the S-E in provisional >>>>>>>>responses. >>>>>>>> (It doesn't mention provisional responses, and the Table 1 update >>>>>>>> in section >>>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is >>>>>>>> inserted into the INVITE by a proxy, the UAC won't know that a >>>>>>>> session timer has been requested until it receives the > final >>>>>>>> response to the invite. >>>>>>>> Meanwhile it might decide send an UPDATE with S-E. >>>>>>> >>>>>>> My suggestion is that the UAC would not be allowed to send UPDATE >>>>>>> with S-E until it has received the final response for the INVITE. >>>>>> >>>>>> This is more or less the original proposal that was shot down. Or >>>>>> do you mean that the *UAC* is restricted that way, but the *UAS* is >>>>>> permitted to use S-E to negotiate session timer in the midst of the >>>>>> INVITE, at least in some cases? >>>>> I have been thinking about this, talked to some people etc, and >>>>> perhaps the easiest solution would be to now allow UPDATE with S-E >>>>> during an active INVITE transaction (as suggested above). >>>> >>>> I have now gotten lost in the propossals and counter proposals. Can >>>> you explicitly state what you are proposing? >>>> >>>> Thanks, >>>> Paul >>=20 > From nobody Mon Oct 30 06:32:32 2017 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 B485313F9D5 for ; Mon, 30 Oct 2017 06:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 1d3t3J8Syr_N for ; Mon, 30 Oct 2017 06:32:29 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 BB63213F9D4 for ; Mon, 30 Oct 2017 06:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1509370349; x=1540906349; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bSvVliW029AR9fVVVZjr8yy2zkE1nQTKTQaVYvljRTI=; b=tek11c/PeWWA44DO7Vd+sFhryK+xZSf+s5qttdhk0xMuw3sERVDMo46v G7TjnwOmBELSYB80Tmq3nTu7thHamxfuQTWOFnHSSLa6KQO8ggDh1dtQC 0CtnUJLGi1AvDiMsbijfT8rwjNMGSlry7n2+9aMZCpu9ok6DFKBD0Zk9o qGS9KwSIwvDM3hIGtI2PY3aT5z3Z0M83ZkZfJRM3dJV+e7tz0hY6VgNxx 1MLnU6H+PbPIeyv4B6KNUCsfcQ0xpw7EkFGNBgTvUEm7eE5q2k0sBsTWb 6zgtu6zQaDi7H16Kb9HkjOy0Ir16sVFYX7yqcqXg/XegzrWjSsdMRYPYM g==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2017 14:32:26 +0100 X-IronPort-AV: E=Sophos;i="5.44,320,1505772000"; d="scan'208";a="1413451030" Received: from he105870.emea1.cds.t-internal.com ([10.169.118.67]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 30 Oct 2017 14:32:25 +0100 Received: from HE101947.EMEA1.cds.t-internal.com (10.169.118.83) by HE105870.emea1.cds.t-internal.com (10.169.118.67) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 14:32:25 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101947.EMEA1.cds.t-internal.com (10.169.118.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 30 Oct 2017 14:32:25 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.24) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 14:32:15 +0100 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0484.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 13:32:21 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::bd84:f9ba:18c4:136]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::bd84:f9ba:18c4:136%14]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 13:32:21 +0000 From: "Jesske, Roland" To: Christer Holmberg , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: Session timer fix Thread-Index: AQHTUXoUfbO/SiPf+keIhIOPlUY6E6L8Wg+w Date: Mon, 30 Oct 2017 13:32:21 +0000 Message-ID: References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> <7594FB04B1934943A5C02806D1A2204B5C67820D@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0484; 6:9lMtLYDk+6q5CA0a6BmgGK5j6vL7Yk2a2I4an5vGIjgg0rH8pd8+rE2z6wVobjN+rpBghZV5gUwX2kq3nyMkzYrO0V25+x/1XgiMzEsGq7TJe5SkkDphP7uQ+pqWsJr1UVw25P0Rjlzy3D/KJV574U6fu2uACU7br73tkv1ixe5gOVluQshXgRqmp23sQFecebohWVwXEoqj55vgM04F+THhc8O7wsemY9Pow7EI1G43/AS5bYAJ/kFAkuXVNzttSMvvdreSw6tkW1kksmC+b7RvnOXThn1Y7/nE7irmLGgKPAWi+hA5NxDFUtUIXoSBIjbCGMcN+uTfPtSTGK2IO5DG0f8rhoPrbDoffOHUshc=; 5:hIMr5PhKKXeBWens1LX0w9fxuRTi8bCAbqwbbyNh0j1U0FnTpPGJCH4XcFJnFAmMEvafiLV/x1L6qU8Bs8gNNCZfnFf5ItU1Aifr+N5yVlOxh5qtKcm83ue91dsrrZREkIFDpR5nrvULFdQt9aJywmilTboC3dS1dsfYaA69cdA=; 24:CxpQgHhznjmyKLbsH/i7WrwTP31pK9z92hrkqY5k5/P74O7tlqDlklhRlBdltwFXwChCmlAig1Qi2KXNNzPypSwz6aqvWfe9q9FooZgeZmo=; 7:PojJLgdHVGaf8oWjbpPQf9wButw/u7wVYi9VTD9Z33Nz3AGe5x8G1hI1tu3j5B03CGNPPazibsqBtF9Zg/brVgkJoVamHTzk/U9QtodldAagHqpU4lZ+Y3qfG3oWY8uwEJtPfitPQu4Lre25kpXlWl/U2B1gO1Qni/6EzbbshMDfSl1z+UluF+zw4Ol9S3KfzxZzDHv5qTinvRcDEySQS7def6BKclOa+fTjxtZ7cA0W+G4WZFvyNDqCtcwEDz+b x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 670f58ea-c2dc-479a-3e03-08d51f9aa61e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:FRAPR01MB0484; x-ms-traffictypediagnostic: FRAPR01MB0484: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0484; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0484; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(51444003)(199003)(189002)(24454002)(7116003)(3280700002)(9686003)(75402003)(66066001)(8936002)(2950100002)(4326008)(53936002)(81156014)(81166006)(8676002)(97736004)(6306002)(189998001)(6116002)(102836003)(3846002)(68736007)(105586002)(74482002)(55016002)(5250100002)(106356001)(2900100001)(5003630100001)(966005)(7696004)(3660700001)(305945005)(2906002)(76176999)(54356999)(7736002)(101416001)(50986999)(72206003)(86362001)(551934003)(561944003)(33656002)(2171002)(478600001)(316002)(110136005)(93886005)(14454004)(5660300001)(53546010); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0484; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 670f58ea-c2dc-479a-3e03-08d51f9aa61e X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 13:32:21.4436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0484 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:32:32 -0000 Hi Christer, You state with regard to turning off the session timer that: The draft DOES update that paragraph, by saying that it only applies if the= associated request did contain S-E. For this I fully agree. And this issue is clarified. Then I see the statement from Paul: "Because normally an UPDATE or re-INVIT= E without S-E removes any timer that is in effect." Where you also agree. =20 I do not think that this is correct. I think it depends on the SIP field "s= upported timer". As long as there is an "supported: timer" within an UPDATE= or Re-INVITE it is the task of the UAS to agree on a Session refresh or no= t. Only the case where the UAS does not sent the S-E then I would say the sess= ion timer is turned off. I do not find any statement in Section 7.4 stating that. Or did I missed something or have I overread something in you discussion?=20 Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer > Holmberg > Gesendet: Montag, 30. Oktober 2017 13:24 > An: Paul Kyzivat > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix >=20 > Hi, >=20 > >>>>I am proposing that it is not allowed to include S-E in an UPDATE > >>>>while there is an ongoing INVITE transaction. > >>> > >>> I think that is a good solution as long as we can resolve any > >>>backward compatibility issues with existing deployments. I gather we > >>>have one, but it is what identified the problem and so it needs to > >>>change anyway. > >> > >> Well, the reason we do this exercise is because some of the existing > >>deployments are broken (or, the spec they are based on is > >>broken/unclear), so we can only hope they will be fixed. > >> > >> But, at least based on the original problem case I solved, the fix > >>would have to be done in a network device (the one sending UPDATE with > >>S-E while the INVITE transaction is still ongoing) - which is much > >>easier than having to fix a large bunch of SIP UAs. > > > >OK. If you go with this approach, it is important for the update to the > >spec to be clear that an UPDATE (without S-E) in the midst of a INVITE > >transaction *does not* impact the status of the the timer being > >negotiated by the INVITE or one that was in effect prior to the INVITE. > > > >(Because normally an UPDATE or re-INVITE without S-E removes any timer > >that is in effect.) >=20 > I am not sure that is correct. >=20 > Section 4 says: >=20 > "The default value of the Session-Expires header field is undefined. > This means that the absence of the Session-Expires header field > implies no expiration of the session, using the mechanism defined in > this specification." >=20 >=20 > My understanding is that the timer can only be removed by not including S= -E in > a response, as said in section 7.2: >=20 > "If the 2xx response did not contain a Session-Expires header field, > there is no session expiration. In this case, no refreshes need to > be sent. A 2xx without a Session-Expires can come for both initial > and subsequent session refresh requests. This means that the sessi= on > timer can be 'turned-off' in mid dialog by receiving a response > without a Session-Expires header field.=B2 >=20 >=20 > The draft DOES update that paragraph, by saying that it only applies if t= he > associated request did contain S-E. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > >>> Sent from my iPhone > >>> > >>> On 27 Oct 2017, at 17.51, Paul Kyzivat >>> > wrote: > >>> > >>>> On 10/27/17 8:31 AM, Christer Holmberg wrote: > >>>>> Hi, > >>>>>>>>>> Yes, I understand that is the case you are thinking of. But I > >>>>>>>>>> was raising a different case: > >>>>>>>>>> > >>>>>>>>>> - the UAC sends an invite without a S-E. > >>>>>>>>>> - a proxy along the path includes an S-E. (The UAC is > >>>>>>>>>> unaware.) > >>>>>>>>>> - later, the UAC sends an UPDATE with S-E. > >>>>>>>>>> > >>>>>>>>>> That violates the rule in your draft, but the UAC doesn't > >>>>>>>>>> know it has violated it. So your rule for avoiding the > >>>>>>>>>> problem in this case doesn't work. > >>>>>>>>> > >>>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as > >>>>>>>>> far as I understand the proxy will never remove S-E from a > response. > >>>>>>>>> So, we could say that the UAC must not send UPDATE with S-E > >>>>>>>>> until it has received a response to the INVITE. > >>>>>>>> > >>>>>>>> The problem is that the rfc only talks about the *final* (2xx) > >>>>>>>>response. > >>>>>>>> It has no provision for including the S-E in provisional > >>>>>>>>responses. > >>>>>>>> (It doesn't mention provisional responses, and the Table 1 > >>>>>>>>update in section > >>>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is > >>>>>>>>inserted into the INVITE by a proxy, the UAC won't know that a > >>>>>>>>session timer has been requested until it receives the > final > >>>>>>>>response to the invite. > >>>>>>>> Meanwhile it might decide send an UPDATE with S-E. > >>>>>>> > >>>>>>> My suggestion is that the UAC would not be allowed to send > >>>>>>> UPDATE with S-E until it has received the final response for the > INVITE. > >>>>>> > >>>>>> This is more or less the original proposal that was shot down. Or > >>>>>> do you mean that the *UAC* is restricted that way, but the *UAS* > >>>>>> is permitted to use S-E to negotiate session timer in the midst > >>>>>> of the INVITE, at least in some cases? > >>>>> I have been thinking about this, talked to some people etc, and > >>>>> perhaps the easiest solution would be to now allow UPDATE with S-E > >>>>> during an active INVITE transaction (as suggested above). > >>>> > >>>> I have now gotten lost in the propossals and counter proposals. Can > >>>> you explicitly state what you are proposing? > >>>> > >>>> Thanks, > >>>> Paul > >> > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Oct 30 06:38:28 2017 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 BBCDB13F444 for ; Mon, 30 Oct 2017 06:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOX80w1iRaAu for ; Mon, 30 Oct 2017 06:38:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B6213F4F4 for ; Mon, 30 Oct 2017 06:38:24 -0700 (PDT) X-AuditID: c1b4fb2d-bf5ff7000000268d-01-59f72b4e2a8f Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.2F.09869.E4B27F95; Mon, 30 Oct 2017 14:38:22 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 30 Oct 2017 14:38:21 +0100 From: Christer Holmberg To: "Jesske, Roland" , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: AW: Session timer fix Thread-Index: AQHTUYRaNQk5paWN/k6WFLPj89rehA== Date: Mon, 30 Oct 2017 13:38:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="windows-1254" Content-ID: <3942D4580650054E89D5207675BC26AA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7ga6f9vdIgwVv5SxWbDjAatF0p4vN 4uuPTWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6MrXcusRXsMq6Y2fyEuYHx ukYXIyeHhICJxPyrUxi7GLk4hAQOM0pcbetngnAWM0ocmtIDlOHgYBOwkOj+pw3SICIQJHHq zi92EJtZQFPi0c69TCC2sICSxIKmRSwg5SICyhI7GpkgyvUkXv6bBFbOIqAqcfrUahYQm1fA WuLQqUXMIDajgJjE91NrmCBGikvcejKfCeI2AYkle84zQ9iiEi8f/2MFsUWBZm44cZsdIq4k 8WPDJRaIXgOJI+duskLY1hI/vkxkhLC1JZYtfM0MsVdQ4uTMJywTGEVnIVk3C0n7LCTts5C0 z0LSvoCRdRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYDwd3PJbdwfj6teOhxgFOBiVeHiP K32PFGJNLCuuzD3EKMHBrCTCu0oRKMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+FCCGB9MSS 1OzU1ILUIpgsEwenVAPjmvisvIt/xPyP/ZjQkXSgtuJddaqO6utTbtedQoUcNuwV2lf4oouV M1Jt4fxdqx2jP835eeBEYeZKmw8Htxh3ap7Kufdkx+co1yChZOu1Mb81ttdO6lXMNPs4STXh uKdPP28D47Y7q3ZedktpY9VdyTrRufjRqpmp11VfOjbmWhbd5eX1uvlTiaU4I9FQi7moOBEA /vMIxqMCAAA= Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:38:28 -0000 Hi, >You state with regard to turning off the session timer that: >The draft DOES update that paragraph, by saying that it only applies if >the associated request did contain S-E. > >For this I fully agree. And this issue is clarified. > >Then I see the statement from Paul: "Because normally an UPDATE or >re-INVITE without S-E removes any timer that is in effect." Where you >also agree. >=20 >I do not think that this is correct. I think it depends on the SIP field >"supported timer". As long as there is an "supported: timer" within an >UPDATE or Re-INVITE it is the task of the UAS to agree on a Session >refresh or not. >Only the case where the UAS does not sent the S-E then I would say the >session timer is turned off. > >I do not find any statement in Section 7.4 stating that. > >Or did I missed something or have I overread something in you discussion? Yes :) I actually disagreed with Paul=92s statement, and pointed to section 7.4 which says that the session timer can only be turned off in a response. Regards, Christer >> -----Urspr=FCngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer >> Holmberg >> Gesendet: Montag, 30. Oktober 2017 13:24 >> An: Paul Kyzivat >> Cc: sipcore@ietf.org >> Betreff: Re: [sipcore] Session timer fix >>=20 >> Hi, >>=20 >> >>>>I am proposing that it is not allowed to include S-E in an UPDATE >> >>>>while there is an ongoing INVITE transaction. >> >>> >> >>> I think that is a good solution as long as we can resolve any >> >>>backward compatibility issues with existing deployments. I gather we >> >>>have one, but it is what identified the problem and so it needs to >> >>>change anyway. >> >> >> >> Well, the reason we do this exercise is because some of the existing >> >>deployments are broken (or, the spec they are based on is >> >>broken/unclear), so we can only hope they will be fixed. >> >> >> >> But, at least based on the original problem case I solved, the fix >> >>would have to be done in a network device (the one sending UPDATE with >> >>S-E while the INVITE transaction is still ongoing) - which is much >> >>easier than having to fix a large bunch of SIP UAs. >> > >> >OK. If you go with this approach, it is important for the update to the >> >spec to be clear that an UPDATE (without S-E) in the midst of a INVITE >> >transaction *does not* impact the status of the the timer being >> >negotiated by the INVITE or one that was in effect prior to the INVITE. >> > >> >(Because normally an UPDATE or re-INVITE without S-E removes any timer >> >that is in effect.) >>=20 >> I am not sure that is correct. >>=20 >> Section 4 says: >>=20 >> "The default value of the Session-Expires header field is undefined. >> This means that the absence of the Session-Expires header field >> implies no expiration of the session, using the mechanism defined >>in >> this specification." >>=20 >>=20 >> My understanding is that the timer can only be removed by not including >>S-E in >> a response, as said in section 7.2: >>=20 >> "If the 2xx response did not contain a Session-Expires header >>field, >> there is no session expiration. In this case, no refreshes need >>to >> be sent. A 2xx without a Session-Expires can come for both >>initial >> and subsequent session refresh requests. This means that the >>session >> timer can be 'turned-off' in mid dialog by receiving a response >> without a Session-Expires header field.=B2 >>=20 >>=20 >> The draft DOES update that paragraph, by saying that it only applies if >>the >> associated request did contain S-E. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >> >>> Sent from my iPhone >> >>> >> >>> On 27 Oct 2017, at 17.51, Paul Kyzivat > >>> > wrote: >> >>> >> >>>> On 10/27/17 8:31 AM, Christer Holmberg wrote: >> >>>>> Hi, >> >>>>>>>>>> Yes, I understand that is the case you are thinking of. But I >> >>>>>>>>>> was raising a different case: >> >>>>>>>>>> >> >>>>>>>>>> - the UAC sends an invite without a S-E. >> >>>>>>>>>> - a proxy along the path includes an S-E. (The UAC is >> >>>>>>>>>> unaware.) >> >>>>>>>>>> - later, the UAC sends an UPDATE with S-E. >> >>>>>>>>>> >> >>>>>>>>>> That violates the rule in your draft, but the UAC doesn't >> >>>>>>>>>> know it has violated it. So your rule for avoiding the >> >>>>>>>>>> problem in this case doesn't work. >> >>>>>>>>> >> >>>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as >> >>>>>>>>> far as I understand the proxy will never remove S-E from a >> response. >> >>>>>>>>> So, we could say that the UAC must not send UPDATE with S-E >> >>>>>>>>> until it has received a response to the INVITE. >> >>>>>>>> >> >>>>>>>> The problem is that the rfc only talks about the *final* (2xx) >> >>>>>>>>response. >> >>>>>>>> It has no provision for including the S-E in provisional >> >>>>>>>>responses. >> >>>>>>>> (It doesn't mention provisional responses, and the Table 1 >> >>>>>>>>update in section >> >>>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is >> >>>>>>>>inserted into the INVITE by a proxy, the UAC won't know that a >> >>>>>>>>session timer has been requested until it receives the > final >> >>>>>>>>response to the invite. >> >>>>>>>> Meanwhile it might decide send an UPDATE with S-E. >> >>>>>>> >> >>>>>>> My suggestion is that the UAC would not be allowed to send >> >>>>>>> UPDATE with S-E until it has received the final response for the >> INVITE. >> >>>>>> >> >>>>>> This is more or less the original proposal that was shot down. Or >> >>>>>> do you mean that the *UAC* is restricted that way, but the *UAS* >> >>>>>> is permitted to use S-E to negotiate session timer in the midst >> >>>>>> of the INVITE, at least in some cases? >> >>>>> I have been thinking about this, talked to some people etc, and >> >>>>> perhaps the easiest solution would be to now allow UPDATE with S-E >> >>>>> during an active INVITE transaction (as suggested above). >> >>>> >> >>>> I have now gotten lost in the propossals and counter proposals. Can >> >>>> you explicitly state what you are proposing? >> >>>> >> >>>> Thanks, >> >>>> Paul >> >> >> > >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Oct 30 07:13:37 2017 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 4DE5C13F54B for ; Mon, 30 Oct 2017 07:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 bICzBuQt8Bs7 for ; Mon, 30 Oct 2017 07:13:31 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 66946138BD8 for ; Mon, 30 Oct 2017 07:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1509372810; x=1540908810; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8QRMur/tfzUAXDtp2f/TXWb5IP+U/2l79EDHAWJG/6o=; b=xkA9HnRbYZpBJCsyMpS9+zSpnVWSHYvjPhusRT11pT6cCatPGfLkXh9K pyjSYL6FsxtMFvF04dOtKaQc2YQ3wsL4Qg7gJGhWIrpR/T0/UcLDKASTl NQ6Oh6nLqcuIvGar2H8IPezGCL6eDa7IM/Zo28UpboWS9RE8sZ+KG0/u9 JU3DgT9tb8K9tlKSQMpxlczSnkUAnUusTTQ5DFga828ol3EXmh9+2OCJN iMsK67MWKHg0Lgv2jVnGr4TKvoyYPSL+VKGrm7CBKYtaIEjCvmSATktUa FPPM4VftDvUZbBk47Jz/ttusnPiqEC0V+7QwgoAk5WOY0dcPAnpkWJaAD w==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2017 15:13:27 +0100 X-IronPort-AV: E=Sophos;i="5.44,320,1505772000"; d="scan'208";a="687063774" Received: from he101943.emea1.cds.t-internal.com ([10.169.119.83]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 30 Oct 2017 15:13:27 +0100 Received: from HE104993.EMEA1.cds.t-internal.com (10.169.119.36) by HE101943.emea1.cds.t-internal.com (10.169.119.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 15:13:27 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE104993.EMEA1.cds.t-internal.com (10.169.119.36) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 30 Oct 2017 15:13:27 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.22) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Oct 2017 15:12:53 +0100 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0484.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 14:13:26 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::bd84:f9ba:18c4:136]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::bd84:f9ba:18c4:136%14]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 14:13:26 +0000 From: "Jesske, Roland" To: Christer Holmberg , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: AW: Session timer fix Thread-Index: AQHTUYRaNQk5paWN/k6WFLPj89rehKL8bNTg Date: Mon, 30 Oct 2017 14:13:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0484; 6:CpQKUT7JDUctKuACMeue5lmvj2/tu573FBLFnCcV9HYXTxDr5P2x/Tin3f1chrwkKkIPx73d6hZO8toT18OE9+Jk3DdrI/BH9Jjkvm6T89hDzJNT2NN4NpyT8Sl4D2q7skgQG00Y40pSiJzb6b8zaShrCtwCsnWaOTi9mTZ7hWVxj9R18LdqqVRgy6i5+BELQ72kKfppWkrw0S/6jDVgiI+pu69GPY0c3gZZiPS8owzLnHDioEEZXVOb9+nNFwbR+L1UOF8s2Yxn8IODfefvz8Vl140+9znwdXFk4RTq91njA0RB/tYW1gtbilOR0UJcJFUBe9nkaTkNzA1nJunmZd9yPSW3RtM44MesZuTAnP8=; 5:n1A1GDINJRuERzyX3g2hKR3ocXk4vHJIqvpQMdIMm+IRYjGtAAy5Y7vavGrMmJqkyu/j+VpMQH+iJlqVTxunj+Y9PLvoEsXs55pd3ED72C9xh+iQ1LE6Vq76bb8NlKTvFtodBHcgmllalMGDNFNc6lsuh2qEDyWJ+NIXctPcH6s=; 24:eVE70HbUYfoN5ssqIpHvxpp534d+NKu66a2xSvf8TZTdtkDkqjJj9WytVM0Fe2clTb6aeKs3rU9PpSA0gCkRg1BQ1wppW2LrPupbj9ePwns=; 7:u5IlkuhO+WR25SBggmVJ2LBVjDJHS02em8qT8DWxdspy1OdHWeJaxDtfIIdtooK3BQOzYYGdiQuV0nKV31ubnplnXBtkgiM993Hgqw8a/Zb5SN9qXvssyEUb8UFpHRErexBX5sFiSe+uXlX1D4aGYXZyYx5m4wsCmR9KXc/tWfWtHakDX+swr1AGdNiCl4rTOAHAQgvbtMyVWUjJsHgbUtaJkRzCcbY9/Ya/mddJmteV0f5Zn4Kkz0hDDON6uFa2 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 55f52dab-8456-4475-8151-08d51fa0634c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:FRAPR01MB0484; x-ms-traffictypediagnostic: FRAPR01MB0484: x-exchange-antispam-report-test: UriScan:(37575265505322); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0484; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0484; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(24454002)(199003)(51444003)(189002)(551934003)(561944003)(86362001)(72206003)(33656002)(7696004)(3660700001)(5003630100001)(966005)(7736002)(54356999)(76176999)(50986999)(101416001)(2906002)(305945005)(14454004)(5660300001)(53546010)(478600001)(2171002)(316002)(110136005)(53936002)(4326008)(8676002)(6306002)(97736004)(81156014)(81166006)(8936002)(3280700002)(66066001)(9686003)(75402003)(2950100002)(106356001)(2900100001)(3846002)(189998001)(102836003)(6116002)(105586002)(74482002)(55016002)(5250100002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0484; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 55f52dab-8456-4475-8151-08d51fa0634c X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 14:13:26.3511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0484 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:13:36 -0000 So for the second case: If I send an session refresh without S-E and receive a response with S-E --= > still session timer switched on. And only in the case S-E in request and response absent then --> Session ti= mer switched off. Yes? If yes can we document that? Like an addition to Section 7.4 like NEW TEXT: If the request did not contain a Session-Expires header field, and the associated 2xx response did not contain a Session-Expires header field, there is no session expiration. In this case, no refreshes need to be sent. This means that the session timer can be 'turned-off' in mid dialog by sending a reques= t=20 without a Session-Expires header field but only when the UAS responds with = a 2xx without a Session-Expires. I think Section 7.4 is not very clear on this. Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Gesendet: Montag, 30. Oktober 2017 14:38 > An: Jesske, Roland ; Paul Kyzivat > > Cc: sipcore@ietf.org > Betreff: Re: AW: Session timer fix >=20 > Hi, >=20 > >You state with regard to turning off the session timer that: > >The draft DOES update that paragraph, by saying that it only applies if > >the associated request did contain S-E. > > > >For this I fully agree. And this issue is clarified. > > > >Then I see the statement from Paul: "Because normally an UPDATE or > >re-INVITE without S-E removes any timer that is in effect." Where you > >also agree. > > > >I do not think that this is correct. I think it depends on the SIP > >field "supported timer". As long as there is an "supported: timer" > >within an UPDATE or Re-INVITE it is the task of the UAS to agree on a > >Session refresh or not. > >Only the case where the UAS does not sent the S-E then I would say the > >session timer is turned off. > > > >I do not find any statement in Section 7.4 stating that. > > > >Or did I missed something or have I overread something in you discussion= ? >=20 > Yes :) >=20 > I actually disagreed with Paul's statement, and pointed to section 7.4 wh= ich > says that the session timer can only be turned off in a response. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von > >> Christer Holmberg > >> Gesendet: Montag, 30. Oktober 2017 13:24 > >> An: Paul Kyzivat > >> Cc: sipcore@ietf.org > >> Betreff: Re: [sipcore] Session timer fix > >> > >> Hi, > >> > >> >>>>I am proposing that it is not allowed to include S-E in an UPDATE > >> >>>>while there is an ongoing INVITE transaction. > >> >>> > >> >>> I think that is a good solution as long as we can resolve any > >> >>>backward compatibility issues with existing deployments. I gather > >> >>>we have one, but it is what identified the problem and so it > >> >>>needs to change anyway. > >> >> > >> >> Well, the reason we do this exercise is because some of the > >> >>existing deployments are broken (or, the spec they are based on is > >> >>broken/unclear), so we can only hope they will be fixed. > >> >> > >> >> But, at least based on the original problem case I solved, the fix > >> >>would have to be done in a network device (the one sending UPDATE > >> >>with S-E while the INVITE transaction is still ongoing) - which is > >> >>much easier than having to fix a large bunch of SIP UAs. > >> > > >> >OK. If you go with this approach, it is important for the update to > >> >the spec to be clear that an UPDATE (without S-E) in the midst of a > >> >INVITE transaction *does not* impact the status of the the timer > >> >being negotiated by the INVITE or one that was in effect prior to the > INVITE. > >> > > >> >(Because normally an UPDATE or re-INVITE without S-E removes any > >> >timer that is in effect.) > >> > >> I am not sure that is correct. > >> > >> Section 4 says: > >> > >> "The default value of the Session-Expires header field is undefine= d. > >> This means that the absence of the Session-Expires header field > >> implies no expiration of the session, using the mechanism > >>defined in > >> this specification." > >> > >> > >> My understanding is that the timer can only be removed by not > >>including S-E in a response, as said in section 7.2: > >> > >> "If the 2xx response did not contain a Session-Expires header > >>field, > >> there is no session expiration. In this case, no refreshes > >>need to > >> be sent. A 2xx without a Session-Expires can come for both > >>initial > >> and subsequent session refresh requests. This means that the > >>session > >> timer can be 'turned-off' in mid dialog by receiving a response > >> without a Session-Expires header field.=B2 > >> > >> > >> The draft DOES update that paragraph, by saying that it only applies > >>if the associated request did contain S-E. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> >>> Sent from my iPhone > >> >>> > >> >>> On 27 Oct 2017, at 17.51, Paul Kyzivat >> >>> > wrote: > >> >>> > >> >>>> On 10/27/17 8:31 AM, Christer Holmberg wrote: > >> >>>>> Hi, > >> >>>>>>>>>> Yes, I understand that is the case you are thinking of. > >> >>>>>>>>>> But I was raising a different case: > >> >>>>>>>>>> > >> >>>>>>>>>> - the UAC sends an invite without a S-E. > >> >>>>>>>>>> - a proxy along the path includes an S-E. (The UAC is > >> >>>>>>>>>> unaware.) > >> >>>>>>>>>> - later, the UAC sends an UPDATE with S-E. > >> >>>>>>>>>> > >> >>>>>>>>>> That violates the rule in your draft, but the UAC doesn't > >> >>>>>>>>>> know it has violated it. So your rule for avoiding the > >> >>>>>>>>>> problem in this case doesn't work. > >> >>>>>>>>> > >> >>>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but > >> >>>>>>>>> as far as I understand the proxy will never remove S-E from > >> >>>>>>>>> a > >> response. > >> >>>>>>>>> So, we could say that the UAC must not send UPDATE with S-E > >> >>>>>>>>> until it has received a response to the INVITE. > >> >>>>>>>> > >> >>>>>>>> The problem is that the rfc only talks about the *final* > >> >>>>>>>>(2xx) response. > >> >>>>>>>> It has no provision for including the S-E in provisional > >> >>>>>>>>responses. > >> >>>>>>>> (It doesn't mention provisional responses, and the Table 1 > >> >>>>>>>>update in section > >> >>>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is > >> >>>>>>>>inserted into the INVITE by a proxy, the UAC won't know that > >> >>>>>>>>a session timer has been requested until it receives the > > >> >>>>>>>>final response to the invite. > >> >>>>>>>> Meanwhile it might decide send an UPDATE with S-E. > >> >>>>>>> > >> >>>>>>> My suggestion is that the UAC would not be allowed to send > >> >>>>>>> UPDATE with S-E until it has received the final response for > >> >>>>>>> the > >> INVITE. > >> >>>>>> > >> >>>>>> This is more or less the original proposal that was shot down. > >> >>>>>> Or do you mean that the *UAC* is restricted that way, but the > >> >>>>>> *UAS* is permitted to use S-E to negotiate session timer in > >> >>>>>> the midst of the INVITE, at least in some cases? > >> >>>>> I have been thinking about this, talked to some people etc, and > >> >>>>> perhaps the easiest solution would be to now allow UPDATE with > >> >>>>> S-E during an active INVITE transaction (as suggested above). > >> >>>> > >> >>>> I have now gotten lost in the propossals and counter proposals. > >> >>>> Can you explicitly state what you are proposing? > >> >>>> > >> >>>> Thanks, > >> >>>> Paul > >> >> > >> > > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Oct 30 07:20:32 2017 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 9713B13F444 for ; Mon, 30 Oct 2017 07:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_flIxxN9OSH for ; Mon, 30 Oct 2017 07:20:21 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 0CDEE139F18 for ; Mon, 30 Oct 2017 07:20:20 -0700 (PDT) X-AuditID: c1b4fb30-ef1ff70000001b7f-e0-59f735238898 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1E.39.07039.32537F95; Mon, 30 Oct 2017 15:20:19 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Mon, 30 Oct 2017 15:20:18 +0100 From: Christer Holmberg To: "Jesske, Roland" , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: AW: AW: Session timer fix Thread-Index: AQHTUYo2aPXolYE0wUOZQxb7inVz8w== Date: Mon, 30 Oct 2017 14:20:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdS1fZ9HukwayD4hYrNhxgtWi608Vm 8fXHJjYHZo+/7z8weSxZ8pPJo+2lQgBzFJdNSmpOZllqkb5dAlfGs66F7AULnCoWtYk1ML42 7mLk5JAQMJGYtK6ZqYuRi0NI4DCjxKyfM5khnMWMEt9/XWHpYuTgYBOwkOj+pw3SICIQJHHq zi92EJtZQFPi0c69TCC2sICaxJP5S5ghatQlrj/qZIGw9SQa7nSD1bMIqEqcP/cAzOYVsJa4 vLUHrJdRQEzi+6k1TBAzxSVuPZnPBHGcgMSSPeeZIWxRiZeP/7GC2KJAMzecuM0OcpqEgKLE 8n45iFYDiSPnbrJC2NYSMzd+hBqpLbFs4WtmiLWCEidnPmGZwCg6C8m2WUjaZyFpn4WkfRaS 9gWMrKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAqPp4JbfBjsYXz53PMQowMGoxMP7SOF7 pBBrYllxZe4hRgkOZiUR3lWKQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8jvsuRAgJpCeWpGan phakFsFkmTg4pRoYuT++PKiiOP/wdumw05eOxys4zJBMe6smOt83ccHhC017v1jmb920/csn b6cvWU83rV7CLfAsxfmo6HmRsoUZdwy3XcoSOF7E9YR90dcAm0uSvzOtt7ZPWvm36L/UNZvX Hy/MfPx40fbdoSfyzxyuSLygkvs0Ln6m6fajDFV+UemPGbu/sCz41K3EUpyRaKjFXFScCAAu U0y4ogIAAA== Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:20:30 -0000 Hi, >So for the second case: >If I send an session refresh without S-E and receive a response with S-E >--> still session timer switched on. Yes (at least that is my understanding of the text). >And only in the case S-E in request and response absent then --> Session >timer switched off. > >Yes? Yes (at least that is my understanding of the text). >If yes can we document that? >Like an addition to Section 7.4 like NEW TEXT: > > If the request did not contain a Session-Expires header field, and the > associated 2xx response did not contain a Session-Expires header > field, there is no session expiration. In this case, no refreshes > need to be sent. This means that > the session timer can be 'turned-off' in mid dialog by sending a >request=20 >without a Session-Expires header field but only when the UAS responds >with a 2xx without a Session-Expires. > >I think Section 7.4 is not very clear on this. I assume you mean Section 7.2? We can for sure make the text more clear. Regards, Christer >> -----Urspr=FCngliche Nachricht----- >> Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Gesendet: Montag, 30. Oktober 2017 14:38 >> An: Jesske, Roland ; Paul Kyzivat >> >> Cc: sipcore@ietf.org >> Betreff: Re: AW: Session timer fix >>=20 >> Hi, >>=20 >> >You state with regard to turning off the session timer that: >> >The draft DOES update that paragraph, by saying that it only applies if >> >the associated request did contain S-E. >> > >> >For this I fully agree. And this issue is clarified. >> > >> >Then I see the statement from Paul: "Because normally an UPDATE or >> >re-INVITE without S-E removes any timer that is in effect." Where you >> >also agree. >> > >> >I do not think that this is correct. I think it depends on the SIP >> >field "supported timer". As long as there is an "supported: timer" >> >within an UPDATE or Re-INVITE it is the task of the UAS to agree on a >> >Session refresh or not. >> >Only the case where the UAS does not sent the S-E then I would say the >> >session timer is turned off. >> > >> >I do not find any statement in Section 7.4 stating that. >> > >> >Or did I missed something or have I overread something in you >>discussion? >>=20 >> Yes :) >>=20 >> I actually disagreed with Paul's statement, and pointed to section 7.4 >>which >> says that the session timer can only be turned off in a response. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >> >> -----Urspr=FCngliche Nachricht----- >> >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >> >> Christer Holmberg >> >> Gesendet: Montag, 30. Oktober 2017 13:24 >> >> An: Paul Kyzivat >> >> Cc: sipcore@ietf.org >> >> Betreff: Re: [sipcore] Session timer fix >> >> >> >> Hi, >> >> >> >> >>>>I am proposing that it is not allowed to include S-E in an UPDATE >> >> >>>>while there is an ongoing INVITE transaction. >> >> >>> >> >> >>> I think that is a good solution as long as we can resolve any >> >> >>>backward compatibility issues with existing deployments. I gather >> >> >>>we have one, but it is what identified the problem and so it >> >> >>>needs to change anyway. >> >> >> >> >> >> Well, the reason we do this exercise is because some of the >> >> >>existing deployments are broken (or, the spec they are based on is >> >> >>broken/unclear), so we can only hope they will be fixed. >> >> >> >> >> >> But, at least based on the original problem case I solved, the fix >> >> >>would have to be done in a network device (the one sending UPDATE >> >> >>with S-E while the INVITE transaction is still ongoing) - which is >> >> >>much easier than having to fix a large bunch of SIP UAs. >> >> > >> >> >OK. If you go with this approach, it is important for the update to >> >> >the spec to be clear that an UPDATE (without S-E) in the midst of a >> >> >INVITE transaction *does not* impact the status of the the timer >> >> >being negotiated by the INVITE or one that was in effect prior to >>the >> INVITE. >> >> > >> >> >(Because normally an UPDATE or re-INVITE without S-E removes any >> >> >timer that is in effect.) >> >> >> >> I am not sure that is correct. >> >> >> >> Section 4 says: >> >> >> >> "The default value of the Session-Expires header field is >>undefined. >> >> This means that the absence of the Session-Expires header field >> >> implies no expiration of the session, using the mechanism >> >>defined in >> >> this specification." >> >> >> >> >> >> My understanding is that the timer can only be removed by not >> >>including S-E in a response, as said in section 7.2: >> >> >> >> "If the 2xx response did not contain a Session-Expires header >> >>field, >> >> there is no session expiration. In this case, no refreshes >> >>need to >> >> be sent. A 2xx without a Session-Expires can come for both >> >>initial >> >> and subsequent session refresh requests. This means that the >> >>session >> >> timer can be 'turned-off' in mid dialog by receiving a response >> >> without a Session-Expires header field.=B2 >> >> >> >> >> >> The draft DOES update that paragraph, by saying that it only applies >> >>if the associated request did contain S-E. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> >> >> >>> Sent from my iPhone >> >> >>> >> >> >>> On 27 Oct 2017, at 17.51, Paul Kyzivat > >> >>> > wrote: >> >> >>> >> >> >>>> On 10/27/17 8:31 AM, Christer Holmberg wrote: >> >> >>>>> Hi, >> >> >>>>>>>>>> Yes, I understand that is the case you are thinking of. >> >> >>>>>>>>>> But I was raising a different case: >> >> >>>>>>>>>> >> >> >>>>>>>>>> - the UAC sends an invite without a S-E. >> >> >>>>>>>>>> - a proxy along the path includes an S-E. (The UAC is >> >> >>>>>>>>>> unaware.) >> >> >>>>>>>>>> - later, the UAC sends an UPDATE with S-E. >> >> >>>>>>>>>> >> >> >>>>>>>>>> That violates the rule in your draft, but the UAC doesn't >> >> >>>>>>>>>> know it has violated it. So your rule for avoiding the >> >> >>>>>>>>>> problem in this case doesn't work. >> >> >>>>>>>>> >> >> >>>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but >> >> >>>>>>>>> as far as I understand the proxy will never remove S-E from >> >> >>>>>>>>> a >> >> response. >> >> >>>>>>>>> So, we could say that the UAC must not send UPDATE with S-E >> >> >>>>>>>>> until it has received a response to the INVITE. >> >> >>>>>>>> >> >> >>>>>>>> The problem is that the rfc only talks about the *final* >> >> >>>>>>>>(2xx) response. >> >> >>>>>>>> It has no provision for including the S-E in provisional >> >> >>>>>>>>responses. >> >> >>>>>>>> (It doesn't mention provisional responses, and the Table 1 >> >> >>>>>>>>update in section >> >> >>>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is >> >> >>>>>>>>inserted into the INVITE by a proxy, the UAC won't know that >> >> >>>>>>>>a session timer has been requested until it receives the > >> >> >>>>>>>>final response to the invite. >> >> >>>>>>>> Meanwhile it might decide send an UPDATE with S-E. >> >> >>>>>>> >> >> >>>>>>> My suggestion is that the UAC would not be allowed to send >> >> >>>>>>> UPDATE with S-E until it has received the final response for >> >> >>>>>>> the >> >> INVITE. >> >> >>>>>> >> >> >>>>>> This is more or less the original proposal that was shot down. >> >> >>>>>> Or do you mean that the *UAC* is restricted that way, but the >> >> >>>>>> *UAS* is permitted to use S-E to negotiate session timer in >> >> >>>>>> the midst of the INVITE, at least in some cases? >> >> >>>>> I have been thinking about this, talked to some people etc, and >> >> >>>>> perhaps the easiest solution would be to now allow UPDATE with >> >> >>>>> S-E during an active INVITE transaction (as suggested above). >> >> >>>> >> >> >>>> I have now gotten lost in the propossals and counter proposals. >> >> >>>> Can you explicitly state what you are proposing? >> >> >>>> >> >> >>>> Thanks, >> >> >>>> Paul >> >> >> >> >> > >> >> >> >> _______________________________________________ >> >> sipcore mailing list >> >> sipcore@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Oct 30 07:37:49 2017 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 1F91E13FA0B for ; Mon, 30 Oct 2017 07:37:48 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVebDKvkSoBj for ; Mon, 30 Oct 2017 07:37:46 -0700 (PDT) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6F39413FA09 for ; Mon, 30 Oct 2017 07:37:46 -0700 (PDT) X-AuditID: 1207440f-a43ff70000007960-74-59f7393755bc Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id CC.91.31072.83937F95; Mon, 30 Oct 2017 10:37:44 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9UEbggR029355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 30 Oct 2017 10:37:43 -0400 To: Christer Holmberg Cc: "sipcore@ietf.org" References: <4555d239-2c1e-6f36-19d8-b2d69fa3cf5b@alum.mit.edu> <04077b98-6791-8eb2-8bbf-391c91c6bf11@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B56320A61@ESESSMB109.ericsson.se> <120396cb-c884-3851-de9f-1a7dcdffd8b9@alum.mit.edu> <9E1E6574-6A26-49BE-BD7D-151EAD006B28@ericsson.com> <7594FB04B1934943A5C02806D1A2204B5C67820D@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 30 Oct 2017 10:37:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IRYndR1LWw/B5p8PaVtcWFmYcZLb7+2MTm wOTx6+tVNo8lS34yBTBFcdmkpOZklqUW6dslcGWsumhb8EO2Ys2Jl4wNjLPEuxg5OSQETCRm bnzH3MXIxSEksINJYk/jYVaQhJDAQyaJp/1FILawgJzE684rYHERATOJ6597mUBsZgFNic3r LrBDNF9mlZjQeowdJMEmoCUx59B/li5GDg5eAXuJC38jQcIsAqoSMz++YwSxRQXSJO7MeAg2 h1dAUOLkzCcsIDangI3E+20r2SDmm0nM2/yQGcIWl7j1ZD7UXnmJ5q2zmScwCsxC0j4LScss JC2zkLQsYGRZxSiXmFOaq5ubmJlTnJqsW5ycmJeXWqRropebWaKXmlK6iRESvvw7GLvWyxxi FOBgVOLh1cj8FinEmlhWXJl7iFGSg0lJlJerASjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHex yfdIId6UxMqq1KJ8mJQ0B4uSOK/6EnU/IYH0xJLU7NTUgtQimKwMB4eSBK+SBVCjYFFqempF WmZOCUKaiYMTZDgP0HBvkBre4oLE3OLMdIj8KUZjjp6eG3+YOJ7NfN3ALMSSl5+XKiXOWwBS KgBSmlGaBzcNloJeMYoDPSfMKwRSxQNMX3DzXgGtYgJapSH5BWRVSSJCSqqBseTyJ26OKC3W ezYa13SfB7JFu3VZ+wl933rF42LIUYssl+sxXZMmPHru0j2LPfFr29Vz7+RXB+zd/ddM/ZeL 5a0zbZM8/B4+C8iZuWd2D7/Jlosqp52lmNgUT/w79nbm8XhGTz69ut8fn37a+IBp22XX+5yJ ynP9uJ/0b7V0XHh0aoFDgPjiGUosxRmJhlrMRcWJAAprfsUcAwAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:37:48 -0000 On 10/30/17 8:24 AM, Christer Holmberg wrote: > Hi, > >>>>> I am proposing that it is not allowed to include S-E in an UPDATE >>>>> while there is an ongoing INVITE transaction. >>>> >>>> I think that is a good solution as long as we can resolve any backward >>>> compatibility issues >>>> with existing deployments. I gather we have one, but it is what >>>> identified the problem and >>>> so it needs to change anyway. >>> >>> Well, the reason we do this exercise is because some of the existing >>> deployments are broken (or, the spec they are based on is >>> broken/unclear), so we can only hope they will be fixed. >>> >>> But, at least based on the original problem case I solved, the fix >>> would have to be done in a network device (the one sending UPDATE with >>> S-E while the INVITE transaction is still ongoing) - which is much >>> easier than having to fix a large bunch of SIP UAs. >> >> OK. If you go with this approach, it is important for the update to the >> spec to be clear that an UPDATE (without S-E) in the midst of a INVITE >> transaction *does not* impact the status of the the timer being >> negotiated by the INVITE or one that was in effect prior to the INVITE. >> >> (Because normally an UPDATE or re-INVITE without S-E removes any timer >> that is in effect.) > > I am not sure that is correct. > > Section 4 says: > > "The default value of the Session-Expires header field is undefined. > This means that the absence of the Session-Expires header field > implies no expiration of the session, using the mechanism defined in > this specification." > > > My understanding is that the timer can only be removed by not including > S-E in a response, as said in section 7.2: > > "If the 2xx response did not contain a Session-Expires header field, > there is no session expiration. In this case, no refreshes need to > be sent. A 2xx without a Session-Expires can come for both initial > and subsequent session refresh requests. This means that the session > timer can be 'turned-off' in mid dialog by receiving a response > without a Session-Expires header field.² Yes, my comment was a bit imprecise. The the potential impact is the same. Consider the case where the UAC and UAS both *support* session timer, but neither of them have any particular desire to enable one. (The purpose of announcing support is so proxies can enable it.) In the absence of proxy requests, there will be no S-E in either the request or the response and so no timer. Then consider where there is a proxy that inserts the S-E. That starts a timer. Later, on a reINVITE, I would expect the UAC to again insert no S-E. If the proxy has lost the interest in the timer and doesn't insert S-E, then it will arrive at the UAS without.The UAS will presumably respond with no S-E and the timer will be cancelled. The same is true if you replace the reINVITE with UPDATE. The above is assuming the UPDATE is outside of an INVITE transaction. So now consider the same behaviors applied to an UPDATE within an INVITE transaction. Assume again that the UAC and UAS have no self interest in having a timer, but are willing to support a proxy who does. If no proxy adds S-E, then I think we need clarification that this doesn't cancel the timer being negotiated in the INVITE. (This might be obvious, but is still worth saying.) And, then I think the update needs to spell out the updated behavior for proxies - that they too can't put an S-E into the UPDATE in this case. But then we have to worry about situations where some proxy on the path doesn't implement the update, and automatically inserts S-E into every INVITE and UPDATE it sees. Thanks, Paul From nobody Mon Oct 30 14:11:58 2017 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 A959713FB90 for ; Mon, 30 Oct 2017 14:11:51 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8QfW_U-LbYh for ; Mon, 30 Oct 2017 14:11:49 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id E50EC13FB8A for ; Mon, 30 Oct 2017 14:11:45 -0700 (PDT) X-AuditID: 12074412-1e5ff7000000748d-f4-59f79590a8d5 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A1.33.29837.09597F95; Mon, 30 Oct 2017 17:11:44 -0400 (EDT) Received: from PaulKyzivatsMBP.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.13.8/8.12.4) with ESMTP id v9ULBhwx020842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 30 Oct 2017 17:11:44 -0400 To: "Jesske, Roland" , Christer Holmberg Cc: "sipcore@ietf.org" References: From: Paul Kyzivat Message-ID: Date: Mon, 30 Oct 2017 17:11:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixO6iqDtx6vdIg/UbmS0uzDzMaNF0p4vN 4uuPTWwOzB6/vl5l81iy5CeTR9tLhQDmKC6blNSczLLUIn27BK6M+ZcXsRV8cqnYf+MTYwPj B7MuRk4OCQETiVd/3rB3MXJxCAnsYJKY2v2XDcJ5yCTxde1OZpAqYQE1iSfzl4DZIgLpEks3 XGcCsZkFNCU2r7sA1d3LKLGt7zcrSIJNQEtizqH/LCA2r4C9xOVNkxlBbBYBVYn713vBBokK pEncmfGQCaJGUOLkzCdg9ZwCMRK3ni1jh1hgJjFv80NmCFtc4taT+VCL5SWat85mnsAoMAtJ +ywkLbOQtMxC0rKAkWUVo1xiTmmubm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRkhYC+1g XH9S7hCjAAejEg/vjMTvkUKsiWXFlbmHGCU5mJREeXc6AoX4kvJTKjMSizPii0pzUosPMUpw MCuJ8H6ZBJTjTUmsrEotyodJSXOwKInz/lys7ickkJ5YkpqdmlqQWgSTleHgUJLg7Z4C1ChY lJqeWpGWmVOCkGbi4AQZzgM0fO1kkOHFBYm5xZnpEPlTjJYcPT03/jBxrDt9D0g+m/m6gVmI JS8/L1VKnDcSZKgASENGaR7cTFiaesUoDvSiMG81SBUPMMXBTX0FtJAJaKGG5BeQhSWJCCmp BkaXiU7bbsXOrDnEGfQsvzi/cnHO6bZAx9oSF4fzLYkLEzuW7L767fK+SQ7Hkv+EfOpaelPH gS+s8OX6vKLFN49rzb567sPdQnf2QKfIvau/mem4MxZUtFSfFrugGlWxZvYvkznPpaJ1TGXE JNommLnJxuzj0252dWqd7nT34tmYkLfZQjN/r1FiKc5INNRiLipOBADvA6K/LgMAAA== Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:11:52 -0000 On 10/30/17 10:13 AM, Jesske, Roland wrote: > So for the second case: > If I send an session refresh without S-E and receive a response with S-E --> still session timer switched on. > > And only in the case S-E in request and response absent then --> Session timer switched off. No. In the case where it isn't in either the request or the response it needs to be switched off. This covers the case I outlined where neither the UAC nor UAS want it, and the proxy that once wanted it no longer does. And this means that the UPDATE within an INVITE transaction is a special case. And in this case I'm concerned about what happens when this change is introduced and some proxies don't get updated to support it. To be sure of that it might be better to say that S-E received in an UPDATE/200 ought to be ignored when embedded within an INVITE transaction. Then proxies that don't support the update won't screw things up. Thanks, Paul > Yes? > If yes can we document that? > > Like an addition to Section 7.4 like NEW TEXT: > > If the request did not contain a Session-Expires header field, and the > associated 2xx response did not contain a Session-Expires header > field, there is no session expiration. In this case, no refreshes > need to be sent. This means that > the session timer can be 'turned-off' in mid dialog by sending a request > without a Session-Expires header field but only when the UAS responds with a 2xx without a Session-Expires. > > I think Section 7.4 is not very clear on this. > > Thank you and Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Gesendet: Montag, 30. Oktober 2017 14:38 >> An: Jesske, Roland ; Paul Kyzivat >> >> Cc: sipcore@ietf.org >> Betreff: Re: AW: Session timer fix >> >> Hi, >> >>> You state with regard to turning off the session timer that: >>> The draft DOES update that paragraph, by saying that it only applies if >>> the associated request did contain S-E. >>> >>> For this I fully agree. And this issue is clarified. >>> >>> Then I see the statement from Paul: "Because normally an UPDATE or >>> re-INVITE without S-E removes any timer that is in effect." Where you >>> also agree. >>> >>> I do not think that this is correct. I think it depends on the SIP >>> field "supported timer". As long as there is an "supported: timer" >>> within an UPDATE or Re-INVITE it is the task of the UAS to agree on a >>> Session refresh or not. >>> Only the case where the UAS does not sent the S-E then I would say the >>> session timer is turned off. >>> >>> I do not find any statement in Section 7.4 stating that. >>> >>> Or did I missed something or have I overread something in you discussion? >> >> Yes :) >> >> I actually disagreed with Paul's statement, and pointed to section 7.4 which >> says that the session timer can only be turned off in a response. >> >> Regards, >> >> Christer >> >> >> >> >> >>>> -----Ursprüngliche Nachricht----- >>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>> Christer Holmberg >>>> Gesendet: Montag, 30. Oktober 2017 13:24 >>>> An: Paul Kyzivat >>>> Cc: sipcore@ietf.org >>>> Betreff: Re: [sipcore] Session timer fix >>>> >>>> Hi, >>>> >>>>>>>> I am proposing that it is not allowed to include S-E in an UPDATE >>>>>>>> while there is an ongoing INVITE transaction. >>>>>>> >>>>>>> I think that is a good solution as long as we can resolve any >>>>>>> backward compatibility issues with existing deployments. I gather >>>>>>> we have one, but it is what identified the problem and so it >>>>>>> needs to change anyway. >>>>>> >>>>>> Well, the reason we do this exercise is because some of the >>>>>> existing deployments are broken (or, the spec they are based on is >>>>>> broken/unclear), so we can only hope they will be fixed. >>>>>> >>>>>> But, at least based on the original problem case I solved, the fix >>>>>> would have to be done in a network device (the one sending UPDATE >>>>>> with S-E while the INVITE transaction is still ongoing) - which is >>>>>> much easier than having to fix a large bunch of SIP UAs. >>>>> >>>>> OK. If you go with this approach, it is important for the update to >>>>> the spec to be clear that an UPDATE (without S-E) in the midst of a >>>>> INVITE transaction *does not* impact the status of the the timer >>>>> being negotiated by the INVITE or one that was in effect prior to the >> INVITE. >>>>> >>>>> (Because normally an UPDATE or re-INVITE without S-E removes any >>>>> timer that is in effect.) >>>> >>>> I am not sure that is correct. >>>> >>>> Section 4 says: >>>> >>>> "The default value of the Session-Expires header field is undefined. >>>> This means that the absence of the Session-Expires header field >>>> implies no expiration of the session, using the mechanism >>>> defined in >>>> this specification." >>>> >>>> >>>> My understanding is that the timer can only be removed by not >>>> including S-E in a response, as said in section 7.2: >>>> >>>> "If the 2xx response did not contain a Session-Expires header >>>> field, >>>> there is no session expiration. In this case, no refreshes >>>> need to >>>> be sent. A 2xx without a Session-Expires can come for both >>>> initial >>>> and subsequent session refresh requests. This means that the >>>> session >>>> timer can be 'turned-off' in mid dialog by receiving a response >>>> without a Session-Expires header field.² >>>> >>>> >>>> The draft DOES update that paragraph, by saying that it only applies >>>> if the associated request did contain S-E. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On 27 Oct 2017, at 17.51, Paul Kyzivat >>>>>> > wrote: >>>>>>> >>>>>>>> On 10/27/17 8:31 AM, Christer Holmberg wrote: >>>>>>>>> Hi, >>>>>>>>>>>>>> Yes, I understand that is the case you are thinking of. >>>>>>>>>>>>>> But I was raising a different case: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - the UAC sends an invite without a S-E. >>>>>>>>>>>>>> - a proxy along the path includes an S-E. (The UAC is >>>>>>>>>>>>>> unaware.) >>>>>>>>>>>>>> - later, the UAC sends an UPDATE with S-E. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That violates the rule in your draft, but the UAC doesn't >>>>>>>>>>>>>> know it has violated it. So your rule for avoiding the >>>>>>>>>>>>>> problem in this case doesn't work. >>>>>>>>>>>>> >>>>>>>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but >>>>>>>>>>>>> as far as I understand the proxy will never remove S-E from >>>>>>>>>>>>> a >>>> response. >>>>>>>>>>>>> So, we could say that the UAC must not send UPDATE with S-E >>>>>>>>>>>>> until it has received a response to the INVITE. >>>>>>>>>>>> >>>>>>>>>>>> The problem is that the rfc only talks about the *final* >>>>>>>>>>>> (2xx) response. >>>>>>>>>>>> It has no provision for including the S-E in provisional >>>>>>>>>>>> responses. >>>>>>>>>>>> (It doesn't mention provisional responses, and the Table 1 >>>>>>>>>>>> update in section >>>>>>>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is >>>>>>>>>>>> inserted into the INVITE by a proxy, the UAC won't know that >>>>>>>>>>>> a session timer has been requested until it receives the > >>>>>>>>>>>> final response to the invite. >>>>>>>>>>>> Meanwhile it might decide send an UPDATE with S-E. >>>>>>>>>>> >>>>>>>>>>> My suggestion is that the UAC would not be allowed to send >>>>>>>>>>> UPDATE with S-E until it has received the final response for >>>>>>>>>>> the >>>> INVITE. >>>>>>>>>> >>>>>>>>>> This is more or less the original proposal that was shot down. >>>>>>>>>> Or do you mean that the *UAC* is restricted that way, but the >>>>>>>>>> *UAS* is permitted to use S-E to negotiate session timer in >>>>>>>>>> the midst of the INVITE, at least in some cases? >>>>>>>>> I have been thinking about this, talked to some people etc, and >>>>>>>>> perhaps the easiest solution would be to now allow UPDATE with >>>>>>>>> S-E during an active INVITE transaction (as suggested above). >>>>>>>> >>>>>>>> I have now gotten lost in the propossals and counter proposals. >>>>>>>> Can you explicitly state what you are proposing? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore > > From nobody Mon Oct 30 15:08:44 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DA513FC3A; Mon, 30 Oct 2017 15:08:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940131837.28238.11422797560691045050@ietfa.amsl.com> Date: Mon, 30 Oct 2017 15:08:38 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:08:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : SIP Call-Info Parameters for Labeling Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-callinfo-spam-02.txt Pages : 9 Date : 2017-10-30 Abstract: Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, confidence and references to additional information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-callinfo-spam-02 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-spam-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-callinfo-spam-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 31 01:35:57 2017 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 1163713F4FA for ; Tue, 31 Oct 2017 01:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr5IIuFSXtxn for ; Tue, 31 Oct 2017 01:35:54 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1252D13F6C9 for ; Tue, 31 Oct 2017 01:35:53 -0700 (PDT) X-AuditID: c1b4fb3a-dffff70000006897-01-59f835e82cb8 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.AB.26775.8E538F95; Tue, 31 Oct 2017 09:35:52 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Tue, 31 Oct 2017 09:35:51 +0100 From: Christer Holmberg To: Paul Kyzivat , "Jesske, Roland" CC: "sipcore@ietf.org" Thread-Topic: AW: AW: Session timer fix Thread-Index: AQHTUYRaNQk5paWN/k6WFLPj89rehKL8bNTggABmvoCAANHyAA== Date: Tue, 31 Oct 2017 08:35:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7pe4L0x+RBi2XRSxWbDjAatF0p4vN 4uuPTWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6MC0+mMBas8qj4/H8ucwPj V8suRg4OCQETiYPfk7oYuTiEBA4zSpy/1cwK4SxmlHg88TUrSBGbgIVE9z/tLkZODhGBIImO JS0sIDazgKbEo517mUBsYQE1iSfzlzBD1KhLXH/UyQJhO0nMeDuTHcRmEVCV2P+ggRHE5hWw lti6aBUT3OIV3X/AEpwCDhI7t6wFG8QoICbx/dQaJohl4hK3nswHsyUEBCSW7DnPDGGLSrx8 /I8VxBYV0JPYcOI2O8RjihLL++UgWg0kjpy7CfYKM9DeJ788IMLaEssWvmaGOEdQ4uTMJywT GMVnIVk2C0n3LITuWUi6ZyHpXsDIuopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMPYObvlt tYPx4HPHQ4wCHIxKPLz/pX9ECrEmlhVX5h5ilOBgVhLhFfr4PVKINyWxsiq1KD++qDQntfgQ ozQHi5I4r8O+CxFCAumJJanZqakFqUUwWSYOTqkGxll8GhOZqq5dPnniiNH0ktWnLB7VTd2z wbFm8XKFfedXLyho8sxx1Zr68/2H2rs1XpdNL1S17D6b8u3i1HdRps+1ZgssmHzgVoaXz9da 0yvmqralX7WO61+ctOkCB9vzvXXuuscW1pr4aU69NbVYq+HHmSVMSsu+yU+/KKCoWH/nmcGn w4cTWSYqsRRnJBpqMRcVJwIAFde97bkCAAA= Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 08:35:56 -0000 Hi Paul, >>So for the second case: >> If I send an session refresh without S-E and receive a response with >>S-E --> still session timer switched on. >>=20 >> And only in the case S-E in request and response absent then --> >>Session timer switched off. > >No. In the case where it isn't in either the request or the response it >needs to be switched off. This covers the case I outlined where neither >the UAC nor UAS want it, and the proxy that once wanted it no longer does. My suggestion is that no-SE-in-response would switch off if SE was in the request. So, if there is no SE in the request, there is no switch off. Regards, Christer >And this means that the UPDATE within an INVITE transaction is a special >case. And in this case I'm concerned about what happens when this change >is introduced and some proxies don't get updated to support it. To be >sure of that it might be better to say that S-E received in an >UPDATE/200 ought to be ignored when embedded within an INVITE >transaction. Then proxies that don't support the update won't screw >things up. > > Thanks, > Paul > >> Yes? >> If yes can we document that? >>=20 >> Like an addition to Section 7.4 like NEW TEXT: >>=20 >> If the request did not contain a Session-Expires header field, and >>the >> associated 2xx response did not contain a Session-Expires header >> field, there is no session expiration. In this case, no refreshes >> need to be sent. This means that >> the session timer can be 'turned-off' in mid dialog by sending a >>request >> without a Session-Expires header field but only when the UAS responds >>with a 2xx without a Session-Expires. >>=20 >> I think Section 7.4 is not very clear on this. >>=20 >> Thank you and Best Regards >>=20 >> Roland >>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Gesendet: Montag, 30. Oktober 2017 14:38 >>> An: Jesske, Roland ; Paul Kyzivat >>> >>> Cc: sipcore@ietf.org >>> Betreff: Re: AW: Session timer fix >>> >>> Hi, >>> >>>> You state with regard to turning off the session timer that: >>>> The draft DOES update that paragraph, by saying that it only applies >>>>if >>>> the associated request did contain S-E. >>>> >>>> For this I fully agree. And this issue is clarified. >>>> >>>> Then I see the statement from Paul: "Because normally an UPDATE or >>>> re-INVITE without S-E removes any timer that is in effect." Where you >>>> also agree. >>>> >>>> I do not think that this is correct. I think it depends on the SIP >>>> field "supported timer". As long as there is an "supported: timer" >>>> within an UPDATE or Re-INVITE it is the task of the UAS to agree on a >>>> Session refresh or not. >>>> Only the case where the UAS does not sent the S-E then I would say the >>>> session timer is turned off. >>>> >>>> I do not find any statement in Section 7.4 stating that. >>>> >>>> Or did I missed something or have I overread something in you >>>>discussion? >>> >>> Yes :) >>> >>> I actually disagreed with Paul's statement, and pointed to section 7.4 >>>which >>> says that the session timer can only be turned off in a response. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>>> Christer Holmberg >>>>> Gesendet: Montag, 30. Oktober 2017 13:24 >>>>> An: Paul Kyzivat >>>>> Cc: sipcore@ietf.org >>>>> Betreff: Re: [sipcore] Session timer fix >>>>> >>>>> Hi, >>>>> >>>>>>>>> I am proposing that it is not allowed to include S-E in an UPDATE >>>>>>>>> while there is an ongoing INVITE transaction. >>>>>>>> >>>>>>>> I think that is a good solution as long as we can resolve any >>>>>>>> backward compatibility issues with existing deployments. I gather >>>>>>>> we have one, but it is what identified the problem and so it >>>>>>>> needs to change anyway. >>>>>>> >>>>>>> Well, the reason we do this exercise is because some of the >>>>>>> existing deployments are broken (or, the spec they are based on is >>>>>>> broken/unclear), so we can only hope they will be fixed. >>>>>>> >>>>>>> But, at least based on the original problem case I solved, the fix >>>>>>> would have to be done in a network device (the one sending UPDATE >>>>>>> with S-E while the INVITE transaction is still ongoing) - which is >>>>>>> much easier than having to fix a large bunch of SIP UAs. >>>>>> >>>>>> OK. If you go with this approach, it is important for the update to >>>>>> the spec to be clear that an UPDATE (without S-E) in the midst of a >>>>>> INVITE transaction *does not* impact the status of the the timer >>>>>> being negotiated by the INVITE or one that was in effect prior to >>>>>>the >>> INVITE. >>>>>> >>>>>> (Because normally an UPDATE or re-INVITE without S-E removes any >>>>>> timer that is in effect.) >>>>> >>>>> I am not sure that is correct. >>>>> >>>>> Section 4 says: >>>>> >>>>> "The default value of the Session-Expires header field is >>>>>undefined. >>>>> This means that the absence of the Session-Expires header field >>>>> implies no expiration of the session, using the mechanism >>>>> defined in >>>>> this specification." >>>>> >>>>> >>>>> My understanding is that the timer can only be removed by not >>>>> including S-E in a response, as said in section 7.2: >>>>> >>>>> "If the 2xx response did not contain a Session-Expires header >>>>> field, >>>>> there is no session expiration. In this case, no refreshes >>>>> need to >>>>> be sent. A 2xx without a Session-Expires can come for both >>>>> initial >>>>> and subsequent session refresh requests. This means that the >>>>> session >>>>> timer can be 'turned-off' in mid dialog by receiving a >>>>>response >>>>> without a Session-Expires header field.=B2 >>>>> >>>>> >>>>> The draft DOES update that paragraph, by saying that it only applies >>>>> if the associated request did contain S-E. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On 27 Oct 2017, at 17.51, Paul Kyzivat >>>>>>> > wrote: >>>>>>>> >>>>>>>>> On 10/27/17 8:31 AM, Christer Holmberg wrote: >>>>>>>>>> Hi, >>>>>>>>>>>>>>> Yes, I understand that is the case you are thinking of. >>>>>>>>>>>>>>> But I was raising a different case: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - the UAC sends an invite without a S-E. >>>>>>>>>>>>>>> - a proxy along the path includes an S-E. (The UAC is >>>>>>>>>>>>>>> unaware.) >>>>>>>>>>>>>>> - later, the UAC sends an UPDATE with S-E. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That violates the rule in your draft, but the UAC doesn't >>>>>>>>>>>>>>> know it has violated it. So your rule for avoiding the >>>>>>>>>>>>>>> problem in this case doesn't work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but >>>>>>>>>>>>>> as far as I understand the proxy will never remove S-E from >>>>>>>>>>>>>> a >>>>> response. >>>>>>>>>>>>>> So, we could say that the UAC must not send UPDATE with S-E >>>>>>>>>>>>>> until it has received a response to the INVITE. >>>>>>>>>>>>> >>>>>>>>>>>>> The problem is that the rfc only talks about the *final* >>>>>>>>>>>>> (2xx) response. >>>>>>>>>>>>> It has no provision for including the S-E in provisional >>>>>>>>>>>>> responses. >>>>>>>>>>>>> (It doesn't mention provisional responses, and the Table 1 >>>>>>>>>>>>> update in section >>>>>>>>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is >>>>>>>>>>>>> inserted into the INVITE by a proxy, the UAC won't know that >>>>>>>>>>>>> a session timer has been requested until it receives the > >>>>>>>>>>>>> final response to the invite. >>>>>>>>>>>>> Meanwhile it might decide send an UPDATE with S-E. >>>>>>>>>>>> >>>>>>>>>>>> My suggestion is that the UAC would not be allowed to send >>>>>>>>>>>> UPDATE with S-E until it has received the final response for >>>>>>>>>>>> the >>>>> INVITE. >>>>>>>>>>> >>>>>>>>>>> This is more or less the original proposal that was shot down. >>>>>>>>>>> Or do you mean that the *UAC* is restricted that way, but the >>>>>>>>>>> *UAS* is permitted to use S-E to negotiate session timer in >>>>>>>>>>> the midst of the INVITE, at least in some cases? >>>>>>>>>> I have been thinking about this, talked to some people etc, and >>>>>>>>>> perhaps the easiest solution would be to now allow UPDATE with >>>>>>>>>> S-E during an active INVITE transaction (as suggested above). >>>>>>>>> >>>>>>>>> I have now gotten lost in the propossals and counter proposals. >>>>>>>>> Can you explicitly state what you are proposing? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >>=20 > From nobody Tue Oct 31 02:19:15 2017 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 A527E13F63F for ; Tue, 31 Oct 2017 02:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEiFsWjHqrjR for ; Tue, 31 Oct 2017 02:19:10 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE5413F5D7 for ; Tue, 31 Oct 2017 02:19:10 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id z19so19788331qtg.11 for ; Tue, 31 Oct 2017 02:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t5Ttwa1OjlQi7RYN2wsU6bMiw4UVpEKmWpocnieQ9p4=; b=e1pLnyOBat5CLkDq3jooc9TQx9bbNI9nr7NXZgNqS0b+q6WYuE+jPLxzS2l8kcpfN/ 0R6C2qWVa+vpUIzKnDG/MApVJVBEmUO1/cCceQSIJaJNHYQRiyjSGJ4plpruQnzDklca FPm5rdseqqgGgleNBboVyZIYyJ81TE/9oMn5XTia7o2it5dudjyECQAk+jqguibuSwnF 9H49HaQ7E116ILIpmlZ6k9tDQyJgD8/gxYcDi6Jw2l6LgajIfKnnDgHOpMdrRpiDpNl1 eiDh0u8ulrj3vnj8hfukynDyyR4ZsDttLPLW+JAJjP+1HTEUP1UuruaS0652kec2nsjF wUnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t5Ttwa1OjlQi7RYN2wsU6bMiw4UVpEKmWpocnieQ9p4=; b=YA6uU49x/gAc1tGMqYrn0hts97Gnv0ZnU+Guj+GncvBXy56cTPdvrP6Uka8RRKubQp V7GuUkrGythr8sq9YNuxwyQH19O37V0napPKmdqu0l5R0i1td7e4CTy4KzZnjY7TeZn+ 5xXSMdA6bObUpIqzlYBzcfMu1PqGzwjTdaAFNiqTAU8aW/fkak8H587qqqprMPLhW8JA vW7tXk4+zzNoh3u05dWE9CH3a9EyFafNwOBzVWOCdujyMlFLEEiTmbngqdqYmSOXdghR GiYCUSibD02+K0mzaE2eXZGT5uIpVhfs/XHl5PCjD2GZKjdbk5AjsdEymurYcMqPIujq 87rQ== X-Gm-Message-State: AMCzsaX3AHljErLohRoWlp3f3eWfAtKjkx03rXBB+7UXccO4903Bw44S O6sS0rLxCMWfLJ3eb9gy/jW4682CUrRgPyXqo2eBUciR X-Google-Smtp-Source: ABhQp+SO8Fs193tVWz175YA76IGNAd0YqUYbNgyPoQAnsfoCcUpaY5WWXAsaWCm2INZxY7L/k3grJkWM1O1Daahng4I= X-Received: by 10.200.23.166 with SMTP id o35mr1637130qtj.60.1509441549465; Tue, 31 Oct 2017 02:19:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.195.76 with HTTP; Tue, 31 Oct 2017 02:19:08 -0700 (PDT) In-Reply-To: References: <150667511780.14067.5559536080355041849.idtracker@ietfa.amsl.com> From: Yehoshua Gev Date: Tue, 31 Oct 2017 12:19:08 +0300 Message-ID: To: "Jesske, Roland" Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="f403045d68525d7f98055cd43f19" Archived-At: Subject: Re: [sipcore] WG: New Version Notification for draft-ietf-sipcore-reason-q850-loc-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 09:19:14 -0000 --f403045d68525d7f98055cd43f19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Some minor comments: 1. The draft's header indicates that it updates RFC 6442, but there is no reference to that RFC in the draft. I believe it should be removed. 2. Regarding the IANA registration - a. The RFC that defines the guidelines is 3968 (and not 3261). b. The sub-registry is Header Field Parameters (and not headers). c. I believe the "parameter name" in the registry is the actual name ("location") and not the ABNF representation ("isup-cause-location). d. According to the guidelines, "Whether the parameter only accepts a set of predefined values" should be specified. 3. I think the normative text should limit the use of the "location" parameter to Reason header fields that use Q.850 protocol. On the other hand, you can define what "string" (in the ABNF) can be for non-Q.850 Reason headers. Best, Yehoshua Gev On Fri, Sep 29, 2017 at 12:44 PM, Jesske, Roland wrote: > Hi, > now I have uploaded a new draft reflecting the discussions so far. > So currently I have taken the general approach using the LOC-xx for all > missing values. > I have not strong opinion on it. So if people would like to see an > differentiation on the "Spare" and " reserved for national use" > > Since I have no real preference I can live with both approaches. So if > nobody would like to see something other than I keep the current approach= . > > Best Regards > > Roland > > -----Urspr=C3=BCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Gesendet: Freitag, 29. September 2017 10:52 > An: Jesske, Roland > Betreff: New Version Notification for draft-ietf-sipcore-reason- > q850-loc-01.txt > > > A new version of I-D, draft-ietf-sipcore-reason-q850-loc-01.txt > has been successfully submitted by Roland Jesske and posted to the IETF > repository. > > Name: draft-ietf-sipcore-reason-q850-loc > Revision: 01 > Title: ISUP Cause Location Parameter for the SIP Reason Header > Field > Document date: 2017-09-29 > Group: sipcore > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-ietf-sipcore- > reason-q850-loc-01.txt > Status: https://datatracker.ietf.org/ > doc/draft-ietf-sipcore-reason-q850-loc/ > Htmlized: https://tools.ietf.org/html/draft-ietf-sipcore-reason- > q850-loc-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-sipcore- > reason-q850-loc-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore- > reason-q850-loc-01 > > Abstract: > The SIP Reason header field is defined for carrying ISUP cause values > as well as SIP response codes. Some services in SIP networks may > need to know the ISUP location where the call was released in the > PSTN network to correctly interpret the reason of release. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --f403045d68525d7f98055cd43f19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Some minor comments:

=
1. The draft's header indicates that it updates RFC 6442, bu= t there is no reference to that RFC in the draft.
=C2=A0 =C2=A0I = believe it should be removed.

2. Regarding the IAN= A registration -
=C2=A0 =C2=A0a. The RFC that defines the guideli= nes is=C2=A03968 (and not 3261).
=C2=A0 =C2=A0b. The sub-registry= is=C2=A0Header Field Parameters (and not headers).
=C2=A0 =C2=A0= c. I believe the "parameter name" in the registry is the actual n= ame ("location") and not the ABNF representation ("isup-cause-location).
=C2=A0 =C2=A0d= . According to the guidelines, "Whether the parameter only accepts a set of pr= edefined values" should be specified.=C2=A0

3.= I think the normative text should limit the use of the "location"= ; parameter to Reason header fields that use Q.850 protocol.
= =C2=A0 =C2=A0On the other hand, you can define what "string" (in = the ABNF) can be for non-Q.850 Reason headers.

Best,
Yehoshua Gev


On Fri, Sep 29, 2017 = at 12:44 PM, Jesske, Roland <R.Jesske@telekom.de> wrote:
Hi,
now I have uploaded a new draft reflecting the discussions so far.
So currently I have taken the general approach using the LOC-xx for all mis= sing values.
I have not strong opinion on it. So if people would like to see an differen= tiation on the "Spare" and " reserved for national use"=

Since I have no real preference I can live with both approaches. So if nobo= dy would like to see something other than I keep the current approach.

Best Regards

Roland

-----Urspr=C3=BCngliche Nachricht-----
Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf= .org]
Gesendet: Freitag, 29. September 2017 10:52
An: Jesske, Roland <R.Jesske@tele= kom.de>
Betreff: New Version Notification for draft-ietf-sipcore-reason-q850-l= oc-01.txt


A new version of I-D, draft-ietf-sipcore-reason-q850-loc-01.txt
has been successfully submitted by Roland Jesske and posted to the IETF rep= ository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-sipcore-reason-q850-loc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ISUP Cause Location Parameter for = the SIP Reason Header Field
Document date:=C2=A0 2017-09-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sipcore
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-iet= f-sipcore-reason-q850-loc-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-0= 1
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-<= wbr>reason-q850-loc-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipc= ore-reason-q850-loc-01

Abstract:
=C2=A0 =C2=A0The SIP Reason header field is defined for carrying ISUP cause= values
=C2=A0 =C2=A0as well as SIP response codes.=C2=A0 Some services in SIP netw= orks may
=C2=A0 =C2=A0need to know the ISUP location where the call was released in = the
=C2=A0 =C2=A0PSTN network to correctly interpret the reason of release.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

--f403045d68525d7f98055cd43f19-- From nobody Tue Oct 31 06:46:54 2017 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 3B7E8139680 for ; Tue, 31 Oct 2017 06:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBEIxhwmFDlZ for ; Tue, 31 Oct 2017 06:46:50 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 9B3191386DE for ; Tue, 31 Oct 2017 06:46:50 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id d9so20749449qtd.7 for ; Tue, 31 Oct 2017 06:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mikwuJOGT+XV9Ivew4nWUTbglXQkU8fHtTlKcr2CrJs=; b=Ar2tszxxu6d1z3mJBODw4rVFjvIOr9qG8y97zsb87JnNR0poX0IMD9kKjTQ++XLlbX 6OnYQoL7agu3WDn8zOHV+Dh4AW6eZ2dA0G0zHenA8MvaaqsA5rzJydnUMhwXLrFrlLPT 4rdYGwNiXX7ZTqit+GnIONEjGnS7R2xFztfOBD5SUzN4IRuPNjz1QdGBQRI480s+aMRb 4BWaH7LH8TymYIyOFKzjmk5rKosY5R94x44Likws6jkQTwM8y0CoStgdkECBGLBnXqWL vUu6UzO0MW13JDcguPSI3DHV4brNkegqAEzJJvKePI5Wr84eGuubjeye1+IQB2B25igI 7zWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mikwuJOGT+XV9Ivew4nWUTbglXQkU8fHtTlKcr2CrJs=; b=aBdZqjkQ2RCgpKPVFFMqvfyDquH+TMwbzGr+a3S8w0hcJivV9wwNJjjgbnEHAXv2Nl s0GSv3gSL8e7HCtxgEhD8cME+d6mrTgXwlojrIUDLe+U2x37E4XCPVke0z8RfbbDseZE GaBjFmJrlo8kcsUUd5GWD9D9yFMVGO/IQVWA/NX9sdBlRexnX135qgZRwcHriU2hMhc/ zMh029uJtOe2nPuYB0CokFAoDIvnJA3kK7kWVtiMw9iijibDGGksul0tpDedbsNBYs4M 8oCx6MBs6aCx+j+pct5kFVWmdRWlHb3cKIkHok9Hvhrq85XQGv6tuHeIqfbv7AHiU7yt QgEw== X-Gm-Message-State: AMCzsaWbJ3QaEMAxT2ozuGRgcnHBEbK4rgdkLnRt13JDCZwTp6PzWUJa +G9z6ghG/YsiGvxL5hruliBgHrrNEGM= X-Google-Smtp-Source: ABhQp+Qrb3p3QJ+4Tb4glVWxadNpgI2YOqTqltOLD5nbpH/PUNDk0NcFeSUN6Pd5QCwjjTsWuLHEug== X-Received: by 10.200.49.195 with SMTP id i3mr2797586qte.104.1509457609306; Tue, 31 Oct 2017 06:46:49 -0700 (PDT) Received: from [10.33.193.2] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id i37sm888721qte.56.2017.10.31.06.46.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 06:46:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: <3D79AD45-1508-42D2-802F-C2BC49F79AFA@brianrosen.net> Date: Tue, 31 Oct 2017 09:46:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <038C6C2D-F300-4742-A3BF-207B28FCD0CA@brianrosen.net> References: <3D79AD45-1508-42D2-802F-C2BC49F79AFA@brianrosen.net> To: sipcore@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Agenda Items for IETF 100 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 13:46:52 -0000 Any other agenda requests? =20 Brian > On Oct 20, 2017, at 2:21 PM, Brian Rosen wrote: >=20 > We have scheduled a short meeting slot (1 hour). Chairs will = prioritize agenda requests to drafts receiving list discussion, but we = would really like to get some of our older work items finished. If you = want agenda time, please let us know soon. >=20 > Brian From nobody Tue Oct 31 11:16:12 2017 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 AEC1E13FA3B for ; Tue, 31 Oct 2017 11:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAYJ0Y9j-Pct for ; Tue, 31 Oct 2017 11:16:07 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AC313FA36 for ; Tue, 31 Oct 2017 11:16:07 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id b6so14380489pfh.7 for ; Tue, 31 Oct 2017 11:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IwDSrMAXrQeLiBftLIopleC08vxxZ46s9JlvLsqMWHY=; b=Aos4xdAgx4Zu9lThv5Zw7cskKWFR01Cbp+CEVWslcoS93bIXYGKUj/tXuiS+wGQpGI PbB5zga8wGO2TS18odJuiiNBSibiLjLM7m4L/u9BTrufEklqJB0JAGkPITzxySxr2Aqr bjRpNEBckBKW4IrVc9jYoUUruGxHUbmRVcEWb2k2d7/b2ednSE3YvWRgLOXzvTwox7To YnPmXOb+HxmADSX4wO3SH1nuo/Zg4AxzIjfF7qayTB5UFbTbS2/Dsjm9asFBSUbreh02 d0ASBPOO74B53ez8ZL4u15TjMMFrMXupmQC3lbxVT7/7zYWPo1xXLKuzlP1K/SknOhJZ 3HjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IwDSrMAXrQeLiBftLIopleC08vxxZ46s9JlvLsqMWHY=; b=Met0mH2Mn/mdK47eINenPd4pybH6iW1pXetGTTnKU0OtfbrEVe2uxeyTPHgvGaIwxY qB90nPFuewA2A+28lEg7B7Ki2oA+0A9AyHR1s9MhLFbboAnfUzWH9vfZopi+C/2gvc96 6S9TmNFL+6YO0OEOb8B5KRfgdcMEeWNerdqi9Yu+7XCvGoOfOTzd1Y6EcRbRxvl5pBPF H8wf2NzzD/hdHE6fQ7xVOKSmH9tuWVP1ixWee9T0ZEmaT8Mp0ocHw/dG49VYIAkQYD3W sRf+8L5nNZXMnKUdFXKyOTcLonyXv6iFhjAymMiRFoHeEtuv8WEHyiUdNkaYYKblCZ+r IC6g== X-Gm-Message-State: AMCzsaUOpZ2TYP/75bh0B0JNFyZu2Xk0ZFs6+oCiZOVmBF/ldTKYGiEo I96N57jmMCut7CKmkICkr170rwtv X-Google-Smtp-Source: ABhQp+S0tgZt/zaiP9GOv5uPe9yyNqiOZQRemkWLtgmw7RoeRQIJZuhetbbvq8bJi0mCMGafCnhpjA== X-Received: by 10.98.55.133 with SMTP id e127mr2939244pfa.130.1509473766843; Tue, 31 Oct 2017 11:16:06 -0700 (PDT) Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com. [74.125.83.52]) by smtp.gmail.com with ESMTPSA id u8sm3590376pgp.17.2017.10.31.11.16.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 11:16:06 -0700 (PDT) Received: by mail-pg0-f52.google.com with SMTP id l24so15336991pgu.11 for ; Tue, 31 Oct 2017 11:16:05 -0700 (PDT) X-Received: by 10.99.4.75 with SMTP id 72mr2505806pge.400.1509473765821; Tue, 31 Oct 2017 11:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.131 with HTTP; Tue, 31 Oct 2017 11:16:04 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Tue, 31 Oct 2017 14:16:04 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "Jesske, Roland" , Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="001a114f68609c13aa055cdbbfc4" Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:16:10 -0000 --001a114f68609c13aa055cdbbfc4 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 30, 2017 at 10:20 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >So for the second case: > >If I send an session refresh without S-E and receive a response with S-E > >--> still session timer switched on. > > Yes (at least that is my understanding of the text). > This is incorrect. Session timer is switched off. > > >And only in the case S-E in request and response absent then --> Session > >timer switched off. > > > >Yes? > > Yes (at least that is my understanding of the text). > Also not entirely correct. It does not matter if Session-Timer was present in the offer. If there is no Session-Timer in the answer, Session-Timer is switched off. Session-Timer is added the answer based on the Supported or Required headers. Session-Timer in the offer only proposes the Session-Timer interval. It is optional. Regards, ______________ Roman Shpount --001a114f68609c13aa055cdbbfc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 30, 2017 at 10:20 AM, C= hrister Holmberg <christer.holmberg@ericsson.com> wrote:
>So for the second case:
>If I send an session refresh without S-E and receive a response with S-= E
>--> still session timer switched on.

Yes (at least that is my understanding of the text).

This is incorrect. Session timer is switched off.=C2= =A0

>And only in the case S-E in request and response absent then --> Ses= sion
>timer switched off.
>
>Yes?

Yes (at least that is my understanding of the text).

Also not entirely correct. It does not matter if Sessi= on-Timer was present in the offer. If there is no Session-Timer in the answ= er, Session-Timer is switched off.
Session-Timer is added the ans= wer based on the Supported or Required headers. Session-Timer in the offer = only proposes the Session-Timer interval. It is optional.

Regards,
______________
Roman Shpount

--001a114f68609c13aa055cdbbfc4-- From nobody Tue Oct 31 11:21:00 2017 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 F00CE13F5C1 for ; Tue, 31 Oct 2017 11:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UWjvVjxKDdd for ; Tue, 31 Oct 2017 11:20:58 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7199713F502 for ; Tue, 31 Oct 2017 11:20:55 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id e64so14374461pfk.9 for ; Tue, 31 Oct 2017 11:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zKRsjpaUgcAOroYsEaA+gIh3/J8vO8rv0STHbFD4pD0=; b=P70fxLfaq3pMpIVgzJA+0451FYheYsM/LW/IYbYX5ll8qvBaWFojAr/AuKyr7HiOlj n81t/PEfW6zyEwSZYShwzp+d3/gsS8HE3B62bLEZZSmIT0N80OOVTsR4PH2gjbm75WVu L7JPNG4pK8tXnSlZY4pej3rmPPeWT7BAc0uoYAQSx4MQ2D18fw/rQViMUoqgGW7hSriQ e8TnlIs5xYt+HV/f1PuhGrcCtIPRhLNV7crpyhanfTJBezxARiE2SKa3t7rbdvFXW8IA xgxGBEO9u3cr000PJhob3GhRg/qYs6Q7IO3jnRWrwLmkCXvX7vSeF/OmklcL5oBxQSt9 KPfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zKRsjpaUgcAOroYsEaA+gIh3/J8vO8rv0STHbFD4pD0=; b=dY5vPUTIQI1rZnLjQ4KLkNZ/q6yFp5Q9+mFSg6K2kzMCMG3eCoLOZ3vq+Kl21esG3p h6YRmtuNK9Rc9x8xEzDue6jKkuxMFp7Mu1mGmi3SdqlbOFHJNOf7Ik7s3r1OKBruw3qG U2eBCLKvsPLX0qaPatpqPTEo4q5oBmDXcacv5OC+BlGHb/KK19e9Gd7VdsDO7QH5wfz7 2Y13KQo3pMU6KKgpUt0fOUvBs86v4BVZgtCiDrZEzPVTK1bRyhhXsZYF1KV76oKOtFzs 8kA1AtumNurlsBLBRZWEGrTj68zGpCXtHb7qPnvmFy36WtfFGlPRULdiSIIN3n06jnYe PQ2g== X-Gm-Message-State: AMCzsaXeFV3pnODSDgQsXnULtfM+op1IopbQJkFj0pGoZXt37KqjQ9Y5 3ohcK8D9dI1AnxkQUSX4MAjpZS11 X-Google-Smtp-Source: ABhQp+RpRscPzjGc4Mkxn3MNgbcH8hgiLKfcUURBSmRRx0FccV6oWN9sp2oRNC69XBJUn9/qIwWh1g== X-Received: by 10.98.31.73 with SMTP id f70mr2897811pff.183.1509474054886; Tue, 31 Oct 2017 11:20:54 -0700 (PDT) Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com. [74.125.83.47]) by smtp.gmail.com with ESMTPSA id a70sm4859994pfg.176.2017.10.31.11.20.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 11:20:53 -0700 (PDT) Received: by mail-pg0-f47.google.com with SMTP id b192so15367958pga.2 for ; Tue, 31 Oct 2017 11:20:53 -0700 (PDT) X-Received: by 10.101.68.69 with SMTP id e5mr2601598pgq.282.1509474053466; Tue, 31 Oct 2017 11:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.131 with HTTP; Tue, 31 Oct 2017 11:20:52 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Tue, 31 Oct 2017 14:20:52 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="089e08253e34c12e93055cdbd025" Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:20:59 -0000 --089e08253e34c12e93055cdbd025 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 31, 2017 at 4:35 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > My suggestion is that no-SE-in-response would switch off if SE was in the > request. > > So, if there is no SE in the request, there is no switch off. > This will break pretty much every SE implementation. There are number of implementations where UA does not insert SE in the request. It is inserted either by proxies (actually this is the most common use case) or by the answering agent. I think it would be much better to have a new header which will specify "do not update Session-Timer" in the offer. This way if proxies insert Session-Timer, new header will overwrite. Regards, _____________ Roman Shpount --089e08253e34c12e93055cdbd025 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Oct 31, 2017 at 4:3= 5 AM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
My su= ggestion is that no-SE-in-response would switch off if SE was in the
request.

So, if there is no SE in the request, there is no switch off.

This will break pretty much every SE implementation.= There are number of implementations where UA does not insert SE in the req= uest. It is inserted either by proxies (actually this is the most common us= e case) or by the answering agent.

I think it woul= d be much better to have a new header which will specify "do not updat= e Session-Timer" in the offer.
This way if proxies insert Se= ssion-Timer, new header will overwrite.=C2=A0

Rega= rds,
_____________
Roman Shpoun= t
=C2=A0
--089e08253e34c12e93055cdbd025-- From nobody Tue Oct 31 11:44:06 2017 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 9A73013F4F2 for ; Tue, 31 Oct 2017 11:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTUEpYq8aetx for ; Tue, 31 Oct 2017 11:44:03 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C7213F3C3 for ; Tue, 31 Oct 2017 11:44:02 -0700 (PDT) X-AuditID: c1b4fb2d-bf5ff7000000268d-1b-59f8c470b409 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3A.48.09869.074C8F95; Tue, 31 Oct 2017 19:44:00 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Tue, 31 Oct 2017 19:43:49 +0100 From: Christer Holmberg To: Roman Shpount CC: Paul Kyzivat , "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVA Date: Tue, 31 Oct 2017 18:43:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B5C67FEA1ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7tG7BkR+RBndOGVis2HCA1aLpTheb xYwLU5ktvv7YxObA4vH3/QcmjyVLfjJ5tL1U8Lg1pSCAJYrLJiU1J7MstUjfLoEr48/xrywF xxIq9q2NbWD8EtvFyMEhIWAiceCfchcjF4eQwGFGiSNn+5ggnMWMEldn9TCDFLEJWEh0/9Pu YuTkEBFQlfj7fTITiM0sUCnxoe8wmC0soCHxee5lZogaTYmLp5YxQdhGErfPHWYBsVmAek80 t7KB2LwCvhK7Zh2C2rWHSeLlqu3sILs4BQIlWjqDQGoYBcQkvp9aA7VLXOLWk/lgtoSAgMSS PeeZIWxRiZeP/7FC2EoSK7ZfYoSoz5fYs7+NHWKXoMTJmU9YJjCKzEIyahaSsllIymYBXcEM 9ML6XfoQJYoSU7ofskPYGhKtc+ayI4svYGRfxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREY dQe3/Nbdwbj6teMhRgEORiUe3ov7f0QKsSaWFVfmHmKU4GBWEuHtXQEU4k1JrKxKLcqPLyrN SS0+xCjNwaIkzuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgXG5wGfRZVEOHP575RrdtrPtmGxw JZRhM0vA5fN+2w31hNdePPYx8MMahaRpjFuzJtVqVewKPM9+v3nReqPQxMwnNz3VWRPv/vnY Vhi+cdadA2ETo1eJGdrmte4T/8JUv27z67L693Pv/DJdUePgZWnwaUmXXWPWzD03P+WvvVtc 1TYvre2DRq0SS3FGoqEWc1FxIgAbuP4KtgIAAA== Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:44:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B5C67FEA1ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgbWF5IHJlcGx5IHRvIFJvbWFu4oCZcyBjb21tZW50cyBsYXRlci4NCg0KQnV0LCBh dCB0aGUgZW5kIG9mIHRoZSBkYXkgSSB0aGluayB3aGF0IFBhdWwgc2FpZCBpcyB3aGF0IG1hdHRl cnMgbW9zdDogdGhlIHByb2NlZHVyZXMgZm9yIHR1cm5pbmcgc2Vzc2lvbiB0aW1lciBldGMgYXBw bGllcyBBRlRFUiB0aGUgc2Vzc2lvbiB0aW1lciBoYXMgYmVlbiBmdWxseSBuZWdvdGlhdGVkLg0K DQpTbywgaWYgdGhlIHNlc3Npb24gdGltZXIgaXMgbmVnb3RpYXRlZCBkdXJpbmcgdGhlIGluaXRp YWwgSU5WSVRFIHRyYW5zYWN0aW9uLCB3aGF0ZXZlciBVUERBVEVzIGFyZSBzZW50IGR1cmluZyB0 aGF0IHRyYW5zYWN0aW9uIHdpbGwgbm90IGNvbnRhaW4gc2Vzc2lvbiB0aW1lciBpbmZvcm1hdGlv biwgYW5kIHRoZXkgd2lsbCBoYXZlIG5vIGltcGFjdCBvbiB0aGUgc2Vzc2lvbiB0aW1lci4NCg0K QnV0LCBvbmNlIHRoZSBzZXNzaW9uIHRpbWVyIGhhcyBiZWVuIG5lZ290aWF0ZWQgKG9uY2UgdGhl IFVBQyBoYXMgcmVjZWl2ZWQgdGhlIDIwMCBPSywgdGhlIHJ1bGVzIHJlZ2FyZGluZyB0dXJuaW5n IHRoZSBzZXNzaW9uIHRpbWVyIG9mZiBldGMgYXBwbGllcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQpT ZW50OiAzMSBPY3RvYmVyIDIwMTcgMjA6MjENClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1 bS5taXQuZWR1PjsgSmVzc2tlLCBSb2xhbmQgPFIuSmVzc2tlQHRlbGVrb20uZGU+OyBzaXBjb3Jl QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFNlc3Npb24gdGltZXIgZml4DQoNCg0K T24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgNDozNSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPj4gd3JvdGU6DQpNeSBzdWdnZXN0aW9uIGlzIHRoYXQgbm8tU0UtaW4tcmVzcG9uc2Ug d291bGQgc3dpdGNoIG9mZiBpZiBTRSB3YXMgaW4gdGhlDQpyZXF1ZXN0Lg0KDQpTbywgaWYgdGhl cmUgaXMgbm8gU0UgaW4gdGhlIHJlcXVlc3QsIHRoZXJlIGlzIG5vIHN3aXRjaCBvZmYuDQoNClRo aXMgd2lsbCBicmVhayBwcmV0dHkgbXVjaCBldmVyeSBTRSBpbXBsZW1lbnRhdGlvbi4gVGhlcmUg YXJlIG51bWJlciBvZiBpbXBsZW1lbnRhdGlvbnMgd2hlcmUgVUEgZG9lcyBub3QgaW5zZXJ0IFNF IGluIHRoZSByZXF1ZXN0LiBJdCBpcyBpbnNlcnRlZCBlaXRoZXIgYnkgcHJveGllcyAoYWN0dWFs bHkgdGhpcyBpcyB0aGUgbW9zdCBjb21tb24gdXNlIGNhc2UpIG9yIGJ5IHRoZSBhbnN3ZXJpbmcg YWdlbnQuDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgbXVjaCBiZXR0ZXIgdG8gaGF2ZSBhIG5ldyBo ZWFkZXIgd2hpY2ggd2lsbCBzcGVjaWZ5ICJkbyBub3QgdXBkYXRlIFNlc3Npb24tVGltZXIiIGlu IHRoZSBvZmZlci4NClRoaXMgd2F5IGlmIHByb3hpZXMgaW5zZXJ0IFNlc3Npb24tVGltZXIsIG5l dyBoZWFkZXIgd2lsbCBvdmVyd3JpdGUuDQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21h biBTaHBvdW50DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B5C67FEA1ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5JIG1heSByZXBseSB0byBSb21hbuKAmXMgY29tbWVudHMgbGF0ZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CdXQsIGF0IHRoZSBlbmQg b2YgdGhlIGRheSBJIHRoaW5rIHdoYXQgUGF1bCBzYWlkIGlzIHdoYXQgbWF0dGVycyBtb3N0OiB0 aGUgcHJvY2VkdXJlcyBmb3IgdHVybmluZyBzZXNzaW9uIHRpbWVyIGV0YyBhcHBsaWVzIEFGVEVS DQogdGhlIHNlc3Npb24gdGltZXIgaGFzIGJlZW4gZnVsbHkgbmVnb3RpYXRlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvLCBpZiB0aGUgc2Vzc2lvbiB0aW1lciBp cyBuZWdvdGlhdGVkIGR1cmluZyB0aGUgaW5pdGlhbCBJTlZJVEUgdHJhbnNhY3Rpb24sIHdoYXRl dmVyIFVQREFURXMgYXJlIHNlbnQgZHVyaW5nIHRoYXQgdHJhbnNhY3Rpb24gd2lsbA0KIG5vdCBj b250YWluIHNlc3Npb24gdGltZXIgaW5mb3JtYXRpb24sIGFuZCB0aGV5IHdpbGwgaGF2ZSBubyBp bXBhY3Qgb24gdGhlIHNlc3Npb24gdGltZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5CdXQsIG9uY2UgdGhlIHNlc3Npb24gdGltZXIgaGFzIGJlZW4gbmVnb3RpYXRl ZCAob25jZSB0aGUgVUFDIGhhcyByZWNlaXZlZCB0aGUgMjAwIE9LPGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj4sIHRoZSBydWxlcyByZWdhcmRpbmcNCiB0dXJuaW5nIHRoZSBzZXNzaW9uIHRpbWVy IG9mZiBldGMgYXBwbGllcy48bzpwPjwvbzpwPjwvYT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hy aXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IDMxIE9jdG9iZXIgMjAxNyAyMDoyMTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1Jmd0OzsgSmVzc2tl LCBSb2xhbmQgJmx0O1IuSmVzc2tlQHRlbGVrb20uZGUmZ3Q7OyBzaXBjb3JlQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gU2Vzc2lvbiB0aW1lciBmaXg8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBPY3QgMzEsIDIwMTcgYXQgNDozNSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBzdWdn ZXN0aW9uIGlzIHRoYXQgbm8tU0UtaW4tcmVzcG9uc2Ugd291bGQgc3dpdGNoIG9mZiBpZiBTRSB3 YXMgaW4gdGhlPGJyPg0KcmVxdWVzdC48YnI+DQo8YnI+DQpTbywgaWYgdGhlcmUgaXMgbm8gU0Ug aW4gdGhlIHJlcXVlc3QsIHRoZXJlIGlzIG5vIHN3aXRjaCBvZmYuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdpbGwgYnJl YWsgcHJldHR5IG11Y2ggZXZlcnkgU0UgaW1wbGVtZW50YXRpb24uIFRoZXJlIGFyZSBudW1iZXIg b2YgaW1wbGVtZW50YXRpb25zIHdoZXJlIFVBIGRvZXMgbm90IGluc2VydCBTRSBpbiB0aGUgcmVx dWVzdC4gSXQgaXMgaW5zZXJ0ZWQgZWl0aGVyIGJ5IHByb3hpZXMgKGFjdHVhbGx5IHRoaXMgaXMg dGhlIG1vc3QgY29tbW9uIHVzZSBjYXNlKSBvciBieSB0aGUgYW5zd2VyaW5nIGFnZW50LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IGl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIHRvIGhhdmUgYSBuZXcgaGVhZGVyIHdoaWNoIHdpbGwg c3BlY2lmeSAmcXVvdDtkbyBub3QgdXBkYXRlIFNlc3Npb24tVGltZXImcXVvdDsgaW4gdGhlIG9m ZmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyB3YXkgaWYgcHJveGllcyBpbnNlcnQgU2Vzc2lvbi1UaW1lciwgbmV3IGhlYWRlciB3aWxs IG92ZXJ3cml0ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3Vu dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B5C67FEA1ESESSMB109erics_--