From nobody Wed Nov 1 03:47: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 782A813A66B for ; Wed, 1 Nov 2017 03:47: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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 FOU4s9FYqS_J for ; Wed, 1 Nov 2017 03:47:15 -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 8967113F6F9 for ; Wed, 1 Nov 2017 03:47: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=1509533234; x=1541069234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nGiHLShk1kEUfZ76weQ/4m1oo/BAyX3YYrqisBYZazo=; b=1tyLCYUXSR6nYMZ0XtOBOGzbaYOyOqrHgcELITBucBdGo9+3OKoOg3Tj qjc6/WC/BIC0z2LpVpjhvPr4yt1wTypYXVUxiiU/u2Yg5S5ap1ok3ft0t FGOhsjfGzJXl8EbhXJtncctjHwtP75jBCaX5wjuHuHscJnP7VVutbEAPH 6sdHwqxPtZUwjmFMuzYsmFOeGqZP0JsxnQBjTZfXspcKXduEsN65xe5pZ 8EvkoqKp6WAWM/x2hJk6VngnU1O23Ib5ksyI09PUueaOqGsVteisWyt2r 1c4NXMnkcpZwTLubdVNJkhakU7uqVNaRATAqcLfCLkNJgELbTC2Kdt/8I Q==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2017 11:47:11 +0100 X-IronPort-AV: E=Sophos;i="5.44,327,1505772000"; d="scan'208";a="58410850" Received: from he106142.emea1.cds.t-internal.com ([10.169.119.76]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 01 Nov 2017 11:47:11 +0100 Received: from HE106139.EMEA1.cds.t-internal.com (10.169.119.72) by HE106142.emea1.cds.t-internal.com (10.169.119.76) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 1 Nov 2017 11:47:11 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE106139.EMEA1.cds.t-internal.com (10.169.119.72) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 1 Nov 2017 11:47:11 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.20) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 1 Nov 2017 11:46:36 +0100 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.178.6; Wed, 1 Nov 2017 10:47:10 +0000 Received: from LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE ([fe80::58a0:e5a7:224a:aaa7]) by LEXPR01MB0494.DEUPRD01.PROD.OUTLOOK.DE ([fe80::58a0:e5a7:224a:aaa7%14]) with mapi id 15.20.0178.014; Wed, 1 Nov 2017 10:47:10 +0000 From: "Jesske, Roland" To: Christer Holmberg , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: AW: AW: Session timer fix Thread-Index: AQHTUYo2aPXolYE0wUOZQxb7inVz86L/Ic7Q Date: Wed, 1 Nov 2017 10:47:10 +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; LEXPR01MB0493; 6:noGYcFBicu5+f0rLYe3xqs3g1Ww9szFgDH1Hk23iNKCkHisvSLhiOxHGsIGMgC0o+B5/N/aCJ9yrDmcsQF6tXf36e35ITXvxisNj77iTwACj8U9RSNWSOxlUREDLa49rSeDdIeT2QNOV0rpznMaezYl5FsUiDPmsyQTo3JflEIV913/lIO8/F7Q/UiTUnCc1OSWlIBF3q1/sxhUcTPWWd4ny99vDfqqyU/02joTsE+AF6Gk0Uy0CowovfbTdxGGD5lDTLTVNsZBt3RfV7Ktgaee33NrIUBg5c97h9yCrWhU8xn7X+ZrYZPL2RsQWT36FHRLRYNX+To7rg20qCG1nwBDq7ZhXsvgCPdlrg6gvx0o=; 5:sy6CjEpoKQ+Aoj5v2+vCClPL2zGIAF7yBbRJzc7W2P2x0hhxjgMb+/I0NG5zD8q29YJUFvUqTU3G5TdhA8FbnSB9792AOZKm4xAeokOvl+7evWGh2w1Beu6UXsqTwCrwTHbk547KkRKOSD5sudY5O8uYJIFbfCtDBtkGPHFzegc=; 24:R4opDwNmABq+j+8eS1JsgEv2ObDWEdBewL3Tdh4ZPNifAqXytCW85qRFvVvRqJjofD+NQdCv+njUU6Owi9rlqp9wHpk3tm1IQmKpuUiR+yI=; 7:md7gUPJMgh1xdT0MYdrthg6JAbW8YN5DrzT/ZqouAltI1shsCMdUjfwMgSZGyLjEfswqQkKKaNfCD5bPP2I0s3kBChZgmZvUIhqMprltQLvXakWb54EpfOTLFcjmizjS7Q7vtUsuwfgkxTax+HzKi4G2Ek+w4hX3fRmnEWaZU4ZGL15A13/4eWDaGdP96ijj4uJMvxd+bCkpJuU2hibaUxpxwmaUR0YO7YbUB0PCr+dGUb+fPDdB8DJne8yEP+Sn x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d3ee9d69-3848-4821-9eaf-08d52115e74c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:LEXPR01MB0493; x-ms-traffictypediagnostic: LEXPR01MB0493: 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)(93006095)(93001095)(3231020)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(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: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(51444003)(199003)(24454002)(189002)(53546010)(105586002)(33656002)(478600001)(3280700002)(75402003)(76176999)(54356999)(50986999)(2906002)(966005)(3660700001)(68736007)(7696004)(551934003)(101416001)(8936002)(561944003)(189998001)(106356001)(72206003)(305945005)(53936002)(110136005)(2900100001)(4326008)(66066001)(2171002)(7736002)(8676002)(2950100002)(316002)(5003630100001)(86362001)(81156014)(14454004)(81166006)(6306002)(3846002)(102836003)(97736004)(5660300001)(9686003)(74482002)(5250100002)(6116002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0493; 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d3ee9d69-3848-4821-9eaf-08d52115e74c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2017 10:47:10.0912 (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] 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: Wed, 01 Nov 2017 10:47:18 -0000 Hi Christer, So I think we should also put something into 7.4 since this section is desc= ribing the Refresh mechanism for the subsequent refreshes. So if documentation is easier in 7.2 we can do this. But then I think in 7.= 4 we need at least then a reference to 7.2. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Gesendet: Montag, 30. Oktober 2017 15:20 > An: Jesske, Roland ; Paul Kyzivat > > Cc: sipcore@ietf.org > Betreff: Re: AW: AW: Session timer fix >=20 > Hi, >=20 > >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 > Yes (at least that is my understanding of the text). >=20 > >And only in the case S-E in request and response absent then --> > >Session timer switched off. > > > >Yes? >=20 > Yes (at least that is my understanding of the text). >=20 >=20 > >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 t= he > > 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. >=20 > I assume you mean Section 7.2? >=20 > We can for sure make the text more clear. >=20 > Regards, >=20 > Christer >=20 >=20 >=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 fiel= d > >> >> 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 respon= se > >> >> 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 dow= n. > >> >> >>>>>> 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 sugge= sted > 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 Wed Nov 1 08:21: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 59F8513F75F for ; Wed, 1 Nov 2017 08:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 BjDdO0ZCCS7s for ; Wed, 1 Nov 2017 08:21:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D241313FD70 for ; Wed, 1 Nov 2017 08:21:30 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA1FLK7e099494 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Nov 2017 10:21:21 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local References: <58A326A7-BDD9-4508-BCC8-A7660D9C203D@vigilsec.com> From: Adam Roach To: "'SIPCORE'" , Henning Schulzrinne X-Forwarded-Message-Id: <58A326A7-BDD9-4508-BCC8-A7660D9C203D@vigilsec.com> Message-ID: <2fe92c9f-eae4-b539-ae81-d4dfef7c5e90@nostrum.com> Date: Wed, 1 Nov 2017 10:21:15 -0500 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: <58A326A7-BDD9-4508-BCC8-A7660D9C203D@vigilsec.com> Content-Type: multipart/alternative; boundary="------------483FEDF782430F65A358E0F6" Content-Language: en-US Archived-At: Subject: [sipcore] Fwd: Fwd: draft-ietf-sipcore-callinfo-spam-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: Wed, 01 Nov 2017 15:21:34 -0000 This is a multi-part message in MIME format. --------------483FEDF782430F65A358E0F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I've looked over the groups meeting later in the week, and can't find another session that is likely to have the correct community of interest. I've also looked over the changes to the document, and they seem entirely editorial (albeit with a change that technically does impact the wire protocol). It's not clear that there are any remaining open issues that would clearly benefit from face-to-face time. Henning: do you have some questions you specifically wanted to address in the meeting? Or did you just want to present a list of changes to give people an opportunity to object? If the latter, I believe it should be pretty easy for the chairs to say: "We've renamed the 'spam' parameter to 'confidence', and made some other minor editorial improvements. Interested parties should comment on the list if they object." It's up to the chairs whether they want to couple this request with a WGLC. /a > *From: *Henning Schulzrinne > > *Subject: **draft-ietf-sipcore-callinfo-spam-02.txt* > *Date: *October 30, 2017 at 11:08:36 PM EDT > *To: *sipcore-chairs@ietf.org , Stir > Chairs > > *Resent-From: *> > *Resent-From: *wg-alias-bounces@tools.ietf.org > > *Resent-To: *housley@vigilsec.com , > rjsparks@nostrum.com > *Resent-To: *stir-chairs@ietf.org > > Brian & Jean: > > I submitted draft-ietf-sipcore-callinfo-spam-02.txt, which addresses > comments I have received. > > I will be in Singapore, but an obligation related to a grant proposal > makes me arrive Wednesday morning. If there was a need to discuss the > draft, I had kind of hoped that we could move any draft discussion to > STIR, since that seemed topically close and since it was meeting late > in the week as of the time when I booked my flight, but that option is > apparently gone. (I know that session scheduling is tough given the > various constraints, so I'm not complaining.) > > In any event, I'd like to figure out how to wrap up the draft since > discussion seems to have died down. > > Henning > --------------483FEDF782430F65A358E0F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit I've looked over the groups meeting later in the week, and can't find another session that is likely to have the correct community of interest.

I've also looked over the changes to the document, and they seem entirely editorial (albeit with a change that technically does impact the wire protocol). It's not clear that there are any remaining open issues that would clearly benefit from face-to-face time. Henning: do you have some questions you specifically wanted to address in the meeting? Or did you just want to present a list of changes to give people an opportunity to object?

If the latter, I believe it should be pretty easy for the chairs to say: "We've renamed the 'spam' parameter to 'confidence', and made some other minor editorial improvements. Interested parties should comment on the list if they object." It's up to the chairs whether they want to couple this request with a WGLC.

/a

From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: draft-ietf-sipcore-callinfo-spam-02.txt
Date: October 30, 2017 at 11:08:36 PM EDT
Resent-From: <alias-bounces@ietf.org>

Brian & Jean:

I submitted draft-ietf-sipcore-callinfo-spam-02.txt, which addresses
comments I have received.

I will be in Singapore, but an obligation related to a grant proposal
makes me arrive Wednesday morning. If there was a need to discuss the
draft, I had kind of hoped that we could move any draft discussion to
STIR, since that seemed topically close and since it was meeting late
in the week as of the time when I booked my flight, but that option is
apparently gone. (I know that session scheduling is tough given the
various constraints, so I'm not complaining.)

In any event, I'd like to figure out how to wrap up the draft since
discussion seems to have died down.

Henning


--------------483FEDF782430F65A358E0F6-- From nobody Wed Nov 1 10:29:48 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 4A97613F9CA for ; Wed, 1 Nov 2017 10:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 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_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 gFivkrn8-Rtk for ; Wed, 1 Nov 2017 10:29:45 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 ABFD413F984 for ; Wed, 1 Nov 2017 10:29:44 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id w134so3635729qkb.0 for ; Wed, 01 Nov 2017 10:29:44 -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=Ek1qkSLzUoQWmSnkOrRlbyloDgJ27ALqAQm3h7mbWMY=; b=Nal7WI+UqcdsKfI1pM6tfcJQFCkVd1VN6QXT2dYhZKiS1IKeqTv+HvilHKSOsk/dtP QvoTJPa5DuYF1E/nyIr6qxI8/a+S8re/WYnygEfbE7o03SF4bIdDoRHb0ljXqjIdmyyS 7sI51n9iNeKw40WcKqCRMLyqpM24e5R3E5ZViqyKVm4gxatu8s1DP+kRv+D8DIhAG9lh MOruCkemipLDMIZ2hTS40VbhJcTnbaiA+QgVtoYpnl/AqJDqa9SaTSLGWQC3CcjOIAHR NqXNoevUHqVSz1MjQqj34sBF683si2EeCDzyGIgXDxJ1ofYslo84Th5IwCVfwkuZf/HO 8H1Q== 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=Ek1qkSLzUoQWmSnkOrRlbyloDgJ27ALqAQm3h7mbWMY=; b=WARJsg4fZZGOJEQ5hs2HOY1BbF710jh2j0SUqdM92I3YebiUWdsguxGVdVEwpDAJDZ YdDEPgyL5WrXQ5r7VHuiWSFKeb4SrR0XwBTd0WSzPBWixre2WHxr3EFilxCcs8bHjGz+ w1Za0idMao2GDFYStysNE3RcHLSzOkprV/TjNN7NFWF8MHlTrqowjX+4q5ld9qIibtN9 7hbXkX7ZsQjhFmVY+cfEgVLHLCAHRtf88WftAQBlszXKKO6OPQkgWBoIov4NcyAFEJle tUq8s4HBkyXm+4Bc2Hp0kGaCXAQE55SwYbKrz/Dd/9jBVWS4WKmobaHeb67RZJR7FSCy fhXg== X-Gm-Message-State: AMCzsaV+BtOwU/f6lsFVaeG4Rfz6ngM0vevbWjF+OqHZLi0VJH5beNgN ihx2Qzm0KC3Y54AF/4hHYozdlikagh8= X-Google-Smtp-Source: ABhQp+STHLL8yCocayNI8+Jao8UCdyxoW3gaJ21NVsqD/2OkZWgkz3ldm+ReajW9ZDqMXwoaK2StJQ== X-Received: by 10.55.111.3 with SMTP id k3mr895732qkc.332.1509557383738; Wed, 01 Nov 2017 10:29:43 -0700 (PDT) Received: from [10.33.193.2] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id t18sm784212qtc.58.2017.11.01.10.29.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Nov 2017 10:29:42 -0700 (PDT) From: Brian Rosen Message-Id: <1A75128C-2308-444E-A55E-75959DA4B603@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_52C8837E-D0BC-42A8-9E28-D2B2B614B627" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 1 Nov 2017 13:29:40 -0400 In-Reply-To: <2fe92c9f-eae4-b539-ae81-d4dfef7c5e90@nostrum.com> Cc: SIPCORE , Henning Schulzrinne To: Adam Roach References: <58A326A7-BDD9-4508-BCC8-A7660D9C203D@vigilsec.com> <2fe92c9f-eae4-b539-ae81-d4dfef7c5e90@nostrum.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-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: Wed, 01 Nov 2017 17:29:47 -0000 --Apple-Mail=_52C8837E-D0BC-42A8-9E28-D2B2B614B627 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One possibility is for Henning to do a remote presentation in sipcore. = Time zone challenges of course. Brian > On Nov 1, 2017, at 11:21 AM, Adam Roach > wrote: >=20 > I've looked over the groups meeting later in the week, and can't find = another session that is likely to have the correct community of = interest. >=20 > I've also looked over the changes to the document, and they seem = entirely editorial (albeit with a change that technically does impact = the wire protocol). It's not clear that there are any remaining open = issues that would clearly benefit from face-to-face time. Henning: do = you have some questions you specifically wanted to address in the = meeting? Or did you just want to present a list of changes to give = people an opportunity to object? >=20 > If the latter, I believe it should be pretty easy for the chairs to = say: "We've renamed the 'spam' parameter to 'confidence', and made some = other minor editorial improvements. Interested parties should comment on = the list if they object." It's up to the chairs whether they want to = couple this request with a WGLC. >=20 > /a >=20 >> From: Henning Schulzrinne > >> Subject: draft-ietf-sipcore-callinfo-spam-02.txt >> Date: October 30, 2017 at 11:08:36 PM EDT >> To: sipcore-chairs@ietf.org , Stir = Chairs > >> Resent-From: > >> Resent-From: wg-alias-bounces@tools.ietf.org = >> Resent-To: housley@vigilsec.com , = rjsparks@nostrum.com >> Resent-To: stir-chairs@ietf.org >>=20 >> Brian & Jean: >>=20 >> I submitted draft-ietf-sipcore-callinfo-spam-02.txt, which addresses >> comments I have received. >>=20 >> I will be in Singapore, but an obligation related to a grant proposal >> makes me arrive Wednesday morning. If there was a need to discuss the >> draft, I had kind of hoped that we could move any draft discussion to >> STIR, since that seemed topically close and since it was meeting late >> in the week as of the time when I booked my flight, but that option = is >> apparently gone. (I know that session scheduling is tough given the >> various constraints, so I'm not complaining.) >>=20 >> In any event, I'd like to figure out how to wrap up the draft since >> discussion seems to have died down. >>=20 >> Henning >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_52C8837E-D0BC-42A8-9E28-D2B2B614B627 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii One possibility is for Henning to do a remote presentation in sipcore.  Time zone challenges of course.

Brian

On Nov 1, 2017, at 11:21 AM, Adam Roach <adam@nostrum.com> wrote:

I've looked over the groups meeting later in the week, and can't find another session that is likely to have the correct community of interest.

I've also looked over the changes to the document, and they seem entirely editorial (albeit with a change that technically does impact the wire protocol). It's not clear that there are any remaining open issues that would clearly benefit from face-to-face time. Henning: do you have some questions you specifically wanted to address in the meeting? Or did you just want to present a list of changes to give people an opportunity to object?

If the latter, I believe it should be pretty easy for the chairs to say: "We've renamed the 'spam' parameter to 'confidence', and made some other minor editorial improvements. Interested parties should comment on the list if they object." It's up to the chairs whether they want to couple this request with a WGLC.

/a

From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: draft-ietf-sipcore-callinfo-spam-02.txt
Date: October 30, 2017 at 11:08:36 PM EDT
Resent-From: <alias-bounces@ietf.org>

Brian & Jean:

I submitted draft-ietf-sipcore-callinfo-spam-02.txt, which addresses
comments I have received.

I will be in Singapore, but an obligation related to a grant proposal
makes me arrive Wednesday morning. If there was a need to discuss the
draft, I had kind of hoped that we could move any draft discussion to
STIR, since that seemed topically close and since it was meeting late
in the week as of the time when I booked my flight, but that option is
apparently gone. (I know that session scheduling is tough given the
various constraints, so I'm not complaining.)

In any event, I'd like to figure out how to wrap up the draft since
discussion seems to have died down.

Henning


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--Apple-Mail=_52C8837E-D0BC-42A8-9E28-D2B2B614B627-- From nobody Wed Nov 1 10:56: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 E55C513F44C for ; Wed, 1 Nov 2017 10:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 oW2vYFQU2itR for ; Wed, 1 Nov 2017 10:55:57 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576AA13871A for ; Wed, 1 Nov 2017 10:55:57 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by qproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 00E8612073B for ; Wed, 1 Nov 2017 11:55:57 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id Uhqt1w00a1MNPNq01hqwUJ; Wed, 01 Nov 2017 11:50:57 -0600 X-Authority-Analysis: v=2.2 cv=H76r+6Qi c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=sC3jslCIGhcA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8 a=Z80JlwQ0AAAA:8 a=tGX7uwomAAAA:8 a=gl1CgrNLLE5lQLC-CB0A:9 a=Pc1Tm4_foyTJoBSj:21 a=1RlI-B0YSLkCjhpB:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=BsuWh4Fl7XUsdRXN9xwA:9 a=1RAoRDP0hF4b28FD:21 a=Ot_Aud4VUFgU8h60:21 a=2yCvq9MuJGbX7tcV:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=5oret6oapBRfLy7jekVI:22 a=Zz-tw7mMPhxMdvFcggwQ:22 a=ZFOOzkjxzLGrPE5HuMia:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC: To:From:Subject:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Bi78iX4YBmLMG/AcwLDqWMd5fhQsfWWoVxyq+AMt5zU=; b=QTnqV5Y1m9g7PItMMbT8M25t4s nAJlG3C3QaYwYUpJnsKW0q5FRJ94SHnrAuKAbhpydpkawh09YlICkqr7MKKcYnk4qKto9ULOCqE/n sxJN74YMUZq6A2bejR/aRjQBy; Received: from pool-100-36-44-145.washdc.fios.verizon.net ([100.36.44.145]:60345 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1e9xAD-001IR8-5w; Wed, 01 Nov 2017 11:50:53 -0600 User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Wed, 01 Nov 2017 13:50:51 -0400 From: Richard Shockey To: Brian Rosen , Adam Roach CC: SIPCORE Message-ID: Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-02.txt References: <58A326A7-BDD9-4508-BCC8-A7660D9C203D@vigilsec.com> <2fe92c9f-eae4-b539-ae81-d4dfef7c5e90@nostrum.com> <1A75128C-2308-444E-A55E-75959DA4B603@brianrosen.net> In-Reply-To: <1A75128C-2308-444E-A55E-75959DA4B603@brianrosen.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3592389053_200599702" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.145 X-Exim-ID: 1e9xAD-001IR8-5w X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-145.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.145]:60345 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-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: Wed, 01 Nov 2017 17:56:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3592389053_200599702 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 Fine but ultimately unnecessary.=C2=A0 IMHO this should go to WGLC as soon as p= ossible.=20 =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 =20 From: sipcore on behalf of Brian Rosen Date: Wednesday, November 1, 2017 at 1:29 PM To: Adam Roach Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-02.txt =20 One possibility is for Henning to do a remote presentation in sipcore. Tim= e zone challenges of course. =20 Brian =20 On Nov 1, 2017, at 11:21 AM, Adam Roach wrote: =20 I've looked over the groups meeting later in the week, and can't find anoth= er session that is likely to have the correct community of interest. I've also looked over the changes to the document, and they seem entirely e= ditorial (albeit with a change that technically does impact the wire protoco= l). It's not clear that there are any remaining open issues that would clear= ly benefit from face-to-face time. Henning: do you have some questions you s= pecifically wanted to address in the meeting? Or did you just want to presen= t a list of changes to give people an opportunity to object? If the latter, I believe it should be pretty easy for the chairs to say: "W= e've renamed the 'spam' parameter to 'confidence', and made some other minor= editorial improvements. Interested parties should comment on the list if th= ey object." It's up to the chairs whether they want to couple this request w= ith a WGLC. /a From: Henning Schulzrinne Subject: draft-ietf-sipcore-callinfo-spam-02.txt Date: October 30, 2017 at 11:08:36 PM EDT To: sipcore-chairs@ietf.org, Stir Chairs Resent-From: Resent-From: wg-alias-bounces@tools.ietf.org Resent-To: housley@vigilsec.com, rjsparks@nostrum.com Resent-To: stir-chairs@ietf.org =20 Brian & Jean: I submitted draft-ietf-sipcore-callinfo-spam-02.txt, which addresses comments I have received. I will be in Singapore, but an obligation related to a grant proposal makes me arrive Wednesday morning. If there was a need to discuss the draft, I had kind of hoped that we could move any draft discussion to STIR, since that seemed topically close and since it was meeting late in the week as of the time when I booked my flight, but that option is apparently gone. (I know that session scheduling is tough given the various constraints, so I'm not complaining.) In any event, I'd like to figure out how to wrap up the draft since discussion seems to have died down. Henning =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =20 _______________________________________________ sipcore mailing list sipcor= e@ietf.org https://www.ietf.org/mailman/listinfo/sipcore=20 --B_3592389053_200599702 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

Fine but ultimately unnecessary.=C2=A0 IMHO this should go to WGLC as soon a= s possible.

 

=E2=80=94 =

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP = Forum

www.shockey.us=

www.sipforum.org

richard<at>shock= ey.us

Skype-Linkedin= -Facebook =E2=80=93Twitter  rshockey101

PSTN +1 703-593-2683

 

 

From= : sipcore <sipcore-= bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
<= b>Date: Wednesday, November 1, 2017 at 1:29 PM
To: Adam Roach = <adam@nostrum.com>
Cc: SIPCORE <sipcore@ietf.org>
<= b>Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-02.txt

 

One possibility is for Henning to do a remote presentation in = sipcore.  Time zone challenges of course.

 

Brian=

 

O= n Nov 1, 2017, at 11:21 AM, Adam Roach <adam@nostrum.com> wrote:

 

I= 've looked over the groups meeting later in the week, and can't find another= session that is likely to have the correct community of interest.

I'= ve also looked over the changes to the document, and they seem entirely edit= orial (albeit with a change that technically does impact the wire protocol).= It's not clear that there are any remaining open issues that would clearly = benefit from face-to-face time. Henning: do you have some questions you spec= ifically wanted to address in the meeting? Or did you just want to present a= list of changes to give people an opportunity to object?

If the latt= er, I believe it should be pretty easy for the chairs to say: "We've re= named the 'spam' parameter to 'confidence', and made some other minor editor= ial improvements. Interested parties should comment on the list if they obje= ct." It's up to the chairs whether they want to couple this request wit= h a WGLC.

/a

From: Henning Schulzrinne <hgs@cs.columbia.edu>

Subjec= t: draft-ietf-sipcore-callinfo-spam-02.txt

Date: Oc= tober 30, 2017 at 11:08:36 PM EDT

&nb= sp;

Brian= & Jean:

I submitted draft-ietf-sipcore-callinfo-spam-02.txt, whi= ch addresses
comments I have received.

I will be in Singapore, but= an obligation related to a grant proposal
makes me arrive Wednesday morn= ing. If there was a need to discuss the
draft, I had kind of hoped that w= e could move any draft discussion to
STIR, since that seemed topically cl= ose and since it was meeting late
in the week as of the time when I booke= d my flight, but that option is
apparently gone. (I know that session sch= eduling is tough given the
various constraints, so I'm not complaining.)<= br>
In any event, I'd like to figure out how to wrap up the draft sincediscussion seems to have died down.

Henning

 

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/m= ailman/listinfo/sipcore

 

________= _______________________________________ sipcore mailing list sipcore@ietf.or= g https://www.ietf.org/mailman/listinfo/sipcore

= --B_3592389053_200599702-- From nobody Wed Nov 1 11:08: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 2AA1213F9E9 for ; Wed, 1 Nov 2017 11:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 SSbpdI-pqoRG for ; Wed, 1 Nov 2017 11:08:50 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (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 7331D13F5B1 for ; Wed, 1 Nov 2017 11:08:50 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id vA1I8hgb055129 for ; Wed, 1 Nov 2017 14:08:49 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 75BB77E for ; Wed, 1 Nov 2017 14:08:49 -0400 (EDT) Received: from sendprodmail02.cc.columbia.edu (sendprodmail02.cc.columbia.edu [128.59.72.14]) by hazelnut (Postfix) with ESMTP id 5E9CD7E for ; Wed, 1 Nov 2017 14:08:49 -0400 (EDT) Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by sendprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id vA1I8mPC029558 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 1 Nov 2017 14:08:49 -0400 Received: by mail-oi0-f70.google.com with SMTP id l5so3386438oib.0 for ; Wed, 01 Nov 2017 11:08:48 -0700 (PDT) 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=zfJJUoQMr6G6ytkaubsWd1LLlQLNE2TE6Z5mDo/B7bg=; b=hocayUM3eVlHPowYtrZtjDk45PZv5ModlsgbmKLclsvph4tFxECAFtUwCVSHvrZbUq aiYgU8NaO/i64AWYmKhmoJjx4UqUpnEtPWtBiOMm/30wQh93henH/soQjc2KLz3Ov9cy 4VoYs7aycSTl35FtzAqaQizOebUxPIGh6F4Zwc2cmReW79kQrOvcZYBZUURQirioMKZS SkFvr3T6pF/a5zm/tb/Mpl/7toh71JEO3S2OUzduHRk428klGEYfXTkktPfcRDg1Q4f0 Q1XXYHPqryMEAno+zXHa2TS0kzYxZzIiyvNmXGmamQkoo+nOuWzGwA2iV8+3UEAtA2Wn A/wg== X-Gm-Message-State: AMCzsaWCrSi2owC0Q/bmmzGOO60dH9PdmNENXjFomZRsbePuzjerB42/ mVkZPVoNodc8lltffLJkCa9qG945k6KuI82NUQcHcnrLqDdNVC03gAfPGpG5S1MjOav6SSZ3Lp7 1kBBHLpFAiUMqMnmEeWb87QkErVvn2fZ1 X-Received: by 10.202.237.137 with SMTP id l131mr405084oih.168.1509559728389; Wed, 01 Nov 2017 11:08:48 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RLLq93GUig2PIZWQIOCbsIHPY6FYq/Ddjdu0pJ5W30fI8uSxUplY/98LP8Oap3n68TeURFeVrE5AVjxgeIkls= X-Received: by 10.202.237.137 with SMTP id l131mr405074oih.168.1509559727972; Wed, 01 Nov 2017 11:08:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.8.54 with HTTP; Wed, 1 Nov 2017 11:08:27 -0700 (PDT) In-Reply-To: <1A75128C-2308-444E-A55E-75959DA4B603@brianrosen.net> References: <58A326A7-BDD9-4508-BCC8-A7660D9C203D@vigilsec.com> <2fe92c9f-eae4-b539-ae81-d4dfef7c5e90@nostrum.com> <1A75128C-2308-444E-A55E-75959DA4B603@brianrosen.net> From: Henning Schulzrinne Date: Wed, 1 Nov 2017 14:08:27 -0400 Message-ID: To: Brian Rosen Cc: Adam Roach , SIPCORE Content-Type: multipart/alternative; boundary="001a113df3f05a7b47055cefc307" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.14 Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-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: Wed, 01 Nov 2017 18:08:52 -0000 --001a113df3f05a7b47055cefc307 Content-Type: text/plain; charset="UTF-8" I agree - the changes are meant to be purely editorial. Thus, if the chairs believe that this is ready for WGLC, that would be a good outcome in my book... That said, I'm happy to do a presentation remotely. From what I can tell, SIPCORE ends at 18:40 Singapore and is 5:40 am NYC, so not completely ridiculous. Henning On Wed, Nov 1, 2017 at 1:29 PM, Brian Rosen wrote: > One possibility is for Henning to do a remote presentation in sipcore. > Time zone challenges of course. > > Brian > > On Nov 1, 2017, at 11:21 AM, Adam Roach wrote: > > I've looked over the groups meeting later in the week, and can't find > another session that is likely to have the correct community of interest. > > I've also looked over the changes to the document, and they seem entirely > editorial (albeit with a change that technically does impact the wire > protocol). It's not clear that there are any remaining open issues that > would clearly benefit from face-to-face time. Henning: do you have some > questions you specifically wanted to address in the meeting? Or did you > just want to present a list of changes to give people an opportunity to > object? > > If the latter, I believe it should be pretty easy for the chairs to say: > "We've renamed the 'spam' parameter to 'confidence', and made some other > minor editorial improvements. Interested parties should comment on the list > if they object." It's up to the chairs whether they want to couple this > request with a WGLC. > > /a > > *From: *Henning Schulzrinne > *Subject: **draft-ietf-sipcore-callinfo-spam-02.txt* > *Date: *October 30, 2017 at 11:08:36 PM EDT > *To: *sipcore-chairs@ietf.org, Stir Chairs > *Resent-From: * > *Resent-From: *wg-alias-bounces@tools.ietf.org > *Resent-To: *housley@vigilsec.com, rjsparks@nostrum.com > *Resent-To: *stir-chairs@ietf.org > > Brian & Jean: > > I submitted draft-ietf-sipcore-callinfo-spam-02.txt, which addresses > comments I have received. > > I will be in Singapore, but an obligation related to a grant proposal > makes me arrive Wednesday morning. If there was a need to discuss the > draft, I had kind of hoped that we could move any draft discussion to > STIR, since that seemed topically close and since it was meeting late > in the week as of the time when I booked my flight, but that option is > apparently gone. (I know that session scheduling is tough given the > various constraints, so I'm not complaining.) > > In any event, I'd like to figure out how to wrap up the draft since > discussion seems to have died down. > > Henning > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --001a113df3f05a7b47055cefc307 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree - the changes are meant to be purely editorial. Th= us, if the chairs believe that this is ready for WGLC, that would be a good= outcome in my book...

That said, I'm happy to do a = presentation remotely. From what I can tell, SIPCORE ends at 18:40 Singapor= e and is 5:40 am NYC, so not completely ridiculous.

Henning

On Wed, Nov 1, 2017 at 1:29 PM, Brian Rosen <br@brianrosen.net>= wrote:
One possibility is for Henning to do a remote presentation in sip= core.=C2=A0 Time zone challenges of course.

Brian
<= div>
On Nov 1, 2017, at 11= :21 AM, Adam Roach <adam@nostrum.com> wrote:

=20 =20 =20
I've looked over the groups meeting later in the week, and can'= t find another session that is likely to have the correct community of interest.

I've also looked over the changes to the document, and they seem entirely editorial (albeit with a change that technically does impact the wire protocol). It's not clear that there are any remaining open issues that would clearly benefit from face-to-face time. Henning: do you have some questions you specifically wanted to address in the meeting? Or did you just want to present a list of changes to give people an opportunity to object?

If the latter, I believe it should be pretty easy for the chairs to say: "We've renamed the 'spam' parameter to 'confi= dence', and made some other minor editorial improvements. Interested parties should comment on the list if they object." It's up to the chairs whe= ther they want to couple this request with a WGLC.

/a

From: Henning Sch= ulzrinne <hgs@c= s.columbia.edu>
Subject: draft= -ietf-sipcore-callinfo-spam-02.txt
Date: October 30,= 2017 at 11:08:36 PM EDT
Resent-From: &l= t;alias-bounces= @ietf.org>
Resent-From: wg-alias= -bounces@tools.ietf.org

Brian & Jean:

I submitted draft-ietf-sipcore-callinfo-spam-02.txt, whi= ch addresses
comments I have received.

I will be in Singapore, but an obligation related to a grant proposal
makes me arrive Wednesday morning. If there was a need to discuss the
draft, I had kind of hoped that we could move any draft discussion to
STIR, since that seemed topically close and since it was meeting late
in the week as of the time when I booked my flight, but that option is
apparently gone. (I know that session scheduling is tough given the
various constraints, so I'm not complaining.)

In any event, I'd like to figure out how to wrap up the draft since
discussion seems to have died down.

Henning


_______________________________________________
sipcore mailing lis= t
sipcore@ietf.org=
https://www.ietf.org/mailman/listinfo/sipcore


--001a113df3f05a7b47055cefc307-- From nobody Wed Nov 1 23:59: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 439C013F9C8 for ; Wed, 1 Nov 2017 23:59:34 -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 kuQ22WGd_QK9 for ; Wed, 1 Nov 2017 23:59:31 -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 5015B13F9B7 for ; Wed, 1 Nov 2017 23:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1509605970; x=1541141970; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bUn4PZ8Qv8RkO3ph4R7pgLFlyYucn8JnXdRUjpugbnM=; b=3+ASEO5joZR1pGV9oAPSvSFHo3CCpY0YU9XI6j5Rxs6p9dtrq3pEcc23 7Bk3MS7ZngcH7i/xKMGnW84l3iW2yVgwxnP7yyUv4qdOc4OeXfzhaSuEG yg8vzSdmLcJk7kT1JXF5xwMTNIgzifl70e4L6g/TulNBy9Nt85P9gmhDi ocPmKtp5RVYW6GifWNW4x+oqJSFB8V82/cD4j1p/aKAXfYAE+ZP/YpROz AK33QjiNSV60sCQpTMvkBPZiBUCjNrBTtcWMoxebvMON0yEvERQsGl5fu qlMyKO++pY+9Aw0MHd27ao6O4Moye/Lm41sOx2KgEHCybGr+EsvRGZvRC Q==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 07:59:27 +0100 X-IronPort-AV: E=Sophos;i="5.44,332,1505772000"; d="scan'208,217";a="106941213" Received: from he105662.emea1.cds.t-internal.com ([10.169.119.58]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 02 Nov 2017 07:59:26 +0100 Received: from HE106142.EMEA1.cds.t-internal.com (10.169.119.76) by HE105662.emea1.cds.t-internal.com (10.169.119.58) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 07:59:26 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE106142.EMEA1.cds.t-internal.com (10.169.119.76) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 2 Nov 2017 07:59:26 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.21) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 07:58:52 +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; Thu, 2 Nov 2017 06:59:23 +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.015; Thu, 2 Nov 2017 06:59:23 +0000 From: "Jesske, Roland" To: Christer Holmberg , Roman Shpount CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnUFtGaBJrWltk+s1shdGvlnWqL+S3eAgAEO8PA= Date: Thu, 2 Nov 2017 06:59:23 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> 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.154] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0484; 6:i0gw6Y4gdqQnlrTscKeAmagjMrjrVJGS8lb02ZSDOoRO1fFS7vwdOszRg7ppEHE3eHD0NF+mSDNqQHH8u6CuETRqt3ZdeniEBV3R/A4Q3RR8BUU113I4IUhS1U8++YAmJbU1QI14BVPdoJpiKRy0lEvXj0PRFwkW1fzTZpfubbvoVMOnyzdVSG3Z9m09gpXhK3drQF4QXHqdMXMktTvzerrQmiVGyUgzw3bgkSPrsKk+ysjdNnNmoIGFh+3hFDXGH6c/27Xhf7YVByU/N8zS9JYW6ZnwjX3V2dMu3NvJDHGy21fHOw2UJrHns3VEJ2X9UE5eMOyq4jeWUcz8QGnpBRMS6CV8UahnR25kwuIU8ZQ=; 5:Mo+1VBgPrvugqykle8x/l9sqQA8g9AORVZCyXEXrbdG/Eoe3iJHHdPcsVeNEVHOc/V9+T5SyFQ2qrWP3mB7QGjBZN4sQmtPX0qGwePzhwKcN6PaLb7uh8484k2eZtVjgolrAkDZ1qu8y07wx5kZImH6twd37j4bu7YMsNH2qdys=; 24:MiSRZj3mf+/tkQ5y7HWI0YLiHrkjFYJ0mxd5VGCmKoAT216IQANGRc8BPuQoufoS5uhxfwbr9amhXO2ORRH/mdDCSTd4RAKcbomBeNTq19w=; 7:aoe6aWhvU9fCR4nNU+edshCMSi0/D9VByW6ahpVseYlqAfDQUQs3SZbNhafkr5tVuvB0LPix+sh38WwW8W16xDSfmQhEBMBcaLPOkbLIktZIPXmefV1hqnQxdvNli07IrMAQS6G/d9nbM3cjh0W/0q0qPRXsZ3OWu9/zU4gqvjReE/FLRnsl5qbYZFUWZBJBc+gzx2/VBZFJNU0jL0A5jmVEeqdlUl8cQtpLkQGRF9mMVwRYPof1ELhzN70MY/aa x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 72ab349b-5e19-455a-2edc-08d521bf3fda x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:FRAPR01MB0484; x-ms-traffictypediagnostic: FRAPR01MB0484: x-exchange-antispam-report-test: UriScan:(37575265505322)(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)(10201501046)(3231020)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(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: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(76104003)(199003)(24454002)(189002)(55016002)(6116002)(54356999)(53546010)(76176999)(5660300001)(74482002)(50986999)(14454004)(101416001)(33656002)(551934003)(4326008)(75402003)(68736007)(478600001)(790700001)(3660700001)(106356001)(86362001)(102836003)(3846002)(7696004)(72206003)(54896002)(236005)(6306002)(9686003)(105586002)(3280700002)(7736002)(316002)(53936002)(2950100002)(5250100002)(2906002)(93886005)(97736004)(66066001)(8936002)(110136005)(54906003)(81156014)(189998001)(8676002)(81166006)(2900100001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0484; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:3; 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_FRAPR01MB0483B6142F0DECC73A3D2818F95C0FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 72ab349b-5e19-455a-2edc-08d521bf3fda X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 06:59:23.5901 (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: Thu, 02 Nov 2017 06:59:34 -0000 --_000_FRAPR01MB0483B6142F0DECC73A3D2818F95C0FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIGFncmVlIG9uIENocmlzdGVy4oCZcyBjb21tZW50Lg0KQnV0IG5ldmVydGhlbGVzcyBJ IHdvdWxkIGJlIGhhcHB5IHRvIHNlZSBhIGNsZWFyIGFkdmljZSBmb3IgdGhlIHJlZnJlc2ggbWVj aGFuaXNtIHdoZW4gdGhlIFMtRSB0aW1lciBpcyBzd2l0Y2hlZCBvZmYuDQpQZXJoYXBzIGFuIHRh YmxlIGFuZCBzb21lIHRleHQgaW4gc2VjdGlvbiA3LjQgZm9yIHRoZSByZWZyZXNoIG1lY2hhbmlz bSB3b3VsZCBoZWxwIGUuZy46DQoNClRoaXMgaXMgdmFsaWQgZm9yIFVQREFURSBhbmQgSU5WSVRF IHJlZnJlc2hpbmcgYSBzZXNzaW9uIHdoZXJlIFMtRSBpcyBuZWdvdGlhdGVkIGFuZCB0aGUgc3Vw cG9ydGVkIGhlYWRlciB3aXRoIHRpbWVyIGlzIHNldC4NCg0KDQpVQUMgc3VwcG9ydHM/ICAgIFNF IHBhcmFtZXRlciAgICBTLUUgcGFyYW1ldGVyICAgICAgICBTLUUNCiAgICAgICAgICAgICAgICAg IGluIHJlcXVlc3QgICAgIGluIHJlc3BvbnNlICAgICAgc3dpdGNoZWQgb2ZmDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICBZ ICAgICAgICAgICAgICBZICAgICAgICAgICAgICAgIE4gICAgICAgICAgICAgICAgWQ0KICAgICAg WSAgICAgICAgICAgICAgTiAgICAgICAgICAgICAgICBZICAgICAgICAgICAgICAgIE4NCiAgICAg IFkgICAgICAgICAgICAgIE4gICAgICAgICAgICAgICAgTiAgICAgICAgICAgICAgICBZDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSBYIFN3aXRjaCBvZmYgUy1FDQoNCldoZW4gdGhl IHdoZW4gcmVxdWlyZWQgdGltZXIgc2V0IHRoZSBTLUUgY2Fubm90IGJlIHN3aXRjaGVkIG9mZi4N Cg0KV2hhdCBkbyB5b3UgdGhpbms/DQpPZiBjb3Vyc2Ugd2UgY291bGQgZG8gdGhlIHNhbWUgZm9y IHRoZSBpbml0aWFsIG5lZ290aWF0aW9uIHRvIG1ha2UgZXZlcnl0aGluZyBjbGVhci4NCg0KQmVz dCBSZWdhcmRzDQoNClJvbGFuZA0KDQoNClZvbjogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpHZXNlbmRldDogRGllbnN0YWcsIDMxLiBP a3RvYmVyIDIwMTcgMTk6NDQNCkFuOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4N CkNjOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IEplc3NrZSwgUm9sYW5k IDxSLkplc3NrZUB0ZWxla29tLmRlPjsgc2lwY29yZUBpZXRmLm9yZw0KQmV0cmVmZjogUkU6IFtz aXBjb3JlXSBTZXNzaW9uIHRpbWVyIGZpeA0KDQpIaSwNCg0KSSBtYXkgcmVwbHkgdG8gUm9tYW7i gJlzIGNvbW1lbnRzIGxhdGVyLg0KDQpCdXQsIGF0IHRoZSBlbmQgb2YgdGhlIGRheSBJIHRoaW5r IHdoYXQgUGF1bCBzYWlkIGlzIHdoYXQgbWF0dGVycyBtb3N0OiB0aGUgcHJvY2VkdXJlcyBmb3Ig dHVybmluZyBzZXNzaW9uIHRpbWVyIGV0YyBhcHBsaWVzIEFGVEVSIHRoZSBzZXNzaW9uIHRpbWVy IGhhcyBiZWVuIGZ1bGx5IG5lZ290aWF0ZWQuDQoNClNvLCBpZiB0aGUgc2Vzc2lvbiB0aW1lciBp cyBuZWdvdGlhdGVkIGR1cmluZyB0aGUgaW5pdGlhbCBJTlZJVEUgdHJhbnNhY3Rpb24sIHdoYXRl dmVyIFVQREFURXMgYXJlIHNlbnQgZHVyaW5nIHRoYXQgdHJhbnNhY3Rpb24gd2lsbCBub3QgY29u dGFpbiBzZXNzaW9uIHRpbWVyIGluZm9ybWF0aW9uLCBhbmQgdGhleSB3aWxsIGhhdmUgbm8gaW1w YWN0IG9uIHRoZSBzZXNzaW9uIHRpbWVyLg0KDQpCdXQsIG9uY2UgdGhlIHNlc3Npb24gdGltZXIg aGFzIGJlZW4gbmVnb3RpYXRlZCAob25jZSB0aGUgVUFDIGhhcyByZWNlaXZlZCB0aGUgMjAwIE9L LCB0aGUgcnVsZXMgcmVnYXJkaW5nIHR1cm5pbmcgdGhlIHNlc3Npb24gdGltZXIgb2ZmIGV0YyBh cHBsaWVzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IFJvbWFuIFNocG91bnQg W21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDMxIE9jdG9iZXIgMjAxNyAyMDoyMQ0K VG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpDYzogUGF1bCBLeXppdmF0IDxw a3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+OyBKZXNz a2UsIFJvbGFuZCA8Ui5KZXNza2VAdGVsZWtvbS5kZTxtYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5k ZT4+OyBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtzaXBjb3JlXSBTZXNzaW9uIHRpbWVyIGZpeA0KDQoNCk9uIFR1ZSwgT2N0IDMxLCAyMDE3 IGF0IDQ6MzUgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KTXkg c3VnZ2VzdGlvbiBpcyB0aGF0IG5vLVNFLWluLXJlc3BvbnNlIHdvdWxkIHN3aXRjaCBvZmYgaWYg U0Ugd2FzIGluIHRoZQ0KcmVxdWVzdC4NCg0KU28sIGlmIHRoZXJlIGlzIG5vIFNFIGluIHRoZSBy ZXF1ZXN0LCB0aGVyZSBpcyBubyBzd2l0Y2ggb2ZmLg0KDQpUaGlzIHdpbGwgYnJlYWsgcHJldHR5 IG11Y2ggZXZlcnkgU0UgaW1wbGVtZW50YXRpb24uIFRoZXJlIGFyZSBudW1iZXIgb2YgaW1wbGVt ZW50YXRpb25zIHdoZXJlIFVBIGRvZXMgbm90IGluc2VydCBTRSBpbiB0aGUgcmVxdWVzdC4gSXQg aXMgaW5zZXJ0ZWQgZWl0aGVyIGJ5IHByb3hpZXMgKGFjdHVhbGx5IHRoaXMgaXMgdGhlIG1vc3Qg Y29tbW9uIHVzZSBjYXNlKSBvciBieSB0aGUgYW5zd2VyaW5nIGFnZW50Lg0KDQpJIHRoaW5rIGl0 IHdvdWxkIGJlIG11Y2ggYmV0dGVyIHRvIGhhdmUgYSBuZXcgaGVhZGVyIHdoaWNoIHdpbGwgc3Bl Y2lmeSAiZG8gbm90IHVwZGF0ZSBTZXNzaW9uLVRpbWVyIiBpbiB0aGUgb2ZmZXIuDQpUaGlzIHdh eSBpZiBwcm94aWVzIGluc2VydCBTZXNzaW9uLVRpbWVyLCBuZXcgaGVhZGVyIHdpbGwgb3Zlcndy aXRlLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQo= --_000_FRAPR01MB0483B6142F0DECC73A3D2818F95C0FRAPR01MB0483DEUP_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFZvcmZvcm1hdGllcnRaY2hu DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1hdGllcnQiOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyMw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFncmVlIG9uIENocmlzdGVy4oCZcyBj b21tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJ1dCBu ZXZlcnRoZWxlc3MgSSB3b3VsZCBiZSBoYXBweSB0byBzZWUgYSBjbGVhciBhZHZpY2UgZm9yIHRo ZSByZWZyZXNoIG1lY2hhbmlzbSB3aGVuIHRoZSBTLUUgdGltZXIgaXMgc3dpdGNoZWQgb2ZmLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlBlcmhhcHMgYW4gdGFi bGUgYW5kIHNvbWUgdGV4dCBpbiBzZWN0aW9uIDcuNCBmb3IgdGhlIHJlZnJlc2ggbWVjaGFuaXNt IHdvdWxkIGhlbHAgZS5nLjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlRoaXMgaXMgdmFsaWQgZm9yIFVQREFURSBhbmQgSU5WSVRFIHJl ZnJlc2hpbmcgYSBzZXNzaW9uIHdoZXJlIFMtRSBpcyBuZWdvdGlhdGVkIGFuZCB0aGUgc3VwcG9y dGVkIGhlYWRlciB3aXRoIHRpbWVyIGlzIHNldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlVBQyBzdXBwb3J0cz8mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJJVCIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPlNFIHBhcmFtZXRlciZuYnNwOyZuYnNwOyZuYnNwOyBTLUUgcGFyYW1ldGVyJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO1MtRQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pbiByZXF1ZXN0 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIHJlc3BvbnNlJm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3N3aXRjaGVkDQogb2ZmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgWTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBZJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBZJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUg WCBTd2l0Y2ggb2ZmIFMtRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XaGVuIHRo ZSB3aGVuIHJlcXVpcmVkIHRpbWVyIHNldCB0aGUgUy1FIGNhbm5vdCBiZSBzd2l0Y2hlZCBvZmYu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCBkbyB5b3UgdGhpbms/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+T2YgY291cnNlIHdl IGNvdWxkIGRvIHRoZSBzYW1lIGZvciB0aGUgaW5pdGlhbCBuZWdvdGlhdGlvbiB0byBtYWtlIGV2 ZXJ5dGhpbmcgY2xlYXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVz dCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Um9sYW5kPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Wb246PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQ2hyaXN0ZXIgSG9s bWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQo8YnI+DQo8Yj5H ZXNlbmRldDo8L2I+IERpZW5zdGFnLCAzMS4gT2t0b2JlciAyMDE3IDE5OjQ0PGJyPg0KPGI+QW46 PC9iPiBSb21hbiBTaHBvdW50ICZsdDtyb21hbkB0ZWx1cml4LmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1Jmd0OzsgSmVzc2tlLCBS b2xhbmQgJmx0O1IuSmVzc2tlQHRlbGVrb20uZGUmZ3Q7OyBzaXBjb3JlQGlldGYub3JnPGJyPg0K PGI+QmV0cmVmZjo8L2I+IFJFOiBbc2lwY29yZV0gU2Vzc2lvbiB0aW1lciBmaXg8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgbWF5IHJlcGx5IHRvIFJvbWFu4oCZcyBj b21tZW50cyBsYXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QnV0LCBhdCB0aGUgZW5kIG9mIHRoZSBkYXkgSSB0aGlu ayB3aGF0IFBhdWwgc2FpZCBpcyB3aGF0IG1hdHRlcnMgbW9zdDogdGhlIHByb2NlZHVyZXMgZm9y IHR1cm5pbmcgc2Vzc2lvbiB0aW1lciBldGMgYXBwbGllcw0KIEFGVEVSIHRoZSBzZXNzaW9uIHRp bWVyIGhhcyBiZWVuIGZ1bGx5IG5lZ290aWF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvLCBpZiB0aGUgc2Vzc2lv biB0aW1lciBpcyBuZWdvdGlhdGVkIGR1cmluZyB0aGUgaW5pdGlhbCBJTlZJVEUgdHJhbnNhY3Rp b24sIHdoYXRldmVyIFVQREFURXMgYXJlIHNlbnQgZHVyaW5nIHRoYXQgdHJhbnNhY3Rpb24NCiB3 aWxsIG5vdCBjb250YWluIHNlc3Npb24gdGltZXIgaW5mb3JtYXRpb24sIGFuZCB0aGV5IHdpbGwg aGF2ZSBubyBpbXBhY3Qgb24gdGhlIHNlc3Npb24gdGltZXIuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJ1dCwgb25jZSB0 aGUgc2Vzc2lvbiB0aW1lciBoYXMgYmVlbiBuZWdvdGlhdGVkIChvbmNlIHRoZSBVQUMgaGFzIHJl Y2VpdmVkIHRoZSAyMDAgT0s8YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPiwgdGhlIHJ1bGVzDQog cmVnYXJkaW5nIHR1cm5pbmcgdGhlIHNlc3Npb24gdGltZXIgb2ZmIGV0YyBhcHBsaWVzLjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBSb21hbiBTaHBvdW50IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYWlsdG86cm9tYW5AdGVsdXJpeC5j b208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiAzMSBPY3RvYmVyIDIwMTcgMjA6MjE8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhv bG1iZXJnICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBQYXVsIEt5eml2YXQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cGt5eml2YXRAYWx1bS5taXQuZWR1Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5wa3l6 aXZhdEBhbHVtLm1pdC5lZHU8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDs7DQogSmVzc2tlLCBSb2xhbmQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86Ui5KZXNz a2VAdGVsZWtvbS5kZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Ui5KZXNza2VAdGVs ZWtvbS5kZTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCjwv c3Bhbj48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+c2lwY29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gU2Vzc2lvbiB0 aW1lciBmaXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBUdWUsIE9jdCAzMSwgMjAxNyBh dCA0OjM1IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJFTi1HQiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48c3BhbiBs YW5nPSJFTi1HQiI+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5NeSBzdWdnZXN0aW9uIGlzIHRoYXQgbm8tU0UtaW4tcmVz cG9uc2Ugd291bGQgc3dpdGNoIG9mZiBpZiBTRSB3YXMgaW4gdGhlPGJyPg0KcmVxdWVzdC48YnI+ DQo8YnI+DQpTbywgaWYgdGhlcmUgaXMgbm8gU0UgaW4gdGhlIHJlcXVlc3QsIHRoZXJlIGlzIG5v IHN3aXRjaCBvZmYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+VGhpcyB3aWxsIGJyZWFrIHByZXR0eSBtdWNoIGV2ZXJ5IFNFIGltcGxlbWVu dGF0aW9uLiBUaGVyZSBhcmUgbnVtYmVyIG9mIGltcGxlbWVudGF0aW9ucyB3aGVyZSBVQSBkb2Vz IG5vdCBpbnNlcnQgU0UgaW4gdGhlIHJlcXVlc3QuIEl0IGlzIGluc2VydGVkIGVpdGhlciBieSBw cm94aWVzIChhY3R1YWxseSB0aGlzIGlzIHRoZSBtb3N0IGNvbW1vbiB1c2UgY2FzZSkgb3IgYnkg dGhlDQogYW5zd2VyaW5nIGFnZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+SSB0aGluayBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBoYXZlIGEg bmV3IGhlYWRlciB3aGljaCB3aWxsIHNwZWNpZnkgJnF1b3Q7ZG8gbm90IHVwZGF0ZSBTZXNzaW9u LVRpbWVyJnF1b3Q7IGluIHRoZSBvZmZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhpcyB3YXkg aWYgcHJveGllcyBpbnNlcnQgU2Vzc2lvbi1UaW1lciwgbmV3IGhlYWRlciB3aWxsIG92ZXJ3cml0 ZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5fX19fX19fX19fX19fPGJyPg0K Um9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FRAPR01MB0483B6142F0DECC73A3D2818F95C0FRAPR01MB0483DEUP_-- From nobody Thu Nov 2 08:55:04 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 A4517139504 for ; Thu, 2 Nov 2017 08:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.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 78THXqiOhAhQ for ; Thu, 2 Nov 2017 08:54:58 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8675C1386A2 for ; Thu, 2 Nov 2017 08:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=752k5YFuHiX51e6u0RZmUrOPTLP56lVe9Jy2MEjyhj4=; b=EDSgHuN84GQAk0UWcGu3Y2vrWlRmQuVGEhigoC3kdhYwSeNMeItfbp1rxSMMyDRi/FmF87RrdGtM/U8xluCmOSI6jAOcT1U5mSFf7XEnAiCTYPsvcBaFKHf6/f225FS5pZCcCKccu1MktpuTkKnQpxPFiKBTi2ypfIuOvbU9nP8= Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0024.outbound.protection.outlook.com [207.46.163.24]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-191-x60MLlfcNLm81TG-1wc12w-1; Thu, 02 Nov 2017 11:54:55 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Thu, 2 Nov 2017 15:54:52 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::c532:11bc:1c27:ed20]) by SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::c532:11bc:1c27:ed20%18]) with mapi id 15.20.0197.013; Thu, 2 Nov 2017 15:54:52 +0000 From: "Asveren, Tolga" To: Richard Shockey , Brian Rosen , Adam Roach CC: SIPCORE Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-02.txt Thread-Index: AQHTUzcJsPXJqIVRAEGw7e1k9Th1G6L/zXuAgAFx2ZA= Date: Thu, 2 Nov 2017 15:54:52 +0000 Message-ID: References: <58A326A7-BDD9-4508-BCC8-A7660D9C203D@vigilsec.com> <2fe92c9f-eae4-b539-ae81-d4dfef7c5e90@nostrum.com> <1A75128C-2308-444E-A55E-75959DA4B603@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 20:gEkuuXtJNCzReadzOUnJkzxSIBkcgS/rqOBVnWhFfBK8MiEtFewYwFjjvQha2E5Gdd4GHIld0YOZbOauvzQtRvfXU59lAr8w7UyHc4ySnjjYW25ukjyTam4gnEDzEeb/asbXCy3AvwDTUyyw9CKp7b+0Y5V5DcrNeapxInXUs5k= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f440d9be-0013-446e-06bf-08d5220a0e5b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:SN2PR03MB2349; x-ms-traffictypediagnostic: SN2PR03MB2349: x-exchange-antispam-report-test: UriScan:(85170053105377)(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)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(3231020)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2349; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(24454002)(199003)(189002)(81156014)(229853002)(189998001)(76176999)(54356999)(50986999)(606006)(25786009)(1680700002)(4326008)(45080400002)(3280700002)(7736002)(5660300001)(8676002)(101416001)(3660700001)(102836003)(53386004)(68736007)(3846002)(561944003)(97736004)(81166006)(2906002)(53546010)(790700001)(6116002)(105586002)(106356001)(93886005)(7696004)(316002)(236005)(966005)(74316002)(33656002)(8936002)(478600001)(110136005)(53936002)(6246003)(2950100002)(66066001)(14454004)(5250100002)(230783001)(6506006)(9686003)(55016002)(86362001)(2900100001)(54896002)(6306002)(6436002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-Network-Message-Id: f440d9be-0013-446e-06bf-08d5220a0e5b X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 15:54:52.7406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: x60MLlfcNLm81TG-1wc12w-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350D75BAA1625AFB8B2EECCB25C0SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-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, 02 Nov 2017 15:55:03 -0000 --_000_SN2PR03MB2350D75BAA1625AFB8B2EECCB25C0SN2PR03MB2350namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgc2FtZS4NClRoYW5rcywNClRvbGdhDQoNCkZyb206IHNpcGNvcmUgW21haWx0 bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNoYXJkIFNob2NrZXkN ClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyAxOjUxIFBNDQpUbzogQnJpYW4gUm9z ZW4gPGJyQGJyaWFucm9zZW4ubmV0PjsgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT4NCkNj OiBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBkcmFm dC1pZXRmLXNpcGNvcmUtY2FsbGluZm8tc3BhbS0wMi50eHQNCg0KDQpGaW5lIGJ1dCB1bHRpbWF0 ZWx5IHVubmVjZXNzYXJ5LiAgSU1ITyB0aGlzIHNob3VsZCBnbyB0byBXR0xDIGFzIHNvb24gYXMg cG9zc2libGUuDQoNCuKAlA0KDQpSaWNoYXJkIFNob2NrZXkNCg0KU2hvY2tleSBDb25zdWx0aW5n IExMQw0KDQpDaGFpcm1hbiBvZiB0aGUgQm9hcmQgU0lQIEZvcnVtDQoNCnd3dy5zaG9ja2V5LnVz PGh0dHA6Ly93d3cuc2hvY2tleS51cz4NCg0Kd3d3LnNpcGZvcnVtLm9yZzxodHRwOi8vd3d3LnNp cGZvcnVtLm9yZz4NCg0KcmljaGFyZDxhdD5zaG9ja2V5LnVzDQoNClNreXBlLUxpbmtlZGluLUZh Y2Vib29rIOKAk1R3aXR0ZXIgIHJzaG9ja2V5MTAxDQoNClBTVE4gKzEgNzAzLTU5My0yNjgzDQoN Cg0KRnJvbTogc2lwY29yZSA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9z ZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIE5vdmVt YmVyIDEsIDIwMTcgYXQgMToyOSBQTQ0KVG86IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208 bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+Pg0KQ2M6IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc8 bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBkcmFmdC1p ZXRmLXNpcGNvcmUtY2FsbGluZm8tc3BhbS0wMi50eHQNCg0KT25lIHBvc3NpYmlsaXR5IGlzIGZv ciBIZW5uaW5nIHRvIGRvIGEgcmVtb3RlIHByZXNlbnRhdGlvbiBpbiBzaXBjb3JlLiAgVGltZSB6 b25lIGNoYWxsZW5nZXMgb2YgY291cnNlLg0KDQpCcmlhbg0KDQpPbiBOb3YgMSwgMjAxNywgYXQg MTE6MjEgQU0sIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1 bS5jb20+PiB3cm90ZToNCg0KSSd2ZSBsb29rZWQgb3ZlciB0aGUgZ3JvdXBzIG1lZXRpbmcgbGF0 ZXIgaW4gdGhlIHdlZWssIGFuZCBjYW4ndCBmaW5kIGFub3RoZXIgc2Vzc2lvbiB0aGF0IGlzIGxp a2VseSB0byBoYXZlIHRoZSBjb3JyZWN0IGNvbW11bml0eSBvZiBpbnRlcmVzdC4NCg0KSSd2ZSBh bHNvIGxvb2tlZCBvdmVyIHRoZSBjaGFuZ2VzIHRvIHRoZSBkb2N1bWVudCwgYW5kIHRoZXkgc2Vl bSBlbnRpcmVseSBlZGl0b3JpYWwgKGFsYmVpdCB3aXRoIGEgY2hhbmdlIHRoYXQgdGVjaG5pY2Fs bHkgZG9lcyBpbXBhY3QgdGhlIHdpcmUgcHJvdG9jb2wpLiBJdCdzIG5vdCBjbGVhciB0aGF0IHRo ZXJlIGFyZSBhbnkgcmVtYWluaW5nIG9wZW4gaXNzdWVzIHRoYXQgd291bGQgY2xlYXJseSBiZW5l Zml0IGZyb20gZmFjZS10by1mYWNlIHRpbWUuIEhlbm5pbmc6IGRvIHlvdSBoYXZlIHNvbWUgcXVl c3Rpb25zIHlvdSBzcGVjaWZpY2FsbHkgd2FudGVkIHRvIGFkZHJlc3MgaW4gdGhlIG1lZXRpbmc/ IE9yIGRpZCB5b3UganVzdCB3YW50IHRvIHByZXNlbnQgYSBsaXN0IG9mIGNoYW5nZXMgdG8gZ2l2 ZSBwZW9wbGUgYW4gb3Bwb3J0dW5pdHkgdG8gb2JqZWN0Pw0KDQpJZiB0aGUgbGF0dGVyLCBJIGJl bGlldmUgaXQgc2hvdWxkIGJlIHByZXR0eSBlYXN5IGZvciB0aGUgY2hhaXJzIHRvIHNheTogIldl J3ZlIHJlbmFtZWQgdGhlICdzcGFtJyBwYXJhbWV0ZXIgdG8gJ2NvbmZpZGVuY2UnLCBhbmQgbWFk ZSBzb21lIG90aGVyIG1pbm9yIGVkaXRvcmlhbCBpbXByb3ZlbWVudHMuIEludGVyZXN0ZWQgcGFy dGllcyBzaG91bGQgY29tbWVudCBvbiB0aGUgbGlzdCBpZiB0aGV5IG9iamVjdC4iIEl0J3MgdXAg dG8gdGhlIGNoYWlycyB3aGV0aGVyIHRoZXkgd2FudCB0byBjb3VwbGUgdGhpcyByZXF1ZXN0IHdp dGggYSBXR0xDLg0KDQovYQ0KRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNvbHVt YmlhLmVkdTxtYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdT4+DQpTdWJqZWN0OiBkcmFmdC1pZXRm LXNpcGNvcmUtY2FsbGluZm8tc3BhbS0wMi50eHQNCkRhdGU6IE9jdG9iZXIgMzAsIDIwMTcgYXQg MTE6MDg6MzYgUE0gRURUDQpUbzogc2lwY29yZS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnNpcGNv cmUtY2hhaXJzQGlldGYub3JnPiwgU3RpciBDaGFpcnMgPHN0aXItY2hhaXJzQHRvb2xzLmlldGYu b3JnPG1haWx0bzpzdGlyLWNoYWlyc0B0b29scy5pZXRmLm9yZz4+DQpSZXNlbnQtRnJvbTogPGFs aWFzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KUmVz ZW50LUZyb206IHdnLWFsaWFzLWJvdW5jZXNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOndnLWFsaWFz LWJvdW5jZXNAdG9vbHMuaWV0Zi5vcmc+DQpSZXNlbnQtVG86IGhvdXNsZXlAdmlnaWxzZWMuY29t PG1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbT4sIHJqc3BhcmtzQG5vc3RydW0uY29tPG1haWx0 bzpyanNwYXJrc0Bub3N0cnVtLmNvbT4NClJlc2VudC1Ubzogc3Rpci1jaGFpcnNAaWV0Zi5vcmc8 bWFpbHRvOnN0aXItY2hhaXJzQGlldGYub3JnPg0KDQpCcmlhbiAmIEplYW46DQoNCkkgc3VibWl0 dGVkIGRyYWZ0LWlldGYtc2lwY29yZS1jYWxsaW5mby1zcGFtLTAyLnR4dCwgd2hpY2ggYWRkcmVz c2VzDQpjb21tZW50cyBJIGhhdmUgcmVjZWl2ZWQuDQoNCkkgd2lsbCBiZSBpbiBTaW5nYXBvcmUs IGJ1dCBhbiBvYmxpZ2F0aW9uIHJlbGF0ZWQgdG8gYSBncmFudCBwcm9wb3NhbA0KbWFrZXMgbWUg YXJyaXZlIFdlZG5lc2RheSBtb3JuaW5nLiBJZiB0aGVyZSB3YXMgYSBuZWVkIHRvIGRpc2N1c3Mg dGhlDQpkcmFmdCwgSSBoYWQga2luZCBvZiBob3BlZCB0aGF0IHdlIGNvdWxkIG1vdmUgYW55IGRy YWZ0IGRpc2N1c3Npb24gdG8NClNUSVIsIHNpbmNlIHRoYXQgc2VlbWVkIHRvcGljYWxseSBjbG9z ZSBhbmQgc2luY2UgaXQgd2FzIG1lZXRpbmcgbGF0ZQ0KaW4gdGhlIHdlZWsgYXMgb2YgdGhlIHRp bWUgd2hlbiBJIGJvb2tlZCBteSBmbGlnaHQsIGJ1dCB0aGF0IG9wdGlvbiBpcw0KYXBwYXJlbnRs eSBnb25lLiAoSSBrbm93IHRoYXQgc2Vzc2lvbiBzY2hlZHVsaW5nIGlzIHRvdWdoIGdpdmVuIHRo ZQ0KdmFyaW91cyBjb25zdHJhaW50cywgc28gSSdtIG5vdCBjb21wbGFpbmluZy4pDQoNCkluIGFu eSBldmVudCwgSSdkIGxpa2UgdG8gZmlndXJlIG91dCBob3cgdG8gd3JhcCB1cCB0aGUgZHJhZnQg c2luY2UNCmRpc2N1c3Npb24gc2VlbXMgdG8gaGF2ZSBkaWVkIGRvd24uDQoNCkhlbm5pbmcNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUg bWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNpcGNvcmUgbWFpbGluZyBs aXN0IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K --_000_SN2PR03MB2350D75BAA1625AFB8B2EECCB25C0SN2PR03MB2350namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkhlbHZldGljYSBOZXVlIjt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgc2FtZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRvbGdhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+UmljaGFyZCBTaG9ja2V5PGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMSwgMjAxNyAxOjUxIFBNPGJyPg0K PGI+VG86PC9iPiBCcmlhbiBSb3NlbiAmbHQ7YnJAYnJpYW5yb3Nlbi5uZXQmZ3Q7OyBBZGFtIFJv YWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU0lQQ09SRSAmbHQ7 c2lwY29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBk cmFmdC1pZXRmLXNpcGNvcmUtY2FsbGluZm8tc3BhbS0wMi50eHQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RmluZSBidXQgdWx0aW1hdGVseSB1bm5lY2Vzc2FyeS4mbmJzcDsgSU1ITyB0aGlz IHNob3VsZCBnbyB0byBXR0xDIGFzIHNvb24gYXMgcG9zc2libGUuDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjEuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2NvbG9yOmJsYWNrIj7igJQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbEN4U3BNaWRkbGUiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6MS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEuMHB0 O21hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtjb2xvcjpibGFjayI+UmljaGFyZCBTaG9ja2V5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbEN4U3BNaWRkbGUiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6MS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjEuMHB0O21hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtjb2xvcjpibGFjayI+U2hvY2tleSBDb25zdWx0aW5nIExMQzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWxDeFNw TWlkZGxlIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjEuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbToxLjBwdDttYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6YmxhY2siPkNoYWlybWFuIG9mIHRo ZSBCb2FyZCBTSVAgRm9ydW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsQ3hTcE1pZGRsZSIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDox LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MS4wcHQ7bWFyZ2luLWxlZnQ6MGlu O21zby1hZGQtc3BhY2U6YXV0byI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2NvbG9y OmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LnNob2NrZXkudXMiPnd3dy5zaG9ja2V5LnVzPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWxDeFNwTWlkZGxlIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjEuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbToxLjBwdDttYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTph dXRvIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6YmxhY2siPjxhIGhyZWY9 Imh0dHA6Ly93d3cuc2lwZm9ydW0ub3JnIj53d3cuc2lwZm9ydW0ub3JnPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWxDeFNwTWlkZGxl IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjEuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbToxLjBwdDttYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6YmxhY2siPnJpY2hhcmQmbHQ7YXQmZ3Q7c2hv Y2tleS51czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWxDeFNwTWlkZGxlIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjEuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxLjBwdDttYXJnaW4tbGVmdDowaW47bXNvLWFkZC1z cGFjZTphdXRvIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6YmxhY2siPlNr eXBlLUxpbmtlZGluLUZhY2Vib29rIOKAk1R3aXR0ZXIgJm5ic3A7cnNob2NrZXkxMDE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsQ3hTcE1p ZGRsZSIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDoxLjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206MS4wcHQ7bWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2NvbG9yOmJsYWNrIj5QU1ROICYjNDM7MSA3MDMt NTkzLTI2ODM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5zaXBjb3JlICZsdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3Jn Ij5zaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQnJpYW4gUm9z ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+YnJAYnJpYW5yb3Nlbi5u ZXQ8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE5vdmVtYmVyIDEsIDIwMTcg YXQgMToyOSBQTTxicj4NCjxiPlRvOiA8L2I+QWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8 L2I+U0lQQ09SRSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NpcGNvcmVdIGRyYWZ0 LWlldGYtc2lwY29yZS1jYWxsaW5mby1zcGFtLTAyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgcG9zc2liaWxpdHkgaXMgZm9yIEhl bm5pbmcgdG8gZG8gYSByZW1vdGUgcHJlc2VudGF0aW9uIGluIHNpcGNvcmUuICZuYnNwO1RpbWUg em9uZSBjaGFsbGVuZ2VzIG9mIGNvdXJzZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAxLCAyMDE3LCBhdCAxMToy MSBBTSwgQWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFk YW1Abm9zdHJ1bS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBsb29r ZWQgb3ZlciB0aGUgZ3JvdXBzIG1lZXRpbmcgbGF0ZXIgaW4gdGhlIHdlZWssIGFuZCBjYW4ndCBm aW5kIGFub3RoZXIgc2Vzc2lvbiB0aGF0IGlzIGxpa2VseSB0byBoYXZlIHRoZSBjb3JyZWN0IGNv bW11bml0eSBvZiBpbnRlcmVzdC48YnI+DQo8YnI+DQpJJ3ZlIGFsc28gbG9va2VkIG92ZXIgdGhl IGNoYW5nZXMgdG8gdGhlIGRvY3VtZW50LCBhbmQgdGhleSBzZWVtIGVudGlyZWx5IGVkaXRvcmlh bCAoYWxiZWl0IHdpdGggYSBjaGFuZ2UgdGhhdCB0ZWNobmljYWxseSBkb2VzIGltcGFjdCB0aGUg d2lyZSBwcm90b2NvbCkuIEl0J3Mgbm90IGNsZWFyIHRoYXQgdGhlcmUgYXJlIGFueSByZW1haW5p bmcgb3BlbiBpc3N1ZXMgdGhhdCB3b3VsZCBjbGVhcmx5IGJlbmVmaXQgZnJvbSBmYWNlLXRvLWZh Y2UgdGltZS4NCiBIZW5uaW5nOiBkbyB5b3UgaGF2ZSBzb21lIHF1ZXN0aW9ucyB5b3Ugc3BlY2lm aWNhbGx5IHdhbnRlZCB0byBhZGRyZXNzIGluIHRoZSBtZWV0aW5nPyBPciBkaWQgeW91IGp1c3Qg d2FudCB0byBwcmVzZW50IGEgbGlzdCBvZiBjaGFuZ2VzIHRvIGdpdmUgcGVvcGxlIGFuIG9wcG9y dHVuaXR5IHRvIG9iamVjdD88YnI+DQo8YnI+DQpJZiB0aGUgbGF0dGVyLCBJIGJlbGlldmUgaXQg c2hvdWxkIGJlIHByZXR0eSBlYXN5IGZvciB0aGUgY2hhaXJzIHRvIHNheTogJnF1b3Q7V2UndmUg cmVuYW1lZCB0aGUgJ3NwYW0nIHBhcmFtZXRlciB0byAnY29uZmlkZW5jZScsIGFuZCBtYWRlIHNv bWUgb3RoZXIgbWlub3IgZWRpdG9yaWFsIGltcHJvdmVtZW50cy4gSW50ZXJlc3RlZCBwYXJ0aWVz IHNob3VsZCBjb21tZW50IG9uIHRoZSBsaXN0IGlmIHRoZXkgb2JqZWN0LiZxdW90OyBJdCdzIHVw IHRvIHRoZSBjaGFpcnMNCiB3aGV0aGVyIHRoZXkgd2FudCB0byBjb3VwbGUgdGhpcyByZXF1ZXN0 IHdpdGggYSBXR0xDLjxicj4NCjxicj4NCi9hPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPkhlbm5pbmcgU2NodWx6 cmlubmUgJmx0OzxhIGhyZWY9Im1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1Ij5oZ3NAY3MuY29s dW1iaWEuZWR1PC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDsiPlN1YmplY3Q6IGRyYWZ0LWlldGYtc2lwY29yZS1jYWxsaW5mby1z cGFtLTAyLnR4dDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDsiPkRhdGU6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5PY3RvYmVyIDMwLCAyMDE3IGF0IDExOjA4OjM2 IFBNIEVEVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1 ZSZxdW90OyI+VG86IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86c2lwY29yZS1jaGFpcnNAaWV0Zi5v cmciPnNpcGNvcmUtY2hhaXJzQGlldGYub3JnPC9hPiwgU3RpciBDaGFpcnMgJmx0OzxhIGhyZWY9 Im1haWx0bzpzdGlyLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+c3Rpci1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90OyI+UmVzZW50LUZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPiZsdDs8YSBocmVmPSJtYWlsdG86 YWxpYXMtYm91bmNlc0BpZXRmLm9yZyI+YWxpYXMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5S ZXNlbnQtRnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EgTmV1ZSZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOndnLWFsaWFzLWJvdW5jZXNAdG9v bHMuaWV0Zi5vcmciPndnLWFsaWFzLWJvdW5jZXNAdG9vbHMuaWV0Zi5vcmc8L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5SZXNlbnQt VG86IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbSI+aG91c2xl eUB2aWdpbHNlYy5jb208L2E+LA0KPGEgaHJlZj0ibWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29t Ij5yanNwYXJrc0Bub3N0cnVtLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPlJlc2VudC1UbzogPC9zcGFuPg0KPC9iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+PGEgaHJlZj0i bWFpbHRvOnN0aXItY2hhaXJzQGlldGYub3JnIj5zdGlyLWNoYWlyc0BpZXRmLm9yZzwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPkJyaWFuICZhbXA7IEplYW46PGJyPg0KPGJyPg0KSSBzdWJt aXR0ZWQgZHJhZnQtaWV0Zi1zaXBjb3JlLWNhbGxpbmZvLXNwYW0tMDIudHh0LCB3aGljaCBhZGRy ZXNzZXM8YnI+DQpjb21tZW50cyBJIGhhdmUgcmVjZWl2ZWQuPGJyPg0KPGJyPg0KSSB3aWxsIGJl IGluIFNpbmdhcG9yZSwgYnV0IGFuIG9ibGlnYXRpb24gcmVsYXRlZCB0byBhIGdyYW50IHByb3Bv c2FsPGJyPg0KbWFrZXMgbWUgYXJyaXZlIFdlZG5lc2RheSBtb3JuaW5nLiBJZiB0aGVyZSB3YXMg YSBuZWVkIHRvIGRpc2N1c3MgdGhlPGJyPg0KZHJhZnQsIEkgaGFkIGtpbmQgb2YgaG9wZWQgdGhh dCB3ZSBjb3VsZCBtb3ZlIGFueSBkcmFmdCBkaXNjdXNzaW9uIHRvPGJyPg0KU1RJUiwgc2luY2Ug dGhhdCBzZWVtZWQgdG9waWNhbGx5IGNsb3NlIGFuZCBzaW5jZSBpdCB3YXMgbWVldGluZyBsYXRl PGJyPg0KaW4gdGhlIHdlZWsgYXMgb2YgdGhlIHRpbWUgd2hlbiBJIGJvb2tlZCBteSBmbGlnaHQs IGJ1dCB0aGF0IG9wdGlvbiBpczxicj4NCmFwcGFyZW50bHkgZ29uZS4gKEkga25vdyB0aGF0IHNl c3Npb24gc2NoZWR1bGluZyBpcyB0b3VnaCBnaXZlbiB0aGU8YnI+DQp2YXJpb3VzIGNvbnN0cmFp bnRzLCBzbyBJJ20gbm90IGNvbXBsYWluaW5nLik8YnI+DQo8YnI+DQpJbiBhbnkgZXZlbnQsIEkn ZCBsaWtlIHRvIGZpZ3VyZSBvdXQgaG93IHRvIHdyYXAgdXAgdGhlIGRyYWZ0IHNpbmNlPGJyPg0K ZGlzY3Vzc2lvbiBzZWVtcyB0byBoYXZlIGRpZWQgZG93bi48YnI+DQo8YnI+DQpIZW5uaW5nPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzaXBjb3Jl IG1haWxpbmcgbGlzdA0KPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVA aWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZSI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmU8L2E+IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN2PR03MB2350D75BAA1625AFB8B2EECCB25C0SN2PR03MB2350namp_-- From nobody Thu Nov 2 10:06: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 8564113F79E for ; Thu, 2 Nov 2017 10:06:51 -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 R9tTCCk5_CNr for ; Thu, 2 Nov 2017 10:06:50 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 3C34E13F77F for ; Thu, 2 Nov 2017 10:06:50 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id p87so149754pfj.3 for ; Thu, 02 Nov 2017 10:06:50 -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=Z0SZ7Z0iLu7yd57l7Ip4qKw2OL1jD2MqG18qUtYds1I=; b=EFVy84Z7hu5e6pofvIPfmOLo9tEkYAi7pZr2K0dzkYUMurmJfcAvTxFe7zkSrLu9jQ wdcMbgnbDTO7rcvc4goQRWkUcc/NZ+mVUvuDc0Jpx/mYluktG46ZwdhDT0+7U56+dtJv G5jIDpLafmhroIGvkRuaG3T7fZ4V+dA7Gvd4Mnvv6Fthw90F7yfpPRCgsx1BxsaYq3kf lkJHt5Sdv5yBxQhW9BNMfp69gIA6UwFYpVHpYpta7vvm5nJNnDKVPYkqxkJnmy9vO6n9 50ObjRvxWDQ9mJN1UJVWlerkDaMVyIY9pw/pecP2XhEXICyiASG9Z9H4hDASTo2/faOC P65Q== 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=Z0SZ7Z0iLu7yd57l7Ip4qKw2OL1jD2MqG18qUtYds1I=; b=fSoe9NaW4PPvwvQxo4gFnlQLj4Kn1Ywc1u8L6R3/YY5KjG0Sk2M2sWCGtstww3j9kD ubdJA3NUy3k763U0t4Tb7dHcoemJcFrYhfmrPrPUXHbmO3MEPLJHdPkIjrMgM/tCn96C rhqzbcNJIpjV7kgXoMNGMQ+RZQv2qHGK6pI7YsqmAFLLB75U22aZkOdTddehub6ibNyd B2mYlITIVSJ4jg8nK57LKDMJPTJFw1gaoCCnkwox2HFcEcJJOdVFPMGKS7vZEYLhSecQ z7K11G/nKYjSDgwvkCgsKeOibWK9OwPokC5imr6bc0dcCqzdwuCoIGcU4kk4qmmNRK6h 9LyQ== X-Gm-Message-State: AMCzsaVF2BHDNHnWXj/j7W8jldf/gmcqTZJ0CLaqvvyUa/6S0VVlQcS5 ogjz9KaFZjZjJQ5gKegexBHGjxC7 X-Google-Smtp-Source: ABhQp+RiP1WNEp+uJ0nR0twopvVo2ncdhvs8PbroCrLBTHTXFlwrB5WMHxkPnNC2CXvCtozHCZqWyQ== X-Received: by 10.99.122.28 with SMTP id v28mr4161087pgc.394.1509642409652; Thu, 02 Nov 2017 10:06:49 -0700 (PDT) Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com. [209.85.192.169]) by smtp.gmail.com with ESMTPSA id e18sm6147167pfi.57.2017.11.02.10.06.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 10:06:44 -0700 (PDT) Received: by mail-pf0-f169.google.com with SMTP id z11so145330pfk.4 for ; Thu, 02 Nov 2017 10:06:44 -0700 (PDT) X-Received: by 10.99.126.78 with SMTP id o14mr4290479pgn.159.1509642403834; Thu, 02 Nov 2017 10:06:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.131 with HTTP; Thu, 2 Nov 2017 10:06:42 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> From: Roman Shpount Date: Thu, 2 Nov 2017 13:06:42 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Jesske, Roland" Cc: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="f403045e3a5637f172055d03037e" 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, 02 Nov 2017 17:06:51 -0000 --f403045e3a5637f172055d03037e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I might be missing something, but Session Timer is switched of by the last success response to INVITE or UPDATE. Presence of Session-Expires in the offer is irrelevant, so this table is wrong. Also, Session Timer is primarily intended to be inserted by proxies. Its main use case is to allow proxies to detect abandoned calls and expire any state associated with these calls. User Agents do not really need Session Timer, since they can detect abandoned calls by initiating Invite or Update transactions on their own without negotiating anything. Regards, _____________ Roman Shpount On Thu, Nov 2, 2017 at 2:59 AM, Jesske, Roland wrote: > Hi, > > I agree on Christer=E2=80=99s comment. > > But nevertheless I would be happy to see a clear advice for the refresh > mechanism when the S-E timer is switched off. > > Perhaps an table and some text in section 7.4 for the refresh mechanism > would help e.g.: > > > > This is valid for UPDATE and INVITE refreshing a session where S-E is > negotiated and the supported header with timer is set. > > > > > > UAC supports? SE parameter S-E parameter S-E > > in request in response switched off > > ---------------------------------------------------------- > > Y Y N Y > > Y N Y N > > Y N N Y > > > > Figure X Switch off S-E > > > > When the when required timer set the S-E cannot be switched off. > > > > What do you think? > > Of course we could do the same for the initial negotiation to make > everything clear. > > > > Best Regards > > > > Roland > > > > > > *Von:* Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Gesendet:* Dienstag, 31. Oktober 2017 19:44 > *An:* Roman Shpount > *Cc:* Paul Kyzivat ; Jesske, Roland < > R.Jesske@telekom.de>; sipcore@ietf.org > *Betreff:* RE: [sipcore] Session timer fix > > > > Hi, > > > > I may reply to Roman=E2=80=99s comments later. > > > > But, at the end of the day I think what Paul said is what matters most: > the procedures for turning session timer etc applies AFTER the session > timer has been fully negotiated. > > > > So, if the session timer is negotiated during the initial INVITE > transaction, whatever UPDATEs are sent during that transaction will not > contain session timer information, and they will have no impact on the > session timer. > > > > But, once the session timer has been negotiated (once the UAC has receive= d > the 200 OK, the rules regarding turning the session timer off etc applies= . > > > > Regards, > > > > Christer > > > > > > *From:* Roman Shpount [mailto:roman@telurix.com ] > *Sent:* 31 October 2017 20:21 > *To:* Christer Holmberg > *Cc:* Paul Kyzivat ; Jesske, Roland < > R.Jesske@telekom.de>; sipcore@ietf.org > *Subject:* Re: [sipcore] Session timer fix > > > > > > 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 inserte= d > 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 > > > --f403045e3a5637f172055d03037e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I might be missing something, but Session Timer is switche= d of by the last success response to INVITE or UPDATE. Presence of Session-= Expires in the offer is irrelevant, so this table is wrong.

<= div>Also, Session Timer is primarily intended to be inserted by proxies. It= s main use case is to allow proxies to detect abandoned calls and expire an= y state associated with these calls. User Agents do not really need Session= Timer, since they can detect abandoned calls by initiating Invite or Updat= e transactions on their own without negotiating anything.

Regards,

______= _______
Roman Shpount

On Thu, Nov 2, 2017 at 2:59 AM, Jesske, Rola= nd <R.Jesske@telekom.de> wrote:

Hi,

I agree on Christer=E2=80=99s commen= t.

But nevertheless I would be happy to= see a clear advice for the refresh mechanism when the S-E timer is switche= d off.

Perhaps an table and some text in se= ction 7.4 for the refresh mechanism would help e.g.:

=C2=A0

This is valid for UPDATE and INVITE refreshing= a session where S-E is negotiated and the supported header with timer is s= et.

=C2=A0

=C2=A0

UAC support= s?=C2=A0=C2=A0=C2=A0 SE parameter=C2=A0=C2=A0=C2=A0 S-E parameter=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0S-E

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0in request=C2=A0=C2=A0=C2=A0=C2=A0 = in response=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0switched off

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

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Y=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Y=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Y=

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Y=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 N=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Y=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N=

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Y=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 N=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Y=

=C2= =A0

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Figure X Switch off = S-E

=C2= =A0

When the= when required timer set the S-E cannot be switched off.

=C2=A0

What do you think?

Of course we could do the same for t= he initial negotiation to make everything clear.

=C2=A0

Best Regards

=C2=A0

Roland

=C2=A0

=C2=A0

Von: Christe= r Holmberg [mailto:christer.holmberg@ericsson.com]
Gesendet: Dienstag, 31. Oktober 2017 19:44
An: Roman Shpount <roman@telurix.com>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; Jesske, Roland <R.Jesske@telekom.de>; sipcore@ietf.org Betreff: RE: [sipcore] Session timer fix=

=C2=A0

Hi,

=C2=A0

I may reply to Roman= =E2=80=99s comments later.

=C2=A0

But, at the end of the= day I think what Paul said is what matters most: the procedures for turnin= g session timer etc applies AFTER the session timer has been fully negotiated.

=C2=A0

So, if the session tim= er is negotiated during the initial INVITE transaction, whatever UPDATEs ar= e sent during that transaction will not contain session timer information, and they will have no impact o= n the session timer.

=C2=A0

But, once the session = timer has been negotiated (once the UAC has received the 200 OK, the rules regarding turning the session timer off etc applies.

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

=C2=A0

From: = Roman Shpount [mailto:roman@telurix.com]
Sent: 31 October 2017 20:21
To: Christer Holmberg <christer.holmberg@ericsson= .com>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; Jesske, Roland <R.Jesske@telekom.de>= ; sipcore@ietf.org
Subject: Re: [sipcore] Session timer fix

=C2=A0

=C2=A0

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.=

=C2=A0

This will break pretty much eve= ry 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.

=C2=A0

I think it would be much better= to have a new header which will specify "do not update Session-Timer&= quot; in the offer.

This way if proxies insert Sess= ion-Timer, new header will overwrite.=C2=A0

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0


--f403045e3a5637f172055d03037e-- From nobody Thu Nov 2 10:17: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 E52E913F503 for ; Thu, 2 Nov 2017 10:17:01 -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 W7muA37smhYZ for ; Thu, 2 Nov 2017 10:17:00 -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 ECDED13F743 for ; Thu, 2 Nov 2017 10:16:59 -0700 (PDT) X-AuditID: c1b4fb3a-de7ff70000006897-af-59fb5309efd9 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6D.47.26775.9035BF95; Thu, 2 Nov 2017 18:16:57 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Thu, 2 Nov 2017 18:16:57 +0100 From: Christer Holmberg To: Roman Shpount , "Jesske, Roland" CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAJP54CAAKmvAIAAEycw Date: Thu, 2 Nov 2017 17:16:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C686C88@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdUZcz+Hekwfc2I4sVGw6wWjTd6WKz mHFhKrPF1x+b2BxYPP6+/8DksWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBlTN2+iL3g jlpFy/tPLA2Md1S7GDk4JARMJCb0xHQxcnEICRxmlHg/cyJjFyMnkLOIUeLpYWWQGjYBC4nu f9ogpoiAr8Tc+5ogJrNAoMS9VnGQYmEBDYnPcy8zg9giApoSF08tY4Kw3ST+H74HZrMIqEjs /HaMBcTmBZrSN3k3K8TWmSwSe648AEtwAs2c0HSQHcRmFBCT+H5qDVgzs4C4xK0n88FsCQEB iSV7zjND2KISLx//Y4WwlSQalzxhhbhNU2L9Ln2IVkWJKd0P2SH2CkqcnPmEZQKj6CwkU2ch dMxC0jELSccCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIERdHDLb6sdjAefOx5iFOBg VOLh7RX5HSnEmlhWXJl7iFGCg1lJhDfKFSjEm5JYWZValB9fVJqTWnyIUZqDRUmc12HfhQgh gfTEktTs1NSC1CKYLBMHp1QDo3laJu/VGy23oyuvb3p6y98tJ9eh3OWc1tpH5dtfapl7l03S F14RGfx/pZf43sh/pp2bWT9P3MZ69vaXZao8n1+9DVM/G/PcPmOXyF3f2iqdlMdnI79dOlwT v3365bPRUTxCTDJOZy0lpp01PtCVf/CeLbOHVCnDJ/vup4qNvTx8Hy5dnXD2rRJLcUaioRZz UXEiAJTB1pucAgAA 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, 02 Nov 2017 17:17:02 -0000 SGksDQoNCj4gSSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IFNlc3Npb24gVGltZXIg aXMgc3dpdGNoZWQgb2YgYnkgdGhlIGxhc3Qgc3VjY2VzcyByZXNwb25zZSB0byANCj4gSU5WSVRF IG9yIFVQREFURS4gUHJlc2VuY2Ugb2YgU2Vzc2lvbi1FeHBpcmVzIGluIHRoZSBvZmZlciBpcyBp cnJlbGV2YW50LCBzbyB0aGlzIHRhYmxlIGlzIHdyb25nLg0KDQpJIGRvbid0IHRoaW5rIHdlIHNo b3VsZCB0YWxrIGFib3V0IG9mZmVycyBhbmQgYW5zd2VycywgYnV0IHJlcXVlc3RzIGFuZCByZXNw b25zZXMuIFRoaXMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBvZmZlci9hbnN3ZXIgOikNCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KT24gVGh1LCBOb3YgMiwgMjAxNyBhdCAyOjU5IEFN LCBKZXNza2UsIFJvbGFuZCA8Ui5KZXNza2VAdGVsZWtvbS5kZT4gd3JvdGU6DQpIaSwNCkkgYWdy ZWUgb24gQ2hyaXN0ZXLigJlzIGNvbW1lbnQuDQpCdXQgbmV2ZXJ0aGVsZXNzIEkgd291bGQgYmUg aGFwcHkgdG8gc2VlIGEgY2xlYXIgYWR2aWNlIGZvciB0aGUgcmVmcmVzaCBtZWNoYW5pc20gd2hl biB0aGUgUy1FIHRpbWVyIGlzIHN3aXRjaGVkIG9mZi4NClBlcmhhcHMgYW4gdGFibGUgYW5kIHNv bWUgdGV4dCBpbiBzZWN0aW9uIDcuNCBmb3IgdGhlIHJlZnJlc2ggbWVjaGFuaXNtIHdvdWxkIGhl bHAgZS5nLjoNCsKgDQpUaGlzIGlzIHZhbGlkIGZvciBVUERBVEUgYW5kIElOVklURSByZWZyZXNo aW5nIGEgc2Vzc2lvbiB3aGVyZSBTLUUgaXMgbmVnb3RpYXRlZCBhbmQgdGhlIHN1cHBvcnRlZCBo ZWFkZXIgd2l0aCB0aW1lciBpcyBzZXQuDQrCoA0KwqANClVBQyBzdXBwb3J0cz/CoMKgwqAgU0Ug cGFyYW1ldGVywqDCoMKgIFMtRSBwYXJhbWV0ZXLCoMKgwqDCoCDCoMKgwqBTLUUgDQrCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBpbiByZXF1ZXN0wqDCoMKgwqAgaW4gcmVzcG9u c2XCoCDCoMKgwqDCoHN3aXRjaGVkIG9mZg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KwqDCoMKgwqDCoCBZwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgWcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBOwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIFkNCsKgwqDCoMKgwqAgWcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIE7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgWcKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBODQrCoMKgwqDCoMKgIFnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBOwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIE7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgWQ0KwqANCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg RmlndXJlIFggU3dpdGNoIG9mZiBTLUUNCsKgDQpXaGVuIHRoZSB3aGVuIHJlcXVpcmVkIHRpbWVy IHNldCB0aGUgUy1FIGNhbm5vdCBiZSBzd2l0Y2hlZCBvZmYuDQrCoA0KV2hhdCBkbyB5b3UgdGhp bms/DQpPZiBjb3Vyc2Ugd2UgY291bGQgZG8gdGhlIHNhbWUgZm9yIHRoZSBpbml0aWFsIG5lZ290 aWF0aW9uIHRvIG1ha2UgZXZlcnl0aGluZyBjbGVhci4NCsKgDQpCZXN0IFJlZ2FyZHMNCsKgDQpS b2xhbmQNCsKgDQrCoA0KVm9uOiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbV0gDQpHZXNlbmRldDogRGllbnN0YWcsIDMxLiBPa3RvYmVyIDIw MTcgMTk6NDQNCkFuOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiBQYXVs IEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IEplc3NrZSwgUm9sYW5kIDxSLkplc3Nr ZUB0ZWxla29tLmRlPjsgc2lwY29yZUBpZXRmLm9yZw0KQmV0cmVmZjogUkU6IFtzaXBjb3JlXSBT ZXNzaW9uIHRpbWVyIGZpeA0KwqANCkhpLA0KwqANCkkgbWF5IHJlcGx5IHRvIFJvbWFu4oCZcyBj b21tZW50cyBsYXRlci4NCsKgDQpCdXQsIGF0IHRoZSBlbmQgb2YgdGhlIGRheSBJIHRoaW5rIHdo YXQgUGF1bCBzYWlkIGlzIHdoYXQgbWF0dGVycyBtb3N0OiB0aGUgcHJvY2VkdXJlcyBmb3IgdHVy bmluZyBzZXNzaW9uIHRpbWVyIGV0YyBhcHBsaWVzIEFGVEVSIHRoZSBzZXNzaW9uIHRpbWVyIGhh cyBiZWVuIGZ1bGx5IG5lZ290aWF0ZWQuDQrCoA0KU28sIGlmIHRoZSBzZXNzaW9uIHRpbWVyIGlz IG5lZ290aWF0ZWQgZHVyaW5nIHRoZSBpbml0aWFsIElOVklURSB0cmFuc2FjdGlvbiwgd2hhdGV2 ZXIgVVBEQVRFcyBhcmUgc2VudCBkdXJpbmcgdGhhdCB0cmFuc2FjdGlvbiB3aWxsIG5vdCBjb250 YWluIHNlc3Npb24gdGltZXIgaW5mb3JtYXRpb24sIGFuZCB0aGV5IHdpbGwgaGF2ZSBubyBpbXBh Y3Qgb24gdGhlIHNlc3Npb24gdGltZXIuDQrCoA0KQnV0LCBvbmNlIHRoZSBzZXNzaW9uIHRpbWVy IGhhcyBiZWVuIG5lZ290aWF0ZWQgKG9uY2UgdGhlIFVBQyBoYXMgcmVjZWl2ZWQgdGhlIDIwMCBP SywgdGhlIHJ1bGVzIHJlZ2FyZGluZyB0dXJuaW5nIHRoZSBzZXNzaW9uIHRpbWVyIG9mZiBldGMg YXBwbGllcy4NCsKgDQpSZWdhcmRzLA0KwqANCkNocmlzdGVyDQrCoA0KwqANCkZyb206IFJvbWFu IFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0gDQpTZW50OiAzMSBPY3RvYmVyIDIw MTcgMjA6MjENClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPg0KQ2M6IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgSmVzc2tl LCBSb2xhbmQgPFIuSmVzc2tlQHRlbGVrb20uZGU+OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIFNlc3Npb24gdGltZXIgZml4DQrCoA0KwqANCk9uIFR1ZSwgT2N0IDMx LCAyMDE3IGF0IDQ6MzUgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+IHdyb3RlOg0KTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IG5vLVNFLWluLXJlc3Bv bnNlIHdvdWxkIHN3aXRjaCBvZmYgaWYgU0Ugd2FzIGluIHRoZQ0KcmVxdWVzdC4NCg0KU28sIGlm IHRoZXJlIGlzIG5vIFNFIGluIHRoZSByZXF1ZXN0LCB0aGVyZSBpcyBubyBzd2l0Y2ggb2ZmLg0K wqANClRoaXMgd2lsbCBicmVhayBwcmV0dHkgbXVjaCBldmVyeSBTRSBpbXBsZW1lbnRhdGlvbi4g VGhlcmUgYXJlIG51bWJlciBvZiBpbXBsZW1lbnRhdGlvbnMgd2hlcmUgVUEgZG9lcyBub3QgaW5z ZXJ0IFNFIGluIHRoZSByZXF1ZXN0LiBJdCBpcyBpbnNlcnRlZCBlaXRoZXIgYnkgcHJveGllcyAo YWN0dWFsbHkgdGhpcyBpcyB0aGUgbW9zdCBjb21tb24gdXNlIGNhc2UpIG9yIGJ5IHRoZSBhbnN3 ZXJpbmcgYWdlbnQuDQrCoA0KSSB0aGluayBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBoYXZl IGEgbmV3IGhlYWRlciB3aGljaCB3aWxsIHNwZWNpZnkgImRvIG5vdCB1cGRhdGUgU2Vzc2lvbi1U aW1lciIgaW4gdGhlIG9mZmVyLg0KVGhpcyB3YXkgaWYgcHJveGllcyBpbnNlcnQgU2Vzc2lvbi1U aW1lciwgbmV3IGhlYWRlciB3aWxsIG92ZXJ3cml0ZS7CoA0KwqANClJlZ2FyZHMsDQpfX19fX19f X19fX19fDQpSb21hbiBTaHBvdW50DQrCoA0KDQo= From nobody Thu Nov 2 10:53: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 A15C61394E4 for ; Thu, 2 Nov 2017 10:53:44 -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 U4ULqGuz4Hew for ; Thu, 2 Nov 2017 10:53:34 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 02FD813F742 for ; Thu, 2 Nov 2017 10:53:34 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id b79so235357pfk.5 for ; Thu, 02 Nov 2017 10:53:33 -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=5qbjvg1I9HQdFwcR/vLeMBGLTEV1pp6EtvJh3Qa89Bg=; b=PhIzmf7KLBkywX+5VPqaY9IJ1OT+21+dosd3ojpUd5NYgx2xpwF2foxWwXO4ydWRg5 Ut2NWKjQNtUv9w/JhpA8+B4+KDSn93iKoPl47P75BDb1umw5MZz4zDsZgv5wOaUXWTMs ilVEfdwtzIkSS5xAUuD+8mnyOWlfWXHzu/3oJAQCoQEinPgjeGbRS0aQP/A69yXr6lPF 0iu/abZsmV8nsGnOBPOr8bc5k6uLDT9GEzB8cxwX5K3HGXgStfbGDM8BoHAdw0PSBId/ iLiGRwrQNU9luBaYJwMT1wBIXBlYYz4Gnk/p3ClODf9XvceR5Wh/jOy6Yg1xYm2i/I+a m5hA== 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=5qbjvg1I9HQdFwcR/vLeMBGLTEV1pp6EtvJh3Qa89Bg=; b=cLP/Q4cm3ocXmdLM0rUTxQlB3rA7bHwo4Ib44o4im9arXSqU4xtJrBGDklOV2xr955 AKSppHUcd7maklC1w4GhDvREMG7efWS/NOP2qidSs9Tjy0Jgca6JIT1tLg951KxF8NB9 di//54z5b8UNCoiawScqiSK3rSRxiDJ4Y8RaRbmu7Wnv3n/H5pBCwT7LaLRxis52bkyc Xb79KNUYciqFrZz2nZ3X+v4nRAv+su5x0bM+0eboSz1emuYmW8JaxXPsNwn+i4HNsrmG W1Zsbbqg6p8Fck/UpoGRcxE4ETThFuNBXIXBhzC+PyINL0T8Y1CQjY4BedCzEFD/hOGm uEFg== X-Gm-Message-State: AMCzsaXWTaCTAuLndb8yXRMOX3rBovqwbIcDkA8SCnyYNNkY2TXX4w2v nkh1WD/9m463zmogch+mY0793ttd X-Google-Smtp-Source: ABhQp+TspWgyuNilyERrvDYzu074uaVS1votc1g6PepHa8k/tMDs4ow8TTInV+nYc0EGDxUeYXaEGQ== X-Received: by 10.159.206.193 with SMTP id x1mr4131528plo.319.1509645213365; Thu, 02 Nov 2017 10:53:33 -0700 (PDT) Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com. [209.85.192.179]) by smtp.gmail.com with ESMTPSA id g16sm6330249pgn.43.2017.11.02.10.53.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 10:53:25 -0700 (PDT) Received: by mail-pf0-f179.google.com with SMTP id z11so235085pfk.4 for ; Thu, 02 Nov 2017 10:53:25 -0700 (PDT) X-Received: by 10.98.102.132 with SMTP id s4mr4716420pfj.168.1509645205367; Thu, 02 Nov 2017 10:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.131 with HTTP; Thu, 2 Nov 2017 10:53:24 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C686C88@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B5C686C88@ESESSMB109.ericsson.se> From: Roman Shpount Date: Thu, 2 Nov 2017 13:53:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "Jesske, Roland" , Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="001a11412ae233fe83055d03aad8" 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, 02 Nov 2017 17:53:45 -0000 --001a11412ae233fe83055d03aad8 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 2, 2017 at 1:16 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > I might be missing something, but Session Timer is switched of by the > last success response to > > INVITE or UPDATE. Presence of Session-Expires in the offer is > irrelevant, so this table is wrong. > > I don't think we should talk about offers and answers, but requests and > responses. This has nothing to do with offer/answer :) > Agreed. I meant to say presence of Session-Expires in the *request* is irrelevant. Presence of Session-Expires in the success response to INVITE or UPDATE modifies the Session Timer status. The problem you are trying to solve requires some sort of indication to the UAS that even if S-E is inserted in the request by some proxy on the path, it should be ignored, since there is an INVITE transaction is progress which should negotiate the Session Timer. Regards, _____________ Roman Shpount --001a11412ae233fe83055d03aad8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 2, 2017 at 1:16 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
> I might be missing something, but Session Timer is swit= ched of by the last success response to
> INVITE or UPDATE. Presence of Session-Expires in the offer is irreleva= nt, so this table is wrong.

I don't think we should talk about offers and answers, but reque= sts and responses. This has nothing to do with offer/answer :)

Agreed.=C2=A0 I meant to say presence of Session-Ex= pires in the *request* is irrelevant. Presence of Session-Expires in the su= ccess response to INVITE or UPDATE modifies the Session Timer status.
=

The problem you are trying to solve requires some sort = of indication to the UAS that even if S-E is inserted in the request by som= e proxy on the path, it should be ignored, since there is an INVITE transac= tion is progress which should negotiate the Session Timer.

Regards,
_____________Roman Shpount
=C2=A0
--001a11412ae233fe83055d03aad8-- From nobody Thu Nov 2 10:56:38 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 CEE1E13F742 for ; Thu, 2 Nov 2017 10:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 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, SUBJ_ALL_CAPS=1.506] autolearn=no 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 mfg4vNdWeBS5 for ; Thu, 2 Nov 2017 10:56:36 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 E91CA1394E4 for ; Thu, 2 Nov 2017 10:56:35 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id d9so417654qtd.7 for ; Thu, 02 Nov 2017 10:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1ewocBvXPusPSeSTqI+OQmPtQLBzik8QIJXaGNWqs88=; b=hja2QgN/sBqFbz6P1yjbLWRN+R8njaL4yu/5OnU897gKIYXUw70gtfdNROGqrpnf4x r9/pKMqz37OWiTCZZCXIH/28LAFugebSjkqcqKgR1RQDYGf6a0mej1p+keA9/LNhKEOM QF4T6RxG0YTjl3Fq12ulI0lgEtmHJenX2P4sBfsvPH7Tbgv6j+QdzqfL6J+B5A0mExuz l+X5rUDrUjhNj9TgBFNocX6yC/00T7NYm731BmkZ7gMIYXMAPrFXMgTmXGgUJbamS5sK 14e4dPepXQ3U+T8HGFVr/XiJ6IJ56EEBdk8y2MD225ul8Oo/9rOjR7gPrTInfU5oD5JE VPWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1ewocBvXPusPSeSTqI+OQmPtQLBzik8QIJXaGNWqs88=; b=DfM01oQEg3lQOFgO0cXwlqnedRbaRMZ9fFGJms9ra2HCr8XzNh+dhOpfkm6y+0hA+V smxUT01iROdBraQRFBuvUJLBDrZ2+Cy9hQQ+kNlps4BhyUevn7kyYTSoEpUkj9KWd+a9 5fozx6V96bk+9om2FIrXd6cXtIVP5AxtYwDetb0k97YDqTBvoe92QkvDmll6NDQ8YE6G bYNK1YDPASZl8S+FMnw0XAkKM3KPDzQnDiXVWNqLNfiyxVHxG0ufcIAubH+MJVfsUk97 xSlJjqdDfKgbs5hvPftqjRmhsaRbySS1emydosfTWRCeGXGxafL4iZX2MJKzikj9R0me 0LNw== X-Gm-Message-State: AMCzsaXZfDpaLaGvYyqQqxgB+iOx6PKdmzevUMyldHkf5tdagby8mpA/ CdyDpz2IGGOOpKBJnFxuLgs0XqFb+c66bRaMYU9g4w== X-Google-Smtp-Source: ABhQp+QrI8IQFeNHCKx4x49kZ9lbANnDtECvZG3ptyl/aGztx/k8EuI5kdv7xPpWADHvcExLcnfkbPQvcdrWQkVUOBA= X-Received: by 10.200.26.90 with SMTP id q26mr6645314qtk.109.1509645394721; Thu, 02 Nov 2017 10:56:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.36.163 with HTTP; Thu, 2 Nov 2017 10:56:34 -0700 (PDT) From: Mary Barnes Date: Thu, 2 Nov 2017 13:56:34 -0400 Message-ID: To: SIPCORE Content-Type: multipart/alternative; boundary="94eb2c126ffe7d3fc4055d03b587" Archived-At: Subject: [sipcore] SIPNOC 2017 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, 02 Nov 2017 17:56:38 -0000 --94eb2c126ffe7d3fc4055d03b587 Content-Type: text/plain; charset="UTF-8" Hi folks, I know a lot of you all might have gotten the notices on the various SIP Forum mailing list, but I just wanted to remind folks that registration is open: https://www.sipforum.org/news-events/sipnoc-2017-overview/ The first day will be full day training in Wireshark - there's always new tricks to learn. Here's the preliminary agenda: https://www.sipforum.org/news-events/sipnoc-2017-overview/sipnoc-2017-conference-schedule/ The conference is very much focused on technical issues and experiences of SIP service providers (as presented by SPs and vendors). The program committee is quite strict about product pitches. The only person that might be in a suit would be Dr. Eric Burger, the new CTO of the FCC who is the keynote speaker. Regards, Mary. --94eb2c126ffe7d3fc4055d03b587 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I know a lot of you all might= have gotten the notices on the various SIP Forum mailing list, but I just = wanted to remind folks that registration is open:

The fi= rst day will be full day training in Wireshark - there's always new tri= cks to learn. Here's the preliminary agenda:=C2=A0

The conf= erence is very much focused on technical issues and experiences of SIP serv= ice providers (as presented by SPs and vendors).=C2=A0The program committee= is quite strict about=C2=A0 product pitches.=C2=A0 =C2=A0The only person t= hat might be in a suit would be Dr. Eric Burger, the new CTO of the FCC who= is the keynote speaker.

Regards,
Mary.= =C2=A0



--94eb2c126ffe7d3fc4055d03b587-- From nobody Thu Nov 2 13:39: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 7450113F5B7 for ; Thu, 2 Nov 2017 13:39:45 -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 KVAD-k0cqd_p for ; Thu, 2 Nov 2017 13:39:43 -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 B0326134916 for ; Thu, 2 Nov 2017 13:39:43 -0700 (PDT) X-AuditID: 12074414-0d3ff70000006ddf-98-59fb828eb357 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 7B.46.28127.E828BF95; Thu, 2 Nov 2017 16:39:42 -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 vA2KdeWU010405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Nov 2017 16:39:41 -0400 To: "Jesske, Roland" , Christer Holmberg , Roman Shpount Cc: "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <8c493c15-1a38-39e7-e790-b2aa1243ac51@alum.mit.edu> Date: Thu, 2 Nov 2017 16:39:40 -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+NgFprLKsWRmVeSWpSXmKPExsUixO6iqNvX9DvSYFWrrsWFmYcZLZrudLFZ zLgwldni649NbA4sHr++XmXzWLLkJ5NH20sFj1tTCgJYorhsUlJzMstSi/TtErgy9q3vZClY JVsxd9VRpgbGE+JdjBwcEgImEmsfl3QxcnEICexgknjSe5wRwnnAJPF60gIgh5NDWEBHYufX 4ywgtojAZEaJA7cqQGxmAU2JzesusEM0XGKW2LDyLTNIgk1AS2LOof9gDbwC9hJTvk4Ci7MI qEjc/XwHLC4qkCZxZ8ZDJogaQYmTM5+AxTkFYiTm9f9ihFhgJjFv80NmCFtc4taT+UwQtrxE 89bZzBMYBWYhaZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3WLU5OzMtLLdK10MvNLNFL TSndxAgJc5EdjEdOyh1iFOBgVOLhPaD+K1KINbGsuDL3EKMkB5OSKO/djUAhvqT8lMqMxOKM +KLSnNTiQ4wSHMxKIryPY35HCvGmJFZWpRblw6SkOViUxHm/LVb3ExJITyxJzU5NLUgtgsnK cHAoSfBWNQI1ChalpqdWpGXmlCCkmTg4QYbzAA3vBqnhLS5IzC3OTIfIn2I05ujpufGHiePZ zNcNzEIsefl5qVLivNEgpQIgpRmleXDTYKnqFaM40HPCvLtBqniAaQ5u3iugVUxAq7wkfoCs KklESEk1MMZv8LgnGpT5yCooJoF3QqO2+QG7ItMZf0x6zY6+5egSLt25LHTTDMWnUwNvbPP/ neiaxfva4O35Z3WSj/+u2Z2dw3ZupbnMRMl7PfEzXvsqv2OdVNFlyFFZoqs7fz/HPcMfMuzK lhs099pph2blqbbrM0aJfd6WdXveqwv/JtTphMVznXXfqsRSnJFoqMVcVJwIAL/VdNMwAwAA 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, 02 Nov 2017 20:39:45 -0000 On 11/2/17 2:59 AM, Jesske, Roland wrote: > Hi, > > I agree on Christer’s comment. > > But nevertheless I would be happy to see a clear advice for the refresh > mechanism when the S-E timer is switched off. > > Perhaps an table and some text in section 7.4 for the refresh mechanism > would help e.g.: > > This is valid for UPDATE and INVITE refreshing a session where S-E is > negotiated and the supported header with timer is set. > > UAC supports? SE parameter    S-E parameter        S-E > > in request     in response      switched off > > ---------------------------------------------------------- > >       Y              Y                N                Y > >       Y              N                Y                N > >       Y              N                N                Y I don't find this table helpful because of the complex interactions with who is the refresher, and with what might be done by a proxy in the middle. Thanks, Paul >                         Figure X Switch off S-E > > When the when required timer set the S-E cannot be switched off. > > What do you think? > > Of course we could do the same for the initial negotiation to make > everything clear. > > Best Regards > > Roland > > *Von:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Gesendet:* Dienstag, 31. Oktober 2017 19:44 > *An:* Roman Shpount > *Cc:* Paul Kyzivat ; Jesske, Roland > ; sipcore@ietf.org > *Betreff:* RE: [sipcore] Session timer fix > > Hi, > > I may reply to Roman’s comments later. > > But, at the end of the day I think what Paul said is what matters most: > the procedures for turning session timer etc applies AFTER the session > timer has been fully negotiated. > > So, if the session timer is negotiated during the initial INVITE > transaction, whatever UPDATEs are sent during that transaction will not > contain session timer information, and they will have no impact on the > session timer. > > But, once the session timer has been negotiated (once the UAC has > received the 200 OK, the rules regarding turning the session timer off > etc applies. > > Regards, > > Christer > > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* 31 October 2017 20:21 > *To:* Christer Holmberg > > *Cc:* Paul Kyzivat >; Jesske, Roland >; sipcore@ietf.org > *Subject:* Re: [sipcore] Session timer fix > > On Tue, Oct 31, 2017 at 4:35 AM, Christer Holmberg > > > 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 > From nobody Thu Nov 2 14:07: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 5032113F974 for ; Thu, 2 Nov 2017 14:07:54 -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 6l-crYYXFeW1 for ; Thu, 2 Nov 2017 14:07:52 -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 0CBF513F682 for ; Thu, 2 Nov 2017 14:07:51 -0700 (PDT) X-AuditID: 12074411-f7dff70000007f0a-09-59fb8927cbab 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 8D.E0.32522.7298BF95; Thu, 2 Nov 2017 17:07:51 -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 vA2L7mId012292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Nov 2017 17:07:49 -0400 To: Christer Holmberg , Roman Shpount Cc: "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 2 Nov 2017 17:07:48 -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: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixO6iqKve+TvS4M1xYYsLMw8zWjTd6WKz mHFhKrPF1x+b2BxYPH59vcrmsWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBl3H9xkL3g qHTF1LlTWBoYj4t2MXJySAiYSMz6fpKti5GLQ0hgB5PE+hmnWCCcB0wSd4+8ZwWpEhbQkDi0 5zdQgoNDRCBJ4lh3CUiYWSBKomXDXqjmBmaJu7eOs4Mk2AS0JOYc+s8CYvMK2Ev8uXaWCcRm EVCROPXqL1hcVCBN4s6Mh0wQNYISJ2c+AYtzCvhJXJv5hhligZnEvM0PoWxxiVtP5jNB2PIS zVtnM09gFJiFpH0WkpZZSFpmIWlZwMiyilEuMac0Vzc3MTOnODVZtzg5MS8vtUjXVC83s0Qv NaV0EyMkzAV3MM44KXeIUYCDUYmH94D6r0gh1sSy4srcQ4ySHExKorx3NwKF+JLyUyozEosz 4otKc1KLDzFKcDArifA+jvkdKcSbklhZlVqUD5OS5mBREuflW6LuJySQnliSmp2aWpBaBJOV 4eBQkuBt6gBqFCxKTU+tSMvMKUFIM3FwggznARoeBFLDW1yQmFucmQ6RP8Voz9HTc+MPE8em m3eB5IbvD4Dks5mvG5iFWPLy81KlxHkDQNoEQNoySvPgJsNS2CtGcaBHhXn7Qap4gOkPbvYr oLVMQGu9JH6ArC1JREhJNTCK3atwnX99qbON8acLOXVT/a/q/Vov8d+uu/76ZdmdVVHTPk5p tkyTFF0rap5umsP+e/XChoaJBX/y1k3S+39tbfaU/xazzuy7P/HQ0Z3110+oJNs79D0vvbHz yy1hxjO/+ctcotJW5v2zD2OdkbP7RMfF9Skpz3btPTAj/+TGhFsBH9l3n+VMUmIpzkg01GIu Kk4EAJns+SE8AwAA 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, 02 Nov 2017 21:07:54 -0000 On 10/31/17 2:43 PM, Christer Holmberg wrote: > Hi, > > I may reply to Roman’s comments later. > > But, at the end of the day I think what Paul said is what matters most: > the procedures for turning session timer etc applies AFTER the session > timer has been fully negotiated. > > So, if the session timer is negotiated during the initial INVITE > transaction, whatever UPDATEs are sent during that transaction will not > contain session timer information, and they will have no impact on the > session timer. > > But, once the session timer has been negotiated (once the UAC has > received the 200 OK, the rules regarding turning the session timer off > etc applies. I don't think this is the right distinction, because it doesn't cover an update done in the midst of a re-INVITE transaction. The key think is to treat an UPDATE in the midst of an INVITE transaction differently from an UPDATE outside of an INVITE. And IMO this needs to have well defined behavior even if there is a proxy that doesn't support this revision. I've been evolving my thinking as this discussion has continued. I see a couple of ways to go: 1) Specify that the negotiation in the INVITE transaction should be unaffected by whatever happens in an intervening UPDATE. Also specify how timer stuff should be handled in an UPDATE within an INVITE. For that I think what we have been converging on is: - the UAC and proxies for the embedded UPDATE should not include S-E; - the UAS should not include S-E in the UPDATE response, even if it gets one in the request; - proxies should not add an S-E to an embedded UPDATE response; - the UAC should ignore S-E in an embedded UPDATE response. But the key here is the UAC ignoring it. 2) Specify that a UAC or proxy should duplicate in an embedded UPDATE whatever timer stuff they put in the enclosing INVITE transaction. And then the UAC for the INVITE should process the timer stuff in the 2xx response to the INVITE the same as if the UPDATE didn't happen. (What it does to process the timer stuff in the 200 for the UPDATE is irrelevant.) I think (1) is closer to what we have been converging on. But I am now thinking that (2) is more robust in the presence of some components that don't implement the revision. Thanks, Paul > Regards, > > Christer > > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* 31 October 2017 20:21 > *To:* Christer Holmberg > *Cc:* Paul Kyzivat ; Jesske, Roland > ; sipcore@ietf.org > *Subject:* Re: [sipcore] Session timer fix > > On Tue, Oct 31, 2017 at 4:35 AM, Christer Holmberg > > > 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 > From nobody Thu Nov 2 14:28:02 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 1AC5213F9BA for ; Thu, 2 Nov 2017 14:28:02 -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 GTuUycWmbvwo for ; Thu, 2 Nov 2017 14:28:00 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B831513F9B8 for ; Thu, 2 Nov 2017 14:28:00 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id a192so713087pge.9 for ; Thu, 02 Nov 2017 14:28:00 -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=KZP5jfjSkRNN1VeTUHUDRfMsDjM3VJoZxJSHsichwrk=; b=OFbyfMAeRvyPqQbhn2TmkDR1zVySMvUNJAOR5o2dGLrtGjCZXlwlo6GIyBaW9U+N7b D2Nss7p1NbJgyrAum10O4S/sqrOpl5CA97pAABbDVRG/nEuWvR0/Yn3UAhV2cfjBdob2 4aG4o/R5IMHXNHVSmO9mogePMfx8tT5Ps5eq1WQFaD+/1sqlQEHUl/QsfcmwdqfyMYqL tq4MbMUyienNPRU2vbFE2qU76mBBTODRh4ziTSsfgh5xfzwgM+vtWkqzTdNsxiQZo4QF GvBbcx66ktPpCXnBxjmIZ8nVlWs3dHXl8y2f1km0omD7726/xyOMfIYwEm/PrNL5vn+S nUZQ== 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=KZP5jfjSkRNN1VeTUHUDRfMsDjM3VJoZxJSHsichwrk=; b=pfAXAcOibh72bYY9nW+vDi4yvZ4Ys+SvrcXZ8UV3khbGXJ4Nln7AJxUseSHx0c9O8W UidsaYP9lJj3SpF0hq6rRkurkiy8AHwiX0IeXw6scvb6qU2KQHGwienY0j2R4gAyedqN O3qpOkAoaN8Gkc0F6DNixw9Bq7pLVXk3KPKTkadkwfxQ/nh9lRGNarlxxPtYf85n7jj+ xHwppRUobvVGH8tJlePe04kdabzPWTc3gOukX/OLBWkLQ7ENC3oa4yOk1PsJFhgKXlXX 1TyzcqIDaroa9tn4jQhJFvYRCWKXXqAEi/MVyU2sL4YQp00uLTYtuAJLgVXBK8TTQw9Q DN3w== X-Gm-Message-State: AMCzsaVMfoRG1O/08Db+AQbvpAejVY98eP1wGYcxx9XA8N9ajckR3/jJ hM2GAET+QyRqtB6PJryJgsjWpMm+ X-Google-Smtp-Source: ABhQp+R39rkp+KiUQMirCt6bRlukq30cltRGIio9lhS0YkSZVaNa3a0d20oZ1i1YRJJMuWFqLiQYUw== X-Received: by 10.99.36.133 with SMTP id k127mr4836342pgk.171.1509658080195; Thu, 02 Nov 2017 14:28:00 -0700 (PDT) Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com. [209.85.192.180]) by smtp.gmail.com with ESMTPSA id g5sm6568624pgq.94.2017.11.02.14.27.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 14:27:59 -0700 (PDT) Received: by mail-pf0-f180.google.com with SMTP id i5so633663pfe.6 for ; Thu, 02 Nov 2017 14:27:58 -0700 (PDT) X-Received: by 10.99.97.149 with SMTP id v143mr5053011pgb.413.1509658078551; Thu, 02 Nov 2017 14:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.131 with HTTP; Thu, 2 Nov 2017 14:27:57 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> From: Roman Shpount Date: Thu, 2 Nov 2017 17:27:57 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0cc3828126f2055d06a941" 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, 02 Nov 2017 21:28:02 -0000 --94eb2c0cc3828126f2055d06a941 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 2, 2017 at 5:07 PM, Paul Kyzivat wrote: > And IMO this needs to have well defined behavior even if there is a proxy > that doesn't support this revision. > > I've been evolving my thinking as this discussion has continued. I see a > couple of ways to go: > > 1) Specify that the negotiation in the INVITE transaction should be > unaffected by whatever happens in an intervening UPDATE. Also specify how > timer stuff should be handled in an UPDATE within an INVITE. For that I > think what we have been converging on is: > > - the UAC and proxies for the embedded UPDATE should not include S-E; > - the UAS should not include S-E in the UPDATE response, > even if it gets one in the request; > - proxies should not add an S-E to an embedded UPDATE response; > - the UAC should ignore S-E in an embedded UPDATE response. > > But the key here is the UAC ignoring it. > > 2) Specify that a UAC or proxy should duplicate in an embedded UPDATE > whatever timer stuff they put in the enclosing INVITE transaction. And then > the UAC for the INVITE should process the timer stuff in the 2xx response > to the INVITE the same as if the UPDATE didn't happen. (What it does to > process the timer stuff in the 200 for the UPDATE is irrelevant.) > > I think (1) is closer to what we have been converging on. But I am now > thinking that (2) is more robust in the presence of some components that > don't implement the revision. > There are two requirements for this work: 1. UAC must ignore the S-T negotiation result when UPDATE is within INVITE transaction 2. UAC and UAS mast agree on the negotiation results. I was thinking that including some sort of header (or supported tag) in the UPDATE request and mirroring the same header (or tag) in the response would be the best way to achieve this result. In this case, it is irrelevant if proxies inserted S-E in the request -- the new header will overwrite it. Proxies can also detect that S-E will have no effect on this request or response, since the extra header is present. UAC and UAS will know that they behave the same way since they will both see this header only if they both support it. Regards, _____________ Roman Shpount --94eb2c0cc3828126f2055d06a941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 2, 2017 at 5:07 PM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:
And IMO this needs to have well d= efined behavior even if there is a proxy that doesn't support this revi= sion.

I've been evolving my thinking as this discussion has continued. I see = a couple of ways to go:

1) Specify that the negotiation in the INVITE transaction should be unaffec= ted by whatever happens in an intervening UPDATE. Also specify how timer st= uff should be handled in an UPDATE within an INVITE. For that I think what = we have been converging on is:

- the UAC and proxies for the embedded UPDATE should not include S-E;
- the UAS should not include S-E in the UPDATE response,
=C2=A0 even if it gets one in the request;
- proxies should not add an S-E to an embedded UPDATE response;
- the UAC should ignore S-E in an embedded UPDATE response.

But the key here is the UAC ignoring it.

2) Specify that a UAC or proxy should duplicate in an embedded UPDATE whate= ver timer stuff they put in the enclosing INVITE transaction. And then the = UAC for the INVITE should process the timer stuff in the 2xx response to th= e INVITE the same as if the UPDATE didn't happen. (What it does to proc= ess the timer stuff in the 200 for the UPDATE is irrelevant.)

I think (1) is closer to what we have been converging on. But I am now thin= king that (2) is more robust in the presence of some components that don= 9;t implement the revision.

There are t= wo requirements for this work:

1. UAC must ignore = the S-T negotiation result when UPDATE is within INVITE transaction
2. UAC and UAS mast agree on the negotiation results.

I was thinking that including some sort of header (or supported tag)= in the UPDATE request and mirroring the same header (or tag) in the respon= se would be the best way to achieve this result. In this case, it is irrele= vant if proxies inserted S-E in the request -- the new header will overwrit= e it. Proxies can also detect that S-E will have no effect on this request = or response, since the extra header is present.

UA= C and UAS will know that they behave the same way since they will both see = this header only if they both support it.

Regards,=
_____________
Roman Shpount
=C2=A0
--94eb2c0cc3828126f2055d06a941-- From nobody Thu Nov 2 14:47: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 408C313F70B for ; Thu, 2 Nov 2017 14:47:47 -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 GDT4o7btRUey for ; Thu, 2 Nov 2017 14:47:46 -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 A3B6513F69E for ; Thu, 2 Nov 2017 14:47:45 -0700 (PDT) X-AuditID: 1207440e-bf9ff70000007085-2d-59fb927f53bd 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 D0.19.28805.F729BF95; Thu, 2 Nov 2017 17:47:43 -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 vA2Llf6b014499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Nov 2017 17:47:42 -0400 To: Roman Shpount Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 2 Nov 2017 17:47:40 -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+NgFprLKsWRmVeSWpSXmKPExsUixO6iqNsw6Xekwe3nQhYXZh5mtGi608Vm MePCVGaLrz82sTmwePz6epXNY8mSn0webS8VPG5NKQhgieKySUnNySxLLdK3S+DKuN0nUHBS ouLm6duMDYwXhLoYOTkkBEwkpix+wdzFyMUhJLCDSWLa6RlQzgMmiRV3tjCBVAkLaEgc2vOb BcQWEVCV+Pt9MhNIEbPAdEaJ3/OaoDr+MkvcbQVxODnYBLQk5hz6D9bBK2Av8fnhQzYQm0VA ReLh8cWMILaoQJrEnRkPmSBqBCVOznwCVM/BwSkQKHF8VjlImFnATGLe5ofMELa4xK0n85kg bHmJ5q2zmScwCsxC0j0LScssJC2zkLQsYGRZxSiXmFOaq5ubmJlTnJqsW5ycmJeXWqRrrJeb WaKXmlK6iRES5nw7GNvXyxxiFOBgVOLhldD6FSnEmlhWXJl7iFGSg0lJlPfuRqAQX1J+SmVG YnFGfFFpTmrxIUYJDmYlEd7HMb8jhXhTEiurUovyYVLSHCxK4rxqS9T9hATSE0tSs1NTC1KL YLIyHBxKErxmE4EaBYtS01Mr0jJzShDSTBycIMN5gIbvAKnhLS5IzC3OTIfIn2I05ujpufGH iePZzNcNzEIsefl5qVLivOYgpQIgpRmleXDTYKnqFaM40HPCvNwgVTzANAc37xXQKiagVV4S P0BWlSQipKQaGKMMZXaZTgyyLC1lW7Rs6UyfslPrlNZrT3Y+floj5epis5qk8+9FWY5+zpqz XXBtnlrkvlc9Fmsa5ig2Z22UYjL6GejEEHS5XOHG8rhU8UAPbZdHFjOPFTpdWHS1xSesq694 UtuDCRtFmGzNPj2/EVz/QO6teFb71/sRYlMNC3lkBTdZrL7sosRSnJFoqMVcVJwIAK/6KDcw AwAA 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, 02 Nov 2017 21:47:47 -0000 On 11/2/17 5:27 PM, Roman Shpount wrote: > On Thu, Nov 2, 2017 at 5:07 PM, Paul Kyzivat > wrote: > > And IMO this needs to have well defined behavior even if there is a > proxy that doesn't support this revision. > > I've been evolving my thinking as this discussion has continued. I > see a couple of ways to go: > > 1) Specify that the negotiation in the INVITE transaction should be > unaffected by whatever happens in an intervening UPDATE. Also > specify how timer stuff should be handled in an UPDATE within an > INVITE. For that I think what we have been converging on is: > > - the UAC and proxies for the embedded UPDATE should not include S-E; > - the UAS should not include S-E in the UPDATE response, >   even if it gets one in the request; > - proxies should not add an S-E to an embedded UPDATE response; > - the UAC should ignore S-E in an embedded UPDATE response. > > But the key here is the UAC ignoring it. > > 2) Specify that a UAC or proxy should duplicate in an embedded > UPDATE whatever timer stuff they put in the enclosing INVITE > transaction. And then the UAC for the INVITE should process the > timer stuff in the 2xx response to the INVITE the same as if the > UPDATE didn't happen. (What it does to process the timer stuff in > the 200 for the UPDATE is irrelevant.) > > I think (1) is closer to what we have been converging on. But I am > now thinking that (2) is more robust in the presence of some > components that don't implement the revision. > > > There are two requirements for this work: > > 1. UAC must ignore the S-T negotiation result when UPDATE is within > INVITE transaction > 2. UAC and UAS mast agree on the negotiation results. > > I was thinking that including some sort of header (or supported tag) in > the UPDATE request and mirroring the same header (or tag) in the > response would be the best way to achieve this result. In this case, it > is irrelevant if proxies inserted S-E in the request -- the new header > will overwrite it. Proxies can also detect that S-E will have no effect > on this request or response, since the extra header is present. > > UAC and UAS will know that they behave the same way since they will both > see this header only if they both support it. I'm not sure a tag adds much. It doesn't do anything for proxies unless we use Proxy-Require, and we don't want that. And what do you do if the tag isn't recognized by the UAS? ISTM a way to approach this is to first specify our proposed behavior (as in (1) or (2)). Then we need to analyze it in the presence of one or more components that don't implement the revision, and with various plausible interpretations of the existing ambiguous specification. And then see if the result is any worse for any components with the revision than it is without it. (And I guess we should also figure out if it is any *better* before going ahead and doing this.) Thanks, Paul From nobody Fri Nov 3 03:02: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 2C81813FD3F for ; Fri, 3 Nov 2017 03:02:42 -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_H4=-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 anR-m0ITrH1X for ; Fri, 3 Nov 2017 03:02:39 -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 1399E13FD39 for ; Fri, 3 Nov 2017 03:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1509703359; x=1541239359; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VscMv7DQo9Wu/AUIovXGmCIbBQf8dSnrp2kJqWqIujc=; b=5qgNUxUHoHBglPNkXHZI1C7iAJQll9tHhtHc9gdCkVOIggWEWVr9iizl RpZlrOjfrfVJEAGfHBn7z+R8kYuVUUE5XNW3fTteh6yzaha4sFu9wHN+k RNdCqN/FRraLg9wRPUGzyW3a2RIcVER+U1A0n2cysP4gDFF5mOgWulRCg h5yhpkKW8iprEF46xF1DHpbUFpdB9OhnC18Kug3voamDmJ7wVqnuTakIX DBZy6S8TZPYDcYY6AyBDHUUxGMy7h+qIiN6T6VCfWgok/hY6UbG8LewiY 2QrMKDED2D5vTvuBKQ5d4wA3xo+ofdKQug+QRI5l9fIJPzgAkR8Zww8/A Q==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2017 11:02:36 +0100 X-IronPort-AV: E=Sophos;i="5.44,338,1505772000"; d="scan'208";a="107802265" Received: from he104852.emea1.cds.t-internal.com ([10.169.118.15]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 03 Nov 2017 11:02:35 +0100 Received: from HE105762.EMEA1.cds.t-internal.com (10.169.118.58) by HE104852.emea1.cds.t-internal.com (10.169.118.15) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 11:02:35 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105762.EMEA1.cds.t-internal.com (10.169.118.58) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 3 Nov 2017 11:02:35 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.17) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 11:02:26 +0100 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.197.15; Fri, 3 Nov 2017 10:02:34 +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.0197.017; Fri, 3 Nov 2017 10:02:34 +0000 From: "Jesske, Roland" To: Christer Holmberg , Roman Shpount CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnUFtGaBJrWltk+s1shdGvlnWqL+S3eAgAEO8PCAAfqXAIAAAtwAgAEXz1A= Date: Fri, 3 Nov 2017 10:02:34 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B5C686C88@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C686C88@ESESSMB109.ericsson.se> 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.242] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:dyjZlnCCeTS3YOzzRzdnVSDfQLEaLVPZ45yRyiWnYVfPcIqy3g3nhOTrM6Oi9xcPimCLOlqh7+nCN+faP9WeVV6G14k8elOV6jeRTGRJ34VxnPCiNvIpKzLaXXHWlXLRnN1j4YBcT4/XEngfCAFWhb0hpmGReMRIIwGgaZSeaSPz0x2MGBFkhlC6scZXSGPg9KKpd9z0ezABSB1MR7xvgQ7N2vJoU1uJ/urRaCg2H4mOlPipwRTjXoKKhLkcL0l55DeK+FksxTnGlCePYnebWXgchjbqLS3o41AmgyypUHCKsAAfR30JLLyJO6MT9+Kl59Fkq8zwF0AXmkhEIrsq/ZGMNwybY+z9/NCRLhXGzjE=; 5:NWcEeh2z7E5jeo4v1rFntbkNg4v1Uj2LfrBShXKLMMr2iaiLBlwbRGPTN/CfgJpVTn6L5BF63BgT1SZvJ3eIO/BaSP826Wlu7y6lO1USDGaWS/iW707miVvlsWeH3VcIn+iifMzIKLDGCKSZCznRaDBI0sK0F1vEeQKJBzEzks8=; 24:sIDiQl5Jo+G8HzTFtjGrBueOg2meFc6C17PWYwBPGuoQo+eG0xGz3pWdm9DmuBu+Yl77P1rujSqKAzHSGflZAXNKZow58lwP6ZNzd3CS82c=; 7:J2RcDgqtMnbgyuflHB5kosZHyn8RHMT4E7SLbeY52p4YBFj9NI1DVjJ4ppHK78TzlNTF45kxTHd4sg9d3NIPEbYdS2/ol+jS9dITona2yt4k1SgnyAOOQxFSQwy5uVZozZQoEm9U/TExjosoR4IWd5TqdAap691oQ2Yjjur9gaL9g0PAfkW+2PFkprHt0gp4CX5yJ1QytZfw1tfDQWwoODgF36em9zdmdiaIVIBmFAFbsw53YyzLuZUnUa3EYjEI x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 421f2791-e107-4828-885f-08d522a20169 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: 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)(3231021)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(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: 0480A51D4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(199003)(76104003)(24454002)(3280700002)(4326008)(7736002)(97736004)(3660700001)(305945005)(5250100002)(86362001)(76176999)(189998001)(54356999)(3846002)(6116002)(102836003)(7696004)(5660300001)(2950100002)(2906002)(50986999)(53546010)(2900100001)(75402003)(66066001)(110136005)(316002)(106356001)(105586002)(14454004)(33656002)(551934003)(68736007)(74482002)(93886005)(81166006)(81156014)(101416001)(966005)(8676002)(72206003)(8936002)(53936002)(478600001)(55016002)(9686003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0482; 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 421f2791-e107-4828-885f-08d522a20169 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2017 10:02:34.5751 (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] 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, 03 Nov 2017 10:02:42 -0000 SGkgQ2hyaXN0ZXIsDQp5ZXMgb2ZmZXIvYW5zd2VyIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggaXQu IEkgbWVhbnQgUmVxdWVzdC4NClRoZSB0YWJsZSB3YXMgdGFsa2luZyBhYm91dCBSZXF1ZXN0IGFu ZCByZXNwb25zZS4NCg0KU28gYnkgdGFraW5nIHlvdXIgd29yZHMuIEluZGVwZW5kZW50IHdoYXQg d2FzIHN0YXRlZCB3aXRoaW4gdGhlIFJFUVVFU1Qgb2YgdGhlIHJlZnJlc2ggaWYgdGhlIFJFU1BP TlNFIGRvZXMgbm90IGNvbnRhaW4gdGhlIFNFIHRoZW4gdGhlIFNlc3Npb24gVGltZSBNZWNoYW5p c20gaXMgc3dpdGNoZWQgb2ZmLg0KQ29ycmVjdC4NCg0KQmVzdCBSZWdhcmRzDQoNClJvbGFuZA0K DQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBzaXBjb3JlIFtt YWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBDaHJpc3Rlcg0K PiBIb2xtYmVyZw0KPiBHZXNlbmRldDogRG9ubmVyc3RhZywgMi4gTm92ZW1iZXIgMjAxNyAxODox Nw0KPiBBbjogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+OyBKZXNza2UsIFJvbGFu ZA0KPiA8Ui5KZXNza2VAdGVsZWtvbS5kZT4NCj4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmcNCj4gQmV0 cmVmZjogUmU6IFtzaXBjb3JlXSBTZXNzaW9uIHRpbWVyIGZpeA0KPiANCj4gSGksDQo+IA0KPiA+ IEkgbWlnaHQgYmUgbWlzc2luZyBzb21ldGhpbmcsIGJ1dCBTZXNzaW9uIFRpbWVyIGlzIHN3aXRj aGVkIG9mIGJ5IHRoZQ0KPiA+IGxhc3Qgc3VjY2VzcyByZXNwb25zZSB0byBJTlZJVEUgb3IgVVBE QVRFLiBQcmVzZW5jZSBvZiBTZXNzaW9uLUV4cGlyZXMgaW4gdGhlDQo+IG9mZmVyIGlzIGlycmVs ZXZhbnQsIHNvIHRoaXMgdGFibGUgaXMgd3JvbmcuDQo+IA0KPiBJIGRvbid0IHRoaW5rIHdlIHNo b3VsZCB0YWxrIGFib3V0IG9mZmVycyBhbmQgYW5zd2VycywgYnV0IHJlcXVlc3RzIGFuZA0KPiBy ZXNwb25zZXMuIFRoaXMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBvZmZlci9hbnN3ZXIgOikNCj4g DQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IA0KPiANCj4gT24gVGh1LCBO b3YgMiwgMjAxNyBhdCAyOjU5IEFNLCBKZXNza2UsIFJvbGFuZCA8Ui5KZXNza2VAdGVsZWtvbS5k ZT4gd3JvdGU6DQo+IEhpLA0KPiBJIGFncmVlIG9uIENocmlzdGVy4oCZcyBjb21tZW50Lg0KPiBC dXQgbmV2ZXJ0aGVsZXNzIEkgd291bGQgYmUgaGFwcHkgdG8gc2VlIGEgY2xlYXIgYWR2aWNlIGZv ciB0aGUgcmVmcmVzaA0KPiBtZWNoYW5pc20gd2hlbiB0aGUgUy1FIHRpbWVyIGlzIHN3aXRjaGVk IG9mZi4NCj4gUGVyaGFwcyBhbiB0YWJsZSBhbmQgc29tZSB0ZXh0IGluIHNlY3Rpb24gNy40IGZv ciB0aGUgcmVmcmVzaCBtZWNoYW5pc20gd291bGQNCj4gaGVscCBlLmcuOg0KPiANCj4gVGhpcyBp cyB2YWxpZCBmb3IgVVBEQVRFIGFuZCBJTlZJVEUgcmVmcmVzaGluZyBhIHNlc3Npb24gd2hlcmUg Uy1FIGlzDQo+IG5lZ290aWF0ZWQgYW5kIHRoZSBzdXBwb3J0ZWQgaGVhZGVyIHdpdGggdGltZXIg aXMgc2V0Lg0KPiANCj4gDQo+IFVBQyBzdXBwb3J0cz/CoMKgwqAgU0UgcGFyYW1ldGVywqDCoMKg IFMtRSBwYXJhbWV0ZXLCoMKgwqDCoCDCoMKgwqBTLUUNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgaW4gcmVxdWVzdMKgwqDCoMKgIGluIHJlc3BvbnNlwqAgwqDCoMKgwqBz d2l0Y2hlZCBvZmYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiDCoMKgwqDCoMKgIFnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBZwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIE7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgWQ0KPiDCoMKgwqDCoMKgIFnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBOwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgTg0KPiDCoMKgwqDCoMKgIFnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBOwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIE7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgWQ0K PiANCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBGaWd1 cmUgWCBTd2l0Y2ggb2ZmIFMtRQ0KPiANCj4gV2hlbiB0aGUgd2hlbiByZXF1aXJlZCB0aW1lciBz ZXQgdGhlIFMtRSBjYW5ub3QgYmUgc3dpdGNoZWQgb2ZmLg0KPiANCj4gV2hhdCBkbyB5b3UgdGhp bms/DQo+IE9mIGNvdXJzZSB3ZSBjb3VsZCBkbyB0aGUgc2FtZSBmb3IgdGhlIGluaXRpYWwgbmVn b3RpYXRpb24gdG8gbWFrZSBldmVyeXRoaW5nDQo+IGNsZWFyLg0KPiANCj4gQmVzdCBSZWdhcmRz DQo+IA0KPiBSb2xhbmQNCj4gDQo+IA0KPiBWb246IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPiBHZXNlbmRldDogRGllbnN0YWcsIDMx LiBPa3RvYmVyIDIwMTcgMTk6NDQNCj4gQW46IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXgu Y29tPg0KPiBDYzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBKZXNza2Us IFJvbGFuZA0KPiA8Ui5KZXNza2VAdGVsZWtvbS5kZT47IHNpcGNvcmVAaWV0Zi5vcmcNCj4gQmV0 cmVmZjogUkU6IFtzaXBjb3JlXSBTZXNzaW9uIHRpbWVyIGZpeA0KPiANCj4gSGksDQo+IA0KPiBJ IG1heSByZXBseSB0byBSb21hbuKAmXMgY29tbWVudHMgbGF0ZXIuDQo+IA0KPiBCdXQsIGF0IHRo ZSBlbmQgb2YgdGhlIGRheSBJIHRoaW5rIHdoYXQgUGF1bCBzYWlkIGlzIHdoYXQgbWF0dGVycyBt b3N0OiB0aGUNCj4gcHJvY2VkdXJlcyBmb3IgdHVybmluZyBzZXNzaW9uIHRpbWVyIGV0YyBhcHBs aWVzIEFGVEVSIHRoZSBzZXNzaW9uIHRpbWVyIGhhcw0KPiBiZWVuIGZ1bGx5IG5lZ290aWF0ZWQu DQo+IA0KPiBTbywgaWYgdGhlIHNlc3Npb24gdGltZXIgaXMgbmVnb3RpYXRlZCBkdXJpbmcgdGhl IGluaXRpYWwgSU5WSVRFIHRyYW5zYWN0aW9uLA0KPiB3aGF0ZXZlciBVUERBVEVzIGFyZSBzZW50 IGR1cmluZyB0aGF0IHRyYW5zYWN0aW9uIHdpbGwgbm90IGNvbnRhaW4gc2Vzc2lvbg0KPiB0aW1l ciBpbmZvcm1hdGlvbiwgYW5kIHRoZXkgd2lsbCBoYXZlIG5vIGltcGFjdCBvbiB0aGUgc2Vzc2lv biB0aW1lci4NCj4gDQo+IEJ1dCwgb25jZSB0aGUgc2Vzc2lvbiB0aW1lciBoYXMgYmVlbiBuZWdv dGlhdGVkIChvbmNlIHRoZSBVQUMgaGFzIHJlY2VpdmVkDQo+IHRoZSAyMDAgT0ssIHRoZSBydWxl cyByZWdhcmRpbmcgdHVybmluZyB0aGUgc2Vzc2lvbiB0aW1lciBvZmYgZXRjIGFwcGxpZXMuDQo+ IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiBGcm9tOiBSb21hbiBTaHBv dW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo+IFNlbnQ6IDMxIE9jdG9iZXIgMjAxNyAy MDoyMQ0KPiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4NCj4gQ2M6IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgSmVzc2tl LCBSb2xhbmQNCj4gPFIuSmVzc2tlQHRlbGVrb20uZGU+OyBzaXBjb3JlQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbc2lwY29yZV0gU2Vzc2lvbiB0aW1lciBmaXgNCj4gDQo+IA0KPiBPbiBUdWUs IE9jdCAzMSwgMjAxNyBhdCA0OjM1IEFNLCBDaHJpc3RlciBIb2xtYmVyZw0KPiA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IG5v LVNFLWluLXJlc3BvbnNlIHdvdWxkIHN3aXRjaCBvZmYgaWYgU0Ugd2FzIGluIHRoZQ0KPiByZXF1 ZXN0Lg0KPiANCj4gU28sIGlmIHRoZXJlIGlzIG5vIFNFIGluIHRoZSByZXF1ZXN0LCB0aGVyZSBp cyBubyBzd2l0Y2ggb2ZmLg0KPiANCj4gVGhpcyB3aWxsIGJyZWFrIHByZXR0eSBtdWNoIGV2ZXJ5 IFNFIGltcGxlbWVudGF0aW9uLiBUaGVyZSBhcmUgbnVtYmVyIG9mDQo+IGltcGxlbWVudGF0aW9u cyB3aGVyZSBVQSBkb2VzIG5vdCBpbnNlcnQgU0UgaW4gdGhlIHJlcXVlc3QuIEl0IGlzIGluc2Vy dGVkDQo+IGVpdGhlciBieSBwcm94aWVzIChhY3R1YWxseSB0aGlzIGlzIHRoZSBtb3N0IGNvbW1v biB1c2UgY2FzZSkgb3IgYnkgdGhlDQo+IGFuc3dlcmluZyBhZ2VudC4NCj4gDQo+IEkgdGhpbmsg aXQgd291bGQgYmUgbXVjaCBiZXR0ZXIgdG8gaGF2ZSBhIG5ldyBoZWFkZXIgd2hpY2ggd2lsbCBz cGVjaWZ5ICJkbyBub3QNCj4gdXBkYXRlIFNlc3Npb24tVGltZXIiIGluIHRoZSBvZmZlci4NCj4g VGhpcyB3YXkgaWYgcHJveGllcyBpbnNlcnQgU2Vzc2lvbi1UaW1lciwgbmV3IGhlYWRlciB3aWxs IG92ZXJ3cml0ZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IF9fX19fX19fX19fX18NCj4gUm9tYW4gU2hw b3VudA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From nobody Mon Nov 6 09:12: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 951A513FB55; Mon, 6 Nov 2017 09:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 xHJX27K0Bgjs; Mon, 6 Nov 2017 09:12:19 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A0813FAF7; Mon, 6 Nov 2017 09:12:19 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id EDD9F40B09; Mon, 6 Nov 2017 18:12:17 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id CD9031A005E; Mon, 6 Nov 2017 18:12:17 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0361.001; Mon, 6 Nov 2017 18:12:17 +0100 From: To: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Thread-Topic: Moving forward with draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdNXIjwlWLrexLcES629EV6FwjmfbA== Date: Mon, 6 Nov 2017 17:12:16 +0000 Message-ID: <21917_1509988337_5A0097F1_21917_335_1_8B970F90C584EA4E97D5BAAC9172DBB81D650552@OPEXCLILMA4.corporate.adroot.infra.ftgroup> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sipcore] Moving forward with draft-ietf-sipcore-originating-cdiv-parameter 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, 06 Nov 2017 17:12:21 -0000 Hi folks, This draft was adopted in SIPCORE WG in May.=20 A new version including Christer's comments has been published in September= 27th.=20 Since there was no additional feedback on this I-D, I would like to take th= e opportunity of the upcoming meeting to ask if it should move forward goin= g to WGLC. Feedbacks are welcomed! Regards, Marianne > -----Message d'origine----- > De=A0: sipcore [mailto:sipcore-bounces@ietf.org] De la part de > marianne.mohali@orange.com > Envoy=E9=A0: jeudi 28 septembre 2017 00:42 > =C0=A0: sipcore@ietf.org; sipcore-chairs@ietf.org > Objet=A0: [sipcore] New version of draft-ietf-sipcore-originating-cdiv-pa= rameter >=20 > Hi, >=20 > Here is the -01 version of the working group document draft-ietf-sipcore-= originating- > cdiv-parameter. > In this version I have splitted the introduction section into the normal = use case (as > defined in RFC5502) and the problem statement by which it has been decide= d to > propose an extension of the P-Served-User header. > Call Flows section has also been added to illustrate usage of the new pro= posed > session case. >=20 > Review and comments are welcome. >=20 > Best regards, > Marianne >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-para= meter/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-originating-cdiv-parameter= -01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-originating-cdiv= -parameter-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-originating-cdiv-p= arameter-01 >=20 >=20 > ____________________________________________________________________ > _____________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles > ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies= sans > autorisation. Si vous avez recu ce message par erreur, veuillez le signal= er a > l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques > etant susceptibles d'alteration, Orange decline toute responsabilite si c= e message a > ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation > that may be protected by law; they should not be distributed, used or cop= ied without > authorisation. > If you have received this email in error, please notify the sender and de= lete 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 ___________________________________________________________________________= ______________________________________________ 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. From nobody Thu Nov 16 16:52: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 9B446126BF0 for ; Thu, 16 Nov 2017 16:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 860pGa1QeDit for ; Thu, 16 Nov 2017 16:52:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AC3126CB6 for ; Thu, 16 Nov 2017 16:52:10 -0800 (PST) Received: from [10.178.73.221] (mobile-166-170-37-195.mycingular.net [166.170.37.195]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vAH0q62E026396 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 16 Nov 2017 18:52:10 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-170-37-195.mycingular.net [166.170.37.195] claimed to be [10.178.73.221] From: Ben Campbell Content-Type: multipart/alternative; boundary=Apple-Mail-6592039E-7380-4450-B44B-270379212C85 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Fri, 17 Nov 2017 08:52:00 +0800 Message-Id: <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> References: <20171116022038.047B6B8104D@rfc-editor.org> To: sipcore@ietf.org X-Mailer: iPhone Mail (15B93) Archived-At: Subject: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 17 Nov 2017 00:52:19 -0000 --Apple-Mail-6592039E-7380-4450-B44B-270379212C85 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi,=20 Does anyone in sipcore have thoughts on this?=20 Thanks, Ben. Begin forwarded message: > From: RFC Errata System > Date: November 16, 2017 at 10:20:38 AM GMT+8 > To: jon.peterson@neustar.biz, ben@nostrum.com, aamelnikov@fastmail.fm, ada= m@nostrum.com, dean.willis@softarmor.com, drage@alcatel-lucent.com > Cc: isly33@gmail.com, rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC3323 (5184) >=20 > The following errata report has been submitted for RFC3323, > "A Privacy Mechanism for the Session Initiation Protocol (SIP)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5184 >=20 > -------------------------------------- > Type: Technical > Reported by: DONG O YI >=20 > Section: 4.2 Expre... >=20 > Original Text > ------------- > Privacy-hdr =3D "Privacy" HCOLON priv-value *(";" priv-value) >=20 >=20 > Corrected Text > -------------- > Privacy-hdr =3D "Privacy" HCOLON priv-value *("," priv-value) >=20 >=20 > Notes > ----- > RFC3261 says,=20 >=20 > Specifically, any SIP header whose grammar is of the form >=20 > header =3D "header-name" HCOLON header-value *(COMMA header-value) >=20 > allows for combining header fields of the same name into a comma- > separated list. >=20 > So, RFC3323 conflicts RFC3261. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC3323 (draft-ietf-sip-privacy-general-01) > -------------------------------------- > Title : A Privacy Mechanism for the Session Initiation Proto= col (SIP) > Publication Date : November 2002 > Author(s) : J. Peterson > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG --Apple-Mail-6592039E-7380-4450-B44B-270379212C85 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi, 

Does anyon= e in sipcore have thoughts on this? 

Thanks,

Ben.

Begin forwarded message:

From: RFC Errata System <rfc-editor@rfc-editor.org>
<= b>Date: November 16, 2017 at 10:20:38 AM GMT+8
To: jon.peterson@neustar.biz, ben@nostrum.com, aamelnikov@fastmail.fm, ada= m@nostrum.com, dean.willis@= softarmor.com, drage@alcatel= -lucent.com
Cc: isly33@gma= il.com, rfc-editor@rfc-edit= or.org
Subject: [Technical Errata Reported] RFC3323 (5184)<= /b>

The follo= wing errata report has been submitted for RFC3323,
"A Privac= y Mechanism for the Session Initiation Protocol (SIP)".

--------------------------------------
You may r= eview the report below and at:
http://www.rfc-editor.org/errata/eid5184<= br>
--------------------------------------
<= span>Type: Technical
Reported by: DONG O YI <isly33@gmail.com>

= Section: 4.2 Expre...

Original Text
-------------
Privacy-hdr  =3D  "Pr= ivacy" HCOLON priv-value *(";" priv-value)

=
Corrected Text
--------------
Privacy-hdr  =3D  "Privacy" HCOLON priv-value *("," priv-value)=


Notes
---= --
RFC3261 says,

Specifica= lly, any SIP header whose grammar is of the form

=      header  =3D  "header-name" HC= OLON header-value *(COMMA header-value)

&n= bsp; allows for combining header fields of the same name into a comma-<= /span>
  separated list.

So, RFC3323 conflicts RFC3261.

Instructio= ns:
-------------
This erratum is currently p= osted as "Reported". If necessary, please
use "Reply All" to= discuss whether it should be verified or
rejected. When a d= ecision is reached, the verifying party  
can log in to= change the status and edit the report, if necessary.

--------------------------------------
RFC3323 (= draft-ietf-sip-privacy-general-01)
-------------------------= -------------
Title       &nbs= p;       : A Privacy Mechanism for the Se= ssion Initiation Protocol (SIP)
Publication Date   = ; : November 2002
Author(s)     &nb= sp;     : J. Peterson
Category &nbs= p;          : PROPOSED STA= NDARD
Source         = ;     : Session Initiation Protocol
Area            &nbs= p;   : Real-time Applications and Infrastructure
Stream            = ;  : IETF
Verifying Party     = : IESG
= --Apple-Mail-6592039E-7380-4450-B44B-270379212C85-- From nobody Thu Nov 16 17:47: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 B46F0124239 for ; Thu, 16 Nov 2017 17:47:27 -0800 (PST) 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 DNXT2i7MYP6W for ; Thu, 16 Nov 2017 17:47:25 -0800 (PST) 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 52A211267BB for ; Thu, 16 Nov 2017 17:47:25 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-6d-5a0e3fab7af4 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.B8.08439.BAF3E0A5; Fri, 17 Nov 2017 02:47:23 +0100 (CET) Received: from ESESSMB102.ericsson.se ([169.254.2.99]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Fri, 17 Nov 2017 02:47:22 +0100 From: Christer Holmberg To: Ben Campbell , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) Thread-Index: AQHTXz5Uw8dI58mDOEuhj94C2xcC0qMXzVaQ Date: Fri, 17 Nov 2017 01:47:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFDDA93@ESESSMB102.ericsson.se> References: <20171116022038.047B6B8104D@rfc-editor.org> <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> In-Reply-To: <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> 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_7594FB04B1934943A5C02806D1A2204B6BFDDA93ESESSMB102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdWHe1PV+Uwe97MhbzO0+zW3z9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mq4NK2sYENRxdk7X1kbGJfkdzFyckgImEhM XtPJ3MXIxSEkcJhR4tmkQ0wQzmJGid9vTwE5HBxsAhYS3f+0QRpEBDwlOh62s4HYwgJuEq03 Olgh4u5A8UYmCNtIomPadrAaFgFViXnXjoDV8Ar4Sqzo6wezhQRyJH6ePMIOYnMK2Es83HgG LM4oICbx/dQasDnMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWwliRXbLzFC1OdLNDbeZ4TY JShxcuYTlgmMwrOQjJqFpGwWkrJZQF8yC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWM osWpxUm56UbGeqlFmcnFxfl5enmpJZsYgbFzcMtv1R2Ml984HmIU4GBU4uG9a8kXJcSaWFZc mXuIUYKDWUmEt2Eib5QQb0piZVVqUX58UWlOavEhRmkOFiVx3pOeQCmB9MSS1OzU1ILUIpgs EwenVAOj+4ofgaE1XvcvJ2smNlZsUQ+/ITz5XkubUZh3pcwHnn2/zHtmfb5VX9Mu9iwg4KSf x/Fnr+awxR5d1Pn7kLeCi32JXSjToxucLYKNbqe3qzGIzdQ/9m/SO6u+zONMJZrzgu41FL/N V45nMI+78f+Owtc9r42msT8OPrduQ1mFLOuLLV9EqqcqsRRnJBpqMRcVJwIAk7OqApkCAAA= Archived-At: Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 17 Nov 2017 01:47:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6BFDDA93ESESSMB102erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gbG9va2luZyBpbnRvIHRoaXMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN CkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCZW4gQ2FtcGJlbGwNClNlbnQ6IDE3IE5vdmVtYmVyIDIwMTcgMDI6NTINClRvOiBzaXBj b3JlQGlldGYub3JnDQpTdWJqZWN0OiBbc2lwY29yZV0gRndkOiBbVGVjaG5pY2FsIEVycmF0YSBS ZXBvcnRlZF0gUkZDMzMyMyAoNTE4NCkNCg0KDQpIaSwNCg0KRG9lcyBhbnlvbmUgaW4gc2lwY29y ZSBoYXZlIHRob3VnaHRzIG9uIHRoaXM/DQoNClRoYW5rcywNCg0KQmVuLg0KDQpCZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZToNCkZyb206IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPj4NCkRhdGU6IE5vdmVt YmVyIDE2LCAyMDE3IGF0IDEwOjIwOjM4IEFNIEdNVCs4DQpUbzogam9uLnBldGVyc29uQG5ldXN0 YXIuYml6PG1haWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXo+LCBiZW5Abm9zdHJ1bS5jb208 bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4sIGFhbWVsbmlrb3ZAZmFzdG1haWwuZm08bWFpbHRvOmFh bWVsbmlrb3ZAZmFzdG1haWwuZm0+LCBhZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3Ry dW0uY29tPiwgZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbTxtYWlsdG86ZGVhbi53aWxsaXNAc29m dGFybW9yLmNvbT4sIGRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86ZHJhZ2VAYWxjYXRl bC1sdWNlbnQuY29tPg0KQ2M6IGlzbHkzM0BnbWFpbC5jb208bWFpbHRvOmlzbHkzM0BnbWFpbC5j b20+LCByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0 b3Iub3JnPg0KU3ViamVjdDogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzMzMjMgKDUx ODQpDQpUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBS RkMzMzIzLA0KIkEgUHJpdmFjeSBNZWNoYW5pc20gZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb24g UHJvdG9jb2wgKFNJUCkiLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQpodHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2VycmF0YS9laWQ1MTg0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpUeXBlOiBUZWNobmljYWwNClJlcG9ydGVkIGJ5OiBET05HIE8gWUkgPGlz bHkzM0BnbWFpbC5jb208bWFpbHRvOmlzbHkzM0BnbWFpbC5jb20+Pg0KDQpTZWN0aW9uOiA0LjIg RXhwcmUuLi4NCg0KT3JpZ2luYWwgVGV4dA0KLS0tLS0tLS0tLS0tLQ0KUHJpdmFjeS1oZHIgID0g ICJQcml2YWN5IiBIQ09MT04gcHJpdi12YWx1ZSAqKCI7IiBwcml2LXZhbHVlKQ0KDQoNCkNvcnJl Y3RlZCBUZXh0DQotLS0tLS0tLS0tLS0tLQ0KUHJpdmFjeS1oZHIgID0gICJQcml2YWN5IiBIQ09M T04gcHJpdi12YWx1ZSAqKCIsIiBwcml2LXZhbHVlKQ0KDQoNCk5vdGVzDQotLS0tLQ0KUkZDMzI2 MSBzYXlzLA0KDQpTcGVjaWZpY2FsbHksIGFueSBTSVAgaGVhZGVyIHdob3NlIGdyYW1tYXIgaXMg b2YgdGhlIGZvcm0NCg0KICAgICBoZWFkZXIgID0gICJoZWFkZXItbmFtZSIgSENPTE9OIGhlYWRl ci12YWx1ZSAqKENPTU1BIGhlYWRlci12YWx1ZSkNCg0KICBhbGxvd3MgZm9yIGNvbWJpbmluZyBo ZWFkZXIgZmllbGRzIG9mIHRoZSBzYW1lIG5hbWUgaW50byBhIGNvbW1hLQ0KICBzZXBhcmF0ZWQg bGlzdC4NCg0KU28sIFJGQzMzMjMgY29uZmxpY3RzIFJGQzMyNjEuDQoNCkluc3RydWN0aW9uczoN Ci0tLS0tLS0tLS0tLS0NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBv cnRlZCIuIElmIG5lY2Vzc2FyeSwgcGxlYXNlDQp1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3 aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lv biBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5DQpjYW4gbG9nIGluIHRvIGNoYW5nZSB0 aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJGQzMzMjMgKGRyYWZ0LWlldGYtc2lwLXBy aXZhY3ktZ2VuZXJhbC0wMSkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpUaXRsZSAgICAgICAgICAgICAgIDogQSBQcml2YWN5IE1lY2hhbmlzbSBmb3IgdGhlIFNlc3Np b24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKQ0KUHVibGljYXRpb24gRGF0ZSAgICA6IE5vdmVt YmVyIDIwMDINCkF1dGhvcihzKSAgICAgICAgICAgOiBKLiBQZXRlcnNvbg0KQ2F0ZWdvcnkgICAg ICAgICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQpTb3VyY2UgICAgICAgICAgICAgIDogU2Vzc2lv biBJbml0aWF0aW9uIFByb3RvY29sDQpBcmVhICAgICAgICAgICAgICAgIDogUmVhbC10aW1lIEFw cGxpY2F0aW9ucyBhbmQgSW5mcmFzdHJ1Y3R1cmUNClN0cmVhbSAgICAgICAgICAgICAgOiBJRVRG DQpWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0K --_000_7594FB04B1934943A5C02806D1A2204B6BFDDA93ESESSMB102erics_ 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 LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhbSBsb29raW5nIGludG8gdGhp cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBz aXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5CZW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gMTcgTm92ZW1iZXIgMjAxNyAwMjo1 Mjxicj4NCjxiPlRvOjwvYj4gc2lwY29yZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBb c2lwY29yZV0gRndkOiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDMzMyMyAoNTE4NCk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpIaSwm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMg YW55b25lIGluIHNpcGNvcmUgaGF2ZSB0aG91Z2h0cyBvbiB0aGlzPyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbi48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPkZyb206PC9iPiBSRkMgRXJyYXRhIFN5c3RlbSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciPnJmYy1lZGl0b3JAcmZjLWVkaXRvci5v cmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PC9iPiBOb3ZlbWJlciAxNiwgMjAxNyBhdCAxMDoyMDoz OCBBTSBHTVQmIzQzOzg8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb24ucGV0ZXJz b25AbmV1c3Rhci5iaXoiPmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpejwvYT4sDQo8YSBocmVmPSJt YWlsdG86YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1bS5jb208L2E+LCA8YSBocmVmPSJtYWls dG86YWFtZWxuaWtvdkBmYXN0bWFpbC5mbSI+DQphYW1lbG5pa292QGZhc3RtYWlsLmZtPC9hPiwg PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5jb208L2E+LA0K PGEgaHJlZj0ibWFpbHRvOmRlYW4ud2lsbGlzQHNvZnRhcm1vci5jb20iPmRlYW4ud2lsbGlzQHNv ZnRhcm1vci5jb208L2E+LCA8YSBocmVmPSJtYWlsdG86ZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29t Ij4NCmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzppc2x5MzNAZ21haWwuY29tIj5pc2x5MzNAZ21haWwuY29tPC9hPiwgPGEgaHJlZj0i bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciPg0KcmZjLWVkaXRvckByZmMtZWRpdG9y Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gPGI+W1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0 ZWRdIFJGQzMzMjMgKDUxODQpPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZm9sbG93aW5nIGVycmF0YSBy ZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkMzMzIzLDxicj4NCiZxdW90O0EgUHJpdmFj eSBNZWNoYW5pc20gZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkmcXVv dDsuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDo8YnI+DQo8YSBocmVmPSJo dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ1MTg0Ij5odHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2VycmF0YS9laWQ1MTg0PC9hPjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KVHlwZTogVGVjaG5pY2FsPGJyPg0KUmVwb3J0ZWQg Ynk6IERPTkcgTyBZSSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlzbHkzM0BnbWFpbC5jb20iPmlzbHkz M0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxicj4NClNlY3Rpb246IDQuMiBFeHByZS4uLjxicj4N Cjxicj4NCk9yaWdpbmFsIFRleHQ8YnI+DQotLS0tLS0tLS0tLS0tPGJyPg0KUHJpdmFjeS1oZHIg Jm5ic3A7PSAmbmJzcDsmcXVvdDtQcml2YWN5JnF1b3Q7IEhDT0xPTiBwcml2LXZhbHVlICooJnF1 b3Q7OyZxdW90OyBwcml2LXZhbHVlKTxicj4NCjxicj4NCjxicj4NCkNvcnJlY3RlZCBUZXh0PGJy Pg0KLS0tLS0tLS0tLS0tLS08YnI+DQpQcml2YWN5LWhkciAmbmJzcDs9ICZuYnNwOyZxdW90O1By aXZhY3kmcXVvdDsgSENPTE9OIHByaXYtdmFsdWUgKigmcXVvdDssJnF1b3Q7IHByaXYtdmFsdWUp PGJyPg0KPGJyPg0KPGJyPg0KTm90ZXM8YnI+DQotLS0tLTxicj4NClJGQzMyNjEgc2F5cywgPGJy Pg0KPGJyPg0KU3BlY2lmaWNhbGx5LCBhbnkgU0lQIGhlYWRlciB3aG9zZSBncmFtbWFyIGlzIG9m IHRoZSBmb3JtPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aGVhZGVy ICZuYnNwOz0gJm5ic3A7JnF1b3Q7aGVhZGVyLW5hbWUmcXVvdDsgSENPTE9OIGhlYWRlci12YWx1 ZSAqKENPTU1BIGhlYWRlci12YWx1ZSk8YnI+DQo8YnI+DQombmJzcDsmbmJzcDthbGxvd3MgZm9y IGNvbWJpbmluZyBoZWFkZXIgZmllbGRzIG9mIHRoZSBzYW1lIG5hbWUgaW50byBhIGNvbW1hLTxi cj4NCiZuYnNwOyZuYnNwO3NlcGFyYXRlZCBsaXN0Ljxicj4NCjxicj4NClNvLCBSRkMzMzIzIGNv bmZsaWN0cyBSRkMzMjYxLjxicj4NCjxicj4NCkluc3RydWN0aW9uczo8YnI+DQotLS0tLS0tLS0t LS0tPGJyPg0KVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1b3Q7UmVwb3J0 ZWQmcXVvdDsuIElmIG5lY2Vzc2FyeSwgcGxlYXNlPGJyPg0KdXNlICZxdW90O1JlcGx5IEFsbCZx dW90OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yPGJyPg0KcmVq ZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5ICZu YnNwOzxicj4NCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJl cG9ydCwgaWYgbmVjZXNzYXJ5LiA8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NClJGQzMzMjMgKGRyYWZ0LWlldGYtc2lwLXByaXZhY3ktZ2VuZXJh bC0wMSk8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRp dGxlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogQSBQcml2YWN5IE1lY2hhbmlzbSBmb3Ig dGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKTxicj4NClB1YmxpY2F0aW9uIERh dGUgJm5ic3A7Jm5ic3A7Jm5ic3A7OiBOb3ZlbWJlciAyMDAyPGJyPg0KQXV0aG9yKHMpICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzog Si4gUGV0ZXJzb248YnI+DQpDYXRlZ29yeSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IFBST1BPU0VEIFNUQU5EQVJEPGJy Pg0KU291cmNlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogU2Vzc2lvbiBJbml0aWF0aW9uIFByb3Rv Y29sPGJyPg0KQXJlYSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IFJlYWwtdGlt ZSBBcHBsaWNhdGlvbnMgYW5kIEluZnJhc3RydWN0dXJlPGJyPg0KU3RyZWFtICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzogSUVURjxicj4NClZlcmlmeWluZyBQYXJ0eSAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs6IElFU0c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B6BFDDA93ESESSMB102erics_-- From nobody Thu Nov 16 17:52: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 1C9B0126BF0 for ; Thu, 16 Nov 2017 17:52:57 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=team.neustar 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 pPxagLgcFuvY for ; Thu, 16 Nov 2017 17:52:54 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 B56A21267BB for ; Thu, 16 Nov 2017 17:52:54 -0800 (PST) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAH1ibbN002348; Thu, 16 Nov 2017 20:52:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=selector1; bh=U0u9DPXzh1ZAgGGOR74lzdQYGGyw8KOPsQ885HfhbIM=; b=IvOK68t3i67L207NSwpAwdH0WYinpxrE8gbfoafA21o+D7Nv254uhE8FO5Af92pFEc0x CDF5W5ZX7zO+AfrHrTA/5+Ii/5NEyfHmkhOTJA9tycrqieGiwRrY4vakL64gdYIGhEdm 8S5khwlQvuGV+RzeIutrXQrPJgvQsoKCbMtrGk/bZZ6R9Xql3CQvYhodl/C5xvpAF2gE BBLZ5Ihn+oexlHY4kf/i5gk/opORdqurFyy/RlUq909tmwYMBca6QOSC8jkNTmExu9kS fSy6pELceYgRPcRe1ezBKYe17aOWk/nJxsXB6zF5RFGms2FPrHrcIBGZBfUsPpCYSc03 8Q== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2e8d7tnh77-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Nov 2017 20:52:52 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.47]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 16 Nov 2017 20:52:51 -0500 From: "Peterson, Jon" To: Ben Campbell CC: "sipcore@ietf.org" Thread-Topic: [EXTERNAL] [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) Thread-Index: AQHTXz5WEOa65Sy5F0KRdLDd7zHwvaMXzxAR Date: Fri, 17 Nov 2017 01:52:50 +0000 Message-ID: <21D88006-5EB7-44F9-A12C-EBA477E253AC@team.neustar> References: <20171116022038.047B6B8104D@rfc-editor.org>, <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> In-Reply-To: <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_21D880065EB744F9A12CEBA477E253ACteamneustar_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound 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-1709140000 definitions=main-1711170023 Archived-At: Subject: Re: [sipcore] [EXTERNAL] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 17 Nov 2017 01:52:57 -0000 --_000_21D880065EB744F9A12CEBA477E253ACteamneustar_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC3323 did not manage multiple values for the Privacy header in the way th= at passage in RFC3261 explicitly allows. But I don't read RFC3261 as requir= ing that all headers that admit of multiple values MUST use comma separatio= n rather than semicolon separation. It might be a one-off but in what sense= is this a bug? Jon Peterson Neustar, Inc. On Nov 17, 2017, at 8:52 AM, Ben Campbell > wrote: Hi, Does anyone in sipcore have thoughts on this? Thanks, Ben. Begin forwarded message: From: RFC Errata System > Date: November 16, 2017 at 10:20:38 AM GMT+8 To: jon.peterson@neustar.biz, ben@nostrum.= com, aamelnikov@fastmail.fm, adam@nostrum.com, dean.willis@softarmor.c= om, drage@alcatel-lucent.com Cc: isly33@gmail.com, rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC3323 (5184) The following errata report has been submitted for RFC3323, "A Privacy Mechanism for the Session Initiation Protocol (SIP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5184 -------------------------------------- Type: Technical Reported by: DONG O YI > Section: 4.2 Expre... Original Text ------------- Privacy-hdr =3D "Privacy" HCOLON priv-value *(";" priv-value) Corrected Text -------------- Privacy-hdr =3D "Privacy" HCOLON priv-value *("," priv-value) Notes ----- RFC3261 says, Specifically, any SIP header whose grammar is of the form header =3D "header-name" HCOLON header-value *(COMMA header-value) allows for combining header fields of the same name into a comma- separated list. So, RFC3323 conflicts RFC3261. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3323 (draft-ietf-sip-privacy-general-01) -------------------------------------- Title : A Privacy Mechanism for the Session Initiation Protoc= ol (SIP) Publication Date : November 2002 Author(s) : J. Peterson Category : PROPOSED STANDARD Source : Session Initiation Protocol Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_21D880065EB744F9A12CEBA477E253ACteamneustar_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
RFC3323 did = not manage multiple values for the Privacy header in the way that passage i= n RFC3261 explicitly allows. But I don't read RFC3261 as requiring that all= headers that admit of multiple values MUST use comma separation rather than semicolon separation. It might be a = one-off but in what sense is this a bug?

Jon Peterson=
Neustar, Inc= .

On Nov 17, 2017, at 8:52 AM, Ben Campbell <ben@nostrum.com> wrote:


Hi, 

Does anyone in sipcore have thoughts on this? 

Thanks,

Ben.

Begin forwarded message:

From: RFC Errata System <rfc-editor@rfc-editor.org>
Date: November 16, 2017 at 10:20:38 AM GMT+8
To: jon.peterson@neustar= .biz, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostru= m.com, dean.willis@softarmor.com,= drage@alcatel-lucent.com
Cc: isly33@gmail.com, rfc-editor@rfc-editor.org
Subject: [Technical Errata Reported] RFC3323 (5184)

The following errata report has been submitted for RFC3323,
"A Privacy Mechanism for the Session Initiation Protocol (SIP)&q= uot;.

--------------------------------------
You may review the report below and at:
http://www.rfc-e= ditor.org/errata/eid5184

--------------------------------------
Type: Technical
Reported by: DONG O YI <isly33= @gmail.com>

Section: 4.2 Expre...

Original Text
-------------
Privacy-hdr  =3D  "Privacy" HCOLON priv-value *(&= quot;;" priv-value)


Corrected Text
--------------
Privacy-hdr  =3D  "Privacy" HCOLON priv-value *(&= quot;," priv-value)


Notes
-----
RFC3261 says,

Specifically, any SIP header whose grammar is of the form

     header  =3D  "header-nam= e" HCOLON header-value *(COMMA header-value)

  allows for combining header fields of the same name into = a comma-
  separated list.

So, RFC3323 conflicts RFC3261.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessar= y, please
use "Reply All" to discuss whether it should be verified or=
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC3323 (draft-ietf-sip-privacy-general-01)
--------------------------------------
Title           &nb= sp;   : A Privacy Mechanism for the Session Initiation Proto= col (SIP)
Publication Date    : November 2002
Author(s)           = ;: J. Peterson
Category           =  : PROPOSED STANDARD
Source           &n= bsp;  : Session Initiation Protocol
Area           &nbs= p;    : Real-time Applications and Infrastructure
Stream           &n= bsp;  : IETF
Verifying Party     : IESG
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_21D880065EB744F9A12CEBA477E253ACteamneustar_-- From nobody Thu Nov 16 21:59: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 9CC83128961 for ; Thu, 16 Nov 2017 21:58:58 -0800 (PST) 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 KNHZ1AQX68aB for ; Thu, 16 Nov 2017 21:58:56 -0800 (PST) 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 9BB5012895E for ; Thu, 16 Nov 2017 21:58:56 -0800 (PST) X-AuditID: 1207440d-853ff70000000f42-98-5a0e7a9d049e 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 F2.AC.03906.E9A7E0A5; Fri, 17 Nov 2017 00:58:54 -0500 (EST) 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 vAH5wnmn032345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 17 Nov 2017 00:58:52 -0500 To: sipcore@ietf.org References: <20171116022038.047B6B8104D@rfc-editor.org> <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> From: Paul Kyzivat Message-ID: Date: Fri, 17 Nov 2017 00:58:49 -0500 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: <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixO6iqDu/ii/KYNF1QYuvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48eL8ILPMhUNR7+xNjBOl+hi5OSQEDCRmHRqIXsXIxeHkMAO Jombl/sZIZwfTBLti76zgFQJC7hJfHhzjhnEFhEQkXg2/R8biC0kkCPx8+QRdhCbTUBLYs6h /0D1HBy8AvYSLQuTQMIsAqoSm3dvYQSxRQXSJO7MeMgEYvMKCEqcnPkEbDwnUPnDjWdYQWxm ATOJeZsfMkPY4hK3nsxngrDlJZq3zmaewMg/C0n7LCQts5C0zELSsoCRZRWjXGJOaa5ubmJm TnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGSEjy7mD8v07mEKMAB6MSD2/GMd4oIdbEsuLK3EOM khxMSqK8POZ8UUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeNnygXK8KYmVValF+TApaQ4WJXFe tSXqfkIC6YklqdmpqQWpRTBZGQ4OJQle00qgRsGi1PTUirTMnBKENBMHJ8hwHqDhYiA1vMUF ibnFmekQ+VOMlhw9PTf+MHGsun4XSD6b+bqBWYglLz8vVUqc1x+kQQCkIaM0D24mLMW8YhQH elGY93cFUBUPMD3BTX0FtJAJaKHNDW6QhSWJCCmpBkaPQyXaJct0/kiGphhE7XaezKWe+M9w guvW34mLhN0rSoJtpkxk39W80DC/uCbtM3O07cQXc9TP63rdV/cxcpCx55v104Wh+dodA5Ef jLcF7XWmX7gyb1GHYO6Ks+zHlGcdX8X7PI/t0tO32i8n/XlbbNmbkGotasuxWrjb2UdGvzWp +7vCZiWW4oxEQy3mouJEAFAy1tcMAwAA Archived-At: Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 17 Nov 2017 05:58:59 -0000 On 11/16/17 7:52 PM, Ben Campbell wrote: > > Hi, > > Does anyone in sipcore have thoughts on this? Yes. Inline. > Thanks, > > Ben. > > Begin forwarded message: > >> *From:* RFC Errata System > > >> *Date:* November 16, 2017 at 10:20:38 AM GMT+8 >> *To:* jon.peterson@neustar.biz , >> ben@nostrum.com , aamelnikov@fastmail.fm >> , adam@nostrum.com >> , dean.willis@softarmor.com >> , drage@alcatel-lucent.com >> >> *Cc:* isly33@gmail.com , >> rfc-editor@rfc-editor.org >> *Subject:* *[Technical Errata Reported] RFC3323 (5184)* >> >> The following errata report has been submitted for RFC3323, >> "A Privacy Mechanism for the Session Initiation Protocol (SIP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5184 >> >> -------------------------------------- >> Type: Technical >> Reported by: DONG O YI > >> >> Section: 4.2 Expre... >> >> Original Text >> ------------- >> Privacy-hdr  =  "Privacy" HCOLON priv-value *(";" priv-value) >> >> >> Corrected Text >> -------------- >> Privacy-hdr  =  "Privacy" HCOLON priv-value *("," priv-value) >> >> >> Notes >> ----- >> RFC3261 says, >> >> Specifically, any SIP header whose grammar is of the form >> >>      header  =  "header-name" HCOLON header-value *(COMMA header-value) >> >>   allows for combining header fields of the same name into a comma- >>   separated list. >> >> So, RFC3323 conflicts RFC3261. Well... ISTM that the syntax *ought* to have been: Privacy-hdr = "Privacy" HCOLON priv-value *(COMMA priv-value) for stylistic consistency with other similar header fields. But as written it doesn't *conflict* with the referenced section - it simply doesn't qualify as an example of that. And if it was explicitly intended to use semicolon (hence following the typical parameter syntax) then it *should* have been: Privacy-hdr = "Privacy" HCOLON priv-value *(SEMI priv-value) BUT given the late date that this has come to light much concern must be paid to what has been deployed. I looked (not very hard) for published examples that have multiple privacy values, but didn't find any. Thanks, Paul >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3323 (draft-ietf-sip-privacy-general-01) >> -------------------------------------- >> Title               : A Privacy Mechanism for the Session Initiation >> Protocol (SIP) >> Publication Date    : November 2002 >> Author(s)           : J. Peterson >> Category            : PROPOSED STANDARD >> Source              : Session Initiation Protocol >> Area                : Real-time Applications and Infrastructure >> Stream              : IETF >> Verifying Party     : IESG > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Nov 17 01:52: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 2C9D8126C25 for ; Fri, 17 Nov 2017 01:52:47 -0800 (PST) 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 Wkft2ru_Qirz for ; Fri, 17 Nov 2017 01:52:45 -0800 (PST) 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 88F3C124D6C for ; Fri, 17 Nov 2017 01:52:45 -0800 (PST) X-AuditID: c1b4fb30-df9f99c000002554-43-5a0eb16beaf2 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 96.57.09556.B61BE0A5; Fri, 17 Nov 2017 10:52:43 +0100 (CET) Received: from ESESSMB102.ericsson.se ([169.254.2.99]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Fri, 17 Nov 2017 10:52:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) Thread-Index: AQHTXz5Uw8dI58mDOEuhj94C2xcC0qMYAwaAgABQrCA= Date: Fri, 17 Nov 2017 09:52:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFE453C@ESESSMB102.ericsson.se> References: <20171116022038.047B6B8104D@rfc-editor.org> <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.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+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7sW72Rr4og/03DSxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjwsLrLAVHWCqWbNnN1sC4haWLkZNDQsBE oun8V+YuRi4OIYHDjBJ7ty9hhXAWM0qserAVKMPBwSZgIdH9TxukQUQgUOLqkgnMILawgJtE 640OVoi4u0THw0YmCNtKYs68z2A2i4CqxOq5e8BsXgFfictLDzNCzF/EKNG95SRYM6eAg8ST JZvAbEYBMYnvp9aANTALiEvcejKfCeJSAYkle84zQ9iiEi8f/2OFsJUkFt0GWcYBVK8psX6X PkSrosSU7ofsEHsFJU7OfMIygVFkFpKpsxA6ZiHpmIWkYwEjyypG0eLU4qTcdCMjvdSizOTi 4vw8vbzUkk2MwGg4uOW3wQ7Gl88dDzEKcDAq8fAyrOGLEmJNLCuuzD3EKMHBrCTCO2M5UIg3 JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgsEwenVAPjokpZ3b4XU8XL ovY4fPG76bzXIs7u6927LE0bHkyYecxB5+mnUwyypp9jo371/NksnKkltZqXZc/XjQEyeoV3 OdbOO68d/pRNV7t+n9m8DQHrhPu3L+RuqL6X68FzZUP5jymMHxnPKElkze/fdf7+8r+e0k9P m7YJuSQ43Gzlm9o1u4jn9/IyJZbijERDLeai4kQAU+HPpIICAAA= Archived-At: Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 17 Nov 2017 09:52:47 -0000 SGksDQoNCi4uLg0KDQo+IEJVVCBnaXZlbiB0aGUgbGF0ZSBkYXRlIHRoYXQgdGhpcyBoYXMgY29t ZSB0byBsaWdodCBtdWNoIGNvbmNlcm4gbXVzdCBiZSBwYWlkIHRvIHdoYXQgaGFzIGJlZW4gDQo+ IGRlcGxveWVkLiBJIGxvb2tlZCAobm90IHZlcnkgaGFyZCkgZm9yIHB1Ymxpc2hlZCBleGFtcGxl cyB0aGF0IGhhdmUgbXVsdGlwbGUgcHJpdmFjeSB2YWx1ZXMsIGJ1dCBkaWRuJ3QgZmluZCBhbnku DQoNCkkgYmVsaWV2ZSB0aGVyZSBhcmUgY2FzZXMgd2l0aCBtdWx0aXBsZSB2YWx1ZXMuIEl0J3Mg YSBsaXR0bGUgZGlmZmljdWx0IGZvciBtZSB0byBsb29rIGZvciB0aGVtIHdoaWxlIGluIFNpbmdh cG9yZSwgYnV0IG9uY2UgSSdtIGJhY2sgaW4gb2ZmaWNlIGl0IHdpbGwgYmUgZWFzaWVyLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Fri Nov 17 02:11: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 0424A127369 for ; Fri, 17 Nov 2017 02:11:09 -0800 (PST) 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_H4=-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=3t+f/xA5; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=Uz59rS1j 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 ECaAg7FxQJyh for ; Fri, 17 Nov 2017 02:11:01 -0800 (PST) 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 AF350129471 for ; Fri, 17 Nov 2017 02:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1510913452; x=1542449452; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xrpwhD3Zbq0dQKkxWbH6MdUV+om84HpWwhi0s+bl0Fs=; b=3t+f/xA5RI0vlBOyKJVKFKiJ0h/3hwB+v1kQlVYfpr7cIxsHUDbLeonR 1pvqfBLbg8Ppiy3XhCNWXcryQYOeIRBNqOJpreQm4e5+xPErGry7p23YJ bqk3rveciufLZ8RClhSSajjBppj+ft1guA37YBsDI5Ds1iKPRuqOGLD7L vWtcUc/23saOczW6p+A+KeUYLDOra5vzKlwTy2+NDlNfvQw6YJJxF5a0n rTHsd6ipfeGuzyGpyN1YslUEaCWifDjA0SF+bv44o/W/JFM3vzp2B5bSs Oho3yyZSlgmz3DqKBSCX5QP+XkuBm4cR8mh9jUD6b794quLD7C8nYlGv+ A==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2017 11:10:50 +0100 X-IronPort-AV: E=Sophos;i="5.44,408,1505772000"; d="scan'208";a="66846449" Received: from he101953.emea1.cds.t-internal.com ([10.169.118.78]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 17 Nov 2017 11:10:36 +0100 Received: from HE105711.EMEA1.cds.t-internal.com (10.169.118.42) by HE101953.emea1.cds.t-internal.com (10.169.118.78) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 17 Nov 2017 11:10:36 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105711.EMEA1.cds.t-internal.com (10.169.118.42) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 17 Nov 2017 11:10:36 +0100 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; Fri, 17 Nov 2017 11:10:17 +0100 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=xrpwhD3Zbq0dQKkxWbH6MdUV+om84HpWwhi0s+bl0Fs=; b=Uz59rS1jBaZl6gqnX/A2cTBl8qtmYWanZZ5PFORH0R1F+yLIRoN5ddbS6c+/oc8cQNib8aczMulPr3aTWbxG2UMrtLJzNusB4n6R8s9kwCWt7cVXE3Odzefk5ETSDWWKGZJg5pdrm6qG29X+bAVI+HuUddyzvvlcqlyIWUfSENo= 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.239.5; Fri, 17 Nov 2017 10:10:32 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0239.007; Fri, 17 Nov 2017 10:10:32 +0000 From: To: , , Thread-Topic: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) Thread-Index: AQHTXz5Yv0IggD3uVEGBm+iOLD8MeaMYE8mAgABBUgCAAATGoA== Date: Fri, 17 Nov 2017 10:10:32 +0000 Message-ID: References: <20171116022038.047B6B8104D@rfc-editor.org> <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6BFE453C@ESESSMB102.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6BFE453C@ESESSMB102.ericsson.se> 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.22] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0484; 6:GQcRgW/ebvisqin+lGWKANyIakZIg7GVXcuPWkiA1vvuYSF/PdB4XIb7M7NRmgf67x+6ARDmXFVdAwc1sMCc2AfEmtVWorAsVm/Waf3cyTyNT3Hv33gS86eoM7BEg9uUUxhri1AxuyEdNxTUs8/snEscDAdD5H94B6jc0ws1Aaj5rn94WszR1NKOXvu9nonBqsF+1DtztL2uXjM1kyRI7KQlK7s1OtkHHCPKVLHdD/WEiHWQGGq0pkaiXk1fbJkyiQ6VLl84EfOmAdRtmhvPgyoCVkulL4q+hCmm2j8EEFEbtXHeGDpmRJ/SKRZv3TI3IwPFXNfGOP2HueYQ+Ei8CAOmlnVba7uhVcK8oNSA0zE=; 5:+xIYFgNO/H50b8zEgHmkwcZ8yiMpY/RSHhY4hmvvGVxzrTUgA+NAU24ReX+WLdEOXJmbTB/XdyrbOMqreluIQRgvfvNSxqKTpUH8nYFiM/P6s3n4fiLP1p7tJ9YSXIj1lNi0xNgKh5dc5R88euFzPTMt+eWhbYLdektCceLu3vM=; 24:Rn01UEHIGXhOeoxP9oXX5fpEBiSKqsHZAuKrQpsjRKl9ng/b3kj5lqaRPmW3YNTTAgvQwBGZyIMjko9l7Dx1tdT00LFesYbt6fPS3ymPHI0=; 7:lXRRZkW+c/1Rv9gjdR1Nyk7yfCUYJNyXt1ZyBVj6zZd6yTuhtWWFBhOZaYLqibXSCMqRtcU8ueHCyp33lqrE8OzxFsOf5ChtzrWc1f7iVm+yUHLrb+CNSLozpeouXul+XVGM2r8o8M4UUwWTh196BTRn2WxPehpyuZKUzKu9EAcOiBN/t9lD3fVMJLuWeXbWqLgz7T77M1qXoQNmP7uEqGUJeJ+wg3FDvReewl/JBX6mHBAczFIzkZ4pDYDbDavo x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ad87a7fc-dd80-4b77-3d54-08d52da37029 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:FRAPR01MB0484; x-ms-traffictypediagnostic: FRAPR01MB0484: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3231022)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(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: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(55016002)(2501003)(50986999)(478600001)(6116002)(76176999)(5250100002)(102836003)(54356999)(3846002)(81156014)(8676002)(81166006)(101416001)(3280700002)(189998001)(14454004)(110136005)(7736002)(305945005)(2906002)(2950100002)(33656002)(75402003)(72206003)(316002)(86362001)(7696004)(3660700001)(74482002)(97736004)(2900100001)(2171002)(68736007)(105586002)(106356001)(66066001)(53936002)(5660300001)(9686003)(8936002)(93886005)(6306002)(966005); 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: ad87a7fc-dd80-4b77-3d54-08d52da37029 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 10:10:32.6681 (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] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 17 Nov 2017 10:11:09 -0000 Hi, I have asked my guys to forward me how we have the done the implementation. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer > Holmberg > Gesendet: Freitag, 17. November 2017 10:53 > An: Paul Kyzivat ; sipcore@ietf.org > Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) >=20 > Hi, >=20 > ... >=20 > > BUT given the late date that this has come to light much concern must > > be paid to what has been deployed. I looked (not very hard) for publish= ed > examples that have multiple privacy values, but didn't find any. >=20 > I believe there are cases with multiple values. It's a little difficult f= or me to look > for them while in Singapore, but once I'm back in office it will be easie= r. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Nov 17 02:31: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 730C21293D6 for ; Fri, 17 Nov 2017 02:31:22 -0800 (PST) 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_H4=-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=qDrVeDZd; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=N7Y7I+fr 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 hDlhBE7yc0Cd for ; Fri, 17 Nov 2017 02:31:20 -0800 (PST) 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 BB2421292FC for ; Fri, 17 Nov 2017 02:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1510914679; x=1542450679; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=J1ClIOBowq9VICfWHrZW5rD0kcWFa4wBvVI6gcU3tH8=; b=qDrVeDZdEd5rbZ5xOsyq0JhaSLzPSBjH47NAFc4vaZ31iZKoiHNYHtJq vwptzmEEHaMa2hf8BWSprIE0j4eWPMF5SD20+byAGssP9QTcVy6cPMMYv aKDLZdfO0b+wKTTChN7PPY9LCRJKZH8NkTrjsj09xcmo2q/arzeHiLkuv kdK3IrruC0KrwcryOQ9YgbYCMGEFW8ogYDqJBtUn29TzMiw/1gNM9E+N6 b/fd6A+Zz3q49Y5pw8a9ZsimXrRXnjnGvVpd1nEaccxUgyZ8ExSqCu9PF hUjGmbk+x6xF/2OG2lcLmKBMcfxRn1vGi2EBkw0gtxttlDqBEwRikb0Qw A==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2017 11:31:16 +0100 X-IronPort-AV: E=Sophos;i="5.44,408,1505772000"; d="scan'208";a="1424549250" Received: from he101942.emea1.cds.t-internal.com ([10.169.119.82]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 17 Nov 2017 11:31:09 +0100 Received: from HE105689.EMEA1.cds.t-internal.com (10.169.119.67) by HE101942.emea1.cds.t-internal.com (10.169.119.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 17 Nov 2017 11:31:08 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105689.EMEA1.cds.t-internal.com (10.169.119.67) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 17 Nov 2017 11:31:08 +0100 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.1347.2; Fri, 17 Nov 2017 11:30:32 +0100 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=J1ClIOBowq9VICfWHrZW5rD0kcWFa4wBvVI6gcU3tH8=; b=N7Y7I+frggYo26OtsnueY0UO+RdRSjIn6xxLJNCjmVhFRtUcQ7z4r0SuMXpo6zDD1gEJUJKIGrdgl0BjI1/mwcCSQGEGCg2HN/7AhpKgUCO82KGXM0oXhyAmFCGFRiOqYUlgwTibh4rNRYCM+VnbMC/9SJ3LfCKb658EneCgGMo= 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.239.5; Fri, 17 Nov 2017 10:31:07 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0239.007; Fri, 17 Nov 2017 10:31:07 +0000 From: To: , , Thread-Topic: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) Thread-Index: AQHTXz5Yv0IggD3uVEGBm+iOLD8MeaMYE8mAgABBUgCAAATGoIAABOkg Date: Fri, 17 Nov 2017 10:31:07 +0000 Message-ID: References: <20171116022038.047B6B8104D@rfc-editor.org> <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6BFE453C@ESESSMB102.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.22] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0483; 6:m10Adk7FlyphwM/S7SyNR2fLPAcSYC9Mfetmv3cMKW3Tme+hyuwyXCgyzlOSTSlgl9qP/5RuekitltTQp2WOHyc5JkZpbmHz9wfdlzJkcnsg8Ev69qjL4eyC7Xyp/0Moaan+sbBfJO31AB1oEyOzzlr9R1F0Q0pk6//9q71x6GowAa1HErMvASnjzUt01yYaeOO23FXphM/Zjny7ef9LQPdd2eXswl7TddImxBYwnJ8Idq4JDUWTqL23GHkAOD5/1BoGS8/WCHdQbUo1m8qIKCU/RY1t8SQBm143HdohOGUb4BphT+98O6HnWz7FTevvE2fg/POh4v3DYZHckFDezuAp6A1Flj1DN4Tecz8Gcyg=; 5:3kE+IRD7ufyAiH5MucZlsZcidEGX+Zhlkqj1roASYR0QfhnT0T9T9oLVWsQh1iF+/X/n0CAb9T7Mo5vjmnvQTlSo8rprIuVI4l4XmZMzgZ/W1gc/n9p5EcZXTvj9k6/syel8zkbIjU/jjAxsqOBk9aFUbIDq0Mm913deASLOIMM=; 24:CBB4RUKHU7deVj1U3bHpv40zZhLEJHlV/MbbQ26wQPKCIgDDJdbqhlyxD57iwirJOGrDydR/47gdSU8vmA7lbzur/N64JgqBzoJsyOE4jEg=; 7:Kmwtu9V0iCpO3G/kS3S9+xBuuEmTx8U/3o8GNKXsOz3VmeijCp9BMBNejKUhTHzgMiFA5meB8MAn+x4Hi0NA7t2dqEGgrb5//7U5jxMuGaFWsxuUiZUYZgxpYxt/viY7zoa9jzeqyMw3r4ublqqPhUqIE0vGsXWx5xdf0r6XhviJcZjZMiLkEddY5ZofCWll8yIPG4OJ9CWyDmVl1YuETFya17SdwB941IkiBK5Tfj4VphpYpmVRbKTxr7zohEqp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 31d7a6cb-01ae-45d7-5ada-08d52da65058 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:FRAPR01MB0483; x-ms-traffictypediagnostic: FRAPR01MB0483: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231022)(100000703101)(100105400095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(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: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(97736004)(66066001)(33656002)(2201001)(2906002)(305945005)(81166006)(81156014)(8676002)(53936002)(5250100002)(2900100001)(101416001)(55016002)(3846002)(102836003)(189998001)(74482002)(6116002)(9686003)(5660300001)(6306002)(2950100002)(93886005)(2501003)(68736007)(2940100002)(7696004)(966005)(106356001)(8936002)(14454004)(7736002)(105586002)(478600001)(72206003)(110136005)(3660700001)(86362001)(3280700002)(2171002)(76176999)(75402003)(50986999)(54356999)(316002); 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 31d7a6cb-01ae-45d7-5ada-08d52da65058 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 10:31:07.7644 (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] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 17 Nov 2017 10:31:22 -0000 Hi, it was faster than expected. So we are separating with semicolon. Like: Privacy: header;id;user So I would not propose to change anything. It will not be backwards compatible. And I assume we will get in trouble wh= en: Privacy: header,id,user appear. PS: It is a implementation from Christer's company. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Jesske, Rol= and > Gesendet: Freitag, 17. November 2017 11:11 > An: christer.holmberg@ericsson.com; pkyzivat@alum.mit.edu; sipcore@ietf.o= rg > Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) >=20 > Hi, > I have asked my guys to forward me how we have the done the > implementation. >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer > > Holmberg > > Gesendet: Freitag, 17. November 2017 10:53 > > An: Paul Kyzivat ; sipcore@ietf.org > > Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) > > > > Hi, > > > > ... > > > > > BUT given the late date that this has come to light much concern > > > must be paid to what has been deployed. I looked (not very hard) for > > > published > > examples that have multiple privacy values, but didn't find any. > > > > I believe there are cases with multiple values. It's a little > > difficult for me to look for them while in Singapore, but once I'm back= in > office it will be easier. > > > > Regards, > > > > Christer > > > > _______________________________________________ > > 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 Fri Nov 17 18:54: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 01765126D0C for ; Fri, 17 Nov 2017 18:54:58 -0800 (PST) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 7z3yfGgwNJe9 for ; Fri, 17 Nov 2017 18:54:56 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B62126BF3 for ; Fri, 17 Nov 2017 18:54:56 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id FtHJediEshVw8FtHTeAR6f; Sat, 18 Nov 2017 02:54:55 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-13v.sys.comcast.net with SMTP id FtHSeYzzHbSXWFtHSeJzNj; Sat, 18 Nov 2017 02:54:55 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id vAI2srAG015172; Fri, 17 Nov 2017 21:54:53 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vAI2srHb015169; Fri, 17 Nov 2017 21:54:53 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ben Campbell Cc: sipcore@ietf.org In-Reply-To: <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> (ben@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 17 Nov 2017 21:54:53 -0500 Message-ID: <87ine8fg8y.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOMM3logH5qiwCAGzl04J08fpJoQWOli/f4fjssUYwzm9kbobqf/JvCUnpTq94LidlPYqY+uWkHCIJtTZv1FdaddyrHIhuWK2ZYPlQe/JN5v4vZ3TQ8u vwGKMJbX38IDzPbdV6jH0wdM0zAFRUOOpYvCeSlyxu3JrvCLNxXZngUGhyXP7rUHOv9rq6XfebmNew== Archived-At: Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 18 Nov 2017 02:54:58 -0000 >> The following errata report has been submitted for RFC3323, >> "A Privacy Mechanism for the Session Initiation Protocol (SIP)". >> Original Text >> ------------- >> Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value) >> >> >> Corrected Text >> -------------- >> Privacy-hdr = "Privacy" HCOLON priv-value *("," priv-value) My suspicion is that the syntax with semicolon was chosen specifically to prevent the rule for combining header fields from being applicable. This ensures that if the UA sends a single Privacy header with multiple values, no intermediary can split it into multiple Privacy headers. (The text only speaks of a single Privacy header, never multiple ones.) But as Paul says, (1) it should be SEMI and (2) we must pay attention to what has been deployed. Dale From nobody Fri Nov 17 21:40: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 3F366120726 for ; Fri, 17 Nov 2017 21:40:17 -0800 (PST) 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 DtWOHYxFxwac for ; Fri, 17 Nov 2017 21:40:15 -0800 (PST) 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 E77FF124BE8 for ; Fri, 17 Nov 2017 21:40:14 -0800 (PST) X-AuditID: c1b4fb2d-f23ff70000001e3d-c0-5a0fc7bccff3 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.13.07741.CB7CF0A5; Sat, 18 Nov 2017 06:40:13 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sat, 18 Nov 2017 06:40:12 +0100 From: Christer Holmberg To: "R.Jesske@telekom.de" , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) Thread-Index: AQHTXz5Uw8dI58mDOEuhj94C2xcC0qMYAwaAgABQrCD///WoAIAABcCAgAE5gYA= Date: Sat, 18 Nov 2017 05:40:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFF74C5@ESESSMB109.ericsson.se> References: <20171116022038.047B6B8104D@rfc-editor.org> <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6BFE453C@ESESSMB102.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7tO7e4/xRBqf3cVqs2HCA1aLpTheb xdcfm9gcmD3+vv/A5LFkyU8mj7aXCgHMUVw2Kak5mWWpRfp2CVwZOz68YSm4L1wxd8IulgbG v/xdjJwcEgImEj0rtrB2MXJxCAkcZpRYvvIzG4SzhFFi+sY9jF2MHBxsAhYS3f+0QeIiAp2M Ei8ftjCCdAsLuEm03uhgBbFFBNwlOh42MkHYfhL/vjewgNgsAqoSC7ZsAYvzCvhK/F62kBFi QRezxJvDt9lBEpwCMRKvl8xkBrEZBcQkvp9aA9bALCAucevJfCaIUwUkluw5zwxhi0q8fPyP FcJWklh7eDsLRL2exI2pU9ggbG2JZQtfM0MsFpQ4OfMJywRGkVlIxs5C0jILScssJC0LGFlW MYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRGycEtv3V3MK5+7XiIUYCDUYmHd+NR/igh1sSy 4srcQ4wSHMxKIrwzlvNFCfGmJFZWpRblxxeV5qQWH2KU5mBREuc96ckbJSSQnliSmp2aWpBa BJNl4uCUamCc8P2lbncA96IOR6sLXJ90V1k+Wz6nZ8/ewIVPV7xKOH7p1YXernmHFV8VVsQk l5y4u4avofcSY438vIpvylezDz3iEV91K/UYa7MPA0O4d8aOGzvX8wTyc6m33/nGImcUe8nZ N7TvzE4jp1sXBQTszcy6Nxu5ns1zWyqmJiarO/vntWWBvTuUWIozEg21mIuKEwFCV5kBjgIA AA== Archived-At: Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 18 Nov 2017 05:40:17 -0000 Hi, >it was faster than expected. >So we are separating with semicolon. >Like: >Privacy: header;id;user > >So I would not propose to change anything. >It will not be backwards compatible. And I assume we will get in trouble w= hen: >Privacy: header,id,user appear. > >PS: It is a implementation from Christer's company. Luckily I got the same feedback from our product people :) So, I don't think we should change anything. I don't even think the intention ever was to allow multiple instances of th= e Privacy header field. What would the semantics of having multiple header = field instances be?=20 For headers where we DO allow multiple instances (whether the header field = values are comma separated within a single header instance, or in separate = header instances) there is clear semantics for that. E.g., Contact, Record-= Route, Route, Via etc. Regards, Christer > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Jesske,=20 > Roland > Gesendet: Freitag, 17. November 2017 11:11 > An: christer.holmberg@ericsson.com; pkyzivat@alum.mit.edu;=20 > sipcore@ietf.org > Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) >=20 > Hi, > I have asked my guys to forward me how we have the done the=20 > implementation. >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von=20 > > Christer Holmberg > > Gesendet: Freitag, 17. November 2017 10:53 > > An: Paul Kyzivat ; sipcore@ietf.org > > Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323=20 > > (5184) > > > > Hi, > > > > ... > > > > > BUT given the late date that this has come to light much concern=20 > > > must be paid to what has been deployed. I looked (not very hard)=20 > > > for published > > examples that have multiple privacy values, but didn't find any. > > > > I believe there are cases with multiple values. It's a little=20 > > difficult for me to look for them while in Singapore, but once I'm=20 > > back in > office it will be easier. > > > > Regards, > > > > Christer > > > > _______________________________________________ > > 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 Sat Nov 18 01:35: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 96708126C26 for ; Sat, 18 Nov 2017 01:35:45 -0800 (PST) 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 EjQAzR_e8OiD for ; Sat, 18 Nov 2017 01:35:43 -0800 (PST) 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 8F87212421A for ; Sat, 18 Nov 2017 01:35:43 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-a0-5a0ffeeda12b Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.95.08439.DEEFF0A5; Sat, 18 Nov 2017 10:35:41 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Sat, 18 Nov 2017 10:35:40 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount CC: "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiA= Date: Sat, 18 Nov 2017 09:35:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbHdWPftP/4og7mzxS1WbDjAatF0p4vN YsaFqcwWX39sYnNg8fj7/gOTx5IlP5k82l4qeNyaUhDAEsVlk5Kak1mWWqRvl8CVsb+9g6lg jkHF878TWBoY/+h1MXJwSAiYSHx8Y9PFyMUhJHCYUWLR+2WMEM4SRolj19rYQIrYBCwkuv9p dzFycogIeEtMmL+aDcRmFgiW2HB/AjOILSygIfF57mVmiBpNiYunljFB2H4SE88tBKtnEVCV 2D53KyOIzSvgK/F8YRcTxK7NLBIn7p9gBUlwCjhIHL7aBDaIUUBM4vupNUwQy8Qlbj2ZD2ZL CAhILNlznhnCFpV4+fgfK4StJNG45AkryM3MQEes36UP0aooMaX7ITvEXkGJkzOfsExgFJ2F ZOoshI5ZSDpmIelYwMiyilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwjg5u+a26g/HyG8dD jAIcjEo8vG6/+KOEWBPLiitzDzFKcDArifDOWM4XJcSbklhZlVqUH19UmpNafIhRmoNFSZz3 pCdvlJBAemJJanZqakFqEUyWiYNTqoHRtXuO2OtUZg1VuelyUduEYs6d6+9dX+yjddbH4OlS 3QsBS4yW+C8UvZx27W/aaaXt011MCzguP/GQiFp/WWDG0pIZhfx2yo9Fdmf+8vg+76PZR5XZ ZdrSoksuR2nIJSlemJEQsbr9/XPz36IrY5q1laM3vJHnN1h98HX333trC/eKnm85mnlMiaU4 I9FQi7moOBEAaHOt0p8CAAA= 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: Sat, 18 Nov 2017 09:35:45 -0000 SGksDQoNCkkgYWdyZWUgd2l0aCBQYXVsIHRoYXQgbmV3IG9wdGlvbi10YWdzIGV0YyBhcmVuJ3Qg Z29pbmcgdG8gaGVscC4gQWxzbywgaW4gZ2VuZXJhbCwgSSB0aGluayB3ZSBzaG91bGQgdHJ5IHRv IGxpbWl0IHRvIGltcGFjdHMgb24gZGlmZmVyZW50IHR5cGVzIG9mIG5vZGVzLg0KDQpPbmUgc3Vn Z2VzdGlvbiB3b3VsZCBiZSB0byBmb3JiaWQgdGhlIHVzYWdlIG9mIFVQREFURSB0byBjaGFuZ2Ug dGhlIHJlZnJlc2hlci4gSWYgYW4gZW5kcG9pbnQgd2FudHMgdG8gY2hhbmdlIHRoZSByZWZyZXNo ZXIgaXQgTVVTVCBzZW5kIGEgKHJlLSlJTlZJVEUgdG8gZG8gc28uIEFuZCwgbmV3IGVuZHBvaW50 cyBjb3VsZCBkaXNjYXJkIHRoZSByZWZyZXNoZXIgdmFsdWUgaW4gcmVjZWl2ZWQgVVBEQVRFcywg d2hpY2ggbWVhbnMgdGhleSB3b3VsZCB3b3JrIHdpdGggbGVnYWN5IGVuZHBvaW50cyB0aGF0IG1h eSB0cnkgdG8gY2hhbmdlIHRoZSByZWZyZXNoZXIgaW4gYW4gVVBEQVRFLg0KDQpUaGF0IHdheSB3 ZSBtYXkgbm90IGhhdmUgdG8gc2VwYXJhdGUgVVBEQVRFcyBzZW50IGluc2lkZSBJTlZJVEUgdHJh bnNhY3Rpb25zIGFuZCBVUERBVEVzIHNlbnQgb3V0c2lkZSBJTlZJVEUgdHJhbnNhY3Rpb25zLg0K DQpJIHRoaW5rIFBhdWwgbW9yZSBvciBsZXNzIHN1Z2dlc3RlZCB0aGUgc2FtZSB0aGluZyBlYXJs aWVyICgidGhlIHBlZXIgbXVzdCBtaXJyb3IgdGhlIHJlZnJlc2hlciB2YWx1ZSIpLCBldmVudGhv dWdoIEkgYmVsaWV2ZSBoZSB3YXMgb25seSB0YWxraW5nIGFib3V0IFVQREFURXMgaW5zaWRlIElO VklURSB0cmFuc2FjdGlvbi4NCg0KVGhhdCB3b3VsZCBhdCBsZWFzdCBzb2x2ZSB0aGUgcHJvYmxl bSB0aGF0IG9yaWdpbmFsbHkgdHJpZ2dlcmVkIGFsbCB0aGlzLiBBbmQsIGF0IGxlYXN0IGluIHRo ZSBkZXBsb3ltZW50IEkgYW0gYXdhcmUgb2YgaXQgd291bGQgb25seSBpbXBhY3QgYW4gYXBwbGlj YXRpb24gc2VydmVyIC0gdGhlcmUgd291bGQgYmUgbm8gbmVlZCB0byBjaGFuZ2UgYW55IHByb3hp ZXMgb3IgdGVybWluYWxzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5t aXQuZWR1XSANClNlbnQ6IDAyIE5vdmVtYmVyIDIwMTcgMjM6NDgNClRvOiBSb21hbiBTaHBvdW50 IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPjsgSmVzc2tlLCBSb2xhbmQgPFIuSmVzc2tlQHRlbGVrb20uZGU+ OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFNlc3Npb24gdGltZXIg Zml4DQoNCk9uIDExLzIvMTcgNToyNyBQTSwgUm9tYW4gU2hwb3VudCB3cm90ZToNCj4gT24gVGh1 LCBOb3YgMiwgMjAxNyBhdCA1OjA3IFBNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0 LmVkdSANCj4gPG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCj4gDQo+ICAg ICBBbmQgSU1PIHRoaXMgbmVlZHMgdG8gaGF2ZSB3ZWxsIGRlZmluZWQgYmVoYXZpb3IgZXZlbiBp ZiB0aGVyZSBpcyBhDQo+ICAgICBwcm94eSB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCB0aGlzIHJldmlz aW9uLg0KPiANCj4gICAgIEkndmUgYmVlbiBldm9sdmluZyBteSB0aGlua2luZyBhcyB0aGlzIGRp c2N1c3Npb24gaGFzIGNvbnRpbnVlZC4gSQ0KPiAgICAgc2VlIGEgY291cGxlIG9mIHdheXMgdG8g Z286DQo+IA0KPiAgICAgMSkgU3BlY2lmeSB0aGF0IHRoZSBuZWdvdGlhdGlvbiBpbiB0aGUgSU5W SVRFIHRyYW5zYWN0aW9uIHNob3VsZCBiZQ0KPiAgICAgdW5hZmZlY3RlZCBieSB3aGF0ZXZlciBo YXBwZW5zIGluIGFuIGludGVydmVuaW5nIFVQREFURS4gQWxzbw0KPiAgICAgc3BlY2lmeSBob3cg dGltZXIgc3R1ZmYgc2hvdWxkIGJlIGhhbmRsZWQgaW4gYW4gVVBEQVRFIHdpdGhpbiBhbg0KPiAg ICAgSU5WSVRFLiBGb3IgdGhhdCBJIHRoaW5rIHdoYXQgd2UgaGF2ZSBiZWVuIGNvbnZlcmdpbmcg b24gaXM6DQo+IA0KPiAgICAgLSB0aGUgVUFDIGFuZCBwcm94aWVzIGZvciB0aGUgZW1iZWRkZWQg VVBEQVRFIHNob3VsZCBub3QgaW5jbHVkZSBTLUU7DQo+ICAgICAtIHRoZSBVQVMgc2hvdWxkIG5v dCBpbmNsdWRlIFMtRSBpbiB0aGUgVVBEQVRFIHJlc3BvbnNlLA0KPiAgICAgIMKgIGV2ZW4gaWYg aXQgZ2V0cyBvbmUgaW4gdGhlIHJlcXVlc3Q7DQo+ICAgICAtIHByb3hpZXMgc2hvdWxkIG5vdCBh ZGQgYW4gUy1FIHRvIGFuIGVtYmVkZGVkIFVQREFURSByZXNwb25zZTsNCj4gICAgIC0gdGhlIFVB QyBzaG91bGQgaWdub3JlIFMtRSBpbiBhbiBlbWJlZGRlZCBVUERBVEUgcmVzcG9uc2UuDQo+IA0K PiAgICAgQnV0IHRoZSBrZXkgaGVyZSBpcyB0aGUgVUFDIGlnbm9yaW5nIGl0Lg0KPiANCj4gICAg IDIpIFNwZWNpZnkgdGhhdCBhIFVBQyBvciBwcm94eSBzaG91bGQgZHVwbGljYXRlIGluIGFuIGVt YmVkZGVkDQo+ICAgICBVUERBVEUgd2hhdGV2ZXIgdGltZXIgc3R1ZmYgdGhleSBwdXQgaW4gdGhl IGVuY2xvc2luZyBJTlZJVEUNCj4gICAgIHRyYW5zYWN0aW9uLiBBbmQgdGhlbiB0aGUgVUFDIGZv ciB0aGUgSU5WSVRFIHNob3VsZCBwcm9jZXNzIHRoZQ0KPiAgICAgdGltZXIgc3R1ZmYgaW4gdGhl IDJ4eCByZXNwb25zZSB0byB0aGUgSU5WSVRFIHRoZSBzYW1lIGFzIGlmIHRoZQ0KPiAgICAgVVBE QVRFIGRpZG4ndCBoYXBwZW4uIChXaGF0IGl0IGRvZXMgdG8gcHJvY2VzcyB0aGUgdGltZXIgc3R1 ZmYgaW4NCj4gICAgIHRoZSAyMDAgZm9yIHRoZSBVUERBVEUgaXMgaXJyZWxldmFudC4pDQo+IA0K PiAgICAgSSB0aGluayAoMSkgaXMgY2xvc2VyIHRvIHdoYXQgd2UgaGF2ZSBiZWVuIGNvbnZlcmdp bmcgb24uIEJ1dCBJIGFtDQo+ICAgICBub3cgdGhpbmtpbmcgdGhhdCAoMikgaXMgbW9yZSByb2J1 c3QgaW4gdGhlIHByZXNlbmNlIG9mIHNvbWUNCj4gICAgIGNvbXBvbmVudHMgdGhhdCBkb24ndCBp bXBsZW1lbnQgdGhlIHJldmlzaW9uLg0KPiANCj4gDQo+IFRoZXJlIGFyZSB0d28gcmVxdWlyZW1l bnRzIGZvciB0aGlzIHdvcms6DQo+IA0KPiAxLiBVQUMgbXVzdCBpZ25vcmUgdGhlIFMtVCBuZWdv dGlhdGlvbiByZXN1bHQgd2hlbiBVUERBVEUgaXMgd2l0aGluIA0KPiBJTlZJVEUgdHJhbnNhY3Rp b24gMi4gVUFDIGFuZCBVQVMgbWFzdCBhZ3JlZSBvbiB0aGUgbmVnb3RpYXRpb24gDQo+IHJlc3Vs dHMuDQo+IA0KPiBJIHdhcyB0aGlua2luZyB0aGF0IGluY2x1ZGluZyBzb21lIHNvcnQgb2YgaGVh ZGVyIChvciBzdXBwb3J0ZWQgdGFnKSANCj4gaW4gdGhlIFVQREFURSByZXF1ZXN0IGFuZCBtaXJy b3JpbmcgdGhlIHNhbWUgaGVhZGVyIChvciB0YWcpIGluIHRoZSANCj4gcmVzcG9uc2Ugd291bGQg YmUgdGhlIGJlc3Qgd2F5IHRvIGFjaGlldmUgdGhpcyByZXN1bHQuIEluIHRoaXMgY2FzZSwgDQo+ IGl0IGlzIGlycmVsZXZhbnQgaWYgcHJveGllcyBpbnNlcnRlZCBTLUUgaW4gdGhlIHJlcXVlc3Qg LS0gdGhlIG5ldyANCj4gaGVhZGVyIHdpbGwgb3ZlcndyaXRlIGl0LiBQcm94aWVzIGNhbiBhbHNv IGRldGVjdCB0aGF0IFMtRSB3aWxsIGhhdmUgDQo+IG5vIGVmZmVjdCBvbiB0aGlzIHJlcXVlc3Qg b3IgcmVzcG9uc2UsIHNpbmNlIHRoZSBleHRyYSBoZWFkZXIgaXMgcHJlc2VudC4NCj4gDQo+IFVB QyBhbmQgVUFTIHdpbGwga25vdyB0aGF0IHRoZXkgYmVoYXZlIHRoZSBzYW1lIHdheSBzaW5jZSB0 aGV5IHdpbGwgDQo+IGJvdGggc2VlIHRoaXMgaGVhZGVyIG9ubHkgaWYgdGhleSBib3RoIHN1cHBv cnQgaXQuDQoNCkknbSBub3Qgc3VyZSBhIHRhZyBhZGRzIG11Y2guIEl0IGRvZXNuJ3QgZG8gYW55 dGhpbmcgZm9yIHByb3hpZXMgdW5sZXNzIHdlIHVzZSBQcm94eS1SZXF1aXJlLCBhbmQgd2UgZG9u J3Qgd2FudCB0aGF0LiBBbmQgd2hhdCBkbyB5b3UgZG8gaWYgdGhlIHRhZyBpc24ndCByZWNvZ25p emVkIGJ5IHRoZSBVQVM/DQoNCklTVE0gYSB3YXkgdG8gYXBwcm9hY2ggdGhpcyBpcyB0byBmaXJz dCBzcGVjaWZ5IG91ciBwcm9wb3NlZCBiZWhhdmlvciAoYXMgaW4gKDEpIG9yICgyKSkuIFRoZW4g d2UgbmVlZCB0byBhbmFseXplIGl0IGluIHRoZSBwcmVzZW5jZSBvZiBvbmUgb3IgbW9yZSBjb21w b25lbnRzIHRoYXQgZG9uJ3QgaW1wbGVtZW50IHRoZSByZXZpc2lvbiwgYW5kIHdpdGggdmFyaW91 cyBwbGF1c2libGUgaW50ZXJwcmV0YXRpb25zIG9mIHRoZSBleGlzdGluZyBhbWJpZ3VvdXMgc3Bl Y2lmaWNhdGlvbi4NCg0KQW5kIHRoZW4gc2VlIGlmIHRoZSByZXN1bHQgaXMgYW55IHdvcnNlIGZv ciBhbnkgY29tcG9uZW50cyB3aXRoIHRoZSByZXZpc2lvbiB0aGFuIGl0IGlzIHdpdGhvdXQgaXQu IChBbmQgSSBndWVzcyB3ZSBzaG91bGQgYWxzbyBmaWd1cmUgb3V0IGlmIGl0IGlzIGFueSAqYmV0 dGVyKiBiZWZvcmUgZ29pbmcgYWhlYWQgYW5kIGRvaW5nIHRoaXMuKQ0KDQoJVGhhbmtzLA0KCVBh dWwNCg== From nobody Sat Nov 18 08:16: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 A0DA712751F for ; Sat, 18 Nov 2017 08:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=softarmor.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 qH4nweCvbHEf for ; Sat, 18 Nov 2017 08:16:43 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 91E36120726 for ; Sat, 18 Nov 2017 08:16:43 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id o14so4521707wrf.9 for ; Sat, 18 Nov 2017 08:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s+QyDBWXPGdQr1qaM/LGbKYip0/zUSk9B24fyqGieww=; b=SEMZYX0ICP2Xja5qeHhDit04/+lQK+4icYVvLDnqqYW3cqYrPqm+ZCJYRChEEzHL94 ITTqEoRBHyY5wc0ypV5HFnzuGeJnWB/yuZavYHYztYqDB1aRlO+SyivL11GLIY48mFjW 1Yh6Bz8VlrrT4py/U1ldm/JFSwEaFNYNGF8w0= 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=s+QyDBWXPGdQr1qaM/LGbKYip0/zUSk9B24fyqGieww=; b=TifWTicAUf338ShWHb5ptTJuKtArovbU2pRuhuXEtVj22olpb1v9tYu3csOOYiY1Ce hpjvEty/0VCeQlnGi5qdP1i8zeIaI+OhNTLQ/9jrDpzxlUrvbDKopCX0BGrRLskr1Upc HFIhf+2hHhsUGbOGFe8Hfm+zibriqt35iRnJTw1HIyRQ7JaKkHRHBjtm1x8pAM5ibB+9 cjcLMVbT+P9Mcq2pzI+u89TDnAHfXHJ54qZm7uNcbJcZGJyiLoaMkK6cka4reGsLFZzg QHnKyinBwxCc3elSmzmaflZXeKyKkKHGIQ8T1L7sgDbBViucBJky+Qb9sAfgdedE+caz 2cyQ== X-Gm-Message-State: AJaThX7K6rnvD5h4bpm77gu05ETC9q8Ua4xq0rid5YUoDkLtBExz57tw 7PxqfbFRAguouKF9got81oUTcFk/Nrl3HTE7fodjUg== X-Google-Smtp-Source: AGs4zMYkcSLkzV5mZg5vZZ8uDdHrbF9xJztq4iwqrEjOIPdwoWlumO1HXqsoN6WJIjhbVPKNwDzwdTsOJ/pEyBUuwGk= X-Received: by 10.223.176.233 with SMTP id j38mr6801922wra.178.1511021801683; Sat, 18 Nov 2017 08:16:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.166.54 with HTTP; Sat, 18 Nov 2017 08:16:41 -0800 (PST) Received: by 10.223.166.54 with HTTP; Sat, 18 Nov 2017 08:16:41 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6BFF74C5@ESESSMB109.ericsson.se> References: <20171116022038.047B6B8104D@rfc-editor.org> <05021C56-903E-46A2-9CC0-DD07C3147EC2@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6BFE453C@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF74C5@ESESSMB109.ericsson.se> From: Dean Willis Date: Sat, 18 Nov 2017 10:16:41 -0600 Message-ID: To: Christer Holmberg Cc: "Roland Jesske (R.Jesske@telekom.de)" , Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="001a113bdedcbcd583055e442d10" Archived-At: Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) 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, 18 Nov 2017 16:16:45 -0000 --001a113bdedcbcd583055e442d10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I concur with this set of arguments. Not valid. On Nov 17, 2017 23:40, "Christer Holmberg" wrote: > Hi, > > >it was faster than expected. > >So we are separating with semicolon. > >Like: > >Privacy: header;id;user > > > >So I would not propose to change anything. > >It will not be backwards compatible. And I assume we will get in trouble > when: > >Privacy: header,id,user appear. > > > >PS: It is a implementation from Christer's company. > > Luckily I got the same feedback from our product people :) > > So, I don't think we should change anything. > > I don't even think the intention ever was to allow multiple instances of > the Privacy header field. What would the semantics of having multiple > header field instances be? > > For headers where we DO allow multiple instances (whether the header fiel= d > values are comma separated within a single header instance, or in separat= e > header instances) there is clear semantics for that. E.g., Contact, > Record-Route, Route, Via etc. > > Regards, > > Christer > > > > -----Urspr=C3=BCngliche Nachricht----- > > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Jesske, > > Roland > > Gesendet: Freitag, 17. November 2017 11:11 > > An: christer.holmberg@ericsson.com; pkyzivat@alum.mit.edu; > > sipcore@ietf.org > > Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184) > > > > Hi, > > I have asked my guys to forward me how we have the done the > > implementation. > > > > Best Regards > > > > Roland > > > > > -----Urspr=C3=BCngliche Nachricht----- > > > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von > > > Christer Holmberg > > > Gesendet: Freitag, 17. November 2017 10:53 > > > An: Paul Kyzivat ; sipcore@ietf.org > > > Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 > > > (5184) > > > > > > Hi, > > > > > > ... > > > > > > > BUT given the late date that this has come to light much concern > > > > must be paid to what has been deployed. I looked (not very hard) > > > > for published > > > examples that have multiple privacy values, but didn't find any. > > > > > > I believe there are cases with multiple values. It's a little > > > difficult for me to look for them while in Singapore, but once I'm > > > back in > > office it will be easier. > > > > > > 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 > --001a113bdedcbcd583055e442d10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I concur with this set of arguments.=C2=A0

Not valid.

On Nov 17, 2017 23:40, "Christer H= olmberg" <christe= r.holmberg@ericsson.com> wrote:
Hi,

>it was faster than expected.
>So we are separating with semicolon.
>Like:
>Privacy: header;id;user
>
>So I would not propose to change anything.
>It will not be backwards compatible. And I assume we will get in troubl= e when:
>Privacy: header,id,user appear.
>
>PS: It is a implementation from Christer's company.

Luckily I got the same feedback from our product people :)

So, I don't think we should change anything.

I don't even think the intention ever was to allow multiple instances o= f the Privacy header field. What would the semantics of having multiple hea= der field instances be?

For headers where we DO allow multiple instances (whether the header field = values are comma separated within a single header instance, or in separate = header instances) there is clear semantics for that. E.g., Contact, Record-= Route, Route, Via etc.

Regards,

Christer


> -----Urspr=C3=BCngliche Nachricht-----
> Von: sipcore [mailto:sipco= re-bounces@ietf.org] Im Auftrag von Jesske,
> Roland
> Gesendet: Freitag, 17. November 2017 11:11
> An: christer.holmber= g@ericsson.com; pkyzivat@= alum.mit.edu;
> sipcore@ietf.org
> Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184)=
>
> Hi,
> I have asked my guys to forward me how we have the done the
> implementation.
>
> Best Regards
>
> Roland
>
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: sipcore [mailto:= sipcore-bounces@ietf.org] Im Auftrag von
> > Christer Holmberg
> > Gesendet: Freitag, 17. November 2017 10:53
> > An: Paul Kyzivat <pky= zivat@alum.mit.edu>; sipcore@iet= f.org
> > Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 > > (5184)
> >
> > Hi,
> >
> > ...
> >
> > > BUT given the late date that this has come to light much con= cern
> > > must be paid to what has been deployed. I looked (not very h= ard)
> > > for published
> > examples that have multiple privacy values, but didn't find a= ny.
> >
> > I believe there are cases with multiple values. It's a little=
> > difficult for me to look for them while in Singapore, but once I&= #39;m
> > back in
> office it will be easier.
> >
> > Regards,
> >
> > Christer
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/si= pcore
>
> _______________________________________________
> 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<= br>
--001a113bdedcbcd583055e442d10-- From nobody Sat Nov 18 10:26: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 6CF9F126CF6 for ; Sat, 18 Nov 2017 10:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 AiEj0P6MMros for ; Sat, 18 Nov 2017 10:26:24 -0800 (PST) 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 B57A11204DA for ; Sat, 18 Nov 2017 10:26:24 -0800 (PST) X-AuditID: 12074413-3a3ff70000007929-ea-5a107b4f5e92 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 1C.17.31017.F4B701A5; Sat, 18 Nov 2017 13:26:23 -0500 (EST) 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 vAIIQM3S002106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 18 Nov 2017 13:26:23 -0500 To: Christer Holmberg , Roman Shpount Cc: "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Sat, 18 Nov 2017 13:26:22 -0500 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: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixO6iqOtfLRBlMPmqqcWFmYcZLZrudLFZ zLgwldni649NbA4sHr++XmXzWLLkJ5NH20sFj1tTCgJYorhsUlJzMstSi/TtErgyvn93L3ii VbFyUg9bA+N6xS5GTg4JAROJlr9vGLsYuTiEBHYwSUz4s48JwnnIJPHg+A1GkCphAQ2JQ3t+ s3QxcnCICCRJHOsuAQkzC0RJtGzYywZR/51F4t/8PiaQBJuAlsScQ/9ZQGxeAXuJI0t3M4PY LAKqEjvevwGrERVIk7gz4yETRI2gxMmZT8DqOQX8JLbd/cYOscBMYt7mh8wQtrjErSfzmSBs eYnmrbOZJzAKzELSPgtJyywkLbOQtCxgZFnFKJeYU5qrm5uYmVOcmqxbnJyYl5dapGuul5tZ opeaUrqJERLkwjsYd52UO8QowMGoxMN7gYk/Sog1say4MvcQoyQHk5Io78H1QCG+pPyUyozE 4oz4otKc1OJDjBIczEoivLlJAlFCvCmJlVWpRfkwKWkOFiVxXrUl6n5CAumJJanZqakFqUUw WRkODiUJ3meVQI2CRanpqRVpmTklCGkmDk6Q4TxAw2WrQIYXFyTmFmemQ+RPMbpy9PTc+MPE 8ejGXSC54fsDIPls5usGZo55x781MQux5OXnpUqJ8+aBNAuANGeU5sHNhyWzV4ziQO8K83qA VPEAEyHchldAy5mAlrtc4AdZXpKIkJJqYGTom7skNNVmUebnso0Xd8+8wn7tZnS31LHJ7je9 tvzxe7pvs34zs9CHjv6e1NlNQm9L35fcPxnxSiHIKmlu3LHug/+5o1gLL69YckTSZVF+pHJo 2tNbC+6KsH6bkl4pmHH3jOXj3IbpMh7LDxsdaNNK8ZY6zVz78O3tR2lvud+dNvuy8sahj71K LMUZiYZazEXFiQAiZGfzQQMAAA== 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: Sat, 18 Nov 2017 18:26:26 -0000 On 11/18/17 4:35 AM, Christer Holmberg wrote: > Hi, > > I agree with Paul that new option-tags etc aren't going to help. Also, in general, I think we should try to limit to impacts on different types of nodes. > > One suggestion would be to forbid the usage of UPDATE to change the refresher. If an endpoint wants to change the refresher it MUST send a (re-)INVITE to do so. And, new endpoints could discard the refresher value in received UPDATEs, which means they would work with legacy endpoints that may try to change the refresher in an UPDATE. > > That way we may not have to separate UPDATEs sent inside INVITE transactions and UPDATEs sent outside INVITE transactions. > > I think Paul more or less suggested the same thing earlier ("the peer must mirror the refresher value"), eventhough I believe he was only talking about UPDATEs inside INVITE transaction. UPDATE *within* INVITE and UPDATE *outside* INVITE are two distinct cases. Banning use of UPDATE outside for this purpose is a more extreme case. (IMO, once you have a session, using an offerless UPDATE for s-t refreshes is preferable unless you happen to also need a concurrent O/A.) So I hesitate to ban that case unless allowing it causes some problem. The only possible problem I can see is if the two ends might disagree on whether the UPDATE is within an INVITE. This might occur if one end sends reINVITE and the other sends UPDATE more-or-less concurrently. But ISTM that case should be treated as glare. I think this can be covered by adding some text to the new draft talking about this case and spelling out that 491 should be used if this occurs. Thanks, Paul > That would at least solve the problem that originally triggered all this. And, at least in the deployment I am aware of it would only impact an application server - there would be no need to change any proxies or terminals. > > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 02 November 2017 23:48 > To: Roman Shpount > Cc: Christer Holmberg ; Jesske, Roland ; sipcore@ietf.org > Subject: Re: [sipcore] Session timer fix > > On 11/2/17 5:27 PM, Roman Shpount wrote: >> On Thu, Nov 2, 2017 at 5:07 PM, Paul Kyzivat > > wrote: >> >> And IMO this needs to have well defined behavior even if there is a >> proxy that doesn't support this revision. >> >> I've been evolving my thinking as this discussion has continued. I >> see a couple of ways to go: >> >> 1) Specify that the negotiation in the INVITE transaction should be >> unaffected by whatever happens in an intervening UPDATE. Also >> specify how timer stuff should be handled in an UPDATE within an >> INVITE. For that I think what we have been converging on is: >> >> - the UAC and proxies for the embedded UPDATE should not include S-E; >> - the UAS should not include S-E in the UPDATE response, >>   even if it gets one in the request; >> - proxies should not add an S-E to an embedded UPDATE response; >> - the UAC should ignore S-E in an embedded UPDATE response. >> >> But the key here is the UAC ignoring it. >> >> 2) Specify that a UAC or proxy should duplicate in an embedded >> UPDATE whatever timer stuff they put in the enclosing INVITE >> transaction. And then the UAC for the INVITE should process the >> timer stuff in the 2xx response to the INVITE the same as if the >> UPDATE didn't happen. (What it does to process the timer stuff in >> the 200 for the UPDATE is irrelevant.) >> >> I think (1) is closer to what we have been converging on. But I am >> now thinking that (2) is more robust in the presence of some >> components that don't implement the revision. >> >> >> There are two requirements for this work: >> >> 1. UAC must ignore the S-T negotiation result when UPDATE is within >> INVITE transaction 2. UAC and UAS mast agree on the negotiation >> results. >> >> I was thinking that including some sort of header (or supported tag) >> in the UPDATE request and mirroring the same header (or tag) in the >> response would be the best way to achieve this result. In this case, >> it is irrelevant if proxies inserted S-E in the request -- the new >> header will overwrite it. Proxies can also detect that S-E will have >> no effect on this request or response, since the extra header is present. >> >> UAC and UAS will know that they behave the same way since they will >> both see this header only if they both support it. > > I'm not sure a tag adds much. It doesn't do anything for proxies unless we use Proxy-Require, and we don't want that. And what do you do if the tag isn't recognized by the UAS? > > ISTM a way to approach this is to first specify our proposed behavior (as in (1) or (2)). Then we need to analyze it in the presence of one or more components that don't implement the revision, and with various plausible interpretations of the existing ambiguous specification. > > And then see if the result is any worse for any components with the revision than it is without it. (And I guess we should also figure out if it is any *better* before going ahead and doing this.) > > Thanks, > Paul > From nobody Sat Nov 18 18:36: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 85FBB1200FC for ; Sat, 18 Nov 2017 18:36:07 -0800 (PST) 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 1oEoJO2ZbnAH for ; Sat, 18 Nov 2017 18:36:05 -0800 (PST) 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 6EE1C1252BA for ; Sat, 18 Nov 2017 18:36:05 -0800 (PST) X-AuditID: c1b4fb3a-c73ff70000004c48-6f-5a10ee13a12a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.63.19528.31EE01A5; Sun, 19 Nov 2017 03:36:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Sun, 19 Nov 2017 03:36:03 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount CC: "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIA Date: Sun, 19 Nov 2017 02:36:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@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+NgFuplkeLIzCtJLcpLzFFi42KZGbHdQ1f4nUCUwedOHYsVGw6wWjTd6WKz mHFhKrPF1x+b2BxYPP6+/8DksWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBl3Jv4k6ng gk3FqZazzA2MHdZdjJwcEgImEpvmNzN3MXJxCAkcZpRovP2WFcJZwijx5M1Zti5GDg42AQuJ 7n/aIA0iAt4SE+avZgOxmQWCJTbcn8AMYgsLaEh8nnuZGaJGU+LiqWVMEHaUxPrfO1lAbBYB VYktG2azg9i8Ar4Sr7o3Q+1ayyrxbP8bRpAEp4CDxJeTm8AWMAqISXw/tYYJYpm4xK0n85kg rhaQWLLnPDOELSrx8vE/VghbSWLR7c9MIDczAx2xfpc+RKuixJTuh1B7BSVOznzCMoFRdBaS qbMQOmYh6ZiFpGMBI8sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMBIOrjlt9UOxoPPHQ8x CnAwKvHwSu8WiBJiTSwrrsw9xCjBwawkwpubBBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOe9KT N0pIID2xJDU7NbUgtQgmy8TBKdXAGNl7jedE/b8dbYuMd2jEZ/Ed2HwhqmxN8ZtQNa9WFrkY ox9L57TV/Mvfc2rBzl9bZK+nNleU+19XVAlzNva8O3f/hye/OhkmqhpLi/BUT/1n8umnRLTw tDOPv2jvs3rJKMmXsc4s8Cuj4g+PjfFn1ivzRHx7aJPPfuezhtyapUarcyP1Jx7WVmIpzkg0 1GIuKk4EAC5MJSOgAgAA 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, 19 Nov 2017 02:36:07 -0000 SGksDQoNCj4+IEkgYWdyZWUgd2l0aCBQYXVsIHRoYXQgbmV3IG9wdGlvbi10YWdzIGV0YyBhcmVu J3QgZ29pbmcgdG8gaGVscC4gQWxzbywgaW4gZ2VuZXJhbCwgSSB0aGluayB3ZQ0KPj4gc2hvdWxk IHRyeSB0byBsaW1pdCB0byBpbXBhY3RzIG9uIGRpZmZlcmVudCB0eXBlcyBvZiBub2Rlcy4NCj4+ IA0KPj4gT25lIHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gZm9yYmlkIHRoZSB1c2FnZSBvZiBVUERB VEUgdG8gY2hhbmdlIHRoZSByZWZyZXNoZXIuIElmIGFuIGVuZHBvaW50IA0KPj4gd2FudHMgdG8g Y2hhbmdlIHRoZSByZWZyZXNoZXIgaXQgTVVTVCBzZW5kIGEgKHJlLSlJTlZJVEUgdG8gZG8gc28u IEFuZCwgbmV3IGVuZHBvaW50cyBjb3VsZCBkaXNjYXJkIA0KPj4gdGhlIHJlZnJlc2hlciB2YWx1 ZSBpbiByZWNlaXZlZCBVUERBVEVzLCB3aGljaCBtZWFucyB0aGV5IHdvdWxkIHdvcmsgd2l0aCBs ZWdhY3kgZW5kcG9pbnRzIHRoYXQgbWF5DQo+PiB0cnkgdG8gY2hhbmdlIHRoZSByZWZyZXNoZXIg aW4gYW4gVVBEQVRFLg0KPj4gDQo+PiBUaGF0IHdheSB3ZSBtYXkgbm90IGhhdmUgdG8gc2VwYXJh dGUgVVBEQVRFcyBzZW50IGluc2lkZSBJTlZJVEUgdHJhbnNhY3Rpb25zIGFuZCBVUERBVEVzIHNl bnQgb3V0c2lkZSBJTlZJVEUgdHJhbnNhY3Rpb25zLg0KPj4gDQo+PiBJIHRoaW5rIFBhdWwgbW9y ZSBvciBsZXNzIHN1Z2dlc3RlZCB0aGUgc2FtZSB0aGluZyBlYXJsaWVyICgidGhlIHBlZXIgbXVz dCBtaXJyb3IgdGhlIHJlZnJlc2hlciB2YWx1ZSIpLCBldmVudGhvdWdoIA0KPj4gSSBiZWxpZXZl IGhlIHdhcyBvbmx5IHRhbGtpbmcgYWJvdXQgVVBEQVRFcyBpbnNpZGUgSU5WSVRFIHRyYW5zYWN0 aW9uLg0KPg0KPiBVUERBVEUgKndpdGhpbiogSU5WSVRFIGFuZCBVUERBVEUgKm91dHNpZGUqIElO VklURSBhcmUgdHdvIGRpc3RpbmN0IGNhc2VzLiBCYW5uaW5nIHVzZSBvZiBVUERBVEUgb3V0c2lk ZSBmb3IgDQo+IHRoaXMgcHVycG9zZSBpcyBhIG1vcmUgZXh0cmVtZSBjYXNlLiAoSU1PLCBvbmNl IHlvdSBoYXZlIGEgc2Vzc2lvbiwgdXNpbmcgYW4gb2ZmZXJsZXNzIFVQREFURSBmb3Igcy10IHJl ZnJlc2hlcyBpcyANCj4gcHJlZmVyYWJsZSB1bmxlc3MgeW91IGhhcHBlbiB0byBhbHNvIG5lZWQg YSBjb25jdXJyZW50IE8vQS4pDQoNCkkgYW0gbm90IHN1Z2dlc3RpbmcgdGhhdCB3ZSBiYW4gdXNh Z2Ugb2YgVVBEQVRFIGZvciBzLXQgcmVmcmVzaGVzLiBNeSBzdWdnZXN0aW9uIGlzIHRoYXQgd2Ug YmFuIHVzYWdlIG9mIFVQREFURSBmb3IgY2hhbmdpbmcgdGhlIHJlZnJlc2hlciByb2xlICh1YWMt PnVhcyBldGMpLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KU28gSSBoZXNp dGF0ZSB0byBiYW4gdGhhdCBjYXNlIHVubGVzcyBhbGxvd2luZyBpdCBjYXVzZXMgc29tZSBwcm9i bGVtLiANClRoZSBvbmx5IHBvc3NpYmxlIHByb2JsZW0gSSBjYW4gc2VlIGlzIGlmIHRoZSB0d28g ZW5kcyBtaWdodCBkaXNhZ3JlZSBvbiB3aGV0aGVyIHRoZSBVUERBVEUgaXMgd2l0aGluIGFuIElO VklURS4gVGhpcyBtaWdodCBvY2N1ciBpZiBvbmUgZW5kIHNlbmRzIHJlSU5WSVRFIGFuZCB0aGUg b3RoZXIgc2VuZHMgVVBEQVRFIG1vcmUtb3ItbGVzcyBjb25jdXJyZW50bHkuIEJ1dCBJU1RNIHRo YXQgY2FzZSBzaG91bGQgYmUgdHJlYXRlZCBhcyBnbGFyZS4gSSB0aGluayB0aGlzIGNhbiBiZSBj b3ZlcmVkIGJ5IGFkZGluZyBzb21lIHRleHQgdG8gdGhlIG5ldyBkcmFmdCB0YWxraW5nIGFib3V0 IHRoaXMgY2FzZSBhbmQgc3BlbGxpbmcgb3V0IHRoYXQgNDkxIHNob3VsZCBiZSB1c2VkIGlmIHRo aXMgb2NjdXJzLg0KDQoJVGhhbmtzLA0KCVBhdWwNCg0KPiBUaGF0IHdvdWxkIGF0IGxlYXN0IHNv bHZlIHRoZSBwcm9ibGVtIHRoYXQgb3JpZ2luYWxseSB0cmlnZ2VyZWQgYWxsIHRoaXMuIEFuZCwg YXQgbGVhc3QgaW4gdGhlIGRlcGxveW1lbnQgSSBhbSBhd2FyZSBvZiBpdCB3b3VsZCBvbmx5IGlt cGFjdCBhbiBhcHBsaWNhdGlvbiBzZXJ2ZXIgLSB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIHRvIGNo YW5nZSBhbnkgcHJveGllcyBvciB0ZXJtaW5hbHMuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hy aXN0ZXINCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBhdWwgS3l6 aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0NCj4gU2VudDogMDIgTm92ZW1iZXIg MjAxNyAyMzo0OA0KPiBUbzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+DQo+IENj OiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgSmVz c2tlLCBSb2xhbmQgDQo+IDxSLkplc3NrZUB0ZWxla29tLmRlPjsgc2lwY29yZUBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFNlc3Npb24gdGltZXIgZml4DQo+IA0KPiBPbiAxMS8y LzE3IDU6MjcgUE0sIFJvbWFuIFNocG91bnQgd3JvdGU6DQo+PiBPbiBUaHUsIE5vdiAyLCAyMDE3 IGF0IDU6MDcgUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1IA0KPj4gPG1h aWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCj4+DQo+PiAgICAgIEFuZCBJTU8g dGhpcyBuZWVkcyB0byBoYXZlIHdlbGwgZGVmaW5lZCBiZWhhdmlvciBldmVuIGlmIHRoZXJlIGlz IGENCj4+ICAgICAgcHJveHkgdGhhdCBkb2Vzbid0IHN1cHBvcnQgdGhpcyByZXZpc2lvbi4NCj4+ DQo+PiAgICAgIEkndmUgYmVlbiBldm9sdmluZyBteSB0aGlua2luZyBhcyB0aGlzIGRpc2N1c3Np b24gaGFzIGNvbnRpbnVlZC4gSQ0KPj4gICAgICBzZWUgYSBjb3VwbGUgb2Ygd2F5cyB0byBnbzoN Cj4+DQo+PiAgICAgIDEpIFNwZWNpZnkgdGhhdCB0aGUgbmVnb3RpYXRpb24gaW4gdGhlIElOVklU RSB0cmFuc2FjdGlvbiBzaG91bGQgYmUNCj4+ICAgICAgdW5hZmZlY3RlZCBieSB3aGF0ZXZlciBo YXBwZW5zIGluIGFuIGludGVydmVuaW5nIFVQREFURS4gQWxzbw0KPj4gICAgICBzcGVjaWZ5IGhv dyB0aW1lciBzdHVmZiBzaG91bGQgYmUgaGFuZGxlZCBpbiBhbiBVUERBVEUgd2l0aGluIGFuDQo+ PiAgICAgIElOVklURS4gRm9yIHRoYXQgSSB0aGluayB3aGF0IHdlIGhhdmUgYmVlbiBjb252ZXJn aW5nIG9uIGlzOg0KPj4NCj4+ICAgICAgLSB0aGUgVUFDIGFuZCBwcm94aWVzIGZvciB0aGUgZW1i ZWRkZWQgVVBEQVRFIHNob3VsZCBub3QgaW5jbHVkZSBTLUU7DQo+PiAgICAgIC0gdGhlIFVBUyBz aG91bGQgbm90IGluY2x1ZGUgUy1FIGluIHRoZSBVUERBVEUgcmVzcG9uc2UsDQo+PiAgICAgICDC oCBldmVuIGlmIGl0IGdldHMgb25lIGluIHRoZSByZXF1ZXN0Ow0KPj4gICAgICAtIHByb3hpZXMg c2hvdWxkIG5vdCBhZGQgYW4gUy1FIHRvIGFuIGVtYmVkZGVkIFVQREFURSByZXNwb25zZTsNCj4+ ICAgICAgLSB0aGUgVUFDIHNob3VsZCBpZ25vcmUgUy1FIGluIGFuIGVtYmVkZGVkIFVQREFURSBy ZXNwb25zZS4NCj4+DQo+PiAgICAgIEJ1dCB0aGUga2V5IGhlcmUgaXMgdGhlIFVBQyBpZ25vcmlu ZyBpdC4NCj4+DQo+PiAgICAgIDIpIFNwZWNpZnkgdGhhdCBhIFVBQyBvciBwcm94eSBzaG91bGQg ZHVwbGljYXRlIGluIGFuIGVtYmVkZGVkDQo+PiAgICAgIFVQREFURSB3aGF0ZXZlciB0aW1lciBz dHVmZiB0aGV5IHB1dCBpbiB0aGUgZW5jbG9zaW5nIElOVklURQ0KPj4gICAgICB0cmFuc2FjdGlv bi4gQW5kIHRoZW4gdGhlIFVBQyBmb3IgdGhlIElOVklURSBzaG91bGQgcHJvY2VzcyB0aGUNCj4+ ICAgICAgdGltZXIgc3R1ZmYgaW4gdGhlIDJ4eCByZXNwb25zZSB0byB0aGUgSU5WSVRFIHRoZSBz YW1lIGFzIGlmIHRoZQ0KPj4gICAgICBVUERBVEUgZGlkbid0IGhhcHBlbi4gKFdoYXQgaXQgZG9l cyB0byBwcm9jZXNzIHRoZSB0aW1lciBzdHVmZiBpbg0KPj4gICAgICB0aGUgMjAwIGZvciB0aGUg VVBEQVRFIGlzIGlycmVsZXZhbnQuKQ0KPj4NCj4+ICAgICAgSSB0aGluayAoMSkgaXMgY2xvc2Vy IHRvIHdoYXQgd2UgaGF2ZSBiZWVuIGNvbnZlcmdpbmcgb24uIEJ1dCBJIGFtDQo+PiAgICAgIG5v dyB0aGlua2luZyB0aGF0ICgyKSBpcyBtb3JlIHJvYnVzdCBpbiB0aGUgcHJlc2VuY2Ugb2Ygc29t ZQ0KPj4gICAgICBjb21wb25lbnRzIHRoYXQgZG9uJ3QgaW1wbGVtZW50IHRoZSByZXZpc2lvbi4N Cj4+DQo+Pg0KPj4gVGhlcmUgYXJlIHR3byByZXF1aXJlbWVudHMgZm9yIHRoaXMgd29yazoNCj4+ DQo+PiAxLiBVQUMgbXVzdCBpZ25vcmUgdGhlIFMtVCBuZWdvdGlhdGlvbiByZXN1bHQgd2hlbiBV UERBVEUgaXMgd2l0aGluIA0KPj4gSU5WSVRFIHRyYW5zYWN0aW9uIDIuIFVBQyBhbmQgVUFTIG1h c3QgYWdyZWUgb24gdGhlIG5lZ290aWF0aW9uIA0KPj4gcmVzdWx0cy4NCj4+DQo+PiBJIHdhcyB0 aGlua2luZyB0aGF0IGluY2x1ZGluZyBzb21lIHNvcnQgb2YgaGVhZGVyIChvciBzdXBwb3J0ZWQg dGFnKSANCj4+IGluIHRoZSBVUERBVEUgcmVxdWVzdCBhbmQgbWlycm9yaW5nIHRoZSBzYW1lIGhl YWRlciAob3IgdGFnKSBpbiB0aGUgDQo+PiByZXNwb25zZSB3b3VsZCBiZSB0aGUgYmVzdCB3YXkg dG8gYWNoaWV2ZSB0aGlzIHJlc3VsdC4gSW4gdGhpcyBjYXNlLCANCj4+IGl0IGlzIGlycmVsZXZh bnQgaWYgcHJveGllcyBpbnNlcnRlZCBTLUUgaW4gdGhlIHJlcXVlc3QgLS0gdGhlIG5ldyANCj4+ IGhlYWRlciB3aWxsIG92ZXJ3cml0ZSBpdC4gUHJveGllcyBjYW4gYWxzbyBkZXRlY3QgdGhhdCBT LUUgd2lsbCBoYXZlIA0KPj4gbm8gZWZmZWN0IG9uIHRoaXMgcmVxdWVzdCBvciByZXNwb25zZSwg c2luY2UgdGhlIGV4dHJhIGhlYWRlciBpcyBwcmVzZW50Lg0KPj4NCj4+IFVBQyBhbmQgVUFTIHdp bGwga25vdyB0aGF0IHRoZXkgYmVoYXZlIHRoZSBzYW1lIHdheSBzaW5jZSB0aGV5IHdpbGwgDQo+ PiBib3RoIHNlZSB0aGlzIGhlYWRlciBvbmx5IGlmIHRoZXkgYm90aCBzdXBwb3J0IGl0Lg0KPiAN Cj4gSSdtIG5vdCBzdXJlIGEgdGFnIGFkZHMgbXVjaC4gSXQgZG9lc24ndCBkbyBhbnl0aGluZyBm b3IgcHJveGllcyB1bmxlc3Mgd2UgdXNlIFByb3h5LVJlcXVpcmUsIGFuZCB3ZSBkb24ndCB3YW50 IHRoYXQuIEFuZCB3aGF0IGRvIHlvdSBkbyBpZiB0aGUgdGFnIGlzbid0IHJlY29nbml6ZWQgYnkg dGhlIFVBUz8NCj4gDQo+IElTVE0gYSB3YXkgdG8gYXBwcm9hY2ggdGhpcyBpcyB0byBmaXJzdCBz cGVjaWZ5IG91ciBwcm9wb3NlZCBiZWhhdmlvciAoYXMgaW4gKDEpIG9yICgyKSkuIFRoZW4gd2Ug bmVlZCB0byBhbmFseXplIGl0IGluIHRoZSBwcmVzZW5jZSBvZiBvbmUgb3IgbW9yZSBjb21wb25l bnRzIHRoYXQgZG9uJ3QgaW1wbGVtZW50IHRoZSByZXZpc2lvbiwgYW5kIHdpdGggdmFyaW91cyBw bGF1c2libGUgaW50ZXJwcmV0YXRpb25zIG9mIHRoZSBleGlzdGluZyBhbWJpZ3VvdXMgc3BlY2lm aWNhdGlvbi4NCj4gDQo+IEFuZCB0aGVuIHNlZSBpZiB0aGUgcmVzdWx0IGlzIGFueSB3b3JzZSBm b3IgYW55IGNvbXBvbmVudHMgd2l0aCB0aGUgDQo+IHJldmlzaW9uIHRoYW4gaXQgaXMgd2l0aG91 dCBpdC4gKEFuZCBJIGd1ZXNzIHdlIHNob3VsZCBhbHNvIGZpZ3VyZSBvdXQgDQo+IGlmIGl0IGlz IGFueSAqYmV0dGVyKiBiZWZvcmUgZ29pbmcgYWhlYWQgYW5kIGRvaW5nIHRoaXMuKQ0KPiANCj4g CVRoYW5rcywNCj4gCVBhdWwNCj4gDQoNCg== From nobody Sun Nov 19 12:25:56 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 7F0A0126CF6 for ; Sun, 19 Nov 2017 12:25:55 -0800 (PST) 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 V6Cm8mg9vS_A for ; Sun, 19 Nov 2017 12:25:54 -0800 (PST) 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 10EAB124BFA for ; Sun, 19 Nov 2017 12:25:53 -0800 (PST) X-AuditID: 1207440f-a43ff70000007960-84-5a11e8ceb5de 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 A2.25.31072.FC8E11A5; Sun, 19 Nov 2017 15:25:52 -0500 (EST) 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 vAJKPnsh004452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 19 Nov 2017 15:25:49 -0500 To: Christer Holmberg , Roman Shpount Cc: "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Sun, 19 Nov 2017 15:25:49 -0500 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: <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixO6iqHvhhWCUwexmMYsLMw8zWjTd6WKz mHFhKrPF1x+b2BxYPH59vcrmsWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBlfFvxh72g w7Ti0v1G9gbGXZpdjJwcEgImEotn32DpYuTiEBLYwSQx88INVgjnIZNE+8b/TCBVwgIaEof2 /Aaq4uAQEUiSONZdAhJmFoiSaNmwlw2i/iOrRM/tyWD1bAJaEnMO/Qer5xWwl+icZAESZhFQ lfg7fxE7iC0qkCZxZ8ZDsHJeAUGJkzOfsIDYnAJ+EtumtjNDzDeTmLf5IZQtLnHryXwmCFte onnrbOYJjAKzkLTPQtIyC0nLLCQtCxhZVjHKJeaU5urmJmbmFKcm6xYnJ+blpRbpmujlZpbo paaUbmKEBDn/Dsau9TKHGAU4GJV4eC26BKKEWBPLiitzDzFKcjApifIeXM8fJcSXlJ9SmZFY nBFfVJqTWnyIUYKDWUmE19JFMEqINyWxsiq1KB8mJc3BoiTOq75E3U9IID2xJDU7NbUgtQgm K8PBoSTBe/k5UKNgUWp6akVaZk4JQpqJgxNkOA/Q8BqQGt7igsTc4sx0iPwpRleOnp4bf5g4 Ht24CyQ3fH8AJJ/NfN3AzDHv+LcmZiGWvPy8VClx3l6QZgGQ5ozSPLj5sGT2ilEc6F1hXilg ahPiASZCuA2vgJYzAS13ucAPsrwkESEl1cA4OZPHLEKq+canCM0jouy8vRr7ObSnqDz7yyj5 XniXXdPtiw9m2vfXO3b0/FJ5ZirKKJXhLb779JLmf7ZO9kc599ok3dcpne97RLr2xfxmC1MH g58dM2QtdVL2Lvx1774qa0HYT/89mSxryretf5n//YiE6fVLF7d5Rx1znGXhdiHG/+DDN3FK LMUZiYZazEXFiQCKF/+6QQMAAA== 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, 19 Nov 2017 20:25:55 -0000 On 11/18/17 9:36 PM, Christer Holmberg wrote: > Hi, > >>> I agree with Paul that new option-tags etc aren't going to help. Also, in general, I think we >>> should try to limit to impacts on different types of nodes. >>> >>> One suggestion would be to forbid the usage of UPDATE to change the refresher. If an endpoint >>> wants to change the refresher it MUST send a (re-)INVITE to do so. And, new endpoints could discard >>> the refresher value in received UPDATEs, which means they would work with legacy endpoints that may >>> try to change the refresher in an UPDATE. >>> >>> That way we may not have to separate UPDATEs sent inside INVITE transactions and UPDATEs sent outside INVITE transactions. >>> >>> I think Paul more or less suggested the same thing earlier ("the peer must mirror the refresher value"), eventhough >>> I believe he was only talking about UPDATEs inside INVITE transaction. >> >> UPDATE *within* INVITE and UPDATE *outside* INVITE are two distinct cases. Banning use of UPDATE outside for >> this purpose is a more extreme case. (IMO, once you have a session, using an offerless UPDATE for s-t refreshes is >> preferable unless you happen to also need a concurrent O/A.) > > I am not suggesting that we ban usage of UPDATE for s-t refreshes. My suggestion is that we ban usage of UPDATE for changing the refresher role (uac->uas etc). (I figured you were going to say that.) The problem with that is that the rules are then even more complicated. If the refresher parameter is omitted then it is offering to negotiate who does it. If it includes the refresher parameter then what value it uses has to be compared to the last negotiated refresher to determine if this is a change. As the rfc is written it only discusses what should be done when refreshing. It doesn't explicitly talk about cases where reINVITE/UPDATE are being used primarily for other purposes. The case where the end that is *not* the refresher needs to send a reINVITE/UPDATE should be explicitly discussed. Such a case *does* refresh (or cancel) the session timer, and does have the potential to reassign the refresher. IMO it is easier (and will make for clearer text) to make the UPDATE within INVITE the special case, and leave UPDATE outside of INVITE alone. Thanks, Paul > Regards, > > Christer > > > > > > > So I hesitate to ban that case unless allowing it causes some problem. > The only possible problem I can see is if the two ends might disagree on whether the UPDATE is within an INVITE. This might occur if one end sends reINVITE and the other sends UPDATE more-or-less concurrently. But ISTM that case should be treated as glare. I think this can be covered by adding some text to the new draft talking about this case and spelling out that 491 should be used if this occurs. > > Thanks, > Paul > >> That would at least solve the problem that originally triggered all this. And, at least in the deployment I am aware of it would only impact an application server - there would be no need to change any proxies or terminals. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 02 November 2017 23:48 >> To: Roman Shpount >> Cc: Christer Holmberg ; Jesske, Roland >> ; sipcore@ietf.org >> Subject: Re: [sipcore] Session timer fix >> >> On 11/2/17 5:27 PM, Roman Shpount wrote: >>> On Thu, Nov 2, 2017 at 5:07 PM, Paul Kyzivat >> > wrote: >>> >>> And IMO this needs to have well defined behavior even if there is a >>> proxy that doesn't support this revision. >>> >>> I've been evolving my thinking as this discussion has continued. I >>> see a couple of ways to go: >>> >>> 1) Specify that the negotiation in the INVITE transaction should be >>> unaffected by whatever happens in an intervening UPDATE. Also >>> specify how timer stuff should be handled in an UPDATE within an >>> INVITE. For that I think what we have been converging on is: >>> >>> - the UAC and proxies for the embedded UPDATE should not include S-E; >>> - the UAS should not include S-E in the UPDATE response, >>>   even if it gets one in the request; >>> - proxies should not add an S-E to an embedded UPDATE response; >>> - the UAC should ignore S-E in an embedded UPDATE response. >>> >>> But the key here is the UAC ignoring it. >>> >>> 2) Specify that a UAC or proxy should duplicate in an embedded >>> UPDATE whatever timer stuff they put in the enclosing INVITE >>> transaction. And then the UAC for the INVITE should process the >>> timer stuff in the 2xx response to the INVITE the same as if the >>> UPDATE didn't happen. (What it does to process the timer stuff in >>> the 200 for the UPDATE is irrelevant.) >>> >>> I think (1) is closer to what we have been converging on. But I am >>> now thinking that (2) is more robust in the presence of some >>> components that don't implement the revision. >>> >>> >>> There are two requirements for this work: >>> >>> 1. UAC must ignore the S-T negotiation result when UPDATE is within >>> INVITE transaction 2. UAC and UAS mast agree on the negotiation >>> results. >>> >>> I was thinking that including some sort of header (or supported tag) >>> in the UPDATE request and mirroring the same header (or tag) in the >>> response would be the best way to achieve this result. In this case, >>> it is irrelevant if proxies inserted S-E in the request -- the new >>> header will overwrite it. Proxies can also detect that S-E will have >>> no effect on this request or response, since the extra header is present. >>> >>> UAC and UAS will know that they behave the same way since they will >>> both see this header only if they both support it. >> >> I'm not sure a tag adds much. It doesn't do anything for proxies unless we use Proxy-Require, and we don't want that. And what do you do if the tag isn't recognized by the UAS? >> >> ISTM a way to approach this is to first specify our proposed behavior (as in (1) or (2)). Then we need to analyze it in the presence of one or more components that don't implement the revision, and with various plausible interpretations of the existing ambiguous specification. >> >> And then see if the result is any worse for any components with the >> revision than it is without it. (And I guess we should also figure out >> if it is any *better* before going ahead and doing this.) >> >> Thanks, >> Paul >> > From nobody Sun Nov 19 21:26: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 505D7124D68 for ; Sun, 19 Nov 2017 21:26:30 -0800 (PST) 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 srYQgfsW0bdi for ; Sun, 19 Nov 2017 21:26:28 -0800 (PST) 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 3297B124239 for ; Sun, 19 Nov 2017 21:26:27 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-a1-5a126782d2c9 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.40.08439.287621A5; Mon, 20 Nov 2017 06:26:26 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Mon, 20 Nov 2017 06:26:25 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount CC: "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UA== Date: Mon, 20 Nov 2017 05:26:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbHdTLcpXSjK4PQXYYsVGw6wWjTd6WKz mHFhKrPF1x+b2BxYPP6+/8DksWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBl/FyjUrDH p+JiXyNrA+MBry5GTg4JAROJ5a/amEFsIYHDjBKtq527GLmA7CWMEr+OzWLtYuTgYBOwkOj+ pw1SIyLgLTFh/mo2EJtZIFhiw/0JYL3CAhoSn+deZoao0ZS4eGoZE4SdJXH7wFlGEJtFQFXi 3pE+sDivgK/Ege4rrBC7lrNJ/Hjzhh0kwSngIPHn/FywQYwCYhLfT61hglgmLnHryXwmiKMF JJbsOc8MYYtKvHz8jxXCVpJYe3g7C8jNzEBHrN+lD9GqKDGl+yE7xF5BiZMzn7BMYBSdhWTq LISOWUg6ZiHpWMDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMIoObvmtuoPx8hvHQ4wC HIxKPLy5DkJRQqyJZcWVuYcYJTiYlUR41aKAQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJG CQmkJ5akZqemFqQWwWSZODilGhjF50x9fKjHr7juwZu7i+uWT1dhnMJ1hJnfvZVbKbDY2IH/ +4lUX/t0u78ZC7NzFtiuN7vyXistw/dF1dx5dcdq+iYHha/mazieeejv/S+HlCudHgcVbPD5 /85+2383TeH2fdeiKxNP/EphPcHFJhdnxfxGecbmOCeWh0cNv+zcyxee/GzVmXtKLMUZiYZa zEXFiQBgqV4IngIAAA== 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, 20 Nov 2017 05:26:30 -0000 SGksDQoNCj4+Pj4gSSBhZ3JlZSB3aXRoIFBhdWwgdGhhdCBuZXcgb3B0aW9uLXRhZ3MgZXRjIGFy ZW4ndCBnb2luZyB0byBoZWxwLiANCj4+Pj4gQWxzbywgaW4gZ2VuZXJhbCwgSSB0aGluayB3ZSBz aG91bGQgdHJ5IHRvIGxpbWl0IHRvIGltcGFjdHMgb24gZGlmZmVyZW50IHR5cGVzIG9mIG5vZGVz Lg0KPj4+Pg0KPj4+PiBPbmUgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBmb3JiaWQgdGhlIHVzYWdl IG9mIFVQREFURSB0byBjaGFuZ2UgdGhlIA0KPj4+PiByZWZyZXNoZXIuIElmIGFuIGVuZHBvaW50 IHdhbnRzIHRvIGNoYW5nZSB0aGUgcmVmcmVzaGVyIGl0IE1VU1Qgc2VuZCANCj4+Pj4gYSAocmUt KUlOVklURSB0byBkbyBzby4gQW5kLCBuZXcgZW5kcG9pbnRzIGNvdWxkIGRpc2NhcmQgdGhlIA0K Pj4+PiByZWZyZXNoZXIgdmFsdWUgaW4gcmVjZWl2ZWQgVVBEQVRFcywgd2hpY2ggbWVhbnMgdGhl eSB3b3VsZCB3b3JrIHdpdGggbGVnYWN5IGVuZHBvaW50cyB0aGF0IG1heSB0cnkgdG8gY2hhbmdl IHRoZSByZWZyZXNoZXIgaW4gYW4gVVBEQVRFLg0KPj4+Pg0KPj4+PiBUaGF0IHdheSB3ZSBtYXkg bm90IGhhdmUgdG8gc2VwYXJhdGUgVVBEQVRFcyBzZW50IGluc2lkZSBJTlZJVEUgdHJhbnNhY3Rp b25zIGFuZCBVUERBVEVzIHNlbnQgb3V0c2lkZSBJTlZJVEUgdHJhbnNhY3Rpb25zLg0KPj4+Pg0K Pj4+PiBJIHRoaW5rIFBhdWwgbW9yZSBvciBsZXNzIHN1Z2dlc3RlZCB0aGUgc2FtZSB0aGluZyBl YXJsaWVyICgidGhlIA0KPj4+PiBwZWVyIG11c3QgbWlycm9yIHRoZSByZWZyZXNoZXIgdmFsdWUi KSwgZXZlbnRob3VnaCBJIGJlbGlldmUgaGUgd2FzIG9ubHkgdGFsa2luZyBhYm91dCBVUERBVEVz IGluc2lkZSBJTlZJVEUgdHJhbnNhY3Rpb24uDQo+Pj4NCj4+PiBVUERBVEUgKndpdGhpbiogSU5W SVRFIGFuZCBVUERBVEUgKm91dHNpZGUqIElOVklURSBhcmUgdHdvIGRpc3RpbmN0IA0KPj4+IGNh c2VzLiBCYW5uaW5nIHVzZSBvZiBVUERBVEUgb3V0c2lkZSBmb3IgdGhpcyBwdXJwb3NlIGlzIGEg bW9yZSANCj4+PiBleHRyZW1lIGNhc2UuIChJTU8sIG9uY2UgeW91IGhhdmUgYSBzZXNzaW9uLCB1 c2luZyBhbiBvZmZlcmxlc3MgDQo+Pj4gVVBEQVRFIGZvciBzLXQgcmVmcmVzaGVzIGlzIHByZWZl cmFibGUgdW5sZXNzIHlvdSBoYXBwZW4gdG8gYWxzbyBuZWVkIA0KPj4+IGEgY29uY3VycmVudCBP L0EuKQ0KPj4gDQo+PiBJIGFtIG5vdCBzdWdnZXN0aW5nIHRoYXQgd2UgYmFuIHVzYWdlIG9mIFVQ REFURSBmb3Igcy10IHJlZnJlc2hlcy4gTXkgc3VnZ2VzdGlvbiBpcyB0aGF0IHdlIGJhbiANCj4+ IHVzYWdlIG9mIFVQREFURSBmb3IgY2hhbmdpbmcgdGhlIHJlZnJlc2hlciByb2xlICh1YWMtPnVh cyBldGMpLg0KPg0KPiAoSSBmaWd1cmVkIHlvdSB3ZXJlIGdvaW5nIHRvIHNheSB0aGF0LikNCj4N Cj4gVGhlIHByb2JsZW0gd2l0aCB0aGF0IGlzIHRoYXQgdGhlIHJ1bGVzIGFyZSB0aGVuIGV2ZW4g bW9yZSBjb21wbGljYXRlZC4gDQo+IElmIHRoZSByZWZyZXNoZXIgcGFyYW1ldGVyIGlzIG9taXR0 ZWQgdGhlbiBpdCBpcyBvZmZlcmluZyB0byBuZWdvdGlhdGUgd2hvIGRvZXMgaXQuIElmIGl0IGlu Y2x1ZGVzIHRoZSANCj4gcmVmcmVzaGVyIHBhcmFtZXRlciB0aGVuIHdoYXQgdmFsdWUgaXQgdXNl cyBoYXMgdG8gYmUgY29tcGFyZWQgdG8gdGhlIGxhc3QgbmVnb3RpYXRlZCByZWZyZXNoZXIgdG8g ZGV0ZXJtaW5lIGlmIHRoaXMgaXMgYSBjaGFuZ2UuDQoNClRoZSByZWNlaXZlciBhbnl3YXkgbmVl ZHMgdG8gaGF2ZSB0aGUgcHJldmlvdXNseSBuZWdvdGlhdGVkIHZhbHVlIHN0b3JlZCwgaW4gb3Jk ZXIgdG8ga25vdyB3aGV0aGVyIGl0IGlzIHRoZSByZWZyZXNoZXIgb3Igbm90Lg0KDQo+IEFzIHRo ZSByZmMgaXMgd3JpdHRlbiBpdCBvbmx5IGRpc2N1c3NlcyB3aGF0IHNob3VsZCBiZSBkb25lIHdo ZW4gcmVmcmVzaGluZy4gSXQgZG9lc24ndCBleHBsaWNpdGx5IHRhbGsgYWJvdXQgY2FzZXMgd2hl cmUgcmVJTlZJVEUvVVBEQVRFDQo+IGFyZSBiZWluZyB1c2VkIHByaW1hcmlseSBmb3Igb3RoZXIg cHVycG9zZXMuIFRoZSBjYXNlIHdoZXJlIHRoZSBlbmQgdGhhdCBpcyAqbm90KiB0aGUgcmVmcmVz aGVyIG5lZWRzIHRvIHNlbmQgYSByZUlOVklURS9VUERBVEUgc2hvdWxkDQo+IGJlIGV4cGxpY2l0 bHkgZGlzY3Vzc2VkLiBTdWNoIGEgY2FzZSAqZG9lcyogcmVmcmVzaCAob3IgY2FuY2VsKSB0aGUg c2Vzc2lvbiB0aW1lciwgYW5kIGRvZXMgaGF2ZSB0aGUgcG90ZW50aWFsIHRvIHJlYXNzaWduIHRo ZSByZWZyZXNoZXIuDQoNCk5vdCBpZiB0aGV5IGRvbid0IGNoYW5nZSB0aGUgdmFsdWUuDQoNCkFu ZCwgaWYgYW4gVVBEQVRFIGlzIHNlbnQgd2l0aG91dCB0aGUgcmVmcmVzaGVyIHZhbHVlLCB0aGUg cmVjZWl2ZXIgd291bGQgbm90IGJlIGFsbG93ZWQgdG8gY2hhbmdlIHRoZSBwcmV2aW91c2x5IG5l Z290aWF0ZWQgb25lLg0KDQo+IElNTyBpdCBpcyBlYXNpZXIgKGFuZCB3aWxsIG1ha2UgZm9yIGNs ZWFyZXIgdGV4dCkgdG8gbWFrZSB0aGUgVVBEQVRFIHdpdGhpbiBJTlZJVEUgdGhlIHNwZWNpYWwg Y2FzZSwgYW5kIGxlYXZlIFVQREFURSBvdXRzaWRlIG9mIElOVklURSBhbG9uZS4NCg0KU28sIGp1 c3QgdG8gbWFrZSBzdXJlIHdlIGFyZSBvbmUgdGhlIHNhbWUgcGFnZSwgaG93IHdvdWxkIHRoYXQg c3BlY2lhbCBjYXNlIHdvcms/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KPiAN Cj4gU28gSSBoZXNpdGF0ZSB0byBiYW4gdGhhdCBjYXNlIHVubGVzcyBhbGxvd2luZyBpdCBjYXVz ZXMgc29tZSBwcm9ibGVtLg0KPiBUaGUgb25seSBwb3NzaWJsZSBwcm9ibGVtIEkgY2FuIHNlZSBp cyBpZiB0aGUgdHdvIGVuZHMgbWlnaHQgZGlzYWdyZWUgb24gd2hldGhlciB0aGUgVVBEQVRFIGlz IHdpdGhpbiBhbiBJTlZJVEUuIFRoaXMgbWlnaHQgb2NjdXIgaWYgb25lIGVuZCBzZW5kcyByZUlO VklURSBhbmQgdGhlIG90aGVyIHNlbmRzIFVQREFURSBtb3JlLW9yLWxlc3MgY29uY3VycmVudGx5 LiBCdXQgSVNUTSB0aGF0IGNhc2Ugc2hvdWxkIGJlIHRyZWF0ZWQgYXMgZ2xhcmUuIEkgdGhpbmsg dGhpcyBjYW4gYmUgY292ZXJlZCBieSBhZGRpbmcgc29tZSB0ZXh0IHRvIHRoZSBuZXcgZHJhZnQg dGFsa2luZyBhYm91dCB0aGlzIGNhc2UgYW5kIHNwZWxsaW5nIG91dCB0aGF0IDQ5MSBzaG91bGQg YmUgdXNlZCBpZiB0aGlzIG9jY3Vycy4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPj4g VGhhdCB3b3VsZCBhdCBsZWFzdCBzb2x2ZSB0aGUgcHJvYmxlbSB0aGF0IG9yaWdpbmFsbHkgdHJp Z2dlcmVkIGFsbCB0aGlzLiBBbmQsIGF0IGxlYXN0IGluIHRoZSBkZXBsb3ltZW50IEkgYW0gYXdh cmUgb2YgaXQgd291bGQgb25seSBpbXBhY3QgYW4gYXBwbGljYXRpb24gc2VydmVyIC0gdGhlcmUg d291bGQgYmUgbm8gbmVlZCB0byBjaGFuZ2UgYW55IHByb3hpZXMgb3IgdGVybWluYWxzLg0KPj4N Cj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQu ZWR1XQ0KPj4gU2VudDogMDIgTm92ZW1iZXIgMjAxNyAyMzo0OA0KPj4gVG86IFJvbWFuIFNocG91 bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KPj4gQ2M6IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBKZXNza2UsIA0KPj4gUm9sYW5kIDxSLkplc3NrZUB0 ZWxla29tLmRlPjsgc2lwY29yZUBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBT ZXNzaW9uIHRpbWVyIGZpeA0KPj4NCj4+IE9uIDExLzIvMTcgNToyNyBQTSwgUm9tYW4gU2hwb3Vu dCB3cm90ZToNCj4+PiBPbiBUaHUsIE5vdiAyLCAyMDE3IGF0IDU6MDcgUE0sIFBhdWwgS3l6aXZh dCA8cGt5eml2YXRAYWx1bS5taXQuZWR1IA0KPj4+IDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQu ZWR1Pj4gd3JvdGU6DQo+Pj4NCj4+PiAgICAgICBBbmQgSU1PIHRoaXMgbmVlZHMgdG8gaGF2ZSB3 ZWxsIGRlZmluZWQgYmVoYXZpb3IgZXZlbiBpZiB0aGVyZSBpcyBhDQo+Pj4gICAgICAgcHJveHkg dGhhdCBkb2Vzbid0IHN1cHBvcnQgdGhpcyByZXZpc2lvbi4NCj4+Pg0KPj4+ICAgICAgIEkndmUg YmVlbiBldm9sdmluZyBteSB0aGlua2luZyBhcyB0aGlzIGRpc2N1c3Npb24gaGFzIGNvbnRpbnVl ZC4gSQ0KPj4+ICAgICAgIHNlZSBhIGNvdXBsZSBvZiB3YXlzIHRvIGdvOg0KPj4+DQo+Pj4gICAg ICAgMSkgU3BlY2lmeSB0aGF0IHRoZSBuZWdvdGlhdGlvbiBpbiB0aGUgSU5WSVRFIHRyYW5zYWN0 aW9uIHNob3VsZCBiZQ0KPj4+ICAgICAgIHVuYWZmZWN0ZWQgYnkgd2hhdGV2ZXIgaGFwcGVucyBp biBhbiBpbnRlcnZlbmluZyBVUERBVEUuIEFsc28NCj4+PiAgICAgICBzcGVjaWZ5IGhvdyB0aW1l ciBzdHVmZiBzaG91bGQgYmUgaGFuZGxlZCBpbiBhbiBVUERBVEUgd2l0aGluIGFuDQo+Pj4gICAg ICAgSU5WSVRFLiBGb3IgdGhhdCBJIHRoaW5rIHdoYXQgd2UgaGF2ZSBiZWVuIGNvbnZlcmdpbmcg b24gaXM6DQo+Pj4NCj4+PiAgICAgICAtIHRoZSBVQUMgYW5kIHByb3hpZXMgZm9yIHRoZSBlbWJl ZGRlZCBVUERBVEUgc2hvdWxkIG5vdCBpbmNsdWRlIFMtRTsNCj4+PiAgICAgICAtIHRoZSBVQVMg c2hvdWxkIG5vdCBpbmNsdWRlIFMtRSBpbiB0aGUgVVBEQVRFIHJlc3BvbnNlLA0KPj4+ICAgICAg ICDCoCBldmVuIGlmIGl0IGdldHMgb25lIGluIHRoZSByZXF1ZXN0Ow0KPj4+ICAgICAgIC0gcHJv eGllcyBzaG91bGQgbm90IGFkZCBhbiBTLUUgdG8gYW4gZW1iZWRkZWQgVVBEQVRFIHJlc3BvbnNl Ow0KPj4+ICAgICAgIC0gdGhlIFVBQyBzaG91bGQgaWdub3JlIFMtRSBpbiBhbiBlbWJlZGRlZCBV UERBVEUgcmVzcG9uc2UuDQo+Pj4NCj4+PiAgICAgICBCdXQgdGhlIGtleSBoZXJlIGlzIHRoZSBV QUMgaWdub3JpbmcgaXQuDQo+Pj4NCj4+PiAgICAgICAyKSBTcGVjaWZ5IHRoYXQgYSBVQUMgb3Ig cHJveHkgc2hvdWxkIGR1cGxpY2F0ZSBpbiBhbiBlbWJlZGRlZA0KPj4+ICAgICAgIFVQREFURSB3 aGF0ZXZlciB0aW1lciBzdHVmZiB0aGV5IHB1dCBpbiB0aGUgZW5jbG9zaW5nIElOVklURQ0KPj4+ ICAgICAgIHRyYW5zYWN0aW9uLiBBbmQgdGhlbiB0aGUgVUFDIGZvciB0aGUgSU5WSVRFIHNob3Vs ZCBwcm9jZXNzIHRoZQ0KPj4+ICAgICAgIHRpbWVyIHN0dWZmIGluIHRoZSAyeHggcmVzcG9uc2Ug dG8gdGhlIElOVklURSB0aGUgc2FtZSBhcyBpZiB0aGUNCj4+PiAgICAgICBVUERBVEUgZGlkbid0 IGhhcHBlbi4gKFdoYXQgaXQgZG9lcyB0byBwcm9jZXNzIHRoZSB0aW1lciBzdHVmZiBpbg0KPj4+ ICAgICAgIHRoZSAyMDAgZm9yIHRoZSBVUERBVEUgaXMgaXJyZWxldmFudC4pDQo+Pj4NCj4+PiAg ICAgICBJIHRoaW5rICgxKSBpcyBjbG9zZXIgdG8gd2hhdCB3ZSBoYXZlIGJlZW4gY29udmVyZ2lu ZyBvbi4gQnV0IEkgYW0NCj4+PiAgICAgICBub3cgdGhpbmtpbmcgdGhhdCAoMikgaXMgbW9yZSBy b2J1c3QgaW4gdGhlIHByZXNlbmNlIG9mIHNvbWUNCj4+PiAgICAgICBjb21wb25lbnRzIHRoYXQg ZG9uJ3QgaW1wbGVtZW50IHRoZSByZXZpc2lvbi4NCj4+Pg0KPj4+DQo+Pj4gVGhlcmUgYXJlIHR3 byByZXF1aXJlbWVudHMgZm9yIHRoaXMgd29yazoNCj4+Pg0KPj4+IDEuIFVBQyBtdXN0IGlnbm9y ZSB0aGUgUy1UIG5lZ290aWF0aW9uIHJlc3VsdCB3aGVuIFVQREFURSBpcyB3aXRoaW4gDQo+Pj4g SU5WSVRFIHRyYW5zYWN0aW9uIDIuIFVBQyBhbmQgVUFTIG1hc3QgYWdyZWUgb24gdGhlIG5lZ290 aWF0aW9uIA0KPj4+IHJlc3VsdHMuDQo+Pj4NCj4+PiBJIHdhcyB0aGlua2luZyB0aGF0IGluY2x1 ZGluZyBzb21lIHNvcnQgb2YgaGVhZGVyIChvciBzdXBwb3J0ZWQgdGFnKSANCj4+PiBpbiB0aGUg VVBEQVRFIHJlcXVlc3QgYW5kIG1pcnJvcmluZyB0aGUgc2FtZSBoZWFkZXIgKG9yIHRhZykgaW4g dGhlIA0KPj4+IHJlc3BvbnNlIHdvdWxkIGJlIHRoZSBiZXN0IHdheSB0byBhY2hpZXZlIHRoaXMg cmVzdWx0LiBJbiB0aGlzIGNhc2UsIA0KPj4+IGl0IGlzIGlycmVsZXZhbnQgaWYgcHJveGllcyBp bnNlcnRlZCBTLUUgaW4gdGhlIHJlcXVlc3QgLS0gdGhlIG5ldyANCj4+PiBoZWFkZXIgd2lsbCBv dmVyd3JpdGUgaXQuIFByb3hpZXMgY2FuIGFsc28gZGV0ZWN0IHRoYXQgUy1FIHdpbGwgaGF2ZSAN Cj4+PiBubyBlZmZlY3Qgb24gdGhpcyByZXF1ZXN0IG9yIHJlc3BvbnNlLCBzaW5jZSB0aGUgZXh0 cmEgaGVhZGVyIGlzIHByZXNlbnQuDQo+Pj4NCj4+PiBVQUMgYW5kIFVBUyB3aWxsIGtub3cgdGhh dCB0aGV5IGJlaGF2ZSB0aGUgc2FtZSB3YXkgc2luY2UgdGhleSB3aWxsIA0KPj4+IGJvdGggc2Vl IHRoaXMgaGVhZGVyIG9ubHkgaWYgdGhleSBib3RoIHN1cHBvcnQgaXQuDQo+Pg0KPj4gSSdtIG5v dCBzdXJlIGEgdGFnIGFkZHMgbXVjaC4gSXQgZG9lc24ndCBkbyBhbnl0aGluZyBmb3IgcHJveGll cyB1bmxlc3Mgd2UgdXNlIFByb3h5LVJlcXVpcmUsIGFuZCB3ZSBkb24ndCB3YW50IHRoYXQuIEFu ZCB3aGF0IGRvIHlvdSBkbyBpZiB0aGUgdGFnIGlzbid0IHJlY29nbml6ZWQgYnkgdGhlIFVBUz8N Cj4+DQo+PiBJU1RNIGEgd2F5IHRvIGFwcHJvYWNoIHRoaXMgaXMgdG8gZmlyc3Qgc3BlY2lmeSBv dXIgcHJvcG9zZWQgYmVoYXZpb3IgKGFzIGluICgxKSBvciAoMikpLiBUaGVuIHdlIG5lZWQgdG8g YW5hbHl6ZSBpdCBpbiB0aGUgcHJlc2VuY2Ugb2Ygb25lIG9yIG1vcmUgY29tcG9uZW50cyB0aGF0 IGRvbid0IGltcGxlbWVudCB0aGUgcmV2aXNpb24sIGFuZCB3aXRoIHZhcmlvdXMgcGxhdXNpYmxl IGludGVycHJldGF0aW9ucyBvZiB0aGUgZXhpc3RpbmcgYW1iaWd1b3VzIHNwZWNpZmljYXRpb24u DQo+Pg0KPj4gQW5kIHRoZW4gc2VlIGlmIHRoZSByZXN1bHQgaXMgYW55IHdvcnNlIGZvciBhbnkg Y29tcG9uZW50cyB3aXRoIHRoZSANCj4+IHJldmlzaW9uIHRoYW4gaXQgaXMgd2l0aG91dCBpdC4g KEFuZCBJIGd1ZXNzIHdlIHNob3VsZCBhbHNvIGZpZ3VyZSANCj4+IG91dCBpZiBpdCBpcyBhbnkg KmJldHRlciogYmVmb3JlIGdvaW5nIGFoZWFkIGFuZCBkb2luZyB0aGlzLikNCj4+DQo+PiAJVGhh bmtzLA0KPj4gCVBhdWwNCj4+DQo+IA0KDQo= From Michael.Arnold@metaswitch.com Mon Nov 20 08:58: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 19DB0129C13 for ; Mon, 20 Nov 2017 08:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.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 8C82YmkdiwuA for ; Mon, 20 Nov 2017 08:58:40 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0107.outbound.protection.outlook.com [104.47.36.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC002129BFC for ; Mon, 20 Nov 2017 08:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+YRQt91CoW+0lsP9Qd/cg3oMh68OV4stYqIeM0wxH7c=; b=BkT7qEnXC8qUJoUSsWUKbzcabT7SXFxwCdB2cflbypy6tZLVax0kbxmcc6eJqVWEZq5JCV0dV7b2GnIDmk4mUFZ0DqZHs7mUj5bONyFW6Wg2xqhbptdAK1wNRqWZw9a6wJX93i+wQWIB9dc9XeDF9N599+jF+qsUx0HXAOepCXM= Received: from CY1PR02MB1262.namprd02.prod.outlook.com (10.163.16.155) by DM5PR02MB2841.namprd02.prod.outlook.com (10.175.86.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 20 Nov 2017 16:58:38 +0000 Received: from CY1PR02MB1262.namprd02.prod.outlook.com ([10.163.16.155]) by CY1PR02MB1262.namprd02.prod.outlook.com ([10.163.16.155]) with mapi id 15.20.0239.009; Mon, 20 Nov 2017 16:58:37 +0000 From: Mickey Arnold To: "sipcore@ietf.org" Thread-Topic: [sipcore] draft-arnold-push-notification-gateway-00 Thread-Index: AdNiG57djAiaf91/Q+iOX2phLeBj4Q== Date: Mon, 20 Nov 2017 16:58:37 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:104:4000:206e:acc6:65ce:1953:d013] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR02MB2841; 6:4E/3/IYNvyZkxJoyT2wLh9xpDYT06yKnvoTzDUT7rwJdT2EMrpYRBmvQTBDjr0vF9bHlUeF2P9nJ+LtPC358k8kVElOvulTBqtjkXBKfWSyXYezRQ7SBx5pM2WsoDkNUcnPAiwrW75wpd3Xfub/rHPRxRg/mmQGoSeEybsktEy4iIQ7Y++vulzObb66Ftjv5lmcxW5UIHZUbKRwlRIdtZWqrlSdA2FQ/9JFXhnJnhmRTNJRPWcsSY1PGngCyfH7fMMfc+LLZNzVeEIdVxjvnFtn6oiT8ttc+qL3tLKVxl4jcUAWr+QhZPMuXk41N6q2rCvt47mPeqM3rz/8Q8asH0w+TMQ750Cr85S6CZBPgiyA=; 5:l3FbD18EYvditj55WzOlfCd1vnj8eCFPVRPMAIzwMZuiEQTNv+ZxmTSyDkX5Xm5NqKeBo88e8yi36WKIe9gBcupuM5NIuPXPJkMZKLgc5v8RuwRTGPxqQHHAeCszziGuBpuVJUeorJI3wFQ2NQDjZ8W6eDEEWK4Qfggu/GUmf20=; 24:FlhLwjYL/+PFfegyMB16EgHvaLyIoi5RecBhqYiRLCtw5rsOPZELW7Gb25WGGUmkWPB/+vOHWZai9db2P7lguHTuJ1x1Y/STz1J7DVyt89A=; 7:b6H+sEGKvY1XowOKC2UG6qd+ZXMV1LC9IMh4vWhSBh+mRCloaQEQUXPqD8VozPCNXvcjT3F0M7CmvyXPfE1W47bs+pP1x2vi5z5Cyj2Ixpr6AdO8ILKOHldcOlYVVGVXGecyybbDzyTok59FZKzs9PmDCAAIGZfewIz6YgwyecY25J4+5uZ6PcRSsnRZIClf87lepdwF9nidq4fEidnKaMic7melEiztYypUHw0Kvj6mIeLZzqabgMbSsWrya4sC x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(376002)(199003)(189002)(6916009)(77096006)(8676002)(1730700003)(2351001)(5640700003)(6506006)(105586002)(6436002)(25786009)(106356001)(2906002)(5630700001)(72206003)(101416001)(5660300001)(3280700002)(7696004)(68736007)(2501003)(15650500001)(8936002)(478600001)(2420400007)(14454004)(230783001)(10710500007)(3660700001)(81156014)(81166006)(33656002)(54356999)(50986999)(413944005)(7736002)(966005)(316002)(2900100001)(74316002)(97736004)(53936002)(236005)(6306002)(86362001)(99286004)(7110500001)(189998001)(790700001)(9686003)(54896002)(606006)(55016002)(6116002)(102836003)(46800400004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR02MB2841; H:CY1PR02MB1262.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: ce1a0482-dc52-41c1-92a2-08d53037f151 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:DM5PR02MB2841; x-ms-traffictypediagnostic: DM5PR02MB2841: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Arnold@metaswitch.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(3231022)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR02MB2841; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR02MB2841; x-forefront-prvs: 04976078F0 received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR02MB12624279413816DDA61B5F37E9220CY1PR02MB1262namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce1a0482-dc52-41c1-92a2-08d53037f151 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2017 16:58:37.1532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2841 Archived-At: Subject: [sipcore] draft-arnold-push-notification-gateway-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, 20 Nov 2017 17:00:19 -0000 --_000_CY1PR02MB12624279413816DDA61B5F37E9220CY1PR02MB1262namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, We've recently been working on a mechanism of using push notification servi= ces (such as Apple's APNs) to ensure the core network is able to reliably c= ontact a SIP User Agent. We've noticed that a draft specification covering = a similar mechanism has been published in the last few months here: https:/= /tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02. Although our solution is similar to the one above there's a few differences= , with ours involving a more fully-featured network element that we've bran= ded the Push Notification Gateway (PNG). The driver behind the PNG was to a= llow interoperation with SIP UAs running on devices with limited or forbidd= en, background or scheduled processing. Rather than give a detailed rundown= of the differences in this mailing list I've uploaded an internet draft he= re https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-= gateway-00.txt outlining our solution. As a very brief intro: The SIP UA must always re-register with the network when it receives a push= notification. The PNG takes on responsibility for storing inbound messages= that would be routed to such a UA, generating a push notification to the U= A, waiting for the UA to reregister with the network (which must be via the= PNG) and then rerouting the original message to the UA if the access netwo= rk topology has changed since the last registration. This allows a high pro= bability of delivery for UAs that may not be able to notify the core networ= k of changes in its access network and doesn't rely on re-opening previousl= y closed NAT pinholes. The PNG generating a push notification can also be u= sed as a reliable mechanism to ensure that a UA that is unable to schedule = its own reregistration prompts is able to regularly register with the core = network. I hope this is a useful addition to the conversation on how best to leverag= e push notification services to improve the reliability of SIP user agents = and I'm looking forward to working with you all to agree a standard approac= h to solving this problem. I'm happy to answer any questions you may have. Thanks very much, Michael Arnold --_000_CY1PR02MB12624279413816DDA61B5F37E9220CY1PR02MB1262namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

We’ve recently been working on a mechanism of = using push notification services (such as Apple’s APNs) to ensure the= core network is able to reliably contact a SIP User Agent. We’ve not= iced that a draft specification covering a similar mechanism has been published in the last few months here: https://tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02.

 

Although our solution is similar to the one above th= ere’s a few differences, with ours involving a more fully-featured ne= twork element that we’ve branded the Push Notification Gateway (PNG).= The driver behind the PNG was to allow interoperation with SIP UAs running on devices with limited or forbidden, background or s= cheduled processing. Rather than give a detailed rundown of the differences= in this mailing list I’ve uploaded an internet draft here https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-gat= eway-00.txt outlining our solution.

 

As a very brief intro:

The SIP UA must always re-register with the network = when it receives a push notification. The PNG takes on responsibility for s= toring inbound messages that would be routed to such a UA, generating a pus= h notification to the UA, waiting for the UA to reregister with the network (which must be via the PNG) and = then rerouting the original message to the UA if the access network topolog= y has changed since the last registration. This allows a high probability o= f delivery for UAs that may not be able to notify the core network of changes in its access network and do= esn’t rely on re-opening previously closed NAT pinholes. The PNG gene= rating a push notification can also be used as a reliable mechanism to ensu= re that a UA that is unable to schedule its own reregistration prompts is able to regularly register with the core= network.

 

I hope this is a useful addition to the conversation= on how best to leverage push notification services to improve the reliabil= ity of SIP user agents and I’m looking forward to working with you al= l to agree a standard approach to solving this problem. I’m happy to answer any questions you may have.

 

Thanks very much,

 

Michael Arnold

 

 

--_000_CY1PR02MB12624279413816DDA61B5F37E9220CY1PR02MB1262namp_-- From nobody Mon Nov 20 09:40: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 9EE2B12E037 for ; Mon, 20 Nov 2017 09:40:48 -0800 (PST) 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 Q38Dcxv_N-Vd for ; Mon, 20 Nov 2017 09:40:46 -0800 (PST) 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 746E712E034 for ; Mon, 20 Nov 2017 09:40:46 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-b3-5a13139cfbed Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 09.A7.08439.C93131A5; Mon, 20 Nov 2017 18:40:44 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Mon, 20 Nov 2017 18:40:44 +0100 From: Christer Holmberg To: Mickey Arnold , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-arnold-push-notification-gateway-00 Thread-Index: AdNiG57djAiaf91/Q+iOX2phLeBj4QACnu1Q Date: Mon, 20 Nov 2017 17:40:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C00F331@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C00F331ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbE9RHeOsHCUwZpmBYvDLRvZLb7+2MTm wOSxZMlPJo+jN+cyBzBFcdmkpOZklqUW6dslcGUsWneUueC/X8XHnuPMDYzdLl2MnBwSAiYS 9xfvY+1i5OIQEjjMKHHl3m92CGcJo8SZ58+Yuxg5ONgELCS6/2mDNIgIREnsvtXHAhIWFnCU OP63HCLsJLFj4VY2CNtI4ubvn0wgNouAqsSGh1MZQWxeAV+Jj6/b2EFsIYEYiQ1ft4HZnAKx Eo8PfGAGsRkFxCS+n1oD1sssIC5x68l8Jog7BSSW7DnPDGGLSrx8/I8VwlaSaFzyhBWiPl/i 7t0JTBC7BCVOznzCMoFReBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlX MYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgRGz8Etv1V3MF5+43iIUYCDUYmHV/ydUJQQa2JZ cWXuIUYJDmYlEV61KKAQb0piZVVqUX58UWlOavEhRmkOFiVx3pOevFFCAumJJanZqakFqUUw WSYOTqkGxolmPEYm/beDg2qO87UkHM1xdvPWWG6wbh7nF9Xcpuuzp+YsP6n423DhXZ+ZF7YJ zD3edGv7278uXLHcsjf+reWOWNw2uaT45ItDAU3PU49ud3stPEk5b9fP25lcLbWCSk3Xl7KG HdzU12leUP5j2s9Fkg/+Jl0Nmmmuz+l5Sc1D1MR2r0e6qxJLcUaioRZzUXEiAKz4TxSaAgAA Archived-At: Subject: Re: [sipcore] draft-arnold-push-notification-gateway-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, 20 Nov 2017 17:40:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C00F331ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mickey, While re-registration is currently not described in the holmberg draft, I d= id talk about that during my presentation in IETF last week. So, the mechan= ism can also be used for re-registrations, and the intention is to describe= that in the next version of the draft. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Mickey Arnold Sent: 20 November 2017 18:59 To: sipcore@ietf.org Subject: [sipcore] draft-arnold-push-notification-gateway-00 Dear all, We've recently been working on a mechanism of using push notification servi= ces (such as Apple's APNs) to ensure the core network is able to reliably c= ontact a SIP User Agent. We've noticed that a draft specification covering = a similar mechanism has been published in the last few months here: https:/= /tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02. Although our solution is similar to the one above there's a few differences= , with ours involving a more fully-featured network element that we've bran= ded the Push Notification Gateway (PNG). The driver behind the PNG was to a= llow interoperation with SIP UAs running on devices with limited or forbidd= en, background or scheduled processing. Rather than give a detailed rundown= of the differences in this mailing list I've uploaded an internet draft he= re https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-= gateway-00.txt outlining our solution. As a very brief intro: The SIP UA must always re-register with the network when it receives a push= notification. The PNG takes on responsibility for storing inbound messages= that would be routed to such a UA, generating a push notification to the U= A, waiting for the UA to reregister with the network (which must be via the= PNG) and then rerouting the original message to the UA if the access netwo= rk topology has changed since the last registration. This allows a high pro= bability of delivery for UAs that may not be able to notify the core networ= k of changes in its access network and doesn't rely on re-opening previousl= y closed NAT pinholes. The PNG generating a push notification can also be u= sed as a reliable mechanism to ensure that a UA that is unable to schedule = its own reregistration prompts is able to regularly register with the core = network. I hope this is a useful addition to the conversation on how best to leverag= e push notification services to improve the reliability of SIP user agents = and I'm looking forward to working with you all to agree a standard approac= h to solving this problem. I'm happy to answer any questions you may have. Thanks very much, Michael Arnold --_000_7594FB04B1934943A5C02806D1A2204B6C00F331ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mickey,<= /span>

 

While re-registration = is currently not described in the holmberg draft, I did talk about that dur= ing my presentation in IETF last week. So, the mechanism can also be used f= or re-registrations, and the intention is to describe that in the next version of the draft.

 

Regards,

 

Christer

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Mickey Arnold
Sent: 20 November 2017 18:59
To: sipcore@ietf.org
Subject: [sipcore] draft-arnold-push-notification-gateway-00

 

Dear all,

 

We’ve recently been working on a mechanism of = using push notification services (such as Apple’s APNs) to ensure the= core network is able to reliably contact a SIP User Agent. We’ve not= iced that a draft specification covering a similar mechanism has been published in the last few months here: https://tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02.

 

Although our solution is similar to the one above th= ere’s a few differences, with ours involving a more fully-featured ne= twork element that we’ve branded the Push Notification Gateway (PNG).= The driver behind the PNG was to allow interoperation with SIP UAs running on devices with limited or forbidden, background or s= cheduled processing. Rather than give a detailed rundown of the differences= in this mailing list I’ve uploaded an internet draft here https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-gat= eway-00.txt outlining our solution.

 

As a very brief intro:

The SIP UA must always re-register with the network = when it receives a push notification. The PNG takes on responsibility for s= toring inbound messages that would be routed to such a UA, generating a pus= h notification to the UA, waiting for the UA to reregister with the network (which must be via the PNG) and = then rerouting the original message to the UA if the access network topolog= y has changed since the last registration. This allows a high probability o= f delivery for UAs that may not be able to notify the core network of changes in its access network and do= esn’t rely on re-opening previously closed NAT pinholes. The PNG gene= rating a push notification can also be used as a reliable mechanism to ensu= re that a UA that is unable to schedule its own reregistration prompts is able to regularly register with the core= network.

 

I hope this is a useful addition to the conversation= on how best to leverage push notification services to improve the reliabil= ity of SIP user agents and I’m looking forward to working with you al= l to agree a standard approach to solving this problem. I’m happy to answer any questions you may have.

 

Thanks very much,

 

Michael Arnold

 

 

--_000_7594FB04B1934943A5C02806D1A2204B6C00F331ESESSMB109erics_-- From nobody Mon Nov 20 13:18:31 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 760341241FC for ; Mon, 20 Nov 2017 13:18:30 -0800 (PST) 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 pTALvTtWLTlz for ; Mon, 20 Nov 2017 13:18:29 -0800 (PST) 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 5AA6412EAC6 for ; Mon, 20 Nov 2017 13:18:23 -0800 (PST) X-AuditID: 12074413-38bff70000007929-f8-5a13469ef50d 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 B1.94.31017.E96431A5; Mon, 20 Nov 2017 16:18:22 -0500 (EST) 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 vAKLIKmT010518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Nov 2017 16:18:21 -0500 To: Christer Holmberg , Roman Shpount Cc: "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 20 Nov 2017 16:18:20 -0500 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: <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixO6iqDvPTTjKYP5hVYsLMw8zWjTd6WKz mHFhKrPF1x+b2BxYPH59vcrmsWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBlLD7iXnCE uWJHzzPmBsZ3TF2MnBwSAiYSr/e3AdlcHEICO5gkFvb2sUE4D5kkHj5ezQxSJSygIXFoz2+W LkYODhGBJIlj3SUgYWaBKImWDXuh6l+zSWx9ep4NJMEmoCUx59B/FhCbV8Be4uiTyWBzWARU JT73NIPFRQXSJO7MeMgEUSMocXLmE7A4p4CfxNxjfUwQC8wk5m1+yAxhi0vcejIfKi4vsf3t HOYJjAKzkLTPQtIyC0nLLCQtCxhZVjHKJeaU5urmJmbmFKcm6xYnJ+blpRbpmuvlZpbopaaU bmKEBLnwDsZdJ+UOMQpwMCrx8H7gEYoSYk0sK67MPcQoycGkJMq76jdQiC8pP6UyI7E4I76o NCe1+BCjBAezkgivWhRQjjclsbIqtSgfJiXNwaIkzqu2RN1PSCA9sSQ1OzW1ILUIJivDwaEk wRvtKhwlJFiUmp5akZaZU4KQZuLgBBnOAzS8AKSGt7ggMbc4Mx0if4rRkuPGw+t/mDh6em4A yWczXzcwC7Hk5eelSonzyoE0CIA0ZJTmwc2EJa1XjOJALwrzngWp4gEmPLipr4AWMgEtdLnA D7KwJBEhJdXAKG2V//pZ3dtY2/BHkb6/j1SteVS0f+dT0VNHAw625yXfuLLKo8Dp1rm2CcEx sioMildEYgX+t/Lnq77/e09XSebJy5oznXYb2v1/1Rq4hGxdOq3X+XP+V9e+l+KOvUsv8t7d Zx9iF1sovSg6LVZc/dZ19dMmRYLfggtcWWwu/DZpWsHCys2ixFKckWioxVxUnAgARi2upTUD AAA= 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, 20 Nov 2017 21:18:30 -0000 On 11/20/17 12:26 AM, Christer Holmberg wrote: >> IMO it is easier (and will make for clearer text) to make the UPDATE within INVITE the special case, and leave UPDATE outside of INVITE alone. > > So, just to make sure we are one the same page, how would that special case work? My earlier message had a couple of alternative proposals for this: https://mailarchive.ietf.org/arch/msg/sipcore/f3whYmpCxFLfWulW7ZE3xsURQfs Thanks, Paul From nobody Mon Nov 20 23:56:56 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 04A89128DE7 for ; Mon, 20 Nov 2017 23:56:55 -0800 (PST) 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 dvyFG7Q6hq5v for ; Mon, 20 Nov 2017 23:56:53 -0800 (PST) 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 5DDF312714F for ; Mon, 20 Nov 2017 23:56:53 -0800 (PST) X-AuditID: c1b4fb2d-2ec699c000001e3d-cd-5a13dc43d9b7 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 31.1F.07741.34CD31A5; Tue, 21 Nov 2017 08:56:51 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Tue, 21 Nov 2017 08:56:50 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount CC: "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgADWOQA= Date: Tue, 21 Nov 2017 07:56:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@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: <25A6D1511FD95A4CAAB781F04B6C9EC9@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7va7zHeEog1tt8hYrNhxgtWi608Vm MePCVGaLrz82sTmwePx9/4HJY8mSn0webS8VPG5NKQhgieKySUnNySxLLdK3S+DK6DvmXjCV tWLB/KAGxqksXYycHBICJhJ7j/5i7mLk4hASOMwocWbeVSYIZwmjxImuL0AOBwebgIVE9z9t kAYRAW+JCfNXs4HYzALBEhvuT2AGsYUFNCQO7fnNAlGjKXHx1DImCLtM4uD8h2BxFgFViZaN b8FsXgFriZ0HVkHtWsguMW/WJrAGTgEHiQ0np7GC2IwCYhLfT61hglgmLnHryXwmiKsFJJbs Oc8MYYtKvHz8D6xeVEBPYsOJ2+wQcUWJq9OXQ/XqSdyYOgXqaGuJGz9/MELY2hLLFr5mhjhI UOLkzCcsExjFZyFZNwtJ+ywk7bOQtM9C0r6AkXUVo2hxanFxbrqRsV5qUWZycXF+nl5easkm RmBEHtzyW3cH4+rXjocYBTgYlXh4N58UjhJiTSwrrsw9xCjBwawkwqsWJRQlxJuSWFmVWpQf X1Sak1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgZFvSdOyl39qVj5bJR1oGfDz 2PlDxiF/9u3Q3/kif8fN+xbCdT49yiWqkZLTW4vK5yxcp97wIt6cfXorV892ndV5dU7Hapeu EIyQCyi2vOgnJqz9uO3CTMvUxvWaKhNZbp/etvnXPfONBW+bHCIE6+7ndaR6GFiV+d/fX1ze sjHLTqLF94/APiWW4oxEQy3mouJEADpXWobEAgAA 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, 21 Nov 2017 07:56:55 -0000 Hi, >>> IMO it is easier (and will make for clearer text) to make the UPDATE >>>within INVITE the special case, and leave UPDATE outside of INVITE >>>alone. >>=20 >> So, just to make sure we are one the same page, how would that special >>case work? > >My earlier message had a couple of alternative proposals for this: > >https://mailarchive.ietf.org/arch/msg/sipcore/f3whYmpCxFLfWulW7ZE3xsURQfs >From an implementation perspective, isn=B9t alternative 2 more or less what I also suggest? The only difference is that I suggest to apply to rule to every UPDATE - no matter whether it=B9s embedded in an INVITE or not. Regards, Christer From nobody Tue Nov 21 05:42: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 C3D88126E01 for ; Tue, 21 Nov 2017 05:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, 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=metaswitch.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 2NYGO7WXtB3V for ; Tue, 21 Nov 2017 05:42:13 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0138.outbound.protection.outlook.com [104.47.33.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05B61201F8 for ; Tue, 21 Nov 2017 05:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=txfweGhKssVRJ149OrjSbOGjhw1Z+NzTim0XJDcKn7I=; b=bb/69k2PMyo8l/5ynHeYOBEa7DjXK/FOSgSmFn+CQD/rugMkiaSEyVve+iIVoLy3vBgCrexN6n9QZSWLjhPge3KLp2MFuxFgBK9kYxt3Aqy8XOraiq4mK3DMbjwH2RXreTLWftCXRE9HanA7/iarcN+0+9qWc2N64ieOrevUkMM= Received: from CY1PR02MB1262.namprd02.prod.outlook.com (10.163.16.155) by CY1PR02MB1261.namprd02.prod.outlook.com (10.163.16.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 13:42:10 +0000 Received: from CY1PR02MB1262.namprd02.prod.outlook.com ([10.163.16.155]) by CY1PR02MB1262.namprd02.prod.outlook.com ([10.163.16.155]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 13:42:10 +0000 From: Mickey Arnold To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-arnold-push-notification-gateway-00 Thread-Index: AQHTYiazL4Zt3//Ns0qlUcuJiqPk5aMe2HFA Date: Tue, 21 Nov 2017 13:42:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C00F331@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C00F331@ESESSMB109.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Arnold@metaswitch.com; x-originating-ip: [2620:104:4000:206e:acc6:65ce:1953:d013] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR02MB1261; 6:rhc15opcZt0Iz9MvhnZuQF86N8xUtTf5A+oz7kVlJgClVoci56oiD4GFfTPUM8pP7dkwixhFQ/EM9KsFvoXduDOIdvj2CsiZ/gI3JO7e9n9U/K+7bNKYY0DXRkcqsaLbq3m8uIRLPQFPelvg0bj79Ob3TzZj9ssKWPqet5hYeyQDwdFCoIqjnELezu8NJW3/fagy199DXZ4LNQCXSqEacrWep7y0nqwbpS87dsYbIy8iVe9qKlxRigBGa1+0mw+5IDjQLeFGOLpahYr7Ck1B3Lxtn+pZljhedGVAIKmRzymeh3mqBd32+HejZd/Chh7Fzk0Jhe66QYRmsVFTPXWeZbuj3mkylhX2QPO1ElaNw+8=; 5:ZzaoYXAOB7/i26DO2Ixo9Km9KjOSr7+QrAFN9RXjkoRto9rVpXMeEHX0xNYWc5YRDSs5AUB8vrUeHZeL0WODWpm/V7ASyqo/BoROnULJbQU+LoHOc8gdkIcGip+iglZ3QNv67Snw9puSvtPUAdywuzaHeLgkv6uq+3RWdCZY5EM=; 24:0KRCzsPlBcMOubnxKPVjXD40Iak0kuH1bAmGVR/O5ScD1sJKed9VbP5tq2/JQoaZ4xNdjS2S2nhd28IFYhZHRpafzkJ4mDIYVJG2gV0N3gw=; 7:S2ASudkX2BlxvfoHBf0+x09jJF+ZHj+Vs/DSSDFl0ncZOKo+GiyTaIdXgHySECoojqXFy6TOamLIHiHRONzfYk7agU2D81Hzl4fCrt69bm2pmWnckP5KKiP+xsUTNCEe4BWYqCmdktktCWlWGyQfDsK1p86Ex6q1F3K4aX1d6/+CsPIYhJ25ebT77tQaj5eLeYs7V1yG+0F8fyy/g6jlw8vaJ5Js/jINWkPqgZWuKTYfio/6zUfT6aDcGpU3hDiG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 50af29f4-0ed6-43bc-9e10-08d530e5aa61 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY1PR02MB1261; x-ms-traffictypediagnostic: CY1PR02MB1261: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(48300812402016)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR02MB1261; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR02MB1261; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(51414003)(51444003)(199003)(189002)(7736002)(77096006)(606006)(53546010)(25786009)(74316002)(229853002)(9326002)(6506006)(55016002)(230783001)(966005)(316002)(7696004)(72206003)(2950100002)(14454004)(81156014)(8676002)(110136005)(102836003)(6436002)(8936002)(478600001)(3280700002)(33656002)(2900100001)(5660300001)(561944003)(236005)(101416001)(7110500001)(189998001)(99286004)(9686003)(6306002)(54896002)(3660700001)(81166006)(2501003)(53936002)(2906002)(105586002)(50986999)(86362001)(6246003)(97736004)(76176999)(54356999)(2420400007)(6116002)(790700001)(10710500007)(68736007)(15650500001)(106356001)(46800400004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR02MB1261; H:CY1PR02MB1262.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR02MB1262B2E2A84CFDAF50368A54E9230CY1PR02MB1262namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50af29f4-0ed6-43bc-9e10-08d530e5aa61 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 13:42:10.5650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1261 Archived-At: Subject: Re: [sipcore] draft-arnold-push-notification-gateway-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, 21 Nov 2017 13:42:16 -0000 --_000_CY1PR02MB1262B2E2A84CFDAF50368A54E9230CY1PR02MB1262namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks a lot for getting back to me. I'd be interested to see your presenta= tion, is it recorded anywhere? (Sorry if that's a stupid question, I'm new = to contributing here!) In any case I look forward to reading your next draft version, are you prop= osing a mechanism whereby a push notification always requires a re-register= or something else? I'd also be interested in your thoughts on holding up inbound SIP messages = and then re-routing them after the UA has re-registered, I think that's the= main remaining difference between our drafts. Apologies if I've misunderst= ood your proposal, but by the proxy sending the SIP message straight throug= h isn't there a problem if there has been a change in the UA's access netwo= rk? For example if a new NAT pinhole is opened or the mobile device has mov= ed then sending the SIP message to the original IP/port is unlikely to reac= h the UA even once it has been woken up by the notification. Looking forward to hearing back from you. Thanks very much, Michael Arnold From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 20 November 2017 17:41 To: Mickey Arnold ; sipcore@ietf.org Subject: RE: [sipcore] draft-arnold-push-notification-gateway-00 Hi Mickey, While re-registration is currently not described in the holmberg draft, I d= id talk about that during my presentation in IETF last week. So, the mechan= ism can also be used for re-registrations, and the intention is to describe= that in the next version of the draft. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Mickey Arnold Sent: 20 November 2017 18:59 To: sipcore@ietf.org Subject: [sipcore] draft-arnold-push-notification-gateway-00 Dear all, We've recently been working on a mechanism of using push notification servi= ces (such as Apple's APNs) to ensure the core network is able to reliably c= ontact a SIP User Agent. We've noticed that a draft specification covering = a similar mechanism has been published in the last few months here: https:/= /tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02. Although our solution is similar to the one above there's a few differences= , with ours involving a more fully-featured network element that we've bran= ded the Push Notification Gateway (PNG). The driver behind the PNG was to a= llow interoperation with SIP UAs running on devices with limited or forbidd= en, background or scheduled processing. Rather than give a detailed rundown= of the differences in this mailing list I've uploaded an internet draft he= re https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-= gateway-00.txt outlining our solution. As a very brief intro: The SIP UA must always re-register with the network when it receives a push= notification. The PNG takes on responsibility for storing inbound messages= that would be routed to such a UA, generating a push notification to the U= A, waiting for the UA to reregister with the network (which must be via the= PNG) and then rerouting the original message to the UA if the access netwo= rk topology has changed since the last registration. This allows a high pro= bability of delivery for UAs that may not be able to notify the core networ= k of changes in its access network and doesn't rely on re-opening previousl= y closed NAT pinholes. The PNG generating a push notification can also be u= sed as a reliable mechanism to ensure that a UA that is unable to schedule = its own reregistration prompts is able to regularly register with the core = network. I hope this is a useful addition to the conversation on how best to leverag= e push notification services to improve the reliability of SIP user agents = and I'm looking forward to working with you all to agree a standard approac= h to solving this problem. I'm happy to answer any questions you may have. Thanks very much, Michael Arnold --_000_CY1PR02MB1262B2E2A84CFDAF50368A54E9230CY1PR02MB1262namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

Thanks a lot for getting back to me. I’d be in= terested to see your presentation, is it recorded anywhere? (Sorry if that&= #8217;s a stupid question, I’m new to contributing here!)

In any case I look forward to reading your next draf= t version, are you proposing a mechanism whereby a push notification always= requires a re-register or something else?

 

I’d also be interested in your thoughts on hol= ding up inbound SIP messages and then re-routing them after the UA has re-r= egistered, I think that’s the main remaining difference between our d= rafts. Apologies if I’ve misunderstood your proposal, but by the proxy sending the SIP message straight through isn’t ther= e a problem if there has been a change in the UA’s access network? Fo= r example if a new NAT pinhole is opened or the mobile device has moved the= n sending the SIP message to the original IP/port is unlikely to reach the UA even once it has been woken up by the notifica= tion.

 

Looking forward to hearing back from you.=

 

Thanks very much,

Michael Arnold

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: 20 November 2017 17:41
To: Mickey Arnold <Michael.Arnold@metaswitch.com>; sipcore@iet= f.org
Subject: RE: [sipcore] draft-arnold-push-notification-gateway-00

 

Hi Mickey,<= /span>

 

While re-registration = is currently not described in the holmberg draft, I did talk about that dur= ing my presentation in IETF last week. So, the mechanism can also be used f= or re-registrations, and the intention is to describe that in the next version of the draft.

 

Regards,

 

Christer

 

From: sipcore [mailto:sipcor= e-bounces@ietf.org] On Behalf Of Mickey Arnold
Sent: 20 November 2017 18:59
To: sipcore@ietf.org
Subject: [sipcore] draft-arnold-push-notification-gateway-00

 

Dear all,

 

We’ve recently been working on a mechanism of = using push notification services (such as Apple’s APNs) to ensure the= core network is able to reliably contact a SIP User Agent. We’ve not= iced that a draft specification covering a similar mechanism has been published in the last few months here: https://tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02.

 

Although our solution is similar to the one above th= ere’s a few differences, with ours involving a more fully-featured ne= twork element that we’ve branded the Push Notification Gateway (PNG).= The driver behind the PNG was to allow interoperation with SIP UAs running on devices with limited or forbidden, background or s= cheduled processing. Rather than give a detailed rundown of the differences= in this mailing list I’ve uploaded an internet draft here https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-gat= eway-00.txt outlining our solution.

 

As a very brief intro:

The SIP UA must always re-register with the network = when it receives a push notification. The PNG takes on responsibility for s= toring inbound messages that would be routed to such a UA, generating a pus= h notification to the UA, waiting for the UA to reregister with the network (which must be via the PNG) and = then rerouting the original message to the UA if the access network topolog= y has changed since the last registration. This allows a high probability o= f delivery for UAs that may not be able to notify the core network of changes in its access network and do= esn’t rely on re-opening previously closed NAT pinholes. The PNG gene= rating a push notification can also be used as a reliable mechanism to ensu= re that a UA that is unable to schedule its own reregistration prompts is able to regularly register with the core= network.

 

I hope this is a useful addition to the conversation= on how best to leverage push notification services to improve the reliabil= ity of SIP user agents and I’m looking forward to working with you al= l to agree a standard approach to solving this problem. I’m happy to answer any questions you may have.

 

Thanks very much,

 

Michael Arnold

 

 

--_000_CY1PR02MB1262B2E2A84CFDAF50368A54E9230CY1PR02MB1262namp_-- From nobody Tue Nov 21 06:01: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 C23371201F8 for ; Tue, 21 Nov 2017 06:01:23 -0800 (PST) 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 Q879MDIaJFbg for ; Tue, 21 Nov 2017 06:01:21 -0800 (PST) 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 16BAF129483 for ; Tue, 21 Nov 2017 06:01:20 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-2d-5a1431af1406 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5D.30.08439.FA1341A5; Tue, 21 Nov 2017 15:01:19 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Tue, 21 Nov 2017 15:00:12 +0100 From: Christer Holmberg To: Mickey Arnold , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-arnold-push-notification-gateway-00 Thread-Index: AQHTYs6KwIKhfHkt+EOn1VBmRR7a1qMe74wA Date: Tue, 21 Nov 2017 14:00:11 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C00F331@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.17] Content-Type: multipart/alternative; boundary="_000_D639FCC52623Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7hO56Q5EogzWveS0Ot2xkt/j6YxOb A5PHkiU/mTyO3pzLHMAUxWWTkpqTWZZapG+XwJWx/eBKloKPCxkrlu1Zxd7AeLObsYuRk0NC wETi0IM7rF2MXBxCAocZJT42b2aEcJYwSuxv62DqYuTgYBOwkOj+pw3SICIQJbH7Vh8LiC0s 4Cjx5uQDVoi4k8SOhVvZIGwjif29b9lBbBYBVYnTvdfAbF4Ba4l1E/YwQ8z/zCjRumMeWIJT IFbifedfsKGMAmIS30+tYQKxmQXEJW49mc8EcamAxJI955khbFGJl4//gS0WFdCT2HDiNjvI nRICihLL++UgWhMkpi75yAixV1Di5MwnLBMYRWYhmToLSdksJGUQcQOJ9+fmM0PY2hLLFr6G svUlNn45ywhhW0scmHWOBVnNAkaOVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBMXdwy2/V HYyX3zgeYhTgYFTi4V2lIRIlxJpYVlyZe4hRgoNZSYQ3UxYoxJuSWFmVWpQfX1Sak1p8iFGa g0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgdHH2lX99+oLV1fPqb6sPePdL5asQ0bsZ+LY KqRvz35xzDQtrWBbzv21/e+WJ683Wy18+an4+3sMbeHzvgR9V15sta9Vx7bA+84F2zNx9xIm 3n/eLuYvPHUJS+Eclf2zT7lFLax3rOrvOnxPtWBKgLPKte5ApVXv556XMz7/1Ulgxqvz1V+m KhsrsRRnJBpqMRcVJwIAve5XhbUCAAA= Archived-At: Subject: Re: [sipcore] draft-arnold-push-notification-gateway-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, 21 Nov 2017 14:01:24 -0000 --_000_D639FCC52623Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mickey, > Thanks a lot for getting back to me. I=92d be interested to see your pres= entation, is it recorded anywhere? (Sorry if that=92s a stupid question, I= =92m new to contributing here!) https://play.conf.meetecho.com/Playout/?session=3DIETF100-SIPCORE-20171113-= 1740 > In any case I look forward to reading your next draft version, are you pr= oposing a mechanism whereby a push notification always requires a re-regist= er or something else? Personally I=92d be fine to always require a re-register. > I=92d also be interested in your thoughts on holding up inbound SIP messa= ges and then re-routing them after the UA has re-registered, I think that= =92s the main remaining difference between our drafts. The draft currently doesn=92t say much regarding exactly when the SIP messa= ge is forwarded, but it was commented at the meeting that we need text rega= rding that. So, if we know there will be a re-register, the proxy can wait for it befor= e forwarding the SIP message. Of course, as an optimisation, the proxy can try to forward the SIP message= even before it receives the re-register, but we don=92t need to mandate su= ch behaviour. > Apologies if I=92ve misunderstood your proposal, but by the proxy sending= the SIP message straight through isn=92t there a problem if there has been= a change in the UA=92s access network? > For example if a new NAT pinhole is opened or the mobile device has moved= then sending the SIP message to the original IP/port is unlikely to reach = the UA even once it has been woken up by the notification. Correct. And, all of that should be solved with sending re-register :) The reason I didn=92t include that in the draft so far was because I first = wanted to know whether the community has an interest to work on this to beg= in with. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 20 November 2017 17:41 To: Mickey Arnold >; sipcore@ietf.org Subject: RE: [sipcore] draft-arnold-push-notification-gateway-00 Hi Mickey, While re-registration is currently not described in the holmberg draft, I d= id talk about that during my presentation in IETF last week. So, the mechan= ism can also be used for re-registrations, and the intention is to describe= that in the next version of the draft. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Mickey Arnold Sent: 20 November 2017 18:59 To: sipcore@ietf.org Subject: [sipcore] draft-arnold-push-notification-gateway-00 Dear all, We=92ve recently been working on a mechanism of using push notification ser= vices (such as Apple=92s APNs) to ensure the core network is able to reliab= ly contact a SIP User Agent. We=92ve noticed that a draft specification cov= ering a similar mechanism has been published in the last few months here: h= ttps://tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02. Although our solution is similar to the one above there=92s a few differenc= es, with ours involving a more fully-featured network element that we=92ve = branded the Push Notification Gateway (PNG). The driver behind the PNG was = to allow interoperation with SIP UAs running on devices with limited or for= bidden, background or scheduled processing. Rather than give a detailed run= down of the differences in this mailing list I=92ve uploaded an internet dr= aft here https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notific= ation-gateway-00.txt outlining our solution. As a very brief intro: The SIP UA must always re-register with the network when it receives a push= notification. The PNG takes on responsibility for storing inbound messages= that would be routed to such a UA, generating a push notification to the U= A, waiting for the UA to reregister with the network (which must be via the= PNG) and then rerouting the original message to the UA if the access netwo= rk topology has changed since the last registration. This allows a high pro= bability of delivery for UAs that may not be able to notify the core networ= k of changes in its access network and doesn=92t rely on re-opening previou= sly closed NAT pinholes. The PNG generating a push notification can also be= used as a reliable mechanism to ensure that a UA that is unable to schedul= e its own reregistration prompts is able to regularly register with the cor= e network. I hope this is a useful addition to the conversation on how best to leverag= e push notification services to improve the reliability of SIP user agents = and I=92m looking forward to working with you all to agree a standard appro= ach to solving this problem. I=92m happy to answer any questions you may ha= ve. Thanks very much, Michael Arnold --_000_D639FCC52623Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <976171CD7FBCEE47B4505EB57599F907@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Mickey,
 

> Thanks a lot for getting back to me. I=92d be i= nterested to see your presentation, is it recorded anywhere? (Sorry if that= =92s a stupid question, I=92m new to contributing here!)


> In any case I look forward to reading your next= draft version, are you proposing a mechanism whereby a push notification a= lways requires a re-register or something else?

Personally I=92d be fine to always require a re-register.

> I=92d also be interested in your thoughts on ho= lding up inbound SIP messages and then re-routing them after the UA has re-= registered, I think that=92s the main remaining difference between our draf= ts.


The draft currently doesn=92t say much regarding exactly when the SIP messa= ge is forwarded, but it was commented at the meeting that we need text rega= rding that.

So, if we know there will be a re-register, the proxy can wait for it befor= e forwarding the SIP message. 

Of course, as an optimisation, the proxy can try to forward the SIP message= even before it receives the re-register, but we don=92t need to mandate su= ch behaviour.

> Apologies if I=92ve misunderstood your proposal= , but by the proxy sending the SIP message straight through isn=92t there a= problem if there has been a change in the UA=92s access network?

> For example if a new NAT pinhole= is opened or the mobile device has moved then sending the SIP message to t= he original IP/port is unlikely to reach the UA even once it has been woken= up by the notification.

Correct.= And, all of that should be solved with sending re-register :)

The= reason I didn=92t include that in the draft so far was because I first wan= ted to know whether the community has an interest to work on this to begin = with.

Regards,=

Christer=

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: 20 November 2017 17:41
To: Mickey Arnold <Michael.Arnold@metaswitch.com>; sipcore@ietf.org
Subject: RE: [sipcore] draft-arnold-push-notification-gateway-00

 

Hi Mickey,<= /span>

 

While re-registration = is currently not described in the holmberg draft, I did talk about that dur= ing my presentation in IETF last week. So, the mechanism can also be used f= or re-registrations, and the intention is to describe that in the next version of the draft.

 

Regards,

 

Christer

 

From: sipcore [mailto:sipcor= e-bounces@ietf.org] On Behalf Of Mickey Arnold
Sent: 20 November 2017 18:59
To: sipcore@ietf.org
Subject: [sipcore] draft-arnold-push-notification-gateway-00

 

Dear all,

 

We=92ve recently been working on a mechanism of usin= g push notification services (such as Apple=92s APNs) to ensure the core ne= twork is able to reliably contact a SIP User Agent. We=92ve noticed that a = draft specification covering a similar mechanism has been published in the last few months here: https://tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02.

 

Although our solution is similar to the one above th= ere=92s a few differences, with ours involving a more fully-featured networ= k element that we=92ve branded the Push Notification Gateway (PNG). The dri= ver behind the PNG was to allow interoperation with SIP UAs running on devices with limited or forbidden, background or s= cheduled processing. Rather than give a detailed rundown of the differences= in this mailing list I=92ve uploaded an internet draft here https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-gat= eway-00.txt outlining our solution.

 

As a very brief intro:

The SIP UA must always re-register with the network = when it receives a push notification. The PNG takes on responsibility for s= toring inbound messages that would be routed to such a UA, generating a pus= h notification to the UA, waiting for the UA to reregister with the network (which must be via the PNG) and = then rerouting the original message to the UA if the access network topolog= y has changed since the last registration. This allows a high probability o= f delivery for UAs that may not be able to notify the core network of changes in its access network and do= esn=92t rely on re-opening previously closed NAT pinholes. The PNG generati= ng a push notification can also be used as a reliable mechanism to ensure t= hat a UA that is unable to schedule its own reregistration prompts is able to regularly register with the core= network.

 

I hope this is a useful addition to the conversation= on how best to leverage push notification services to improve the reliabil= ity of SIP user agents and I=92m looking forward to working with you all to= agree a standard approach to solving this problem. I=92m happy to answer any questions you may have.=

 

Thanks very much,

 

Michael Arnold

 

 

 --_000_D639FCC52623Dchristerholmbergericssoncom_-- From nobody Tue Nov 21 06:49:31 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 86D2912949D for ; Tue, 21 Nov 2017 06:49:29 -0800 (PST) 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 lG5apdYs1xUi for ; Tue, 21 Nov 2017 06:49:28 -0800 (PST) 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 1AE7B12949A for ; Tue, 21 Nov 2017 06:49:28 -0800 (PST) X-AuditID: 12074413-38bff70000007929-00-5a143cf7c7f9 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 18.7A.31017.7FC341A5; Tue, 21 Nov 2017 09:49:27 -0500 (EST) 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 vALEnPbA027441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Nov 2017 09:49:26 -0500 To: Christer Holmberg , Roman Shpount Cc: "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <343e7d78-2961-f778-c678-a9e841a8f336@alum.mit.edu> Date: Tue, 21 Nov 2017 09:49:25 -0500 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+NgFprDKsWRmVeSWpSXmKPExsUixO6iqPvdRiTK4NBlaYsLMw8zWjTd6WKz mHFhKrPF1x+b2BxYPH59vcrmsWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBl/DpzhKng J2dF895bLA2M39m7GDk4JARMJDb/0+hi5OIQEtjBJLF76StGCOchk8SUQxtZuxg5OYQFNCQO 7fnNAtIgIpAkcay7BCTMLBAl0bJhLxtE/WV2iaVPXzCBJNgEtCTmHPrPAmLzCthL/Lv6iBnE ZhFQlTj+7yWYLSqQJnFnxkMmiBpBiZMzn4DVcwrYSPyaf4oZYoGZxLzND6FscYlbT+YzQdjy Es1bZzNPYBSYhaR9FpKWWUhaZiFpWcDIsopRLjGnNFc3NzEzpzg1Wbc4OTEvL7VI11wvN7NE LzWldBMjJMiFdzDuOil3iFGAg1GJh3eHsUiUEGtiWXFl7iFGSQ4mJVFeSVOgEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHeTFmgHG9KYmVValE+TEqag0VJnFdtibqfkEB6YklqdmpqQWoRTFaG g0NJgvebNVCjYFFqempFWmZOCUKaiYMTZDgP0HArkBre4oLE3OLMdIj8KUZjjp6eG3+YOJ7N fN3ALMSSl5+XKiXO+xSkVACkNKM0D24aLFG9YhQHek6Y1xKYtoR4gEkObt4roFVMQKt+HhcG WVWSiJCSamCsCnHdvk3fOs1gqtQqrhnBfqw+2XLHFdvONbadbb+85KjqT5nadSukeAvcyr6e 0I66Uvlu7yGF7bZb7fWape5ybfGb0WO1XXg5g6pV5L8nsk49Jk7H4ibLLpgZuVTcnmHaguVl ib7hfYsFW+vqL27i7Ah1PfpfIlJEaP8pufizL7qMqutaZJVYijMSDbWYi4oTAcg4NuAvAwAA 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, 21 Nov 2017 14:49:29 -0000 On 11/21/17 2:56 AM, Christer Holmberg wrote: > Hi, > >>>> IMO it is easier (and will make for clearer text) to make the UPDATE >>>> within INVITE the special case, and leave UPDATE outside of INVITE >>>> alone. >>> >>> So, just to make sure we are one the same page, how would that special >>> case work? >> >> My earlier message had a couple of alternative proposals for this: >> >> https://mailarchive.ietf.org/arch/msg/sipcore/f3whYmpCxFLfWulW7ZE3xsURQfs > >>From an implementation perspective, isn¹t alternative 2 more or less what > I also suggest? The only difference is that I suggest to apply to rule to > every UPDATE - no matter whether it¹s embedded in an INVITE or not. The rules in (2) don't work for UPDATEs outside an INVTE. (When sending an UPDATE *outside* an INVITE you can't include the same s-t stuff as in the *enclosing* INVITE because there is no enclosing INVITE.) Also, with an UPDATE within an INVITE, whatever happens as a result of the UPDATE will quickly be overridden when processing the 200 for the INVITE. Also, it is important here to analyze what happens when one or more of the parties in the dialog don't support this revision. I think (2) is in pretty good shape in that case. Thanks, Paul From nobody Tue Nov 21 09:02: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 4F58E129AF3 for ; Tue, 21 Nov 2017 09:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, 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=metaswitch.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 7RBinaaXrZgk for ; Tue, 21 Nov 2017 09:02:25 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87095129B04 for ; Tue, 21 Nov 2017 09:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LTd4fz1p7p0me/fgRmYq82coqTcfjeZJ1fldkp9XlF0=; b=kyXoUgZt4nRb6U+TvaKkcE59pEKric/k6410aXIx4nCPDiD1sNDg7icSpXV4RNl3h4v29o21dXWfYomQc78sZVWhPWPQ0BIe72M4j2dVPpU6fJTZrS+W8ER3XrXb3YvHnGl/djl9zpcx8ZDQzGiPRa1GJtfgOJLg3kbXU4etUE8= Received: from CY1PR02MB1262.namprd02.prod.outlook.com (10.163.16.155) by CY1PR02MB1263.namprd02.prod.outlook.com (10.163.16.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 17:02:23 +0000 Received: from CY1PR02MB1262.namprd02.prod.outlook.com ([10.163.16.155]) by CY1PR02MB1262.namprd02.prod.outlook.com ([10.163.16.155]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 17:02:23 +0000 From: Mickey Arnold To: "sipcore@ietf.org" , Christer Holmberg Thread-Topic: [sipcore] draft-arnold-push-notification-gateway-00 Thread-Index: AQHTYiazL4Zt3//Ns0qlUcuJiqPk5aMe2HFAgAAFWYCAABu0EA== Date: Tue, 21 Nov 2017 17:02:23 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C00F331@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Arnold@metaswitch.com; x-originating-ip: [2620:104:4000:206e:acc6:65ce:1953:d013] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR02MB1263; 6:6CYMJ5C7vZ0Ut7XvlejxPZlZVgZAKdyay4Cl0YVh8lcscm63vcKtMlmw+sSfJK7Tx3RlHzWovvrQG2soZrJN7Z3XQIJ+CV74IuW3XzvJqPN2W1FuzZYqFepFv9UcznOj7ptTsc1mjBqLS2CybVXrIijnDqj7rcVbybJ9GEkeHOQtebD9mWZ+aYXVUuV+x6H0n6XGopEsV8s5oJXpK6/wXaj3hqcLiuUkbVIjN8wImnDgkVveI2PyuubIm09sPJ4dTn/VPp9ljYHQrmxSj5az+s8m3eA9KdoddjsV8us7FG6u2vucnsB08LiuG6YaNe0ljCujWd+4wCZivP6u8xe3QkK61VpweXzo5GvgLG2n6Wg=; 5:vFjJ4GsxCnWmpd74cVEygHOAfO9XzJD/FMl3I+KF3STmAJQ6heQfeOhNsv+cXDgfugNPv1bD9aZZsIfYpPVHosDTEjt+FDTKKd2CWDGKWqpIVwX6QjCHpmjpQgnzWJvzF+7iAIDTDmLyW6tgqPwM2SVwetbd5tLhJbCf+JAkE7g=; 24:1ftgVsO5gCRjFgrejQzrt411ig9sHVuVpcmE4I8DPIBTcuCZhFyBFNfyrXDayQWoJoPoKK0/xrUikak2aqht8H6PiCH90Ea1pay4i4xDk1Y=; 7:qyb66tqEYa+ZVN0DMVnFw15ORTHtoe5oD6JIby+NYLneW4YWTF+C08LzeEEEAlzMGIcLi7an/IkaEN8IC2Y0gs3sEbVjOLuaLdSAr++ADNfDYithk7FtNs0PRZYaE11aj05K17ozYZ3oDzSNN+6zxwUvqhTvlgrxbIVvq4ACCz/RcG8ueQ9v8qKsxpZBlw5gZT8aX266169XMEyy70klfeBWCcWJPdWlLgXTW2ailFvm6K9VtiIvon7kfjE4gwKk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ec7e2710-8b96-44f9-ce00-08d53101a2be x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:CY1PR02MB1263; x-ms-traffictypediagnostic: CY1PR02MB1263: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(48300812402016)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(3231022)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR02MB1263; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR02MB1263; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(51444003)(189002)(199003)(51414003)(86362001)(93886005)(606006)(2501003)(6246003)(72206003)(3280700002)(5660300001)(3660700001)(316002)(53546010)(110136005)(966005)(81166006)(102836003)(6116002)(2950100002)(230783001)(14454004)(81156014)(790700001)(10710500007)(2906002)(7696004)(15650500001)(8676002)(74316002)(2900100001)(99286004)(33656002)(9686003)(106356001)(55016002)(105586002)(561944003)(8936002)(68736007)(77096006)(236005)(6506006)(54356999)(6436002)(2420400007)(53936002)(6306002)(54896002)(7736002)(25786009)(9326002)(101416001)(76176999)(50986999)(478600001)(97736004)(7110500001)(229853002)(189998001)(46800400004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR02MB1263; H:CY1PR02MB1262.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR02MB12628BA2393E86EE3FA0BA6CE9230CY1PR02MB1262namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec7e2710-8b96-44f9-ce00-08d53101a2be X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 17:02:23.6372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1263 Archived-At: Subject: Re: [sipcore] draft-arnold-push-notification-gateway-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, 21 Nov 2017 17:02:28 -0000 --_000_CY1PR02MB12628BA2393E86EE3FA0BA6CE9230CY1PR02MB1262namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks a lot for your responses and the link to the recording, they've clea= red up a lot of my concerns. Looking forward to seeing your next draft! Thanks very much, Michael Arnold From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 21 November 2017 14:00 To: Mickey Arnold ; sipcore@ietf.org Subject: Re: [sipcore] draft-arnold-push-notification-gateway-00 Hi Mickey, > Thanks a lot for getting back to me. I'd be interested to see your presen= tation, is it recorded anywhere? (Sorry if that's a stupid question, I'm ne= w to contributing here!) https://play.conf.meetecho.com/Playout/?session=3DIETF100-SIPCORE-20171113-= 1740 > In any case I look forward to reading your next draft version, are you pr= oposing a mechanism whereby a push notification always requires a re-regist= er or something else? Personally I'd be fine to always require a re-register. > I'd also be interested in your thoughts on holding up inbound SIP message= s and then re-routing them after the UA has re-registered, I think that's t= he main remaining difference between our drafts. The draft currently doesn't say much regarding exactly when the SIP message= is forwarded, but it was commented at the meeting that we need text regard= ing that. So, if we know there will be a re-register, the proxy can wait for it befor= e forwarding the SIP message. Of course, as an optimisation, the proxy can try to forward the SIP message= even before it receives the re-register, but we don't need to mandate such= behaviour. > Apologies if I've misunderstood your proposal, but by the proxy sending t= he SIP message straight through isn't there a problem if there has been a c= hange in the UA's access network? > For example if a new NAT pinhole is opened or the mobile device has moved= then sending the SIP message to the original IP/port is unlikely to reach = the UA even once it has been woken up by the notification. Correct. And, all of that should be solved with sending re-register :) The reason I didn't include that in the draft so far was because I first wa= nted to know whether the community has an interest to work on this to begin= with. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 20 November 2017 17:41 To: Mickey Arnold >; sipcore@ietf.org Subject: RE: [sipcore] draft-arnold-push-notification-gateway-00 Hi Mickey, While re-registration is currently not described in the holmberg draft, I d= id talk about that during my presentation in IETF last week. So, the mechan= ism can also be used for re-registrations, and the intention is to describe= that in the next version of the draft. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Mickey Arnold Sent: 20 November 2017 18:59 To: sipcore@ietf.org Subject: [sipcore] draft-arnold-push-notification-gateway-00 Dear all, We've recently been working on a mechanism of using push notification servi= ces (such as Apple's APNs) to ensure the core network is able to reliably c= ontact a SIP User Agent. We've noticed that a draft specification covering = a similar mechanism has been published in the last few months here: https:/= /tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02. Although our solution is similar to the one above there's a few differences= , with ours involving a more fully-featured network element that we've bran= ded the Push Notification Gateway (PNG). The driver behind the PNG was to a= llow interoperation with SIP UAs running on devices with limited or forbidd= en, background or scheduled processing. Rather than give a detailed rundown= of the differences in this mailing list I've uploaded an internet draft he= re https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-= gateway-00.txt outlining our solution. As a very brief intro: The SIP UA must always re-register with the network when it receives a push= notification. The PNG takes on responsibility for storing inbound messages= that would be routed to such a UA, generating a push notification to the U= A, waiting for the UA to reregister with the network (which must be via the= PNG) and then rerouting the original message to the UA if the access netwo= rk topology has changed since the last registration. This allows a high pro= bability of delivery for UAs that may not be able to notify the core networ= k of changes in its access network and doesn't rely on re-opening previousl= y closed NAT pinholes. The PNG generating a push notification can also be u= sed as a reliable mechanism to ensure that a UA that is unable to schedule = its own reregistration prompts is able to regularly register with the core = network. I hope this is a useful addition to the conversation on how best to leverag= e push notification services to improve the reliability of SIP user agents = and I'm looking forward to working with you all to agree a standard approac= h to solving this problem. I'm happy to answer any questions you may have. Thanks very much, Michael Arnold --_000_CY1PR02MB12628BA2393E86EE3FA0BA6CE9230CY1PR02MB1262namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

Thanks a lot for your responses and the link to the = recording, they’ve cleared up a lot of my concerns. Looking forward t= o seeing your next draft!

 

Thanks very much,

Michael Arnold

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: 21 November 2017 14:00
To: Mickey Arnold <Michael.Arnold@metaswitch.com>; sipcore@iet= f.org
Subject: Re: [sipcore] draft-arnold-push-notification-gateway-00

 

Hi Mick= ey,

 

> Thanks a lot for= getting back to me. I’d be interested to see your presentation, is i= t recorded anywhere? (Sorry if that’s a stupid question, I’m new to contributing here!)

&n= bsp;

&n= bsp;

> In any case I lo= ok forward to reading your next draft version, are you proposing a mechanis= m whereby a push notification always requires a re-register or something else?

&n= bsp;

Persona= lly I’d be fine to always require a re-register.

&n= bsp;

> I’d also b= e interested in your thoughts on holding up inbound SIP messages and then r= e-routing them after the UA has re-registered, I think that’s the main remaining difference between our drafts.

&n= bsp;

The dra= ft currently doesn’t say much regarding exactly when the SIP message = is forwarded, but it was commented at the meeting that we need text regardi= ng that.

&n= bsp;

So, if = we know there will be a re-register, the proxy can wait for it before forwa= rding the SIP message. 

&n= bsp;

Of cour= se, as an optimisation, the proxy can try to forward the SIP message even b= efore it receives the re-register, but we don’t need to mandate such = behaviour.

&n= bsp;

> Apologies if I&#= 8217;ve misunderstood your proposal, but by the proxy sending the SIP messa= ge straight through isn’t there a problem if there has been a change in the UA’s access network?

>&nb= sp;For example if a new NAT pinhole is o= pened or the mobile device has moved then sending the SIP message to the or= iginal IP/port is unlikely to reach the UA even once it has been woken up by the notification.

&n= bsp;

Correct= . And, all of that should be solved with sending re-register :)

&n= bsp;

The reason I didn&#= 8217;t include that in the draft so far was because I first wanted to know = whether the community has an interest to work on this to begin with.=

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 

Fro= m: C= hrister Holmberg [= mailto:christer.holmberg@er= icsson.com]
Sent: 20 November 2017 17:41
To: Mickey Arnold <Michael.Arnold@me= taswitch.com>; sipcore@ietf.org
Subject: RE: [sipcore] draft-arnold-push-notification-gateway-00

 

Hi Mickey,

 

While re-registrati= on is currently not described in the holmberg draft, I did talk about that = during my presentation in IETF last week. So, the mechanism can also be used for re-registrations, and the intention= is to describe that in the next version of the draft.

 

Regards,

 

Christer

 

Fro= m: s= ipcore [mailto:sipcore-bounces@ietf.org<= span lang=3D"EN-US" style=3D"font-size:10.5pt;color:black">] On Behalf Of Mickey Arnold
Sent: 20 November 2017 18:59
To: sipcore@ietf.org
Subject: [sipcore] draft-arnold-push-notification-gateway-00<= span style=3D"font-size:10.5pt;color:black">

 

Dear all,<= /span>

 

We’ve recently = been working on a mechanism of using push notification services (such as Ap= ple’s APNs) to ensure the core network is able to reliably contact a SIP User Agent. We’ve noticed that a draft spe= cification covering a similar mechanism has been published in the last few = months here: https://tools.ietf.org/html/draft-h= olmberg-sipcore-sip-push-02.

 

Although our solution= is similar to the one above there’s a few differences, with ours inv= olving a more fully-featured network element that we’ve branded the Push Notification Gateway (PNG). The driver b= ehind the PNG was to allow interoperation with SIP UAs running on devices w= ith limited or forbidden, background or scheduled processing. Rather than g= ive a detailed rundown of the differences in this mailing list I’ve uploaded an internet draft here https://datatracker.i= etf.org/doc/draft-arnold-sipcore-push-notification-gateway-00.txt outlining our solution.

 

As a very brief intro= :

The SIP UA must alway= s re-register with the network when it receives a push notification. The PN= G takes on responsibility for storing inbound messages that would be routed to such a UA, generating a push noti= fication to the UA, waiting for the UA to reregister with the network (whic= h must be via the PNG) and then rerouting the original message to the UA if= the access network topology has changed since the last registration. This allows a high probability of del= ivery for UAs that may not be able to notify the core network of changes in= its access network and doesn’t rely on re-opening previously closed = NAT pinholes. The PNG generating a push notification can also be used as a reliable mechanism to ensure that a UA = that is unable to schedule its own reregistration prompts is able to regula= rly register with the core network.

 

I hope this is a usef= ul addition to the conversation on how best to leverage push notification s= ervices to improve the reliability of SIP user agents and I’m looking forward to working with you all to a= gree a standard approach to solving this problem. I’m happy to answer= any questions you may have.

 

Thanks very much,

 

Michael Arnold

 

 

--_000_CY1PR02MB12628BA2393E86EE3FA0BA6CE9230CY1PR02MB1262namp_-- From nobody Tue Nov 21 10:32:33 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 9755F129B8D for ; Tue, 21 Nov 2017 10:32:32 -0800 (PST) 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 SgLIHXSZTl2m for ; Tue, 21 Nov 2017 10:32:31 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 090D6129B91 for ; Tue, 21 Nov 2017 10:32:30 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id z184so10808446pgd.13 for ; Tue, 21 Nov 2017 10:32:30 -0800 (PST) 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=msiqnRukmO5bvmHMbOHT+EgRI+9/jAEHJGsVo5NJfWo=; b=qrcQZiIaFIypVMxhc8ze5Zm4D5u5hSux2HCDRTnwTK18pkzDp1KZGW+SIuxbML7jJp rm0+TCcdRoEg7npA2QWKaC/cNLo21Wv3EvZCTp/3NQVxe+pnpLOL0NNrFdcBwk5dftqd 28RekuVjlsXjNgStEH6Bvr4g/lRreuHr8y9ubNuvZ6G9kOjKwd2DJOnHgmdPwylRw7BB nE56Cw68r+wYbt9DL8k59RYwHvpNLt+hN4dW0OMWpHhwJccSZo1rKp8TB7GpkSCm/r0j XhhPSamBLRmOiiazchqq9aOG0dpDOU1UptU986VyDKinrNNUDk51HZKcRW3CPh0JqIHu dTIg== 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=msiqnRukmO5bvmHMbOHT+EgRI+9/jAEHJGsVo5NJfWo=; b=g6UTdWCMemFm3xhIdEsz60NW0oY7l2fRoins94nJsuTFbv878mat2Ue6ls+ZahEYIK t69Dz4rn2FUbJsvd6brMWMcFxGOZjved3LBHzlEIoGXDmyat8rWH+7XgqYxWEeC6qqBj s5Pq8VG+4CzVt0fR6MQM/LcLNFVLMcjuLtoKH+Ynq+Cly6m21WGEivCm7zaKMvCWvGXL jU78vEyMPEuN2z+xdnmAfhPVW9p05c++Zjd1IhbN5jKhf679KzjUQHmgA/OucfBIUCKt JFVhBBZFnWy3JDw/ktb7owRRYfmODDj+/xiWfOYuu6fhsMQHvjL/cXVXVWZLwLMIOpuV qclQ== X-Gm-Message-State: AJaThX7J+PvD61TVggkCg3pMGRJEBP/YsQyycCq8YC442XBTzjXOc3v8 LVhcSvBvy3EtJIpAvTaHOAwL35S7 X-Google-Smtp-Source: AGs4zMaYO3KRbGSSgCFsxJG+T1Ad/ZM2T5mwjWD9kW7aG3h86bsSXfclIDy14OWpFhszoYu1fcbslQ== X-Received: by 10.84.236.12 with SMTP id q12mr18569091plk.314.1511289150518; Tue, 21 Nov 2017 10:32:30 -0800 (PST) Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com. [74.125.83.50]) by smtp.gmail.com with ESMTPSA id u90sm24985310pfg.106.2017.11.21.10.32.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 10:32:29 -0800 (PST) Received: by mail-pg0-f50.google.com with SMTP id c123so10811485pga.11 for ; Tue, 21 Nov 2017 10:32:28 -0800 (PST) X-Received: by 10.99.112.92 with SMTP id a28mr18425178pgn.413.1511289148690; Tue, 21 Nov 2017 10:32:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 21 Nov 2017 10:32:27 -0800 (PST) In-Reply-To: <343e7d78-2961-f778-c678-a9e841a8f336@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <343e7d78-2961-f778-c678-a9e841a8f336@alum.mit.edu> From: Roman Shpount Date: Tue, 21 Nov 2017 13:32:27 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="f403045c6b5edc58e9055e826c23" 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, 21 Nov 2017 18:32:33 -0000 --f403045c6b5edc58e9055e826c23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 21, 2017 at 9:49 AM, Paul Kyzivat wrote= : > On 11/21/17 2:56 AM, Christer Holmberg wrote: > >> Hi, >> >> IMO it is easier (and will make for clearer text) to make the UPDATE >>>>> within INVITE the special case, and leave UPDATE outside of INVITE >>>>> alone. >>>>> >>>> >>>> So, just to make sure we are one the same page, how would that special >>>> case work? >>>> >>> >>> My earlier message had a couple of alternative proposals for this: >>> >>> https://mailarchive.ietf.org/arch/msg/sipcore/f3whYmpCxFLfWu >>> lW7ZE3xsURQfs >>> >> >> From an implementation perspective, isn=C2=B9t alternative 2 more or les= s what >>> >> I also suggest? The only difference is that I suggest to apply to rule t= o >> every UPDATE - no matter whether it=C2=B9s embedded in an INVITE or not. >> > > The rules in (2) don't work for UPDATEs outside an INVTE. (When sending a= n > UPDATE *outside* an INVITE you can't include the same s-t stuff as in the > *enclosing* INVITE because there is no enclosing INVITE.) Also, with an > UPDATE within an INVITE, whatever happens as a result of the UPDATE will > quickly be overridden when processing the 200 for the INVITE. > > Also, it is important here to analyze what happens when one or more of th= e > parties in the dialog don't support this revision. I think (2) is in pret= ty > good shape in that case. > > How would the proxy know that UPDATE is outside of INVITE transaction? This is not a very simple thing to determine for the proxy, especially if it is a stateless proxies distributed across several servers. Such proxies do no track transaction state and modify all SIP messages in stateless manner. Also, If UPDATE is sent by the UAS from the INVITE transaction, there are multiple race conditions, where UPDATE can be received by the other user agent or a proxy before the 200 OK for the INVITE transaction. _____________ Roman Shpount --f403045c6b5edc58e9055e826c23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 11/21/= 17 2:56 AM, Christer Holmberg wrote:
Hi,

IMO it is easier (and will make for clearer text) to make the UPDATE
within INVITE the special case, and leave UPDATE outside of INVITE
alone.

So, just to make sure we are one the same page, how would that special
case work?

My earlier message had a couple of alternative proposals for this:

https://mailarchive.ietf.or= g/arch/msg/sipcore/f3whYmpCxFLfWulW7ZE3xsURQfs

>From an implementation perspective, isn=C2=B9t alternative 2 more or less w= hat
I also suggest? The only difference is that I suggest to apply to rule to every UPDATE - no matter whether it=C2=B9s embedded in an INVITE or not.

The rules in (2) don't work for UPDATEs outside an INVTE. (When sending= an UPDATE *outside* an INVITE you can't include the same s-t stuff as = in the *enclosing* INVITE because there is no enclosing INVITE.) Also, with= an UPDATE within an INVITE, whatever happens as a result of the UPDATE wil= l quickly be overridden when processing the 200 for the INVITE.

Also, it is important here to analyze what happens when one or more of the = parties in the dialog don't support this revision. I think (2) is in pr= etty good shape in that case.


How would the proxy know that UPDATE i= s outside of INVITE transaction? This is not a very simple thing to determi= ne for the proxy, especially if it is a stateless proxies distributed acros= s several servers. Such proxies do no track transaction state and modify al= l SIP messages in stateless manner.

Also, If UPDAT= E is sent by the UAS from the INVITE transaction, there are multiple race c= onditions, where UPDATE can be received by the other user agent or a proxy = before the 200 OK for the INVITE transaction.
_____________
Roman Shpount
=C2=A0
--f403045c6b5edc58e9055e826c23-- From nobody Tue Nov 21 10:43: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 9427712943B for ; Tue, 21 Nov 2017 10:43:43 -0800 (PST) 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 IcPsiUgXXR1A for ; Tue, 21 Nov 2017 10:43:42 -0800 (PST) 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 BE3EB129B77 for ; Tue, 21 Nov 2017 10:43:41 -0800 (PST) X-AuditID: 1207440d-853ff70000000f42-6d-5a1473db1fde 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 14.23.03906.BD3741A5; Tue, 21 Nov 2017 13:43:40 -0500 (EST) 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 vALIhZ9v007936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Nov 2017 13:43:37 -0500 To: Roman Shpount Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <343e7d78-2961-f778-c678-a9e841a8f336@alum.mit.edu> From: Paul Kyzivat Message-ID: <11aa72e3-4e36-e7b5-4922-5382698ef23e@alum.mit.edu> Date: Tue, 21 Nov 2017 13:43:35 -0500 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+NgFprLKsWRmVeSWpSXmKPExsUixO6iqHunWCTK4MQbaYsLMw8zWjTd6WKz mHFhKrPF1x+b2BxYPH59vcrmsWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBlHDirUdAv WrHnwjLWBsavfF2MHBwSAiYS65pquxi5OIQEdjBJ7P+4lBnCecgkcWX5bfYuRk4OYQENiUN7 frOA2CICqhJ/v09mAiliFpjOKPF7XhNUxz92id4fT9hAqtgEtCTmHPoP1sErYC+xZ1sPE4jN AtT9bmYHmC0qkCZxZ8ZDJogaQYmTM5+A1XMKBEr0r1sDFmcWMJOYt/khM4QtLnHryXyouLxE 89bZzBMYBWYhaZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3WLU5OzMtLLdI10svNLNFL TSndxAgJc94djP/XyRxiFOBgVOLhnZEkEiXEmlhWXJl7iFGSg0lJlFfSFCjEl5SfUpmRWJwR X1Sak1p8iFGCg1lJhNc9BijHm5JYWZValA+TkuZgURLnVVui7ickkJ5YkpqdmlqQWgSTleHg UJLg/VgE1ChYlJqeWpGWmVOCkGbi4AQZzgM03KsAZHhxQWJucWY6RP4UozFHT8+NP0wcz2a+ bmAWYsnLz0uVEue1BBknAFKaUZoHNw2Wql4xigM9J8xrA1LFA0xzcPNeAa1iAlr187gwyKqS RISUVANjecQMsbjW2nPlScxVrws/5WbclPlYW8BVuMZmX/SO1v7pDXP4d00LCNn1Pjd52/oz R5/PqFDSPnilrkrqgeaDgD+JK1bxrPlxhrdQt+TMrqteqec0zBQ0H1cdYfdZ6jufzfvuK566 lvAp+kzW095a8xW//M0eFPdXQZZ7Tm9oZZOU/upPPvFKLMUZiYZazEXFiQAvk5xUMAMAAA== 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, 21 Nov 2017 18:43:43 -0000 On 11/21/17 1:32 PM, Roman Shpount wrote: > On Tue, Nov 21, 2017 at 9:49 AM, Paul Kyzivat > wrote: > > On 11/21/17 2:56 AM, Christer Holmberg wrote: > > Hi, > > IMO it is easier (and will make for clearer text) to > make the UPDATE > within INVITE the special case, and leave UPDATE > outside of INVITE > alone. > > > So, just to make sure we are one the same page, how > would that special > case work? > > > My earlier message had a couple of alternative proposals for > this: > > https://mailarchive.ietf.org/arch/msg/sipcore/f3whYmpCxFLfWulW7ZE3xsURQfs > > > > >From an implementation perspective, isn¹t alternative 2 more or less what > > I also suggest? The only difference is that I suggest to apply > to rule to > every UPDATE - no matter whether it¹s embedded in an INVITE or not. > > > The rules in (2) don't work for UPDATEs outside an INVTE. (When > sending an UPDATE *outside* an INVITE you can't include the same s-t > stuff as in the *enclosing* INVITE because there is no enclosing > INVITE.) Also, with an UPDATE within an INVITE, whatever happens as > a result of the UPDATE will quickly be overridden when processing > the 200 for the INVITE. > > Also, it is important here to analyze what happens when one or more > of the parties in the dialog don't support this revision. I think > (2) is in pretty good shape in that case. > > > How would the proxy know that UPDATE is outside of INVITE transaction? > This is not a very simple thing to determine for the proxy, especially > if it is a stateless proxies distributed across several servers. Such > proxies do no track transaction state and modify all SIP messages in > stateless manner. Stateless proxies shouldn't be messing with session timers. Isn't the whole point that they need the session timer so they can know when to discard state? If no state then no need for the timer. > Also, If UPDATE is sent by the UAS from the INVITE transaction, there > are multiple race conditions, where UPDATE can be received by the other > user agent or a proxy before the 200 OK for the INVITE transaction. If the recipient UA gets the UPDATE before the INVITE has completed then it can reject it as glare situation. Thanks, Paul From nobody Tue Nov 21 11:06:56 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 EC87D1296D2 for ; Tue, 21 Nov 2017 11:06:54 -0800 (PST) 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 Yvj13MSwR5dX for ; Tue, 21 Nov 2017 11:06:54 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 149DD1296CD for ; Tue, 21 Nov 2017 11:06:54 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id r68so4341818pfe.10 for ; Tue, 21 Nov 2017 11:06:54 -0800 (PST) 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=Pey/3lEkVMq/EHvYZrLFO3X/CVAIFgF6LVeMxbpbgP0=; b=wIg1lDxIohIuF5vubkAZPFFCugPtKY4sOCPdvD42tFf0J+P753ANGsLHQkmA0qKase LlpoAgXoeYF6N9IOHCyhADQ/1VBj2SdRo0Sp9/9MvHL7csIavYzDqulz8HfsPRQ42J6x ntsWFVNdcliRPFs+G1enmL8wkubpaGzO0vLbMpa2/+kWOjrlffuSVLFLXQt5hfH8VEYZ M8BCVUBUBrjBlnO6svm+NTXLt+U9JKA1s+fGXAmCHq4jhtFd9uKFM/E+erOkKfVwO6Sn iX/MbnGweUZAYXKBcSFQKKD5QpKLo00upKyBisonC7icylIA7l4I7LTYKr7izJPQC7I/ RvhA== 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=Pey/3lEkVMq/EHvYZrLFO3X/CVAIFgF6LVeMxbpbgP0=; b=l1YvtQEEIflpjRi2oSkufGbKz8fEoVSnmQ1c+qBUXEIN1yfqcB/d9FitPPc89pILA5 Y2C63rktgh0WXQoWN7hMJJXNy8txV8vnEsrO5qDYecwyN8IvnXZbb/rvvT6Xct2d/cBb fgOKDdmjVjsW6mRWBDZeFqkfxJYrQDftPGOOjbfVxo9zbGYxagVtjmVu6s+hERPQFHTq A3eD4zzf5jdLw2/NYHkphfaMpY08KOJ7kRiR432zsbPibaZ3GTI2Dgby3uhf9gJy16cQ XCELCur1/8MHyUHgZ6iGAmax1osm3bPrHXxDMQNewiPBkgdmxUC9Wum2dCZgZHpvO2fk BtKQ== X-Gm-Message-State: AJaThX4y9qCS5T8lJxgBE8eEaw4BlBx7U1IUxnf+LC4xG2TZ0ciW0E9x p0KRiD/e1Wa9OqwnRs4GqLCQVZBR X-Google-Smtp-Source: AGs4zMZ3c+moByUX68bExaMW5L8V2Js+UUimS75B/a+e+hjmetMx/1JGvqP3EnSpBbnn4ZClwn8AKw== X-Received: by 10.98.69.209 with SMTP id n78mr16224147pfi.28.1511291213497; Tue, 21 Nov 2017 11:06:53 -0800 (PST) Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com. [74.125.83.53]) by smtp.gmail.com with ESMTPSA id f12sm22553291pga.7.2017.11.21.11.06.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 11:06:52 -0800 (PST) Received: by mail-pg0-f53.google.com with SMTP id p9so10892906pgc.8 for ; Tue, 21 Nov 2017 11:06:52 -0800 (PST) X-Received: by 10.84.246.18 with SMTP id k18mr7410598pll.374.1511291212638; Tue, 21 Nov 2017 11:06:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 21 Nov 2017 11:06:51 -0800 (PST) In-Reply-To: <11aa72e3-4e36-e7b5-4922-5382698ef23e@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <343e7d78-2961-f778-c678-a9e841a8f336@alum.mit.edu> <11aa72e3-4e36-e7b5-4922-5382698ef23e@alum.mit.edu> From: Roman Shpount Date: Tue, 21 Nov 2017 14:06:51 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="089e082d7458e1b1fa055e82e727" 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, 21 Nov 2017 19:06:55 -0000 --089e082d7458e1b1fa055e82e727 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 21, 2017 at 1:43 PM, Paul Kyzivat wrote: > On 11/21/17 1:32 PM, Roman Shpount wrote: > > Also, If UPDATE is sent by the UAS from the INVITE transaction, there are >> multiple race conditions, where UPDATE can be received by the other user >> agent or a proxy before the 200 OK for the INVITE transaction. >> > > If the recipient UA gets the UPDATE before the INVITE has completed then > it can reject it as glare situation. > UA might not always have a valid reason to reject the UPDATE, especially if UPDATE does not carry SDP. Even if US rejects the UPDATE, proxy would still need to deal with this ambiguity when processing the UPDATE request, which is hard to resolve even for state-full proxies that track transactions. Regards, _____________ Roman Shpount --089e082d7458e1b1fa055e82e727 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 21, 2017 at 1:43 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 11/21/17 1:32 PM, Roman Shpou= nt wrote:

Also, If UPDATE is sent by the UAS from the INVITE transaction, = there are multiple race conditions, where UPDATE can be received by the oth= er user agent or a proxy before the 200 OK for the INVITE transaction.

 If the recipient UA gets the UPDATE before the INVITE has completed then it= can reject it as glare situation.

UA m= ight not always have a valid reason to reject the UPDATE, especially if UPD= ATE does not carry SDP. Even if US rejects the UPDATE,=C2=A0 proxy would st= ill need to deal with this ambiguity when processing the UPDATE request, wh= ich is hard to resolve even for state-full proxies that track transactions.=

Regards,
_____________
Roman Shpount
=C2=A0
--089e082d7458e1b1fa055e82e727-- From nobody Tue Nov 21 12:39: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 9F672129BF3 for ; Tue, 21 Nov 2017 12:39:03 -0800 (PST) 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 fzCYFZ0yOOFo for ; Tue, 21 Nov 2017 12:39:02 -0800 (PST) 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 4299B129BFC for ; Tue, 21 Nov 2017 12:38:52 -0800 (PST) X-AuditID: 1207440f-a5bff70000007960-8b-5a148ed8b708 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 E3.EF.31072.9DE841A5; Tue, 21 Nov 2017 15:38:49 -0500 (EST) 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 vALKckqt014580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Nov 2017 15:38:47 -0500 To: Roman Shpount Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <343e7d78-2961-f778-c678-a9e841a8f336@alum.mit.edu> <11aa72e3-4e36-e7b5-4922-5382698ef23e@alum.mit.edu> From: Paul Kyzivat Message-ID: <0c032270-5b32-7a30-8f5a-898e9fe9ad7c@alum.mit.edu> Date: Tue, 21 Nov 2017 15:38:46 -0500 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+NgFprHKsWRmVeSWpSXmKPExsUixO6iqHurTyTKYGmxxYWZhxktmu50sVnM uDCV2eLrj01sDiwev75eZfNYsuQnk0fbSwWPW1MKAliiuGxSUnMyy1KL9O0SuDK2XX3OVLCb p2LJ8jnsDYyHObsYOTkkBEwk/v08ydzFyMUhJLCDSeL2+k1QzkMmiUMbpjODVAkLaEgc2vOb BcQWEVCV+Pt9MhNIEbPAdEaJ3/OaoDrOsEvsvbyPEaSKTUBLYs6h/2AdvAL2ErOWfGAFsVmA uj/v38sOYosKpEncmfGQCaJGUOLkzCdg9ZwCgRKrn+4Am8MsYCYxb/NDZghbXOLWk/lMELa8 RPPW2cwTGAVmIWmfhaRlFpKWWUhaFjCyrGKUS8wpzdXNTczMKU5N1i1OTszLSy3SNdHLzSzR S00p3cQICXR+oCvWyxxiFOBgVOLhnZEkEiXEmlhWXJl7iFGSg0lJlFfSFCjEl5SfUpmRWJwR X1Sak1p8iFGCg1lJhNc9BijHm5JYWZValA+TkuZgURLnVV+i7ickkJ5YkpqdmlqQWgSTleHg UJLgNQBGtJBgUWp6akVaZk4JQpqJgxNkOA/Q8GCQGt7igsTc4sx0iPwpRmOOnp4bf5g4ns18 3cAsxJKXn5cqJc7L0AtUKgBSmlGaBzcNlqxeMYoDPSfMyw0ykAeY6ODmvQJaxQS06udxYZBV JYkIKakGxm15Ahes7zf+u7NZo2kN55at57QFQrZbiWhs09D9dnTp9XOz3j0Q0xdXPCmr6sik kKveV334RPY/feb0rY6nV9kbOcwIdLsTo82zc2vNoupa2U3r171Zba968LZK3jOX94kLtsYZ e4k9379B/kCcb33jabMr2Xv/iPYV6l0tPKf6VeJAeJv3QyWW4oxEQy3mouJEAAInVb4xAwAA 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, 21 Nov 2017 20:39:04 -0000 On 11/21/17 2:06 PM, Roman Shpount wrote: > On Tue, Nov 21, 2017 at 1:43 PM, Paul Kyzivat > wrote: > > On 11/21/17 1:32 PM, Roman Shpount wrote: > > Also, If UPDATE is sent by the UAS from the INVITE transaction, > there are multiple race conditions, where UPDATE can be received > by the other user agent or a proxy before the 200 OK for the > INVITE transaction. > > > If the recipient UA gets the UPDATE before the INVITE has completed > then it can reject it as glare situation. > > > UA might not always have a valid reason to reject the UPDATE, especially > if UPDATE does not carry SDP. Even if US rejects the UPDATE,  proxy > would still need to deal with this ambiguity when processing the UPDATE > request, which is hard to resolve even for state-full proxies that track > transactions. I think we would need to include a new reason for generating 491 as part of this revision/clarification of s-t. IIUC your concern is with proxies (presumably dialog-stateful) that want to request a s-t and also comply with this revision. I think they actually don't need to do anything different than they are already doing unless they have *not* made a s-t request in an INVITE and then *do* decide they want to do that when an UPDATE is sent within that UPDATE. I find that to be a far fetched situation. If they simply always request the same thing in every INVITE and UPDATE that goes by then they will be in compliance. Thanks, Paul From nobody Wed Nov 22 05:17:13 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 A6A8D12943C for ; Wed, 22 Nov 2017 05:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 8LItcgIKNAkm for ; Wed, 22 Nov 2017 05:16:52 -0800 (PST) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::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 0167D129432 for ; Wed, 22 Nov 2017 05:16:52 -0800 (PST) Received: by mail-pl0-x235.google.com with SMTP id h3so726727pln.10 for ; Wed, 22 Nov 2017 05:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=fGC/5U0POdzamGp6aBUYg867D4Fqb3CoxZoJlGDCeak=; b=XSnc09eRqvTDBram1G4TZ5MGEcGQOPlDUGQY2MO1ls9F3GAbqFYTXINNO+P0AIAxkd V8SQohojcDDczmMM08dR6UuVIc/aGTvvUZiX5aybzUKnYYG7nPlBRReaOmieY0bArRAa mOUCOvKhou/xVPWJmCUDbfgEnbN4yWHOKthQ5W+yOl122DGgkpC8nRhBHfJXGxITU8U2 8A4hjhvnxaaVppzdUhS6r7ywsQGb/fiyvN2aWv/vR7f483vH/4FpE5bayNpz7sSp6L5R RzTjAo6pKuTdoYqIo7qzphWCl97Po+b1ThKZM8EOR5PJivxgUOBjKwL8TKko0x0AT0+j S/wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=fGC/5U0POdzamGp6aBUYg867D4Fqb3CoxZoJlGDCeak=; b=QkhF141Ic0+dhsANFMEvkg/3+rnxRt49Z4/7IisKoFyaIE2Y7pOm7pk7rgj7XTQeB6 zHLl5JQGI9ic5QB4hgTpSUsOsRemrLF283GQIIKX98GMzGqHVP3rFRs4IT/kI+og6W+q CsSnTRjIXtTnrB4LwIyIQ6/syvTW/BwmsXza5TO9SB+OpNmhZuCzCSkE9rL2KWDNsDH8 ubYe4fkI0KVLFR1zvdMsnYGhG+0w+qVd+dJvG441vDHlhYerrqYnOoufayN0sSMsGxjJ aHlmcgkWg7XeY6ZALnAGCQeL2CAiIXSE/zgjKXS8gDKOxUkAmLVngLf8xmcNq2oIOv8x 3SZg== X-Gm-Message-State: AJaThX5+X4Mkepi8Kiu54lyPOPEzgxWGGbsN/wd5lAkkUjoIx6IoTax2 z4RQb8JSC4tW3W2YZ1kW8hFWD6Ut X-Google-Smtp-Source: AGs4zMZQtrukiqlXxDWiXMwvwgtDQ6jwmtvrPFJLqBCPRay8G0xot/gYCI2TdWK07gSIhigH22xYAg== X-Received: by 10.84.235.135 with SMTP id p7mr17873949plk.94.1511356611076; Wed, 22 Nov 2017 05:16:51 -0800 (PST) Received: from [192.168.128.64] (123.230.37.138.er.eaccess.ne.jp. [123.230.37.138]) by smtp.gmail.com with ESMTPSA id h69sm28708417pfk.166.2017.11.22.05.16.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 05:16:50 -0800 (PST) From: =?UTF-8?B?5aWl5p2R5Ly45LqM?= To: sipcore@ietf.org Message-ID: <3b6cc11a-db9b-d708-e216-fb0750c11721@gmail.com> Date: Wed, 22 Nov 2017 22:16:44 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 171122-0, 2017/11/22), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [sipcore] Session-timer other issues 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, 22 Nov 2017 13:17:11 -0000 Hi, I have two issues regarding to RFC4028. 1. Proxy can not add or modify Min-SE-value. 8.1.  Processing of Requests A proxy MUST NOT insert a Min-SE header field or modify the value of an existing header field in a proxied request if that request contains a Supported header field with the value 'timer'. According to the above, the following flow is correct. Alice      Proxy P1     Proxy P2        Bob  |(1) INVITE  |            |            |  | k: timer   |            |            |  | SE: 3600   |            |            |  | MSE: 1800  |            |            |  |----------->|            |            |  |            |(2) INVITE  |            |  |            | k: timer   |            |  |            | SE: 3600   |            |  |            | MSE: 1800  |            |  |            |----------->|            |  |            |            |(3) INVITE  |  |            |            | k: timer   |  |            |            | SE: 2400   |  |            |            | MSE: 1800  |  |            |            |----------->|  |            |            |            |  |            |            |(4) 200 OK  |  |            |            |SE:1800     |  |            |            |<-----------|  |            |(5) 200 OK  |            |  |            |SE:1800     |            |  |            |<-----------|            |  |(6) 200 OK  |            |            |  |SE:1800     |            |            |  |<-----------|            |            | But if each policy is the table below, Proxy1 and Proxy2 can not get the desired results. +--------+--------------+ |        | local policy | +--------+--------------+ | Alice  | MSE:1800     | | Proxy1 | MSE:3600     | | Proxy2 | MSE:2400     | | Bob    | MSE:1800     | +--------+--------------+ 2. Unwilling resultfor UAC. 8.2.  Processing of Responses    If, however, the proxy remembers that    the UAC did support the session timer, additional processing is    needed.    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. According to the above description, UAC send "SE: refresher=uas", but it receive "SE: refresher=uac". Regards, Shinji --- このEメールはアバスト アンチウイルスによりウイルススキャンされています。 https://www.avast.com/antivirus From nobody Wed Nov 22 12: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 042C412EB61 for ; Wed, 22 Nov 2017 12:54:54 -0800 (PST) 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 zv7WTKIroWnP for ; Wed, 22 Nov 2017 12:54:51 -0800 (PST) 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 2B5D5129548 for ; Wed, 22 Nov 2017 12:54:51 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-2e-5a15e419c2fa Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D3.0C.08439.914E51A5; Wed, 22 Nov 2017 21:54:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Wed, 22 Nov 2017 21:54:48 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: SIP Push: Re-registration pull request Thread-Index: AdNj1B3PJZaELbiRRXGXIs0aQTVuAQ== Date: Wed, 22 Nov 2017 20:54:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0194C2@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_7594FB04B1934943A5C02806D1A2204B6C0194C2ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2K7sa7kE9EogyVtYhZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp45e9kKVipWPF+3hbWB8Y1sFyMnh4SAicTKd3uYuxi5OIQE DjNK3PrXxgjhLGGU2HXrBEsXIwcHm4CFRPc/bZAGEQFNieXftrKD2MIC+hJv5x1iBikRARq0 4a4ARImexPZ781lBbBYBVYnTXfuYQWxeAV+Jjr8tYDajgJjE91NrmEBsZgFxiVtP5jNB3CMg sWTPeWYIW1Ti5eN/rBC2ksSi25+h6vMllp18wAYxU1Di5MwnLBMYBWchGTULSdksJGUQcR2J Bbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg4B/c 8lt1B+PlN46HGAU4GJV4eOXPi0YJsSaWFVfmHmKU4GBWEuENXgAU4k1JrKxKLcqPLyrNSS0+ xCjNwaIkznvSkzdKSCA9sSQ1OzW1ILUIJsvEwSnVwJhZ4HtepU7zAYet0lZW9jlHc/0ynzx5 om2eppY377L79oa4g7OXsx17vbT5vGeMoYLq4ei3S7UZFH/W1u0KFa9y6VZbmcq9euufKEVN Oba3Uny5GX4mS3pSlY8ZrfN/YWu1Nomvt/DnxSPvGba9DHq1w8vwxCaX63PSD30KejpP8d6s LmUFWyWW4oxEQy3mouJEAPmTQTt4AgAA Archived-At: Subject: [sipcore] SIP Push: Re-registration pull request 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, 22 Nov 2017 20:54:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C0194C2ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have created a pull request, which adds text regarding re-registration to= the draft. https://github.com/cdh4u/draft-sip-push/pull/3 Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6C0194C2ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I have created a pull = request, which adds text regarding re-registration to the draft.=

 

https://github.com/cdh4u/draft-sip-pus= h/pull/3

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6C0194C2ESESSMB109erics_-- From nobody Thu Nov 23 00:42: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 E909B127978 for ; Thu, 23 Nov 2017 00:42:43 -0800 (PST) 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 zG99Hc2zpYeY for ; Thu, 23 Nov 2017 00:42:42 -0800 (PST) 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 9C1121286C7 for ; Thu, 23 Nov 2017 00:42:42 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-73-5a168a0095ef Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.4D.08439.00A861A5; Thu, 23 Nov 2017 09:42:40 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Thu, 23 Nov 2017 09:41:44 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: holmberg-sip-push-03 Thread-Index: AQHTZDbjH+bahhtpbkKBjZ0zic+Mfg== Date: Thu, 23 Nov 2017 08:41:43 +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_D63C585B263DCchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7ui5Dl1iUQcsNPYuvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8mbf6wFS3gqjtw/wtzAeJKri5GTQ0LAROLX7WlMXYxcHEIC hxklbs6axgLhLGGUaJu7i7GLkYODTcBCovufNkiDiICmxPJvW9lBbGEBA4mX15uZIeKmEg3H ljNB2HoS/85cBYuzCKhK3Ni9HczmFbCW2LagmRXEZhQQk/h+ag1YPbOAuMStJ/OZIA4SkFiy 5zwzhC0q8fLxP7B6UaCZG07cZoeIK0rsPNvODNGbILH4xjF2iPmCEidnPmGZwCg0C8nYWUjK ZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAY6hea4mO51+YkdUsYORYxShanFqclJtuZKyXWpSZ XFycn6eXl1qyiREYKwe3/FbdwXj5jeMhRgEORiUeXslCsSgh1sSy4srcQ4wSHMxKIrzi7UAh 3pTEyqrUovz4otKc1OJDjNIcLErivCc9eaOEBNITS1KzU1MLUotgskwcnFINjHpPUvTq+/9N FU+oXmJU732EUf8y5xTxVA3Bp+Lyyjqtxyqdnj3/z8SrXan6WrP/gFnN8R7B7xq9dza8bvD0 5fo6q3Cz+ILtHq97H7Cd2nvnvObcxX93rIr4+PC1hfrWyrcTL2wSFVLlD3z17P3EovownTiz XUL3o2p4hEIsV+g+1v/6lzk7TomlOCPRUIu5qDgRAPWIkXuRAgAA Archived-At: Subject: [sipcore] Draft new version: holmberg-sip-push-03 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, 23 Nov 2017 08:42:44 -0000 --_000_D63C585B263DCchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the feedback in Singapore, and on the list, I have submitted a new= version (-03) of draft-holmberg-sipcore-sip-push. The draft now also covers re-registrations: * UA performing re-registrations when a push notification is received. * Proxy forwarding SIP request when it receives the re-registration req= uest. Regards, Christer --_000_D63C585B263DCchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1AF02340C7735E458B99AC8267EFDA4A@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on the feedback in Singapore, and on the list, I have submitted = a new version (-03) of draft-holmberg-sipcore-sip-push.

The draft now also covers re-registrations:
  • UA performing re-registrations when a push notification is received.
  • Proxy forwarding SIP request when it receives the re-registration req= uest.
Regards,

Christer
--_000_D63C585B263DCchristerholmbergericssoncom_-- From nobody Thu Nov 23 00:55: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 76897127333 for ; Thu, 23 Nov 2017 00:55:45 -0800 (PST) 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 KNfkd2jASPgo for ; Thu, 23 Nov 2017 00:55:42 -0800 (PST) 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 5A220127843 for ; Thu, 23 Nov 2017 00:55:41 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-a9-5a168d0ba5b5 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 93.40.08439.B0D861A5; Thu, 23 Nov 2017 09:55:39 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Thu, 23 Nov 2017 09:55:35 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount CC: "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgADWOQCAAE9ygIAC5amA Date: Thu, 23 Nov 2017 08:55:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <343e7d78-2961-f778-c678-a9e841a8f336@alum.mit.edu> In-Reply-To: <343e7d78-2961-f778-c678-a9e841a8f336@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.146] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7sS53r1iUwYMGbYsVGw6wWjTd6WKz mHFhKrPF1x+b2BxYPP6+/8DksWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBlnF09g63g mXDFlEvb2RsYlwh3MXJySAiYSMxvaWXpYuTiEBI4zCgxefUhVghnCaPExq1H2LsYOTjYBCwk uv9pgzSICHhLTJi/mg3EZhYIlthwfwIziC0soCFxaM9vFogaTYmLp5YxgcwREWhilHixajlY EYuAqsTNpv/sIDavgLXEw6MXmCGWdXJIzHl0lBFkGaeAg8TrdwYgNYwCYhLfT61hglgmLnHr yXwmiKsFJJbsOc8MYYtKvHz8jxXEFhXQk9hw4jY7RFxJ4seGSywQvVoSX37sgzraWqLr2AYo W1FiSvdDqHsEJU7OfMIygVF8FpJ1s5C0z0LSPgtJ+ywk7QsYWVcxihanFiflphsZ66UWZSYX F+fn6eWllmxiBEblwS2/VXcwXn7jeIhRgINRiYeXqVssSog1say4MvcQowQHs5IIr3g7UIg3 JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgsEwenVAOjfNbBXz+bNZ6L rZktfsQuv2Pu3bNsRtJLX3lwa2pNmWzWHJzD+yLXdG23CveTuy5RfYxVhpdvH5N6/CHIsmpH MddZ228FhyLm8T0xPnKQV3vt/i49c9lp5TGWn/IZ09Vl0vW3SNmLGanZtq97yfji0GMxRm+b +iaWfx6sHktf1noVX2Lak6LEUpyRaKjFXFScCAADqhqlxgIAAA== 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, 23 Nov 2017 08:55:45 -0000 SGksDQoNCj4+Pj4+SU1PIGl0IGlzIGVhc2llciAoYW5kIHdpbGwgbWFrZSBmb3IgY2xlYXJlciB0 ZXh0KSB0byBtYWtlIHRoZSBVUERBVEUNCj4+Pj4+IHdpdGhpbiBJTlZJVEUgdGhlIHNwZWNpYWwg Y2FzZSwgYW5kIGxlYXZlIFVQREFURSBvdXRzaWRlIG9mIElOVklURQ0KPj4+Pj4gYWxvbmUuDQo+ Pj4+DQo+Pj4+IFNvLCBqdXN0IHRvIG1ha2Ugc3VyZSB3ZSBhcmUgb25lIHRoZSBzYW1lIHBhZ2Us IGhvdyB3b3VsZCB0aGF0IHNwZWNpYWwNCj4+Pj4gY2FzZSB3b3JrPw0KPj4+DQo+Pj4gTXkgZWFy bGllciBtZXNzYWdlIGhhZCBhIGNvdXBsZSBvZiBhbHRlcm5hdGl2ZSBwcm9wb3NhbHMgZm9yIHRo aXM6DQo+Pj4NCj4+PiANCj4+Pmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv c2lwY29yZS9mM3doWW1wQ3hGTGZXdWxXN1pFM3hzVVJRZg0KPj4+cw0KPj4gDQo+Pj5Gcm9tIGFu IGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlLCBpc26p9nQgYWx0ZXJuYXRpdmUgMiBtb3JlIG9y IGxlc3MNCj4+PndoYXQNCj4+IEkgYWxzbyBzdWdnZXN0PyBUaGUgb25seSBkaWZmZXJlbmNlIGlz IHRoYXQgSSBzdWdnZXN0IHRvIGFwcGx5IHRvIHJ1bGUNCj4+dG8NCj4+IGV2ZXJ5IFVQREFURSAt IG5vIG1hdHRlciB3aGV0aGVyIGl0qfZzIGVtYmVkZGVkIGluIGFuIElOVklURSBvciBub3QuDQo+ DQo+VGhlIHJ1bGVzIGluICgyKSBkb24ndCB3b3JrIGZvciBVUERBVEVzIG91dHNpZGUgYW4gSU5W VEUuIChXaGVuIHNlbmRpbmcNCj5hbiBVUERBVEUgKm91dHNpZGUqIGFuIElOVklURSB5b3UgY2Fu J3QgaW5jbHVkZSB0aGUgc2FtZSBzLXQgc3R1ZmYgYXMgaW4NCj50aGUgKmVuY2xvc2luZyogSU5W SVRFIGJlY2F1c2UgdGhlcmUgaXMgbm8gZW5jbG9zaW5nIElOVklURS4pDQoNCldoZW4gc2VuZGlu ZyBVUERBVEUgKm91dHNpZGUqIGFuIElOVklURSB5b3UgaW5jbHVkZSB3aGF0ZXZlciBzLXQgc3R1 ZmYgaGFzDQpiZWVuIG5lZ290aWF0ZWQuDQoNCj4gQWxzbywgd2l0aCBhbiBVUERBVEUgd2l0aGlu IGFuIElOVklURSwgd2hhdGV2ZXIgaGFwcGVucyBhcyBhIHJlc3VsdCBvZg0KPnRoZSBVUERBVEUN Cj53aWxsIHF1aWNrbHkgYmUgb3ZlcnJpZGRlbiB3aGVuIHByb2Nlc3NpbmcgdGhlIDIwMCBmb3Ig dGhlIElOVklURS4NCg0KQ29ycmVjdCwgYW5kIHRoYXShr3Mgd2h5IGFuIFVQREFURSB3aXRoaW4g YW4gSU5WSVRFIHNob3VsZCByZWZsZWN0IHdoYXRldmVyDQp3aWxsIGJlIGluIHRoZSAyMDAgZm9y IHRoZSBJTlZJVEUuIEl0oa9zIGxpa2Ugc2VuZGluZyBTRFAgaW4gYW4gdW5yZWxpYWJsZQ0KMTh4 IC0gaXShr3Mgbm90IHRoZSBvZmZpY2lhbCBhbnN3ZXIsIGJ1dCB0aGUgY29udGVudCBtdXN0IHN0 aWxsIGJlIHRoZSBzYW1lDQphcyBpbiB0aGUgYW5zd2VyIDopDQoNClNvLCBhc3N1bWUgQWxpY2Ug c2VuZHMgSU5WSVRFIHdpdGggcy10O3JlZnJlc2hlcj11YWMuDQoNCkJvYiB3aWxsIGV2ZW50dWFs bHkgc2VuZCAyMDAgT0sgd2l0aCByZWZyZXNoZXI9dWFjLg0KDQpIb3dldmVyLCBiZWZvcmUgdGhl IDIwMCBPSywgQm9iIHNlbmRzIGFuIFVQREFURSwgd2l0aCByZWZyZXNoZXI9dWFjLg0KDQoNCj5B bHNvLCBpdCBpcyBpbXBvcnRhbnQgaGVyZSB0byBhbmFseXplIHdoYXQgaGFwcGVucyB3aGVuIG9u ZSBvciBtb3JlIG9mDQo+dGhlIHBhcnRpZXMgaW4gdGhlIGRpYWxvZyBkb24ndCBzdXBwb3J0IHRo aXMgcmV2aXNpb24uIEkgdGhpbmsgKDIpIGlzIGluDQo+cHJldHR5IGdvb2Qgc2hhcGUgaW4gdGhh dCBjYXNlLg0KDQpJIGFncmVlIHRoYXQgc3VjaCBhbmFseXNlIGlzIHZlcnkgaW1wb3J0YW50Lg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Thu Nov 23 02:14: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 49A59128891 for ; Thu, 23 Nov 2017 02:13:59 -0800 (PST) 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 If-r86A-y2Ri for ; Thu, 23 Nov 2017 02:13:57 -0800 (PST) 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 C0E6512896F for ; Thu, 23 Nov 2017 02:13:56 -0800 (PST) X-AuditID: c1b4fb2d-f0bff70000001e3d-27-5a169f62ff4f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.BC.07741.26F961A5; Thu, 23 Nov 2017 11:13:54 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Thu, 23 Nov 2017 11:13:54 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount CC: "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNIA= Date: Thu, 23 Nov 2017 10:13:52 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@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: <2BD5865B0447BB42985D528FE982F333@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2J7iG7SfLEog4MHtCxWbDjAatF0p4vN YsaFqcwWX39sYnNg8fj7/gOTx5IlP5k82l4qeNyaUhDAEsVlk5Kak1mWWqRvl8CVsfHQIeaC PvaKiS2t7A2MV1m7GDk5JARMJK68mcQCYgsJHGaUWHIzuIuRC8hewijx8uYV5i5GDg42AQuJ 7n/aIDUiAt4SE+avZgOxmQWCJTbcn8AMYgsLaEgc2vObBaJGU+LiqWVMEHaZREvvcbBdLAKq Eh+P3gWr4RWwlri8ehEjxK6F7BLzZm0Ca+AUcJDYcHIaWAOjgJjE91NrmCCWiUvcejKfCeJo AYkle84zQ9iiEi8f/wOrFxXQk9hw4jY7RFxR4ur05VC9ehI3pk6BOtpa4vn1SawQtrbEsoWv mSEOEpQ4OfMJywRG8VlI1s1C0j4LSfssJO2zkLQvYGRdxShanFpcnJtuZKyXWpSZXFycn6eX l1qyiREYkwe3/Nbdwbj6teMhRgEORiUeXpsesSgh1sSy4srcQ4wSHMxKIrzi7UAh3pTEyqrU ovz4otKc1OJDjNIcLErivCc9eaOEBNITS1KzU1MLUotgskwcnFINjDGi7LGWMktXxOe6TTn6 bFdzv/V/Ic9ur2y/qQfairoOppSzPJn5+qhlxq3XqVWenTWsfXwmRwxMrsmL2fA+XGdfwXVa J/+eyItSTfnSq8tjRLbrJz6u+eOqdHT2i2hjy7XJbBdOMXpV3Xh45Pe/2AQl4ynqja++lORI V1pujqy0ZZt44mWOEktxRqKhFnNRcSIAAj75OsUCAAA= 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, 23 Nov 2017 10:13:59 -0000 Hi Paul, Your proposal says: "2) Specify that a UAC or proxy should duplicate in an embedded UPDATE whatever timer stuff they put in the enclosing INVITE transaction. And then the UAC for the INVITE should process the timer stuff in the 2xx response to the INVITE the same as if the UPDATE didn't happen. (What it does to process the timer stuff in the 200 for the UPDATE is irrelevant.)= =B2 If I understand the text, I DO agree with it. The difference is that I suggest that UPDATEs should never be allowed to change the refresher value: inside an INVITE transaction they simply mirror what is in the INVITE request, and outside an INVITE transaction they mirror what has been negotiated. That way, I don=B9t think entities need to know whether the UPDATE is sent inside or outside an INVUTE transaction, because the UPDATE is not allowed to change anything. Regards, Christer From nobody Thu Nov 23 02:45: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 D97DC128959 for ; Thu, 23 Nov 2017 02:44:58 -0800 (PST) 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 header.b=MARk3dCZ; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=EK4MCp19 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 dwS-EwKd2k7I for ; Thu, 23 Nov 2017 02:44:56 -0800 (PST) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (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 A5F33128961 for ; Thu, 23 Nov 2017 02:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1511433895; x=1542969895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kTaSfFQKYN3BMKYhnxOrKKOmIixx04iaTdB0tu6zCF4=; b=MARk3dCZa/moFbIHq08MwPs87uEY5d6N+e4rL7hhxUFDbCmqIBB6noqf CP1F9dsrQS5efp+YdiPVzU4DAYuweZj92YbafWJ9wTFxVbbzm470qt/3f KVhHrBW+By8GUBa3+99EYgkJThIlhxjHLl/qhGaQvNckFxGFhrcCAe0se +ZSo7uKD/R4WuggDYjpBK6e5IBAUlCPHUG5jqgt/vEaLmY8y86eSSgVjg 1K2FKA3pcVVkChNBXu8Kp9zFLNJ76qpv4vJv40Wq+qasZbJo57H11C1j5 LYii4w7NHnR62pFuh5+2hBGJGONsdcnlXplA77S0xewVplfhw0nfyEJ/n w==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2017 11:44:52 +0100 X-IronPort-AV: E=Sophos;i="5.44,441,1505772000"; d="scan'208";a="1428136982" Received: from he105662.emea1.cds.t-internal.com ([10.169.119.58]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 23 Nov 2017 11:43:50 +0100 Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105662.emea1.cds.t-internal.com (10.169.119.58) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 11:43:49 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105828.EMEA1.cds.t-internal.com (10.169.119.31) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 23 Nov 2017 11:43:49 +0100 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.1347.2; Thu, 23 Nov 2017 11:43:13 +0100 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=kTaSfFQKYN3BMKYhnxOrKKOmIixx04iaTdB0tu6zCF4=; b=EK4MCp19mn9jb0KXvkvp918sNKAMcNxG/a6aDAisy01Ibp+CsqpgxD7hrJydJRAInWUv8sfQ3PNybcKyPv57uuiH4wd0sDuBzJxXo3BtXuer9lngSse9smGCtVOt3zlghSez0a7IppA8ggMMtrsxqxUTg66vqqT7U5QFzAGU2Mw= 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.260.4; Thu, 23 Nov 2017 10:43:49 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0260.004; Thu, 23 Nov 2017 10:43:49 +0000 From: To: , , CC: Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnUFtGaBJrWltk+s1shdGvlnWqL+S3eAgANM5ACAAAWhgIAABYIAgBhYyQCAAJRHAIAAiM8AgAEq5YCAAJcLgIABCfYAgAP9WACAAASbcA== Date: Thu, 23 Nov 2017 10:43:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@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.139] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:Vibb2XtcOyWhD3ZQqnaVmVqnPOqEPcM9IHKd5UvBkaQ/eIGgq1VwkBX546bEVPSS1U5tV4/G9eIIeQZz2eOXQJaCPI5Dv2dWyNQ0/bfgabFPH+Fd7e6BE2QRpuSNifC9LF6s58u/Lrj7VBsTcD6q+b39lN6VNXnSbVcYppW1C4iLFqDaxABe8wZIR4gMdUQkjqGvvpkIQwCukIpqB5vTe4FqLMWDdhi+h8uysXXm71AFcKE0Ur8UZz3RKsWVAxH72abMqGuJ3C1WJy2rTnTknG7/BDTXNdl/0M06Asc0He4ti8F3pTna/s38UI1bbIaAYs+5EBNv+8fLAw5FbQUXHQcM0dLi1+ykoySfmGQwSoA=; 5:KZr+yUk4cCMF17RIxkj8T687nBPaFj8GFgg/mISSzwxe1FK0tfwSVq6MAFRkfg+1wpsP4/vrHg3TBosVc5vjrcByKS5bn+INLvuLsa/tKxLT/hrvkEEdFmZtUcBe1/UnkfavvDiGsM5prKmuwPAsL9QrbfvZ0AsQahMwKYZyuw4=; 24:2XLMXFDmRPBxWfWIfdJ8fvKDpfQ5VnRfg+JMk3yf6+BdDdylgzhog6rKGsKM1papWhSmBmW1J11lp5hR7ivT96uDuysrG4wtMdLUQuxs+Rc=; 7:E9ez2q/1vaVoCgSgOC31jzKDrhKAtnixGexCO2dx97Qr/VtW/pBS6ZKam+r+5KJNHm0gRC/8Mpx3xBE1/BPyFQHM5QlfrycQb3/3FKsId8ITIZFj+44pbvd7QAkMKf55bWKsDqLkcIHJVVqn/PfvAv43PqdYD8oiKDJP/zSrMsm+lrKMyy3gsfC6CS3LoDYzrAxDMGKjPHuo6NycRwKoc6+8GTwSLj7nwJbl4K8XZcfDqdKEgiczQ9MTNI/6S8Dt x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ee8d1cd4-2ca4-438e-3b14-08d5325f14b1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600025)(4604075)(2017052603258); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(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: 05009853EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(366004)(199003)(189002)(2906002)(305945005)(72206003)(7736002)(8936002)(478600001)(75402003)(14454004)(3280700002)(3660700001)(2900100001)(81166006)(106356001)(66066001)(105586002)(68736007)(74482002)(81156014)(5250100002)(8676002)(55016002)(189998001)(53936002)(102836003)(9686003)(6116002)(3846002)(50986999)(52396003)(97736004)(4326008)(33656002)(2171002)(551934003)(561944003)(101416001)(7696004)(54356999)(110136005)(76176999)(2950100002)(316002)(93886005)(5660300001)(86362001); 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-Network-Message-Id: ee8d1cd4-2ca4-438e-3b14-08d5325f14b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2017 10:43:49.2296 (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] 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, 23 Nov 2017 10:44:59 -0000 Hi Christer et all, What is if the SE in the UPDATE is changed? Ignore? I know exactly that we will have in reality. Big problems due to the fact t= hat we will have all possible combinations of INVITE/UPDATE during the init= ial negotiation of the SE.=20 So from my point of view we need clear statements. Either do not allow SE in UPDATE during initial negotiation but with all po= ssible combinations of SE settings and the expected reaction of the UAC/UAS= /Proxy. Or ignore everything within UPDATE and 200OK (UPDATE) according to SE withi= n the initial negotiation of the session timer. And other messages (e.G PRA= CK ) send between INVITE with SE and 200 OK (INVITE) with the final negotia= ted SE. Seen from this I would like to have Solution 1 from Paul. Extending to all = other messages that could appear. i.e. 1) Specify that the negotiation in the INVITE transaction should be=20 unaffected by whatever happens in an intervening UPDATE. Also specify=20 how timer stuff should be handled in an UPDATE within an INVITE. For=20 that I think what we have been converging on is: - the UAC and proxies for the embedded UPDATE should not include S-E; - the UAS should not include S-E in the UPDATE response, even if it gets one in the request; - proxies should not add an S-E to an embedded UPDATE response; - the UAC should ignore S-E in an embedded UPDATE response. But the key here is the UAC ignoring it. Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Gesendet: Donnerstag, 23. November 2017 11:14 > An: Paul Kyzivat ; Roman Shpount > > Cc: Jesske, Roland ; sipcore@ietf.org > Betreff: Re: [sipcore] Session timer fix >=20 > Hi Paul, >=20 > Your proposal says: >=20 > "2) Specify that a UAC or proxy should duplicate in an embedded UPDATE > whatever timer stuff they put in the enclosing INVITE transaction. And th= en the > UAC for the INVITE should process the timer stuff in the 2xx response to = the > INVITE the same as if the UPDATE didn't happen. (What it does to process = the > timer stuff in the 200 for the UPDATE is irrelevant.)=B2 >=20 > If I understand the text, I DO agree with it. >=20 > The difference is that I suggest that UPDATEs should never be allowed to > change the refresher value: inside an INVITE transaction they simply mirr= or > what is in the INVITE request, and outside an INVITE transaction they mir= ror > what has been negotiated. That way, I don=B9t think entities need to know > whether the UPDATE is sent inside or outside an INVUTE transaction, becau= se > the UPDATE is not allowed to change anything. >=20 > Regards, >=20 > Christer From nobody Thu Nov 23 12:20:51 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 A198E124205 for ; Thu, 23 Nov 2017 12:20:49 -0800 (PST) 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 rsq6K84xLnrW for ; Thu, 23 Nov 2017 12:20:48 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 56422120727 for ; Thu, 23 Nov 2017 12:20:48 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id s75so14410855pgs.0 for ; Thu, 23 Nov 2017 12:20:48 -0800 (PST) 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=h27jvQ8K3PfGaFoodP6PieWfTJ8+8WZVPDp32Mqe9gw=; b=wkKMguJLkxjZm3CrrE109ZmIfmq7fVfU7u21Aokx+OiDt6jFQ2U32HSk5FearH9OWf cgi0+w9e6c/9i/aTks4ZWJJ1K2XD+l4PeUKbjtpfs1WS6e24HWRKwqNHY8ZuE7fXmDv/ doxMK4aIyHlL/kiJnb6aMCL+ndbPu472UF8rcHbuf73UdkUYc3aTl47y/s/EczIGqalg ljSRfTKQz0iKxUHx8Y8wvn5Ei7pcOFPFutiug/QgKoS1B+Q3GVT1yOu81+VVvWa1TgkD Du9U5ICGARZLBt6jRHz1odvc6gwCrtsBgavyZGKjq6amZJDHakDECGZjVM9fxF3gZjSR QC/w== 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=h27jvQ8K3PfGaFoodP6PieWfTJ8+8WZVPDp32Mqe9gw=; b=YQvqLzrQewSzNkvUlSwfQIUrz98z+lMDoqtX+1XvLfMs3kg+V7MLhbZsPJIb6NfaPA gHaswLn/I2zSUy3JaK4V3KW6V1DoGqUyqjl6mqCPRucKZXnOOEB9dI9tjCCEyz7L0Lfg 8qTrmfkCkyr89LbKNzqEuYLNzpOpyiP+GYwr50bU/O18NZ8Pt0CRKqdTeiMnts+iKqxg 8OzGjkF/9+Qsarf2VyadvtsNiD80Fa9pu9LgMEwuawwxCrgoOePfSnFm3KxKX0ttoFi5 l7DfZPH1JZ1hZy4ym4EVumUwXp7TzBYuOsui2sSceZyMJb2/jiFHlaOpzHUTDqmjcJWZ /xmg== X-Gm-Message-State: AJaThX5jyiGcp50tC8D/BVtLPx/eSJbiZLRrfRB6OxCWIt3bH7Fk7uF+ e3/m5ZZtveE8OqJdGlrPMAhOiMtZHCU= X-Google-Smtp-Source: AGs4zMa0t+cu8V87+VEllzVDMVFsKC5igC2kOn/OIWcyxQwYuXGjWROQ4hr2Nce3OoWNR1GvOdHebA== X-Received: by 10.101.87.139 with SMTP id b11mr25796217pgr.314.1511468447708; Thu, 23 Nov 2017 12:20:47 -0800 (PST) Received: from mail-pl0-f44.google.com (mail-pl0-f44.google.com. [209.85.160.44]) by smtp.gmail.com with ESMTPSA id f67sm36692722pff.173.2017.11.23.12.20.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 12:20:46 -0800 (PST) Received: by mail-pl0-f44.google.com with SMTP id k7so3179444pln.13 for ; Thu, 23 Nov 2017 12:20:46 -0800 (PST) X-Received: by 10.84.235.200 with SMTP id m8mr19914392plt.276.1511468445900; Thu, 23 Nov 2017 12:20:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Thu, 23 Nov 2017 12:20:45 -0800 (PST) In-Reply-To: <0c032270-5b32-7a30-8f5a-898e9fe9ad7c@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <343e7d78-2961-f778-c678-a9e841a8f336@alum.mit.edu> <11aa72e3-4e36-e7b5-4922-5382698ef23e@alum.mit.edu> <0c032270-5b32-7a30-8f5a-898e9fe9ad7c@alum.mit.edu> From: Roman Shpount Date: Thu, 23 Nov 2017 15:20:45 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="089e08212200cea73e055eac2b39" 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, 23 Nov 2017 20:20:50 -0000 --089e08212200cea73e055eac2b39 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 21, 2017 at 3:38 PM, Paul Kyzivat wrote: > I think we would need to include a new reason for generating 491 as part > of this revision/clarification of s-t. > > IIUC your concern is with proxies (presumably dialog-stateful) that want > to request a s-t and also comply with this revision. I think they actually > don't need to do anything different than they are already doing unless they > have *not* made a s-t request in an INVITE and then *do* decide they want > to do that when an UPDATE is sent within that UPDATE. I find that to be a > far fetched situation. If they simply always request the same thing in > every INVITE and UPDATE that goes by then they will be in compliance. > I think asking proxies to consistently add the same things to all UPDATE and INVITE messages that are processed by proxies is the only possible solution. Asking proxies to do things differently based on dialog state would be impossible to implement. Having more consistent rules for UAC/UAS on handling UDPATE during INVITE, including dealing with potential collisions which can cause inconsistent state, will be helpful . _____________ Roman Shpount --089e08212200cea73e055eac2b39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Nov 21, 2017 at 3:3= 8 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
I think we would need to inc= lude a new reason for generating 491 as part of this revision/clarification= of s-t.

IIUC your concern is with proxies (presumably dialog-stateful) that want to= request a s-t and also comply with this revision. I think they actually do= n't need to do anything different than they are already doing unless th= ey have *not* made a s-t request in an INVITE and then *do* decide they wan= t to do that when an UPDATE is sent within that UPDATE. I find that to be a= far fetched situation. If they simply always request the same thing in eve= ry INVITE and UPDATE that goes by then they will be in compliance.

I think asking proxies to consistently add the = same things to all UPDATE and INVITE messages that are processed by proxies= is the only possible solution. Asking proxies to do things differently bas= ed on dialog state would be impossible to implement.

Having more consistent rules for UAC/UAS on handling UDPATE during INVIT= E, including dealing with potential collisions which can cause inconsistent= state, will be helpful .
________= _____
Roman Shpount
=C2=A0
--089e08212200cea73e055eac2b39-- From nobody Thu Nov 23 12:28:05 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 55E62126DCA for ; Thu, 23 Nov 2017 12:28:04 -0800 (PST) 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 k9aEz8LDXxzS for ; Thu, 23 Nov 2017 12:28:02 -0800 (PST) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 D071A120724 for ; Thu, 23 Nov 2017 12:28:02 -0800 (PST) Received: by mail-pl0-x22f.google.com with SMTP id b12so3194125plm.3 for ; Thu, 23 Nov 2017 12:28:02 -0800 (PST) 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=LstMJ8wfSMrbKhTd4X7cs+zuca/TIMWUlwiPXVy2Dg4=; b=Qv4dx95X+FFJwx4Xw02lf5cex7ImtB4AkUnW0EC48qz/jOrn5QZXAkyupyl8bYR2XE hAMpsynZJiQPIVhumRlrqaEIKqIljLmYBtuScMR7bv7pPsl6k4AQobI+nE43hBQBq5QG +HMvC9iqPK6SR+DnNY8YWn4Q9KjGlWRBrQlyEd05QZHZPsgs3uU7MasvCWFv4shtimho AsoHz7r5FLUU3jk9k1P4hwDjONrnZdBFq1ZJYfdldk6Y1uLxhFxtju0QDOvXmeKSH7Ty t/AkrvFv3Evo0wKAw//EByugBa0tuoLjfef2idBinDcFvMGQ+//1mSHi6sCIuUYyFZJB Nhqg== 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=LstMJ8wfSMrbKhTd4X7cs+zuca/TIMWUlwiPXVy2Dg4=; b=RnnUh2J8EkjrMjHie+K9UnDk46hjtqnfYuedaOEv1WHKBIR1ThffQYlW3XfQ9Xf06t OBFUtgUh84YL7NbXyEIjcrR16iH1QW5Sctbm6WD94bGGk5i8uBF15UbBa7lw9Np2iJFP uS8zkK7kG2B1yOcqdlTjPHe1BT5XvxJ2/Daj5DzrtEsw2WKAYYK1J6O1Q7zOXcAXiOdV uFd8gG3mN/30TQJNHKPhmVYvm4xq0fPN/frI97xz5QOzn9v8ukK2pFGrDMm0K5UOOyb1 sXnJC/GTenQRDIKRFJbrQE5jzLiRnR+pW6Y3Q5POyNmhcz+V77Yl2ZBEMHJVSgr+o5s2 Plyw== X-Gm-Message-State: AJaThX69Tlp76x6/fYT1eGOZt0LrFPXYTB+Xp5Eo/YfnqXTDe9qc6Hnu 3YyLJllgYKbgR3CITFoz1huMDeWs X-Google-Smtp-Source: AGs4zMZIwqpzMtLT9Zgd3YJEhjwtvmlLgnF/cro3ADd4vU8xc0TIcCGe0Ak1TnmCzAaPLbSaYf6dZA== X-Received: by 10.84.165.171 with SMTP id y40mr27039427pla.362.1511468882274; Thu, 23 Nov 2017 12:28:02 -0800 (PST) Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com. [209.85.192.176]) by smtp.gmail.com with ESMTPSA id b25sm24094216pfd.182.2017.11.23.12.28.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 12:28:01 -0800 (PST) Received: by mail-pf0-f176.google.com with SMTP id j28so13890890pfk.8 for ; Thu, 23 Nov 2017 12:28:01 -0800 (PST) X-Received: by 10.99.112.92 with SMTP id a28mr25986125pgn.413.1511468881298; Thu, 23 Nov 2017 12:28:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Thu, 23 Nov 2017 12:28:00 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> From: Roman Shpount Date: Thu, 23 Nov 2017 15:28:00 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="f403045c6b5ec24c34055eac4538" 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, 23 Nov 2017 20:28:04 -0000 --f403045c6b5ec24c34055eac4538 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 23, 2017 at 5:13 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Paul, > > Your proposal says: > > "2) Specify that a UAC or proxy should duplicate in an embedded UPDATE > whatever timer stuff they put in the enclosing INVITE transaction. And > then the UAC for the INVITE should process the timer stuff in the 2xx > response to the INVITE the same as if the UPDATE didn't happen. (What it > does to process the timer stuff in the 200 for the UPDATE is irrelevant.)= =C2=B2 > > If I understand the text, I DO agree with it. > > The difference is that I suggest that UPDATEs should never be allowed to > change the refresher value: inside an INVITE transaction they simply > mirror what is in the INVITE request, and outside an INVITE transaction > they mirror what has been negotiated. That way, I don=C2=B9t think entiti= es > need to know whether the UPDATE is sent inside or outside an INVUTE > transaction, because the UPDATE is not allowed to change anything. > There are cases when UPDATE is being used a simply "lighter" version of re-INVITE with SDP. You can do the same things using UPDATE as you do using re-INVITE, but you can do it using twice fewer messages. Breaking this because of some corner case in Session-Timer negotiation greatly diminishes UPDATE message utility. _____________ Roman Shpount --f403045c6b5ec24c34055eac4538 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 23, 2017 at 5:13 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi Paul,=

Your proposal says:

"2) Specify that a UAC or proxy should duplicate in an embedded UPDATE=
whatever timer stuff they put in the enclosing INVITE transaction. And
then the UAC for the INVITE should process the timer stuff in the 2xx
response to the INVITE the same as if the UPDATE didn't happen. (What i= t
does to process the timer stuff in the 200 for the UPDATE is irrelev= ant.)=C2=B2

If I understand the text, I DO agree with it.

The difference is that I suggest that UPDATEs should never be allowed to change the refresher value: inside an INVITE transaction they simply
mirror what is in the INVITE request, and outside an INVITE transaction
they mirror what has been negotiated. That way, I don=C2=B9t think entities=
need to know whether the UPDATE is sent inside or outside an INVUTE
transaction, because the UPDATE is not allowed to change anything.

There are cases when UPDATE is being used a sim= ply "lighter" version of re-INVITE with SDP. You can do the same = things using UPDATE as you do using re-INVITE, but you can do it using twic= e fewer messages. Breaking this because of some corner case in Session-Time= r negotiation greatly diminishes UPDATE message utility.
_____________
Roman Shpount
=C2= =A0
--f403045c6b5ec24c34055eac4538-- From nobody Thu Nov 23 23:12: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 7F2A5129B20 for ; Thu, 23 Nov 2017 23:12:57 -0800 (PST) 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_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 baPlz_y4IKRJ for ; Thu, 23 Nov 2017 23:12:56 -0800 (PST) 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 14142129B1B for ; Thu, 23 Nov 2017 23:12:55 -0800 (PST) X-AuditID: c1b4fb3a-c73ff70000004c48-da-5a17c676e26b Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.FC.19528.676C71A5; Fri, 24 Nov 2017 08:12:54 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Fri, 24 Nov 2017 08:12:53 +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+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoA Date: Fri, 24 Nov 2017 07:12:52 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@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.18] Content-Type: multipart/alternative; boundary="_000_D63D94B02648Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7vW7ZMfEog1MfBCxWbDjAatF0p4vN YsaFqcwWX39sYnNg8fj7/gOTx5IlP5k82l4qeNyaUhDAEsVlk5Kak1mWWqRvl8CVcf/vR8aC RboVf07+ZW9g/K7dxcjJISFgIvFk2keWLkYuDiGBw4wSN9q6WSGcJYwSr3v2A2U4ONgELCS6 /4E1iAioSvz9PpkJxGYWqJT40HcYzBYW0JA4tOc3C0SNpsTFU8uYQOaICDQxSjS9WscKkmAB at694hgbiM0rYC3RfWobM8SyWRwSX1uXsYIs4xQIlOg4kg1SwyggJvH91BqoZeISt57MZ4K4 WkBiyZ7zzBC2qMTLx//A5osK6ElsOHGbHSKuKPHx1T5GkJHMAgkSv27qQ6wVlDg58wnLBEbR WUimzkKomoWkCqJES+LLj31sELaixJTuh+wQ5ZoSbx7WQoStJU4/fcmIrGQBI8cqRtHi1OLi 3HQjI73Uoszk4uL8PL281JJNjMA4Pbjlt9UOxoPPHQ8xCnAwKvHwpqwTjxJiTSwrrsw9xCjB wawkwiv/VCxKiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU7NTUgtQimCwTB6dU A2MyR96WT6wphxguZHJyzbIOynrY/1+Sa8qKzxEHQxM0vtXsNPxYyakWy/j57fwXIdvnH1Z0 mMe3Nn7ByZDU9zVrWNWtd35Y9Wq77snr2v+vZLEZTeoWcVD6/m3H52NXGyw653HPWnyL4daf PxHXHk9unyOgyrJg4wFmx5KdDJ4/I1PiDh8PFt6jxFKckWioxVxUnAgAY6frwc8CAAA= 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, 24 Nov 2017 07:12:57 -0000 --_000_D63D94B02648Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGksDQoNCllvdXIgcHJvcG9zYWwgc2F5czoNCg0KIjIpIFNwZWNpZnkgdGhhdCBhIFVBQyBvciBw cm94eSBzaG91bGQgZHVwbGljYXRlIGluIGFuIGVtYmVkZGVkIFVQREFURQ0Kd2hhdGV2ZXIgdGlt ZXIgc3R1ZmYgdGhleSBwdXQgaW4gdGhlIGVuY2xvc2luZyBJTlZJVEUgdHJhbnNhY3Rpb24uIEFu ZA0KdGhlbiB0aGUgVUFDIGZvciB0aGUgSU5WSVRFIHNob3VsZCBwcm9jZXNzIHRoZSB0aW1lciBz dHVmZiBpbiB0aGUgMnh4DQpyZXNwb25zZSB0byB0aGUgSU5WSVRFIHRoZSBzYW1lIGFzIGlmIHRo ZSBVUERBVEUgZGlkbid0IGhhcHBlbi4gKFdoYXQgaXQNCmRvZXMgdG8gcHJvY2VzcyB0aGUgdGlt ZXIgc3R1ZmYgaW4gdGhlIDIwMCBmb3IgdGhlIFVQREFURSBpcyBpcnJlbGV2YW50Limp9w0KDQpJ ZiBJIHVuZGVyc3RhbmQgdGhlIHRleHQsIEkgRE8gYWdyZWUgd2l0aCBpdC4NCg0KVGhlIGRpZmZl cmVuY2UgaXMgdGhhdCBJIHN1Z2dlc3QgdGhhdCBVUERBVEVzIHNob3VsZCBuZXZlciBiZSBhbGxv d2VkIHRvDQpjaGFuZ2UgdGhlIHJlZnJlc2hlciB2YWx1ZTogaW5zaWRlIGFuIElOVklURSB0cmFu c2FjdGlvbiB0aGV5IHNpbXBseQ0KbWlycm9yIHdoYXQgaXMgaW4gdGhlIElOVklURSByZXF1ZXN0 LCBhbmQgb3V0c2lkZSBhbiBJTlZJVEUgdHJhbnNhY3Rpb24NCnRoZXkgbWlycm9yIHdoYXQgaGFz IGJlZW4gbmVnb3RpYXRlZC4gVGhhdCB3YXksIEkgZG9uqfZ0IHRoaW5rIGVudGl0aWVzDQpuZWVk IHRvIGtub3cgd2hldGhlciB0aGUgVVBEQVRFIGlzIHNlbnQgaW5zaWRlIG9yIG91dHNpZGUgYW4g SU5WVVRFDQp0cmFuc2FjdGlvbiwgYmVjYXVzZSB0aGUgVVBEQVRFIGlzIG5vdCBhbGxvd2VkIHRv IGNoYW5nZSBhbnl0aGluZy4NCg0KPiBUaGVyZSBhcmUgY2FzZXMgd2hlbiBVUERBVEUgaXMgYmVp bmcgdXNlZCBhIHNpbXBseSAibGlnaHRlciIgdmVyc2lvbiBvZiByZS1JTlZJVEUgd2l0aCBTRFAu IFlvdSBjYW4gZG8gdGhlIHNhbWUgdGhpbmdzIHVzaW5nIFVQREFURSBhcyB5b3UgZG8gdXNpbmcg cmUtSU5WSVRFLA0KPiBidXQgeW91IGNhbiBkbyBpdCB1c2luZyB0d2ljZSBmZXdlciBtZXNzYWdl cy4gQnJlYWtpbmcgdGhpcyBiZWNhdXNlIG9mIHNvbWUgY29ybmVyIGNhc2UgaW4gU2Vzc2lvbi1U aW1lciBuZWdvdGlhdGlvbiBncmVhdGx5IGRpbWluaXNoZXMgVVBEQVRFIG1lc3NhZ2UgdXRpbGl0 eS4NCg0KU28sIGhvdyBvZnRlbiBpcyB0aGUgcmVmcmVzaGVyIGNoYW5nZWQgZHVyaW5nIGEgY2Fs bD8gQXMgZmFyIGFzIEkga25vdywgaW4gdGhlIHZhc3QgbWFqb3JpdHkgb2YgY2FzZXMgdGhlIHNl c3Npb24tdGltZXIgbmVnb3RpYXRpb24gdGFrZXMgcGxhY2UgZHVyaW5nIHRoZSBpbml0aWFsIElO VklURSwgYW5kIHRoZW4gaXQgZG9lc26hr3QgY2hhbmdlIGR1cmluZyB0aGUgY2FsbC4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= --_000_D63D94B02648Fchristerholmbergericssoncom_ Content-Type: text/html; charset="euc-kr" Content-ID: <9A69863F0B1B4347AEFC89926C8C54B1@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGksPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJn YigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj5Z b3VyIHByb3Bvc2FsIHNheXM6PGJyPg0KPGJyPg0KJnF1b3Q7MikgU3BlY2lmeSB0aGF0IGEgVUFD IG9yIHByb3h5IHNob3VsZCBkdXBsaWNhdGUgaW4gYW4gZW1iZWRkZWQgVVBEQVRFPGJyPg0Kd2hh dGV2ZXIgdGltZXIgc3R1ZmYgdGhleSBwdXQgaW4gdGhlIGVuY2xvc2luZyBJTlZJVEUgdHJhbnNh Y3Rpb24uIEFuZDxicj4NCnRoZW4gdGhlIFVBQyBmb3IgdGhlIElOVklURSBzaG91bGQgcHJvY2Vz cyB0aGUgdGltZXIgc3R1ZmYgaW4gdGhlIDJ4eDxicj4NCnJlc3BvbnNlIHRvIHRoZSBJTlZJVEUg dGhlIHNhbWUgYXMgaWYgdGhlIFVQREFURSBkaWRuJ3QgaGFwcGVuLiAoV2hhdCBpdDxicj4NCjwv c3Bhbj5kb2VzIHRvIHByb2Nlc3MgdGhlIHRpbWVyIHN0dWZmIGluIHRoZSAyMDAgZm9yIHRoZSBV UERBVEUgaXMgaXJyZWxldmFudC4pqfc8YnI+DQo8YnI+DQpJZiBJIHVuZGVyc3RhbmQgdGhlIHRl eHQsIEkgRE8gYWdyZWUgd2l0aCBpdC48YnI+DQo8YnI+DQpUaGUgZGlmZmVyZW5jZSBpcyB0aGF0 IEkgc3VnZ2VzdCB0aGF0IFVQREFURXMgc2hvdWxkIG5ldmVyIGJlIGFsbG93ZWQgdG88YnI+DQpj aGFuZ2UgdGhlIHJlZnJlc2hlciB2YWx1ZTogaW5zaWRlIGFuIElOVklURSB0cmFuc2FjdGlvbiB0 aGV5IHNpbXBseTxicj4NCm1pcnJvciB3aGF0IGlzIGluIHRoZSBJTlZJVEUgcmVxdWVzdCwgYW5k IG91dHNpZGUgYW4gSU5WSVRFIHRyYW5zYWN0aW9uPGJyPg0KdGhleSBtaXJyb3Igd2hhdCBoYXMg YmVlbiBuZWdvdGlhdGVkLiBUaGF0IHdheSwgSSBkb26p9nQgdGhpbmsgZW50aXRpZXM8YnI+DQpu ZWVkIHRvIGtub3cgd2hldGhlciB0aGUgVVBEQVRFIGlzIHNlbnQgaW5zaWRlIG9yIG91dHNpZGUg YW4gSU5WVVRFPGJyPg0KdHJhbnNhY3Rpb24sIGJlY2F1c2UgdGhlIFVQREFURSBpcyBub3QgYWxs b3dlZCB0byBjaGFuZ2UgYW55dGhpbmcuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+Jmd0OyBUaGVyZSBhcmUgY2FzZXMgd2hlbiBVUERBVEUgaXMgYmVpbmcgdXNl ZCBhIHNpbXBseSAmcXVvdDtsaWdodGVyJnF1b3Q7IHZlcnNpb24gb2YgcmUtSU5WSVRFIHdpdGgg U0RQLiBZb3UgY2FuIGRvIHRoZSBzYW1lIHRoaW5ncyB1c2luZyBVUERBVEUgYXMgeW91IGRvIHVz aW5nIHJlLUlOVklURSw8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+DQo8ZGl2PiZndDsgYnV0IHlvdSBjYW4gZG8gaXQgdXNpbmcgdHdpY2Ug ZmV3ZXIgbWVzc2FnZXMuIEJyZWFraW5nIHRoaXMgYmVjYXVzZSBvZiBzb21lIGNvcm5lciBjYXNl IGluIFNlc3Npb24tVGltZXIgbmVnb3RpYXRpb24gZ3JlYXRseSBkaW1pbmlzaGVzIFVQREFURSBt ZXNzYWdlIHV0aWxpdHkuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U28sIGhvdyBvZnRlbiBpcyB0 aGUgcmVmcmVzaGVyIGNoYW5nZWQgZHVyaW5nIGEgY2FsbD8gQXMgZmFyIGFzIEkga25vdywgaW4g dGhlIHZhc3QgbWFqb3JpdHkgb2YgY2FzZXMgdGhlIHNlc3Npb24tdGltZXIgbmVnb3RpYXRpb24g dGFrZXMgcGxhY2UgZHVyaW5nIHRoZSBpbml0aWFsIElOVklURSwgYW5kIHRoZW4gaXQgZG9lc26h r3QgY2hhbmdlIGR1cmluZyB0aGUgY2FsbC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaHJpc3RlcjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D63D94B02648Fchristerholmbergericssoncom_-- From nobody Fri Nov 24 00:18: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 F1CC8127342 for ; Fri, 24 Nov 2017 00:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 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, 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=EnpDtEZj; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=L2maLGg0 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 HTAnr6xfCB8D for ; Fri, 24 Nov 2017 00:18:11 -0800 (PST) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (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 529E6127A91 for ; Fri, 24 Nov 2017 00:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1511511490; x=1543047490; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0lAgSPLdZMV4IUfXaj0sylxszUYJ3dvUJ8AwqbR2yR8=; b=EnpDtEZjoHwJ+eHsMvm8mZor4GAB82++vmxSrNroMURl0HWF4rMlviHn kUdY3okdGY9hwlAq7s9s7NgdNEjFAo7b6eGRClqdHeY4jE/38VonzI+r4 21aMxIDq8dmRfRcD0HZUmAY5ciksUkAaJ8jBwiHmb1mSloe0AtINQBrjE sMRziB7pw4R8dN6Gzyq3nnml6COICu2tWmh864v7tqT85P+yheHxGwkZQ vGjVUiFFVKS1ehnax8+OPXHRlU/RIP+rBpRaeuer42/2F2QSp6kgSyocs eRsfruQf5vx7YbB5CXigQCvOYqXfUU7yhRmW4JxFDG08cZnLB3lfTdThV w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Nov 2017 09:18:08 +0100 X-IronPort-AV: E=Sophos; i="5.44,445,1505772000"; d="scan'208,217"; a="70386426" Received: from he105762.emea1.cds.t-internal.com ([10.169.118.58]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 24 Nov 2017 09:08:41 +0100 Received: from HE105776.EMEA1.cds.t-internal.com (10.169.118.36) by HE105762.emea1.cds.t-internal.com (10.169.118.58) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 24 Nov 2017 09:08:41 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105776.EMEA1.cds.t-internal.com (10.169.118.36) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 24 Nov 2017 09:08:41 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.19) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 24 Nov 2017 09:08:21 +0100 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=0lAgSPLdZMV4IUfXaj0sylxszUYJ3dvUJ8AwqbR2yR8=; b=L2maLGg0WnMFcj1W9LmQ74tLHA/n1/4ckidoBi9ruxmyqd8evqVc5szws3u8M67qwJKDeqYFP+CDNo5qZqIfJJP1Jv+4AxHP9hs6LiDCBc8UTXNNx/TOmqM4PtZi6jwSCPKJWilZxcpRd93YDKp+mnoZxULHHE/GuXkPA2m3Urw= 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.260.4; Fri, 24 Nov 2017 08:08:40 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0260.005; Fri, 24 Nov 2017 08:08:40 +0000 From: To: , CC: Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnUFtGaBJrWltk+s1shdGvlnWqL+S3eAgANM5ACAAAWhgIAABYIAgBhYyQCAAJRHAIAAiM8AgAEq5YCAAJcLgIABCfYAgAP9WACAAKuXAIAAtCwAgAAOd1A= Date: Fri, 24 Nov 2017 08:08:40 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.19.3.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:vrBdt+6p121XlprQqxnKKQ1djqZM7ymmBZbCfxS6neFTXFsCPOx28VQ85TtkpiK2o8iebrMqBjlFnRvAuRpNXOXVcAcXzpus4z1H6Dg5y2MD9GkAlCns4TZLyVvqthtvOmz/EsuhNPh75SfzNWZJ7P0kmI6pCX01C1kpEZf3ECwLKWBQvxU4TGavHdARQF8rqMRzWiE1qBSG5m6FLDln979Ebho+If6s2XTvQLbHTNxX+1is7qdLHD3W3NOY8mUkJaxKKgj762cVl6Dn7zTg60/FJ7QW2ZKWDYxmLGEjFA0dXTmPGVqgxU0JhQY4bCtJFJOeDdPyPFQtnjJf/D3PEa14tHfVGdImuXI1uvOcuuM=; 5:1jhRNQp9F3bccdC4I3Vzxb/En9FfvVV4cWjrQ9lB2AP5TmVAfRt0tal2kpUUDGCVOVvyOfL4ZikbgmRX5Q93Yq0V/Xnorz2cFhZSb5pDVavA2kV+uaGNkRwluzxEDwRLdLuRUaAJCxAd+B96rnfb6t5KSmpzC24mPpUK5y6SqPo=; 24:TPApNOygaJ1rzLs3TejjV/TIY8D1f+u9wf4SVjXLvupMUR25Z081RHofGIKIhkXBhbBXnCluz/Uf1coTeT6VG5UPSWBg0s4WzU3unyym/Bo=; 7:NuJglXtHtNZ8XfnJ4t0Pn/8seKWyhG6zGaShCI9f9v6igzua0qhTt9sR4ccEtzG0SywkbqKyblqCWgT7N0sGWjRVaG2B9TVe4IofHRn2GFJeIZ3FBupKgMLHg+F6KGQPoeXPgSY63P5udY492UYZ9+SmihzKb4LBvtKxIya8czKvk/XQzwWHoUaTwZCxE1W8VfS5kd33Yb1vEIgQHpOLRfzyPV2tyGyQG5gNHMc9N3f/vjl4P3k/q96X/QdBqf3g x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: x-ms-office365-filtering-correlation-id: e6ea4aab-39d2-4665-46e4-08d53312927b x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231022)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011); SRVR:FRAPR01MB0482; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:FRAPR01MB0482; x-forefront-prvs: 05015EB482 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(376002)(346002)(189002)(199003)(86362001)(50986999)(54896002)(102836003)(55016002)(6306002)(9686003)(6116002)(189998001)(790700001)(53936002)(316002)(101416001)(110136005)(3846002)(93886005)(2950100002)(5660300001)(561944003)(97736004)(33656002)(54356999)(76176999)(52396003)(7696005)(551934003)(4326008)(75402003)(8936002)(14454004)(3280700002)(2900100001)(478600001)(3660700001)(66066001)(2906002)(68736007)(5250100002)(72206003)(7736002)(81166006)(8676002)(81156014)(105586002)(106356001)(74482002)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0482; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB048397A514068C97FD627A65F9260FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e6ea4aab-39d2-4665-46e4-08d53312927b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2017 08:08:40.2148 (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] 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, 24 Nov 2017 08:18:14 -0000 --_000_FRAPR01MB048397A514068C97FD627A65F9260FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christer, normally the refresher do not change you are right. But I have also seen ca= ses where the refresher is toggling. And it was working over hours. There are also cases that both sides are sending refreshes. i.e they don't = care. Of course this use case is pointing to implementations which are not really= compliant. But e Re-INVITE can be sent in each situation of the call. Best Regards Roland Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer Holm= berg Gesendet: Freitag, 24. November 2017 08:13 An: Roman Shpount Cc: sipcore@ietf.org; Jesske, Roland Betreff: Re: [sipcore] Session timer fix Hi, Your proposal says: "2) Specify that a UAC or proxy should duplicate in an embedded UPDATE whatever timer stuff they put in the enclosing INVITE transaction. And then the UAC for the INVITE should process the timer stuff in the 2xx response to the INVITE the same as if the UPDATE didn't happen. (What it does to process the timer stuff in the 200 for the UPDATE is irrelevant.)= =B2 If I understand the text, I DO agree with it. The difference is that I suggest that UPDATEs should never be allowed to change the refresher value: inside an INVITE transaction they simply mirror what is in the INVITE request, and outside an INVITE transaction they mirror what has been negotiated. That way, I don=B9t think entities need to know whether the UPDATE is sent inside or outside an INVUTE transaction, because the UPDATE is not allowed to change anything. > There are cases when UPDATE is being used a simply "lighter" version of r= e-INVITE with SDP. You can do the same things using UPDATE as you do using = re-INVITE, > but you can do it using twice fewer messages. Breaking this because of so= me corner case in Session-Timer negotiation greatly diminishes UPDATE messa= ge utility. So, how often is the refresher changed during a call? As far as I know, in = the vast majority of cases the session-timer negotiation takes place during= the initial INVITE, and then it doesn't change during the call. Regards, Christer --_000_FRAPR01MB048397A514068C97FD627A65F9260FRAPR01MB0483DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Christ= er,

normally = the refresher do not change you are right. But I have also seen cases where= the refresher is toggling.

And it wa= s working over hours.

&nbs= p;

There are= also cases that both sides are sending refreshes. i.e they don’t car= e.

&nbs= p;

Of course= this use case is pointing to implementations which are not really complian= t. But e Re-INVITE can be sent in each situation of the call.

&nbs= p;

Best Rega= rds

&nbs= p;

Roland

Von: sipcore [mailto:sipcore-bounces= @ietf.org] Im Auftrag von Christer Holmberg
Gesendet: Freitag, 24. November 2017 08:13
An: Roman Shpount <roman@telurix.com>
Cc: sipcore@ietf.org; Jesske, Roland <R.Jesske@telekom.de>
Betreff: Re: [sipcore] Session timer fix

 

Hi,

 

Your proposal sa= ys:

"2) Specify that a UAC or proxy should duplicat= e in an embedded UPDATE
whatever timer stuff they put in the enclosing INVIT= E transaction. And
then the UAC for the INVITE should process the timer= stuff in the 2xx
response to the INVITE the same as if the UPDATE did= n't happen. (What it
does to process the timer stuff in the 200 for the UPDATE is irrelevant.)= =B2

If I understand the text, I DO agree with it.

The difference is that I suggest that UPDATEs should never be allowed to change the refresher value: inside an INVITE transaction they simply
mirror what is in the INVITE request, and outside an INVITE transaction
they mirror what has been negotiated. That way, I don=B9t think entities need to know whether the UPDATE is sent inside or outside an INVUTE
transaction, because the UPDATE is not allowed to change anything.

 

> There are cases when UPDATE is bei= ng used a simply "lighter" version of re-INVITE with SDP. You can= do the same things using UPDATE as you do using re-INVITE,

> but you can do it using twice fewe= r messages. Breaking this because of some corner case in Session-Timer nego= tiation greatly diminishes UPDATE message utility.

 

So, how often is the refresher changed = during a call? As far as I know, in the vast majority of cases the session-= timer negotiation takes place during the initial INVITE, and then it doesn’t change during the call.

 

Regards,

 

Christer

 

 

--_000_FRAPR01MB048397A514068C97FD627A65F9260FRAPR01MB0483DEUP_-- From nobody Sat Nov 25 09:05: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 60ADF127863 for ; Sat, 25 Nov 2017 09:05:05 -0800 (PST) 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 425Nk0xdsS84 for ; Sat, 25 Nov 2017 09:05:04 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 5223E1204DA for ; Sat, 25 Nov 2017 09:05:04 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id 4so16919871pge.1 for ; Sat, 25 Nov 2017 09:05:04 -0800 (PST) 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=VEIprhCDKTU/j42bxR5DO3nXH69d6Nb27x4hZMJ5lhA=; b=VzERNs3dKx24csFTiRxS2sbAULSebhPB7XCU9iZF6dxYrpYv84Ilv0V/Ke1gQ8L1FZ DwdmshHWaPacILwQF3Op9k/SkD/4R3R3J33Mrp1pyCVKjhbG0gLDlLt117bnXEebf3N2 lv2cukVQpF00BwLpJx7Vy3UroMSvYuGAG1WH1cUbxsc76xjZulIM5dMB+EAAF8oEh34K 4xzUD36g8c8KMdX8VU4+EFBBzoB6yltUBfyqB1GAvk0buH+YDNDX0QNqC20cgMaeN+V5 mxnN00f3RkvJq2nLF8nu3kjGWT5jVZOXHRgf2D80sBSDyFtP2vXXSmM1FIIjFBgMbdxN Qqsg== 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=VEIprhCDKTU/j42bxR5DO3nXH69d6Nb27x4hZMJ5lhA=; b=mmbrIAQ34jMjAI4j4ZqgYzqqbW9e0X2zMxEDjRcBOWq0M6ukUSaoQ9MKwiKuftHqrn rKbsXTuGIraLryZpGZ+8DQcVB2Ob26CquvQ/Dc6fZXBEnznB9NAzVPj9S+6/+EaaOmav zSXl2fMJZ7cVQdlmUxhtAoAbn5peqKR2iKzdCKZ1p0ibo5G/cEXCTRFC5otJxCyoX5UP l9tfMV/h+Lv6y3sb1zIIfTPBLIZoYl5Ir7oyW9lMyjIx7SjRBdqk53VO5qQn6KFOgLkI 4HAgWgNx/1hoc25ZlHjRlwPWU5om3a3x5roeeLBs/TKigAWJo54Bh1kZ1hbGw7zCVL55 kOsA== X-Gm-Message-State: AJaThX7XXzRSTieHls9F7mLGjAYNU391S3dNFou/IYLLwPaPsfAtxwuv 2hDUXQ6RvBDT1V0qbPHdHejdHqV6 X-Google-Smtp-Source: AGs4zMbL6bwPrZHFzoatw6labhw8zHiUzTFR6oLm6Zcr7wyTafXapcCQbN6Mio+Yw8nfzVZltvn73Q== X-Received: by 10.99.165.79 with SMTP id r15mr31611667pgu.280.1511629503717; Sat, 25 Nov 2017 09:05:03 -0800 (PST) Received: from mail-pl0-f45.google.com (mail-pl0-f45.google.com. [209.85.160.45]) by smtp.gmail.com with ESMTPSA id g7sm35663665pgn.43.2017.11.25.09.05.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Nov 2017 09:05:01 -0800 (PST) Received: by mail-pl0-f45.google.com with SMTP id k7so6039103pln.13 for ; Sat, 25 Nov 2017 09:05:01 -0800 (PST) X-Received: by 10.84.246.18 with SMTP id k18mr21907313pll.374.1511629501639; Sat, 25 Nov 2017 09:05:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Sat, 25 Nov 2017 09:05:00 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> From: Roman Shpount Date: Sat, 25 Nov 2017 12:05:00 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="089e082d74587a3188055ed1ab29" 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: Sat, 25 Nov 2017 17:05:05 -0000 --089e082d74587a3188055ed1ab29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 24, 2017 at 2:12 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > So, how often is the refresher changed during a call? As far as I know, i= n > the vast majority of cases the session-timer negotiation takes place duri= ng > the initial INVITE, and then it doesn=E2=80=99t change during the call. > > One possible reason for refresher change can be third party call control. You have a B2BUA which is mostly stateless and relies on one of the user agents to send session refresh. If as a result of B2BUA activity two previously connected calls are connected to each other, both can previously be refresher s (or neither of them would be a refresher), and refresher role would need to be renegotiated. Regards, _____________ Roman Shpount --089e082d74587a3188055ed1ab29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 24, 2017 at 2:12 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
So, how often is the refresher changed during a call? As far as I know= , in the vast majority of cases the session-timer negotiation takes place d= uring the initial INVITE, and then it doesn=E2=80=99t change during the cal= l.


One possible reason f= or refresher change can be third party call control. You have a B2BUA which= is mostly stateless and relies on one of the user agents to send session r= efresh. If as a result of B2BUA activity two previously connected calls are= connected to each other, both can previously be refresher s (or neither of= them would be a refresher), and refresher role would need to be renegotiat= ed.

Regards,=C2=A0
_____________
Roman Shpount
=C2=A0
=
--089e082d74587a3188055ed1ab29-- From nobody Sun Nov 26 23:14: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 4EACC124BE8 for ; Sun, 26 Nov 2017 23:14:49 -0800 (PST) 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 rOZnruKQQuhU for ; Sun, 26 Nov 2017 23:14:47 -0800 (PST) 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 19E8A1200CF for ; Sun, 26 Nov 2017 23:14:46 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-87-5a1bbb64eb0c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.FF.08439.46BBB1A5; Mon, 27 Nov 2017 08:14:44 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Mon, 27 Nov 2017 08:14:44 +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+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgA== Date: Mon, 27 Nov 2017 07:14:43 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@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.16] Content-Type: multipart/alternative; boundary="_000_D641894A265ACchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2J7oG7KbukogxVTzCxWbDjAatF0p4vN YsaFqcwWX39sYnNg8fj7/gOTx5IlP5k82l4qeNyaUhDAEsVlk5Kak1mWWqRvl8CVMXl7RMEJ nYonB/+wNTA+U+ti5OSQEDCR2HHlNmMXIxeHkMBhRon3S6axQDhLGCXaL6xg7WLk4GATsJDo /qcN0iAioCrx9/tkJhCbWaBS4kPfYTBbWEBD4tCe3ywQNZoSF08tYwKZIyIwiVFi6eMmdpAE C1Dz1qctjCA2r4C1xNf/T6GWTeaUmLj0KtgkToFAiT3/IRoYBcQkvp9aA7VNXOLWk/lMEGcL SCzZc54ZwhaVePn4HyuILSqgJ7HhxG12iLiixM6z7cwgDzALJEicfBgKsVdQ4uTMJywTGEVn IZk6C6FqFpIqiBIDiffn5jND2NoSyxa+hrL1JTZ+OcsIYVtLTDk+nxVZzQJGjlWMosWpxUm5 6UbGeqlFmcnFxfl5enmpJZsYgZF6cMtv1R2Ml984HmIU4GBU4uE1nisdJcSaWFZcmXuIUYKD WUmEV6BcKkqINyWxsiq1KD++qDQntfgQozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QD Y6F+XtiNq497D1wPElDPvqrJs/Wyl3emusCcxpVn9hUszOUU7j2++AlrrYnHdxfrPI23NgbX Wrj3HZv6dU/f8+TvL1TrLPQYV0a8e7fty/37qt9S447Y+5/R3cg7bZllf4y0ranlk5lShxlj 5a69bCnivJ3WtuODma/Yi/n1XVr5BVcZGd3SlViKMxINtZiLihMBHIDJF9ACAAA= 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, 27 Nov 2017 07:14:49 -0000 --_000_D641894A265ACchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Ok, so what making the restriction for UPDATEs sent inside (re-)INVITE tran= sactions, as suggested by Paul (alternative #2)? I.e., when an UPDATE is sent inside a (re-)INVITE transaction, the s-t valu= es must reflect the values sent in the INVITE request/responses. Regards, Christer From: Roman Shpount > Date: Saturday 25 November 2017 at 19:05 To: Christer Holmberg > Cc: "pkyzivat@alum.mit.edu" >, "R.Jesske@telekom.de" >, "sipcore@ie= tf.org" = > Subject: Re: [sipcore] Session timer fix On Fri, Nov 24, 2017 at 2:12 AM, Christer Holmberg > wrote: So, how often is the refresher changed during a call? As far as I know, in = the vast majority of cases the session-timer negotiation takes place during= the initial INVITE, and then it doesn=92t change during the call. One possible reason for refresher change can be third party call control. Y= ou have a B2BUA which is mostly stateless and relies on one of the user age= nts to send session refresh. If as a result of B2BUA activity two previousl= y connected calls are connected to each other, both can previously be refre= sher s (or neither of them would be a refresher), and refresher role would = need to be renegotiated. Regards, _____________ Roman Shpount --_000_D641894A265ACchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7590E1F1B3430848A7D0F3D608EEFAD0@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Ok, so what making the restriction for UPDATEs sent inside (re-)INVITE= transactions, as suggested by Paul (alternative #2)?

I.e., when an UPDATE is sent inside a (re-)INVITE transaction, the s-t= values must reflect the values sent in the INVITE request/responses.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Saturday 25 November 2017 at = 19:05
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>, "R.Jesske@telekom.de" <R.Jesske@telekom.de>, "sipcore@ietf.org" <<= a href=3D"mailto:sipcore@ietf.org">sipcore@ietf.org>
Subject: Re: [sipcore] Session time= r fix

On Fri, Nov 24, 2017 at 2:12 AM, Christer Ho= lmberg <chr= ister.holmberg@ericsson.com> wrote:
So, how often is the refresher changed during a call? As far as I know= , in the vast majority of cases the session-timer negotiation takes place d= uring the initial INVITE, and then it doesn=92t change during the call.


One possible reason for refresher change can be third party call contr= ol. You have a B2BUA which is mostly stateless and relies on one of the use= r agents to send session refresh. If as a result of B2BUA activity two prev= iously connected calls are connected to each other, both can previously be refresher s (or neither of them woul= d be a refresher), and refresher role would need to be renegotiated.

Regards, 
_____________
Roman Shpount
 
 --_000_D641894A265ACchristerholmbergericssoncom_-- From nobody Mon Nov 27 13:54: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 E09B91200C5 for ; Mon, 27 Nov 2017 13:54:24 -0800 (PST) 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 ZYZbnq9D3Y5j for ; Mon, 27 Nov 2017 13:54:23 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::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 290C81293F2 for ; Mon, 27 Nov 2017 13:54:23 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id s75so19326806pgs.0 for ; Mon, 27 Nov 2017 13:54:23 -0800 (PST) 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=9PhXtfwNOWDcyD0YsknARKTQxRfXFIHqEdVn+p2H1Rk=; b=lMli4BBWZcL3QhkDzcPYQZ9bDTvpGy4IcUIseu0ihg3nueZoW1+h54xa2FXMk3eTzW 9SoPmOPIMlCL1nQYswwEB3OeARUxgF46Whzzxztnzqwc77PuHd/JB01pFrKE+514OSRI gabkTZ0ysA0MIodKWZXSW+gjuYXgFhotWGxK0QZPxOYVM26kEajlmztMPq7ssTSlV90F i8e+F4KRGoiNLs0IMj7hzzE8VXHQDPB6M5/cGCV+g8Po3i1hXPg2f93KfVHnWBDPigd+ OLn8coIGws5CoDNi93ItqsC81+BrWWLmX6togcikm1c9gg6qalAdM/1nKCAqie1vdBe+ NvNQ== 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=9PhXtfwNOWDcyD0YsknARKTQxRfXFIHqEdVn+p2H1Rk=; b=kEQzjOKM+TGMWkbSVwIxNn7mHq4hfHomDINcqPNIRGWJzTsLKkTbk41dU30ZEh/iQR SxDguHOzRzA3SYLesPYgI9r+a0W0CMrW+ILkdr8QQMCXcoqbstCBwXZ61QnSShQcdVs4 xKaeNkq58Nnmpv4eT43bMeNeWc4qEXHM4ytIB011BLRut9Lc91VP+2l7ZrT8lIpPYt7N kUrcz0SjZinlOWjWxKKIWRrA1C1UCNbbdVFaSctDgLAB8vnoTOaPXY7pRNYbBRQIm2bv k5y6zg0gnoOWd7JP1db2uTXJhodEdQTuQJp2RGLvTK9NZRUNo8bB3urAekQKU9df/7h/ TMtw== X-Gm-Message-State: AJaThX4vtGJGRSzOogZ+z8+jzzCRpMeqrnpnRIknGXmyjjtz43P/RGjJ TMQpd4wqyynIeLu55bwSnYotptH1 X-Google-Smtp-Source: AGs4zMb23S5cm5NeB/iBKZU5L+q4POPGoO340YvbiDigelus1qIIbbAIwTgZiv1L4Dd9Z/4fZXS33A== X-Received: by 10.101.81.11 with SMTP id f11mr6899258pgq.432.1511819662588; Mon, 27 Nov 2017 13:54:22 -0800 (PST) Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com. [209.85.192.172]) by smtp.gmail.com with ESMTPSA id o63sm51212173pfg.101.2017.11.27.13.54.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 13:54:21 -0800 (PST) Received: by mail-pf0-f172.google.com with SMTP id r14so11467347pfl.11 for ; Mon, 27 Nov 2017 13:54:21 -0800 (PST) X-Received: by 10.99.106.137 with SMTP id f131mr38702207pgc.334.1511819661107; Mon, 27 Nov 2017 13:54:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Mon, 27 Nov 2017 13:54:20 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> From: Roman Shpount Date: Mon, 27 Nov 2017 16:54:20 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c189c24dd6b28055efdf1d8" 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, 27 Nov 2017 21:54:25 -0000 --94eb2c189c24dd6b28055efdf1d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think restriction that UPDATE sent within (re-)INVITE must match the Session-Timer value sent in INVITE request/responses should work. The question is how do you deal with 2XX responses from non-compliant implementations. To summarize, what you are proposing : 1. When UAC is sending UPDATE during INVITE transaction, it should put the same value in S-T as it put in the original INVITE 2. When proxy adds S-T header to UPDATE, is should add it in such as way that it would match S-T header added by this proxy to INVITE 3. UAS should respond to UPDATE with the same S-T header value as for the 2XX response in enclosing INVITE transaction. 4. When sending UPDATE during INVITE transaction UAS should add the same S-T header value as for the 2XX response in enclosing INVITE transaction. 5. If during INVITE transaction UA receives an UPDATE which does not match S-T header of the INVITE message, it should send 491 (or other new error) response to UPDATE Questions: 1. What happens when UAC receives a 2XX INVITE response with S-T that did not match the S-T value negotiated by UPDATE transaction during this INVITE transaction? 2. What happens when UAC receives a 2XX UPDATE response with S-T that did not match the 2XX response for the previous UPDATE transaction? Regards, _____________ Roman Shpount On Mon, Nov 27, 2017 at 2:14 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Ok, so what making the restriction for UPDATEs sent inside (re-)INVITE > transactions, as suggested by Paul (alternative #2)? > > I.e., when an UPDATE is sent inside a (re-)INVITE transaction, the s-t > values must reflect the values sent in the INVITE request/responses. > > Regards, > > Christer > > From: Roman Shpount > Date: Saturday 25 November 2017 at 19:05 > To: Christer Holmberg > Cc: "pkyzivat@alum.mit.edu" , "R.Jesske@telekom.de= " > , "sipcore@ietf.org" > Subject: Re: [sipcore] Session timer fix > > On Fri, Nov 24, 2017 at 2:12 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> So, how often is the refresher changed during a call? As far as I know, >> in the vast majority of cases the session-timer negotiation takes place >> during the initial INVITE, and then it doesn=E2=80=99t change during the= call. >> >> > One possible reason for refresher change can be third party call control. > You have a B2BUA which is mostly stateless and relies on one of the user > agents to send session refresh. If as a result of B2BUA activity two > previously connected calls are connected to each other, both can previous= ly > be refresher s (or neither of them would be a refresher), and refresher > role would need to be renegotiated. > > Regards, > _____________ > Roman Shpount > > --94eb2c189c24dd6b28055efdf1d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think restriction that UPDA= TE sent within (re-)INVITE must match the Session-Timer value sent in INVIT= E request/responses should work. The question is how do you deal with 2XX r= esponses from non-compliant implementations.

To summariz= e, what you are proposing :

1. When UAC is sen= ding UPDATE during INVITE transaction, it should put the same value in S-T = as it put in the original INVITE
2. When proxy adds S-T header to= UPDATE, is should add it in such as way that it would match S-T header add= ed by this proxy to INVITE
3. UAS should respond to UPDATE with t= he same S-T header value as for the 2XX response in enclosing INVITE transa= ction.
4. When sending UPDATE during INVITE transaction UAS shoul= d add the same S-T header value as for the 2XX response in enclosing INVITE= transaction.
5. If during INVITE transaction UA receives an UPDA= TE which does not match S-T header of the INVITE message, it should send 49= 1 (or other new error) response to UPDATE

Question= s:

1. What happens when UAC receives a 2XX INVITE = response with S-T that did not match the S-T value negotiated by UPDATE tra= nsaction during this INVITE transaction?
2. What happens when UAC= receives a 2XX UPDATE response with S-T that did not match the 2XX respons= e for the previous UPDATE transaction?

Regards= ,

_____________
= Roman Shpount

On Mon, Nov 27, 2017 at 2:14 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

Ok, so what making the restriction for UPDATEs sent inside (re-)INVITE= transactions, as suggested by Paul (alternative #2)?

I.e., when an UPDATE is sent inside a (re-)INVITE transaction, the s-t= values must reflect the values sent in the INVITE request/responses.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Saturday 25 November 2017 at = 19:05
To: Christer Holmberg <christer.holmb= erg@ericsson.com>
Cc: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu= >, "R.= Jesske@telekom.de" <R.Jesske@telekom.de>, "sipcore@ietf.o= rg" <sipc= ore@ietf.org>
Subject: Re: [sipcore] Session time= r fix

On Fri, Nov 24, 2017 a= t 2:12 AM, Christer Holmberg <chr= ister.holmberg@ericsson.com> wrote:
So, how often is the refresher changed during a call? As far as I know= , in the vast majority of cases the session-timer negotiation takes place d= uring the initial INVITE, and then it doesn=E2=80=99t change during the cal= l.


One possible reason for refresher change can be third party call contr= ol. You have a B2BUA which is mostly stateless and relies on one of the use= r agents to send session refresh. If as a result of B2BUA activity two prev= iously connected calls are connected to each other, both can previously be refresher s (or neither of them woul= d be a refresher), and refresher role would need to be renegotiated.

Regards,=C2=A0
_____________
Roman Shpount
=C2=A0

--94eb2c189c24dd6b28055efdf1d8-- From nobody Mon Nov 27 23:52: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 17974124B17 for ; Mon, 27 Nov 2017 23:51:58 -0800 (PST) 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 lh3M0e8dGVKo for ; Mon, 27 Nov 2017 23:51:56 -0800 (PST) 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 5C4991200E5 for ; Mon, 27 Nov 2017 23:51:56 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-2c-5a1d159a9c10 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FE.00.08439.A951D1A5; Tue, 28 Nov 2017 08:51:54 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 28 Nov 2017 08:51:54 +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+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgIAA0dwAgADK3wA= Date: Tue, 28 Nov 2017 07:51:53 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@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.18] Content-Type: multipart/alternative; boundary="_000_D642DD60266DBchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2J7uO4sUdkog/WbpS1WbDjAatF0p4vN YsaFqcwWX39sYnNg8fj7/gOTx5IlP5k82l4qeNyaUhDAEsVlk5Kak1mWWqRvl8CVMfd+TsE9 3Yqbnw+zNDB+VO1i5OSQEDCR2HezlbWLkYtDSOAwo8T0ReeYIZwljBIPd7cxdjFycLAJWEh0 /9MGaRARUJX4+30yE4jNLFAp8aHvMJgtLKAhcWjPbxaIGk2Ji6eWMYHMERGYxygxYeIDsCIW oOaTS9uYQGbyClhLLGvmgtjVwyUxaetqsBpOgUCJKa8/s4HYjAJiEt9PrYFaJi5x68l8Joir BSSW7DnPDGGLSrx8/I8VxBYV0JPYcOI2O0RcUeLjq32MEL0JEsu+t4PV8woISpyc+YRlAqPo LCRjZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZZwG9wwz0zqxfbMhKFjByrGIULU4t TspNNzLWSy3KTC4uzs/Ty0st2cQIjNSDW36r7mC8/MbxEKMAB6MSD28ki2yUEGtiWXFl7iFG CQ5mJRHeIi6gEG9KYmVValF+fFFpTmrxIUZpDhYlcd6TnrxRQgLpiSWp2ampBalFMFkmDk6p BkaxBSabdkdG8fZIbMp6Ff3vTpJ+/4M1GxJ2N7a6uV5i9mux+DWxhfXqHWXVgkb1uKmHQz6u O+dZPYnJ6abp9B/Vt9LCar5p/sx8d/C18svddlsm1aQyi266t7PUcz/fcctOn/LN0h3GXO6x d93PWFxUPbcwml0/n/Fv6P0/Mdrqy/lFszatv6vEUpyRaKjFXFScCADX2eXh0AIAAA== 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, 28 Nov 2017 07:51:58 -0000 --_000_D642DD60266DBchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > I think restriction that UPDATE sent within (re-)INVITE must match the Se= ssion-Timer value sent in INVITE request/responses should work. > The question is how do you deal with 2XX responses from non-compliant imp= lementations. > > To summarize, what you are proposing : > > 1. When UAC is sending UPDATE during INVITE transaction, it should put th= e same value in S-T as it put in the original INVITE Yes. > 2. When proxy adds S-T header to UPDATE, is should add it in such as way = that it would match S-T header added by this proxy to INVITE Yes. The RFC already says: 'The proxy MUST NOT insert or modify the value of the 'refresher' parameter= in the Session-Expires header field.' =85so as long as the UA doesn=92t change the =91refresher parameter it shou= ldn=92t be a problem. > 3. UAS should respond to UPDATE with the same S-T header value as for the= 2XX response in enclosing INVITE transaction. Yes. > 4. When sending UPDATE during INVITE transaction UAS should add the same = S-T header value as for the 2XX response in enclosing INVITE transaction. Yes. > 5. If during INVITE transaction UA receives an UPDATE which does not matc= h S-T header of the INVITE message, it should send 491 (or other new error)= response to UPDATE Yes. > Questions: > > 1. What happens when UAC receives a 2XX INVITE response with S-T that did= not match the S-T value negotiated by UPDATE transaction during this INVIT= E transaction? Error case. > 2. What happens when UAC receives a 2XX UPDATE response with S-T that did= not match the 2XX response for the previous UPDATE transaction? Error case. Regards, Christer --_000_D642DD60266DBchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <68E177450678D246A0D1D89ABF2AFA4D@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

> I think restriction that UPDATE sent within (re-)INVI= TE must match the Session-Timer value sent in INVITE request/responses shou= ld work.
> The question is how do you deal with 2XX responses from non-compl= iant implementations.
>
> To summarize, what you are proposing :
>
> 1. When UAC is sending UPDATE during INVITE transaction, it shoul= d put the same value in S-T as it put in the original INVITE

Yes.

> 2. When proxy adds S-T header to UPDATE, is should add it in such= as way that it would match S-T header added by this proxy to INVITE

Yes. 

The RFC already says:

'The proxy MUST NOT insert= or modify the value of the 'refresher' parameter in the Sessio= n-Expires header field.'

=85so as long as the UA doesn=92t change the =91refresher parameter it= shouldn=92t be a problem.


> 3. UAS should respond to UPDATE with the same S-T header value as= for the 2XX response in enclosing INVITE transaction.

Yes.

> 4. When sending UPDATE during INVITE transaction UAS should add t= he same S-T header value as for the 2XX response in enclosing INVITE transa= ction.

Yes.

> 5. If during INVITE transaction UA receives an UPDATE which does = not match S-T header of the INVITE message, it should send 491 (or other ne= w error) response to UPDATE

Yes.


> Questions:
>
> 1. What happens when UAC receives a 2XX INVITE response with S-T = that did not match the S-T value negotiated by UPDATE transaction during th= is INVITE transaction?

Error case. 

> 2. What happens when UAC receives a 2XX UPDATE response with S-T = that did not match the 2XX response for the previous UPDATE transaction?

Error case.

Regards,

Christer


--_000_D642DD60266DBchristerholmbergericssoncom_-- From nobody Tue Nov 28 11:49: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 3BC71126CBF for ; Tue, 28 Nov 2017 11:49:01 -0800 (PST) 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=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 8K-FjeaCLp8C for ; Tue, 28 Nov 2017 11:49:00 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 1766E1200CF for ; Tue, 28 Nov 2017 11:49:00 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id l24so399576pfj.6 for ; Tue, 28 Nov 2017 11:49:00 -0800 (PST) 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=J8fQFYFkSV3OHWL/o6MJVBRuMBXQg8UmZLTdzi1DPg0=; b=pI383au+eXzEHFxtA+P9NoRd6Hv+h/H9Gq5U7xmuSsRbbwZHsM4YyTTskncOqpHZew 5UbDoBqbQSfVaxkk3ZFMDajApsFHYMwnFsGipkECdcJtJnSYEKcU+ms0SVfrfuBjASU4 6WrwlQQiZOleo7ZoKvCeqypdAdDH/z3gmaK6g01eKtAr337T3AxR35ve2cmBhyrWx7XA j0WvCYrSMHinXhgtHCBcOko8RWJwgwwtYCf+3wGYDrifXsSfCrUQxx0LAWhSIS7xErvB CrgbMVsa9eVZOpGkRe+QqwH9J8SuFI/45DuUfWuPNmbgvdLCG5cxDfCkegvDq7sa+g4E BGnA== 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=J8fQFYFkSV3OHWL/o6MJVBRuMBXQg8UmZLTdzi1DPg0=; b=Y93MkJm9BIOwFr5lDzLzktSaK0owc/CPphkd1k62bY3FhQoiXU/PSEVLSxbhShMKil /L2tYd0QLNBln1qU2lTPlJEfQcCF65zN3L2pHOgMlLAKd06g0H5Tz8rX43NQiU5c3IeB FKLXCa0BbvTfjjg4DxFmvgWFgX52a8oxhQc65dBUo4DzRtFAyvi6gT2dZhJy29FVC6re mz1GLexE9aUxLTRwAnfdbQbwdHeP74F+178NBCv1y6V+PAjfCc9puqUolk4NxJy+dik7 uOS5sAj/GDM/KO2lKRXXKYm8rx04hfAYuECM+BPbH0IuuGZpoMX+bpDne53tQNwnrksA zApA== X-Gm-Message-State: AJaThX6ZxjtDwadnBIZzyQK687E+AqO+WBQwv/l87cp3Vu1F6s6z0pqh lBKqHeFnoOOo4XvFpnPTpfbWhz4m X-Google-Smtp-Source: AGs4zMZaBYmp/daxaAUYowF0UazTDdYRq7UZyFY38skC9Y+aJi5MPN8VXLw2YldIXzRt58Ij9eEiKg== X-Received: by 10.101.73.203 with SMTP id t11mr260935pgs.446.1511898539580; Tue, 28 Nov 2017 11:48:59 -0800 (PST) Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com. [74.125.83.46]) by smtp.gmail.com with ESMTPSA id e9sm55705575pfl.138.2017.11.28.11.48.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 11:48:58 -0800 (PST) Received: by mail-pg0-f46.google.com with SMTP id o2so382000pgc.8 for ; Tue, 28 Nov 2017 11:48:57 -0800 (PST) X-Received: by 10.99.106.137 with SMTP id f131mr268782pgc.334.1511898537653; Tue, 28 Nov 2017 11:48:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 28 Nov 2017 11:48:56 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 28 Nov 2017 14:48:56 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c189c2445fe37055f104fa5" 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, 28 Nov 2017 19:49:01 -0000 --94eb2c189c2445fe37055f104fa5 Content-Type: text/plain; charset="UTF-8" Hi, On Tue, Nov 28, 2017 at 2:51 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > 1. What happens when UAC receives a 2XX INVITE response with S-T that > did not match the S-T value negotiated by UPDATE transaction during this > INVITE transaction? > Error case. > > > 2. What happens when UAC receives a 2XX UPDATE response with S-T that > did not match the 2XX response for the previous UPDATE transaction? > Error case. > How do you want to handle these error cases? Two options that I see are: a. Terminate the dialog (hang up) b. Issue a new UPDATE to set refresher to a known state. Regards, _____________ Roman Shpount --94eb2c189c2445fe37055f104fa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div class=3D"gmail_signature">
On= Tue, Nov 28, 2017 at 2:51 AM, Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
> 1. What happens when UAC receives a 2XX INVITE response with S-T = that did not match the S-T value negotiated by UPDATE transaction during th= is INVITE transaction?
Error case.=C2=A0

> 2. What happens when UAC receives a 2XX UPDATE response with S-T = that did not match the 2XX response for the previous UPDATE transaction?
Error case.
=C2=A0
=C2= =A0
How do you want to handle these error cases? Two options that= I see are:
a. Terminate the dialog (hang up)
b. Issue = a new UPDATE to set refresher to a known state.

Re= gards,
_____________
Roman Shpo= unt
=C2=A0
--94eb2c189c2445fe37055f104fa5-- From nobody Tue Nov 28 11:53: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 8EA2E126CBF for ; Tue, 28 Nov 2017 11:53:24 -0800 (PST) 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 2c4eK4hSUSj3 for ; Tue, 28 Nov 2017 11:53:23 -0800 (PST) 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 1D2AE1200CF for ; Tue, 28 Nov 2017 11:53:22 -0800 (PST) X-AuditID: c1b4fb2d-d6fff700000036aa-be-5a1dbeb03604 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E0.AD.13994.0BEBD1A5; Tue, 28 Nov 2017 20:53:20 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Tue, 28 Nov 2017 20:53:19 +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+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgIAA0dwAgADK3wCAAKRtAIAAEWVg Date: Tue, 28 Nov 2017 19:53:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B5C67FEA1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdVXfDPtkog0MLtSxWbDjAatF0p4vN YsaFqcwWX39sYnNg8fj7/gOTx5IlP5k82l4qeNyaUhDAEsVlk5Kak1mWWqRvl8CV8X51VkEP R8XKXaINjB/Yuxg5OSQETCQe/5wNZHNxCAkcZpTY8Hw3E0hCSGAJo8SOaUldjBwcbAIWEt3/ tEHCIgKqEn+/TwYrYRaolPjQdxjMFhbQkPg89zIzRI2mxMVTy5hAZooIrGKUuP//BFiCBaj5 +e5LYA28Ar4Sr3Y/YoFY3MotsX/hP1aQZZwCgRJtK1xBahgFxCS+n1oDtUxc4taT+UwQRwtI LNlznhnCFpV4+RikFcRWkmhc8gRsDDPQEet36UO0KkpM6X7IDrFWUOLkzCcsExhFZyGZOguh YxaSjllIOhYwsqxiFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIyhg1t+6+5gXP3a8RCjAAej Eg/vjF2yUUKsiWXFlbmHGCU4mJVEeCsnAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInznvTkjRIS SE8sSc1OTS1ILYLJMnFwSjUwrro+ZcJ8n83TOEUURW8FrT3St99jwptTzXLyGwML96hl6JY/ 38xu/PGER+6+5inLPPYsvdazZ/mdedl1m8+wrmXb+YNrw/FFC+uO6YqdjOnYe3aNwss9IXE6 7w4xfZa8aX9+P99+jadZ1QWrt3yOO/8ly+O50G4h5WitI+oXK2bUftPqWeeeXqnEUpyRaKjF XFScCADZ/Ma2nQIAAA== 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, 28 Nov 2017 19:53:24 -0000 SGksDQoNCj4+IDEuIFdoYXQgaGFwcGVucyB3aGVuIFVBQyByZWNlaXZlcyBhIDJYWCBJTlZJVEUg cmVzcG9uc2Ugd2l0aCBTLVQgdGhhdCBkaWQgbm90IG1hdGNoIHRoZSBTLVQgdmFsdWUgDQo+PiBu ZWdvdGlhdGVkIGJ5IFVQREFURSB0cmFuc2FjdGlvbiBkdXJpbmcgdGhpcyBJTlZJVEUgdHJhbnNh Y3Rpb24/DQo+DQo+RXJyb3IgY2FzZS7CoA0KPg0KPj4gMi4gV2hhdCBoYXBwZW5zIHdoZW4gVUFD IHJlY2VpdmVzIGEgMlhYIFVQREFURSByZXNwb25zZSB3aXRoIFMtVCB0aGF0IGRpZCBub3QgbWF0 Y2ggdGhlIDJYWCByZXNwb25zZQ0KPj4gZm9yIHRoZSBwcmV2aW91cyBVUERBVEUgdHJhbnNhY3Rp b24/DQo+DQo+RXJyb3IgY2FzZS4NCj4NCj4gSG93IGRvIHlvdSB3YW50IHRvIGhhbmRsZSB0aGVz ZSBlcnJvciBjYXNlcz8gVHdvIG9wdGlvbnMgdGhhdCBJIHNlZSBhcmU6DQo+IGEuIFRlcm1pbmF0 ZSB0aGUgZGlhbG9nIChoYW5nIHVwKQ0KPiBiLiBJc3N1ZSBhIG5ldyBVUERBVEUgdG8gc2V0IHJl ZnJlc2hlciB0byBhIGtub3duIHN0YXRlLg0KDQpUaG9zZSBhcmUgdHdvIGFsdGVybmF0aXZlcywg eWVzLiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gbWFuZGF0ZSBhbnkgc3BlY2lmaWMgYmVoYXZp b3VyLCBhcyBsb25nIGFzIHdlIG1ha2UgaXQgY2xlYXIgdGhhdCBhbiBlcnJvciBoYXMgb2NjdXJy ZWQgYW5kIGl0IG5lZWRzIHRvIGJlIHRha2VuIGNhcmUgb2YgU09NRUhPVy4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0K From nobody Tue Nov 28 12: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 201F6128D2E for ; Tue, 28 Nov 2017 12:30:56 -0800 (PST) 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 HpvuG-nfQVeh for ; Tue, 28 Nov 2017 12:30:54 -0800 (PST) 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 647A5128B88 for ; Tue, 28 Nov 2017 12:30:54 -0800 (PST) X-AuditID: 1207440d-853ff70000000f42-91-5a1dc77b1167 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 A7.BE.03906.B77CD1A5; Tue, 28 Nov 2017 15:30:52 -0500 (EST) 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 vASKUnaZ010442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Nov 2017 15:30:50 -0500 To: Christer Holmberg , Roman Shpount Cc: "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Tue, 28 Nov 2017 15:30:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixO6iqFtzXDbKoPmYvsWFmYcZLZrudLFZ zLgwldni649NbA4sHr++XmXzWLLkJ5NH20sFj1tTCgJYorhsUlJzMstSi/TtErgyLh2/zl7Q wFvxb99t5gbGyVxdjJwcEgImEh3da5m7GLk4hAR2MEncmHmKCcJ5yCRxfeV3FpAqYQENiUN7 fgPZHBwiAkkSx7pLQMLMAlESLRv2skHUX2SX2H3oPRtIgk1AS2LOof9gvbwC9hLbDx8Gi7MI qEocv3aBFcQWFUiT2HOhA6pGUOLkzCdgNqeAn8Tne72MEAvMJOZtfsgMYYtL3HoynwnClpfY /nYO8wRGgVlI2mchaZmFpGUWkpYFjCyrGOUSc0pzdXMTM3OKU5N1i5MT8/JSi3SN9HIzS/RS U0o3MULCnHcH4/91MocYBTgYlXh4L6yQjRJiTSwrrsw9xCjJwaQkyvtpIVCILyk/pTIjsTgj vqg0J7X4EKMEB7OSCG/lJKAcb0piZVVqUT5MSpqDRUmcV22Jup+QQHpiSWp2ampBahFMVoaD Q0mCt/AYUKNgUWp6akVaZk4JQpqJgxNkOA/Q8GaQGt7igsTc4sx0iPwpRmOOnp4bf5g4ns18 3cAsxJKXn5cqJc67HKRUAKQ0ozQPbhosVb1iFAd6Tpi3DqSKB5jm4Oa9AlrFBLTq5n5pkFUl iQgpqQZGHlfJheG/GnfPzyhfHFLdcvTxosWvch/mbTIWm8+wMPFz6/mIHOluFdv7Kl9FUo7d uC6vu0Jn/gwX1iV7mllmh2aZ1ehdlI849P2Saw6zz5v2f/1961d6Tb4m87Nqo2/V3RyXh4el vggWbJ25zf/U5icnJjX5rj5+y04r9ubJjS0PtrYXb7CrU2Ipzkg01GIuKk4EACM3ODUwAwAA 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, 28 Nov 2017 20:30:56 -0000 On 11/28/17 2:53 PM, Christer Holmberg wrote: > Hi, > >>> 1. What happens when UAC receives a 2XX INVITE response with S-T that did not match the S-T value >>> negotiated by UPDATE transaction during this INVITE transaction? >> >> Error case. >> >>> 2. What happens when UAC receives a 2XX UPDATE response with S-T that did not match the 2XX response >>> for the previous UPDATE transaction? >> >> Error case. >> >> How do you want to handle these error cases? Two options that I see are: >> a. Terminate the dialog (hang up) >> b. Issue a new UPDATE to set refresher to a known state. > > Those are two alternatives, yes. I don't think we need to mandate any specific behaviour, as long as we make it clear that an error has occurred and it needs to be taken care of SOMEHOW. Or you can just ignore the error and hope for the best. My intuition tells me that this will rarely cause a problem. Most of the time a device that doesn't support the update will be compliant with the update by accident. And in a bunch of the remaining cases ignoring a conflicting value in the nested UPDATE won't matter because both ends will settle on what is in the 200/INVITE. And the remaining cases will result in both ends thinking they are UAC or UAS. It isn't a problem if they both think they are the UAC, since then both will attempt to refresh. It is only a problem if they both think they are UAS, since that is the only case when the session won't be refreshed. If that happens, is it worse than having had the call fail? If need be we can work through all the cases. But there are quite a lot of them. Thanks, Paul From nobody Tue Nov 28 12:38: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 F27ED128E19 for ; Tue, 28 Nov 2017 12:38:28 -0800 (PST) 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 d_LUqCoVhnqA for ; Tue, 28 Nov 2017 12:38:27 -0800 (PST) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 205D5128D2E for ; Tue, 28 Nov 2017 12:38:27 -0800 (PST) Received: by mail-pl0-x233.google.com with SMTP id b12so647307plm.3 for ; Tue, 28 Nov 2017 12:38:27 -0800 (PST) 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=LlieglLiFCyDDH5iMDXKaH+juknfk26m2WGInoXAjVE=; b=Py/ptzkZlyVZuJtxbfTvzIvd/eRr0uKx36uVDomZeELMcb4SlaUAZ+UWOYMNwswSSc zURIhmhFmoLsCp/tQSviFv3O3p6xLumlkFoXfTC6XLsJsFIv5lHrJEdpj+rfXB4Mk+sB e17Bqn7LdV9sD8LM2V6qM8Q310vhZlQSCBlefnbF2iexI08BRW+VkBAIAxd4H+zm6oG3 B6suEHLfQfituiC7V6ehWwoNGQM6PQUZu0DUw4zrg04z5t2YzLNYSaXl3F7ATwPusvnb lAb2K/GXBU5i+MK0lzJ8oJrZtzIy21KaUWZjx4Woi4ct7QXWbuT2fq84pG3Dl9wpYKag /tdw== 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=LlieglLiFCyDDH5iMDXKaH+juknfk26m2WGInoXAjVE=; b=s0vqucUJJlh/SBPtoMBXqAH2FZhQ/Z0zoIDFcW++Ar6FMASI/bPZ1sNLylr9PZeOk6 pSK0dta6TBkVFUYKT+BhZLelTQQHT/8OnLUv04PC5XIV9kREVXSYsP+771YaHxdgGaVb H03Zlux+ZeS+b1MyPbZMRnoDQgPMkGNe5BBCDESc+Vhg2VuLPE7ycJuYc2cUg0HrdN49 aP5tz2hzpLPzOCaKxwiTIpueq4RU8z7k5nMSnzD9CTUozmMvusxLixn3zy+v4FK5hSt9 +6Nmm5F+mva8PAO1HlhG5yzP7tnaX6BXhnSA+z/FveDb7YYE/ahcW/+oBuh3mnDM7YRH ttUQ== X-Gm-Message-State: AJaThX5Nk7T/EKcRAzdikWKcgHLAiYSWyN3NI5FsdmbMjL2ndBtK5Hw8 Cl2a1jU/IPaB9X7NMzQTbpYCP82/ X-Google-Smtp-Source: AGs4zMZG/Kba64KgIAbbtYpYJ2Hj3x4M/0o5t9ghx6UWT8fU82qhlNyKuEqUZxZL5X884ULwS+tkwQ== X-Received: by 10.84.215.207 with SMTP id g15mr378845plj.369.1511901506514; Tue, 28 Nov 2017 12:38:26 -0800 (PST) Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com. [74.125.83.53]) by smtp.gmail.com with ESMTPSA id g127sm25471pgc.29.2017.11.28.12.38.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 12:38:25 -0800 (PST) Received: by mail-pg0-f53.google.com with SMTP id j4so450004pgp.1 for ; Tue, 28 Nov 2017 12:38:25 -0800 (PST) X-Received: by 10.99.106.137 with SMTP id f131mr401182pgc.334.1511901505251; Tue, 28 Nov 2017 12:38:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 28 Nov 2017 12:38:24 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 28 Nov 2017 15:38:24 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c189c2427f06d055f1100a4" 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, 28 Nov 2017 20:38:29 -0000 --94eb2c189c2427f06d055f1100a4 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 28, 2017 at 3:30 PM, Paul Kyzivat wrote: > On 11/28/17 2:53 PM, Christer Holmberg wrote: > >> Hi, >> >> 1. What happens when UAC receives a 2XX INVITE response with S-T that did >>>> not match the S-T value >>>> negotiated by UPDATE transaction during this INVITE transaction? >>>> >>> >>> Error case. >>> >>> 2. What happens when UAC receives a 2XX UPDATE response with S-T that >>>> did not match the 2XX response >>>> for the previous UPDATE transaction? >>>> >>> >>> Error case. >>> >>> How do you want to handle these error cases? Two options that I see are: >>> a. Terminate the dialog (hang up) >>> b. Issue a new UPDATE to set refresher to a known state. >>> >> >> Those are two alternatives, yes. I don't think we need to mandate any >> specific behaviour, as long as we make it clear that an error has occurred >> and it needs to be taken care of SOMEHOW. >> > > Or you can just ignore the error and hope for the best. > > My intuition tells me that this will rarely cause a problem. Most of the > time a device that doesn't support the update will be compliant with the > update by accident. And in a bunch of the remaining cases ignoring a > conflicting value in the nested UPDATE won't matter because both ends will > settle on what is in the 200/INVITE. And the remaining cases will result in > both ends thinking they are UAC or UAS. It isn't a problem if they both > think they are the UAC, since then both will attempt to refresh. It is only > a problem if they both think they are UAS, since that is the only case when > the session won't be refreshed. If that happens, is it worse than having > had the call fail? > > If need be we can work through all the cases. But there are quite a lot of > them. > The safest option is to ignore the error if the end point thinks that refresher is UAC and do an UPDATE transaction if end point thinks refresher is UAS. This looks like a better option then hang up or simply ignoring the error. _____________ Roman Shpount --94eb2c189c2427f06d055f1100a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 28, 2017 at 3:30 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 11/28/= 17 2:53 PM, Christer Holmberg wrote:
Hi,

1. What happens when UAC receives a 2XX INVITE response with S-T that did n= ot match the S-T value
negotiated by UPDATE transaction during this INVITE transaction?

Error case.

2. What happens when UAC receives a 2XX UPDATE response with S-T that did n= ot match the 2XX response
for the previous UPDATE transaction?

Error case.

How do you want to handle these error cases? Two options that I see are: a. Terminate the dialog (hang up)
b. Issue a new UPDATE to set refresher to a known state.

Those are two alternatives, yes. I don't think we need to mandate any s= pecific behaviour, as long as we make it clear that an error has occurred a= nd it needs to be taken care of SOMEHOW.

 Or you can just ignore the error and hope for the best.

My intuition tells me that this will rarely cause a problem. Most of the ti= me a device that doesn't support the update will be compliant with the = update by accident. And in a bunch of the remaining cases ignoring a confli= cting value in the nested UPDATE won't matter because both ends will se= ttle on what is in the 200/INVITE. And the remaining cases will result in b= oth ends thinking they are UAC or UAS. It isn't a problem if they both = think they are the UAC, since then both will attempt to refresh. It is only= a problem if they both think they are UAS, since that is the only case whe= n the session won't be refreshed. If that happens, is it worse than hav= ing had the call fail?

If need be we can work through all the cases. But there are quite a lot of = them.

The safest option is to ignore th= e error if the end point thinks that refresher is UAC and do an UPDATE tran= saction if end point thinks refresher is UAS. This looks like a better opti= on then hang up or simply ignoring the error.
_____________
Roman Shpount
=C2=A0
--94eb2c189c2427f06d055f1100a4-- From nobody Tue Nov 28 12:55:02 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 3A0A912773A for ; Tue, 28 Nov 2017 12:55:01 -0800 (PST) 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 Z-j2XXsdOzIp for ; Tue, 28 Nov 2017 12:55:00 -0800 (PST) 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 D01011205D3 for ; Tue, 28 Nov 2017 12:54:59 -0800 (PST) X-AuditID: 12074414-0d3ff70000006ddf-08-5a1dcd226185 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 07.24.28127.22DCD1A5; Tue, 28 Nov 2017 15:54:58 -0500 (EST) 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 vASKsvq7012121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Nov 2017 15:54:57 -0500 To: Roman Shpount Cc: Christer Holmberg , "Jesske, Roland" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <701211ef-f4de-7263-f95c-c7c8128f2951@alum.mit.edu> Date: Tue, 28 Nov 2017 15:54:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.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+NgFprPKsWRmVeSWpSXmKPExsUixO6iqKt0VjbKoPe+pMWFmYcZLZrudLFZ zLgwldni649NbA4sHr++XmXzWLLkJ5NH20sFj1tTCgJYorhsUlJzMstSi/TtErgyXl7ewVhw SaxiTscqxgbGx/xdjJwcEgImEh9/nmXvYuTiEBLYwSRxpPkRI4TzkEni6d89TCBVwgIaEof2 /GYBsUUEVCX+fp/MBFLELDCdUeL3vCZmiI4r7BIXNv5mB6liE9CSmHPoP1gHr4C9RNvnx4wg NgtQ94xXa5lBbFGBNIk9FzqgagQlTs58AmZzCgRKHJyzBsxmFjCTmLf5ITOELS5x68l8Jghb XmL72znMExgFZiFpn4WkZRaSlllIWhYwsqxilEvMKc3VzU3MzClOTdYtTk7My0st0rXQy80s 0UtNKd3ECAl1kR2MR07KHWIU4GBU4uHVWC0bJcSaWFZcmXuIUZKDSUmU99NCoBBfUn5KZUZi cUZ8UWlOavEhRgkOZiUR3spJQDnelMTKqtSifJiUNAeLkjjvt8XqfkIC6YklqdmpqQWpRTBZ GQ4OJQneqaeBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGbwCp4S0uSMwtzkyHyJ9iNObo6bnxh4nj 2czXDcxCLHn5ealS4rzaIKUCIKUZpXlw02Dp6hWjONBzwrxvQap4gKkObt4roFVMQKtu7pcG WVWSiJCSamBk+b3m7NaPZ7KYnS+XSyuefdQ0b5qD5uvkFzyZQRIRZ+sypJ+vmrhfKZ5//x9d 3W/JVzNfZ1nuM9UrVJBO2LGvkot15VZehbKDjl41DofWGttKliTUvjq299U3kdZHom1eX9y/ 7POu9p1b4aKqckl45f8ov/8XHsz8dXLxnXespf84v7FtbVNWYinOSDTUYi4qTgQAyjYr5jID AAA= 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, 28 Nov 2017 20:55:01 -0000 On 11/28/17 3:38 PM, Roman Shpount wrote: > On Tue, Nov 28, 2017 at 3:30 PM, Paul Kyzivat > wrote: > > On 11/28/17 2:53 PM, Christer Holmberg wrote: > > Hi, > > 1. What happens when UAC receives a 2XX INVITE response > with S-T that did not match the S-T value > negotiated by UPDATE transaction during this INVITE > transaction? > > > Error case. > > 2. What happens when UAC receives a 2XX UPDATE response > with S-T that did not match the 2XX response > for the previous UPDATE transaction? > > > Error case. > > How do you want to handle these error cases? Two options > that I see are: > a. Terminate the dialog (hang up) > b. Issue a new UPDATE to set refresher to a known state. > > > Those are two alternatives, yes. I don't think we need to > mandate any specific behaviour, as long as we make it clear that > an error has occurred and it needs to be taken care of SOMEHOW. > > > Or you can just ignore the error and hope for the best. > > My intuition tells me that this will rarely cause a problem. Most of > the time a device that doesn't support the update will be compliant > with the update by accident. And in a bunch of the remaining cases > ignoring a conflicting value in the nested UPDATE won't matter > because both ends will settle on what is in the 200/INVITE. And the > remaining cases will result in both ends thinking they are UAC or > UAS. It isn't a problem if they both think they are the UAC, since > then both will attempt to refresh. It is only a problem if they both > think they are UAS, since that is the only case when the session > won't be refreshed. If that happens, is it worse than having had the > call fail? > > If need be we can work through all the cases. But there are quite a > lot of them. > > > The safest option is to ignore the error if the end point thinks that > refresher is UAC and do an UPDATE transaction if end point thinks > refresher is UAS. This looks like a better option then hang up or simply > ignoring the error. Refining that a bit: If the INVITE transaction completes with a 2xx, then the UA that is nominated to be the UAS based on the 200/INVITE should consider if there was an intervening UPDATE that asked that UA to be the UAC. If so, then it should initiate a new UPDATE transaction to verify the roles. In that request, if it can do either role then it should not specify and thus let other end decide. Perhaps we can refine this so that we can avoid being any more normative. Thanks, Paul From nobody Tue Nov 28 14:34: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 43210127AD4 for ; Tue, 28 Nov 2017 14:34:57 -0800 (PST) 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, 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=kBXRT/E0; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=EiECeyE7 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 4kUMACYXw8mT for ; Tue, 28 Nov 2017 14:34:54 -0800 (PST) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 19D8D12702E for ; Tue, 28 Nov 2017 14:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1511908494; x=1543444494; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WnFyvbyZitsFntpr+ERKVZJgmyemI0tVOW4fIZtLD4M=; b=kBXRT/E0kuQ2khXPaBfXxMxW8qFQThhyyNIBqLVgC6gi3sZeFyQiVUqs PUdYJktd9JRAo4m5kOgI04IXp89rWrg0pnox3db6FQ74IEpe0p5bEPtqM Tkp6gtWMLJVyR8agesCekjlN4dxNjG1SuZy9maYRKClbxsf70Y/5ZJbAA yyikTseOx3iZ6li0owJ5pcGkej0nNgYHicmmfTArfj0cM24URrdli1Vrj GdJHBvewhwOkWokL/XiJ/Q3GmMyk6KRzW14MTYbe8AIt2cljH9dnQ9lH/ qGxrjVaWgt3uy97SHYjpL/CiPgWus0MLzCSvTjFbxYchD8LX9BBtIyvOQ Q==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2017 23:33:49 +0100 X-IronPort-AV: E=Sophos;i="5.44,468,1505772000"; d="scan'208";a="72495944" Received: from he106142.emea1.cds.t-internal.com ([10.169.119.76]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 28 Nov 2017 23:33:49 +0100 Received: from HE105704.EMEA1.cds.t-internal.com (10.169.119.21) by HE106142.emea1.cds.t-internal.com (10.169.119.76) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 23:33:48 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105704.EMEA1.cds.t-internal.com (10.169.119.21) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 28 Nov 2017 23:33:48 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.21) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 23:33:12 +0100 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=WnFyvbyZitsFntpr+ERKVZJgmyemI0tVOW4fIZtLD4M=; b=EiECeyE7sxTM9GOxLlfMYWKtv8aEHRPU6rWp/J2IK+QWIGwtdpaRP/PXjbFwXf4D0v6qs28SjUCslJO3u8rtKMTSN5pwnIIP5G+2bymZ5eJR/YchqpkZ91BkircjKIqi/279I+dFrIzk87NmWs6dwaPudBmyq8h3iYQ9GA2fxGs= 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.260.4; Tue, 28 Nov 2017 22:33:47 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0260.007; Tue, 28 Nov 2017 22:33:47 +0000 From: To: , , CC: Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnUFtGaBJrWltk+s1shdGvlnWqL+S3eAgANM5ACAAAWhgIAABYIAgBhYyQCAAJRHAIAAiM8AgAEq5YCAAJcLgIABCfYAgAP9WACAAKuXAIAAtCwAgAI3xgCAAn+9gIAA9cMAgACm9ICAAMhXAIAAATqAgAAKeoCAAB8d4A== Date: Tue, 28 Nov 2017 22:33:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@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.39] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0481; 6:XJb9aPbbYwlKmU11QnKgdSX+bYxEFUUhFYIcX80FafLxD7I7xkNOQasFb4YQGJWVSfhBynzaRpdw28qM1bQY7vqb7U29Fkp+SFcNHNv6eDXYGUlyHanCdstJZkLRNiW0Y0uOycB+/CQ1T5tuMLpB/tQUk+Lo7slnvMJitx/tbOO+Zi18I6T0wWUqbf2ZPOK3WBmyS9V+HfZs3sv23ChDlWfGdSUEwENmioo6h8y3yqcgwF9KM8I+Eh7ZKO8sNdpEgVrKXhKk3hBT3MbrhF+FQOv0wS1al8iozvEBFOlgtjpxq7YhXZljQlSgKnPp7ZJVVB5y7+D+yuc4BPNGVPi8pE7LdQKtaYN07qDRRr+1b1A=; 5:3w899/wLcBiU9HGo8KHtbg9qb+kK5lZv89CkWCGOmjQbUK7Vl08n/Ozfvqs4kYQV0r6NjyQQD6/DjUxfi82pPuAzIpWaapWhAHTPlzfPkGPrtVa2bHmySyLop/1YAvGu4fp5c9XTIXJ63YgJix/SuaAZ5Ml6g0PTyFd56u69Y+4=; 24:QHBCeeR3rub6VWDA5++VF8xytao3ojp7ZHQj/+P92Umf43jkLuCYelGey1MswUVEmQfwUrzKyjaNYjgtMJWkaxedcnzcjKg61T/aLQVn6io=; 7:b/5pRs3T4tLtDmYVmFjyyPH01WHiyHZBaPx5OEQyI7RR3yYPmRhHPZ3izjsJy+l9Cl+Zp+lpNsOsft/tita+a6/wb70cuei0FVZSvzuDcxtfrRzxWTuMcbjHfQFgwDAIdLmkRZhCiT3yO5EtGhMZd/0xbamB/X4MaHEwRHyoYSKiQha6JYvyQ7uGLma133oqQlfjLs2YFU9vvPIpb8tvWyhX6M/OXe5p1ivXjCzZLlut96qnBkkTCab3EaaaPX25 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5c61771e-78c7-4557-36f0-08d536b01748 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:FRAPR01MB0481; x-ms-traffictypediagnostic: FRAPR01MB0481: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:FRAPR01MB0481; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:FRAPR01MB0481; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(366004)(376002)(199003)(189002)(51444003)(24454002)(106356001)(6116002)(102836003)(551934003)(55016002)(3846002)(105586002)(66066001)(97736004)(75402003)(2171002)(53936002)(9686003)(53546010)(52396003)(68736007)(7696005)(101416001)(2906002)(33656002)(93886005)(54356999)(76176999)(478600001)(189998001)(3280700002)(81156014)(86362001)(50986999)(3660700001)(2900100001)(7736002)(5660300001)(14454004)(74482002)(5250100002)(2950100002)(4326008)(8676002)(81166006)(110136005)(316002)(72206003)(8936002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0481; 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-Network-Message-Id: 5c61771e-78c7-4557-36f0-08d536b01748 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 22:33:47.4139 (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: Tue, 28 Nov 2017 22:34:57 -0000 SGkgUGF1bCwNCldlIGhhdmUgZGlmZmVyZW50IGlzc3VlcyB3aGVyZSB3ZSBoYXZlIGxvb2sgb24u DQpBbmQgd2Ugc2VlIHRoYXQgd2UgaGF2ZSBVUERBVEUgd2l0aCBhbiBTLVQgY2F1c2luZyBhIGxv dCBvZiB0cm91YmxlLg0KVGhpcyBpcyBkZXBlbmRlbnQgb24gZGlmZmVyZW50IHVzZSBjYXNlcy4N Ck9uZSBpcyB0aGF0IHRoZSBVQSBkb2VzIG5vdCBzdXBwb3J0IFVQREFURS4NClllcyB0aGF0IGlz IHRydWUuDQpCdXQgb25lIG9mIHRoZSBtYWluIHByb2JsZW1zIGFyZSB0aGUgcHJveGllcyBpbiBi ZXR3ZWVuLg0KRWl0aGVyIHByb3hpZXMgZG8gbm90IHJlYWN0IHdoaWNoIGlzIE9LLg0KQW5kIHRo ZSBVQUMgaW50ZXJwcmV0aW5nIHRoZSAyMDBPSy4NCkFsc28gdGhlIGRpcmVjdGlvbiBvZiB0aGUg VVBEQVRFIGlzIGltcG9ydGFudC4NCkFsc28gdGhlIGJlaGF2aW9yIG9mIHRoZSBwcm94eS4gV2Ug aGF2ZSBzZWVuIHByb3hpZXMgYWRkaW5nIFMtVCB0byB0aGUgVVBEQVRFIGR1ZSB0byB0aGUgZmFj dCB0aGF0IHNlc3Npb24gdGltZXIgc3VwcG9ydGVkIGlzIHNldC4gVGhlIFMtVCB2YWx1ZXMgd2hl cmUgZGlmZmVyZW50IHRvIHRoYXQgc2V0IGJ5IHRoZSBVQUMuDQoNClNvIGFzIHlvdSBzYWlkIHdl IGNhbiBpZGVudGlmeSBhbGwgdXNlIGNhc2VzLiBBbmQgSSB0aGluayB0aGF0IGlzIHdoYXQgd2Ug bmVlZCBvciByZWFsIGNsZWFyIHJ1bGVzIGZvciBVQUMvVUFTIGFuZCBQcm94eS4NCg0KQmVzdCBS ZWdhcmRzDQoNClJvbGFuZA0KDQoNCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0t LQ0KPiBWb246IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0NCj4g R2VzZW5kZXQ6IERpZW5zdGFnLCAyOC4gTm92ZW1iZXIgMjAxNyAyMTozMQ0KPiBBbjogQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IFJvbWFuIFNocG91 bnQNCj4gPHJvbWFuQHRlbHVyaXguY29tPg0KPiBDYzogSmVzc2tlLCBSb2xhbmQgPFIuSmVzc2tl QHRlbGVrb20uZGU+OyBzaXBjb3JlQGlldGYub3JnDQo+IEJldHJlZmY6IFJlOiBbc2lwY29yZV0g U2Vzc2lvbiB0aW1lciBmaXgNCj4gDQo+IE9uIDExLzI4LzE3IDI6NTMgUE0sIENocmlzdGVyIEhv bG1iZXJnIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4+PiAxLiBXaGF0IGhhcHBlbnMgd2hlbiBV QUMgcmVjZWl2ZXMgYSAyWFggSU5WSVRFIHJlc3BvbnNlIHdpdGggUy1UDQo+ID4+PiB0aGF0IGRp ZCBub3QgbWF0Y2ggdGhlIFMtVCB2YWx1ZSBuZWdvdGlhdGVkIGJ5IFVQREFURSB0cmFuc2FjdGlv bg0KPiBkdXJpbmcgdGhpcyBJTlZJVEUgdHJhbnNhY3Rpb24/DQo+ID4+DQo+ID4+IEVycm9yIGNh c2UuDQo+ID4+DQo+ID4+PiAyLiBXaGF0IGhhcHBlbnMgd2hlbiBVQUMgcmVjZWl2ZXMgYSAyWFgg VVBEQVRFIHJlc3BvbnNlIHdpdGggUy1UDQo+ID4+PiB0aGF0IGRpZCBub3QgbWF0Y2ggdGhlIDJY WCByZXNwb25zZSBmb3IgdGhlIHByZXZpb3VzIFVQREFURQ0KPiB0cmFuc2FjdGlvbj8NCj4gPj4N Cj4gPj4gRXJyb3IgY2FzZS4NCj4gPj4NCj4gPj4gSG93IGRvIHlvdSB3YW50IHRvIGhhbmRsZSB0 aGVzZSBlcnJvciBjYXNlcz8gVHdvIG9wdGlvbnMgdGhhdCBJIHNlZSBhcmU6DQo+ID4+IGEuIFRl cm1pbmF0ZSB0aGUgZGlhbG9nIChoYW5nIHVwKQ0KPiA+PiBiLiBJc3N1ZSBhIG5ldyBVUERBVEUg dG8gc2V0IHJlZnJlc2hlciB0byBhIGtub3duIHN0YXRlLg0KPiA+DQo+ID4gVGhvc2UgYXJlIHR3 byBhbHRlcm5hdGl2ZXMsIHllcy4gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIG1hbmRhdGUgYW55 DQo+IHNwZWNpZmljIGJlaGF2aW91ciwgYXMgbG9uZyBhcyB3ZSBtYWtlIGl0IGNsZWFyIHRoYXQg YW4gZXJyb3IgaGFzIG9jY3VycmVkIGFuZA0KPiBpdCBuZWVkcyB0byBiZSB0YWtlbiBjYXJlIG9m IFNPTUVIT1cuDQo+IA0KPiBPciB5b3UgY2FuIGp1c3QgaWdub3JlIHRoZSBlcnJvciBhbmQgaG9w ZSBmb3IgdGhlIGJlc3QuDQo+IA0KPiBNeSBpbnR1aXRpb24gdGVsbHMgbWUgdGhhdCB0aGlzIHdp bGwgcmFyZWx5IGNhdXNlIGEgcHJvYmxlbS4gTW9zdCBvZiB0aGUgdGltZSBhDQo+IGRldmljZSB0 aGF0IGRvZXNuJ3Qgc3VwcG9ydCB0aGUgdXBkYXRlIHdpbGwgYmUgY29tcGxpYW50IHdpdGggdGhl IHVwZGF0ZSBieQ0KPiBhY2NpZGVudC4gQW5kIGluIGEgYnVuY2ggb2YgdGhlIHJlbWFpbmluZyBj YXNlcyBpZ25vcmluZyBhIGNvbmZsaWN0aW5nIHZhbHVlIGluDQo+IHRoZSBuZXN0ZWQgVVBEQVRF IHdvbid0IG1hdHRlciBiZWNhdXNlIGJvdGggZW5kcyB3aWxsIHNldHRsZSBvbiB3aGF0IGlzIGlu DQo+IHRoZSAyMDAvSU5WSVRFLiBBbmQgdGhlIHJlbWFpbmluZyBjYXNlcyB3aWxsIHJlc3VsdCBp biBib3RoIGVuZHMgdGhpbmtpbmcNCj4gdGhleSBhcmUgVUFDIG9yIFVBUy4gSXQgaXNuJ3QgYSBw cm9ibGVtIGlmIHRoZXkgYm90aCB0aGluayB0aGV5IGFyZSB0aGUgVUFDLA0KPiBzaW5jZSB0aGVu IGJvdGggd2lsbCBhdHRlbXB0IHRvIHJlZnJlc2guIEl0IGlzIG9ubHkgYSBwcm9ibGVtIGlmIHRo ZXkgYm90aCB0aGluaw0KPiB0aGV5IGFyZSBVQVMsIHNpbmNlIHRoYXQgaXMgdGhlIG9ubHkgY2Fz ZSB3aGVuIHRoZSBzZXNzaW9uIHdvbid0IGJlDQo+IHJlZnJlc2hlZC4gSWYgdGhhdCBoYXBwZW5z LCBpcyBpdCB3b3JzZSB0aGFuIGhhdmluZyBoYWQgdGhlIGNhbGwgZmFpbD8NCj4gDQo+IElmIG5l ZWQgYmUgd2UgY2FuIHdvcmsgdGhyb3VnaCBhbGwgdGhlIGNhc2VzLiBCdXQgdGhlcmUgYXJlIHF1 aXRlIGEgbG90IG9mDQo+IHRoZW0uDQo+IA0KPiAJVGhhbmtzLA0KPiAJUGF1bA0K From nobody Tue Nov 28 15:06: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 EE6DC128B44 for ; Tue, 28 Nov 2017 15:06:45 -0800 (PST) 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=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 K1SUZ6UQN8oC for ; Tue, 28 Nov 2017 15:06:44 -0800 (PST) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::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 E61FE126DC2 for ; Tue, 28 Nov 2017 15:06:43 -0800 (PST) Received: by mail-pl0-x234.google.com with SMTP id x22so868139pln.11 for ; Tue, 28 Nov 2017 15:06:43 -0800 (PST) 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=LOtvLEHhqkKkMqPTOMHzGUExcWMa9IhWqx6jjbE3obk=; b=BdDNFslDpTIUkOlpVyg1BeIGJLhh6cAUho1tI+KmKUmjgLJwsQkjrvQastTNVqW/mI WHZqYIRaXegt9eszfVdqrJxJgtb4+knWAXhTv2dq0S/1y2ZAhQaxhC8b7JhujKneSb6z tQtrbaD3b+u+NorJ79kszY/hBxf7gVAYjLErB0ksjo5lybNn6hu0WLqRvNSylLfYLD62 fnM23+XGYy5L3PwF0z+8oDiETh5PkBntrshKWg4ru3X1wl/4nJ9LFE3u45YGLY6Xqemq q9yWpFOpWerLNrjl9ogPcGDy6IIt8DRbKl/OpDOX55PcD8QzoMwDoOBtqBMF4w6Gham8 97Jw== 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=LOtvLEHhqkKkMqPTOMHzGUExcWMa9IhWqx6jjbE3obk=; b=i2ID1I66uU3utmvvHnHHQOCjDpc8yF/aOw4/OcKQtoX4imv3oT1XufUsZcYYuUxn2+ XeggZYjVGpcJSFNMptvYjmMkUP06JvzPLnv6wt4SloGduS7dD2Y59v2OokzTy1OzcUtz HxbbeGDO9N+1Px1+PuEmn+UPvVT4qcx3cNAoB7sCdC8MZ7gkmiEBff6uJ0SUAjWNU8zg z3Yho/HKzlsh0kZ5JFpc5VACmz+569n/2yaU0j8VV52fzTs+lKztjX6x+LIbAyqYy4yM DhVmcXTHBhXjSOtryUIiFhdGmlhvr0lqQYhwDMdmPmSIsg5fNGM5LbmC/rBgH+coR0GR 8GRw== X-Gm-Message-State: AJaThX7VjylX/Nf4blwC5ixabQEc6xHmysRGltxqmsDxALRj0BGQfsfB CFP/WRWqOv1vi83U9ZWkiahlSRPX X-Google-Smtp-Source: AGs4zMbR6kQV2IjTLxNSujUy/Nz68fuQQtDymxfdh9Shbh4hReLYAsJDtGRGUaafc/lO4ksYKp3mEA== X-Received: by 10.159.197.65 with SMTP id d1mr822763plo.58.1511910403409; Tue, 28 Nov 2017 15:06:43 -0800 (PST) Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com. [209.85.192.175]) by smtp.gmail.com with ESMTPSA id l13sm248767pfj.73.2017.11.28.15.06.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 15:06:42 -0800 (PST) Received: by mail-pf0-f175.google.com with SMTP id p84so636023pfd.3 for ; Tue, 28 Nov 2017 15:06:42 -0800 (PST) X-Received: by 10.98.185.8 with SMTP id z8mr803898pfe.166.1511910401941; Tue, 28 Nov 2017 15:06:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 28 Nov 2017 15:06:41 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 28 Nov 2017 18:06:41 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "R.Jesske@telekom.de" Cc: Paul Kyzivat , Christer Holmberg , SIPCORE Content-Type: multipart/alternative; boundary="f403043a60b870ab74055f1312ed" 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, 28 Nov 2017 23:06:46 -0000 --f403043a60b870ab74055f1312ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Roland, Please provide the exact scenario. What you seem to be describing are misconfigured proxies or clients that do not follow existing specifications= . Regards, _____________ Roman Shpount On Tue, Nov 28, 2017 at 5:33 PM, wrote: > Hi Paul, > We have different issues where we have look on. > And we see that we have UPDATE with an S-T causing a lot of trouble. > This is dependent on different use cases. > One is that the UA does not support UPDATE. > Yes that is true. > But one of the main problems are the proxies in between. > Either proxies do not react which is OK. > And the UAC interpreting the 200OK. > Also the direction of the UPDATE is important. > Also the behavior of the proxy. We have seen proxies adding S-T to the > UPDATE due to the fact that session timer supported is set. The S-T value= s > where different to that set by the UAC. > > So as you said we can identify all use cases. And I think that is what we > need or real clear rules for UAC/UAS and Proxy. > > Best Regards > > Roland > > > > -----Urspr=C3=BCngliche Nachricht----- > > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Gesendet: Dienstag, 28. November 2017 21:31 > > An: Christer Holmberg ; Roman Shpount > > > > Cc: Jesske, Roland ; sipcore@ietf.org > > Betreff: Re: [sipcore] Session timer fix > > > > On 11/28/17 2:53 PM, Christer Holmberg wrote: > > > Hi, > > > > > >>> 1. What happens when UAC receives a 2XX INVITE response with S-T > > >>> that did not match the S-T value negotiated by UPDATE transaction > > during this INVITE transaction? > > >> > > >> Error case. > > >> > > >>> 2. What happens when UAC receives a 2XX UPDATE response with S-T > > >>> that did not match the 2XX response for the previous UPDATE > > transaction? > > >> > > >> Error case. > > >> > > >> How do you want to handle these error cases? Two options that I see > are: > > >> a. Terminate the dialog (hang up) > > >> b. Issue a new UPDATE to set refresher to a known state. > > > > > > Those are two alternatives, yes. I don't think we need to mandate any > > specific behaviour, as long as we make it clear that an error has > occurred and > > it needs to be taken care of SOMEHOW. > > > > Or you can just ignore the error and hope for the best. > > > > My intuition tells me that this will rarely cause a problem. Most of th= e > time a > > device that doesn't support the update will be compliant with the updat= e > by > > accident. And in a bunch of the remaining cases ignoring a conflicting > value in > > the nested UPDATE won't matter because both ends will settle on what is > in > > the 200/INVITE. And the remaining cases will result in both ends thinki= ng > > they are UAC or UAS. It isn't a problem if they both think they are the > UAC, > > since then both will attempt to refresh. It is only a problem if they > both think > > they are UAS, since that is the only case when the session won't be > > refreshed. If that happens, is it worse than having had the call fail? > > > > If need be we can work through all the cases. But there are quite a lot > of > > them. > > > > Thanks, > > Paul > --f403043a60b870ab74055f1312ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roland,

Please provide the exact scenar= io. What you seem to be describing are misconfigured proxies or clients tha= t do not follow existing specifications.

Regards,<= div class=3D"gmail_extra">
_____________
Roman Shpount

On Tue, Nov 28, 2017 at 5:33 PM, <R.Jes= ske@telekom.de> wrote:
Hi P= aul,
We have different issues where we have look on.
And we see that we have UPDATE with an S-T causing a lot of trouble.
This is dependent on different use cases.
One is that the UA does not support UPDATE.
Yes that is true.
But one of the main problems are the proxies in between.
Either proxies do not react which is OK.
And the UAC interpreting the 200OK.
Also the direction of the UPDATE is important.
Also the behavior of the proxy. We have seen proxies adding S-T to the UPDA= TE due to the fact that session timer supported is set. The S-T values wher= e different to that set by the UAC.

So as you said we can identify all use cases. And I think that is what we n= eed or real clear rules for UAC/UAS and Proxy.

Best Regards

Roland


> -----Urspr=C3=BCngliche Nachricht-----
> Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Gesendet: Dienstag, 28. November 2017 21:31
> An: Christer Holmberg <christer.holmberg@ericsson.com>; Roman Shpount
> <roman@teluri= x.com>
> Cc: Jesske, Roland <R.Jesske= @telekom.de>; sipcore@ietf.org
> Betreff: Re: [sipcore] Session timer fix
>
> On 11/28/17 2:53 PM, Christer Holmberg wrote:
> > Hi,
> >
> >>> 1. What happens when UAC receives a 2XX INVITE response w= ith S-T
> >>> that did not match the S-T value negotiated by UPDATE tra= nsaction
> during this INVITE transaction?
> >>
> >> Error case.
> >>
> >>> 2. What happens when UAC receives a 2XX UPDATE response w= ith S-T
> >>> that did not match the 2XX response for the previous UPDA= TE
> transaction?
> >>
> >> Error case.
> >>
> >> How do you want to handle these error cases? Two options that= I see are:
> >> a. Terminate the dialog (hang up)
> >> b. Issue a new UPDATE to set refresher to a known state.
> >
> > Those are two alternatives, yes. I don't think we need to man= date any
> specific behaviour, as long as we make it clear that an error has occu= rred and
> it needs to be taken care of SOMEHOW.
>
> Or you can just ignore the error and hope for the best.
>
> My intuition tells me that this will rarely cause a problem. Most of t= he time a
> device that doesn't support the update will be compliant with the = update by
> accident. And in a bunch of the remaining cases ignoring a conflicting= value in
> the nested UPDATE won't matter because both ends will settle on wh= at is in
> the 200/INVITE. And the remaining cases will result in both ends think= ing
> they are UAC or UAS. It isn't a problem if they both think they ar= e the UAC,
> since then both will attempt to refresh. It is only a problem if they = both think
> they are UAS, since that is the only case when the session won't b= e
> refreshed. If that happens, is it worse than having had the call fail?=
>
> If need be we can work through all the cases. But there are quite a lo= t of
> them.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul

--f403043a60b870ab74055f1312ed-- From nobody Tue Nov 28 16:46: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 9C548127B5A for ; Tue, 28 Nov 2017 16:46:26 -0800 (PST) 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=kXrlVVdC; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=09DGIJc3 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 6P1jJIfuqewD for ; Tue, 28 Nov 2017 16:46:24 -0800 (PST) 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 4FC9C120724 for ; Tue, 28 Nov 2017 16:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1511916383; x=1543452383; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R4FqXPTmcMo3iRbhDEHl7NDv7C49eVY3+lwVDh+YJrQ=; b=kXrlVVdCWdb13KS2I9OwiG8lIAWBGzXpMkDt9YwQfeO87HRtn3JoDcol kcpwT7aabSd3peyUeh9yA5wDER1UWQh/KXrT+mVPPNUjv3MlbhI74tef2 ODCDIzS8zUkz0RSWb/UeqH0YXPeMp5acU6wqOXXmrV16YS/DZSiedyD0O ay397U0ojWTZTrei3gG+c6c1Os7mc1RQr9mLk+nL9qxmZQgHEIdQNh+SA q4xy84bAqDqX+yjH8w3KAp2F4w4DbydqHMIQWJ4h5bAO2wS3N/xbaHo9s ZnJorwltkSn6LtE7zy6vtKyl7gfmE7dZbrl+ZN5pbfmgyzgpWa9QvuSES A==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 01:46:21 +0100 X-IronPort-AV: E=Sophos;i="5.44,470,1505772000"; d="scan'208,217";a="123591130" Received: from he105760.emea1.cds.t-internal.com ([10.169.118.56]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 29 Nov 2017 01:46:21 +0100 Received: from HE104854.EMEA1.cds.t-internal.com (10.169.118.17) by HE105760.emea1.cds.t-internal.com (10.169.118.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Nov 2017 01:46:21 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE104854.EMEA1.cds.t-internal.com (10.169.118.17) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 29 Nov 2017 01:46:20 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.17) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Nov 2017 01:46:14 +0100 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=R4FqXPTmcMo3iRbhDEHl7NDv7C49eVY3+lwVDh+YJrQ=; b=09DGIJc3ZRuWgkF0BiwM7JlQ2zI+n9E/BfJY0Zdswssd3b6kI23HxR6WcFB0EA4wsQUpWJlNTKiMvy9VLKTnYpW2m9yetv+xMwK52zPbjxyxck3q5U1PkQIc2BlnyNO+KPMpz9R0rmXSgAMWGzu5+lcRMycZh3aKKGRt+IACWPg= 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.260.4; Wed, 29 Nov 2017 00:46:19 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0260.007; Wed, 29 Nov 2017 00:46:20 +0000 From: To: CC: Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnUFtGaBJrWltk+s1shdGvlnWqL+S3eAgANM5ACAAAWhgIAABYIAgBhYyQCAAJRHAIAAiM8AgAEq5YCAAJcLgIABCfYAgAP9WACAAKuXAIAAtCwAgAI3xgCAAn+9gIAA9cMAgACm9ICAAMhXAIAAATqAgAAKeoCAAB8d4IAADHCAgAAVcKA= Date: Wed, 29 Nov 2017 00:46:19 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@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.39] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0484; 6:dA93mEfJkxqRDL9ue/febj2gWWXIHRE7x3lLz5TuyCdi0xIBx4CZWAEo/UBRRYTjO2Lbkyh4raoo9guG39xMg+OCi7YELhvp0BM/4TkT5QthFF8XdkO3TBqsc/OgjmyziIf/FJyK8AAWJ14JrYPng2HMrgEytmsJcqHmYWd/A4qCHsRwhXqgwinlMuMm4nyAIJ/cBnwZdjY5/WXRFXxjl3SlMA+yEMpBJg3mJa8QGNJX1KSBkzml4Z2OlvOy/4vsHNP5hgQiFR5njuWMBWxYVqGypxDR3uJhfAUqPs0tllWWB3o/jkrF296v/WmQ/mo3FVAowQHW0QdYk++yaZKH1dKdB3nwGukH8KPi/qSVMk8=; 5:smYjxGjJNgC/+G3G+LUf7wyDvnQB9GJA/287dRqhF5k/qTsMjw/E+vXuxeQZWsJnTvmwS+PiSCs0xO+bv1vZGt/JGydNXix4gMFW9qWqgszUJ+/vyCugUjAH/rGpZ2jkCI5lqbA504nA1ty6SNzFfefhNyQQoxVjKJKOnLRm3qA=; 24:Dy2/VWEyUSPFP3FQ0ONwiURPSivNqw0qIVWnCk2T7Xu2prQQmdZIK2JeGrOtpFk59//4Jzti1kvFjk4BYmBDg5JB/pM2sWZNM3u8V3YGMBs=; 7:9HPHx67fK5H1ThXjTH5hLnNVyi0xc+m2ILFahc7lAjd0gSNUAkeD6SnNezCF/6GO/oe6xWM9EuHeADPkWhf5Pc+AtjlAQRMcd3l6jEYmHKQFXJdOzu9KaGwOmSOM2nLS99za1+Y6FvCyXQQoq+X2APa7MV7PYpwKj3n/bICC53NOPLf1F6bMiTqmUFPehBFQNP+IUDmRxjusnpJW2mvx8YRkJwo503UcglBvKcBoS709MADY1TRzZGjOI/iM82kc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ac8e5f5e-e464-4ab2-e8ca-08d536c29b55 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:FRAPR01MB0484; x-ms-traffictypediagnostic: FRAPR01MB0484: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:FRAPR01MB0484; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:FRAPR01MB0484; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(199003)(24454002)(51444003)(189002)(551934003)(105586002)(101416001)(9686003)(106356001)(5250100002)(50986999)(790700001)(53936002)(102836003)(33656002)(3846002)(76176999)(54356999)(81156014)(81166006)(55016002)(6306002)(236005)(54896002)(189998001)(6116002)(5660300001)(75402003)(93886005)(2900100001)(8676002)(74482002)(66066001)(53546010)(8936002)(478600001)(7696005)(4326008)(14454004)(6916009)(97736004)(2950100002)(2906002)(68736007)(3280700002)(7736002)(52396003)(316002)(3660700001)(72206003)(86362001)(19627235001); 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: multipart/alternative; boundary="_000_FRAPR01MB04831C3F0FC1878EB3815130F93B0FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ac8e5f5e-e464-4ab2-e8ca-08d536c29b55 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 00:46:19.9197 (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: Wed, 29 Nov 2017 00:46:27 -0000 --_000_FRAPR01MB04831C3F0FC1878EB3815130F93B0FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCkludml0ZSB3aXRoIFMtRSAzNjAwIGlzIHNlbnQgYnkgdGhlIFVBQy4gUHJv eHkgbGV0IElOVklURSBwYXNzIHRvd2FyZHMgVUFTLg0KMXN0IG5lZ290aWF0aW9uIGlzIG9uZ29p bmcuDQoxOHgvUFJBQ0svMjAwT0soUFJBQ0spIGlzIGV4Y2hhbmdlZC4NCg0KTm93IFVBUyBpcyBz ZW5kaW5nIFVQREFURSB3aXRoIGEgc3VwcG9ydGVkIHRpbWVyIGFuZCBQcm94eSBhZGRzIFMtRSBk dWUgdG8gbG9jYWwgcG9saWN5IHdpdGggUy1FIDE4MDAuDQoNClNvIHdoYXQgd2lsbCB0aGUgVUFD IGRvLiBUaGUgcHJveHkgaGFzIGFkZGVkIHRoZSBTLUUuDQpVQUMgKFdoaWNoIGhhcyBzZW50IHRo ZSBJTlZJVEUpIGNvdWxkIGlnbm9yZSBhbmQgc2VuZCAyMDAgT0sgd2l0aG91dCBhbnkgUy1FLiBp LmUuIGlnbm9yaW5nIFVQREFURS4NCg0KSW4gdGhpcyBjYXNlLCB3aGF0IGlzIHRoZSB0aGVuIHBy b3h5IGRvaW5nPyBQYXNzaW5nIDIwME9LIHcvbyBTLUUgb3IgbWF5IGl0IGFkZCBhbiBTLUUgYWdh aW4/IEFzc3VtaW5nIGl0IGFkZHMgUy1FIDE4MDAgYmVjYXVzZSBpdCByZW1lbWJlcnMgdGhhdCB0 aGUgVVBEQVRFIHdhcyByZWNlaXZlZCB3aXRoIHN1cHBvcnRlZCB0aW1lci4NCg0KV2hhdCBkb2Vz IHRoZSBVQVMgZG8/IElnbm9yaW5nIHRoZSAyMDAgT0sgd2l0aCBTRSBvciBhY2NlcHRpbmc/DQoN CkFuZCB0aGVuIHdoYXQgd2lsbCB0aGUgVUFTIGRvPyBTZW5kaW5nIDIwMCBPSyAoSU5WSVRFKSB3 aXRoIFMtRSAzNjAwIGFzIHByb3Bvc2VkIGJ5IHRoZSBJTlZJVEUsIGJlY2F1c2UgdGhlIFVBUyBp cyBpZ25vcmluZyB0aGUgMjAwIE9LIChVUERBVEUpIHdpdGggUy1FIDE4MDA/DQoNCk9yIGRvIHlv dSB0aGluayB0aGF0IGhpcyBpcyBhIHdyb25nIGltcGxlbWVudGF0aW9uLg0KDQpCZXN0IFJlZ2Fy ZHMNCg0KUm9sYW5kDQoNCg0KDQpWb246IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNA aWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIFJvbWFuIFNocG91bnQNCkdlc2VuZGV0OiBNaXR0d29j aCwgMjkuIE5vdmVtYmVyIDIwMTcgMDA6MDcNCkFuOiBKZXNza2UsIFJvbGFuZCA8Ui5KZXNza2VA dGVsZWtvbS5kZT4NCkNjOiBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KQmV0cmVmZjogUmU6 IFtzaXBjb3JlXSBTZXNzaW9uIHRpbWVyIGZpeA0KDQpSb2xhbmQsDQoNClBsZWFzZSBwcm92aWRl IHRoZSBleGFjdCBzY2VuYXJpby4gV2hhdCB5b3Ugc2VlbSB0byBiZSBkZXNjcmliaW5nIGFyZSBt aXNjb25maWd1cmVkIHByb3hpZXMgb3IgY2xpZW50cyB0aGF0IGRvIG5vdCBmb2xsb3cgZXhpc3Rp bmcgc3BlY2lmaWNhdGlvbnMuDQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBv dW50DQoNCk9uIFR1ZSwgTm92IDI4LCAyMDE3IGF0IDU6MzMgUE0sIDxSLkplc3NrZUB0ZWxla29t LmRlPG1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPj4gd3JvdGU6DQpIaSBQYXVsLA0KV2UgaGF2 ZSBkaWZmZXJlbnQgaXNzdWVzIHdoZXJlIHdlIGhhdmUgbG9vayBvbi4NCkFuZCB3ZSBzZWUgdGhh dCB3ZSBoYXZlIFVQREFURSB3aXRoIGFuIFMtVCBjYXVzaW5nIGEgbG90IG9mIHRyb3VibGUuDQpU aGlzIGlzIGRlcGVuZGVudCBvbiBkaWZmZXJlbnQgdXNlIGNhc2VzLg0KT25lIGlzIHRoYXQgdGhl IFVBIGRvZXMgbm90IHN1cHBvcnQgVVBEQVRFLg0KWWVzIHRoYXQgaXMgdHJ1ZS4NCkJ1dCBvbmUg b2YgdGhlIG1haW4gcHJvYmxlbXMgYXJlIHRoZSBwcm94aWVzIGluIGJldHdlZW4uDQpFaXRoZXIg cHJveGllcyBkbyBub3QgcmVhY3Qgd2hpY2ggaXMgT0suDQpBbmQgdGhlIFVBQyBpbnRlcnByZXRp bmcgdGhlIDIwME9LLg0KQWxzbyB0aGUgZGlyZWN0aW9uIG9mIHRoZSBVUERBVEUgaXMgaW1wb3J0 YW50Lg0KQWxzbyB0aGUgYmVoYXZpb3Igb2YgdGhlIHByb3h5LiBXZSBoYXZlIHNlZW4gcHJveGll cyBhZGRpbmcgUy1UIHRvIHRoZSBVUERBVEUgZHVlIHRvIHRoZSBmYWN0IHRoYXQgc2Vzc2lvbiB0 aW1lciBzdXBwb3J0ZWQgaXMgc2V0LiBUaGUgUy1UIHZhbHVlcyB3aGVyZSBkaWZmZXJlbnQgdG8g dGhhdCBzZXQgYnkgdGhlIFVBQy4NCg0KU28gYXMgeW91IHNhaWQgd2UgY2FuIGlkZW50aWZ5IGFs bCB1c2UgY2FzZXMuIEFuZCBJIHRoaW5rIHRoYXQgaXMgd2hhdCB3ZSBuZWVkIG9yIHJlYWwgY2xl YXIgcnVsZXMgZm9yIFVBQy9VQVMgYW5kIFByb3h5Lg0KDQpCZXN0IFJlZ2FyZHMNCg0KUm9sYW5k DQoNCg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogUGF1bCBL eXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVt Lm1pdC5lZHU+XQ0KPiBHZXNlbmRldDogRGllbnN0YWcsIDI4LiBOb3ZlbWJlciAyMDE3IDIxOjMx DQo+IEFuOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgUm9tYW4gU2hwb3VudA0K PiA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCj4gQ2M6IEpl c3NrZSwgUm9sYW5kIDxSLkplc3NrZUB0ZWxla29tLmRlPG1haWx0bzpSLkplc3NrZUB0ZWxla29t LmRlPj47IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQo+IEJldHJl ZmY6IFJlOiBbc2lwY29yZV0gU2Vzc2lvbiB0aW1lciBmaXgNCj4NCj4gT24gMTEvMjgvMTcgMjo1 MyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPj4+IDEuIFdo YXQgaGFwcGVucyB3aGVuIFVBQyByZWNlaXZlcyBhIDJYWCBJTlZJVEUgcmVzcG9uc2Ugd2l0aCBT LVQNCj4gPj4+IHRoYXQgZGlkIG5vdCBtYXRjaCB0aGUgUy1UIHZhbHVlIG5lZ290aWF0ZWQgYnkg VVBEQVRFIHRyYW5zYWN0aW9uDQo+IGR1cmluZyB0aGlzIElOVklURSB0cmFuc2FjdGlvbj8NCj4g Pj4NCj4gPj4gRXJyb3IgY2FzZS4NCj4gPj4NCj4gPj4+IDIuIFdoYXQgaGFwcGVucyB3aGVuIFVB QyByZWNlaXZlcyBhIDJYWCBVUERBVEUgcmVzcG9uc2Ugd2l0aCBTLVQNCj4gPj4+IHRoYXQgZGlk IG5vdCBtYXRjaCB0aGUgMlhYIHJlc3BvbnNlIGZvciB0aGUgcHJldmlvdXMgVVBEQVRFDQo+IHRy YW5zYWN0aW9uPw0KPiA+Pg0KPiA+PiBFcnJvciBjYXNlLg0KPiA+Pg0KPiA+PiBIb3cgZG8geW91 IHdhbnQgdG8gaGFuZGxlIHRoZXNlIGVycm9yIGNhc2VzPyBUd28gb3B0aW9ucyB0aGF0IEkgc2Vl IGFyZToNCj4gPj4gYS4gVGVybWluYXRlIHRoZSBkaWFsb2cgKGhhbmcgdXApDQo+ID4+IGIuIElz c3VlIGEgbmV3IFVQREFURSB0byBzZXQgcmVmcmVzaGVyIHRvIGEga25vd24gc3RhdGUuDQo+ID4N Cj4gPiBUaG9zZSBhcmUgdHdvIGFsdGVybmF0aXZlcywgeWVzLiBJIGRvbid0IHRoaW5rIHdlIG5l ZWQgdG8gbWFuZGF0ZSBhbnkNCj4gc3BlY2lmaWMgYmVoYXZpb3VyLCBhcyBsb25nIGFzIHdlIG1h a2UgaXQgY2xlYXIgdGhhdCBhbiBlcnJvciBoYXMgb2NjdXJyZWQgYW5kDQo+IGl0IG5lZWRzIHRv IGJlIHRha2VuIGNhcmUgb2YgU09NRUhPVy4NCj4NCj4gT3IgeW91IGNhbiBqdXN0IGlnbm9yZSB0 aGUgZXJyb3IgYW5kIGhvcGUgZm9yIHRoZSBiZXN0Lg0KPg0KPiBNeSBpbnR1aXRpb24gdGVsbHMg bWUgdGhhdCB0aGlzIHdpbGwgcmFyZWx5IGNhdXNlIGEgcHJvYmxlbS4gTW9zdCBvZiB0aGUgdGlt ZSBhDQo+IGRldmljZSB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCB0aGUgdXBkYXRlIHdpbGwgYmUgY29t cGxpYW50IHdpdGggdGhlIHVwZGF0ZSBieQ0KPiBhY2NpZGVudC4gQW5kIGluIGEgYnVuY2ggb2Yg dGhlIHJlbWFpbmluZyBjYXNlcyBpZ25vcmluZyBhIGNvbmZsaWN0aW5nIHZhbHVlIGluDQo+IHRo ZSBuZXN0ZWQgVVBEQVRFIHdvbid0IG1hdHRlciBiZWNhdXNlIGJvdGggZW5kcyB3aWxsIHNldHRs ZSBvbiB3aGF0IGlzIGluDQo+IHRoZSAyMDAvSU5WSVRFLiBBbmQgdGhlIHJlbWFpbmluZyBjYXNl cyB3aWxsIHJlc3VsdCBpbiBib3RoIGVuZHMgdGhpbmtpbmcNCj4gdGhleSBhcmUgVUFDIG9yIFVB Uy4gSXQgaXNuJ3QgYSBwcm9ibGVtIGlmIHRoZXkgYm90aCB0aGluayB0aGV5IGFyZSB0aGUgVUFD LA0KPiBzaW5jZSB0aGVuIGJvdGggd2lsbCBhdHRlbXB0IHRvIHJlZnJlc2guIEl0IGlzIG9ubHkg YSBwcm9ibGVtIGlmIHRoZXkgYm90aCB0aGluaw0KPiB0aGV5IGFyZSBVQVMsIHNpbmNlIHRoYXQg aXMgdGhlIG9ubHkgY2FzZSB3aGVuIHRoZSBzZXNzaW9uIHdvbid0IGJlDQo+IHJlZnJlc2hlZC4g SWYgdGhhdCBoYXBwZW5zLCBpcyBpdCB3b3JzZSB0aGFuIGhhdmluZyBoYWQgdGhlIGNhbGwgZmFp bD8NCj4NCj4gSWYgbmVlZCBiZSB3ZSBjYW4gd29yayB0aHJvdWdoIGFsbCB0aGUgY2FzZXMuIEJ1 dCB0aGVyZSBhcmUgcXVpdGUgYSBsb3Qgb2YNCj4gdGhlbS4NCj4NCj4gICAgICAgVGhhbmtzLA0K PiAgICAgICBQYXVsDQoNCg== --_000_FRAPR01MB04831C3F0FC1878EB3815130F93B0FRAPR01MB0483DEUP_ 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 ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNt IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgUm9tYW4sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW52aXRlIHdpdGggUy1FIDM2MDAgaXMgc2VudCBi eSB0aGUgVUFDLiBQcm94eSBsZXQgSU5WSVRFIHBhc3MgdG93YXJkcyBVQVMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+MXN0IG5lZ290aWF0aW9uIGlzIG9uZ29pbmcu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+MTh4L1BSQUNLLzIwME9L KFBSQUNLKSBpcyBleGNoYW5nZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Tm93 IFVBUyBpcyBzZW5kaW5nIFVQREFURSB3aXRoIGEgc3VwcG9ydGVkIHRpbWVyIGFuZCBQcm94eSBh ZGRzIFMtRSBkdWUgdG8gbG9jYWwgcG9saWN5IHdpdGggUy1FIDE4MDAuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+U28gd2hhdCB3aWxsIHRoZSBVQUMgZG8uIFRoZSBwcm94eSBoYXMg YWRkZWQgdGhlIFMtRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5V QUMgKFdoaWNoIGhhcyBzZW50IHRoZSBJTlZJVEUpIGNvdWxkIGlnbm9yZSBhbmQgc2VuZCAyMDAg T0sgd2l0aG91dCBhbnkgUy1FLiBpLmUuIGlnbm9yaW5nIFVQREFURS4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkluIHRoaXMgY2FzZSwgd2hhdCBpcyB0aGUgdGhlbiBwcm94eSBk b2luZz8gUGFzc2luZyAyMDBPSyB3L28gUy1FIG9yIG1heSBpdCBhZGQgYW4gUy1FIGFnYWluPyBB c3N1bWluZyBpdCBhZGRzIFMtRSAxODAwIGJlY2F1c2UgaXQgcmVtZW1iZXJzIHRoYXQgdGhlIFVQ REFURSB3YXMgcmVjZWl2ZWQgd2l0aCBzdXBwb3J0ZWQNCiB0aW1lci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5XaGF0IGRvZXMgdGhlIFVBUyBkbz8gSWdub3JpbmcgdGhlIDIwMCBP SyB3aXRoIFNFIG9yIGFjY2VwdGluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5B bmQgdGhlbiB3aGF0IHdpbGwgdGhlIFVBUyBkbz8gU2VuZGluZyAyMDAgT0sgKElOVklURSkgd2l0 aCBTLUUgMzYwMCBhcyBwcm9wb3NlZCBieSB0aGUgSU5WSVRFLCBiZWNhdXNlIHRoZSBVQVMgaXMg aWdub3JpbmcgdGhlIDIwMCBPSyAoVVBEQVRFKSB3aXRoIFMtRSAxODAwPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPk9yIGRvIHlvdSB0aGluayB0aGF0IGhpcyBpcyBhIHdyb25nIGlt cGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJlc3QgUmVnYXJk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJvbGFuZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Vm9uOjwvYj4g c2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gPGI+SW0gQXVmdHJhZyB2 b24NCjwvYj5Sb21hbiBTaHBvdW50PGJyPg0KPGI+R2VzZW5kZXQ6PC9iPiBNaXR0d29jaCwgMjku IE5vdmVtYmVyIDIwMTcgMDA6MDc8YnI+DQo8Yj5Bbjo8L2I+IEplczxzcGFuIGxhbmc9IkVOLVVT Ij5zPC9zcGFuPmtlLCBSb2xhbmQgJmx0O1IuSmVzc2tlQHRlbGVrb20uZGUmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPkJldHJlZmY6 PC9iPiBSZTogW3NpcGNvcmVdIFNlc3Npb24gdGltZXIgZml4PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9sYW5kLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHByb3ZpZGUgdGhlIGV4YWN0IHNjZW5hcmlv LiBXaGF0IHlvdSBzZWVtIHRvIGJlIGRlc2NyaWJpbmcgYXJlIG1pc2NvbmZpZ3VyZWQgcHJveGll cyBvciBjbGllbnRzIHRoYXQgZG8gbm90IGZvbGxvdyBleGlzdGluZyBzcGVjaWZpY2F0aW9ucy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgNToz MyBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlIiB0YXJnZXQ9Il9i bGFuayI+Ui5KZXNza2VAdGVsZWtvbS5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFBhdWwsPGJyPg0KV2UgaGF2ZSBk aWZmZXJlbnQgaXNzdWVzIHdoZXJlIHdlIGhhdmUgbG9vayBvbi48YnI+DQpBbmQgd2Ugc2VlIHRo YXQgd2UgaGF2ZSBVUERBVEUgd2l0aCBhbiBTLVQgY2F1c2luZyBhIGxvdCBvZiB0cm91YmxlLjxi cj4NClRoaXMgaXMgZGVwZW5kZW50IG9uIGRpZmZlcmVudCB1c2UgY2FzZXMuPGJyPg0KT25lIGlz IHRoYXQgdGhlIFVBIGRvZXMgbm90IHN1cHBvcnQgVVBEQVRFLjxicj4NClllcyB0aGF0IGlzIHRy dWUuPGJyPg0KQnV0IG9uZSBvZiB0aGUgbWFpbiBwcm9ibGVtcyBhcmUgdGhlIHByb3hpZXMgaW4g YmV0d2Vlbi48YnI+DQpFaXRoZXIgcHJveGllcyBkbyBub3QgcmVhY3Qgd2hpY2ggaXMgT0suPGJy Pg0KQW5kIHRoZSBVQUMgaW50ZXJwcmV0aW5nIHRoZSAyMDBPSy48YnI+DQpBbHNvIHRoZSBkaXJl Y3Rpb24gb2YgdGhlIFVQREFURSBpcyBpbXBvcnRhbnQuPGJyPg0KQWxzbyB0aGUgYmVoYXZpb3Ig b2YgdGhlIHByb3h5LiBXZSBoYXZlIHNlZW4gcHJveGllcyBhZGRpbmcgUy1UIHRvIHRoZSBVUERB VEUgZHVlIHRvIHRoZSBmYWN0IHRoYXQgc2Vzc2lvbiB0aW1lciBzdXBwb3J0ZWQgaXMgc2V0LiBU aGUgUy1UIHZhbHVlcyB3aGVyZSBkaWZmZXJlbnQgdG8gdGhhdCBzZXQgYnkgdGhlIFVBQy48YnI+ DQo8YnI+DQpTbyBhcyB5b3Ugc2FpZCB3ZSBjYW4gaWRlbnRpZnkgYWxsIHVzZSBjYXNlcy4gQW5k IEkgdGhpbmsgdGhhdCBpcyB3aGF0IHdlIG5lZWQgb3IgcmVhbCBjbGVhciBydWxlcyBmb3IgVUFD L1VBUyBhbmQgUHJveHkuPGJyPg0KPGJyPg0KQmVzdCBSZWdhcmRzPGJyPg0KPGJyPg0KUm9sYW5k PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0t PGJyPg0KJmd0OyBWb246IFBhdWwgS3l6aXZhdCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpwa3l6 aXZhdEBhbHVtLm1pdC5lZHUiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT5dPGJyPg0KJmd0OyBH ZXNlbmRldDogRGllbnN0YWcsIDI4LiBOb3ZlbWJlciAyMDE3IDIxOjMxPGJyPg0KJmd0OyBBbjog Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7OyBSb21h biBTaHBvdW50PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29t Ij5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogSmVzc2tlLCBSb2xhbmQg Jmx0OzxhIGhyZWY9Im1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlIj5SLkplc3NrZUB0ZWxla29t LmRlPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7IEJldHJlZmY6IFJlOiBbc2lwY29yZV0gU2Vzc2lvbiB0aW1l ciBmaXg8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0Ozxicj4NCiZndDsgT24gMTEvMjgvMTcgMjo1MyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3Jv dGU6PGJyPg0KJmd0OyAmZ3Q7IEhpLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IDEuIFdoYXQgaGFwcGVucyB3aGVuIFVBQyByZWNlaXZlcyBhIDJYWCBJTlZJVEUgcmVzcG9u c2Ugd2l0aCBTLVQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGF0IGRpZCBub3QgbWF0Y2ggdGhl IFMtVCB2YWx1ZSBuZWdvdGlhdGVkIGJ5IFVQREFURSB0cmFuc2FjdGlvbjxicj4NCiZndDsgZHVy aW5nIHRoaXMgSU5WSVRFIHRyYW5zYWN0aW9uPzxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7IEVycm9yIGNhc2UuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IDIuIFdoYXQgaGFwcGVucyB3aGVuIFVBQyByZWNlaXZlcyBhIDJYWCBVUERBVEUgcmVz cG9uc2Ugd2l0aCBTLVQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGF0IGRpZCBub3QgbWF0Y2gg dGhlIDJYWCByZXNwb25zZSBmb3IgdGhlIHByZXZpb3VzIFVQREFURTxicj4NCiZndDsgdHJhbnNh Y3Rpb24/PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgRXJyb3IgY2FzZS48 YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBIb3cgZG8geW91IHdhbnQgdG8g aGFuZGxlIHRoZXNlIGVycm9yIGNhc2VzPyBUd28gb3B0aW9ucyB0aGF0IEkgc2VlIGFyZTo8YnI+ DQomZ3Q7ICZndDsmZ3Q7IGEuIFRlcm1pbmF0ZSB0aGUgZGlhbG9nIChoYW5nIHVwKTxicj4NCiZn dDsgJmd0OyZndDsgYi4gSXNzdWUgYSBuZXcgVVBEQVRFIHRvIHNldCByZWZyZXNoZXIgdG8gYSBr bm93biBzdGF0ZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhvc2UgYXJlIHR3byBh bHRlcm5hdGl2ZXMsIHllcy4gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIG1hbmRhdGUgYW55PGJy Pg0KJmd0OyBzcGVjaWZpYyBiZWhhdmlvdXIsIGFzIGxvbmcgYXMgd2UgbWFrZSBpdCBjbGVhciB0 aGF0IGFuIGVycm9yIGhhcyBvY2N1cnJlZCBhbmQ8YnI+DQomZ3Q7IGl0IG5lZWRzIHRvIGJlIHRh a2VuIGNhcmUgb2YgU09NRUhPVy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPciB5b3UgY2FuIGp1c3Qg aWdub3JlIHRoZSBlcnJvciBhbmQgaG9wZSBmb3IgdGhlIGJlc3QuPGJyPg0KJmd0Ozxicj4NCiZn dDsgTXkgaW50dWl0aW9uIHRlbGxzIG1lIHRoYXQgdGhpcyB3aWxsIHJhcmVseSBjYXVzZSBhIHBy b2JsZW0uIE1vc3Qgb2YgdGhlIHRpbWUgYTxicj4NCiZndDsgZGV2aWNlIHRoYXQgZG9lc24ndCBz dXBwb3J0IHRoZSB1cGRhdGUgd2lsbCBiZSBjb21wbGlhbnQgd2l0aCB0aGUgdXBkYXRlIGJ5PGJy Pg0KJmd0OyBhY2NpZGVudC4gQW5kIGluIGEgYnVuY2ggb2YgdGhlIHJlbWFpbmluZyBjYXNlcyBp Z25vcmluZyBhIGNvbmZsaWN0aW5nIHZhbHVlIGluPGJyPg0KJmd0OyB0aGUgbmVzdGVkIFVQREFU RSB3b24ndCBtYXR0ZXIgYmVjYXVzZSBib3RoIGVuZHMgd2lsbCBzZXR0bGUgb24gd2hhdCBpcyBp bjxicj4NCiZndDsgdGhlIDIwMC9JTlZJVEUuIEFuZCB0aGUgcmVtYWluaW5nIGNhc2VzIHdpbGwg cmVzdWx0IGluIGJvdGggZW5kcyB0aGlua2luZzxicj4NCiZndDsgdGhleSBhcmUgVUFDIG9yIFVB Uy4gSXQgaXNuJ3QgYSBwcm9ibGVtIGlmIHRoZXkgYm90aCB0aGluayB0aGV5IGFyZSB0aGUgVUFD LDxicj4NCiZndDsgc2luY2UgdGhlbiBib3RoIHdpbGwgYXR0ZW1wdCB0byByZWZyZXNoLiBJdCBp cyBvbmx5IGEgcHJvYmxlbSBpZiB0aGV5IGJvdGggdGhpbms8YnI+DQomZ3Q7IHRoZXkgYXJlIFVB Uywgc2luY2UgdGhhdCBpcyB0aGUgb25seSBjYXNlIHdoZW4gdGhlIHNlc3Npb24gd29uJ3QgYmU8 YnI+DQomZ3Q7IHJlZnJlc2hlZC4gSWYgdGhhdCBoYXBwZW5zLCBpcyBpdCB3b3JzZSB0aGFuIGhh dmluZyBoYWQgdGhlIGNhbGwgZmFpbD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiBuZWVkIGJlIHdl IGNhbiB3b3JrIHRocm91Z2ggYWxsIHRoZSBjYXNlcy4gQnV0IHRoZXJlIGFyZSBxdWl0ZSBhIGxv dCBvZjxicj4NCiZndDsgdGhlbS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1RoYW5rcyw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGF1 bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FRAPR01MB04831C3F0FC1878EB3815130F93B0FRAPR01MB0483DEUP_-- From nobody Tue Nov 28 17:04: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 89E311292F5 for ; Tue, 28 Nov 2017 17:04:31 -0800 (PST) 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 6WTRvVdRpE4n for ; Tue, 28 Nov 2017 17:04:29 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4D9126FB3 for ; Tue, 28 Nov 2017 17:04:29 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id j124so768315pfc.2 for ; Tue, 28 Nov 2017 17:04:29 -0800 (PST) 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=wNLdf4unOnoxDQEirhChsxUin1DyVZdgCQvioepAv/c=; b=Uk2LOWcJA33WCmlSL2nai6I2CO3vTYR5vW+91SdScNYF64tbb7MqtS42em2Mqe13I0 y1CdHe4F1J8iv7nmz3TKbMie4JJ98jw4/pmp17v9LtdChHNCUVQ3YdK7RYQ/dqj1ZXsc tzBIb1hFD+lGN4zIhCclo0rcg/1GEGJ5rc0jaG2h0nvmjDA+o1q5lXwSESiDyDGUAJBd rMV4kyNRV8eijXFHnEZ7bvGN28OT1LI0GgMbNkq08siTHgp1lmYH8mKHPb8PaF9ZSKNO wJpEJZC99wk5vOoRQV0sQnE0gfU6YxsMgZMIx/BGyCmOWIjW2OQMFaCiRZSNCRcC+Z64 EWzQ== 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=wNLdf4unOnoxDQEirhChsxUin1DyVZdgCQvioepAv/c=; b=KIFGXEt9yOYU7kpwuCMu2RCyoyGtuqQ7a4FpP+ehB4DrHm//ut+uQamOSZNFpyjdf+ YUzbsABRFw2Mcy7lTSLy5OPqMBuzsi/WRnZxbSgvKDYgoOrRk9/xgkSN/1hLE9zd+izM QfVyeCiQGQZlCgHBNcSTWvB/OtJVGHbwMF2fswueyyqEv6DjqpsTdeSiv1WIPi7+BFwh Mqj8QL5L63ASMGFRVNK3IJ59tDVO5YSFp2BWtztxWkLmgb8cf1XfXEnI4EbGm8GHx7Kl dRBlLShEgIv79N3tfR22D1v6xV2e8XeZBLa3AnzvgMvAGTEq3XvM0L6U/vBqyrbyJK5j NZBw== X-Gm-Message-State: AJaThX7SfgqaNtCprauwGkuWL2/z4t385tb4lblsxyhFs5EN6ESX4W45 j0QriWtlr7+MqgxllJdVdnc2NQic X-Google-Smtp-Source: AGs4zMZKs0N61wuA+TCMzdq114JvUBY05/5Bx3PkwgqhFIzfjUjll4vBgaEP3dBvTbc8nDg/YF5q2Q== X-Received: by 10.99.4.142 with SMTP id 136mr1055749pge.72.1511917468281; Tue, 28 Nov 2017 17:04:28 -0800 (PST) Received: from mail-pl0-f52.google.com (mail-pl0-f52.google.com. [209.85.160.52]) by smtp.gmail.com with ESMTPSA id b8sm427458pff.26.2017.11.28.17.04.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 17:04:27 -0800 (PST) Received: by mail-pl0-f52.google.com with SMTP id bi12so1036876plb.6 for ; Tue, 28 Nov 2017 17:04:27 -0800 (PST) X-Received: by 10.84.214.2 with SMTP id h2mr1152708pli.142.1511917467295; Tue, 28 Nov 2017 17:04:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 28 Nov 2017 17:04:26 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 28 Nov 2017 20:04:26 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "R.Jesske@telekom.de" Cc: SIPCORE Content-Type: multipart/alternative; boundary="f403045d264891657c055f14b7db" 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: Wed, 29 Nov 2017 01:04:31 -0000 --f403045d264891657c055f14b7db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Roland, This is not exactly wrong but this User Agent is asking for trouble and should be fixed. 1. UAC should not send INVITE with Session Expires header unless it was previously negotiated. User Agents do not need Session Expires, it was designed for proxies to deal with dialog expiration. User Agent can send re-INVITE or UPDATE at any time on its own to check the presence of the dialog. There is no need negotiate this. 2. If UAC does send Session Expires in the INVITE (sometimes is needed by B2BUA with limited state), it should add the same S-E header to UPDATE -- this will prevent proxy from adding S-E to UPDATE. *If you are going to fix one thing, fix this.* 3. Proxy should never modify S-E in the response. This is against the specifications. For User Agent which got two responses with different Session Timer values, it is safe to pick the smaller if it is a refresher or larger, if other UA is a refresher. If it got responses that have different refresher values, it is safe to assume that UA is the refresher. Also, after INVITE transaction completes, when in doubt, UA can send a new UPDATE without refresher value and S-E header to sort this thing out. Regards, _____________ Roman Shpount On Tue, Nov 28, 2017 at 7:46 PM, wrote: > Hi Roman, > > > > Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards UA= S. > > 1st negotiation is ongoing. > > 18x/PRACK/200OK(PRACK) is exchanged. > > > > Now UAS is sending UPDATE with a supported timer and Proxy adds S-E due t= o > local policy with S-E 1800. > > > > So what will the UAC do. The proxy has added the S-E. > > UAC (Which has sent the INVITE) could ignore and send 200 OK without any > S-E. i.e. ignoring UPDATE. > > > > In this case, what is the then proxy doing? Passing 200OK w/o S-E or may > it add an S-E again? Assuming it adds S-E 1800 because it remembers that > the UPDATE was received with supported timer. > > > > What does the UAS do? Ignoring the 200 OK with SE or accepting? > > > > And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 as > proposed by the INVITE, because the UAS is ignoring the 200 OK (UPDATE) > with S-E 1800? > > > > Or do you think that his is a wrong implementation. > > > > Best Regards > > > > Roland > > > > > > > > *Von:* sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von *Roman > Shpount > *Gesendet:* Mittwoch, 29. November 2017 00:07 > *An:* Jesske, Roland > *Cc:* SIPCORE > > *Betreff:* Re: [sipcore] Session timer fix > > > > Roland, > > > > Please provide the exact scenario. What you seem to be describing are > misconfigured proxies or clients that do not follow existing specificatio= ns. > > > > Regards, > > _____________ > Roman Shpount > > > > On Tue, Nov 28, 2017 at 5:33 PM, wrote: > > Hi Paul, > We have different issues where we have look on. > And we see that we have UPDATE with an S-T causing a lot of trouble. > This is dependent on different use cases. > One is that the UA does not support UPDATE. > Yes that is true. > But one of the main problems are the proxies in between. > Either proxies do not react which is OK. > And the UAC interpreting the 200OK. > Also the direction of the UPDATE is important. > Also the behavior of the proxy. We have seen proxies adding S-T to the > UPDATE due to the fact that session timer supported is set. The S-T value= s > where different to that set by the UAC. > > So as you said we can identify all use cases. And I think that is what we > need or real clear rules for UAC/UAS and Proxy. > > Best Regards > > Roland > > > > -----Urspr=C3=BCngliche Nachricht----- > > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Gesendet: Dienstag, 28. November 2017 21:31 > > An: Christer Holmberg ; Roman Shpount > > > > Cc: Jesske, Roland ; sipcore@ietf.org > > Betreff: Re: [sipcore] Session timer fix > > > > > On 11/28/17 2:53 PM, Christer Holmberg wrote: > > > Hi, > > > > > >>> 1. What happens when UAC receives a 2XX INVITE response with S-T > > >>> that did not match the S-T value negotiated by UPDATE transaction > > during this INVITE transaction? > > >> > > >> Error case. > > >> > > >>> 2. What happens when UAC receives a 2XX UPDATE response with S-T > > >>> that did not match the 2XX response for the previous UPDATE > > transaction? > > >> > > >> Error case. > > >> > > >> How do you want to handle these error cases? Two options that I see > are: > > >> a. Terminate the dialog (hang up) > > >> b. Issue a new UPDATE to set refresher to a known state. > > > > > > Those are two alternatives, yes. I don't think we need to mandate any > > specific behaviour, as long as we make it clear that an error has > occurred and > > it needs to be taken care of SOMEHOW. > > > > Or you can just ignore the error and hope for the best. > > > > My intuition tells me that this will rarely cause a problem. Most of th= e > time a > > device that doesn't support the update will be compliant with the updat= e > by > > accident. And in a bunch of the remaining cases ignoring a conflicting > value in > > the nested UPDATE won't matter because both ends will settle on what is > in > > the 200/INVITE. And the remaining cases will result in both ends thinki= ng > > they are UAC or UAS. It isn't a problem if they both think they are the > UAC, > > since then both will attempt to refresh. It is only a problem if they > both think > > they are UAS, since that is the only case when the session won't be > > refreshed. If that happens, is it worse than having had the call fail? > > > > If need be we can work through all the cases. But there are quite a lot > of > > them. > > > > Thanks, > > Paul > > > --f403045d264891657c055f14b7db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roland,

This is not exactly wrong but t= his User Agent is asking for trouble and should be fixed.

1. UAC should not send INVITE with Session Expires=C2=A0header unle= ss it was previously negotiated. User Agents do not need Session Expires, i= t was designed for proxies to deal with dialog expiration. User Agent can s= end re-INVITE or UPDATE at any time on its own to check the presence of the= dialog. There is no need negotiate this.

2. If UA= C does send Session Expires=C2=A0in the INVITE (sometimes is needed by B2BU= A with limited state), it should add the same S-E header to UPDATE -- this = will prevent proxy from adding S-E to UPDATE. *If you are going to fix one = thing, fix this.*

3. Proxy should never modify S-E= in the response. This is against the specifications.

<= div>For User Agent which got two responses with different Session Timer val= ues, it is safe to pick the smaller if it is a refresher or larger, if othe= r UA is a refresher. If it got responses that have different refresher valu= es, it is safe to assume that UA is the refresher. Also, after INVITE trans= action completes, when in doubt, UA can send a new UPDATE without refresher= value and S-E header to sort this thing out.

Rega= rds,

 --f403045d264891657c055f14b7db-- From nobody Tue Nov 28 17:25: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 11CD5127058 for ; Tue, 28 Nov 2017 17:25:48 -0800 (PST) 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 c10_Z9nUK1uH for ; Tue, 28 Nov 2017 17:25:46 -0800 (PST) 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 11320128CFF for ; Tue, 28 Nov 2017 17:25:45 -0800 (PST) X-AuditID: 1207440f-a5bff70000007960-23-5a1e0c97507a 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 D6.E4.31072.79C0E1A5; Tue, 28 Nov 2017 20:25:44 -0500 (EST) 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 vAT1PfWU026971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Nov 2017 20:25:42 -0500 To: R.Jesske@telekom.de, christer.holmberg@ericsson.com, roman@telurix.com Cc: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Tue, 28 Nov 2017 20:25:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.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+NgFprLKsWRmVeSWpSXmKPExsUixO6iqDuDRy7K4NVWFYsLMw8zWjTd6WKz mHFhKrPF1x+b2BxYPH59vcrmsWTJTyaPtpcKHremFASwRHHZpKTmZJalFunbJXBl3H94h6ng lFRF5/lFjA2MH0W6GDk5JARMJG6uW8rexcjFISSwg0liwdd5LBDOQyaJp7NmsoNUCQvoSOz8 epwFxBYR8JLYcP8aaxcjBwezgIjEuY+GEPX32SXW/rwFVs8moCUx59B/sHpeAXuJzv7FbCA2 i4CqRNOV08wgtqhAmsSeCx1QNYISJ2c+AbM5BWIkLvx7xgpiMwuYSczb/JAZwhaXuPVkPhOE LS/RvHU28wRGgVlI2mchaZmFpGUWkpYFjCyrGOUSc0pzdXMTM3OKU5N1i5MT8/JSi3RN9HIz S/RSU0o3MULCnH8HY9d6mUOMAhyMSjy8F1bIRgmxJpYVV+YeYpTkYFIS5f20ECjEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhLdyElCONyWxsiq1KB8mJc3BoiTOq75E3U9IID2xJDU7NbUgtQgm K8PBoSTBywWMZyHBotT01Iq0zJwShDQTByfIcB6g4W3cQDW8xQWJucWZ6RD5U4zGHD09N/4w cTyb+bqBWYglLz8vVUqctwGkVACkNKM0D24aLFW9YhQHek6YNxSkigeY5uDmvQJaxQS06uZ+ aZBVJYkIKakGRpF+3pXvPR3dO7n3iDYsk+66oRtlPZeFKdXupdVaRx5Bq0n6tl8fH5v53XKi Q1hUynNnfxtui64Fltzec4yjoucHrCmdd2a/2vLOEsHU0PLCc0266vNTk49GGL7/ZNG2Jtzr +XdfvYt+6RYTDc6smMTFHafNLSHaKL3ec/XDCT2ybbvjvy5XYinOSDTUYi4qTgQAy0/gwjAD AAA= 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: Wed, 29 Nov 2017 01:25:48 -0000 Roland, I will reply to your later messages in this thread, but also have a comment here. On 11/28/17 5:33 PM, R.Jesske@telekom.de wrote: > Hi Paul, > We have different issues where we have look on. > And we see that we have UPDATE with an S-T causing a lot of trouble. > This is dependent on different use cases. > One is that the UA does not support UPDATE. If UPDATE isn't supported by one of the UAs then it won't be sent, and none of the issues we have been discussing come into play. > Yes that is true. > But one of the main problems are the proxies in between. > Either proxies do not react which is OK. > And the UAC interpreting the 200OK. > Also the direction of the UPDATE is important. Why? It has subtle distinctions, but IIUC the issues we have been concerned with are the same. > Also the behavior of the proxy. We have seen proxies adding S-T to the UPDATE due to the fact that session timer supported is set. The S-T values where different to that set by the UAC. If the proxy inserts the same S-E in the UPDATE and INVITE then I don't see a problem. Thanks, Paul > So as you said we can identify all use cases. And I think that is what we need or real clear rules for UAC/UAS and Proxy. > > Best Regards > > Roland > > >> -----Ursprüngliche Nachricht----- >> Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Gesendet: Dienstag, 28. November 2017 21:31 >> An: Christer Holmberg ; Roman Shpount >> >> Cc: Jesske, Roland ; sipcore@ietf.org >> Betreff: Re: [sipcore] Session timer fix >> >> On 11/28/17 2:53 PM, Christer Holmberg wrote: >>> Hi, >>> >>>>> 1. What happens when UAC receives a 2XX INVITE response with S-T >>>>> that did not match the S-T value negotiated by UPDATE transaction >> during this INVITE transaction? >>>> >>>> Error case. >>>> >>>>> 2. What happens when UAC receives a 2XX UPDATE response with S-T >>>>> that did not match the 2XX response for the previous UPDATE >> transaction? >>>> >>>> Error case. >>>> >>>> How do you want to handle these error cases? Two options that I see are: >>>> a. Terminate the dialog (hang up) >>>> b. Issue a new UPDATE to set refresher to a known state. >>> >>> Those are two alternatives, yes. I don't think we need to mandate any >> specific behaviour, as long as we make it clear that an error has occurred and >> it needs to be taken care of SOMEHOW. >> >> Or you can just ignore the error and hope for the best. >> >> My intuition tells me that this will rarely cause a problem. Most of the time a >> device that doesn't support the update will be compliant with the update by >> accident. And in a bunch of the remaining cases ignoring a conflicting value in >> the nested UPDATE won't matter because both ends will settle on what is in >> the 200/INVITE. And the remaining cases will result in both ends thinking >> they are UAC or UAS. It isn't a problem if they both think they are the UAC, >> since then both will attempt to refresh. It is only a problem if they both think >> they are UAS, since that is the only case when the session won't be >> refreshed. If that happens, is it worse than having had the call fail? >> >> If need be we can work through all the cases. But there are quite a lot of >> them. >> >> Thanks, >> Paul From nobody Tue Nov 28 17:27:38 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 11C0E129329 for ; Tue, 28 Nov 2017 17:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=iGc0qwKk; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=NH3+J/Jz 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 nLPNkeZkd_24 for ; Tue, 28 Nov 2017 17:27:34 -0800 (PST) Received: from mailout33.telekom.de (MAILOUT33.telekom.de [194.25.225.145]) (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 DC499128CFF for ; Tue, 28 Nov 2017 17:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1511918854; x=1543454854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MSHXhk1bff3anOE1yhz7bTu1FTcSSUmJCNeC2kaDPsc=; b=iGc0qwKkzbchIotTnrOus3sQKfjSlyubFp+EZNxDr/22T+TwEaxG8QtD 9lPKkDHku+Vb88p5J3W4OqCQOrFNPCKpdd6/XxGVfwznSEXV6Nuu5IK9w VK9CSfzvLKRpZ7+iS4WlJau0GfznK19i+InbTSBkmCxwyHgl39l35tZo0 2aN0qyvd3bNMq/sTEIKgqgCgaZVdEwRXxLA9VuXf9Eug1dY5qW8TsmfAl QKvUAXpCPS6TjPBQjBMINq3So56FAVW5FOSTyyopfLbI/7zprMg5XT5oD BIIZ+TEBYQx8kk5WfX77153gWA1qBmJBq2CCvvNLhCZ6LMnkCVViRVGq3 A==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 02:27:31 +0100 X-IronPort-AV: E=Sophos;i="5.44,470,1505772000"; d="scan'208";a="123599947" Received: from he105707.emea1.cds.t-internal.com ([10.169.119.38]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 29 Nov 2017 02:27:31 +0100 Received: from HE105867.EMEA1.cds.t-internal.com (10.169.119.44) by HE105707.emea1.cds.t-internal.com (10.169.119.38) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Nov 2017 02:27:31 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105867.EMEA1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 29 Nov 2017 02:27:31 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.21) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Nov 2017 02:26:49 +0100 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=MSHXhk1bff3anOE1yhz7bTu1FTcSSUmJCNeC2kaDPsc=; b=NH3+J/Jz73wen/AryM6HggSiH/GoUpbw6XO0XqQxKCxjLfzcmZBFL+Az6zCOznVRgxf3/7lt6vfXtcMq2Ky5B6HjK+QC95baHUsvPnqWfqWGSJqYou4TFwoa6hqGA2MkebFboQo5zBu2Ui8+rzGtW8VqzgrzQMy5gSXqNB7g23o= 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.260.4; Wed, 29 Nov 2017 01:27:24 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0260.007; Wed, 29 Nov 2017 01:27:24 +0000 From: To: CC: Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnUFtGaBJrWltk+s1shdGvlnWqL+S3eAgANM5ACAAAWhgIAABYIAgBhYyQCAAJRHAIAAiM8AgAEq5YCAAJcLgIABCfYAgAP9WACAAKuXAIAAtCwAgAI3xgCAAn+9gIAA9cMAgACm9ICAAMhXAIAAATqAgAAKeoCAAB8d4IAADHCAgAAVcKCAAAt2AIAAAoYw Date: Wed, 29 Nov 2017 01:27:24 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@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.39] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0481; 6:UOMKnSzs8zIhC93J0rezDpvSyvab8ETZkj4U2n0W1uhKi/bRgMZyZmIwrVr14KjwS9+h2/wToXH7AWpec+F/Wc2Kmn5eXDkq5XCUYjUHkN0wgTnlyV/1I4YsA7oWLTXM89l3+5boTzKlOUnab4xzYXDCBgaxdazimyA5IvKe5qhn7KtwTnW8l4CVgTGx3cwfV1z+apKAgW0tDV4xTysuu5Ipo+I+JIcHvSNIUKGIi6fyQrka6efkIDnJ0/AsxPFoLo6UGktTkgDbfY5XKMaOh4HutnY7XB1bxhtEdHNKZ6txTzEvcVkrjL/jNI7iW11wUqGlRxkYKJH0NHcJWtYCTVwbgnqzHfd7mH6Df5cUNHU=; 5:vtb12YmWRZ74b2DbruPVEE7GkG8OkA5BLYvQzX5aQJbBQbup3NpDi4/7sOHQFklXC2ClXK7VTc+To7Q4qAskvB4WZFMYwcmnh+R0lhpqqnS5qNJ8Tob1gwVC6o471M3G3nuIraPEz6auh1dFH3o6G1blrUQLomQPg2t2tefOPa4=; 24:DKUgObW4N4Ik5OV/nWDgIiZ27LXZlr3yj6YJsCYtAduTRxBtQ8FvRxrJWCk+r84FPkzs5uEjI+xI60DEM5Cccb3374VMv9TUlqgrOhuRbRc=; 7:IUWGTNs6QgqRPjSB6Vfon8+1KznOrvhLCOjthcF3JIae8Xbseq0pGdvQye+RHCwd4TEYrlkJh25CGZHXesBRM7KU9rXC4ckO9fJO8zDMLVWvNR7ldPFGucfn3qYd9D/yeGxfqvf2qkXKopgJB7M3D5UPPDOvZsbuy9/DkFMDKOc3HI+X9/ToUnpmPx8O4zC21tSJLAVgMfXy4bRnFMK3iBZ39+VOojJVGTcg+qypG9n/ZD/HDnLYGQIil8U5mlga x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 08dd2108-3a6b-4990-028c-08d536c8583d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:FRAPR01MB0481; x-ms-traffictypediagnostic: FRAPR01MB0481: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:FRAPR01MB0481; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:FRAPR01MB0481; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(366004)(346002)(51444003)(24454002)(189002)(199003)(50986999)(86362001)(81156014)(189998001)(7736002)(3660700001)(2900100001)(478600001)(93886005)(76176999)(54356999)(3280700002)(4326008)(72206003)(316002)(8676002)(81166006)(8936002)(305945005)(5660300001)(14454004)(74482002)(6916009)(5250100002)(2950100002)(105586002)(3846002)(75402003)(66066001)(97736004)(6116002)(106356001)(102836003)(55016002)(551934003)(52396003)(68736007)(2906002)(33656002)(7696005)(101416001)(53936002)(9686003)(53546010); 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 08dd2108-3a6b-4990-028c-08d536c8583d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 01:27:24.3764 (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: Wed, 29 Nov 2017 01:27:37 -0000 SGkgUm9tYW4sDQpZZXMgdGhhdCBpcyB3aGF0IEkgd291bGQgbGlrZSB0byBzZWUgYnV0IHJlYWxp dHkgaXMgc29tZXRoaW5nIG90aGVyLg0KDQpTbyB0aGUgVUFDL1VBUyBjb3VsZCBiZSBzb21lIGJv cmRlciBlbGVtZW50IHdpdGhpbiB5b3VyIG5ldHdvcmsuIEluIG91cnMgdGhlIFMtRSB3aWxsIGJl IG5lZ290aWF0ZWQgYnkgdGhlIGZpcnN0IHByb3h5IHdpdGhpbiB0aGUgbmV0d29yay4NCldlIGhh dmUgaW50ZXJjb25uZWN0aW9uIHNpdHVhdGlvbnMgd2hlcmUgd2UgaGF2ZSBubyBpbmZsdWVuY2Ug b24gb3RoZXIgcHJveGllcy4NCg0KVGhhdCB3aGF0IEkgaGF2ZSBkZXNjcmliZWQgaXMgY29uZm9y bWFudCB3aXRoIFJGQzQwMjguDQoNClNlZSBiZWxvdw0KDQo+Vm9uOiBSb21hbiBTaHBvdW50IFtt YWlsdG86cm9tYW5AdGVsdXJpeC5jb21dIA0KPkdlc2VuZGV0OiBNaXR0d29jaCwgMjkuIE5vdmVt YmVyIDIwMTcgMDI6MDQNCj5BbjogSmVzc2tlLCBSb2xhbmQgPFIuSmVzc2tlQHRlbGVrb20uZGU+ DQo+Q2M6IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQo+QmV0cmVmZjogUmU6IFtzaXBjb3Jl XSBTZXNzaW9uIHRpbWVyIGZpeA0KPg0KPlJvbGFuZCwgDQo+DQo+VGhpcyBpcyBub3QgZXhhY3Rs eSB3cm9uZyBidXQgdGhpcyBVc2VyIEFnZW50IGlzIGFza2luZyBmb3IgdHJvdWJsZSBhbmQgc2hv dWxkIGJlIGZpeGVkLg0KID4NCg0KPjEuIFVBQyBzaG91bGQgbm90IHNlbmQgSU5WSVRFIHdpdGgg U2Vzc2lvbiBFeHBpcmVzwqBoZWFkZXIgdW5sZXNzIGl0IHdhcyBwcmV2aW91c2x5IG5lZ290aWF0 ZWQuIA0KPlVzZXIgQWdlbnRzIGRvIG5vdCBuZWVkIFNlc3Npb24gRXhwaXJlcywgaXQgd2FzIGRl c2lnbmVkIGZvciANCj5wcm94aWVzIHRvIGRlYWwgd2l0aCBkaWFsb2cgZXhwaXJhdGlvbi4gVXNl ciBBZ2VudCBjYW4gc2VuZCByZS1JTlZJVEUgb3IgVVBEQVRFIA0KPmF0IGFueSB0aW1lIG9uIGl0 cyBvd24gdG8gY2hlY2sgdGhlIHByZXNlbmNlIG9mIHRoZSBkaWFsb2cuIFRoZXJlIGlzIG5vIG5l ZWQgDQo+bmVnb3RpYXRlIHRoaXMuDQoNCltSSl0gU2VjdGlvbiA3LjEgLi4uIEEgVUFDIE1BWSBp bmNsdWRlIHRoZSBNaW4tU0UgaGVhZGVyIGZpZWxkIGluIHRoZSBpbml0aWFsIElOVklURQ0KICAg cmVxdWVzdC4uLi4NCg0KPjIuIElmIFVBQyBkb2VzIHNlbmQgU2Vzc2lvbiBFeHBpcmVzwqBpbiB0 aGUgSU5WSVRFIChzb21ldGltZXMgaXMgbmVlZGVkIGJ5IEIyQlVBIHdpdGggbGltaXRlZCBzdGF0 ZSksDQo+IGl0IHNob3VsZCBhZGQgdGhlIHNhbWUgUy1FIGhlYWRlciB0byBVUERBVEUgLS0gdGhp cyB3aWxsIA0KPnByZXZlbnQgcHJveHkgZnJvbSBhZGRpbmcgUy1FIHRvIFVQREFURS4gKklmIHlv dSBhcmUgZ29pbmcgdG8gZml4IG9uZSB0aGluZywgZml4IHRoaXMuKg0KDQpbUkpdIEluIHRoaXMg Y2FzZSB0aGUgVVBEQVRFIGlzIHNlbnQgYnkgdGhlIFVBUyB3aXRoIGEgc3VwcG9ydGVkICJ0aW1l ciIgc28gdGhlIHByb3h5IGhhcyBhZGRlZCB0aGUgUy1FLg0KWWVzIEkgYWdyZWUgdGhhdCB0aGUg VVBEQVRFIHNlbnQgc2hvdWxkIGhhdmUgdGhlbiB0aGUgUy1FIGJ1dCB0aGlzIG5lZWRzIHRvIGJl IGNsYXJpZmllZC4NCg0KPjMuIFByb3h5IHNob3VsZCBuZXZlciBtb2RpZnkgUy1FIGluIHRoZSBy ZXNwb25zZS4gVGhpcyBpcyBhZ2FpbnN0IHRoZSBzcGVjaWZpY2F0aW9ucy4NCg0KW1JKXSBUaGVy ZSBpcyBubyBtb2RpZmljYXRpb24gd2l0aGluIHRoZSAyMDAgT0sgc2luY2UgdGhpcyB1c2UgY2Fz ZSBhc3N1bWVzIHRoYXQgdGhlIFVBIGRvZXMgbm90IGFkZCBhbnkgUy1FIGJlY2F1c2Ugb2YgaWdu b3JpbmcgdGhlIFVQREFURS4NCkJ1dCB0aGUgUHJveHkgaXMgZm9sbG93aW5nIHRoaXMgcnVsZSBv dXQgb2YgUkZDNDAyOCA4LjE6DQoNCiAgLi4uQmVjYXVzZSB0aGVyZSBpcyBubyBTZXNzaW9uLUV4 cGlyZXMgb3IgUmVxdWlyZSBoZWFkZXIgZmllbGQgaW4gdGhlDQogICByZXNwb25zZSwgdGhlIHBy b3h5IGtub3dzIHRoYXQgaXQgaXMgdGhlIGZpcnN0IHNlc3Npb24tdGltZXItYXdhcmUNCiAgIHBy b3h5IHRvIHJlY2VpdmUgdGhlIHJlc3BvbnNlLiAgVGhpcyBwcm94eSBNVVNUIGluc2VydCBhDQog ICBTZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxkIGludG8gdGhlIHJlc3BvbnNlIHdpdGggdGhl IHZhbHVlIGl0DQogICByZW1lbWJlcmVkIGZyb20gdGhlIGZvcndhcmRlZCByZXF1ZXN0Li4uLg0K DQpTbyB0aGUgUHJveHkgcmVtZW1iZXJzIHRoZSB2YWx1ZSBpdCBoYXMgcHV0IGJ5IGl0c2VsZiBp bnRvIHRoZSBVUERBVEUuDQoNCg0KPkZvciBVc2VyIEFnZW50IHdoaWNoIGdvdCB0d28gcmVzcG9u c2VzIHdpdGggZGlmZmVyZW50IFNlc3Npb24gVGltZXIgdmFsdWVzDQo+LGl0IGlzIHNhZmUgdG8g cGljayB0aGUgc21hbGxlciBpZiBpdCBpcyBhIHJlZnJlc2hlciBvciBsYXJnZXIsIGlmIG90aGVy IFVBIGlzIGEgcmVmcmVzaGVyLg0KPiBJZiBpdCBnb3QgcmVzcG9uc2VzIHRoYXQgaGF2ZSBkaWZm ZXJlbnQgcmVmcmVzaGVyIHZhbHVlcywgaXQgaXMgc2FmZSB0byBhc3N1bWUgdGhhdCBVQSBpcyB0 aGUgcmVmcmVzaGVyLg0KPiBBbHNvLCBhZnRlciBJTlZJVEUgdHJhbnNhY3Rpb24gY29tcGxldGVz LCB3aGVuIGluIGRvdWJ0LCBVQSANCj5jYW4gc2VuZCBhIG5ldyBVUERBVEUgd2l0aG91dCByZWZy ZXNoZXIgdmFsdWUgYW5kIFMtRSBoZWFkZXIgdG8gc29ydCB0aGlzIHRoaW5nIG91dC4NCg0KUmVn YXJkcywNCg0KDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVHVlLCBOb3Yg MjgsIDIwMTcgYXQgNzo0NiBQTSwgPG1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPiB3cm90ZToN CkhpIFJvbWFuLA0KwqANCkludml0ZSB3aXRoIFMtRSAzNjAwIGlzIHNlbnQgYnkgdGhlIFVBQy4g UHJveHkgbGV0IElOVklURSBwYXNzIHRvd2FyZHMgVUFTLg0KMXN0IG5lZ290aWF0aW9uIGlzIG9u Z29pbmcuDQoxOHgvUFJBQ0svMjAwT0soUFJBQ0spIGlzIGV4Y2hhbmdlZC4NCsKgDQpOb3cgVUFT IGlzIHNlbmRpbmcgVVBEQVRFIHdpdGggYSBzdXBwb3J0ZWQgdGltZXIgYW5kIFByb3h5IGFkZHMg Uy1FIGR1ZSB0byBsb2NhbCBwb2xpY3kgd2l0aCBTLUUgMTgwMC4NCsKgDQpTbyB3aGF0IHdpbGwg dGhlIFVBQyBkby4gVGhlIHByb3h5IGhhcyBhZGRlZCB0aGUgUy1FLg0KVUFDIChXaGljaCBoYXMg c2VudCB0aGUgSU5WSVRFKSBjb3VsZCBpZ25vcmUgYW5kIHNlbmQgMjAwIE9LIHdpdGhvdXQgYW55 IFMtRS4gaS5lLiBpZ25vcmluZyBVUERBVEUuIA0KwqANCkluIHRoaXMgY2FzZSwgd2hhdCBpcyB0 aGUgdGhlbiBwcm94eSBkb2luZz8gUGFzc2luZyAyMDBPSyB3L28gUy1FIG9yIG1heSBpdCBhZGQg YW4gUy1FIGFnYWluPyBBc3N1bWluZyBpdCBhZGRzIFMtRSAxODAwIGJlY2F1c2UgaXQgcmVtZW1i ZXJzIHRoYXQgdGhlIFVQREFURSB3YXMgcmVjZWl2ZWQgd2l0aCBzdXBwb3J0ZWQgdGltZXIuDQrC oA0KV2hhdCBkb2VzIHRoZSBVQVMgZG8/IElnbm9yaW5nIHRoZSAyMDAgT0sgd2l0aCBTRSBvciBh Y2NlcHRpbmc/DQrCoA0KQW5kIHRoZW4gd2hhdCB3aWxsIHRoZSBVQVMgZG8/IFNlbmRpbmcgMjAw IE9LIChJTlZJVEUpIHdpdGggUy1FIDM2MDAgYXMgcHJvcG9zZWQgYnkgdGhlIElOVklURSwgYmVj YXVzZSB0aGUgVUFTIGlzIGlnbm9yaW5nIHRoZSAyMDAgT0sgKFVQREFURSkgd2l0aCBTLUUgMTgw MD8NCsKgDQpPciBkbyB5b3UgdGhpbmsgdGhhdCBoaXMgaXMgYSB3cm9uZyBpbXBsZW1lbnRhdGlv bi4NCsKgDQpCZXN0IFJlZ2FyZHMNCsKgDQpSb2xhbmQNCsKgDQrCoA0KwqANClZvbjogc2lwY29y ZSBbbWFpbHRvOm1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9u IFJvbWFuIFNocG91bnQNCkdlc2VuZGV0OiBNaXR0d29jaCwgMjkuIE5vdmVtYmVyIDIwMTcgMDA6 MDcNCkFuOiBKZXNza2UsIFJvbGFuZCA8bWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGU+DQpDYzog U0lQQ09SRSA8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQoNCkJldHJlZmY6IFJlOiBbc2lwY29y ZV0gU2Vzc2lvbiB0aW1lciBmaXgNCsKgDQpSb2xhbmQsDQrCoA0KUGxlYXNlIHByb3ZpZGUgdGhl IGV4YWN0IHNjZW5hcmlvLiBXaGF0IHlvdSBzZWVtIHRvIGJlIGRlc2NyaWJpbmcgYXJlIG1pc2Nv bmZpZ3VyZWQgcHJveGllcyBvciBjbGllbnRzIHRoYXQgZG8gbm90IGZvbGxvdyBleGlzdGluZyBz cGVjaWZpY2F0aW9ucy4NCsKgDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3Vu dA0KwqANCk9uIFR1ZSwgTm92IDI4LCAyMDE3IGF0IDU6MzMgUE0sIDxtYWlsdG86Ui5KZXNza2VA dGVsZWtvbS5kZT4gd3JvdGU6DQpIaSBQYXVsLA0KV2UgaGF2ZSBkaWZmZXJlbnQgaXNzdWVzIHdo ZXJlIHdlIGhhdmUgbG9vayBvbi4NCkFuZCB3ZSBzZWUgdGhhdCB3ZSBoYXZlIFVQREFURSB3aXRo IGFuIFMtVCBjYXVzaW5nIGEgbG90IG9mIHRyb3VibGUuDQpUaGlzIGlzIGRlcGVuZGVudCBvbiBk aWZmZXJlbnQgdXNlIGNhc2VzLg0KT25lIGlzIHRoYXQgdGhlIFVBIGRvZXMgbm90IHN1cHBvcnQg VVBEQVRFLg0KWWVzIHRoYXQgaXMgdHJ1ZS4NCkJ1dCBvbmUgb2YgdGhlIG1haW4gcHJvYmxlbXMg YXJlIHRoZSBwcm94aWVzIGluIGJldHdlZW4uDQpFaXRoZXIgcHJveGllcyBkbyBub3QgcmVhY3Qg d2hpY2ggaXMgT0suDQpBbmQgdGhlIFVBQyBpbnRlcnByZXRpbmcgdGhlIDIwME9LLg0KQWxzbyB0 aGUgZGlyZWN0aW9uIG9mIHRoZSBVUERBVEUgaXMgaW1wb3J0YW50Lg0KQWxzbyB0aGUgYmVoYXZp b3Igb2YgdGhlIHByb3h5LiBXZSBoYXZlIHNlZW4gcHJveGllcyBhZGRpbmcgUy1UIHRvIHRoZSBV UERBVEUgZHVlIHRvIHRoZSBmYWN0IHRoYXQgc2Vzc2lvbiB0aW1lciBzdXBwb3J0ZWQgaXMgc2V0 LiBUaGUgUy1UIHZhbHVlcyB3aGVyZSBkaWZmZXJlbnQgdG8gdGhhdCBzZXQgYnkgdGhlIFVBQy4N Cg0KU28gYXMgeW91IHNhaWQgd2UgY2FuIGlkZW50aWZ5IGFsbCB1c2UgY2FzZXMuIEFuZCBJIHRo aW5rIHRoYXQgaXMgd2hhdCB3ZSBuZWVkIG9yIHJlYWwgY2xlYXIgcnVsZXMgZm9yIFVBQy9VQVMg YW5kIFByb3h5Lg0KDQpCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQoNCg0KPiAtLS0tLVVyc3Byw7xu Z2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogUGF1bCBLeXppdmF0IFttYWlsdG86bWFpbHRv OnBreXppdmF0QGFsdW0ubWl0LmVkdV0NCj4gR2VzZW5kZXQ6IERpZW5zdGFnLCAyOC4gTm92ZW1i ZXIgMjAxNyAyMTozMQ0KPiBBbjogQ2hyaXN0ZXIgSG9sbWJlcmcgPG1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBSb21hbiBTaHBvdW50DQo+IDxtYWlsdG86cm9tYW5AdGVs dXJpeC5jb20+DQo+IENjOiBKZXNza2UsIFJvbGFuZCA8bWFpbHRvOlIuSmVzc2tlQHRlbGVrb20u ZGU+OyBtYWlsdG86c2lwY29yZUBpZXRmLm9yZw0KPiBCZXRyZWZmOiBSZTogW3NpcGNvcmVdIFNl c3Npb24gdGltZXIgZml4DQo+DQo+IE9uIDExLzI4LzE3IDI6NTMgUE0sIENocmlzdGVyIEhvbG1i ZXJnIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4+PiAxLiBXaGF0IGhhcHBlbnMgd2hlbiBVQUMg cmVjZWl2ZXMgYSAyWFggSU5WSVRFIHJlc3BvbnNlIHdpdGggUy1UDQo+ID4+PiB0aGF0IGRpZCBu b3QgbWF0Y2ggdGhlIFMtVCB2YWx1ZSBuZWdvdGlhdGVkIGJ5IFVQREFURSB0cmFuc2FjdGlvbg0K PiBkdXJpbmcgdGhpcyBJTlZJVEUgdHJhbnNhY3Rpb24/DQo+ID4+DQo+ID4+IEVycm9yIGNhc2Uu DQo+ID4+DQo+ID4+PiAyLiBXaGF0IGhhcHBlbnMgd2hlbiBVQUMgcmVjZWl2ZXMgYSAyWFggVVBE QVRFIHJlc3BvbnNlIHdpdGggUy1UDQo+ID4+PiB0aGF0IGRpZCBub3QgbWF0Y2ggdGhlIDJYWCBy ZXNwb25zZSBmb3IgdGhlIHByZXZpb3VzIFVQREFURQ0KPiB0cmFuc2FjdGlvbj8NCj4gPj4NCj4g Pj4gRXJyb3IgY2FzZS4NCj4gPj4NCj4gPj4gSG93IGRvIHlvdSB3YW50IHRvIGhhbmRsZSB0aGVz ZSBlcnJvciBjYXNlcz8gVHdvIG9wdGlvbnMgdGhhdCBJIHNlZSBhcmU6DQo+ID4+IGEuIFRlcm1p bmF0ZSB0aGUgZGlhbG9nIChoYW5nIHVwKQ0KPiA+PiBiLiBJc3N1ZSBhIG5ldyBVUERBVEUgdG8g c2V0IHJlZnJlc2hlciB0byBhIGtub3duIHN0YXRlLg0KPiA+DQo+ID4gVGhvc2UgYXJlIHR3byBh bHRlcm5hdGl2ZXMsIHllcy4gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIG1hbmRhdGUgYW55DQo+ IHNwZWNpZmljIGJlaGF2aW91ciwgYXMgbG9uZyBhcyB3ZSBtYWtlIGl0IGNsZWFyIHRoYXQgYW4g ZXJyb3IgaGFzIG9jY3VycmVkIGFuZA0KPiBpdCBuZWVkcyB0byBiZSB0YWtlbiBjYXJlIG9mIFNP TUVIT1cuDQo+DQo+IE9yIHlvdSBjYW4ganVzdCBpZ25vcmUgdGhlIGVycm9yIGFuZCBob3BlIGZv ciB0aGUgYmVzdC4NCj4NCj4gTXkgaW50dWl0aW9uIHRlbGxzIG1lIHRoYXQgdGhpcyB3aWxsIHJh cmVseSBjYXVzZSBhIHByb2JsZW0uIE1vc3Qgb2YgdGhlIHRpbWUgYQ0KPiBkZXZpY2UgdGhhdCBk b2Vzbid0IHN1cHBvcnQgdGhlIHVwZGF0ZSB3aWxsIGJlIGNvbXBsaWFudCB3aXRoIHRoZSB1cGRh dGUgYnkNCj4gYWNjaWRlbnQuIEFuZCBpbiBhIGJ1bmNoIG9mIHRoZSByZW1haW5pbmcgY2FzZXMg aWdub3JpbmcgYSBjb25mbGljdGluZyB2YWx1ZSBpbg0KPiB0aGUgbmVzdGVkIFVQREFURSB3b24n dCBtYXR0ZXIgYmVjYXVzZSBib3RoIGVuZHMgd2lsbCBzZXR0bGUgb24gd2hhdCBpcyBpbg0KPiB0 aGUgMjAwL0lOVklURS4gQW5kIHRoZSByZW1haW5pbmcgY2FzZXMgd2lsbCByZXN1bHQgaW4gYm90 aCBlbmRzIHRoaW5raW5nDQo+IHRoZXkgYXJlIFVBQyBvciBVQVMuIEl0IGlzbid0IGEgcHJvYmxl bSBpZiB0aGV5IGJvdGggdGhpbmsgdGhleSBhcmUgdGhlIFVBQywNCj4gc2luY2UgdGhlbiBib3Ro IHdpbGwgYXR0ZW1wdCB0byByZWZyZXNoLiBJdCBpcyBvbmx5IGEgcHJvYmxlbSBpZiB0aGV5IGJv dGggdGhpbmsNCj4gdGhleSBhcmUgVUFTLCBzaW5jZSB0aGF0IGlzIHRoZSBvbmx5IGNhc2Ugd2hl biB0aGUgc2Vzc2lvbiB3b24ndCBiZQ0KPiByZWZyZXNoZWQuIElmIHRoYXQgaGFwcGVucywgaXMg aXQgd29yc2UgdGhhbiBoYXZpbmcgaGFkIHRoZSBjYWxsIGZhaWw/DQo+DQo+IElmIG5lZWQgYmUg d2UgY2FuIHdvcmsgdGhyb3VnaCBhbGwgdGhlIGNhc2VzLiBCdXQgdGhlcmUgYXJlIHF1aXRlIGEg bG90IG9mDQo+IHRoZW0uDQo+DQo+wqAgwqAgwqAgwqBUaGFua3MsDQo+wqAgwqAgwqAgwqBQYXVs DQrCoA0KDQo= From nobody Tue Nov 28 17:37: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 F199F1292FD for ; Tue, 28 Nov 2017 17:37:53 -0800 (PST) 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 2T8F5kOTvwu1 for ; Tue, 28 Nov 2017 17:37:52 -0800 (PST) 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 045FB120454 for ; Tue, 28 Nov 2017 17:37:51 -0800 (PST) X-AuditID: 12074411-f7dff70000007f0a-a5-5a1e0f6fc1fd 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 AB.76.32522.F6F0E1A5; Tue, 28 Nov 2017 20:37:51 -0500 (EST) 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 vAT1boPt027678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 28 Nov 2017 20:37:50 -0500 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Tue, 28 Nov 2017 20:37:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.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+NgFvrKIsWRmVeSWpSXmKPExsUixO6iqJvPLxdlsGOakMXXH5vYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMWtVE1vBZcOKzx++sjYwLlPpYuTkkBAwkXjUtYSpi5GLQ0hg B5PE6ksz2SGcH0wSZ/Y+YgKpEhbQkDi05zcLiC0iICLxbPo/NhBbSOAfu8SMrfogNpuAlsSc Q//BangF7CW2/LoDZrMIqEr8O7OTGcQWFUiT2HOhA6pGUOLkzCdgNqdAjETD7CZGEJtZwExi 3uaHzBC2uMStJ/OZIGx5ieats5knMPLPQtI+C0nLLCQts5C0LGBkWcUol5hTmqubm5iZU5ya rFucnJiXl1qka6qXm1mil5pSuokREpaCOxhnnJQ7xCjAwajEw6uxWjZKiDWxrLgy9xCjJAeT kijvp4VAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8lZOAcrwpiZVVqUX5MClpDhYlcV6+Jep+ QgLpiSWp2ampBalFMFkZDg4lCd4CPrkoIcGi1PTUirTMnBKENBMHJ8hwHqDhoSA1vMUFibnF mekQ+VOMxhw9PTf+MHE8m/m6gVmIJS8/L1VKnDcYpFQApDSjNA9uGiy1vGIUB3pOmDcNpIoH mJbg5r0CWsUEtOrmfmmQVSWJCCmpBsZtK3vTez9/nPj8wLRTxV/tbLJ/85Ts0uMR6O5iTtcu L8l+EfLXek7RTmeNvX1fL4cwBqgVH/i6ftrFY0e2NflJsh7/Ijd/Z4nUzfMb7m3ax3Z9Ruu8 pfIiN43nz3rx03CfZSBzppWxxEJ+TUcr17OmB1PbmJka57r5qzI8k70bXP9OOlDSYqcSS3FG oqEWc1FxIgCeoHv0CAMAAA== 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: Wed, 29 Nov 2017 01:37:54 -0000 On 11/28/17 7:46 PM, R.Jesske@telekom.de wrote: > Hi Roman, > > Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards UAS. > > 1st negotiation is ongoing. > > 18x/PRACK/200OK(PRACK) is exchanged. > > Now UAS is sending UPDATE with a supported timer and Proxy adds S-E due > to local policy with S-E 1800. If that is its policy, why didn't it also reduce the S-E to 1800 in the INVITE? If it had done that there wouldn't be a problem. > So what will the UAC do. The proxy has added the S-E. The case you presented, where the proxy is inconsistent between INVITE and UPDATE, does present a problem. The UA could send S-E 1800 in the 200/UPDATE. But what the other end does in that case is undefined. What you have demonstrated here is that there is an issue with the S-E value as well as with the refresher role. > UAC (Which has sent the INVITE) could ignore and send 200 OK without any > S-E. i.e. ignoring UPDATE. > > In this case, what is the then proxy doing? Passing 200OK w/o S-E or may > it add an S-E again? Assuming it adds S-E 1800 because it remembers that > the UPDATE was received with supported timer. > > What does the UAS do? Ignoring the 200 OK with SE or accepting? > > And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 as > proposed by the INVITE, because the UAS is ignoring the 200 OK (UPDATE) > with S-E 1800? > > Or do you think that his is a wrong implementation. I think it is a stupid implementation. AFAIK there is nothing in 4028 that says it is wrong. I think the fix I sketched in a mail a few hours ago can probably be extended to cover this case. Notably, if one side detects an ambiguity in one or more of the negotiated s-t values, and that ambiguity has negative consequences, then it should initiate an immediate s-t refresh to fix it. We just need to sort out what all the ambiguities are and how to detect them. Thanks, Paul > Best Regards > > Roland > > *Von:* sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von *Roman > Shpount > *Gesendet:* Mittwoch, 29. November 2017 00:07 > *An:* Jesske, Roland > *Cc:* SIPCORE > *Betreff:* Re: [sipcore] Session timer fix > > Roland, > > Please provide the exact scenario. What you seem to be describing are > misconfigured proxies or clients that do not follow existing specifications. > > Regards, > > _____________ > Roman Shpount > > On Tue, Nov 28, 2017 at 5:33 PM, > wrote: > > Hi Paul, > We have different issues where we have look on. > And we see that we have UPDATE with an S-T causing a lot of trouble. > This is dependent on different use cases. > One is that the UA does not support UPDATE. > Yes that is true. > But one of the main problems are the proxies in between. > Either proxies do not react which is OK. > And the UAC interpreting the 200OK. > Also the direction of the UPDATE is important. > Also the behavior of the proxy. We have seen proxies adding S-T to > the UPDATE due to the fact that session timer supported is set. The > S-T values where different to that set by the UAC. > > So as you said we can identify all use cases. And I think that is > what we need or real clear rules for UAC/UAS and Proxy. > > Best Regards > > Roland > > > > -----Ursprüngliche Nachricht----- > > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu > ] > > Gesendet: Dienstag, 28. November 2017 21:31 > > An: Christer Holmberg >; Roman Shpount > > > > > Cc: Jesske, Roland >; sipcore@ietf.org > > > Betreff: Re: [sipcore] Session timer fix > > > > > On 11/28/17 2:53 PM, Christer Holmberg wrote: > > > Hi, > > > > > >>> 1. What happens when UAC receives a 2XX INVITE response with S-T > > >>> that did not match the S-T value negotiated by UPDATE transaction > > during this INVITE transaction? > > >> > > >> Error case. > > >> > > >>> 2. What happens when UAC receives a 2XX UPDATE response with S-T > > >>> that did not match the 2XX response for the previous UPDATE > > transaction? > > >> > > >> Error case. > > >> > > >> How do you want to handle these error cases? Two options that > I see are: > > >> a. Terminate the dialog (hang up) > > >> b. Issue a new UPDATE to set refresher to a known state. > > > > > > Those are two alternatives, yes. I don't think we need to > mandate any > > specific behaviour, as long as we make it clear that an error has > occurred and > > it needs to be taken care of SOMEHOW. > > > > Or you can just ignore the error and hope for the best. > > > > My intuition tells me that this will rarely cause a problem. Most > of the time a > > device that doesn't support the update will be compliant with the > update by > > accident. And in a bunch of the remaining cases ignoring a > conflicting value in > > the nested UPDATE won't matter because both ends will settle on > what is in > > the 200/INVITE. And the remaining cases will result in both ends > thinking > > they are UAC or UAS. It isn't a problem if they both think they > are the UAC, > > since then both will attempt to refresh. It is only a problem if > they both think > > they are UAS, since that is the only case when the session won't be > > refreshed. If that happens, is it worse than having had the call > fail? > > > > If need be we can work through all the cases. But there are quite > a lot of > > them. > > > >       Thanks, > >       Paul > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Nov 28 23:31:43 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 42F19127601 for ; Tue, 28 Nov 2017 23:31:42 -0800 (PST) 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 pqXaLmyuQabL for ; Tue, 28 Nov 2017 23:31:40 -0800 (PST) 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 E43E3127522 for ; Tue, 28 Nov 2017 23:31:39 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-75-5a1e6259bd82 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.E3.08439.9526E1A5; Wed, 29 Nov 2017 08:31:37 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Wed, 29 Nov 2017 08:31:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgIAA0dwAgADK3wCAAKRtAIAAEWVg///6T4CAACJbgIAACTGAgAAb1oCAAA5lAIAAhseA Date: Wed, 29 Nov 2017 07:31:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7um5kklyUwcSjhhYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx+/4J9oLJlhW3t95gaWD8odXFyMkhIWAi cfR5L2MXIxeHkMBhRokjW66yQjhLGCXm9MwEynBwsAlYSHT/0wZpEBEIlLi6ZAIziC0soCFx aM9vFoi4psTFU8uYQHpFBC4B9f54CVbEIqAqsXDxFrAiXgFridl3H4HFhQS2cEi07mUFmc8p 4CAxv9kbJMwoICbx/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK4gtKqAnseHEbXaI uKLE1enLoXr1JG5MncIGYVtLLHpwkhHC1pZYtvA1M8Q5ghInZz5hmcAoNgvJullI2mchaZ+F pH0WkvYFjKyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQLj6uCW36o7GC+/cTzEKMDBqMTD uydQLkqINbGsuDL3EKMEB7OSCO8GL6AQb0piZVVqUX58UWlOavEhRmkOFiVx3pOevFFCAumJ JanZqakFqUUwWSYOTqkGRukg78erzk/UOfk0tHbJxr+BvC/zPYIUH+6qjPd7kssj3Vnz4J2q 0bad0+y/TP04caaP9oN/LS/3lM7f0b7Ygm2aztatDJmnNoZO7FjaxH/Bas2++7LuF/l/2R1R +BCsoumkwPdu/vryC55c4ans7rd0voSbTktolfLaNmPxnJKJKwKWqEjs2qzEUpyRaKjFXFSc CAD3vPyQpwIAAA== 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: Wed, 29 Nov 2017 07:31:42 -0000 Hi, It is really difficult to reference specific messages when there is no call flow. But, in my opinion, whatever is sent in the 2xx/INVITE matters. I also think it would be a good idea for the UAS to actually include a timer value in the UPDATE request - the same timer value that it will later include in the 2xx/INVITE. The proxy may still of course lower the value, but perhaps it would simply pass it. Regards, Christer On 29/11/17 03:37, "sipcore on behalf of Paul Kyzivat" wrote: >On 11/28/17 7:46 PM, R.Jesske@telekom.de wrote: >> Hi Roman, >>=20 >> Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards >>UAS. >>=20 >> 1st negotiation is ongoing. >>=20 >> 18x/PRACK/200OK(PRACK) is exchanged. >>=20 >> Now UAS is sending UPDATE with a supported timer and Proxy adds S-E due >> to local policy with S-E 1800. > >If that is its policy, why didn't it also reduce the S-E to 1800 in the >INVITE? If it had done that there wouldn't be a problem. > >> So what will the UAC do. The proxy has added the S-E. > >The case you presented, where the proxy is inconsistent between INVITE >and UPDATE, does present a problem. The UA could send S-E 1800 in the >200/UPDATE. But what the other end does in that case is undefined. > >What you have demonstrated here is that there is an issue with the S-E >value as well as with the refresher role. > >> UAC (Which has sent the INVITE) could ignore and send 200 OK without >>any=20 >> S-E. i.e. ignoring UPDATE. >>=20 >> In this case, what is the then proxy doing? Passing 200OK w/o S-E or >>may=20 >> it add an S-E again? Assuming it adds S-E 1800 because it remembers >>that=20 >> the UPDATE was received with supported timer. >>=20 >> What does the UAS do? Ignoring the 200 OK with SE or accepting? >>=20 >> And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 as >> proposed by the INVITE, because the UAS is ignoring the 200 OK (UPDATE) >> with S-E 1800? >>=20 >> Or do you think that his is a wrong implementation. > >I think it is a stupid implementation. AFAIK there is nothing in 4028 >that says it is wrong. > >I think the fix I sketched in a mail a few hours ago can probably be >extended to cover this case. Notably, if one side detects an ambiguity >in one or more of the negotiated s-t values, and that ambiguity has >negative consequences, then it should initiate an immediate s-t refresh >to fix it. > >We just need to sort out what all the ambiguities are and how to detect >them. > > Thanks, > Paul > >> Best Regards >>=20 >> Roland >>=20 >> *Von:* sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von *Roman >> Shpount >> *Gesendet:* Mittwoch, 29. November 2017 00:07 >> *An:* Jesske, Roland >> *Cc:* SIPCORE >> *Betreff:* Re: [sipcore] Session timer fix >>=20 >> Roland, >>=20 >> Please provide the exact scenario. What you seem to be describing are >> misconfigured proxies or clients that do not follow existing >>specifications. >>=20 >> Regards, >>=20 >> _____________ >> Roman Shpount >>=20 >> On Tue, Nov 28, 2017 at 5:33 PM, > > wrote: >>=20 >> Hi Paul, >> We have different issues where we have look on. >> And we see that we have UPDATE with an S-T causing a lot of trouble. >> This is dependent on different use cases. >> One is that the UA does not support UPDATE. >> Yes that is true. >> But one of the main problems are the proxies in between. >> Either proxies do not react which is OK. >> And the UAC interpreting the 200OK. >> Also the direction of the UPDATE is important. >> Also the behavior of the proxy. We have seen proxies adding S-T to >> the UPDATE due to the fact that session timer supported is set. The >> S-T values where different to that set by the UAC. >>=20 >> So as you said we can identify all use cases. And I think that is >> what we need or real clear rules for UAC/UAS and Proxy. >>=20 >> Best Regards >>=20 >> Roland >>=20 >>=20 >> > -----Urspr=FCngliche Nachricht----- >> > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >> ] >> > Gesendet: Dienstag, 28. November 2017 21:31 >> > An: Christer Holmberg > >; Roman Shpount >> > > >> > Cc: Jesske, Roland > >; sipcore@ietf.org >> >> > Betreff: Re: [sipcore] Session timer fix >>=20 >> > >> > On 11/28/17 2:53 PM, Christer Holmberg wrote: >> > > Hi, >> > > >> > >>> 1. What happens when UAC receives a 2XX INVITE response with >>S-T >> > >>> that did not match the S-T value negotiated by UPDATE >>transaction >> > during this INVITE transaction? >> > >> >> > >> Error case. >> > >> >> > >>> 2. What happens when UAC receives a 2XX UPDATE response with >>S-T >> > >>> that did not match the 2XX response for the previous UPDATE >> > transaction? >> > >> >> > >> Error case. >> > >> >> > >> How do you want to handle these error cases? Two options that >> I see are: >> > >> a. Terminate the dialog (hang up) >> > >> b. Issue a new UPDATE to set refresher to a known state. >> > > >> > > Those are two alternatives, yes. I don't think we need to >> mandate any >> > specific behaviour, as long as we make it clear that an error has >> occurred and >> > it needs to be taken care of SOMEHOW. >> > >> > Or you can just ignore the error and hope for the best. >> > >> > My intuition tells me that this will rarely cause a problem. Most >> of the time a >> > device that doesn't support the update will be compliant with the >> update by >> > accident. And in a bunch of the remaining cases ignoring a >> conflicting value in >> > the nested UPDATE won't matter because both ends will settle on >> what is in >> > the 200/INVITE. And the remaining cases will result in both ends >> thinking >> > they are UAC or UAS. It isn't a problem if they both think they >> are the UAC, >> > since then both will attempt to refresh. It is only a problem if >> they both think >> > they are UAS, since that is the only case when the session won't >>be >> > refreshed. If that happens, is it worse than having had the call >> fail? >> > >> > If need be we can work through all the cases. But there are quite >> a lot of >> > them. >> > >> > Thanks, >> > Paul >>=20 >>=20 >>=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 From nobody Wed Nov 29 05:52: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 81DA2120724 for ; Wed, 29 Nov 2017 05:52:34 -0800 (PST) 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 qjgQXTGDOIXv for ; Wed, 29 Nov 2017 05:52:33 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 62F7B1274A5 for ; Wed, 29 Nov 2017 05:52:31 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id d66so4448787qkg.1 for ; Wed, 29 Nov 2017 05:52:31 -0800 (PST) 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=Jo+ddb0I9367ct4RGe18gMaQKK2swZYzRoKYROuYNU8=; b=DnwZx1NkcLsfrCAO4C+WZMakODPq/F3VLAPs6ndeo4rTVk0T2IY8FKt3QrvIKiOj+W MBkdB7tR9XgREnC9dd6Lp69/wkZbqfCf0+gvTap3ENB3BuIHntRD5w9gQrxdniD5dFLM GnhnBWZGqY8zFSh+1t9L4iEin7oR+RqzlQEadne8STh595zXjqBR/ojbWaZgUqBvkrdC VTfmgpKykKpUdbWmwIqg8XrL/xCoaRbPVBXrqcU8zz/o8qdl47b63VBCSd1rcaePKbHX uDizOSMifPhKqFdmv0ygHWskISoPfhPK4owiLEFI07dRrzZnKJiX9LLJhgBwN2Zu2kmp HQIA== 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=Jo+ddb0I9367ct4RGe18gMaQKK2swZYzRoKYROuYNU8=; b=HjSQsYGS2h1UW4Z6xgia0p1ZRQAJufzeTtIy7Wya4IoASdkX5jYeAcI2JpiNAyXbSa xNxMMxX4lCoZHR6e7B6Se5TkBWVoCvMJfw5sUVy9yod1CShP5UL4rzLhtGxtxj2NYA2f Uo9YgL+EtJVbKeIEx5Yf0McfxOedRl99+k9rSyfDc0s4WG/hnz84ZXAJm4PYcQDtqTu3 9YmEwRAJaXfyZgFaeRyKaVdtlJW6yhYbhdWRj8FMv9QkKZT7mGbBGFRNMUfCCEHPf5Bp AOuQxssFvoSD5jcsJaeexOJNqo7OglRwLGGLJr31g7/JFvYEoc/cix0eCdMmEh+cvk5U vs1w== X-Gm-Message-State: AJaThX6KGIOfysMnwPMIvIQSRWlJm8e8pqx8IVDb8ZCohdnnkdZ5vh8x 8ziAzxWY1z/LbfPXfNdVDTUZwGlvtBc= X-Google-Smtp-Source: AGs4zMbXTerj6euJiw/3b8ePTdgdQjOWZuDyr9+1Ew1N8Lx87PstUyPY6pY/WdeJdAvXsWnlastdqw== X-Received: by 10.55.157.133 with SMTP id g127mr4264942qke.280.1511963550147; Wed, 29 Nov 2017 05:52:30 -0800 (PST) Received: from [10.33.193.2] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id 76sm1293630qky.56.2017.11.29.05.52.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 05:52:29 -0800 (PST) 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: Date: Wed, 29 Nov 2017 08:52:27 -0500 To: SIPCORE X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sipcore] Call For Adoption 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: Wed, 29 Nov 2017 13:52:34 -0000 We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore = document. Please provide comments by December 13.= From nobody Wed Nov 29 08:35: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 7DAF81242EA for ; Wed, 29 Nov 2017 08:35:08 -0800 (PST) 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 JIgNyTWf23vl for ; Wed, 29 Nov 2017 08:35:06 -0800 (PST) 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 6D8A7128616 for ; Wed, 29 Nov 2017 08:35:06 -0800 (PST) X-AuditID: 12074411-f95ff70000007f0a-03-5a1ee1b94d4b 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 D1.F9.32522.9B1EE1A5; Wed, 29 Nov 2017 11:35:05 -0500 (EST) 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 vATGZ447004464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Nov 2017 11:35:04 -0500 To: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> Date: Wed, 29 Nov 2017 11:35:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.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+NgFvrHIsWRmVeSWpSXmKPExsUixO6iqLvzoVyUwYZJMhYXZh5mtPj6YxOb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJVxpnU2W8GtgIq+syuZGxif2XQxcnJICJhI 3F23m62LkYtDSGAHk8TZN5MYIZyHTBKdfZ+ZQaqEBTQkDu35zQJiiwikSfRM7GeHKHrDLrFr 2Vx2kASbgJbEnEP/gYo4OHgF7CU+7warZxFQlbg44zcriC0K1LvnQgdYnFdAUOLkzCdg5ZwC NhJft5uBhJkFzCTmbX7IDGGLS9x6Mp8JwpaXaN46m3kCI/8sJN2zkLTMQtIyC0nLAkaWVYxy iTmlubq5iZk5xanJusXJiXl5qUW6pnq5mSV6qSmlmxghgSq4g3HGSblDjAIcjEo8vBqrZaOE WBPLiitzDzFKcjApifJ+WggU4kvKT6nMSCzOiC8qzUktPsQowcGsJMKrsFsuSog3JbGyKrUo HyYlzcGiJM7Lt0TdT0ggPbEkNTs1tSC1CCYrw8GhJMH7/AFQo2BRanpqRVpmTglCmomDE2Q4 D9DwwyA1vMUFibnFmekQ+VOMxhw9PTf+MHE8m/m6gVmIJS8/L1VKnHcCSKkASGlGaR7cNFiy ecUoDvScMK8WMPUI8QATFdy8V0CrmIBW3dwvDbKqJBEhJdXAmHBx/4bdgkJOzx7cD6pZsnVi 3Y/DX3OjeJ4wXp026ewmfTYr/pb9tfM7gtdZOH5smFp5ZIHt9s3uC60fvjKJib7Nd/L0td7O mK0hz//6PZ3IxnJqQsOSTcz+jW37ZYLKOY/KRf0rXHVw05ZVC+7Ktl9472It7mao1bcxp+6I SmjuvhrlgFdsdkosxRmJhlrMRcWJAFEqA1ARAwAA 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: Wed, 29 Nov 2017 16:35:08 -0000 We have wandered around quite a bit on this. I'm not sure if we are converging or not. I'm going to try to restate the problem, taking advantage of the insights that we've had in the discussion. The Problem: Even when all parties comply with RFC4028 it is possible to end with differences of opinion among the parties about the negotiated session timer values: the session expiration time, the min-s-e, and/or the refresher. In some cases these ambiguities are benign in that the session will still get refreshed by somebody who is willing to do so within a time interval that is acceptable to all. And the refresh may well clear up the ambiguity. However there are some cases that are not so benign. For instance, it is possible to arrive at a situation where neither UA believes it is the refresher, and so the session will never get refreshed. Possible Solutions (in the abstract): 1) Revise/clarify the rules of RFC4028 to eliminate the ambiguities. An issue with this is that it only eliminates all the problems if all the parties in the call (UAC, UAS, and proxies) implement this update. In principle Require and Proxy-Require could be used to ensure that all parties support the update. But in practice there is no good way to roll that out, and it is generally more important that calls succeed. 2) If a UA in the call detects that the call has ended up in a state that causes a non-benign ambiguity it should immediately initiate a session refresh to remove the ambiguity. In most cases it should be possible for at least one end to detect the situation. The only exception I can think of is when neither UA supports this extension but a proxy does. I think the proxy is helpless in this case and I don't see any fix other than the proxy causing the INVITE to fail. ISTM that doing (1) isn't a sufficient solution, while (2) is. So I think we should concentrate on that first. A really simple algorithm for this would be that if an UPDATE was used within an INVITE then once the INVITE completes then the end that thinks it is now UAS (non refresher) should immediately do a refresh using UPDATE. This would clarify who is refresher and fix the case where neither end think they are the refresher. And it would clarify any ambiguity in s-e and min-s-e. But that algorithm is inefficient in that it will be sent in many cases where it isn't needed. I think we can narrow the conditions when it needs to be sent, so that it is only sent if there actually is non-benign ambiguity. I think (2) is probably sufficient. If we wanted to go further, then we could *also* do (1). Thanks, Paul On 11/29/17 2:31 AM, Christer Holmberg wrote: > Hi, > > It is really difficult to reference specific messages when there is no > call flow. > > But, in my opinion, whatever is sent in the 2xx/INVITE matters. > > I also think it would be a good idea for the UAS to actually include a > timer value in the UPDATE request - the same timer value that it will > later include in the 2xx/INVITE. The proxy may still of course lower the > value, but perhaps it would simply pass it. > > Regards, > > Christer > > > > > On 29/11/17 03:37, "sipcore on behalf of Paul Kyzivat" > wrote: > >> On 11/28/17 7:46 PM, R.Jesske@telekom.de wrote: >>> Hi Roman, >>> >>> Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards >>> UAS. >>> >>> 1st negotiation is ongoing. >>> >>> 18x/PRACK/200OK(PRACK) is exchanged. >>> >>> Now UAS is sending UPDATE with a supported timer and Proxy adds S-E due >>> to local policy with S-E 1800. >> >> If that is its policy, why didn't it also reduce the S-E to 1800 in the >> INVITE? If it had done that there wouldn't be a problem. >> >>> So what will the UAC do. The proxy has added the S-E. >> >> The case you presented, where the proxy is inconsistent between INVITE >> and UPDATE, does present a problem. The UA could send S-E 1800 in the >> 200/UPDATE. But what the other end does in that case is undefined. >> >> What you have demonstrated here is that there is an issue with the S-E >> value as well as with the refresher role. >> >>> UAC (Which has sent the INVITE) could ignore and send 200 OK without >>> any >>> S-E. i.e. ignoring UPDATE. >>> >>> In this case, what is the then proxy doing? Passing 200OK w/o S-E or >>> may >>> it add an S-E again? Assuming it adds S-E 1800 because it remembers >>> that >>> the UPDATE was received with supported timer. >>> >>> What does the UAS do? Ignoring the 200 OK with SE or accepting? >>> >>> And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 as >>> proposed by the INVITE, because the UAS is ignoring the 200 OK (UPDATE) >>> with S-E 1800? >>> >>> Or do you think that his is a wrong implementation. >> >> I think it is a stupid implementation. AFAIK there is nothing in 4028 >> that says it is wrong. >> >> I think the fix I sketched in a mail a few hours ago can probably be >> extended to cover this case. Notably, if one side detects an ambiguity >> in one or more of the negotiated s-t values, and that ambiguity has >> negative consequences, then it should initiate an immediate s-t refresh >> to fix it. >> >> We just need to sort out what all the ambiguities are and how to detect >> them. >> >> Thanks, >> Paul >> >>> Best Regards >>> >>> Roland >>> >>> *Von:* sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von *Roman >>> Shpount >>> *Gesendet:* Mittwoch, 29. November 2017 00:07 >>> *An:* Jesske, Roland >>> *Cc:* SIPCORE >>> *Betreff:* Re: [sipcore] Session timer fix >>> >>> Roland, >>> >>> Please provide the exact scenario. What you seem to be describing are >>> misconfigured proxies or clients that do not follow existing >>> specifications. >>> >>> Regards, >>> >>> _____________ >>> Roman Shpount >>> >>> On Tue, Nov 28, 2017 at 5:33 PM, >> > wrote: >>> >>> Hi Paul, >>> We have different issues where we have look on. >>> And we see that we have UPDATE with an S-T causing a lot of trouble. >>> This is dependent on different use cases. >>> One is that the UA does not support UPDATE. >>> Yes that is true. >>> But one of the main problems are the proxies in between. >>> Either proxies do not react which is OK. >>> And the UAC interpreting the 200OK. >>> Also the direction of the UPDATE is important. >>> Also the behavior of the proxy. We have seen proxies adding S-T to >>> the UPDATE due to the fact that session timer supported is set. The >>> S-T values where different to that set by the UAC. >>> >>> So as you said we can identify all use cases. And I think that is >>> what we need or real clear rules for UAC/UAS and Proxy. >>> >>> Best Regards >>> >>> Roland >>> >>> >>> > -----Ursprüngliche Nachricht----- >>> > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >>> ] >>> > Gesendet: Dienstag, 28. November 2017 21:31 >>> > An: Christer Holmberg >> >; Roman Shpount >>> > > >>> > Cc: Jesske, Roland >> >; sipcore@ietf.org >>> >>> > Betreff: Re: [sipcore] Session timer fix >>> >>> > >>> > On 11/28/17 2:53 PM, Christer Holmberg wrote: >>> > > Hi, >>> > > >>> > >>> 1. What happens when UAC receives a 2XX INVITE response with >>> S-T >>> > >>> that did not match the S-T value negotiated by UPDATE >>> transaction >>> > during this INVITE transaction? >>> > >> >>> > >> Error case. >>> > >> >>> > >>> 2. What happens when UAC receives a 2XX UPDATE response with >>> S-T >>> > >>> that did not match the 2XX response for the previous UPDATE >>> > transaction? >>> > >> >>> > >> Error case. >>> > >> >>> > >> How do you want to handle these error cases? Two options that >>> I see are: >>> > >> a. Terminate the dialog (hang up) >>> > >> b. Issue a new UPDATE to set refresher to a known state. >>> > > >>> > > Those are two alternatives, yes. I don't think we need to >>> mandate any >>> > specific behaviour, as long as we make it clear that an error has >>> occurred and >>> > it needs to be taken care of SOMEHOW. >>> > >>> > Or you can just ignore the error and hope for the best. >>> > >>> > My intuition tells me that this will rarely cause a problem. Most >>> of the time a >>> > device that doesn't support the update will be compliant with the >>> update by >>> > accident. And in a bunch of the remaining cases ignoring a >>> conflicting value in >>> > the nested UPDATE won't matter because both ends will settle on >>> what is in >>> > the 200/INVITE. And the remaining cases will result in both ends >>> thinking >>> > they are UAC or UAS. It isn't a problem if they both think they >>> are the UAC, >>> > since then both will attempt to refresh. It is only a problem if >>> they both think >>> > they are UAS, since that is the only case when the session won't >>> be >>> > refreshed. If that happens, is it worse than having had the call >>> fail? >>> > >>> > If need be we can work through all the cases. But there are quite >>> a lot of >>> > them. >>> > >>> > Thanks, >>> > Paul >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Nov 29 10:38: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 23902127444 for ; Wed, 29 Nov 2017 10:38:51 -0800 (PST) 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 0q1Lw6wjEJhO for ; Wed, 29 Nov 2017 10:38:48 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 2E5A7127337 for ; Wed, 29 Nov 2017 10:38:48 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id k15so1868194pgr.7 for ; Wed, 29 Nov 2017 10:38:48 -0800 (PST) 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=T/tUta+7LAQJ9qrKcsdE6hUWipI7k6Pk1euQ+jnzGf4=; b=kYKghwdRVgoyrJxXPeFx+lgkSDjsiwO+UnjtBTcIKbDAaNPycfXH0sgMYurbDVl2Z0 3pNbVaJr64aZPqmaUsUZo7FiWZ76+SgOdWctVK8GePufw9Uzwi5lYCg5FudSZnyc5QAC o2kccFEFmOJSNhLwmSgdgnJV3DBEK+8WInmspRL7fDkgtehj/EA5uO+w42iX/rKX7nFb G3JePxYVuIr2Mbp9BAhKvTDPdGQ1TYOBEnVX1R9GR7QnT+OIX3/B+QZKDOQOL8+Tae2I OjqFyA2hiq4ipQjRy8TXyM54ilAQciMwmNaFOhBzc67R8Yj2rKxYu1LEzwuL339ifQ/u vUVQ== 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=T/tUta+7LAQJ9qrKcsdE6hUWipI7k6Pk1euQ+jnzGf4=; b=uZT9vVY6H6jz5Yty34u19pmYL38FaZMy5VvSMI9mJUfhAu8NB6viyviMk1jjRgL9+n rkl8DiSX78eE5CUDQhw6K9CDs0ZAEcC+sMahTH7kwUSvOkL17cJ4HIwoRHRG9HQiqI/o DYsFsBo0e2IZD/K7JIJCgYR/u8qQWYkhVCbyd4GgBodZlwx/AkCSlKSeRUp1+IIat8yL jIsTR1k99i+A932rymMAeVgaD9cZPvDxGOgGHNbVWpHAnIPSjnSaeumaAJuimtGPu651 A+sqb2fwR+yzy56lBIGjRUiCRlupV9UOFnhHT8+JleCl8kBGlXz8FuxJuokIEX+aw+3B 4Qjg== X-Gm-Message-State: AJaThX5Gch8Zl8uOOje9HFaTEbI+e2UHw2dQl7p+pMBEoZEaNlY1t+md BO8B1PGA2TBBfa4BA0YnZ7QnDZqk X-Google-Smtp-Source: AGs4zMbQY/K5Vq/J2X/Ejk1jHjOS8xjZtkphXygNyI5DJaKO6gS9iYoQT9wM9bzhbUZ0hSgBUN07Ow== X-Received: by 10.99.5.1 with SMTP id 1mr3604633pgf.183.1511980727487; Wed, 29 Nov 2017 10:38:47 -0800 (PST) Received: from mail-pl0-f42.google.com (mail-pl0-f42.google.com. [209.85.160.42]) by smtp.gmail.com with ESMTPSA id l73sm4904678pfi.82.2017.11.29.10.38.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 10:38:46 -0800 (PST) Received: by mail-pl0-f42.google.com with SMTP id 1so2609381pla.7 for ; Wed, 29 Nov 2017 10:38:46 -0800 (PST) X-Received: by 10.84.214.2 with SMTP id h2mr3919930pli.142.1511980726119; Wed, 29 Nov 2017 10:38:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Wed, 29 Nov 2017 10:38:45 -0800 (PST) In-Reply-To: <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> From: Roman Shpount Date: Wed, 29 Nov 2017 13:38:45 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="f403045d2648167446055f237219" 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: Wed, 29 Nov 2017 18:38:51 -0000 --f403045d2648167446055f237219 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Paul, I generally agree. I think the path forward should be: 1. Define conditions when S-E state is dangerously ambiguous and recommend for UA to send an UPDATE to clarify the S-E state 2. Define recommended rules for UA and Proxies to avoid ambiguous situation= s 1 should be sufficient to provide resilient implementations. 2 should help to avoid the extra UPDATE. Regards, _____________ Roman Shpount On Wed, Nov 29, 2017 at 11:35 AM, Paul Kyzivat wrote: > We have wandered around quite a bit on this. I'm not sure if we are > converging or not. I'm going to try to restate the problem, taking > advantage of the insights that we've had in the discussion. > > The Problem: > > Even when all parties comply with RFC4028 it is possible to end with > differences of opinion among the parties about the negotiated session tim= er > values: the session expiration time, the min-s-e, and/or the refresher. > > In some cases these ambiguities are benign in that the session will still > get refreshed by somebody who is willing to do so within a time interval > that is acceptable to all. And the refresh may well clear up the ambiguit= y. > > However there are some cases that are not so benign. For instance, it is > possible to arrive at a situation where neither UA believes it is the > refresher, and so the session will never get refreshed. > > Possible Solutions (in the abstract): > > 1) Revise/clarify the rules of RFC4028 to eliminate the ambiguities. > > An issue with this is that it only eliminates all the problems if all the > parties in the call (UAC, UAS, and proxies) implement this update. In > principle Require and Proxy-Require could be used to ensure that all > parties support the update. But in practice there is no good way to roll > that out, and it is generally more important that calls succeed. > > 2) If a UA in the call detects that the call has ended up in a state that > causes a non-benign ambiguity it should immediately initiate a session > refresh to remove the ambiguity. > > In most cases it should be possible for at least one end to detect the > situation. The only exception I can think of is when neither UA supports > this extension but a proxy does. I think the proxy is helpless in this ca= se > and I don't see any fix other than the proxy causing the INVITE to fail. > > ISTM that doing (1) isn't a sufficient solution, while (2) is. So I think > we should concentrate on that first. > > A really simple algorithm for this would be that if an UPDATE was used > within an INVITE then once the INVITE completes then the end that thinks = it > is now UAS (non refresher) should immediately do a refresh using UPDATE. > This would clarify who is refresher and fix the case where neither end > think they are the refresher. And it would clarify any ambiguity in s-e a= nd > min-s-e. > > But that algorithm is inefficient in that it will be sent in many cases > where it isn't needed. I think we can narrow the conditions when it needs > to be sent, so that it is only sent if there actually is non-benign > ambiguity. > > I think (2) is probably sufficient. If we wanted to go further, then we > could *also* do (1). > > Thanks, > Paul > > > > On 11/29/17 2:31 AM, Christer Holmberg wrote: > >> Hi, >> >> It is really difficult to reference specific messages when there is no >> call flow. >> >> But, in my opinion, whatever is sent in the 2xx/INVITE matters. >> >> I also think it would be a good idea for the UAS to actually include a >> timer value in the UPDATE request - the same timer value that it will >> later include in the 2xx/INVITE. The proxy may still of course lower the >> value, but perhaps it would simply pass it. >> >> Regards, >> >> Christer >> >> >> >> >> On 29/11/17 03:37, "sipcore on behalf of Paul Kyzivat" >> wrote: >> >> On 11/28/17 7:46 PM, R.Jesske@telekom.de wrote: >>> >>>> Hi Roman, >>>> >>>> Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards >>>> UAS. >>>> >>>> 1st negotiation is ongoing. >>>> >>>> 18x/PRACK/200OK(PRACK) is exchanged. >>>> >>>> Now UAS is sending UPDATE with a supported timer and Proxy adds S-E du= e >>>> to local policy with S-E 1800. >>>> >>> >>> If that is its policy, why didn't it also reduce the S-E to 1800 in the >>> INVITE? If it had done that there wouldn't be a problem. >>> >>> So what will the UAC do. The proxy has added the S-E. >>>> >>> >>> The case you presented, where the proxy is inconsistent between INVITE >>> and UPDATE, does present a problem. The UA could send S-E 1800 in the >>> 200/UPDATE. But what the other end does in that case is undefined. >>> >>> What you have demonstrated here is that there is an issue with the S-E >>> value as well as with the refresher role. >>> >>> UAC (Which has sent the INVITE) could ignore and send 200 OK without >>>> any >>>> S-E. i.e. ignoring UPDATE. >>>> >>>> In this case, what is the then proxy doing? Passing 200OK w/o S-E or >>>> may >>>> it add an S-E again? Assuming it adds S-E 1800 because it remembers >>>> that >>>> the UPDATE was received with supported timer. >>>> >>>> What does the UAS do? Ignoring the 200 OK with SE or accepting? >>>> >>>> And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 a= s >>>> proposed by the INVITE, because the UAS is ignoring the 200 OK (UPDATE= ) >>>> with S-E 1800? >>>> >>>> Or do you think that his is a wrong implementation. >>>> >>> >>> I think it is a stupid implementation. AFAIK there is nothing in 4028 >>> that says it is wrong. >>> >>> I think the fix I sketched in a mail a few hours ago can probably be >>> extended to cover this case. Notably, if one side detects an ambiguity >>> in one or more of the negotiated s-t values, and that ambiguity has >>> negative consequences, then it should initiate an immediate s-t refresh >>> to fix it. >>> >>> We just need to sort out what all the ambiguities are and how to detect >>> them. >>> >>> Thanks, >>> Paul >>> >>> Best Regards >>>> >>>> Roland >>>> >>>> *Von:* sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von *Roma= n >>>> Shpount >>>> *Gesendet:* Mittwoch, 29. November 2017 00:07 >>>> *An:* Jesske, Roland >>>> *Cc:* SIPCORE >>>> *Betreff:* Re: [sipcore] Session timer fix >>>> >>>> Roland, >>>> >>>> Please provide the exact scenario. What you seem to be describing are >>>> misconfigured proxies or clients that do not follow existing >>>> specifications. >>>> >>>> Regards, >>>> >>>> _____________ >>>> Roman Shpount >>>> >>>> On Tue, Nov 28, 2017 at 5:33 PM, >>> > wrote: >>>> >>>> Hi Paul, >>>> We have different issues where we have look on. >>>> And we see that we have UPDATE with an S-T causing a lot of >>>> trouble. >>>> This is dependent on different use cases. >>>> One is that the UA does not support UPDATE. >>>> Yes that is true. >>>> But one of the main problems are the proxies in between. >>>> Either proxies do not react which is OK. >>>> And the UAC interpreting the 200OK. >>>> Also the direction of the UPDATE is important. >>>> Also the behavior of the proxy. We have seen proxies adding S-T t= o >>>> the UPDATE due to the fact that session timer supported is set. T= he >>>> S-T values where different to that set by the UAC. >>>> >>>> So as you said we can identify all use cases. And I think that is >>>> what we need or real clear rules for UAC/UAS and Proxy. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> >>>> > -----Urspr=C3=BCngliche Nachricht----- >>>> > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >>>> ] >>>> > Gesendet: Dienstag, 28. November 2017 21:31 >>>> > An: Christer Holmberg >>> >; Roman Shpount >>>> > > >>>> > Cc: Jesske, Roland >>> >; sipcore@ietf.org >>>> >>>> > Betreff: Re: [sipcore] Session timer fix >>>> >>>> > >>>> > On 11/28/17 2:53 PM, Christer Holmberg wrote: >>>> > > Hi, >>>> > > >>>> > >>> 1. What happens when UAC receives a 2XX INVITE response wi= th >>>> S-T >>>> > >>> that did not match the S-T value negotiated by UPDATE >>>> transaction >>>> > during this INVITE transaction? >>>> > >> >>>> > >> Error case. >>>> > >> >>>> > >>> 2. What happens when UAC receives a 2XX UPDATE response wi= th >>>> S-T >>>> > >>> that did not match the 2XX response for the previous UPDAT= E >>>> > transaction? >>>> > >> >>>> > >> Error case. >>>> > >> >>>> > >> How do you want to handle these error cases? Two options th= at >>>> I see are: >>>> > >> a. Terminate the dialog (hang up) >>>> > >> b. Issue a new UPDATE to set refresher to a known state. >>>> > > >>>> > > Those are two alternatives, yes. I don't think we need to >>>> mandate any >>>> > specific behaviour, as long as we make it clear that an error >>>> has >>>> occurred and >>>> > it needs to be taken care of SOMEHOW. >>>> > >>>> > Or you can just ignore the error and hope for the best. >>>> > >>>> > My intuition tells me that this will rarely cause a problem. >>>> Most >>>> of the time a >>>> > device that doesn't support the update will be compliant with >>>> the >>>> update by >>>> > accident. And in a bunch of the remaining cases ignoring a >>>> conflicting value in >>>> > the nested UPDATE won't matter because both ends will settle o= n >>>> what is in >>>> > the 200/INVITE. And the remaining cases will result in both en= ds >>>> thinking >>>> > they are UAC or UAS. It isn't a problem if they both think the= y >>>> are the UAC, >>>> > since then both will attempt to refresh. It is only a problem = if >>>> they both think >>>> > they are UAS, since that is the only case when the session won= 't >>>> be >>>> > refreshed. If that happens, is it worse than having had the ca= ll >>>> fail? >>>> > >>>> > If need be we can work through all the cases. But there are >>>> quite >>>> a lot of >>>> > them. >>>> > >>>> > Thanks, >>>> > Paul >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > --f403045d2648167446055f237219 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul,

I generally agree. I think the pa= th forward should be:

1. Define conditions when S-= E state is dangerously ambiguous and recommend for UA to send an UPDATE to = clarify the S-E state
2. Define recommended rules for UA and Prox= ies to avoid ambiguous situations

1 should be suff= icient to provide resilient implementations. 2 should help to avoid the ext= ra UPDATE.

Regards,
________= _____
Roman Shpount

On Wed, Nov 29, 2017 at 11:35 AM, Paul Kyziv= at <pkyzivat@alum.mit.edu> wrote:
We have wandered around quite a bit on this. I'm not sure= if we are converging or not. I'm going to try to restate the problem, = taking advantage of the insights that we've had in the discussion.

The Problem:

Even when all parties comply with RFC4028 it is possible to end with differ= ences of opinion among the parties about the negotiated session timer value= s: the session expiration time, the min-s-e, and/or the refresher.

In some cases these ambiguities are benign in that the session will still g= et refreshed by somebody who is willing to do so within a time interval tha= t is acceptable to all. And the refresh may well clear up the ambiguity.
However there are some cases that are not so benign. For instance, it is po= ssible to arrive at a situation where neither UA believes it is the refresh= er, and so the session will never get refreshed.

Possible Solutions (in the abstract):

1) Revise/clarify the rules of RFC4028 to eliminate the ambiguities.

An issue with this is that it only eliminates all the problems if all the p= arties in the call (UAC, UAS, and proxies) implement this update. In princi= ple Require and Proxy-Require could be used to ensure that all parties supp= ort the update. But in practice there is no good way to roll that out, and = it is generally more important that calls succeed.

2) If a UA in the call detects that the call has ended up in a state that c= auses a non-benign ambiguity it should immediately initiate a session refre= sh to remove the ambiguity.

In most cases it should be possible for at least one end to detect the situ= ation. The only exception I can think of is when neither UA supports this e= xtension but a proxy does. I think the proxy is helpless in this case and I= don't see any fix other than the proxy causing the INVITE to fail.

ISTM that doing (1) isn't a sufficient solution, while (2) is. So I thi= nk we should concentrate on that first.

A really simple algorithm for this would be that if an UPDATE was used with= in an INVITE then once the INVITE completes then the end that thinks it is = now UAS (non refresher) should immediately do a refresh using UPDATE. This = would clarify who is refresher and fix the case where neither end think the= y are the refresher. And it would clarify any ambiguity in s-e and min-s-e.=

But that algorithm is inefficient in that it will be sent in many cases whe= re it isn't needed. I think we can narrow the conditions when it needs = to be sent, so that it is only sent if there actually is non-benign ambigui= ty.

I think (2) is probably sufficient. If we wanted to go further, then we cou= ld *also* do (1).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul


On 11/29/17 2:31 AM, Christer Holmberg wrote:
Hi,

It is really difficult to reference specific messages when there is no
call flow.

But, in my opinion, whatever is sent in the 2xx/INVITE matters.

I also think it would be a good idea for the UAS to actually include a
timer value in the UPDATE request - the same timer value that it will
later include in the 2xx/INVITE. The proxy may still of course lower the value, but perhaps it would simply pass it.

Regards,

Christer




On 29/11/17 03:37, "sipcore on behalf of Paul Kyzivat"
<sipcore-b= ounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:

On 11/28/17 7:46 PM, R.Jesske@telekom.de wrote:
Hi Roman,

Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards
UAS.

1st negotiation is ongoing.

18x/PRACK/200OK(PRACK) is exchanged.

Now UAS is sending UPDATE with a supported timer and Proxy adds S-E due
to local policy with S-E 1800.

If that is its policy, why didn't it also reduce the S-E to 1800 in the=
INVITE? If it had done that there wouldn't be a problem.

So what will the UAC do. The proxy has added the S-E.

The case you presented, where the proxy is inconsistent between INVITE
and UPDATE, does present a problem. The UA could send S-E 1800 in the
200/UPDATE. But what the other end does in that case is undefined.

What you have demonstrated here is that there is an issue with the S-E
value as well as with the refresher role.

UAC (Which has sent the INVITE) could ignore and send 200 OK without
any
S-E. i.e. ignoring UPDATE.

In this case, what is the then proxy doing? Passing 200OK w/o S-E or
may
it add an S-E again? Assuming it adds S-E 1800 because it remembers
that
the UPDATE was received with supported timer.

What does the UAS do? Ignoring the 200 OK with SE or accepting?

And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 as
proposed by the INVITE, because the UAS is ignoring the 200 OK (UPDATE)
with S-E 1800?

Or do you think that his is a wrong implementation.

I think it is a stupid implementation. AFAIK there is nothing in 4028
that says it is wrong.

I think the fix I sketched in a mail a few hours ago can probably be
extended to cover this case. Notably, if one side detects an ambiguity
in one or more of the negotiated s-t values, and that ambiguity has
negative consequences, then it should initiate an immediate s-t refresh
to fix it.

We just need to sort out what all the ambiguities are and how to detect
them.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

Best Regards

Roland

*Von:* sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von *Roman
Shpount
*Gesendet:* Mittwoch, 29. November 2017 00:07
*An:* Jesske, Roland <R.Jesske@telekom.de>
*Cc:* SIPCORE <sip= core@ietf.org>
*Betreff:* Re: [sipcore] Session timer fix

Roland,

Please provide the exact scenario. What you seem to be describing are
misconfigured proxies or clients that do not follow existing
specifications.

Regards,

_____________
Roman Shpount

On Tue, Nov 28, 2017 at 5:33 PM, <R.Jesske@telekom.de
<mailto:R.Jessk= e@telekom.de>> wrote:

=C2=A0 =C2=A0 =C2=A0Hi Paul,
=C2=A0 =C2=A0 =C2=A0We have different issues where we have look on.
=C2=A0 =C2=A0 =C2=A0And we see that we have UPDATE with an S-T causing a lo= t of trouble.
=C2=A0 =C2=A0 =C2=A0This is dependent on different use cases.
=C2=A0 =C2=A0 =C2=A0One is that the UA does not support UPDATE.
=C2=A0 =C2=A0 =C2=A0Yes that is true.
=C2=A0 =C2=A0 =C2=A0But one of the main problems are the proxies in between= .
=C2=A0 =C2=A0 =C2=A0Either proxies do not react which is OK.
=C2=A0 =C2=A0 =C2=A0And the UAC interpreting the 200OK.
=C2=A0 =C2=A0 =C2=A0Also the direction of the UPDATE is important.
=C2=A0 =C2=A0 =C2=A0Also the behavior of the proxy. We have seen proxies ad= ding S-T to
=C2=A0 =C2=A0 =C2=A0the UPDATE due to the fact that session timer supported= is set. The
=C2=A0 =C2=A0 =C2=A0S-T values where different to that set by the UAC.

=C2=A0 =C2=A0 =C2=A0So as you said we can identify all use cases. And I thi= nk that is
=C2=A0 =C2=A0 =C2=A0what we need or real clear rules for UAC/UAS and Proxy.=

=C2=A0 =C2=A0 =C2=A0Best Regards

=C2=A0 =C2=A0 =C2=A0Roland


=C2=A0 =C2=A0 =C2=A0 > -----Urspr=C3=BCngliche Nachricht-----
=C2=A0 =C2=A0 =C2=A0 > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu
=C2=A0 =C2=A0 =C2=A0<mailto:pkyzivat@alum.mit.edu>]
=C2=A0 =C2=A0 =C2=A0 > Gesendet: Dienstag, 28. November 2017 21:31
=C2=A0 =C2=A0 =C2=A0 > An: Christer Holmberg <christer.holmberg@ericsson.co<= wbr>m
=C2=A0 =C2=A0 =C2=A0<mailto:christer.holmberg@ericsson.com>>; Ro= man Shpount
=C2=A0 =C2=A0 =C2=A0 > <roman@telurix.com <mailto:roman@telurix.com>>
=C2=A0 =C2=A0 =C2=A0 > Cc: Jesske, Roland <R.Jesske@telekom.de
=C2=A0 =C2=A0 =C2=A0<mailto:R.Jesske@telekom.de>>; sipcore@ietf.org
=C2=A0 =C2=A0 =C2=A0<mailto:sipcore@ietf.org>
=C2=A0 =C2=A0 =C2=A0 > Betreff: Re: [sipcore] Session timer fix

=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > On 11/28/17 2:53 PM, Christer Holmberg wrote:
=C2=A0 =C2=A0 =C2=A0 > > Hi,
=C2=A0 =C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 =C2=A0 > >>> 1. What happens when UAC receives a = 2XX INVITE response with
S-T
=C2=A0 =C2=A0 =C2=A0 > >>> that did not match the S-T value neg= otiated by UPDATE
transaction
=C2=A0 =C2=A0 =C2=A0 > during this INVITE transaction?
=C2=A0 =C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 =C2=A0 > >> Error case.
=C2=A0 =C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 =C2=A0 > >>> 2. What happens when UAC receives a = 2XX UPDATE response with
S-T
=C2=A0 =C2=A0 =C2=A0 > >>> that did not match the 2XX response = for the previous UPDATE
=C2=A0 =C2=A0 =C2=A0 > transaction?
=C2=A0 =C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 =C2=A0 > >> Error case.
=C2=A0 =C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 =C2=A0 > >> How do you want to handle these error ca= ses? Two options that
=C2=A0 =C2=A0 =C2=A0I see are:
=C2=A0 =C2=A0 =C2=A0 > >> a. Terminate the dialog (hang up)
=C2=A0 =C2=A0 =C2=A0 > >> b. Issue a new UPDATE to set refresher t= o a known state.
=C2=A0 =C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 =C2=A0 > > Those are two alternatives, yes. I don't= think we need to
=C2=A0 =C2=A0 =C2=A0mandate any
=C2=A0 =C2=A0 =C2=A0 > specific behaviour, as long as we make it clear t= hat an error has
=C2=A0 =C2=A0 =C2=A0occurred and
=C2=A0 =C2=A0 =C2=A0 > it needs to be taken care of SOMEHOW.
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > Or you can just ignore the error and hope for the= best.
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > My intuition tells me that this will rarely cause= a problem. Most
=C2=A0 =C2=A0 =C2=A0of the time a
=C2=A0 =C2=A0 =C2=A0 > device that doesn't support the update will b= e compliant with the
=C2=A0 =C2=A0 =C2=A0update by
=C2=A0 =C2=A0 =C2=A0 > accident. And in a bunch of the remaining cases i= gnoring a
=C2=A0 =C2=A0 =C2=A0conflicting value in
=C2=A0 =C2=A0 =C2=A0 > the nested UPDATE won't matter because both e= nds will settle on
=C2=A0 =C2=A0 =C2=A0what is in
=C2=A0 =C2=A0 =C2=A0 > the 200/INVITE. And the remaining cases will resu= lt in both ends
=C2=A0 =C2=A0 =C2=A0thinking
=C2=A0 =C2=A0 =C2=A0 > they are UAC or UAS. It isn't a problem if th= ey both think they
=C2=A0 =C2=A0 =C2=A0are the UAC,
=C2=A0 =C2=A0 =C2=A0 > since then both will attempt to refresh. It is on= ly a problem if
=C2=A0 =C2=A0 =C2=A0they both think
=C2=A0 =C2=A0 =C2=A0 > they are UAS, since that is the only case when th= e session won't
be
=C2=A0 =C2=A0 =C2=A0 > refreshed. If that happens, is it worse than havi= ng had the call
=C2=A0 =C2=A0 =C2=A0fail?
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 > If need be we can work through all the cases. But= there are quite
=C2=A0 =C2=A0 =C2=A0a lot of
=C2=A0 =C2=A0 =C2=A0 > them.
=C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul



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

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



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


___= __________
Roman Shpount

On Tue, Nov 28, 2017 at 7:46 PM, <R.Jes= ske@telekom.de> wrote:

Hi Roman,<= /p>

=C2=A0

Invite with S-E 3600 is sent by= the UAC. Proxy let INVITE pass towards UAS.

1st negotiation is ongoing.<= /u>

18x/PRACK/200OK(PRACK) is excha= nged.

=C2=A0

Now UAS is sending UPDATE with = a supported timer and Proxy adds S-E due to local policy with S-E 1800.<= /u>

=C2=A0

So what will the UAC do. The pr= oxy has added the S-E.

UAC (Which has sent the INVITE)= could ignore and send 200 OK without any S-E. i.e. ignoring UPDATE.

=C2=A0

In this case, what is the then = proxy doing? Passing 200OK w/o S-E or may it add an S-E again? Assuming it = adds S-E 1800 because it remembers that the UPDATE was received with suppor= ted timer.

=C2=A0

What does the UAS do? Ignoring = the 200 OK with SE or accepting?

=C2=A0

And then what will the UAS do? = Sending 200 OK (INVITE) with S-E 3600 as proposed by the INVITE, because th= e UAS is ignoring the 200 OK (UPDATE) with S-E 1800?

=C2=A0

Or do you think that his is a w= rong implementation.

=C2=A0

Best Regards

=C2=A0

Roland

=C2=A0

=C2=A0

=C2=A0

Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Roman Shpount
Gesendet: Mittwoch, 29. November 2017 00:07
An: Jesske, Roland <R.Jesske@telekom.de>
Cc: SIPCORE <sipcore@ietf.org>


Betreff: Re: [sipcore] Session timer fix

=C2=A0

Roland,

=C2=A0

Please provide the exact scenario. What you seem to = be describing are misconfigured proxies or clients that do not follow exist= ing specifications.

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

On Tue, Nov 28, 2017 at 5:33 PM, <R.Jesske@telekom.de> wrote= :

Hi Paul,
We have different issues where we have look on.
And we see that we have UPDATE with an S-T causing a lot of trouble.
This is dependent on different use cases.
One is that the UA does not support UPDATE.
Yes that is true.
But one of the main problems are the proxies in between.
Either proxies do not react which is OK.
And the UAC interpreting the 200OK.
Also the direction of the UPDATE is important.
Also the behavior of the proxy. We have seen proxies adding S-T to the UPDA= TE due to the fact that session timer supported is set. The S-T values wher= e different to that set by the UAC.

So as you said we can identify all use cases. And I think that is what we n= eed or real clear rules for UAC/UAS and Proxy.

Best Regards

Roland


> -----Urspr=C3=BCngliche Nachricht-----
> Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Gesendet: Dienstag, 28. November 2017 21:31
> An: Christer Holmberg <christer.holmberg@ericsson.com>; Roman = Shpount
> <roman@telur= ix.com>
> Cc: Jesske, Roland <R.Jesske@telekom.de>; sipcore@ietf.org<= br> > Betreff: Re: [sipcore] Session timer fix

>
> On 11/28/17 2:53 PM, Christer Holmberg wrote:
> > Hi,
> >
> >>> 1. What happens when UAC receives a 2XX INVITE response w= ith S-T
> >>> that did not match the S-T value negotiated by UPDATE tra= nsaction
> during this INVITE transaction?
> >>
> >> Error case.
> >>
> >>> 2. What happens when UAC receives a 2XX UPDATE response w= ith S-T
> >>> that did not match the 2XX response for the previous UPDA= TE
> transaction?
> >>
> >> Error case.
> >>
> >> How do you want to handle these error cases? Two options that= I see are:
> >> a. Terminate the dialog (hang up)
> >> b. Issue a new UPDATE to set refresher to a known state.
> >
> > Those are two alternatives, yes. I don't think we need to man= date any
> specific behaviour, as long as we make it clear that an error has occu= rred and
> it needs to be taken care of SOMEHOW.
>
> Or you can just ignore the error and hope for the best.
>
> My intuition tells me that this will rarely cause a problem. Most of t= he time a
> device that doesn't support the update will be compliant with the = update by
> accident. And in a bunch of the remaining cases ignoring a conflicting= value in
> the nested UPDATE won't matter because both ends will settle on wh= at is in
> the 200/INVITE. And the remaining cases will result in both ends think= ing
> they are UAC or UAS. It isn't a problem if they both think they ar= e the UAC,
> since then both will attempt to refresh. It is only a problem if they = both think
> they are UAS, since that is the only case when the session won't b= e
> refreshed. If that happens, is it worse than having had the call fail?=
>
> If need be we can work through all the cases. But there are quite a lo= t of
> them.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul

=C2=A0


--f403045d2648167446055f237219-- From nobody Wed Nov 29 10:48:56 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 26FB512420B for ; Wed, 29 Nov 2017 10:48:54 -0800 (PST) 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LYhru3gSR8II for ; Wed, 29 Nov 2017 10:48:52 -0800 (PST) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 D9BED126C22 for ; Wed, 29 Nov 2017 10:48:51 -0800 (PST) Received: by mail-pl0-x22f.google.com with SMTP id bi12so2617340plb.6 for ; Wed, 29 Nov 2017 10:48:51 -0800 (PST) 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=UdD4snKtKrr/3/U+pnLKBUSwPiEbAu5jzSU2uLaOVEA=; b=VI3F3iTSW7a+5+JoQDMz6pblEFuSU1vqg1JGyryHiHxbak+5kL+hXZlpQ6au82IwsZ XOLQQNSQiGdR2un1UCu1FHtC+OAIbDYnxVfhWO8Pe/8kwGfUVeXHHYmxo8+j+E1zjG0C sOmiUdsOPHqo56kegTpaxyMqHbwmSFyKL9cDoBbADCik/vvCgaani7Xk4gTkAUmOq329 vcyjp6hEH3cADmkzHKsMXMAGjj7crMuyWBNcszVGWNUk/tkOPW8/GZj7Y7PH+wgpaos3 ysmR2aVtT2qDvgs7fwitazVZ43sL734+GivYj84Uz0yYHTPPEqHSuAC2xPBS6pagTHGK wwZQ== 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=UdD4snKtKrr/3/U+pnLKBUSwPiEbAu5jzSU2uLaOVEA=; b=LOI2KgSXvTeZMmOqYheh1gV9ms6B5dTn6FRosil6y7FgavPShCcTRO4zm9N1GnQRlb CZ/se8DqzzCh2gU1aUXAt3mXyfvuDKBU76h4cUeZo3hWt0KYV+fxQ3Nc7+gq+v9b6vXn vGAF93Wn0Sx2scGvcR6LvhVntOh1DpNd2eWEIc+hSJvu2yWkZjuD+4Zekc1yIgida1kY J3z4vvuYbjMHbfAgM6Z2y7vhP8UWB2IZDNOajpXXlfax06WR7lMXLwjYflC4ttAG0KVz y57ug8VMWhc7voG7j1ihfZjgkCEQtj0xrj03XB3r6xzILP4VvaZRNJtHJWJbeKx8va3I 0F6g== X-Gm-Message-State: AJaThX6LY+fAPEJDgxcvQxqjhOpNLehcLsLyPow6fJhPXyr5DHMJ7MJR xX3931toLriXPD3OhuiOKCvvjoyE X-Google-Smtp-Source: AGs4zMbQ/PBq+b1N82ysqkmH7xqr3jme+Y9fug7MIp2WjVrgQm0wPjQa+HC0HP3VIHBiIeuoN1osog== X-Received: by 10.84.202.163 with SMTP id x32mr3692771pld.55.1511981331247; Wed, 29 Nov 2017 10:48:51 -0800 (PST) Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com. [74.125.83.45]) by smtp.gmail.com with ESMTPSA id q13sm3828930pgt.73.2017.11.29.10.48.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 10:48:50 -0800 (PST) Received: by mail-pg0-f45.google.com with SMTP id j4so1890036pgp.1 for ; Wed, 29 Nov 2017 10:48:50 -0800 (PST) X-Received: by 10.98.245.68 with SMTP id n65mr3931294pfh.113.1511981329889; Wed, 29 Nov 2017 10:48:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Wed, 29 Nov 2017 10:48:48 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6BFF9657@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFE2C4@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> From: Roman Shpount Date: Wed, 29 Nov 2017 13:48:48 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "R.Jesske@telekom.de" Cc: SIPCORE Content-Type: multipart/alternative; boundary="001a113b0aa4133efe055f23963c" 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: Wed, 29 Nov 2017 18:48:54 -0000 --001a113b0aa4133efe055f23963c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Roland, Two more comments about your original scenario: 4. Proxy is not behaving in a consistent manner. If proxy needs expires the dialog after 1800 seconds, it should reduce the S-E value in INVITE to 1800 seconds. If proxy expires the dialog after 3600 seconds, it should insert 3600 in UPDATE. 5. UAS knows the expiration time for the dialog when it processed the request. It should respond with the dialog refresh value, not the value from request. Since, in your example, dialog expiration time got set to 1800 by UPDATE transaction, it should respond with 1800 to both UPDATE and INVITE regardless of the S-E value in INVITE. If you look at the rules that we are proposing, you will see that if either UAC or UAS followed these rules, the problem would not occur. Regards, _____________ Roman Shpount On Tue, Nov 28, 2017 at 8:27 PM, wrote: > Hi Roman, > Yes that is what I would like to see but reality is something other. > > So the UAC/UAS could be some border element within your network. In ours > the S-E will be negotiated by the first proxy within the network. > We have interconnection situations where we have no influence on other > proxies. > > That what I have described is conformant with RFC4028. > > See below > > >Von: Roman Shpount [mailto:roman@telurix.com] > >Gesendet: Mittwoch, 29. November 2017 02:04 > >An: Jesske, Roland > >Cc: SIPCORE > >Betreff: Re: [sipcore] Session timer fix > > > >Roland, > > > >This is not exactly wrong but this User Agent is asking for trouble and > should be fixed. > > > > >1. UAC should not send INVITE with Session Expires header unless it was > previously negotiated. > >User Agents do not need Session Expires, it was designed for > >proxies to deal with dialog expiration. User Agent can send re-INVITE or > UPDATE > >at any time on its own to check the presence of the dialog. There is no > need > >negotiate this. > > [RJ] Section 7.1 ... A UAC MAY include the Min-SE header field in the > initial INVITE > request.... > > >2. If UAC does send Session Expires in the INVITE (sometimes is needed b= y > B2BUA with limited state), > > it should add the same S-E header to UPDATE -- this will > >prevent proxy from adding S-E to UPDATE. *If you are going to fix one > thing, fix this.* > > [RJ] In this case the UPDATE is sent by the UAS with a supported "timer" > so the proxy has added the S-E. > Yes I agree that the UPDATE sent should have then the S-E but this needs > to be clarified. > > >3. Proxy should never modify S-E in the response. This is against the > specifications. > > [RJ] There is no modification within the 200 OK since this use case > assumes that the UA does not add any S-E because of ignoring the UPDATE. > But the Proxy is following this rule out of RFC4028 8.1: > > ...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.... > > So the Proxy remembers the value it has put by itself into the UPDATE. > > > >For User Agent which got two responses with different Session Timer valu= es > >,it is safe to pick the smaller if it is a refresher or larger, if other > UA is a refresher. > > If it got responses that have different refresher values, it is safe to > assume that UA is the refresher. > > Also, after INVITE transaction completes, when in doubt, UA > >can send a new UPDATE without refresher value and S-E header to sort thi= s > thing out. > > Regards, > > > > _____________ > Roman Shpount > > On Tue, Nov 28, 2017 at 7:46 PM, wrote: > Hi Roman, > > Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards UA= S. > 1st negotiation is ongoing. > 18x/PRACK/200OK(PRACK) is exchanged. > > Now UAS is sending UPDATE with a supported timer and Proxy adds S-E due t= o > local policy with S-E 1800. > > So what will the UAC do. The proxy has added the S-E. > UAC (Which has sent the INVITE) could ignore and send 200 OK without any > S-E. i.e. ignoring UPDATE. > > In this case, what is the then proxy doing? Passing 200OK w/o S-E or may > it add an S-E again? Assuming it adds S-E 1800 because it remembers that > the UPDATE was received with supported timer. > > What does the UAS do? Ignoring the 200 OK with SE or accepting? > > And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 as > proposed by the INVITE, because the UAS is ignoring the 200 OK (UPDATE) > with S-E 1800? > > Or do you think that his is a wrong implementation. > > Best Regards > > Roland > > > > Von: sipcore [mailto:mailto:sipcore-bounces@ietf.org] Im Auftrag von > Roman Shpount > Gesendet: Mittwoch, 29. November 2017 00:07 > An: Jesske, Roland > Cc: SIPCORE > > Betreff: Re: [sipcore] Session timer fix > > Roland, > > Please provide the exact scenario. What you seem to be describing are > misconfigured proxies or clients that do not follow existing specificatio= ns. > > Regards, > _____________ > Roman Shpount > > On Tue, Nov 28, 2017 at 5:33 PM, wrote: > Hi Paul, > We have different issues where we have look on. > And we see that we have UPDATE with an S-T causing a lot of trouble. > This is dependent on different use cases. > One is that the UA does not support UPDATE. > Yes that is true. > But one of the main problems are the proxies in between. > Either proxies do not react which is OK. > And the UAC interpreting the 200OK. > Also the direction of the UPDATE is important. > Also the behavior of the proxy. We have seen proxies adding S-T to the > UPDATE due to the fact that session timer supported is set. The S-T value= s > where different to that set by the UAC. > > So as you said we can identify all use cases. And I think that is what we > need or real clear rules for UAC/UAS and Proxy. > > Best Regards > > Roland > > > > -----Urspr=C3=BCngliche Nachricht----- > > Von: Paul Kyzivat [mailto:mailto:pkyzivat@alum.mit.edu] > > Gesendet: Dienstag, 28. November 2017 21:31 > > An: Christer Holmberg ; Roman > Shpount > > > > Cc: Jesske, Roland ; mailto:sipcore@ietf.or= g > > Betreff: Re: [sipcore] Session timer fix > > > > On 11/28/17 2:53 PM, Christer Holmberg wrote: > > > Hi, > > > > > >>> 1. What happens when UAC receives a 2XX INVITE response with S-T > > >>> that did not match the S-T value negotiated by UPDATE transaction > > during this INVITE transaction? > > >> > > >> Error case. > > >> > > >>> 2. What happens when UAC receives a 2XX UPDATE response with S-T > > >>> that did not match the 2XX response for the previous UPDATE > > transaction? > > >> > > >> Error case. > > >> > > >> How do you want to handle these error cases? Two options that I see > are: > > >> a. Terminate the dialog (hang up) > > >> b. Issue a new UPDATE to set refresher to a known state. > > > > > > Those are two alternatives, yes. I don't think we need to mandate any > > specific behaviour, as long as we make it clear that an error has > occurred and > > it needs to be taken care of SOMEHOW. > > > > Or you can just ignore the error and hope for the best. > > > > My intuition tells me that this will rarely cause a problem. Most of th= e > time a > > device that doesn't support the update will be compliant with the updat= e > by > > accident. And in a bunch of the remaining cases ignoring a conflicting > value in > > the nested UPDATE won't matter because both ends will settle on what is > in > > the 200/INVITE. And the remaining cases will result in both ends thinki= ng > > they are UAC or UAS. It isn't a problem if they both think they are the > UAC, > > since then both will attempt to refresh. It is only a problem if they > both think > > they are UAS, since that is the only case when the session won't be > > refreshed. If that happens, is it worse than having had the call fail? > > > > If need be we can work through all the cases. But there are quite a lot > of > > them. > > > > Thanks, > > Paul > > > --001a113b0aa4133efe055f23963c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roland,

Two more comments about your or= iginal scenario:

4. Proxy is not behaving in a con= sistent manner. If proxy needs expires the dialog after 1800 seconds, it sh= ould reduce the S-E value in INVITE to 1800 seconds. If proxy expires the d= ialog after 3600 seconds, it should insert 3600 in UPDATE.

5. UAS knows the expiration time for the dialog when it processed = the request. It should respond with the dialog refresh value, not the value= from request. Since, in your example, dialog expiration time got set to 18= 00 by UPDATE transaction, it should respond with 1800 to both UPDATE and IN= VITE regardless of the S-E value in INVITE.

If you= look at the rules that we are proposing, you will see that if either UAC o= r UAS followed these rules, the problem would not occur.

Regards,

_______= ______
Roman Shpount

On Tue, Nov 28, 2017 at 8:27 PM, <R.Jes= ske@telekom.de> wrote:
Hi R= oman,
Yes that is what I would like to see but reality is something other.

So the UAC/UAS could be some border element within your network. In ours th= e S-E will be negotiated by the first proxy within the network.
We have interconnection situations where we have no influence on other prox= ies.

That what I have described is conformant with RFC4028.

See below

>Von: Roman Shpount [mailto:roman@t= elurix.com]
>Gesendet: Mittwoch, 29. November 2017 02:04
>An: Jesske, Roland <R.Jesske@telekom.de>
>Cc: SIPCORE <sipcore@ietf.org>
>Betreff: Re: [sipcore] Session timer fix
>
>Roland,
>
>This is not exactly wrong but this User Agent i= s asking for trouble and should be fixed.
=C2=A0>

>1. UAC should not send INVITE with Session Expires=C2=A0header unless i= t was previously negotiated.
>User Agents do not need Session Expires, it was designed for
>proxies to deal with dialog expiration. User Agent can send re-INVITE o= r UPDATE
>at any time on its own to check the presence of the dialog. There is no= need
>negotiate this.

[RJ] Section 7.1 ... A UAC MAY include the Min-SE header field in th= e initial INVITE
=C2=A0 =C2=A0request....

>2. If UAC does send Session Expires=C2=A0in the INVITE (sometimes is ne= eded by B2BUA with limited state),
> it should add the same S-E header to UPDATE -- this will
>prevent proxy from adding S-E to UPDATE. *If you are going to fix one t= hing, fix this.*

[RJ] In this case the UPDATE is sent by the UAS with a supported &qu= ot;timer" so the proxy has added the S-E.
Yes I agree that the UPDATE sent should have then the S-E but this needs to= be clarified.

>3. Proxy should never modify S-E in the response. This is against the s= pecifications.

[RJ] There is no modification within the 200 OK since this use case = assumes that the UA does not add any S-E because of ignoring the UPDATE. But the Proxy is following this rule out of RFC4028 8.1:

=C2=A0 ...Because there is no Session-Expires or Require header field in th= e
=C2=A0 =C2=A0response, the proxy knows that it is the firs= t session-timer-aware
=C2=A0 =C2=A0proxy to receive the response.=C2=A0 This proxy MUST insert a<= br> =C2=A0 =C2=A0Session-Expires header field into the response with the value = it
=C2=A0 =C2=A0remembered from the forwarded request....

So the Proxy remembers the value it has put by itself into the UPDATE.


>For User Agent which got two responses with different Session Timer val= ues
>,it is safe to pick the smaller if it is a refresher or larger, = if other UA is a refresher.
> If it got responses that have different refresher val= ues, it is safe to assume that UA is the refresher.
> Also, after INVITE transaction completes, when in doubt, UA
>can send a new UPDATE without refresher value and S-E header to sort th= is thing out.

Regards,



_____________
Roman Shpount

On Tue, Nov 28, 2017 at 7:46 PM, <mailto:R.Jesske@telekom.de> wrote:
Hi Roman,
=C2=A0
Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards UAS.=
1st negotiation is ongoing.
18x/PRACK/200OK(PRACK) is exchanged.
=C2=A0
Now UAS is sending UPDATE with a supported timer and Proxy adds S-E due to = local policy with S-E 1800.
=C2=A0
So what will the UAC do. The proxy has added the S-E.
UAC (Which has sent the INVITE) could ignore and send 200 OK without any S-= E. i.e. ignoring UPDATE.
=C2=A0
In this case, what is the then proxy doing? Passing 200OK w/o S-E or may it= add an S-E again? Assuming it adds S-E 1800 because it remembers that the = UPDATE was received with supported timer.
=C2=A0
What does the UAS do? Ignoring the 200 OK with SE or accepting?
=C2=A0
And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 as pro= posed by the INVITE, because the UAS is ignoring the 200 OK (UPDATE) with S= -E 1800?
=C2=A0
Or do you think that his is a wrong implementation.
=C2=A0
Best Regards
=C2=A0
Roland
=C2=A0
=C2=A0
=C2=A0
Von: sipcore [mailto:mailto:sipcore-bounces@ietf.org] Im Auf= trag von Roman Shpount
Gesendet: Mittwoch, 29. November 2017 00:07
An: Jesske, Roland <mailto:R.Jesske@telekom.de>
Cc: SIPCORE <mailto:sipcore@ietf.org= >

Betreff: Re: [sipcore] Session timer fix
=C2=A0
Roland,
=C2=A0
Please provide the exact scenario. What you seem to be describing are misco= nfigured proxies or clients that do not follow existing specifications.
=C2=A0
Regards,
_____________
Roman Shpount
=C2=A0
On Tue, Nov 28, 2017 at 5:33 PM, <mailto:R.Jesske@telekom.de> wrote:
Hi Paul,
We have different issues where we have look on.
And we see that we have UPDATE with an S-T causing a lot of trouble.
This is dependent on different use cases.
One is that the UA does not support UPDATE.
Yes that is true.
But one of the main problems are the proxies in between.
Either proxies do not react which is OK.
And the UAC interpreting the 200OK.
Also the direction of the UPDATE is important.
Also the behavior of the proxy. We have seen proxies adding S-T to the UPDA= TE due to the fact that session timer supported is set. The S-T values wher= e different to that set by the UAC.

So as you said we can identify all use cases. And I think that is what we n= eed or real clear rules for UAC/UAS and Proxy.

Best Regards

Roland


> -----Urspr=C3=BCngliche Nachricht-----
> Von: Paul Kyzivat [mailto:mailto:= pkyzivat@alum.mit.edu] > Gesendet: Dienstag, 28. November 2017 21:31
> An: Christer Holmberg <mailto:christer.holmberg@ericsson.com>; Roman Shpo= unt
> <mailto:roman@telurix.com&= gt;
> Cc: Jesske, Roland <mailto:R= .Jesske@telekom.de>; mailto:sipc= ore@ietf.org
> Betreff: Re: [sipcore] Session= timer fix
>
> On 11/28/17 2:53 PM, Christer Holmberg wrote:
> > Hi,
> >
> >>> 1. What happens when UAC receives a 2XX INVITE response w= ith S-T
> >>> that did not match the S-T value negotiated by UPDATE tra= nsaction
> during this INVITE transaction?
> >>
> >> Error case.
> >>
> >>> 2. What happens when UAC receives a 2XX UPDATE response w= ith S-T
> >>> that did not match the 2XX response for the previous UPDA= TE
> transaction?
> >>
> >> Error case.
> >>
> >> How do you want to handle these error cases? Two options that= I see are:
> >> a. Terminate the dialog (hang up)
> >> b. Issue a new UPDATE to set refresher to a known state.
> >
> > Those are two alternatives, yes. I don't think we need to man= date any
> specific behaviour, as long as we make it clear that an error has occu= rred and
> it needs to be taken care of SOMEHOW.
>
> Or you can just ignore the error and hope for the best.
>
> My intuition tells me that this will rarely cause a problem. Most of t= he time a
> device that doesn't support the update will be compliant with the = update by
> accident. And in a bunch of the remaining cases ignoring a conflicting= value in
> the nested UPDATE won't matter because both ends will settle on wh= at is in
> the 200/INVITE. And the remaining cases will result in both ends think= ing
> they are UAC or UAS. It isn't a problem if they both think they ar= e the UAC,
> since then both will attempt to refresh. It is only a problem if they = both think
> they are UAS, since that is the only case when the session won't b= e
> refreshed. If that happens, is it worse than having had the call fail?=
>
> If need be we can work through all the cases. But there are quite a lo= t of
> them.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul
=C2=A0


--001a113b0aa4133efe055f23963c-- From nobody Wed Nov 29 11:22: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 D92C41289B5 for ; Wed, 29 Nov 2017 11:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 QAL5iaq528SH for ; Wed, 29 Nov 2017 11:22:50 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 AE2E012896F for ; Wed, 29 Nov 2017 11:22:50 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id s197so1919972vkh.11 for ; Wed, 29 Nov 2017 11:22:50 -0800 (PST) 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=2qgB58b7PTfmZabMImzRtnqbchOL90n/9Dh1Nv1zQag=; b=JlqTBtk+JtNAJ9OcPh4UhI/iEY8+BTzy1gQdVXZ8iDgnWBerqwyJMquObLckplKMLi SILoPBmq7u+SiYeuTvbhnQ1KAdxegK8+wzE+goDu3gHFp9pGlMg7ULagpyg2GI+Ls4fl D4RhdJZLkdzdXb4OgUyOZAkdgALRc6uteMy41SdYdcTUAVfk8/o0aPHa4m2z3iqd91dv mwoX01QiXIM3RQ9u0MegjNaXrybNSAA8+LlhCB2hvEThBr5mUxqtBtkpqDXxieOvuox3 7wk7oY7OgGgtVmmNRnU5g7cVCjEblrgM3G2Zs8CLBbAlkLgC8QUyZqqyb7E7Dhol7jq0 5eYQ== 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=2qgB58b7PTfmZabMImzRtnqbchOL90n/9Dh1Nv1zQag=; b=KIi0dbXi7TwmjWQvnM1X/K3mDTzsLTk1kV0DH/+6AYPTuO04rmn38sR035nVFnnQZP kT+ojyr6SBTXAtGMRNuPx3VBkkhCb5zRuW2o325yJr27WVfm8oMQnPSVIORDZrxP/cOa yHhICXpALk5S0bLzilNUbD5bLQ1H5F3qVEr9hifTCKD4t7v06IsGpZRul4pyYzwGi15N Jn4mobW1wps/tVY1Avugy2t9xhJGaMz7OffFWLkqbp6g7p/j86kN/RfcC7kEFtsLSLco bl5BqxHvR9mpy2zbA+lYf/x7QD2cPZjJ6K1WorsZALrQ6gwg/q0KD4aQaYArDbALcHe8 wiYA== X-Gm-Message-State: AJaThX4llXOlVaRIvSs3k5RMpi7bUuwgMzBh5nKMqMEIt1GBiGqepxRP oqHS64RLC6EJT7Ol94QFIgN/DoCjCUgcd89mjcbf3g== X-Google-Smtp-Source: AGs4zMb0FTHxjqTHMwt2cs6jH2yaBEf92uwETqD+bEDBs0RnyUxS9MHmBghwYGXSohY0NhfHmj+IAEuiEzDSuDo7L3o= X-Received: by 10.31.5.5 with SMTP id 5mr3197742vkf.47.1511983369690; Wed, 29 Nov 2017 11:22:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.68.133 with HTTP; Wed, 29 Nov 2017 11:22:49 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Wed, 29 Nov 2017 14:22:49 -0500 Message-ID: To: Brian Rosen Cc: SIPCORE Content-Type: multipart/alternative; boundary="001a1143dd12a82404055f240f94" Archived-At: Subject: Re: [sipcore] Call For Adoption 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: Wed, 29 Nov 2017 19:22:53 -0000 --001a1143dd12a82404055f240f94 Content-Type: text/plain; charset="UTF-8" I think that this is a useful document, and I support adopting it as a WG document. Regards, Rifaat On Wed, Nov 29, 2017 at 8:52 AM, Brian Rosen wrote: > We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore > document. Please provide comments by December 13. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a1143dd12a82404055f240f94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that this is a useful document, and I support adop= ting it as a WG document.

Regards,
=C2=A0Rifaa= t


On Wed, Nov 29, 2017 at 8:52 AM, Brian Rosen &= lt;br@brianrosen.net= > wrote:
We propose to adop= t draft-holmberg-sipcore-sip-push as a sipcore document.=C2=A0 Please = provide comments by December 13.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--001a1143dd12a82404055f240f94-- From nobody Wed Nov 29 12:58: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 A1EE6126BF6 for ; Wed, 29 Nov 2017 12:58:43 -0800 (PST) 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 CWrhVREgcvaW for ; Wed, 29 Nov 2017 12:58:41 -0800 (PST) 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 4E19D1200CF for ; Wed, 29 Nov 2017 12:58:40 -0800 (PST) X-AuditID: c1b4fb2d-139999c0000036aa-6d-5a1f1f7e490b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.98.13994.E7F1F1A5; Wed, 29 Nov 2017 21:58:39 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Wed, 29 Nov 2017 21:58:38 +0100 From: Christer Holmberg To: Brian Rosen , SIPCORE Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push Thread-Index: AQHTaRlSj083iGbuAUSRkgieoJz4pqMr12iQ Date: Wed, 29 Nov 2017 20:58:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C02DB78@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7lm69vHyUwbtZHBZP709js/j6YxOb A5PH/W9/2T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx8cljpoLFLBW/Lh9hbWC8ztzFyMkhIWAi cXHNGpYuRi4OIYHDjBLvF09lhnCWMEq03PkI5HBwsAlYSHT/0wYxRQTsJY6cVQHpFRbwkJg9 fzcbiC0i4Cmx9+JHJgjbSGLb8k1g81kEVCV+Hl7NCtLKK+Ar8fZ1LUhYSMBR4tDSi+wgNqeA k8SVaZPByhkFxCS+n1oDNoZZQFzi1pP5TBBnCkgs2XMe6mRRiZeP/7FC2EoSK7ZfYoSo15FY sPsTG4StLbFs4Wuwel4BQYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUVo2hxanFxbrqRsV5q UWZycXF+nl5easkmRmAsHNzyW3cH4+rXjocYBTgYlXh4w7jko4RYE8uKK3MPMUpwMCuJ8Crs losS4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvSkzdKSCA9sSQ1OzW1ILUIJsvEwSnVwLgo+YzK 9eCbAl2rD0//axj66M8Hi9DafpuOGJEGhfu6cRynuBbFJz/TOundVdPCvN+gZdvJvXorsq3Z z5wSnu+XWPJLomxZ4IOKol/pxamx/QV/LJinqZeUrbzf+DMzNf1RyiPX7fUdHrtnrrm/aes9 /Ry+dbO/tj773PXwkvcj1Wl/rTYc6FZiKc5INNRiLipOBACTmxKHgQIAAA== Archived-At: Subject: Re: [sipcore] Call For Adoption 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: Wed, 29 Nov 2017 20:58:44 -0000 I obviously support this :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 29 November 2017 15:52 To: SIPCORE Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. = Please provide comments by December 13. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Nov 29 13:05: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 F0268126C83 for ; Wed, 29 Nov 2017 13:05:43 -0800 (PST) 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 Ow-52wLqUtKR for ; Wed, 29 Nov 2017 13:05:42 -0800 (PST) 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 1FDA4126BFD for ; Wed, 29 Nov 2017 13:05:42 -0800 (PST) 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 vATKvLn7043114; Wed, 29 Nov 2017 16:05:38 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2ej3p019ch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Nov 2017 16:05:37 -0500 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 vATL5amt023849; Wed, 29 Nov 2017 16:05:37 -0500 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 vATL5Rfa023663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Nov 2017 16:05:30 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 29 Nov 2017 21:05:10 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.10]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 16:05:10 -0500 From: "DOLLY, MARTIN C" To: Christer Holmberg CC: Brian Rosen , SIPCORE Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push Thread-Index: AQHTaRlSGGlRuQvTXUyX2lRozFfEoqMr12iQgAAB4O8= Date: Wed, 29 Nov 2017 21:05:09 +0000 Message-ID: <3A3CE3A5-28EF-40D2-8704-FEA60B9392A4@att.com> References: , <7594FB04B1934943A5C02806D1A2204B6C02DB78@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C02DB78@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3A3CE3A528EF40D28704FEA60B9392A4attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-29_07:, , 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-1709140000 definitions=main-1711290270 Archived-At: Subject: Re: [sipcore] Call For Adoption 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: Wed, 29 Nov 2017 21:05:44 -0000 --_000_3A3CE3A528EF40D28704FEA60B9392A4attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable T supports Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Nov 29, 2017, at 3:58 PM, Christer Holmberg > wrote: I obviously support this :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 29 November 2017 15:52 To: SIPCORE > Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. = Please provide comments by December 13. _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D --_000_3A3CE3A528EF40D28704FEA60B9392A4attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable T supports

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com

On Nov 29, 2017, at 3:58 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I obviously support this :)

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:sip= core-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: 29 November 2017 15:52
To: SIPCORE <sipcore@ietf.org<= /a>>
Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push<= /span>

We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore docu= ment.  Please provide comments by December 13.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9= v8uCSSQhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&am= p;s=3DhED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&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=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9= v8uCSSQhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&am= p;s=3DhED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&e=3D
--_000_3A3CE3A528EF40D28704FEA60B9392A4attcom_-- From nobody Wed Nov 29 13:22: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 7E727126B6E for ; Wed, 29 Nov 2017 13:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, 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=proximus.com header.b=a+Dy1X0f; dkim=pass (1024-bit key) header.d=proximuscorp.onmicrosoft.com header.b=pEjXww3d 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 nyJxolyBmhwG for ; Wed, 29 Nov 2017 13:22:14 -0800 (PST) Received: from mx18.belgacom.be (mx18.belgacom.be [195.13.15.238]) (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 1D60A1200CF for ; Wed, 29 Nov 2017 13:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=proximus.com; i=@proximus.com; q=dns/txt; s=dkim; t=1511990534; x=1543526534; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NQbXW66sug66oyX6bLDAz79Jf/4IkBWbsEbnB3NxNf0=; b=a+Dy1X0f6zVNAzyrvYjdg5idnY0kc2QTFr/a8g9ih+Iw8InIJVbJYUz1 PMkBudCA7GkVUJwN2D09ACKhW/4AsMkGdjt/fUbKw+EchnpVlpmaCelNC NrVmkgmY3Yo3i7Xlu6dZyLl+zZc4wOYlSc1v2Kdlz76heKiskklNZQ77N I=; X-IronPort-AV: E=Sophos; i="5.45,339,1508796000"; d="scan'208,217"; a="29518372" Received: from a07584.bgc.net ([10.120.80.100]) by mx18.belgacom.be with ESMTP; 29 Nov 2017 22:22:09 +0100 X-TM-IMSS-Message-ID: <248d0b420009f30d@proximus.com> Received: from A04026.BGC.NET ([10.121.135.23]) by proximus.com ([10.120.80.100]) with ESMTP (TREND IMSS SMTP Service 7.5) id 248d0b420009f30d ; Wed, 29 Nov 2017 22:22:09 +0100 Received: from A07638.BGC.NET (10.121.80.46) by A04026.BGC.NET (10.121.135.23) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 29 Nov 2017 22:22:09 +0100 Received: from A07637.BGC.NET (10.120.80.128) by A07638.BGC.NET (10.121.80.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 29 Nov 2017 22:22:09 +0100 Received: from A07624.bgc.net (10.28.29.230) by A07637.BGC.NET (10.120.80.128) 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; Wed, 29 Nov 2017 22:22:08 +0100 Received: from EUR01-VE1-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; Wed, 29 Nov 2017 22:22:01 +0100 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=gZpv5MoSS0yd6OvQkbqte5gF8DXlUv7nNAygn7nQhSc=; b=pEjXww3d990IREZA0a1zAoqJq1nAgUDb1dm/s8KRtBH+uDIEvANV5mU6OOjKLCn17mkyzovk4Itm+BNdtjC60z4VUD6r3xD6Id2kkU4EYdvIAHrSMMN58Z8pmQCCt5zlzosPDwilxNA4PqgMAX4b18Swznh9c/ZsMgONMMWV9q0= Received: from HE1PR0801MB1884.eurprd08.prod.outlook.com (10.168.94.15) by HE1PR0801MB1883.eurprd08.prod.outlook.com (10.168.94.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 21:22:07 +0000 Received: from HE1PR0801MB1884.eurprd08.prod.outlook.com ([fe80::4c96:c7f3:4ece:b6dc]) by HE1PR0801MB1884.eurprd08.prod.outlook.com ([fe80::4c96:c7f3:4ece:b6dc%15]) with mapi id 15.20.0260.006; Wed, 29 Nov 2017 21:22:07 +0000 From: "VAN GEEL Jan (SPC/CSP)" To: SIPCORE Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push Thread-Index: AQHTaRlS3MlR2joZ1U6NAS4xdupq7qMr12iQgAAB34CAAASrwA== Date: Wed, 29 Nov 2017 21:22:07 +0000 Message-ID: References: , <7594FB04B1934943A5C02806D1A2204B6C02DB78@ESESSMB109.ericsson.se> <3A3CE3A5-28EF-40D2-8704-FEA60B9392A4@att.com> In-Reply-To: <3A3CE3A5-28EF-40D2-8704-FEA60B9392A4@att.com> 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: [12.69.88.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0801MB1883; 6:Ua+0TdfLWgKlri1BmokRipQMTszpZ27kERAH/1UTdc6uNNCvi0yr3KFCB9g1Wpu4vUEXcSQXkO4bxii1SaaIUF1qbH6gz8OB52W9jlq8IuSNI4p5GSZ/dL3zWGS9jflrRyrjik5FJSga334NmYn5VFHT8U2CJ1OQGD2PJvLCnEP52hl2b708njlS41qJbssrByLYuSiOBSpmH6NPkfcoqCfU7Bqn8RAckKFSbnR094r4rWU18pl0Hueb0/XCOMBNqPd6wFdnFFoscBuie7yPJOsiQ/V38B08pQ2m1Y5pTC7ONwWaT42FD1iwt6ZImcGUrGGw6PwQKZYuH2RyFUboFeQNVewGTK+pvyz3Cqi2hdo=; 5:6A4+7CZ34Gm3QKexSNh16qk9oUTekY34k6Uq8BmzYbkLrPKSisxuZhQIdDrQ6sj1hTwkPS7GzGpXyIBAvyYYBS9wPHh3cUhad81HKjCJHktYo2LNVTfhwMnH5pZMoqfPM4nAXe+gAveGroNXYGu6GeZO/0Z2QHmJDxa4w3Svz+M=; 24:U6/C9FXxd6REdxMhrrHGQJMPCWZHMuGhS54htfMc27RfmWvicZtqHvufpJ+/6Lh1LWaHdgSFwdDQW0+iOclXsheYrEl/GSnba7a5VI108Uc=; 7:C0EjQkIY/eFdAFBuqR62ZVgJpKlezRrlAyd2e1/GbakTVI/x1fravW1t+qPOu7b3zdVawovVkCC1ii96Kq8HBnXmCJQdP839zRi4v3bQiazQ9F8TWSIhEr+CvYz8is0lxMhJz+JEyBDWGplbNrW1iSxTyI2dVK57DNXTnC4M6pHN34znirJT5zkibgRRxcWEjunhO8+qFQiD4UzAWVmJ7i6xUjnovLs7s+YYRwHTOayQcz8J1Cdr95FiNkrnq8XN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f582043f-f17e-49e4-0e79-08d5376f3eb3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:HE1PR0801MB1883; x-ms-traffictypediagnostic: HE1PR0801MB1883: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(10436049006162)(97927398514766)(174211160506117)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:HE1PR0801MB1883; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0801MB1883; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(252514010)(13464003)(199003)(189002)(24454002)(325944009)(230783001)(189998001)(81166006)(99286004)(606006)(53546010)(5250100002)(6306002)(236005)(54896002)(8676002)(25786009)(6246003)(97736004)(3846002)(6436002)(14454004)(6116002)(53936002)(102836003)(3280700002)(7696005)(2900100001)(966005)(790700001)(33656002)(316002)(7736002)(9686003)(105586002)(55016002)(8936002)(101416001)(106356001)(229853002)(2950100002)(2906002)(5660300001)(66066001)(6506006)(3660700001)(74316002)(575784001)(478600001)(68736007)(6916009)(86362001)(50986010)(81156014)(76176010)(54356010); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0801MB1883; H:HE1PR0801MB1884.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0801MB18845225FDB05F1E6F696AD4B53B0HE1PR0801MB1884_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f582043f-f17e-49e4-0e79-08d5376f3eb3 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 21:22:07.4362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e7ab81b2-1e84-4bf7-9dcb-b6fec01ed138 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1883 X-TM-AS-MatchedID: 150567-711994-106660-700693-706484-707182-700492-187125-7 00562-700618-701253-700075-139006-854212-704416-705441-106230-707997-711995 -701249-139703-706817-708196-700047-700607-139702-139704-113220-111604-1881 19-700362-705718-700345-701827-700264-702497-704425-700732-701012-701306-70 0450-709859-188038-111605-700074-303242-700537-700079-702638-188057-700490- 111610-301328-700109-139705-138539-111608-111603-111601-148004-148036-14805 0-20020-20025-42003 X-OriginatorOrg: proximus.com X-TM-AS-MML: disable Archived-At: Subject: Re: [sipcore] Call For Adoption 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: Wed, 29 Nov 2017 21:22:19 -0000 --_000_HE1PR0801MB18845225FDB05F1E6F696AD4B53B0HE1PR0801MB1884_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C Sent: Wednesday 29 November 2017 22:05 To: Christer Holmberg Cc: SIPCORE Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push T supports Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Nov 29, 2017, at 3:58 PM, Christer Holmberg > wrote: I obviously support this :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 29 November 2017 15:52 To: SIPCORE > Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. = Please provide comments by December 13. _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer --_000_HE1PR0801MB18845225FDB05F1E6F696AD4B53B0HE1PR0801MB1884_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 = ;

From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Wednesday 29 November 2017 22:05
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-= push

 

T supports=

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com=


On Nov 29, 2017, at 3:58 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I obviously support this :)

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Brian Rosen
Sent: 29 November 2017 15:52
To: SIPCORE <sipcore@ietf.org>= ;
Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push

We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. =  Please provide comments by December 13.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3D= hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&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=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3D= hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&e=3D



***** Disclaimer *****
http://www.proximus.be/maildisclaimer
 --_000_HE1PR0801MB18845225FDB05F1E6F696AD4B53B0HE1PR0801MB1884_-- From nobody Wed Nov 29 14:40: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 BE93F120721 for ; Wed, 29 Nov 2017 14:40:52 -0800 (PST) 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 Hfb2hPfpOIBa for ; Wed, 29 Nov 2017 14:40:50 -0800 (PST) Received: from 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 1902B1201FA for ; Wed, 29 Nov 2017 14:40:50 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id E553C100DB5 for ; Wed, 29 Nov 2017 23:40:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id C7A7760070 for ; Wed, 29 Nov 2017 23:40:48 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 23:40:48 +0100 From: To: SIPCORE Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push Thread-Index: AQHTaRlSndCvMecG3ECh6skM7id+N6MrxrCAgAAB1ICAAAS9gIAAJrIw Date: Wed, 29 Nov 2017 22:40:47 +0000 Message-ID: <23384_1511995248_5A1F3770_23384_69_1_8B970F90C584EA4E97D5BAAC9172DBB81D672A54@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: , <7594FB04B1934943A5C02806D1A2204B6C02DB78@ESESSMB109.ericsson.se> <3A3CE3A5-28EF-40D2-8704-FEA60B9392A4@att.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.2] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81D672A54OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Call For Adoption 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: Wed, 29 Nov 2017 22:40:53 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB81D672A54OPEXCLILMA4corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de VAN GEEL Jan (= SPC/CSP) Envoy=E9 : mercredi 29 novembre 2017 22:22 =C0 : SIPCORE Objet : Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push +1 From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Wednesday 29 November 2017 22:05 To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push T supports Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Nov 29, 2017, at 3:58 PM, Christer Holmberg > wrote: I obviously support this :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 29 November 2017 15:52 To: SIPCORE > Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. = Please provide comments by December 13. _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer ___________________________________________________________________________= ______________________________________________ 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_8B970F90C584EA4E97D5BAAC9172DBB81D672A54OPEXCLILMA4corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1

 

De : sipc= ore [mailto:sipcore-bounces@ietf.org] De la part de VAN GEEL Jan (SPC/CSP)
Envoy=E9 : mercredi 29 novembre 2017 22:22
=C0 : SIPCORE
Objet : Re: [sipcore] Call For Adoption draft-holmberg-sipcore-= sip-push

 

+1

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Wednesday 29 November 2017 22:05
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: SIPCORE <sipcore@ietf.org= >
Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-= push

 

= T supports

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com=

=
On Nov 29, 2017, at 3:58 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I obviously support this :)

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Brian Rosen
Sent: 29 November 2017 15:52
To: SIPCORE <sipcore@ietf.org>= ;
Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push

We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. =  Please provide comments by December 13.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3D= hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&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=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3D= hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&e=3D

 


***** Disclaimer *****
http://www.proximus.be/ma= ildisclaimer

______________________________________________________________________=
___________________________________________________

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_8B970F90C584EA4E97D5BAAC9172DBB81D672A54OPEXCLILMA4corp_-- From nobody Wed Nov 29 16:35: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 9938E124B0A for ; Wed, 29 Nov 2017 16:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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=Yh+8wb+U; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=syaAoxrW 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 LDcxJ3MzfYUo for ; Wed, 29 Nov 2017 16:35:34 -0800 (PST) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 2E228126D73 for ; Wed, 29 Nov 2017 16:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1512002134; x=1543538134; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=46v/Xc10g4voTTGFOIMNzXUj/GVp9eKxUxGfJ56dokY=; b=Yh+8wb+Uo12EAE7az4dcFQ7Bffcgp1mJVysT/JmY7Aq4YnM6mxZ0in79 QgnTjvYq4MyHuUgEQxHqtiMdZ6GRnh5LpRHW/F1DHTCLwG0IyzLxLutQc ybrUdC4grPJhUExzoXJYRZgRI9/nalLrQgK5aBKY78tETFVmLYOMGS2vc CQ44xqBO7iKCAamJIVrG8aJn2cw97+s/w09bH/joPm/EJghfNZXXbdLDl 5JUHv5VLamjrCdhIaedA37Sm/sV3FDOnpIvUK24yL+M1kDsxIl5LdD1gT 2DbFFTs4jSMHO7fL5txIKiIb/FGXnyBG7oOnZw7CUMb2qjLrmZrQsVnB6 Q==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 01:35:32 +0100 X-IronPort-AV: E=Sophos;i="5.45,339,1508796000"; d="scan'208,217";a="704068104" Received: from he105826.emea1.cds.t-internal.com ([10.169.118.48]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 30 Nov 2017 01:35:31 +0100 Received: from HE104850.EMEA1.cds.t-internal.com (10.169.118.13) by HE105826.emea1.cds.t-internal.com (10.169.118.48) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 01:35:30 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE104850.EMEA1.cds.t-internal.com (10.169.118.13) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 30 Nov 2017 01:35:30 +0100 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, 30 Nov 2017 01:35:25 +0100 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=46v/Xc10g4voTTGFOIMNzXUj/GVp9eKxUxGfJ56dokY=; b=syaAoxrWzkZUU0M1S13/mGiAAvNwRkzfkrMY362klUykt0fN9fF6SwT8fUluCkLD6FEsFAElPly4mQlLjXaltiRi3BJNKOOepJA3+7zyNpE8sun5N+rwVfJbJ0uy4c7IZ9w6Sx6ZJHVVnLlt+Lyk958h5FW55dCa9U/w4Z+SYd8= 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.260.4; Thu, 30 Nov 2017 00:35:29 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0260.007; Thu, 30 Nov 2017 00:35:29 +0000 From: To: , Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push Thread-Index: AQHTaRljF+Wounvy/EisfQGAtuqAfqMr13SAgAAB04CAAAS+gIAAFfqAgAAgAxA= Date: Thu, 30 Nov 2017 00:35:29 +0000 Message-ID: References: , <7594FB04B1934943A5C02806D1A2204B6C02DB78@ESESSMB109.ericsson.se> <3A3CE3A5-28EF-40D2-8704-FEA60B9392A4@att.com> <23384_1511995248_5A1F3770_23384_69_1_8B970F90C584EA4E97D5BAAC9172DBB81D672A54@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <23384_1511995248_5A1F3770_23384_69_1_8B970F90C584EA4E97D5BAAC9172DBB81D672A54@OPEXCLILMA4.corporate.adroot.infra.ftgroup> 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.159] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0484; 6:jI4VLjS8b4XiSytAz0nd4bd22InMmLID6c7YluhBCQjgeViX7KNFGf10dMvOdEVtNt+5hkXEWv3eGq+WOmjcTiZquQq5lcRSn5M0vsQ4/5AeZeHNwKcSXuNVrIOnThIRbe8k9RYg+LonKz4hFJ+a3MUdSK3sKiaNHsmucIVmS66694vlnwdiMifyQGXY3hVZpB0TaaOStAPjZaS2Jvc5urKNJpwWG4ff6mRzuIrxWy9S16qCf9FjWnwF+5N3E6DvsJZV9IC+bgOvbTUO867U/nlMepnumhzHZIMQmnSZ2oA8HBpedEb93E+K/bpKMFf2wZRPpQ1KLY0ThK0MCf1yosq44xfEtfZdZ4NUzWBb+VQ=; 5:AgGM2XrYlCj+4MXjdw0qo6avjCwqZNja1h3A8eal11GVPzpZllGHuIkqDKjS9nbOK2lU3KOy+htdLBAarDsJcw6+mApby+FiE9iXyTY9BNahAmcLxDIirA8bVCUeVINbV/nQ2lEO3CeokHIRDQACkOY4/K2QPLJ8D4GXZ41NCoI=; 24:ukRhqagT+yHzFlzwN4DD7w+lGmes+0/Fad6a5rlBOj5K0Rbzr1nsmDUpkitE2Ew9YmDM6776dR6eElrG6nprh/znbRxR58/cHnvVgPbBpUY=; 7:Pm31mPgZn/g3bcnR7tl3kVKfsNNYjQaLJLCz34nfgdWEaXyNZbGwPZeA/bXk+6pZj/iJAO2ix26LhK8vqvdm+/ZRm0GwlaG4LF66y1gcrM15YMlXxOZlgeptkNquzBY7lHeTa34PYH+jFWQvSDFwfmvkFEdArQAML1IS+i1cXolfo2Y1utw0IogdqfNOKeUeDtc02mTasY0/AKzMn4X5ZyZbH65b2ZsYHtj3PFojr2NAZalG/zgSLOKeKC+Xmf9h x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5b313abe-8d4b-43ec-bf4f-08d5378a4200 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603278); SRVR:FRAPR01MB0484; x-ms-traffictypediagnostic: FRAPR01MB0484: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(10436049006162)(97927398514766)(174211160506117)(227612066756510)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:FRAPR01MB0484; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:FRAPR01MB0484; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(189002)(252514010)(24454002)(199003)(13464003)(966005)(325944009)(110136005)(14454004)(575784001)(478600001)(53546010)(97736004)(66066001)(606006)(7696005)(86362001)(316002)(7736002)(2906002)(3660700001)(50986010)(54356010)(76176010)(72206003)(68736007)(8936002)(52396003)(2950100002)(3280700002)(33656002)(102836003)(53936002)(9686003)(3846002)(101416001)(790700001)(105586002)(5250100002)(75402003)(106356001)(93886005)(5660300001)(6116002)(2501003)(8676002)(81156014)(74482002)(2900100001)(55016002)(5890100001)(236005)(189998001)(6306002)(230783001)(54896002)(81166006)(19627235001); 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_FRAPR01MB0483FD5CEC0D422E64D7D15CF9380FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5b313abe-8d4b-43ec-bf4f-08d5378a4200 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 00:35:29.3902 (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] Call For Adoption 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, 30 Nov 2017 00:35:39 -0000 --_000_FRAPR01MB0483FD5CEC0D422E64D7D15CF9380FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von marianne.moha= li@orange.com Gesendet: Mittwoch, 29. November 2017 23:41 An: SIPCORE Betreff: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push +1 De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de VAN GEEL Jan (= SPC/CSP) Envoy=E9 : mercredi 29 novembre 2017 22:22 =C0 : SIPCORE Objet : Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push +1 From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C Sent: Wednesday 29 November 2017 22:05 To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push T supports Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Nov 29, 2017, at 3:58 PM, Christer Holmberg > wrote: I obviously support this :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 29 November 2017 15:52 To: SIPCORE > Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. = Please provide comments by December 13. _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer ___________________________________________________________________________= ______________________________________________ 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_FRAPR01MB0483FD5CEC0D422E64D7D15CF9380FRAPR01MB0483DEUP_ 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 marianne.mohali@orange.com
Gesendet: Mittwoch, 29. November 2017 23:41
An: SIPCORE <sipcore@ietf.org>
Betreff: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-= push

 

+1

 

De : sipc= ore [mailto:sipcore-bounces@iet= f.org] De la part de VAN GEEL Jan (SPC/CSP)
Envoy=E9 : mercredi 29 novembre 2017 22:22
=C0 : SIPCORE
Objet : Re: [sipcore] Call For Adoption draft-holmberg-sipcore-= sip-push

 

+1

 

From: = sipcore [mailto:sipcore-bounces= @ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Wednesday 29 November 2017 22:05
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: SIPCORE <sipcore@ietf.org= >
Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-= push

 =

= T supports

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com

=
On Nov 29, 2017, at 3:58 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I obviously support this :)

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Brian Rosen
Sent: 29 November 2017 15:52
To: SIPCORE <sipcore@ietf.org>= ;
Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push

We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. =  Please provide comments by December 13.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3D= hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&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=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3D= hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&e=3D

 =


***** Disclaimer *****
http://www.proximus.be/ma= ildisclaimer

____________________________________________________=
_____________________________________________________________________<=
/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_FRAPR01MB0483FD5CEC0D422E64D7D15CF9380FRAPR01MB0483DEUP_-- From nobody Wed Nov 29 17:32: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 356311286B1 for ; Wed, 29 Nov 2017 17:32:33 -0800 (PST) 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=BzTXYH7R; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=MAjP0tB7 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 ZrZX_-ckHwLp for ; Wed, 29 Nov 2017 17:32:31 -0800 (PST) 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 56E30127136 for ; Wed, 29 Nov 2017 17:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1512005550; x=1543541550; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AL7ZH1r01ZYhF8Xg3IpKwwl/QV0eSeRoNjEZYF7QpwA=; b=BzTXYH7RdXUWVX6Fo0d5l6SSZ+0vdkfK0oofHAh6umkjd7+fH2eYpUOe a/Fm0VpPYknqq5au15I8hTNZTXxjQw4vxXTevvC0s8Yx/uA7gXlkwoNIH TaZ9nBCTJe3OHcfEhoogdPl4NltxiUcprfHoJc1vLtZ7FipBWnmnzDoLi YkghsQrRdZkwnMatkM/aMVtUc8cfSBIKK18rw7t7hkEDSwn7KrfT08yz4 D20Zqd4Lx+CaVmA9Gx5NHIvVLNzuXfenlM2kVyt5baG2UraIId4L1hoom zcs4dXEk2QSAoP5a3qktJj/J675zXGW5T8170DSn7QS8k+QePNtBFoKwi g==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 02:32:28 +0100 X-IronPort-AV: E=Sophos;i="5.45,339,1508796000"; d="scan'208";a="124563160" Received: from he101951.emea1.cds.t-internal.com ([10.169.118.77]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 30 Nov 2017 02:32:28 +0100 Received: from HE106161.EMEA1.cds.t-internal.com (10.169.118.72) by HE101951.emea1.cds.t-internal.com (10.169.118.77) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 02:32:27 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE106161.EMEA1.cds.t-internal.com (10.169.118.72) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 30 Nov 2017 02:32:27 +0100 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.1347.2; Thu, 30 Nov 2017 02:32:22 +0100 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=AL7ZH1r01ZYhF8Xg3IpKwwl/QV0eSeRoNjEZYF7QpwA=; b=MAjP0tB76GqczW+qgbG4vRy3iYGOFp+GQIakKTI7E27p2pDheDPuZVUJUsApLy1fnatzYO2hyJG4w+zqhU1q/SBLnf5bMWqWN9+mniGwk62S5pLgpZFVNwjPbmCTPXIVwI2jC1S//BX2JMN7im/lKfmo1Lo9pqx5t8TnhBGdmsY= 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.260.4; Thu, 30 Nov 2017 01:32:26 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::707c:6ad8:bdcb:4847%14]) with mapi id 15.20.0260.007; Thu, 30 Nov 2017 01:32:26 +0000 From: To: , Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnUFtGaBJrWltk+s1shdGvlnWqL+S3eAgANM5ACAAAWhgIAABYIAgBhYyQCAAJRHAIAAiM8AgAEq5YCAAJcLgIABCfYAgAP9WACAAKuXAIAAtCwAgAI3xgCAAn+9gIAA9cMAgACm9ICAAMhXAIAAATqAgAAKeoCAAB8d4IAADHCAgAAVcKCAABTLAIABj5HA Date: Thu, 30 Nov 2017 01:32:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C003B7C@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C02989E@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.159] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0481; 6:aF1OORTu+IHiT1nJIE89sMnlwxs/t/uGHGnO0nPCmQBmtL3WnLEjK5O0umbAIscAFaN8fBHMQFzk+hEfDXA0QLDVP0ha90oB2yEqliDRiPz7PpOy0kDI7jrmzsCq4fEAa1Uvek0vyIPDYEyQC+yqgi0eSWcrdBLIHsVOg+K/ggF71ZFfZ/rKOmzLpq/tDGlg9HuZl1iqqmcEZzWRgZtOnv4XNIAjpaDXq+/3fKDgEMQtUeuiUpwt3OcO1OELJgknCYCsTW3OSvz3Tp/KS0ato2jPKMU6aqJNnEfwSR2ulAlwW6Wv94wyWF3wU7OcL4I89PZWTZtEvsZla2VnkE4Ny89vAcx80UVIKhNgncXQzO4=; 5:4qAxmvA8pQzahyy2uq/b8sRDJOLFlOZioUUI7XqUZNp3jU93mHkY8BmrkquNLah6b4ZhEq4lH1edEqAS5XHofC2vWHqRisRdgYrHpwkjIWm2Y2mU9O7gNDKgv3WnrKU3SE+w3iQzmBJRySA/8oQ+7cANU0BGjWVKXkceANWp85E=; 24:+Oi4/A6yYW/gRMTrM+gZOA9BU3bTkhEJyy/3qvHrtyUlckIpkr5BpObwVFSEfIEmTkZpb5LhpxSZQracm6foeoPPP6gjxlHsEncXNr5ekfs=; 7:kI7pFkFOiMXxmPGG45LgAyHG6msKdSKqQArX6eQYWhbE53fD1fET0WfUdYAdbiKdY4lL+2PeLBj/mZKqFXPxZsB854ivRvoBiIItXQXq6I6eQLLCmJg/EdVjMC1RgMLCDM77lEK1AFgiziPWjh1bWB7jkJ4Qo0vM++Jy86tvUmqmYPsvCixPZ4TtiIhtXCK57PTHx1kQxDPV9vXt9dWvExT0awSHSBk8ZVpNjd+bmnx/0yG26YYhzR7UzmRtHwxH x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 024eb19d-551c-44ad-51a7-08d5379236d8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603278); SRVR:FRAPR01MB0481; x-ms-traffictypediagnostic: FRAPR01MB0481: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:FRAPR01MB0481; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:FRAPR01MB0481; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(366004)(346002)(51444003)(24454002)(189002)(199003)(3660700001)(2900100001)(6306002)(966005)(86362001)(345774005)(81156014)(7736002)(93886005)(478600001)(3280700002)(316002)(81166006)(72206003)(8936002)(305945005)(74482002)(110136005)(189998001)(8676002)(5250100002)(2950100002)(551934003)(55016002)(3846002)(105586002)(75402003)(5660300001)(14454004)(102836003)(68736007)(6116002)(106356001)(2501003)(97736004)(2906002)(101416001)(52396003)(2171002)(53936002)(66066001)(9686003)(53546010)(7696005)(76176010)(33656002)(54356010)(50986010); 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 024eb19d-551c-44ad-51a7-08d5379236d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 01:32:26.6911 (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: Thu, 30 Nov 2017 01:32:33 -0000 SGkgUGF1bCwNClRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4NCkF0IGxlYXN0IEkgZnVsbHkg YWdyZWUgd2l0aCB5b3UgYXNzdW1wdGlvbiBhbmQgSSB0aGluayB3ZSBuZWVkIHRoZW4gYSBwcm9w ZXIgZGVzY3JpcHRpb24uIFRvIGF2b2lkIHN1Y2ggc3R1cGlkIGltcGxlbWVudGF0aW9ucy4NCg0K QmVzdCBSZWdhcmRzDQoNClJvbGFuZA0KDQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0 LS0tLS0NCj4gVm9uOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBJ bSBBdWZ0cmFnIHZvbiBQYXVsIEt5eml2YXQNCj4gR2VzZW5kZXQ6IE1pdHR3b2NoLCAyOS4gTm92 ZW1iZXIgMjAxNyAwMjozOA0KPiBBbjogc2lwY29yZUBpZXRmLm9yZw0KPiBCZXRyZWZmOiBSZTog W3NpcGNvcmVdIFNlc3Npb24gdGltZXIgZml4DQo+IA0KPiBPbiAxMS8yOC8xNyA3OjQ2IFBNLCBS Lkplc3NrZUB0ZWxla29tLmRlIHdyb3RlOg0KPiA+IEhpIFJvbWFuLA0KPiA+DQo+ID4gSW52aXRl IHdpdGggUy1FIDM2MDAgaXMgc2VudCBieSB0aGUgVUFDLiBQcm94eSBsZXQgSU5WSVRFIHBhc3Mg dG93YXJkcyBVQVMuDQo+ID4NCj4gPiAxc3QgbmVnb3RpYXRpb24gaXMgb25nb2luZy4NCj4gPg0K PiA+IDE4eC9QUkFDSy8yMDBPSyhQUkFDSykgaXMgZXhjaGFuZ2VkLg0KPiA+DQo+ID4gTm93IFVB UyBpcyBzZW5kaW5nIFVQREFURSB3aXRoIGEgc3VwcG9ydGVkIHRpbWVyIGFuZCBQcm94eSBhZGRz IFMtRQ0KPiA+IGR1ZSB0byBsb2NhbCBwb2xpY3kgd2l0aCBTLUUgMTgwMC4NCj4gDQo+IElmIHRo YXQgaXMgaXRzIHBvbGljeSwgd2h5IGRpZG4ndCBpdCBhbHNvIHJlZHVjZSB0aGUgUy1FIHRvIDE4 MDAgaW4gdGhlIElOVklURT8gSWYgaXQNCj4gaGFkIGRvbmUgdGhhdCB0aGVyZSB3b3VsZG4ndCBi ZSBhIHByb2JsZW0uDQo+IA0KWWVzIHRoYXQgd291bGQgYmUgdGhlIGNvcnJlY3Qgd2F5LCBidXQg dGhpcyBpcyBub3QgZGVzY3JpYmVkIHdpdGhpbiBSRkM0MDI4IGZvIHJ0aGUgcHJveHkgYmVoYXZp b3IuDQpXZSBzaG91bGQgYWRkIHRoaXMuDQo+ID4gU28gd2hhdCB3aWxsIHRoZSBVQUMgZG8uIFRo ZSBwcm94eSBoYXMgYWRkZWQgdGhlIFMtRS4NCj4gDQo+IFRoZSBjYXNlIHlvdSBwcmVzZW50ZWQs IHdoZXJlIHRoZSBwcm94eSBpcyBpbmNvbnNpc3RlbnQgYmV0d2VlbiBJTlZJVEUNCj4gYW5kIFVQ REFURSwgZG9lcyBwcmVzZW50IGEgcHJvYmxlbS4gVGhlIFVBIGNvdWxkIHNlbmQgUy1FIDE4MDAg aW4gdGhlDQo+IDIwMC9VUERBVEUuIEJ1dCB3aGF0IHRoZSBvdGhlciBlbmQgZG9lcyBpbiB0aGF0 IGNhc2UgaXMgdW5kZWZpbmVkLg0KPiANCj4gV2hhdCB5b3UgaGF2ZSBkZW1vbnN0cmF0ZWQgaGVy ZSBpcyB0aGF0IHRoZXJlIGlzIGFuIGlzc3VlIHdpdGggdGhlIFMtRSB2YWx1ZQ0KPiBhcyB3ZWxs IGFzIHdpdGggdGhlIHJlZnJlc2hlciByb2xlLg0KPiANCj4gPiBVQUMgKFdoaWNoIGhhcyBzZW50 IHRoZSBJTlZJVEUpIGNvdWxkIGlnbm9yZSBhbmQgc2VuZCAyMDAgT0sgd2l0aG91dA0KPiA+IGFu eSBTLUUuIGkuZS4gaWdub3JpbmcgVVBEQVRFLg0KPiA+DQo+ID4gSW4gdGhpcyBjYXNlLCB3aGF0 IGlzIHRoZSB0aGVuIHByb3h5IGRvaW5nPyBQYXNzaW5nIDIwME9LIHcvbyBTLUUgb3INCj4gPiBt YXkgaXQgYWRkIGFuIFMtRSBhZ2Fpbj8gQXNzdW1pbmcgaXQgYWRkcyBTLUUgMTgwMCBiZWNhdXNl IGl0DQo+ID4gcmVtZW1iZXJzIHRoYXQgdGhlIFVQREFURSB3YXMgcmVjZWl2ZWQgd2l0aCBzdXBw b3J0ZWQgdGltZXIuDQo+ID4NCj4gPiBXaGF0IGRvZXMgdGhlIFVBUyBkbz8gSWdub3JpbmcgdGhl IDIwMCBPSyB3aXRoIFNFIG9yIGFjY2VwdGluZz8NCj4gPg0KPiA+IEFuZCB0aGVuIHdoYXQgd2ls bCB0aGUgVUFTIGRvPyBTZW5kaW5nIDIwMCBPSyAoSU5WSVRFKSB3aXRoIFMtRSAzNjAwDQo+ID4g YXMgcHJvcG9zZWQgYnkgdGhlIElOVklURSwgYmVjYXVzZSB0aGUgVUFTIGlzIGlnbm9yaW5nIHRo ZSAyMDAgT0sNCj4gPiAoVVBEQVRFKSB3aXRoIFMtRSAxODAwPw0KPiA+DQo+ID4gT3IgZG8geW91 IHRoaW5rIHRoYXQgaGlzIGlzIGEgd3JvbmcgaW1wbGVtZW50YXRpb24uDQo+IA0KPiBJIHRoaW5r IGl0IGlzIGEgc3R1cGlkIGltcGxlbWVudGF0aW9uLiBBRkFJSyB0aGVyZSBpcyBub3RoaW5nIGlu IDQwMjggdGhhdCBzYXlzIGl0DQo+IGlzIHdyb25nLg0KPiANCj4gSSB0aGluayB0aGUgZml4IEkg c2tldGNoZWQgaW4gYSBtYWlsIGEgZmV3IGhvdXJzIGFnbyBjYW4gcHJvYmFibHkgYmUgZXh0ZW5k ZWQNCj4gdG8gY292ZXIgdGhpcyBjYXNlLiBOb3RhYmx5LCBpZiBvbmUgc2lkZSBkZXRlY3RzIGFu IGFtYmlndWl0eSBpbiBvbmUgb3IgbW9yZSBvZg0KPiB0aGUgbmVnb3RpYXRlZCBzLXQgdmFsdWVz LCBhbmQgdGhhdCBhbWJpZ3VpdHkgaGFzIG5lZ2F0aXZlIGNvbnNlcXVlbmNlcywNCj4gdGhlbiBp dCBzaG91bGQgaW5pdGlhdGUgYW4gaW1tZWRpYXRlIHMtdCByZWZyZXNoIHRvIGZpeCBpdC4NCj4g DQo+IFdlIGp1c3QgbmVlZCB0byBzb3J0IG91dCB3aGF0IGFsbCB0aGUgYW1iaWd1aXRpZXMgYXJl IGFuZCBob3cgdG8gZGV0ZWN0DQo+IHRoZW0uDQoNCkkgZnVsbHkgYWdyZWUuDQo+IA0KPiAJVGhh bmtzLA0KPiAJUGF1bA0KPiANCj4gPiBCZXN0IFJlZ2FyZHMNCj4gPg0KPiA+IFJvbGFuZA0KPiA+ DQo+ID4gKlZvbjoqIHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddICpJ bSBBdWZ0cmFnIHZvbg0KPiA+ICpSb21hbiBTaHBvdW50DQo+ID4gKkdlc2VuZGV0OiogTWl0dHdv Y2gsIDI5LiBOb3ZlbWJlciAyMDE3IDAwOjA3DQo+ID4gKkFuOiogSmVzc2tlLCBSb2xhbmQgPFIu SmVzc2tlQHRlbGVrb20uZGU+DQo+ID4gKkNjOiogU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4N Cj4gPiAqQmV0cmVmZjoqIFJlOiBbc2lwY29yZV0gU2Vzc2lvbiB0aW1lciBmaXgNCj4gPg0KPiA+ IFJvbGFuZCwNCj4gPg0KPiA+IFBsZWFzZSBwcm92aWRlIHRoZSBleGFjdCBzY2VuYXJpby4gV2hh dCB5b3Ugc2VlbSB0byBiZSBkZXNjcmliaW5nIGFyZQ0KPiA+IG1pc2NvbmZpZ3VyZWQgcHJveGll cyBvciBjbGllbnRzIHRoYXQgZG8gbm90IGZvbGxvdyBleGlzdGluZyBzcGVjaWZpY2F0aW9ucy4N Cj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBfX19fX19fX19fX19fDQo+ID4gUm9tYW4gU2hw b3VudA0KPiA+DQo+ID4gT24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgNTozMyBQTSwgPFIuSmVzc2tl QHRlbGVrb20uZGUNCj4gPiA8bWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGU+PiB3cm90ZToNCj4g Pg0KPiA+ICAgICBIaSBQYXVsLA0KPiA+ICAgICBXZSBoYXZlIGRpZmZlcmVudCBpc3N1ZXMgd2hl cmUgd2UgaGF2ZSBsb29rIG9uLg0KPiA+ICAgICBBbmQgd2Ugc2VlIHRoYXQgd2UgaGF2ZSBVUERB VEUgd2l0aCBhbiBTLVQgY2F1c2luZyBhIGxvdCBvZiB0cm91YmxlLg0KPiA+ICAgICBUaGlzIGlz IGRlcGVuZGVudCBvbiBkaWZmZXJlbnQgdXNlIGNhc2VzLg0KPiA+ICAgICBPbmUgaXMgdGhhdCB0 aGUgVUEgZG9lcyBub3Qgc3VwcG9ydCBVUERBVEUuDQo+ID4gICAgIFllcyB0aGF0IGlzIHRydWUu DQo+ID4gICAgIEJ1dCBvbmUgb2YgdGhlIG1haW4gcHJvYmxlbXMgYXJlIHRoZSBwcm94aWVzIGlu IGJldHdlZW4uDQo+ID4gICAgIEVpdGhlciBwcm94aWVzIGRvIG5vdCByZWFjdCB3aGljaCBpcyBP Sy4NCj4gPiAgICAgQW5kIHRoZSBVQUMgaW50ZXJwcmV0aW5nIHRoZSAyMDBPSy4NCj4gPiAgICAg QWxzbyB0aGUgZGlyZWN0aW9uIG9mIHRoZSBVUERBVEUgaXMgaW1wb3J0YW50Lg0KPiA+ICAgICBB bHNvIHRoZSBiZWhhdmlvciBvZiB0aGUgcHJveHkuIFdlIGhhdmUgc2VlbiBwcm94aWVzIGFkZGlu ZyBTLVQgdG8NCj4gPiAgICAgdGhlIFVQREFURSBkdWUgdG8gdGhlIGZhY3QgdGhhdCBzZXNzaW9u IHRpbWVyIHN1cHBvcnRlZCBpcyBzZXQuIFRoZQ0KPiA+ICAgICBTLVQgdmFsdWVzIHdoZXJlIGRp ZmZlcmVudCB0byB0aGF0IHNldCBieSB0aGUgVUFDLg0KPiA+DQo+ID4gICAgIFNvIGFzIHlvdSBz YWlkIHdlIGNhbiBpZGVudGlmeSBhbGwgdXNlIGNhc2VzLiBBbmQgSSB0aGluayB0aGF0IGlzDQo+ ID4gICAgIHdoYXQgd2UgbmVlZCBvciByZWFsIGNsZWFyIHJ1bGVzIGZvciBVQUMvVUFTIGFuZCBQ cm94eS4NCj4gPg0KPiA+ICAgICBCZXN0IFJlZ2FyZHMNCj4gPg0KPiA+ICAgICBSb2xhbmQNCj4g Pg0KPiA+DQo+ID4gICAgICA+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4g PiAgICAgID4gVm9uOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUN Cj4gPiAgICAgPG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+XQ0KPiA+ICAgICAgPiBHZXNl bmRldDogRGllbnN0YWcsIDI4LiBOb3ZlbWJlciAyMDE3IDIxOjMxDQo+ID4gICAgICA+IEFuOiBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tDQo+ID4gICAg IDxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47IFJvbWFuIFNocG91bnQN Cj4gPiAgICAgID4gPHJvbWFuQHRlbHVyaXguY29tIDxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+ Pg0KPiA+ICAgICAgPiBDYzogSmVzc2tlLCBSb2xhbmQgPFIuSmVzc2tlQHRlbGVrb20uZGUNCj4g PiAgICAgPG1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPj47IHNpcGNvcmVAaWV0Zi5vcmcNCj4g PiAgICAgPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KPiA+ICAgICAgPiBCZXRyZWZmOiBSZTog W3NpcGNvcmVdIFNlc3Npb24gdGltZXIgZml4DQo+ID4NCj4gPiAgICAgID4NCj4gPiAgICAgID4g T24gMTEvMjgvMTcgMjo1MyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+ID4gICAgICA+ ID4gSGksDQo+ID4gICAgICA+ID4NCj4gPiAgICAgID4gPj4+IDEuIFdoYXQgaGFwcGVucyB3aGVu IFVBQyByZWNlaXZlcyBhIDJYWCBJTlZJVEUgcmVzcG9uc2Ugd2l0aA0KPiBTLVQNCj4gPiAgICAg ID4gPj4+IHRoYXQgZGlkIG5vdCBtYXRjaCB0aGUgUy1UIHZhbHVlIG5lZ290aWF0ZWQgYnkgVVBE QVRFIHRyYW5zYWN0aW9uDQo+ID4gICAgICA+IGR1cmluZyB0aGlzIElOVklURSB0cmFuc2FjdGlv bj8NCj4gPiAgICAgID4gPj4NCj4gPiAgICAgID4gPj4gRXJyb3IgY2FzZS4NCj4gPiAgICAgID4g Pj4NCj4gPiAgICAgID4gPj4+IDIuIFdoYXQgaGFwcGVucyB3aGVuIFVBQyByZWNlaXZlcyBhIDJY WCBVUERBVEUgcmVzcG9uc2Ugd2l0aA0KPiBTLVQNCj4gPiAgICAgID4gPj4+IHRoYXQgZGlkIG5v dCBtYXRjaCB0aGUgMlhYIHJlc3BvbnNlIGZvciB0aGUgcHJldmlvdXMgVVBEQVRFDQo+ID4gICAg ICA+IHRyYW5zYWN0aW9uPw0KPiA+ICAgICAgPiA+Pg0KPiA+ICAgICAgPiA+PiBFcnJvciBjYXNl Lg0KPiA+ICAgICAgPiA+Pg0KPiA+ICAgICAgPiA+PiBIb3cgZG8geW91IHdhbnQgdG8gaGFuZGxl IHRoZXNlIGVycm9yIGNhc2VzPyBUd28gb3B0aW9ucyB0aGF0DQo+ID4gICAgIEkgc2VlIGFyZToN Cj4gPiAgICAgID4gPj4gYS4gVGVybWluYXRlIHRoZSBkaWFsb2cgKGhhbmcgdXApDQo+ID4gICAg ICA+ID4+IGIuIElzc3VlIGEgbmV3IFVQREFURSB0byBzZXQgcmVmcmVzaGVyIHRvIGEga25vd24g c3RhdGUuDQo+ID4gICAgICA+ID4NCj4gPiAgICAgID4gPiBUaG9zZSBhcmUgdHdvIGFsdGVybmF0 aXZlcywgeWVzLiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8NCj4gPiAgICAgbWFuZGF0ZSBhbnkN Cj4gPiAgICAgID4gc3BlY2lmaWMgYmVoYXZpb3VyLCBhcyBsb25nIGFzIHdlIG1ha2UgaXQgY2xl YXIgdGhhdCBhbiBlcnJvciBoYXMNCj4gPiAgICAgb2NjdXJyZWQgYW5kDQo+ID4gICAgICA+IGl0 IG5lZWRzIHRvIGJlIHRha2VuIGNhcmUgb2YgU09NRUhPVy4NCj4gPiAgICAgID4NCj4gPiAgICAg ID4gT3IgeW91IGNhbiBqdXN0IGlnbm9yZSB0aGUgZXJyb3IgYW5kIGhvcGUgZm9yIHRoZSBiZXN0 Lg0KPiA+ICAgICAgPg0KPiA+ICAgICAgPiBNeSBpbnR1aXRpb24gdGVsbHMgbWUgdGhhdCB0aGlz IHdpbGwgcmFyZWx5IGNhdXNlIGEgcHJvYmxlbS4gTW9zdA0KPiA+ICAgICBvZiB0aGUgdGltZSBh DQo+ID4gICAgICA+IGRldmljZSB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCB0aGUgdXBkYXRlIHdpbGwg YmUgY29tcGxpYW50IHdpdGggdGhlDQo+ID4gICAgIHVwZGF0ZSBieQ0KPiA+ICAgICAgPiBhY2Np ZGVudC4gQW5kIGluIGEgYnVuY2ggb2YgdGhlIHJlbWFpbmluZyBjYXNlcyBpZ25vcmluZyBhDQo+ ID4gICAgIGNvbmZsaWN0aW5nIHZhbHVlIGluDQo+ID4gICAgICA+IHRoZSBuZXN0ZWQgVVBEQVRF IHdvbid0IG1hdHRlciBiZWNhdXNlIGJvdGggZW5kcyB3aWxsIHNldHRsZSBvbg0KPiA+ICAgICB3 aGF0IGlzIGluDQo+ID4gICAgICA+IHRoZSAyMDAvSU5WSVRFLiBBbmQgdGhlIHJlbWFpbmluZyBj YXNlcyB3aWxsIHJlc3VsdCBpbiBib3RoIGVuZHMNCj4gPiAgICAgdGhpbmtpbmcNCj4gPiAgICAg ID4gdGhleSBhcmUgVUFDIG9yIFVBUy4gSXQgaXNuJ3QgYSBwcm9ibGVtIGlmIHRoZXkgYm90aCB0 aGluayB0aGV5DQo+ID4gICAgIGFyZSB0aGUgVUFDLA0KPiA+ICAgICAgPiBzaW5jZSB0aGVuIGJv dGggd2lsbCBhdHRlbXB0IHRvIHJlZnJlc2guIEl0IGlzIG9ubHkgYSBwcm9ibGVtIGlmDQo+ID4g ICAgIHRoZXkgYm90aCB0aGluaw0KPiA+ICAgICAgPiB0aGV5IGFyZSBVQVMsIHNpbmNlIHRoYXQg aXMgdGhlIG9ubHkgY2FzZSB3aGVuIHRoZSBzZXNzaW9uIHdvbid0IGJlDQo+ID4gICAgICA+IHJl ZnJlc2hlZC4gSWYgdGhhdCBoYXBwZW5zLCBpcyBpdCB3b3JzZSB0aGFuIGhhdmluZyBoYWQgdGhl IGNhbGwNCj4gPiAgICAgZmFpbD8NCj4gPiAgICAgID4NCj4gPiAgICAgID4gSWYgbmVlZCBiZSB3 ZSBjYW4gd29yayB0aHJvdWdoIGFsbCB0aGUgY2FzZXMuIEJ1dCB0aGVyZSBhcmUgcXVpdGUNCj4g PiAgICAgYSBsb3Qgb2YNCj4gPiAgICAgID4gdGhlbS4NCj4gPiAgICAgID4NCj4gPiAgICAgID7C oCDCoCDCoCDCoFRoYW5rcywNCj4gPiAgICAgID7CoCDCoCDCoCDCoFBhdWwNCj4gPg0KPiA+DQo+ ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gc2lwY29yZUBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+DQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1h aWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From nobody Thu Nov 30 00:39: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 D3133126B7E for ; Thu, 30 Nov 2017 00:39:10 -0800 (PST) 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 vxdEL18TfYCq for ; Thu, 30 Nov 2017 00:39:08 -0800 (PST) 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 DF1421200C5 for ; Thu, 30 Nov 2017 00:39:07 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-85-5a1fc3a98023 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.97.08439.9A3CF1A5; Thu, 30 Nov 2017 09:39:06 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Thu, 30 Nov 2017 09:39:05 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgIAA0dwAgADK3wCAAKRtAIAAEWVg///6T4CAACJbgIAACTGAgAAb1oCAAA5lAIAAhseAgABz6ACAATFKAA== Date: Thu, 30 Nov 2017 08:39:04 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> In-Reply-To: <375782e0-a840-d4ae-0ffa-89a5dccc480b@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.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7ou6qw/JRBqufsFqs2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGkflLWAreR1a8WnuVqYHxuUsXIyeHhICJ xIy1Hxm7GLk4hAQOM0r8+XKIHcJZwiix6+Q3li5GDg42AQuJ7n/aIA0iAoESV5dMYAaxhQU0 JA7t+c0CEdeUuHhqGRNIr4jAI0aJA5cPsIEkWARUJaYseckEYvMKWEt833+aDWLBIg6Jz1su gnVzCjhILNz/CayBUUBM4vupNWANzALiEreezGeCOFVAYsme88wQtqjEy8f/WEFsUQE9iQ0n brNDxBUlPr7axwjRqydxY+oUNgjbWuLwn4dQM7Ulli18zQxxkKDEyZlPWCYwis1Csm4WkvZZ SNpnIWmfhaR9ASPrKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzA2Dq45bfqDsbLbxwPMQpw MCrx8PIckI8SYk0sK67MPcQowcGsJMIbWAkU4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvSkzdK SCA9sSQ1OzW1ILUIJsvEwSnVwOgzm/FW+UZTliU7tcI+uusFcG3ndnKq25azqNw8yvHek0MT dkhdMGpfJvvOYD53sLWe16+zjZZp5r9eHFDnXKx25q6My7JJ/xZlfTqRsUY+9PLMWxOcWz0b 7XYdMjisuKjM7n3DfAt1z2satu8TMtrv7g1aMqdZiG1e4aldahbmkoJGU3aK5iixFGckGmox FxUnAgBVtfYpqQIAAA== 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, 30 Nov 2017 08:39:11 -0000 Hi, I don=B9t think that (2) is enough. In the deployment case that triggered the problem, there would never be a chance to send the clarification UDPATE, because the INVITE is rejected. So, I still think we shall clarify the procedures, and restrict what can be done in UPDATEs sent within INVITEs. For example, one must not change the refresher etc., and whatever comes in the 2xx/INVITE matters. Again, in the deployment case, that should be rather easy to fix, because the impact will be on an limited number of application servers - not on thousands of UAs. Regarding Roland=B9s proxy case, we can clarify that a proxy must not chang= e the timer value in a response. Regards, Christer On 29/11/17 18:35, "Paul Kyzivat" wrote: >We have wandered around quite a bit on this. I'm not sure if we are >converging or not. I'm going to try to restate the problem, taking >advantage of the insights that we've had in the discussion. > >The Problem: > >Even when all parties comply with RFC4028 it is possible to end with >differences of opinion among the parties about the negotiated session >timer values: the session expiration time, the min-s-e, and/or the >refresher. > >In some cases these ambiguities are benign in that the session will >still get refreshed by somebody who is willing to do so within a time >interval that is acceptable to all. And the refresh may well clear up >the ambiguity. > >However there are some cases that are not so benign. For instance, it is >possible to arrive at a situation where neither UA believes it is the >refresher, and so the session will never get refreshed. > >Possible Solutions (in the abstract): > >1) Revise/clarify the rules of RFC4028 to eliminate the ambiguities. > >An issue with this is that it only eliminates all the problems if all >the parties in the call (UAC, UAS, and proxies) implement this update. >In principle Require and Proxy-Require could be used to ensure that all >parties support the update. But in practice there is no good way to roll >that out, and it is generally more important that calls succeed. > >2) If a UA in the call detects that the call has ended up in a state >that causes a non-benign ambiguity it should immediately initiate a >session refresh to remove the ambiguity. > >In most cases it should be possible for at least one end to detect the >situation. The only exception I can think of is when neither UA supports >this extension but a proxy does. I think the proxy is helpless in this >case and I don't see any fix other than the proxy causing the INVITE to >fail. > >ISTM that doing (1) isn't a sufficient solution, while (2) is. So I >think we should concentrate on that first. > >A really simple algorithm for this would be that if an UPDATE was used >within an INVITE then once the INVITE completes then the end that thinks >it is now UAS (non refresher) should immediately do a refresh using >UPDATE. This would clarify who is refresher and fix the case where >neither end think they are the refresher. And it would clarify any >ambiguity in s-e and min-s-e. > >But that algorithm is inefficient in that it will be sent in many cases >where it isn't needed. I think we can narrow the conditions when it >needs to be sent, so that it is only sent if there actually is >non-benign ambiguity. > >I think (2) is probably sufficient. If we wanted to go further, then we >could *also* do (1). > > Thanks, > Paul > > >On 11/29/17 2:31 AM, Christer Holmberg wrote: >> Hi, >>=20 >> It is really difficult to reference specific messages when there is no >> call flow. >>=20 >> But, in my opinion, whatever is sent in the 2xx/INVITE matters. >>=20 >> I also think it would be a good idea for the UAS to actually include a >> timer value in the UPDATE request - the same timer value that it will >> later include in the 2xx/INVITE. The proxy may still of course lower the >> value, but perhaps it would simply pass it. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >> On 29/11/17 03:37, "sipcore on behalf of Paul Kyzivat" >> wrote: >>=20 >>> On 11/28/17 7:46 PM, R.Jesske@telekom.de wrote: >>>> Hi Roman, >>>> >>>> Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards >>>> UAS. >>>> >>>> 1st negotiation is ongoing. >>>> >>>> 18x/PRACK/200OK(PRACK) is exchanged. >>>> >>>> Now UAS is sending UPDATE with a supported timer and Proxy adds S-E >>>>due >>>> to local policy with S-E 1800. >>> >>> If that is its policy, why didn't it also reduce the S-E to 1800 in the >>> INVITE? If it had done that there wouldn't be a problem. >>> >>>> So what will the UAC do. The proxy has added the S-E. >>> >>> The case you presented, where the proxy is inconsistent between INVITE >>> and UPDATE, does present a problem. The UA could send S-E 1800 in the >>> 200/UPDATE. But what the other end does in that case is undefined. >>> >>> What you have demonstrated here is that there is an issue with the S-E >>> value as well as with the refresher role. >>> >>>> UAC (Which has sent the INVITE) could ignore and send 200 OK without >>>> any >>>> S-E. i.e. ignoring UPDATE. >>>> >>>> In this case, what is the then proxy doing? Passing 200OK w/o S-E or >>>> may >>>> it add an S-E again? Assuming it adds S-E 1800 because it remembers >>>> that >>>> the UPDATE was received with supported timer. >>>> >>>> What does the UAS do? Ignoring the 200 OK with SE or accepting? >>>> >>>> And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 >>>>as >>>> proposed by the INVITE, because the UAS is ignoring the 200 OK >>>>(UPDATE) >>>> with S-E 1800? >>>> >>>> Or do you think that his is a wrong implementation. >>> >>> I think it is a stupid implementation. AFAIK there is nothing in 4028 >>> that says it is wrong. >>> >>> I think the fix I sketched in a mail a few hours ago can probably be >>> extended to cover this case. Notably, if one side detects an ambiguity >>> in one or more of the negotiated s-t values, and that ambiguity has >>> negative consequences, then it should initiate an immediate s-t refresh >>> to fix it. >>> >>> We just need to sort out what all the ambiguities are and how to detect >>> them. >>> >>> Thanks, >>> Paul >>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> *Von:* sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von >>>>*Roman >>>> Shpount >>>> *Gesendet:* Mittwoch, 29. November 2017 00:07 >>>> *An:* Jesske, Roland >>>> *Cc:* SIPCORE >>>> *Betreff:* Re: [sipcore] Session timer fix >>>> >>>> Roland, >>>> >>>> Please provide the exact scenario. What you seem to be describing are >>>> misconfigured proxies or clients that do not follow existing >>>> specifications. >>>> >>>> Regards, >>>> >>>> _____________ >>>> Roman Shpount >>>> >>>> On Tue, Nov 28, 2017 at 5:33 PM, >>> > wrote: >>>> >>>> Hi Paul, >>>> We have different issues where we have look on. >>>> And we see that we have UPDATE with an S-T causing a lot of >>>>trouble. >>>> This is dependent on different use cases. >>>> One is that the UA does not support UPDATE. >>>> Yes that is true. >>>> But one of the main problems are the proxies in between. >>>> Either proxies do not react which is OK. >>>> And the UAC interpreting the 200OK. >>>> Also the direction of the UPDATE is important. >>>> Also the behavior of the proxy. We have seen proxies adding S-T >>>>to >>>> the UPDATE due to the fact that session timer supported is set. >>>>The >>>> S-T values where different to that set by the UAC. >>>> >>>> So as you said we can identify all use cases. And I think that is >>>> what we need or real clear rules for UAC/UAS and Proxy. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> >>>> > -----Urspr=FCngliche Nachricht----- >>>> > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >>>> ] >>>> > Gesendet: Dienstag, 28. November 2017 21:31 >>>> > An: Christer Holmberg >>> >; Roman Shpount >>>> > > >>>> > Cc: Jesske, Roland >>> >; sipcore@ietf.org >>>> >>>> > Betreff: Re: [sipcore] Session timer fix >>>> >>>> > >>>> > On 11/28/17 2:53 PM, Christer Holmberg wrote: >>>> > > Hi, >>>> > > >>>> > >>> 1. What happens when UAC receives a 2XX INVITE response >>>>with >>>> S-T >>>> > >>> that did not match the S-T value negotiated by UPDATE >>>> transaction >>>> > during this INVITE transaction? >>>> > >> >>>> > >> Error case. >>>> > >> >>>> > >>> 2. What happens when UAC receives a 2XX UPDATE response >>>>with >>>> S-T >>>> > >>> that did not match the 2XX response for the previous >>>>UPDATE >>>> > transaction? >>>> > >> >>>> > >> Error case. >>>> > >> >>>> > >> How do you want to handle these error cases? Two options >>>>that >>>> I see are: >>>> > >> a. Terminate the dialog (hang up) >>>> > >> b. Issue a new UPDATE to set refresher to a known state. >>>> > > >>>> > > Those are two alternatives, yes. I don't think we need to >>>> mandate any >>>> > specific behaviour, as long as we make it clear that an error >>>>has >>>> occurred and >>>> > it needs to be taken care of SOMEHOW. >>>> > >>>> > Or you can just ignore the error and hope for the best. >>>> > >>>> > My intuition tells me that this will rarely cause a problem. >>>>Most >>>> of the time a >>>> > device that doesn't support the update will be compliant with >>>>the >>>> update by >>>> > accident. And in a bunch of the remaining cases ignoring a >>>> conflicting value in >>>> > the nested UPDATE won't matter because both ends will settle >>>>on >>>> what is in >>>> > the 200/INVITE. And the remaining cases will result in both >>>>ends >>>> thinking >>>> > they are UAC or UAS. It isn't a problem if they both think >>>>they >>>> are the UAC, >>>> > since then both will attempt to refresh. It is only a problem >>>>if >>>> they both think >>>> > they are UAS, since that is the only case when the session >>>>won't >>>> be >>>> > refreshed. If that happens, is it worse than having had the >>>>call >>>> fail? >>>> > >>>> > If need be we can work through all the cases. But there are >>>>quite >>>> a lot of >>>> > them. >>>> > >>>> > Thanks, >>>> > Paul >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Thu Nov 30 02:19: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 680B21293EC for ; Thu, 30 Nov 2017 02:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 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_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 (1024-bit key) header.d=metaswitch.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 oWMonSPRi0wl for ; Thu, 30 Nov 2017 02:19:31 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0136.outbound.protection.outlook.com [104.47.34.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC911293E9 for ; Thu, 30 Nov 2017 02:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JU78q9r9PJ3Qe3r12qk1Mtf3qqhGtiyxWmoVcBudEMg=; b=XIr0uT0AQa21RNFVgKgXmcdbecxs9y9KsJO/+0Ws5fcliGwYAFg99pAkfI3z6UMaD3JWGbufmuXO3Rp2Sbu89ZIZLiNXc0URr6wvIf70/Wy7QcXGHc40C0KGYr5j75i0oGo39nL141wDUOrt3IlUnkaFTqbC/00zEsN+4YAkkqc= Received: from CY1PR02MB1262.namprd02.prod.outlook.com (10.163.16.155) by CY1PR02MB1262.namprd02.prod.outlook.com (10.163.16.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Thu, 30 Nov 2017 10:19:27 +0000 Received: from CY1PR02MB1262.namprd02.prod.outlook.com ([10.163.16.155]) by CY1PR02MB1262.namprd02.prod.outlook.com ([10.163.16.155]) with mapi id 15.20.0282.006; Thu, 30 Nov 2017 10:19:27 +0000 From: Mickey Arnold To: "sipcore@ietf.org" Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push Thread-Index: AQHTaRlSF4NgtCk8vkKzUqkjhLyIpqMr13SAgAAB04CAAAS+gIAAFfqAgAAgDICAAKKOAA== Date: Thu, 30 Nov 2017 10:19:27 +0000 Message-ID: References: , <7594FB04B1934943A5C02806D1A2204B6C02DB78@ESESSMB109.ericsson.se> <3A3CE3A5-28EF-40D2-8704-FEA60B9392A4@att.com> <23384_1511995248_5A1F3770_23384_69_1_8B970F90C584EA4E97D5BAAC9172DBB81D672A54@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Arnold@metaswitch.com; x-originating-ip: [2620:104:4000:206e:9ca0:ac6e:7070:70da] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR02MB1262; 6:MbGctcWCD6KCb+CkOsSqbpJiRLD7gXkqhUzt7zgGq6Q8ImuQpGM4SHUIBuYHH4z/2+rppX2x3GAW0kqzdPfue2fKYPk8kaoOqXu/gZ68iD41cYxmZR2OQfeel8PtbOcF2+6QXLPjKvnfkJL2O1vU9/+Lpwisw8BImoLdI/oDS1GJmATw0d7/tb5B867lznZJYtXrPCcYyxNMiMnHb9eD7Xvt/ntZ6BxbJtJMlU3xnxCZVoiX2KTIB05TXZM5/048/bMZjbIKIXttgzpnZ9Ck97I8xtdDZ76B7l+HGqhVO//2/DGZ753S32CE9ZFBafM7CnpgtMOJfM//Ryz5kSM+lUJSD7Blwo2BB/ygtdYJ6TU=; 5:M6x6o6Of/gp74UqIUd1YQTo/RXvOGxcsgD4qvvCastJU/R060PfXirry7McjcwsE8qjLlMuRwONJahTknVtWILBTAxlcgRCJ91/o0YIJrtqb/Iv94Q0e7T/3ARjbx8wFtg3E0ehoj2MYHsCPgsDSfpemWTotTwZlbGuK8KNWiDE=; 24:lYFkSCRRmSbyppopuOWSpN3F90MzWCVmTopdqoRpbCF486XMxjIumDQdb9CHJJ4nFQNFo9oxyxBn6FNpGnzDvBm97mV+v3loCdo5rqStye8=; 7:k/Y3vDUvogA6Y3xW6ZDc7SUa/Amn8WjdkW/+sghqTGrugLGG3TGCAxasu1bOqeMHxjmbiuJ0SgNTEGgJbhH3ieycDESo1Ciobh5qiyCuJLm1YdQBhfiRv0l3OorEl/mRtGRludql2hf3crT5orLbvd4smmi0/aw9KfLt8P83U9Ohdv63rdb0Mk0NolO51UIl5KJIptmKOnSRIQruN77SsBp5Y1wCVUpvzQ3ZbnrmRQwt6oXX7DqEoGCyJtxc8A1k x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: efcb8530-5a20-4d69-d685-08d537dbd65c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603284); SRVR:CY1PR02MB1262; x-ms-traffictypediagnostic: CY1PR02MB1262: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(10436049006162)(97927398514766)(174211160506117)(227612066756510)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(6072148)(201708071742011); SRVR:CY1PR02MB1262; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR02MB1262; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(24454002)(199003)(13464003)(252514010)(189002)(8936002)(93886005)(99286004)(316002)(6436002)(77096006)(7696005)(55016002)(72206003)(5660300001)(86362001)(54356010)(3660700001)(575784001)(50986010)(478600001)(25786009)(7736002)(2906002)(76176010)(68736007)(325944009)(966005)(53936002)(189998001)(3280700002)(97736004)(236005)(2900100001)(5890100001)(6506006)(1730700003)(101416001)(33656002)(53546010)(102836003)(105586002)(74316002)(2501003)(6116002)(790700001)(230783001)(106356001)(5630700001)(5640700003)(6916009)(2950100002)(6306002)(81166006)(14454004)(229853002)(81156014)(54896002)(8676002)(9686003)(6246003)(606006)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR02MB1262; H:CY1PR02MB1262.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR02MB1262A3B6FA751CC4C879DB70E9380CY1PR02MB1262namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: efcb8530-5a20-4d69-d685-08d537dbd65c X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 10:19:27.5473 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1262 Archived-At: Subject: Re: [sipcore] Call For Adoption 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, 30 Nov 2017 10:19:39 -0000 --_000_CY1PR02MB1262A3B6FA751CC4C879DB70E9380CY1PR02MB1262namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of R.Jesske@telek= om.de Sent: 30 November 2017 00:35 To: marianne.mohali@orange.com; sipcore@ietf.org Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push +1 Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von marianne.moha= li@orange.com Gesendet: Mittwoch, 29. November 2017 23:41 An: SIPCORE > Betreff: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push +1 De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de VAN GEEL Jan (= SPC/CSP) Envoy=E9 : mercredi 29 novembre 2017 22:22 =C0 : SIPCORE Objet : Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push +1 From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C Sent: Wednesday 29 November 2017 22:05 To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push T supports Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Nov 29, 2017, at 3:58 PM, Christer Holmberg > wrote: I obviously support this :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 29 November 2017 15:52 To: SIPCORE > Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. = Please provide comments by December 13. _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3DhED16UGkOq2qm3N= sKr555cbkAEBPsai0YYvLqIyCCjU&e=3D ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer ___________________________________________________________________________= ______________________________________________ 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_CY1PR02MB1262A3B6FA751CC4C879DB70E9380CY1PR02MB1262namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1=

 =

From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
Sent: 30 November 2017 00:35
To: marianne.mohali@orange.com; sipcore@ietf.org
Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-= push

 

+1<= /o:p>

 

Von: sipcore= [mailto:sipcore-bounces@ietf.o= rg] Im Auftrag von mariann= e.mohali@orange.com
Gesendet: Mittwoch, 29. November 2017 23:41
An: SIPCORE <sipcore@ietf.org= >
Betreff: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-= push

 

+1

 

De : sipc= ore [mailto:sipcore-bounces@iet= f.org] De la part de VAN GEEL Jan (SPC/CSP)
Envoy=E9 : mercredi 29 novembre 2017 22:22
=C0 : SIPCORE
Objet : Re: [sipcore] Call For Adoption draft-holmberg-sipcore-= sip-push

 

+1

 

From: = sipcore [mailto:sipcore-bounces= @ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Wednesday 29 November 2017 22:05
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: SIPCORE <sipcore@ietf.org= >
Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-= push

 

T supports

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com


On Nov 29, 2017, at 3:58 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I obviously support this :)

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Brian Rosen
Sent: 29 November 2017 15:52
To: SIPCORE <sipcore@ietf.org>= ;
Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push

We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore document. =  Please provide comments by December 13.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https= ://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_list= info_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3D= hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&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=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSS= QhCmpw7ItG0r2g&m=3DxWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=3D= hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&e=3D

 


***** Disclaimer *****
http://www.proximus.be/ma= ildisclaimer

____________________________________________________=
_____________________________________________________________________<=
/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_CY1PR02MB1262A3B6FA751CC4C879DB70E9380CY1PR02MB1262namp_-- From nobody Thu Nov 30 08:38: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 A5F0F1293DA for ; Thu, 30 Nov 2017 08:38:40 -0800 (PST) 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 TpoGjQqliRCV for ; Thu, 30 Nov 2017 08:38:33 -0800 (PST) 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 2C6431293D8 for ; Thu, 30 Nov 2017 08:38:32 -0800 (PST) X-AuditID: 1207440c-7e5ff7000000143e-5e-5a203403030f 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 D2.6F.05182.304302A5; Thu, 30 Nov 2017 11:38:28 -0500 (EST) 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 vAUGcPL8010941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 30 Nov 2017 11:38:26 -0500 From: Paul Kyzivat To: "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> Message-ID: Date: Thu, 30 Nov 2017 11:38:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.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+NgFvrKIsWRmVeSWpSXmKPExsUixO6iqMtiohBlMOmHksXXH5vYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfVcP2vBnviKwxP3sDQwHvHoYuTkkBAwkdh4ahpzFyMXh5DA DiaJp8v2MYMkhAR+MEk8uB4KYrMJaEnMOfSfBcQWFtCQOLTnN5gtIqApsfzbVnaI5tvsEj9e b2MHSfAK2Eus2DaLFcRmEVCV+HVtDpgtKpAmsedCBwtEjaDEyZlPwGxOARuJlvszwWxmATOJ eZsfMkPY4hK3nsxngrDlJZq3zmaewMg/C0n7LCQts5C0zELSsoCRZRWjXGJOaa5ubmJmTnFq sm5xcmJeXmqRrqFebmaJXmpK6SZGSFjy7GD8tk7mEKMAB6MSD+8EYYUoIdbEsuLK3EOMkhxM SqK8b3SBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4lU/IRwnxpiRWVqUW5cOkpDlYlMR5VZeo +wkJpCeWpGanphakFsFkZTg4lCR4vxsBDRUsSk1PrUjLzClBSDNxcIIM5wEanmgIVMNbXJCY W5yZDpE/xWjM0dNz4w8Tx7OZrxuYhVjy8vNSpcR5W0HGCYCUZpTmwU2DpZZXjOJAzwnzvgep 4gGmJbh5r4BWMQGtylwO8kdxSSJCSqqBUXPFCx/vr3NOPk1/9dds/yPu3WvV3ercohfPMpg+ 094oXWhjb6Al6+kFl5e/D+Bcw3fD6orkDUut3392zohfW3jdvNux/vIjR7nHDhfkL925XniO facsi+mPzu2p6h1zNpwSi531KjVmWmnEdemY5Detso+///rl+29hHed7oWDdudJbLp3qfqbE UpyRaKjFXFScCAAAK7iHCAMAAA== 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, 30 Nov 2017 16:38:41 -0000 On 11/30/17 3:39 AM, Christer Holmberg wrote: > Hi, > > I don¹t think that (2) is enough. In the deployment case that triggered > the problem, there would never be a chance to send the clarification > UDPATE, because the INVITE is rejected. OK, that is an issue. > So, I still think we shall clarify the procedures, and restrict what can > be done in UPDATEs sent within INVITEs. For example, one must not change > the refresher etc., and whatever comes in the 2xx/INVITE matters. Again, > in the deployment case, that should be rather easy to fix, because the > impact will be on an limited number of application servers - not on > thousands of UAs. > > Regarding Roland¹s proxy case, we can clarify that a proxy must not change > the timer value in a response. More than that: If a proxy is going to insert or revise s-e or min-s-e in an UPDATE within an INVITE then it must do so consistently in the enclosing INVITE. Thanks, Paul > Regards, > > Christer > > > > > > > On 29/11/17 18:35, "Paul Kyzivat" wrote: > >> We have wandered around quite a bit on this. I'm not sure if we are >> converging or not. I'm going to try to restate the problem, taking >> advantage of the insights that we've had in the discussion. >> >> The Problem: >> >> Even when all parties comply with RFC4028 it is possible to end with >> differences of opinion among the parties about the negotiated session >> timer values: the session expiration time, the min-s-e, and/or the >> refresher. >> >> In some cases these ambiguities are benign in that the session will >> still get refreshed by somebody who is willing to do so within a time >> interval that is acceptable to all. And the refresh may well clear up >> the ambiguity. >> >> However there are some cases that are not so benign. For instance, it is >> possible to arrive at a situation where neither UA believes it is the >> refresher, and so the session will never get refreshed. >> >> Possible Solutions (in the abstract): >> >> 1) Revise/clarify the rules of RFC4028 to eliminate the ambiguities. >> >> An issue with this is that it only eliminates all the problems if all >> the parties in the call (UAC, UAS, and proxies) implement this update. >> In principle Require and Proxy-Require could be used to ensure that all >> parties support the update. But in practice there is no good way to roll >> that out, and it is generally more important that calls succeed. >> >> 2) If a UA in the call detects that the call has ended up in a state >> that causes a non-benign ambiguity it should immediately initiate a >> session refresh to remove the ambiguity. >> >> In most cases it should be possible for at least one end to detect the >> situation. The only exception I can think of is when neither UA supports >> this extension but a proxy does. I think the proxy is helpless in this >> case and I don't see any fix other than the proxy causing the INVITE to >> fail. >> >> ISTM that doing (1) isn't a sufficient solution, while (2) is. So I >> think we should concentrate on that first. >> >> A really simple algorithm for this would be that if an UPDATE was used >> within an INVITE then once the INVITE completes then the end that thinks >> it is now UAS (non refresher) should immediately do a refresh using >> UPDATE. This would clarify who is refresher and fix the case where >> neither end think they are the refresher. And it would clarify any >> ambiguity in s-e and min-s-e. >> >> But that algorithm is inefficient in that it will be sent in many cases >> where it isn't needed. I think we can narrow the conditions when it >> needs to be sent, so that it is only sent if there actually is >> non-benign ambiguity. >> >> I think (2) is probably sufficient. If we wanted to go further, then we >> could *also* do (1). >> >> Thanks, >> Paul >> >> >> On 11/29/17 2:31 AM, Christer Holmberg wrote: >>> Hi, >>> >>> It is really difficult to reference specific messages when there is no >>> call flow. >>> >>> But, in my opinion, whatever is sent in the 2xx/INVITE matters. >>> >>> I also think it would be a good idea for the UAS to actually include a >>> timer value in the UPDATE request - the same timer value that it will >>> later include in the 2xx/INVITE. The proxy may still of course lower the >>> value, but perhaps it would simply pass it. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> On 29/11/17 03:37, "sipcore on behalf of Paul Kyzivat" >>> wrote: >>> >>>> On 11/28/17 7:46 PM, R.Jesske@telekom.de wrote: >>>>> Hi Roman, >>>>> >>>>> Invite with S-E 3600 is sent by the UAC. Proxy let INVITE pass towards >>>>> UAS. >>>>> >>>>> 1st negotiation is ongoing. >>>>> >>>>> 18x/PRACK/200OK(PRACK) is exchanged. >>>>> >>>>> Now UAS is sending UPDATE with a supported timer and Proxy adds S-E >>>>> due >>>>> to local policy with S-E 1800. >>>> >>>> If that is its policy, why didn't it also reduce the S-E to 1800 in the >>>> INVITE? If it had done that there wouldn't be a problem. >>>> >>>>> So what will the UAC do. The proxy has added the S-E. >>>> >>>> The case you presented, where the proxy is inconsistent between INVITE >>>> and UPDATE, does present a problem. The UA could send S-E 1800 in the >>>> 200/UPDATE. But what the other end does in that case is undefined. >>>> >>>> What you have demonstrated here is that there is an issue with the S-E >>>> value as well as with the refresher role. >>>> >>>>> UAC (Which has sent the INVITE) could ignore and send 200 OK without >>>>> any >>>>> S-E. i.e. ignoring UPDATE. >>>>> >>>>> In this case, what is the then proxy doing? Passing 200OK w/o S-E or >>>>> may >>>>> it add an S-E again? Assuming it adds S-E 1800 because it remembers >>>>> that >>>>> the UPDATE was received with supported timer. >>>>> >>>>> What does the UAS do? Ignoring the 200 OK with SE or accepting? >>>>> >>>>> And then what will the UAS do? Sending 200 OK (INVITE) with S-E 3600 >>>>> as >>>>> proposed by the INVITE, because the UAS is ignoring the 200 OK >>>>> (UPDATE) >>>>> with S-E 1800? >>>>> >>>>> Or do you think that his is a wrong implementation. >>>> >>>> I think it is a stupid implementation. AFAIK there is nothing in 4028 >>>> that says it is wrong. >>>> >>>> I think the fix I sketched in a mail a few hours ago can probably be >>>> extended to cover this case. Notably, if one side detects an ambiguity >>>> in one or more of the negotiated s-t values, and that ambiguity has >>>> negative consequences, then it should initiate an immediate s-t refresh >>>> to fix it. >>>> >>>> We just need to sort out what all the ambiguities are and how to detect >>>> them. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Best Regards >>>>> >>>>> Roland >>>>> >>>>> *Von:* sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von >>>>> *Roman >>>>> Shpount >>>>> *Gesendet:* Mittwoch, 29. November 2017 00:07 >>>>> *An:* Jesske, Roland >>>>> *Cc:* SIPCORE >>>>> *Betreff:* Re: [sipcore] Session timer fix >>>>> >>>>> Roland, >>>>> >>>>> Please provide the exact scenario. What you seem to be describing are >>>>> misconfigured proxies or clients that do not follow existing >>>>> specifications. >>>>> >>>>> Regards, >>>>> >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> On Tue, Nov 28, 2017 at 5:33 PM, >>>> > wrote: >>>>> >>>>> Hi Paul, >>>>> We have different issues where we have look on. >>>>> And we see that we have UPDATE with an S-T causing a lot of >>>>> trouble. >>>>> This is dependent on different use cases. >>>>> One is that the UA does not support UPDATE. >>>>> Yes that is true. >>>>> But one of the main problems are the proxies in between. >>>>> Either proxies do not react which is OK. >>>>> And the UAC interpreting the 200OK. >>>>> Also the direction of the UPDATE is important. >>>>> Also the behavior of the proxy. We have seen proxies adding S-T >>>>> to >>>>> the UPDATE due to the fact that session timer supported is set. >>>>> The >>>>> S-T values where different to that set by the UAC. >>>>> >>>>> So as you said we can identify all use cases. And I think that is >>>>> what we need or real clear rules for UAC/UAS and Proxy. >>>>> >>>>> Best Regards >>>>> >>>>> Roland >>>>> >>>>> >>>>> > -----Ursprüngliche Nachricht----- >>>>> > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >>>>> ] >>>>> > Gesendet: Dienstag, 28. November 2017 21:31 >>>>> > An: Christer Holmberg >>>> >; Roman Shpount >>>>> > > >>>>> > Cc: Jesske, Roland >>>> >; sipcore@ietf.org >>>>> >>>>> > Betreff: Re: [sipcore] Session timer fix >>>>> >>>>> > >>>>> > On 11/28/17 2:53 PM, Christer Holmberg wrote: >>>>> > > Hi, >>>>> > > >>>>> > >>> 1. What happens when UAC receives a 2XX INVITE response >>>>> with >>>>> S-T >>>>> > >>> that did not match the S-T value negotiated by UPDATE >>>>> transaction >>>>> > during this INVITE transaction? >>>>> > >> >>>>> > >> Error case. >>>>> > >> >>>>> > >>> 2. What happens when UAC receives a 2XX UPDATE response >>>>> with >>>>> S-T >>>>> > >>> that did not match the 2XX response for the previous >>>>> UPDATE >>>>> > transaction? >>>>> > >> >>>>> > >> Error case. >>>>> > >> >>>>> > >> How do you want to handle these error cases? Two options >>>>> that >>>>> I see are: >>>>> > >> a. Terminate the dialog (hang up) >>>>> > >> b. Issue a new UPDATE to set refresher to a known state. >>>>> > > >>>>> > > Those are two alternatives, yes. I don't think we need to >>>>> mandate any >>>>> > specific behaviour, as long as we make it clear that an error >>>>> has >>>>> occurred and >>>>> > it needs to be taken care of SOMEHOW. >>>>> > >>>>> > Or you can just ignore the error and hope for the best. >>>>> > >>>>> > My intuition tells me that this will rarely cause a problem. >>>>> Most >>>>> of the time a >>>>> > device that doesn't support the update will be compliant with >>>>> the >>>>> update by >>>>> > accident. And in a bunch of the remaining cases ignoring a >>>>> conflicting value in >>>>> > the nested UPDATE won't matter because both ends will settle >>>>> on >>>>> what is in >>>>> > the 200/INVITE. And the remaining cases will result in both >>>>> ends >>>>> thinking >>>>> > they are UAC or UAS. It isn't a problem if they both think >>>>> they >>>>> are the UAC, >>>>> > since then both will attempt to refresh. It is only a problem >>>>> if >>>>> they both think >>>>> > they are UAS, since that is the only case when the session >>>>> won't >>>>> be >>>>> > refreshed. If that happens, is it worse than having had the >>>>> call >>>>> fail? >>>>> > >>>>> > If need be we can work through all the cases. But there are >>>>> quite >>>>> a lot of >>>>> > them. >>>>> > >>>>> > Thanks, >>>>> > Paul >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Thu Nov 30 08:39: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 B6F4D129401 for ; Thu, 30 Nov 2017 08:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CUK1lWIkc6um for ; Thu, 30 Nov 2017 08:39:23 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3A21293D8 for ; Thu, 30 Nov 2017 08:39:23 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id l24so3329851pfj.6 for ; Thu, 30 Nov 2017 08:39:23 -0800 (PST) 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=SJMqS/uW86CJyT5Ob51eMaTyz7zfuntwSZe49Bu02JI=; b=hl6bksvqTw5hqYVAF/iHpzkkkC4psa095lgFG/xgY2jaECPwPVeutibcIlS5bOgOlE MgqyZOB3mTt6SVMGbFcFUYSQbuIjL2mJRvUBa/l2FSBFmi06ybvi0w3mJWaGQGL9Lfzr Svn05O9Lgz61Bgfy8nbvDJZbWBhn8CouI2pa7AilOYAFx772JJecRLyzTLZE38O/1Sue IPS5+/NgvmlRzvhA+H9w7jGsAMlpLQA7LZsRpvdowAKK4BGZSb+2r3kThQaQ8B+hCa57 UJT9AaFwG2o5QKv4QKASoqv/+rsEWs9xAdBNBeMUaOcznlHGRO62ucWY8hI/nW3Iwvco THCQ== 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=SJMqS/uW86CJyT5Ob51eMaTyz7zfuntwSZe49Bu02JI=; b=OoqAquJGyyEEhuvJtaq0dKVF+mqAlPXfdg90LE8j9IIb2sxFBAC03YhUVNxG8+6Zuf qLza0Kq7FAGqrBuuZTCazcMb5OeFG8tl17Z8grM2QgneSlb26lupxkeiTood/wRTKoK1 YmPGsUwBShVg5KyvwtLQvXJ7yGNPuJMTS94MDq0dihuK779UnbW1WLoxworNUa7w00aB RcgwczcNC/V50/SD811DXF9aBteeg3LgBrZDmmdYO9c0OTrDrXnq2ZPLXGhSyk4957Wc zgkYKNpk8mwlL1g2jB/TqWwRKAKpNhvVAlfNCR1YNAk84LY6R6E4IWwUe7bjbgObtRbS wVFA== X-Gm-Message-State: AJaThX4zwOd2JZlbG6/2c26pVjzWaITWp7/g2GNok4Swhec7swkn9vs1 U7qLFh7ofKiaHwmhTydF7NQTKOS7qjKSAUdXk+Wa3w== X-Google-Smtp-Source: AGs4zMYSPk8aJ0AJhytNYwoJsXurXnnLOh6b7NpHa0FjNW4HnmK7sYuUhByuNme5yr+Qn8fYG5ptMua5Mi/ZTjx1rWI= X-Received: by 10.99.117.19 with SMTP id q19mr2880042pgc.94.1512059963269; Thu, 30 Nov 2017 08:39:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.160.174 with HTTP; Thu, 30 Nov 2017 08:39:21 -0800 (PST) In-Reply-To: References: From: Ranjit Avasarala Date: Thu, 30 Nov 2017 10:39:21 -0600 Message-ID: To: Brian Rosen Cc: SIPCORE Content-Type: multipart/alternative; boundary="f403045c5b3cfd6750055f35e4e2" Archived-At: Subject: Re: [sipcore] Call For Adoption 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, 30 Nov 2017 16:39:26 -0000 --f403045c5b3cfd6750055f35e4e2 Content-Type: text/plain; charset="UTF-8" Hi I have one comment on the draft In section 3, Push Resource ID (PRID), the sentence should be modified to - When an entity registers with a Push Notification Server (PNS),* it (instead of is)* receives a a unique Push Resource ID (PRID) , which is a value associated with the registration Regards Ranjit On Wed, Nov 29, 2017 at 7:52 AM, Brian Rosen wrote: > We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore > document. Please provide comments by December 13. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --f403045c5b3cfd6750055f35e4e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi
I have one comment on the draft

In section 3, Push Resource ID (PRID), the sentence should be modifie= d to -=C2=A0When an en= tity registers with a Push Notification Server (PNS), it (instead of is)= receives a=C2=A0a unique Push Resource ID (PRID) , which is a value=C2=A0associated with the registr= ation=C2=A0

Regards
Ranjit

On Wed, Nov 29, 2017 at 7:52 AM, Brian Ros= en <br@brianrosen.net> wrote:
We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore d= ocument.=C2=A0 Please provide comments by December 13.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--f403045c5b3cfd6750055f35e4e2-- From nobody Thu Nov 30 09:07: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 7B05212762F for ; Thu, 30 Nov 2017 09:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 AxNb8nNV6rQR for ; Thu, 30 Nov 2017 09:07:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 518C4127876 for ; Thu, 30 Nov 2017 09:07:25 -0800 (PST) Received: from [172.16.14.112] ([12.69.88.45]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0M3u86-1fC0Oe3gXq-00rVLs for ; Thu, 30 Nov 2017 18:07:23 +0100 To: "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C02DB78@ESESSMB109.ericsson.se> <3A3CE3A5-28EF-40D2-8704-FEA60B9392A4@att.com> <23384_1511995248_5A1F3770_23384_69_1_8B970F90C584EA4E97D5BAAC9172DBB81D672A54@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Georg Mayer Message-ID: <18756227-3b49-06f0-8426-5f54977b3b50@gmx.com> Date: Thu, 30 Nov 2017 09:07:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:xibvx8FbuwXphlH+6rOsmlJoKU7tZSf/Vxm8sR7AJgQm/T2Dh4t zGJZkDEhY/5Femt0jJo0UXxW7WFlq7yDcQmwfb5Mx8n4I0QR7vfJQUJ4Vi6P9ZAfDKfIHAv bWVt4UY+Q7RBVBn4Y1YFWelt0xKLXNcZbQn5ARJB65w1rxjWRUmO911F0yAO2gR7GJR+Yux WkPDduqzKKbutRoEajQrw== X-UI-Out-Filterresults: notjunk:1;V01:K0:GTZ0yTE5nts=:pCQblx68AZ9AVf9AVVvQm4 smRlqB6dCKNTaFXc+2mq8/PYtaMNaFtaE5fcynW0JuGvOin22VZ7rZ8lRRTT8lBCJ6Ql5Ykp3 MizLQrL0HXfFN+SAq1uiOeL0qSxylfwfOVRJO0mVZD1RQO2MygcXf/tPy3ZT25rxikORnnsDB UevTZirJ7VeiIAJ+teAPAKECONdZKsya87NsDsV5/XtZ2/odU8ZCUUhN/5vat7tIG5+7p7QVY dn+iddJ3AJyvTMKXugMJ7TFekYY8nBnW35272FSwrSzZysIvtY/GnkucUvw3UYzfgxNZF5AHS lMcmmm/Ykm7+X3OGqrbt/itgD3NYmcF2OfDFxVJp05P2yr5X7S6utYsVyEAMvV4EI1HJkjzwF j1d2Fb9Q+VOCoIYV/bUfaGocYexCRwUf+VzrPu3JO0XXezp83j0iToYXnbbV8Q8u2JM+etY9Y ZucFClIqzC9W/kBbtwTd2Pl72DUscvl7/b/dv+3eEAKFe+Jps+6HQpOTNWxCByeI85hthwSlf y54fcrdi/Q6ynsbIe0o8c4+lzUNkBNnRV+255ISj1qff25xxgPaiuFxTyeBoVHgKuNMN09f2y IysB5gALpVAYlq6eGyHKaKIkkLnE4fG2OJ/ecNspLB+pS1AKmDTaFhHn5TKq9Iy6kr9ArqEia Ch5sImHH527/tdmhAvapurntlw8Ga1jWTCRrYlc3NqJa+206OgNgtmQQZrACoH42ELyJQ6ui3 m0CH6jioVgeKOni6zEiMZh6962kUy9m3O3iBUKihTtoQtTcVhjP75kW/i/a8diRFxVKDEpaJJ WnG/8JcsbtbnZM6wyIlyLf5nwwYfhVSGN+SJM8+yqZ3I6soVfCLqwGqISyqKw3zR8x0ivvu Archived-At: Subject: Re: [sipcore] Call For Adoption 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, 30 Nov 2017 17:07:28 -0000 +1 On 2017-11-30 02:19, Mickey Arnold wrote: > +1 > > > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of > *R.Jesske@telekom.de > *Sent:* 30 November 2017 00:35 > *To:* marianne.mohali@orange.com; sipcore@ietf.org > *Subject:* Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push > > > > +1 > > > > *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von > *marianne.mohali@orange.com > *Gesendet:* Mittwoch, 29. November 2017 23:41 > *An:* SIPCORE > > *Betreff:* Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push > > > > +1 > > > > *De:*sipcore [mailto:sipcore-bounces@ietf.org] *De la part de* VAN GEEL > Jan (SPC/CSP) > *Envoy:* mercredi 29 novembre 2017 22:22 > *:* SIPCORE > *Objet:* Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push > > > > +1 > > > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *DOLLY, > MARTIN C > *Sent:* Wednesday 29 November 2017 22:05 > *To:* Christer Holmberg > > *Cc:* SIPCORE > > *Subject:* Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push > > > > T supports > > Martin C. Dolly > Lead Member of Technical Staff > Core & Government/Regulatory Standards > AT&T > Cell:+1.609.903.3360 > Email:md3135@att.com > > > On Nov 29, 2017, at 3:58 PM, Christer Holmberg > > > wrote: > > I obviously support this :) > > Regards, > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: 29 November 2017 15:52 > To: SIPCORE > > Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push > > We propose to adopt draft-holmberg-sipcore-sip-push as a sipcore > document. Please provide comments by December 13. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&e= > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xWeP9COcTk49qnWD4ntEYEM8qVzZj-3W_C_TjKdussk&s=hED16UGkOq2qm3NsKr555cbkAEBPsai0YYvLqIyCCjU&e= > > > > > ------------------------------------------------------------------------ > > > ***** Disclaimer ***** > http://www.proximus.be/maildisclaimer > > _________________________________________________________________________________________________________________________ > > > > 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. > > > > 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. > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > -- Georg Mayer 3GPP CT Chairman HUAWEI Technologies Mobile: +43 699 1900 5758 From nobody Thu Nov 30 09:50: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 CF3B7127873 for ; Thu, 30 Nov 2017 09:50:32 -0800 (PST) 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 U5vVKPRZTHko for ; Thu, 30 Nov 2017 09:50:29 -0800 (PST) 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 B86C4126D85 for ; Thu, 30 Nov 2017 09:50:28 -0800 (PST) X-AuditID: c1b4fb30-093dd9c0000029e3-32-5a2044e2a056 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 80.77.10723.2E4402A5; Thu, 30 Nov 2017 18:50:26 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Thu, 30 Nov 2017 18:49:34 +0100 From: Christer Holmberg To: Ranjit Avasarala , Brian Rosen CC: SIPCORE Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push Thread-Index: AQHTaRlSj083iGbuAUSRkgieoJz4pqMtEJWAgAAjcVA= Date: Thu, 30 Nov 2017 17:49:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C031C89@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbE9RPeRi0KUwbPbChZP709js9jV38tq 8fXHJjYHZo/73/6ye+ycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGccXLmEvuMdecb1/D0sD 4xH2LkZODgkBE4lzjSuYuhi5OIQEDjNKLDh8hhHCWcIosefqO9YuRg4ONgELie5/2iANIgKB Eld/7GUGsZkF5CSuf9jIBmILC3hIzJ6/mw2ixlNi78WPTCCtIgJWEreniYCYLAKqEsvnB4GY vAK+ElOP5UAs6mCUuLH2ANhETqDpm+e/YgSxGQXEJL6fWsMEsUlc4taT+UwQJwtILNlznhnC FpV4+fgfK4StJNG45AnYwcwCmhLrd+lDtCpKTOl+CPYtr4CgxMmZT1gmMIrOQjJ1FkLHLCQd s5B0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGDMHt/w22MH48rnjIUYBDkYlHl4n DYUoIdbEsuLK3EOMEhzMSiK8KU5AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATSE0tS s1NTC1KLYLJMHJxSDYx5Qt+N/5YqbNhxMJLjRBB7x6zZLedfTNvbICtrYnZeTfvK/H0rVAqi lY02ibQWXpmWLZ/Jt21SrsSnog2PL3uG3jR0+9vbGd16LPxh1Ly13fe+FF1X12T+lzu9gaPD J7ZcYcGSKbuvlRS61nFL3vGUXp09v8nw5wr2S7e+CelWN239Hl2YmaHEUpyRaKjFXFScCACC s9nGlQIAAA== Archived-At: Subject: Re: [sipcore] Call For Adoption 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, 30 Nov 2017 17:50:33 -0000 SGksDQoNCj4gSSBoYXZlIG9uZSBjb21tZW50IG9uIHRoZSBkcmFmdA0KPg0KPiBJbiBzZWN0aW9u IDMsIFB1c2ggUmVzb3VyY2UgSUQgKFBSSUQpLCB0aGUgc2VudGVuY2Ugc2hvdWxkIGJlIG1vZGlm aWVkIHRvIC3CoFdoZW4gYW4gZW50aXR5IHJlZ2lzdGVycyB3aXRoIGEgDQo+IFB1c2ggTm90aWZp Y2F0aW9uIFNlcnZlciAoUE5TKSwgaXQgKGluc3RlYWQgb2YgaXMpIHJlY2VpdmVzIGHCoHVuaXF1 ZSBQdXNoIFJlc291cmNlIElEIChQUklEKSAsIHdoaWNoIGlzIGEgdmFsdWXCoA0KPiBhc3NvY2lh dGVkIHdpdGggdGhlIHJlZ2lzdHJhdGlvbsKgDQoNCkkgd2lsbCBmaXggdGhhdCBpbiB0aGUgbmV4 dCB2ZXJzaW9uLg0KDQpUaGFua3MhDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KT24gV2Vk LCBOb3YgMjksIDIwMTcgYXQgNzo1MiBBTSwgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0 PiB3cm90ZToNCldlIHByb3Bvc2UgdG8gYWRvcHQgZHJhZnQtaG9sbWJlcmctc2lwY29yZS1zaXAt cHVzaCBhcyBhIHNpcGNvcmUgZG9jdW1lbnQuwqAgUGxlYXNlIHByb3ZpZGUgY29tbWVudHMgYnkg RGVjZW1iZXIgMTMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQo= From nobody Thu Nov 30 11:43: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 75AC012945D for ; Thu, 30 Nov 2017 11:43:53 -0800 (PST) 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 1ECNsPJ62y5V for ; Thu, 30 Nov 2017 11:43:51 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 CA74D126CE8 for ; Thu, 30 Nov 2017 11:43:51 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id e3so3545900pfi.10 for ; Thu, 30 Nov 2017 11:43:51 -0800 (PST) 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=C9JgYEXbKhuAnRI3yxjF8EKfIl6gYVoLwsnktqji9Kk=; b=PzmUbxOC3I9QUOkZKyEAqb0BbDKoaPrjTOI/cqWfpjqVeg6Nc04PZpF+b7RXSEWY4K AQHRBQ1Dk1LJE1XBw/aReRjVicaijJB0dSJyEQITcqbf0MwmsdVgL3MjYHJG7K8bF3Mr 9yYFN2diGRR7nVWJbQTYf2zCvTrIOqFhQwjLmCUfhp9LFRimKXd4sGyvsSolTVLmn3bV zsu6kHei/5PbX2GCVE8x6VHsKqNgzxaa8ElANA+fGPUSNNZbHp2xJ/oxFGzt0CRe1qBj kSli/RPyAx1eJFbBmYaRxbye1QvCh0T1E2rDNeXRI5Fz9mrMrjm2Y1uHwDJU7G2RoKBq rk+Q== 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=C9JgYEXbKhuAnRI3yxjF8EKfIl6gYVoLwsnktqji9Kk=; b=M/WWg/MQEHB4Ph3ia0R19sHJANIX+CpINpsHondz63OZ/mYzg+oZp8VnTxL3BGmKli +rf5eySsrkEf4+oqYJAzOULBb9k/HjXKIpOhtsPbIqxCSbOjpMy7qrHEZh/r207cPZtY ey6Y4fxjJhwU78Dbs+hoXGLHwsm5aVTv4YJRzvRzCFxoyBZVVEZz2spbCIFPhOsoO2Bc 1pgJZT1lWWUSz+pjh/onXyAviE37Cd9Vlz7wYtxwCh3DyQYahxk0fXLN8M4CoLH/1rpy JHHJB2tAWFHpBWsNDLMelr8+iXzXTQcf64a4DHW4RWrCy6q04CISwZvRS1c21bFbUabQ 1SkQ== X-Gm-Message-State: AJaThX73Di54qSacCmE/zVdgs6o38vILY/MPJPuk7Oh8uGmpO1UJvIOL QF8Gqnf5ovZ9Kig/SxPEPr2XHENp X-Google-Smtp-Source: AGs4zMYZ+e+YsKzUXTjfY0gVUzB2Yw+baSYXk7mwMn9NdtYQMZ/Z2kIyFP12PB6iE/A5RIoNgwmiPA== X-Received: by 10.99.185.89 with SMTP id v25mr3412148pgo.110.1512071030919; Thu, 30 Nov 2017 11:43:50 -0800 (PST) Received: from mail-pl0-f46.google.com (mail-pl0-f46.google.com. [209.85.160.46]) by smtp.gmail.com with ESMTPSA id v28sm9536550pfl.118.2017.11.30.11.43.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 11:43:49 -0800 (PST) Received: by mail-pl0-f46.google.com with SMTP id g2so4865183pli.8 for ; Thu, 30 Nov 2017 11:43:49 -0800 (PST) X-Received: by 10.84.246.18 with SMTP id k18mr3792462pll.374.1512071029220; Thu, 30 Nov 2017 11:43:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Thu, 30 Nov 2017 11:43:47 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> From: Roman Shpount Date: Thu, 30 Nov 2017 14:43:47 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="089e082d74589269f2055f387815" 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, 30 Nov 2017 19:43:53 -0000 --089e082d74589269f2055f387815 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 30, 2017 at 11:38 AM, Paul Kyzivat wrote: > On 11/30/17 3:39 AM, Christer Holmberg wrote: > >> I don=C2=B9t think that (2) is enough. In the deployment case that trigg= ered >> the problem, there would never be a chance to send the clarification >> UDPATE, because the INVITE is rejected. >> > > OK, that is an issue. I am not sure we can put a rule in the specification that prevents refusing INVITE requests randomly. It is not against any specification, just not extremely useful. Proposing that UA should not refuse INVITE transactions due to S-E settings mismatch and use an UPDATE transaction to clear S-E status (2) should be sufficient to address the original issue. So, I still think we shall clarify the procedures, and restrict what can >> be done in UPDATEs sent within INVITEs. For example, one must not change >> the refresher etc., and whatever comes in the 2xx/INVITE matters. Again, >> in the deployment case, that should be rather easy to fix, because the >> impact will be on an limited number of application servers - not on >> thousands of UAs. >> >> Regarding Roland=C2=B9s proxy case, we can clarify that a proxy must not= change >> the timer value in a response. >> > > More than that: If a proxy is going to insert or revise s-e or min-s-e in > an UPDATE within an INVITE then it must do so consistently in the enclosi= ng > INVITE. > I think proxy should be consistent about how it is inserting or updating s-e or min-s-e in general. There is little or no reason why what proxy does should change from transaction-to-transaction. There is one case here which is tricky: 1. UAC sends an INVITE without S-E 2. Proxy inserts S-E set to 3600 since it expects dialogs to expire after an hour 3. Within INVITE transaction UAC sends an UPDATE with S-E set to 1800 4. Proxy does not update S-E in UPDATE since dialog will be refreshed before it is expired by proxy UAS is confused since it got two messages, one with S-E 3600 and another with S-E 1800. It would be hard for the proxy to track what S-E value was used in the INVITE, since proxies are generally not dialog statefull. Even if proxy did track that value, it cannot simply increase the S-E in client UPDATE. Proposed solution -- UAS should pick the smallest S-E value and use that. Regards, _____________ Roman Shpount --089e082d74589269f2055f387815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Nov 30, 2017 at 11:= 38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 1= 1/30/17 3:39 AM, Christer Holmberg wrote:
I don=C2=B9t think that (2) is enough. In the deployment case that tri= ggered
the problem, there would never be a chance to send the clarification
UDPATE, because the INVITE is rejected.

OK, that is an issue.

I am not sure we can = put a rule in the specification that prevents refusing INVITE requests rand= omly. It is not against any specification, just not extremely useful.
=

Proposing that UA should not refuse INVITE transactions= due to S-E settings mismatch and use an UPDATE transaction to clear S-E st= atus (2) should be sufficient to address the original issue.

=
So, I still think we = shall clarify the procedures, and restrict what can
be done in UPDATEs sent within INVITEs. For example, one must not change the refresher etc., and whatever comes in the 2xx/INVITE matters. Again, in the deployment case, that should be rather easy to fix, because the
impact will be on an limited number of application servers - not on
thousands of UAs.

Regarding Roland=C2=B9s proxy case, we can clarify that a proxy must not ch= ange
the timer value in a response.

 More than that: If a proxy is going to insert or revise s-e or min-s-e in a= n UPDATE within an INVITE then it must do so consistently in the enclosing = INVITE.

I think proxy should be consist= ent about how it is inserting or updating s-e or min-s-e in general. There = is little or no reason why what proxy does should change from transaction-t= o-transaction.

There is one case here which is tri= cky:

1. UAC sends an INVITE without S-E
= 2. Proxy inserts S-E set to 3600 since it expects dialogs to expire after a= n hour
3. Within INVITE transaction UAC sends an UPDATE with S-E = set to 1800=C2=A0
4. Proxy does not update S-E in UPDATE since=C2= =A0 dialog will be refreshed before it is expired by proxy

UAS is confused since it got two messages, one with S-E 3600 and a= nother with S-E 1800.

It would be hard for the pro= xy to track what S-E value was used in the INVITE, since proxies are genera= lly not dialog statefull. Even if proxy did track that value, it cannot sim= ply increase the S-E in client UPDATE.

Proposed so= lution -- UAS should pick the smallest S-E value and use that.
Regards,
____________= _
Roman Shpount
=C2=A0
--089e082d74589269f2055f387815-- From nobody Thu Nov 30 12:44: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 7FA80126C22 for ; Thu, 30 Nov 2017 12:43:59 -0800 (PST) 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 Wy23S7ePiyNW for ; Thu, 30 Nov 2017 12:43:57 -0800 (PST) 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 8E2181241F3 for ; Thu, 30 Nov 2017 12:43:56 -0800 (PST) X-AuditID: 12074411-f7dff70000007f0a-cd-5a206d8b41af 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 AF.A0.32522.B8D602A5; Thu, 30 Nov 2017 15:43:55 -0500 (EST) 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 vAUKhsS1025383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Nov 2017 15:43:55 -0500 To: Roman Shpount Cc: "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> From: Paul Kyzivat Message-ID: <3b63d558-f3e1-3c5e-b46e-719f4fb49c9f@alum.mit.edu> Date: Thu, 30 Nov 2017 15:43:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.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+NgFupileLIzCtJLcpLzFFi42IRYndR1O3OVYgyOPlQxWLGhanMFl9/bGJz YPJYsuQnk8etKQUBTFFcNimpOZllqUX6dglcGRuWHmMvmC9Tcat5BXsDY6NoFyMHh4SAicT0 DYZdjFwcQgI7mCS+zL7BCuE8ZJL43vWWuYuRk0NYQEPi0J7fLCC2iICqxN/vk5lAbGYBTYnN 6y6wQzTcZ5dY/bqdDSTBJqAlMefQf7AGXgF7iY1LLoDZLEDNDXOXgNWICqRJ7LnQAVUjKHFy 5hMwm1MgUOLjptNsEAvMJOZtfsgMYYtL3HoyH2qxvETz1tnMExgFZiFpn4WkZRaSlllIWhYw sqxilEvMKc3VzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3ECAlgwR2MM07KHWIU4GBU4uGd IKwQJcSaWFZcmXuIUZKDSUmU91IYUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr3EoUI43JbGy KrUoHyYlzcGiJM7Lt0TdT0ggPbEkNTs1tSC1CCYrw8GhJMHblwPUKFiUmp5akZaZU4KQZuLg BBnOAzQ8Kx1keHFBYm5xZjpE/hSjMUdPz40/TBzPZr5uYBZiycvPS5US5w0FGScAUppRmgc3 DZaEXjGKAz0nzLsNpIoHmMDg5r0CWsUEtCpzuTzIqpJEhJRUA6OJo03/ifnfOdUPTTK1zza0 P3Ly49GjiZ4GLemaoo3bFD7+5dnurByy/MQdnqN2G5581H6wWX9pztfgd5v/hZ/e0MSiwuqn uacqO3B6u9nrtlPL9j/+KnYmq62x9DfjjuN7NhzK2ftF4f2XfT80dIM+dkeZzT+brhLMavD5 t2XBgefTzjAKWVxUYinOSDTUYi4qTgQAOE8MVx0DAAA= 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, 30 Nov 2017 20:43:59 -0000 On 11/30/17 2:43 PM, Roman Shpount wrote: > > On Thu, Nov 30, 2017 at 11:38 AM, Paul Kyzivat > wrote: > > On 11/30/17 3:39 AM, Christer Holmberg wrote: > > I don¹t think that (2) is enough. In the deployment case that > triggered > the problem, there would never be a chance to send the clarification > UDPATE, because the INVITE is rejected. > > > OK, that is an issue. > > > I am not sure we can put a rule in the specification that prevents > refusing INVITE requests randomly. It is not against any specification, > just not extremely useful. IIUC, Christer is saying that an existing implementation is failing the INVITE after getting conflicting values in the UPDATE. And so he is proposing that we revise things so that if at least one side supports the revision that won't happen. > Proposing that UA should not refuse INVITE transactions due to S-E > settings mismatch and use an UPDATE transaction to clear S-E status (2) > should be sufficient to address the original issue. > > So, I still think we shall clarify the procedures, and restrict > what can > be done in UPDATEs sent within INVITEs. For example, one must > not change > the refresher etc., and whatever comes in the 2xx/INVITE > matters. Again, > in the deployment case, that should be rather easy to fix, > because the > impact will be on an limited number of application servers - not on > thousands of UAs. > > Regarding Roland¹s proxy case, we can clarify that a proxy must > not change > the timer value in a response. > > > More than that: If a proxy is going to insert or revise s-e or > min-s-e in an UPDATE within an INVITE then it must do so > consistently in the enclosing INVITE. > > > I think proxy should be consistent about how it is inserting or updating > s-e or min-s-e in general. There is little or no reason why what proxy > does should change from transaction-to-transaction. > > There is one case here which is tricky: > > 1. UAC sends an INVITE without S-E > 2. Proxy inserts S-E set to 3600 since it expects dialogs to expire > after an hour > 3. Within INVITE transaction UAC sends an UPDATE with S-E set to 1800 > 4. Proxy does not update S-E in UPDATE since  dialog will be refreshed > before it is expired by proxy > > UAS is confused since it got two messages, one with S-E 3600 and another > with S-E 1800. > > It would be hard for the proxy to track what S-E value was used in the > INVITE, since proxies are generally not dialog statefull. Even if proxy > did track that value, it cannot simply increase the S-E in client UPDATE. A proxy that isn't dialog stateful should not be messing with s-t, nor should it need to. > Proposed solution -- UAS should pick the smallest S-E value and use that. This of course won't work if the UAS doesn't support the update. There is nothing that the UAC or the Proxy could do to salvage this case. I think it should be our goal to make things work with the minimum number of the participants supporting the revision, but clearly this is a case where the UAS must support the revision. OTOH, if the UAS had happened to simply accept *either* the 3600 or 1800 value, then the UAC would be able to fix it with a followon UPDATE. So I think it will be important to state what this revision can and cannot do. Thanks, Paul