From nobody Fri Dec 1 00:00: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 1E0E4120721 for ; Fri, 1 Dec 2017 00:00:09 -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 mX3Z7wNLzQaq for ; Fri, 1 Dec 2017 00:00:06 -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 46F95126CD6 for ; Fri, 1 Dec 2017 00:00:05 -0800 (PST) X-AuditID: c1b4fb3a-3edff70000003538-88-5a210c023d93 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 27.1D.13624.20C012A5; Fri, 1 Dec 2017 09:00:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Fri, 1 Dec 2017 09:00:02 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgIAA0dwAgADK3wCAAKRtAIAAEWVg///6T4CAACJbgIAACTGAgAAb1oCAAA5lAIAAhseAgABz6ACAATFKAIAAYfuAgAEldAA= Date: Fri, 1 Dec 2017 08:00:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> 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.147] Content-Type: text/plain; charset="windows-1254" Content-ID: <0D08CCBFF4B4A74A9466356B1C2A120F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7ri4zj2KUwf0zPBYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxqusNU8HR5IrfB3tYGhjP+HQxcnJICJhI zDu5irmLkYtDSOAwo8Sd080sIAkhgcWMEqdOqnUxcnCwCVhIdP/TBgmLCARKXF0ygRnEFhbQ kDi05zcLRFxT4uKpZUwgc0QE3jFKTFk0B6yIRUBFovHaMbAiXgFrif5j+xgh5k/kkLi/1g7E 5hRwkFh9so0dxGYUEJP4fmoNE4jNLCAucevJfCaIQwUkluw5zwxhi0q8fPyPFcQWFdCT2HDi NjvInRICShLTtqZBtBpIHDl3kxXCtpY40bsVytaWWLbwNTPEOYISJ2c+YZnAKDYLybZZSNpn IWmfhaR9FpL2BYysqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECo+rglt9WOxgPPnc8xCjA wajEwxv9TiFKiDWxrLgy9xCjBAezkghv3QKgEG9KYmVValF+fFFpTmrxIUZpDhYlcd6TnrxR QgLpiSWp2ampBalFMFkmDk6pBkZ2Fg9dS8cNdcKPLoScnH6nzmN3wQwmtWb7VS4bO1cb2z0O 2Vi4Mq3L5UDp2tq1UiImCZHX+14pnuIobmiesu5GnK27zQtty8aD8tuM+JRlDM/f6Hvtsm36 /7hTS3LFLyVE9c59l5dUNd127r4ZWSm3leybfdVUOEzP/X9pwnpr28FPnofueyqxFGckGmox FxUnAgAwJpHqpgIAAA== 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, 01 Dec 2017 08:00:09 -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. > >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. >>=20 >> Regarding Roland=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 >enclosing INVITE. Correct. Regards, Christer >>On 29/11/17 18:35, "Paul Kyzivat" wrote: >>=20 >>> 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=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 > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Dec 1 00:12: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 C155E126CD6 for ; Fri, 1 Dec 2017 00:12:23 -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 cNDs1-aAXUAa for ; Fri, 1 Dec 2017 00:12:22 -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 3EA271200F1 for ; Fri, 1 Dec 2017 00:12:22 -0800 (PST) X-AuditID: c1b4fb2d-d57ff700000036aa-be-5a210ee41068 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.B8.13994.4EE012A5; Fri, 1 Dec 2017 09:12:20 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Fri, 1 Dec 2017 09:12:19 +0100 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgIAA0dwAgADK3wCAAKRtAIAAEWVg///6T4CAACJbgIAACTGAgAAb1oCAAA5lAIAAhseAgABz6ACAATFKAIAAYfuAgAAzyoCAAPUZgA== Date: Fri, 1 Dec 2017 08:12:18 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7ge4TPsUog479ohYrNhxgtZhxYSqz xdcfm9gcmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyftz+xFSwSKni29zwBsYN il2MnBwSAiYSN3e8Zeli5OIQEjjMKPF36Q5GCGcxo8TnJ79Zuxg5ONgELCS6/2mDNIgIeEv0 9XWwg9jMApoSj3buZQKxhQU0JA7t+c0CUaMpcfHUMiaQOSIC3xgl9n+YD9bAIqAicXplKzvI TF4Ba4lt91wgdt3gkHjQfogRpIZTIFDi46bTbCA2o4CYxPdTa5gglolL3HoynwniagGJJXvO M0PYohIvH/9jBbFFBfQkNpy4DTZfQkBRYnm/HESrlsSXH/vYIGxriU03jzND2IoSU7ofgp3G KyAocXLmE5YJjOKzkGybhaR9FpL2WUjaZyFpX8DIuopRtDi1uDg33chYL7UoM7m4OD9PLy+1 ZBMjMP4Obvmtu4Nx9WvHQ4wCHIxKPLwC7xSihFgTy4orcw8xSnAwK4nw1i0ACvGmJFZWpRbl xxeV5qQWH2KU5mBREuc96ckbJSSQnliSmp2aWpBaBJNl4uCUamBkdT26WWftKX5ZtQk7778J 11xRcCzVI3lhKAPfrMfqXk4354iwBZqnbSqpKtx1YlcwK9vdmfxFAf2TpW3/5btyltpx6J1g 6otctuna02mb/6tY53sv14q8HbXLfal5gsjrk7fv3W580Bjyi1v1c7/aNVmJoh6Z37ndoUfa HULeWf85fNZtDacSS3FGoqEWc1FxIgALfxfwuwIAAA== 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, 01 Dec 2017 08:12:24 -0000 SGksDQoNCj4+PiBJIGRvbqn2dCB0aGluayB0aGF0ICgyKSBpcyBlbm91Z2guIEluIHRoZSBkZXBs b3ltZW50IGNhc2UgdGhhdCB0cmlnZ2VyZWQNCj4+PiB0aGUgcHJvYmxlbSwgdGhlcmUgd291bGQg bmV2ZXIgYmUgYSBjaGFuY2UgdG8gc2VuZCB0aGUgY2xhcmlmaWNhdGlvbg0KPj4+IFVEUEFURSwg YmVjYXVzZSB0aGUgSU5WSVRFIGlzIHJlamVjdGVkLg0KPj4+DQo+PiBPSywgdGhhdCBpcyBhbiBp c3N1ZS4NCj4NCj4gSSBhbSBub3Qgc3VyZSB3ZSBjYW4gcHV0IGEgcnVsZSBpbiB0aGUgc3BlY2lm aWNhdGlvbiB0aGF0IHByZXZlbnRzDQo+cmVmdXNpbmcgSU5WSVRFIHJlcXVlc3RzIHJhbmRvbWx5 LiBJdCBpcyBub3QgYWdhaW5zdCBhbnkgc3BlY2lmaWNhdGlvbiwNCj5qdXN0IG5vdCBleHRyZW1l bHkgdXNlZnVsLg0KPg0KPiBQcm9wb3NpbmcgdGhhdCBVQSBzaG91bGQgbm90IHJlZnVzZSBJTlZJ VEUgdHJhbnNhY3Rpb25zIGR1ZSB0byBTLUUNCj5zZXR0aW5ncyBtaXNtYXRjaCBhbmQgdXNlIGFu IFVQREFURSB0cmFuc2FjdGlvbiB0byBjbGVhciBTLUUgc3RhdHVzICgyKQ0KPnNob3VsZCBiZSBz dWZmaWNpZW50IHRvIGFkZHJlc3MgdGhlIG9yaWdpbmFsIGlzc3VlLg0KDQpJIGFtIG5vdCBzdWdn ZXN0aW5nIHRoZSB3ZSBwcmV2ZW50IGEgVUFTIGZyb20gcmVqZWN0aW5nIGFuIElOVklURSByZXF1 ZXN0DQotIGEgVUFTIGNhbiByZWplY3QgYW4gSU5WSVRFIHdoZW5ldmVyIGl0IHdhbnRzLCBmb3Ig d2hhdGV2ZXIgcmVhc29ucy4NCg0KTXkgcG9pbnQgd2FzIHRoYXQgb25seSBkb2luZyAoMikgd291 bGQgbm90IGZpeCB0aGUgZGVwbG95bWVudCBwcm9ibGVtLCBhcw0KdGhlIElOVklURSBpcyByZWpl Y3RlZCBiZWZvcmUgdGhlcmUgaXMgYSBjaGFuY2UgdG8gc2VuZCBhIGNsYXJpZmljYXRpb24NClVQ REFURS4NCg0KDQo+Pj4gU28sIEkgc3RpbGwgdGhpbmsgd2Ugc2hhbGwgY2xhcmlmeSB0aGUgcHJv Y2VkdXJlcywgYW5kIHJlc3RyaWN0IHdoYXQNCj4+PmNhbg0KPj4+IGJlIGRvbmUgaW4gVVBEQVRF cyBzZW50IHdpdGhpbiBJTlZJVEVzLiBGb3IgZXhhbXBsZSwgb25lIG11c3Qgbm90DQo+Pj5jaGFu Z2UNCj4+PiB0aGUgcmVmcmVzaGVyIGV0Yy4sIGFuZCB3aGF0ZXZlciBjb21lcyBpbiB0aGUgMnh4 L0lOVklURSBtYXR0ZXJzLg0KPj4+QWdhaW4sDQo+Pj4gaW4gdGhlIGRlcGxveW1lbnQgY2FzZSwg dGhhdCBzaG91bGQgYmUgcmF0aGVyIGVhc3kgdG8gZml4LCBiZWNhdXNlIHRoZQ0KPj4+IGltcGFj dCB3aWxsIGJlIG9uIGFuIGxpbWl0ZWQgbnVtYmVyIG9mIGFwcGxpY2F0aW9uIHNlcnZlcnMgLSBu b3Qgb24NCj4+PiB0aG91c2FuZHMgb2YgVUFzLg0KPj4+DQo+Pj4gUmVnYXJkaW5nIFJvbGFuZKn2 cyBwcm94eSBjYXNlLCB3ZSBjYW4gY2xhcmlmeSB0aGF0IGEgcHJveHkgbXVzdCBub3QNCj4+PmNo YW5nZQ0KPj4+IHRoZSB0aW1lciB2YWx1ZSBpbiBhIHJlc3BvbnNlLg0KPj4NCj4+IE1vcmUgdGhh biB0aGF0OiBJZiBhIHByb3h5IGlzIGdvaW5nIHRvIGluc2VydCBvciByZXZpc2Ugcy1lIG9yIG1p bi1zLWUNCj4+aW4gYW4gVVBEQVRFIHdpdGhpbiBhbiBJTlZJVEUgdGhlbiBpdCBtdXN0IGRvIHNv IGNvbnNpc3RlbnRseSBpbiB0aGUNCj4+ZW5jbG9zaW5nIElOVklURS4NCj4NCj4gSSB0aGluayBw cm94eSBzaG91bGQgYmUgY29uc2lzdGVudCBhYm91dCBob3cgaXQgaXMgaW5zZXJ0aW5nIG9yIHVw ZGF0aW5nDQo+cy1lIG9yIG1pbi1zLWUgaW4gZ2VuZXJhbC4gVGhlcmUgaXMgbGl0dGxlIG9yIG5v IHJlYXNvbiB3aHkgd2hhdCBwcm94eQ0KPmRvZXMgc2hvdWxkIGNoYW5nZSBmcm9tIHRyYW5zYWN0 aW9uLXRvLXRyYW5zYWN0aW9uLg0KPg0KPiBUaGVyZSBpcyBvbmUgY2FzZSBoZXJlIHdoaWNoIGlz IHRyaWNreToNCj4NCj4gMS4gVUFDIHNlbmRzIGFuIElOVklURSB3aXRob3V0IFMtRQ0KPiAyLiBQ cm94eSBpbnNlcnRzIFMtRSBzZXQgdG8gMzYwMCBzaW5jZSBpdCBleHBlY3RzIGRpYWxvZ3MgdG8g ZXhwaXJlDQo+YWZ0ZXIgYW4gaG91cg0KPiAzLiBXaXRoaW4gSU5WSVRFIHRyYW5zYWN0aW9uIFVB QyBzZW5kcyBhbiBVUERBVEUgd2l0aCBTLUUgc2V0IHRvIDE4MDANCj4gNC4gUHJveHkgZG9lcyBu b3QgdXBkYXRlIFMtRSBpbiBVUERBVEUgc2luY2UgIGRpYWxvZyB3aWxsIGJlIHJlZnJlc2hlZA0K PmJlZm9yZSBpdCBpcyBleHBpcmVkIGJ5IHByb3h5DQo+DQo+IFVBUyBpcyBjb25mdXNlZCBzaW5j ZSBpdCBnb3QgdHdvIG1lc3NhZ2VzLCBvbmUgd2l0aCBTLUUgMzYwMCBhbmQgYW5vdGhlcg0KPndp dGggUy1FIDE4MDAuDQoNCjMpIHdvdWxkIG5vdCBiZSBhbGxvd2VkLiBUaGUgVURQQVRFIG11c3Qg bWlycm9yIHRoZSBJTlZJVEUuDQoNCkFuZCwgZXZlbiBpZiAzKSBoYXBwZW5zLCB0aGUgVUFTIHdv dWxkIGRpc2NhcmQgdGhlIFMtRSAxODAwLg0KDQoNCj4gSXQgd291bGQgYmUgaGFyZCBmb3IgdGhl IHByb3h5IHRvIHRyYWNrIHdoYXQgUy1FIHZhbHVlIHdhcyB1c2VkIGluIHRoZQ0KPklOVklURSwg c2luY2UgcHJveGllcyBhcmUgZ2VuZXJhbGx5IG5vdCBkaWFsb2cgc3RhdGVmdWxsLiBFdmVuIGlm IHByb3h5DQo+ZGlkIHRyYWNrIHRoYXQgdmFsdWUsIGl0IGNhbm5vdCBzaW1wbHkgaW5jcmVhc2Ug dGhlIFMtRSBpbiBjbGllbnQgVVBEQVRFLg0KPg0KPiBQcm9wb3NlZCBzb2x1dGlvbiAtLSBVQVMg c2hvdWxkIHBpY2sgdGhlIHNtYWxsZXN0IFMtRSB2YWx1ZSBhbmQgdXNlIHRoYXQuDQoNCkkgZG91 YnQgQU5ZIFVBIGRvZXMgdGhhdCB0b2RheSwgd2hpY2ggbWVhbnMgdGhhdCBFVkVSWSBkZXBsb3ll ZCBVQSB3b3VsZA0KaGF2ZSB0byBiZSB1cGRhdGVkIGluIG9yZGVyIGZvciB0aGF0IHRvIHdvcmsu DQoNCkluIGFkZGl0aW9uLCBpdKGvcyBub3Qgb25seSBhYm91dCB0aGUgdGltZXIgdmFsdWUuIFdo YXQgaWYgdGhlIFVBQyBjaGFuZ2VzDQp0aGUgcmVmcmVzaGVyIHZhbHVlIGluIHRoZSBVUERBVEU/ IFRoZSBVQVMgd2lsbCByZWNlaXZlIKGwdWFjobEgaW4gdGhlDQpJTlZJVEUsIGFuZCChsHVhc6Gx IGluIHRoZSBVUERBVEU/IFdoYXQgZG9lcyBpdCBkbz8NCg0KU28sIEkgc3RpbGwgdGhpbmsgdGhl IGVhc2llc3Qgc29sdXRpb24gaXMgdG8gc2ltcGx5IHNheSB0aGF0IHRoZQ0KVVBEQVRFLWluc2lk ZS1JTlZJVEUgbXVzdCBtaXJyb3IgdGhlIElOVklURS4NCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCiANCg0K From nobody Fri Dec 1 10:10: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 375A312762F for ; Fri, 1 Dec 2017 10:10:07 -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 XRLRxaEuUyHz for ; Fri, 1 Dec 2017 10:10:05 -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 7E0C21275C5 for ; Fri, 1 Dec 2017 10:10:05 -0800 (PST) X-AuditID: 12074413-38bff70000007929-19-5a219afb6008 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 CC.65.31017.BFA912A5; Fri, 1 Dec 2017 13:10:03 -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 vB1IA2sK023800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Dec 2017 13:10:03 -0500 To: Christer Holmberg , Roman Shpount Cc: "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 1 Dec 2017 13:10:02 -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=euc-kr; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixO6iqPt7lmKUwb/FVhYXZh5mtJhxYSqz xdcfm9gcmD1+fb3K5rFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyLt/wKuiWqTi7OaWBsU2s i5GTQ0LARGLH9o2MXYxcHEICO5gkdnS1skA4D5gkpv+ayApSJSygIXFoz2+gBAeHiECSxLHu EpAws4CmxOZ1F9gh6u+zS2w+0s4OkmAT0JKYc+g/C4jNK2AvseLRPjYQm0VAReLS1HtgNaIC aRJ7LnRA1QhKnJz5BMzmFLCR6P07nRVigbnEpQ0f2CFscYlbT+YzQdjyEs1bZzNPYBSYhaR9 FpKWWUhaZiFpWcDIsopRLjGnNFc3NzEzpzg1Wbc4OTEvL7VI11wvN7NELzWldBMjJKCFdzDu Oil3iFGAg1GJhzcgSDFKiDWxrLgy9xCjJAeTkigvXydQiC8pP6UyI7E4I76oNCe1+BCjBAez kghv/lSgHG9KYmVValE+TEqag0VJnFdtibqfkEB6YklqdmpqQWoRTFaGg0NJgpcVGLlCgkWp 6akVaZk5JQhpJg5OkOE8QMNfzwQZXlyQmFucmQ6RP8VozNHTc+MPE8ezma8bmIVY8vLzUqXE eQtBSgVASjNK8+CmwZLSK0ZxoOeEedlBlvIAExrcvFdAq5iAVmUulwdZVZKIkJJqYAxxEkj+ 4ST5eXPgnv5ZfUsbbKTPrdw6TWID7zqWVna9f52SfzRXrrc4yvVAdJ53yYVj4kmLFO9eO3sx Q/rl0tR8a5Xtq1Y5JbJPTn/CI3T4Q9yPjz7h+Z++l32p6fw5e/MWKSfjT4/Zt7+OYeiR6va4 0S+4x9JeOHnWqzZG9dmLwzhKTon79CuxFGckGmoxFxUnAgDBc6P9JQMAAA== 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, 01 Dec 2017 18:10:07 -0000 On 12/1/17 3:12 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. >> >> 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. > > I am not suggesting the we prevent a UAS from rejecting an INVITE request > - a UAS can reject an INVITE whenever it wants, for whatever reasons. > > My point was that only doing (2) would not fix the deployment problem, as > the INVITE is rejected before there is a chance to send a clarification > UPDATE. > > >>>> 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. > > 3) would not be allowed. The UDPATE must mirror the INVITE. > > And, even if 3) happens, the UAS would discard the 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. > > I doubt ANY UA does that today, which means that EVERY deployed UA would > have to be updated in order for that to work. > > In addition, itˇŻs not only about the timer value. What if the UAC changes > the refresher value in the UPDATE? The UAS will receive ˇ°uacˇ± in the > INVITE, and ˇ°uasˇ± in the UPDATE? What does it do? > > So, I still think the easiest solution is to simply say that the > UPDATE-inside-INVITE must mirror the INVITE. But the MUST will only apply to UAs that implement this revision. For maximum effect I think we need to specify how to patch things up when only one end supports it and the other end (or a proxy) is behaving in a problematic way. Thanks, Paul From nobody Fri Dec 1 11:14:22 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3FD126CB6 for ; Fri, 1 Dec 2017 11:14:20 -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 kL9piGJag8TR for ; Fri, 1 Dec 2017 11:14:19 -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 2DDB9126BF3 for ; Fri, 1 Dec 2017 11:14:19 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id u19so5041601pfa.12 for ; Fri, 01 Dec 2017 11:14:19 -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=FzRGpgi+zfT3qJDgo/kKIetfg19WNyF0e2vRfdPGOV8=; b=0pJ8L+Cwjw0dHTzrDVoenQVOjtDEzDqT5Dpk3tWvzCRAGyxvb0BY7VNf/ovxejMykv esVCJfDE3kvAv/PKjob400TIwJ3ZpeBJtMDjxpeCup72JleQ1doLx46dIIJ+N8lW4WE9 I1rdiTpbYM/9GtOMELAhkv09rARjjnVACPRKfGfPBrdlc7zB0yGbj+vmDlA7hGfJ319v szRlAfPslSF/mgYQUIfXN9yieKJavbHBzWr6El9tjjYtBclX5xoOkj1BijiVuG+zwOxE pe+GGNy6DsnQUKyKY+S6/aJd8YGhDvkPzOIk0/Ci7bEOgG7CWFIqVgB7vsrQjE9FmDAA Nhzw== 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=FzRGpgi+zfT3qJDgo/kKIetfg19WNyF0e2vRfdPGOV8=; b=XFxl0HdkJYuHHpiu6Smx04y0/bRMv4BMdLes7hOxYVBsFm12M8ESE/TG4ax4yypMnx yyDAgLPGxH3Se1PNjGaqNkXlcaJgUqmCObjbcgiSVlAs5FnpDWQCIgDSs8miE6lem+ax PRgtsRh/usylX+rIeoQFup8WnBNPW/OlEUmOfMWr6q8WjkkjWOGujhS+kpA/3d1H3Gxw 8K+8t5koMrC54YPdjjrYcxPLh1FTOcdOiM+jlKPAj68IXjgb18dXAQ0AoaOoiQhz/60g gQPvwTaGd70tBBUPs27wqTEV6JyKzFmkix2n4aDfao6O/aLOAdHx6pVpaNhN06mNj/+G DkGQ== X-Gm-Message-State: AJaThX7/9kxPD+VQbK1YR94BNJAvS503+3VR6Vj1GzRHv6/9wxjz7e6A f358RgOAfTfOZT5QTNxs56JMaBM4 X-Google-Smtp-Source: AGs4zMbcoOU0YFfPHV6y0XkWXdp3Mu7c7cCU/SVQpJkd9cxplK3iRKJBZ388ketdN/qARDQrBSz1kg== X-Received: by 10.99.147.3 with SMTP id b3mr6981535pge.114.1512155658487; Fri, 01 Dec 2017 11:14:18 -0800 (PST) Received: from mail-pl0-f50.google.com (mail-pl0-f50.google.com. [209.85.160.50]) by smtp.gmail.com with ESMTPSA id f7sm13090040pfa.133.2017.12.01.11.14.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 11:14:16 -0800 (PST) Received: by mail-pl0-f50.google.com with SMTP id q7so6820109plk.0 for ; Fri, 01 Dec 2017 11:14:16 -0800 (PST) X-Received: by 10.84.235.10 with SMTP id o10mr7109702plk.155.1512155656382; Fri, 01 Dec 2017 11:14:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Fri, 1 Dec 2017 11:14:15 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> From: Roman Shpount Date: Fri, 1 Dec 2017 14:14:15 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="089e0820e0d8be6f3e055f4c2c73" 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, 01 Dec 2017 19:14:21 -0000 --089e0820e0d8be6f3e055f4c2c73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 1, 2017 at 1:10 PM, Paul Kyzivat wrote: > I doubt ANY UA does that today, which means that EVERY deployed UA would >> have to be updated in order for that to work. >> >> In addition, it=E2=80=99s not only about the timer value. What if the UA= C changes >> the refresher value in the UPDATE? The UAS will receive =E2=80=9Cuac=E2= =80=9D in the >> INVITE, and =E2=80=9Cuas=E2=80=9D in the UPDATE? What does it do? >> >> So, I still think the easiest solution is to simply say that the >> UPDATE-inside-INVITE must mirror the INVITE. >> > > But the MUST will only apply to UAs that implement this revision. For > maximum effect I think we need to specify how to patch things up when onl= y > one end supports it and the other end (or a proxy) is behaving in a > problematic way. > This was my point exactly. We should suggest the behavior which will result in highest chance of success if only one of the UA implements it. I think there are still scenarios which will break, like UA which simply refuse the INVITE transaction with S-E if they got an UPDATE with S-E during this transaction (even if S-E values matched). If only one UA implements the update, all we hope for is to minimize the number of failures. From this point of view, I am not sure, what would be better: a. Refusing UPDATE with mismatching S-E during INVITE transaction b. Accepting UPDATE and have some sort of logic which makes the safest possible choice between the messages (pick smallest S-E, pick largest Min-S-E, pick refresher option where current UA is doing the refreshing) Regards, _____________ Roman Shpount --089e0820e0d8be6f3e055f4c2c73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 1, 2017 at 1:10 PM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:
I doub= t ANY UA does that today, which means that EVERY deployed UA would
have to be updated in order for that to work.

In addition, it=E2=80=99s not only about the timer value. What if the UAC c= hanges
the refresher value in the UPDATE? The UAS will receive =E2=80=9Cuac=E2=80= =9D in the
INVITE, and =E2=80=9Cuas=E2=80=9D in the UPDATE? What does it do?

So, I still think the easiest solution is to simply say that the
UPDATE-inside-INVITE must mirror the INVITE.

But the MUST will only apply to UAs that implement this revision. For maxim= um effect I think we need to specify how to patch things up when only one e= nd supports it and the other end (or a proxy) is behaving in a problematic = way.

This was my point exactly. We shou= ld suggest the behavior which will result in highest chance of success if o= nly one of the UA implements it. I think there are still scenarios which wi= ll break, like UA which simply refuse the INVITE transaction with S-E if th= ey got an UPDATE with S-E during this transaction (even if S-E values match= ed). If only one UA implements the update, all we hope for is to minimize t= he number of failures. From this point of view, I am not sure, what would b= e better:

a. Refusing UPDATE with mismatching S-E = during INVITE transaction
b. Accepting UPDATE and have some sort = of logic which makes the safest possible choice between the messages=C2=A0 = (pick smallest S-E, pick largest Min-S-E, pick refresher option where curre= nt UA is doing the refreshing)

Regards,
=
_____________
Roman Shpount
=C2=A0
--089e0820e0d8be6f3e055f4c2c73-- From nobody Fri Dec 1 13:06:11 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AE6126C3D for ; Fri, 1 Dec 2017 13:06:09 -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 7dCYFSJv-Q1q for ; Fri, 1 Dec 2017 13:06:08 -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 BAB661242EA for ; Fri, 1 Dec 2017 13:06:06 -0800 (PST) X-AuditID: 1207440d-853ff70000000f42-b9-5a21c43abbab 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 0F.58.03906.B34C12A5; Fri, 1 Dec 2017 16:06:03 -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 vB1L60En000599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Dec 2017 16:06:01 -0500 To: Roman Shpount Cc: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 1 Dec 2017 16:06:00 -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+NgFprNKsWRmVeSWpSXmKPExsUixO6iqGt9RDHKYN5LPYsLMw8zWsy4MJXZ 4uuPTWwOzB6/vl5l81iy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZ/4/fYy84JFxx5X4PewPj U74uRk4OCQETiS2nV7J0MXJxCAnsYJJ41HqIEcJ5wCSx4Mw1RpAqYQENiUN7frOA2CICqhJ/ v09mArGZBdIkNja/gWp4zC5xt3keM0iCTUBLYs6h/2ANvAL2EndXXQaLswioSLy9e5MVxBYF at5zoQOqRlDi5MwnYDanQKDE9u657BALzCTmbX7IDGGLS9x6Mh9qsbxE89bZzBMYBWYhaZ+F pGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAgJa94djP/X yRxiFOBgVOLhXRGiGCXEmlhWXJl7iFGSg0lJlHfdOqAQX1J+SmVGYnFGfFFpTmrxIUYJDmYl EV7W3UA53pTEyqrUonyYlDQHi5I4r9oSdT8hgfTEktTs1NSC1CKYrAwHh5IE759DQI2CRanp qRVpmTklCGkmDk6Q4TxAwzMOggwvLkjMLc5Mh8ifYrTk6Om58YeJ49GNu0Dy2czXDcxCLHn5 ealS4rxeh4EaBEAaMkrz4GbC0tQrRnGgF4V5A0GqeIApDm7qK6CFTEALM5fLgywsSURISTUw Zv1k96zpO7RRLvx5Tg6/xsVPDTMuVPNWFMU3JWxP8Pp/ItxNOtfvapvMzaxZOwNVan/rtbaJ 62U8y7CsNtn+aH5ywzKmMwfP5gVL1kuteGcxVyLOsknWIzRTZHFBOEOV1MfHO9/3ONmrmJop 28dOfOAbtj6jN8/++JmLeVxz39cyMP/wTFJiKc5INNRiLipOBADsi/IJLgMAAA== 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, 01 Dec 2017 21:06:10 -0000 On 12/1/17 2:14 PM, Roman Shpount wrote: > On Fri, Dec 1, 2017 at 1:10 PM, Paul Kyzivat > wrote: > > I doubt ANY UA does that today, which means that EVERY deployed > UA would > have to be updated in order for that to work. > > In addition, it’s not only about the timer value. What if the > UAC changes > the refresher value in the UPDATE? The UAS will receive “uac” in the > INVITE, and “uas” in the UPDATE? What does it do? > > So, I still think the easiest solution is to simply say that the > UPDATE-inside-INVITE must mirror the INVITE. > > > But the MUST will only apply to UAs that implement this revision. > For maximum effect I think we need to specify how to patch things up > when only one end supports it and the other end (or a proxy) is > behaving in a problematic way. > > > This was my point exactly. We should suggest the behavior which will > result in highest chance of success if only one of the UA implements it. > I think there are still scenarios which will break, like UA which simply > refuse the INVITE transaction with S-E if they got an UPDATE with S-E > during this transaction (even if S-E values matched). If only one UA > implements the update, all we hope for is to minimize the number of > failures. From this point of view, I am not sure, what would be better: > > a. Refusing UPDATE with mismatching S-E during INVITE transaction > b. Accepting UPDATE and have some sort of logic which makes the safest > possible choice between the messages  (pick smallest S-E, pick largest > Min-S-E, pick refresher option where current UA is doing the refreshing) Refusing an UPDATE within an INVITE has all sorts of nasty implications. It may be doing more than just the s-t stuff. E.g. I might be doing preconditions. IMO this is a bad path to pursue. Aside from accepting the UPDATE I don't think it matters much what assumptions you make about how it impacts the s-t negotiations. Whatever you assume has a chance to be right or wrong. Better to simply do a s-t refresh immediately after the INVITE. Your guessing can then be limited to what values to use in that refresh. (Note that my use of "refresh" if the end doing this was not clearly chosen as the refresher. So maybe it would be better to call it something else.) Thanks, Paul From nobody Mon Dec 4 03:12: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 EB35212714F for ; Mon, 4 Dec 2017 03:11: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_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 dfLgJzj_-6YH for ; Mon, 4 Dec 2017 03:11:58 -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 D5C851201F2 for ; Mon, 4 Dec 2017 03:11:57 -0800 (PST) X-AuditID: c1b4fb3a-3edff70000003538-a5-5a252d7b2b26 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F2.B9.13624.B7D252A5; Mon, 4 Dec 2017 12:11:56 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Mon, 4 Dec 2017 12:11:55 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgIAA0dwAgADK3wCAAKRtAIAAEWVg///6T4CAACJbgIAACTGAgAAb1oCAAA5lAIAAhseAgABz6ACAATFKAIAAYfuAgAAzyoCAAPUZgIAAgwsAgARmLAA= Date: Mon, 4 Dec 2017 11:11:54 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> 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: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7pW6NrmqUwexoixUbDrBazLgwldni 649NbA7MHn/ff2DyWLLkJ5PHrSkFAcxRXDYpqTmZZalF+nYJXBlrL+5iLtimUbF//UbGBsYN 6l2MnBwSAiYSb2cvZ+9i5OIQEjjMKLFy1hEWCGcxo8SJb2dYuxg5ONgELCS6/2mDNIgIeEtM mL+aDcRmFtCUeLRzLxOILSygIXFoz28WiBpNiYunljGBzBERaGKSuP/yHjPIHBYBFYnZV3hA angFrCVuzt7LCrFrKofEwh0L2EESnAIOEu+/fwFbwCggJvH91BomiGXiEreezGeCuFpAYsme 88wQtqjEy8f/WEFsUQE9iQ0nbrNDxBUldp5tZ4bo1ZL48mMf1NHWEsv+PGSBsBUlpnQ/ZIc4 SFDi5MwnLBMYxWchWTcLSfssJO2zkLTPQtK+gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJ JkZgBB7c8ttqB+PB546HGAU4GJV4eA3lVaOEWBPLiitzDzFKcDArifA6MACFeFMSK6tSi/Lj i0pzUosPMUpzsCiJ85705I0SEkhPLEnNTk0tSC2CyTJxcEo1MIZ7eSsWrf69ePlChlTv7fkX zwemr+46q6VuJyowtd/EU+Qnk9OhfrXjVUejz7axN9gEdN5Kb/CUMXSxP3hxgd/z5bwPtj4K SustFW/8fGCdcrPSwgfzVm3o7KyYVvjX6/fGFaqcVmcZ3rU7PXj69lKKvtzS/grx4huFU4/I LxU59OyGddre1UosxRmJhlrMRcWJABS1eZK8AgAA 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, 04 Dec 2017 11:12:00 -0000 SGksDQoNCj4+Pj4+SSBkb26p9nQgdGhpbmsgdGhhdCAoMikgaXMgZW5vdWdoLiBJbiB0aGUgZGVw bG95bWVudCBjYXNlIHRoYXQNCj4+Pj4+dHJpZ2dlcmVkDQo+Pj4+PiB0aGUgcHJvYmxlbSwgdGhl cmUgd291bGQgbmV2ZXIgYmUgYSBjaGFuY2UgdG8gc2VuZCB0aGUgY2xhcmlmaWNhdGlvbg0KPj4+ Pj4gVURQQVRFLCBiZWNhdXNlIHRoZSBJTlZJVEUgaXMgcmVqZWN0ZWQuDQo+Pj4+Pg0KPj4+PiBP SywgdGhhdCBpcyBhbiBpc3N1ZS4NCj4+Pg0KPj4+IEkgYW0gbm90IHN1cmUgd2UgY2FuIHB1dCBh IHJ1bGUgaW4gdGhlIHNwZWNpZmljYXRpb24gdGhhdCBwcmV2ZW50cw0KPj4+IHJlZnVzaW5nIElO VklURSByZXF1ZXN0cyByYW5kb21seS4gSXQgaXMgbm90IGFnYWluc3QgYW55IHNwZWNpZmljYXRp b24sDQo+Pj4ganVzdCBub3QgZXh0cmVtZWx5IHVzZWZ1bC4NCj4+Pg0KPj4+IFByb3Bvc2luZyB0 aGF0IFVBIHNob3VsZCBub3QgcmVmdXNlIElOVklURSB0cmFuc2FjdGlvbnMgZHVlIHRvIFMtRQ0K Pj4+IHNldHRpbmdzIG1pc21hdGNoIGFuZCB1c2UgYW4gVVBEQVRFIHRyYW5zYWN0aW9uIHRvIGNs ZWFyIFMtRSBzdGF0dXMgKDIpDQo+Pj4gc2hvdWxkIGJlIHN1ZmZpY2llbnQgdG8gYWRkcmVzcyB0 aGUgb3JpZ2luYWwgaXNzdWUuDQo+PiANCj4+IEkgYW0gbm90IHN1Z2dlc3RpbmcgdGhlIHdlIHBy ZXZlbnQgYSBVQVMgZnJvbSByZWplY3RpbmcgYW4gSU5WSVRFDQo+PnJlcXVlc3QNCj4+IC0gYSBV QVMgY2FuIHJlamVjdCBhbiBJTlZJVEUgd2hlbmV2ZXIgaXQgd2FudHMsIGZvciB3aGF0ZXZlciBy ZWFzb25zLg0KPj4gDQo+PiBNeSBwb2ludCB3YXMgdGhhdCBvbmx5IGRvaW5nICgyKSB3b3VsZCBu b3QgZml4IHRoZSBkZXBsb3ltZW50IHByb2JsZW0sDQo+PmFzDQo+PiB0aGUgSU5WSVRFIGlzIHJl amVjdGVkIGJlZm9yZSB0aGVyZSBpcyBhIGNoYW5jZSB0byBzZW5kIGEgY2xhcmlmaWNhdGlvbg0K Pj4gVVBEQVRFLg0KPj4gDQo+PiANCj4+Pj4+IFNvLCBJIHN0aWxsIHRoaW5rIHdlIHNoYWxsIGNs YXJpZnkgdGhlIHByb2NlZHVyZXMsIGFuZCByZXN0cmljdCB3aGF0DQo+Pj4+PiBjYW4NCj4+Pj4+ IGJlIGRvbmUgaW4gVVBEQVRFcyBzZW50IHdpdGhpbiBJTlZJVEVzLiBGb3IgZXhhbXBsZSwgb25l IG11c3Qgbm90DQo+Pj4+PiBjaGFuZ2UNCj4+Pj4+IHRoZSByZWZyZXNoZXIgZXRjLiwgYW5kIHdo YXRldmVyIGNvbWVzIGluIHRoZSAyeHgvSU5WSVRFIG1hdHRlcnMuDQo+Pj4+PiBBZ2FpbiwNCj4+ Pj4+IGluIHRoZSBkZXBsb3ltZW50IGNhc2UsIHRoYXQgc2hvdWxkIGJlIHJhdGhlciBlYXN5IHRv IGZpeCwgYmVjYXVzZQ0KPj4+Pj50aGUNCj4+Pj4+IGltcGFjdCB3aWxsIGJlIG9uIGFuIGxpbWl0 ZWQgbnVtYmVyIG9mIGFwcGxpY2F0aW9uIHNlcnZlcnMgLSBub3Qgb24NCj4+Pj4+IHRob3VzYW5k cyBvZiBVQXMuDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkaW5nIFJvbGFuZKn2cyBwcm94eSBjYXNlLCB3 ZSBjYW4gY2xhcmlmeSB0aGF0IGEgcHJveHkgbXVzdCBub3QNCj4+Pj4+IGNoYW5nZQ0KPj4+Pj4g dGhlIHRpbWVyIHZhbHVlIGluIGEgcmVzcG9uc2UuDQo+Pj4+DQo+Pj4+IE1vcmUgdGhhbiB0aGF0 OiBJZiBhIHByb3h5IGlzIGdvaW5nIHRvIGluc2VydCBvciByZXZpc2Ugcy1lIG9yIG1pbi1zLWUN Cj4+Pj4gaW4gYW4gVVBEQVRFIHdpdGhpbiBhbiBJTlZJVEUgdGhlbiBpdCBtdXN0IGRvIHNvIGNv bnNpc3RlbnRseSBpbiB0aGUNCj4+Pj4gZW5jbG9zaW5nIElOVklURS4NCj4+Pg0KPj4+IEkgdGhp bmsgcHJveHkgc2hvdWxkIGJlIGNvbnNpc3RlbnQgYWJvdXQgaG93IGl0IGlzIGluc2VydGluZyBv cg0KPj4+dXBkYXRpbmcNCj4+PiBzLWUgb3IgbWluLXMtZSBpbiBnZW5lcmFsLiBUaGVyZSBpcyBs aXR0bGUgb3Igbm8gcmVhc29uIHdoeSB3aGF0IHByb3h5DQo+Pj4gZG9lcyBzaG91bGQgY2hhbmdl IGZyb20gdHJhbnNhY3Rpb24tdG8tdHJhbnNhY3Rpb24uDQo+Pj4NCj4+PiBUaGVyZSBpcyBvbmUg Y2FzZSBoZXJlIHdoaWNoIGlzIHRyaWNreToNCj4+Pg0KPj4+IDEuIFVBQyBzZW5kcyBhbiBJTlZJ VEUgd2l0aG91dCBTLUUNCj4+PiAyLiBQcm94eSBpbnNlcnRzIFMtRSBzZXQgdG8gMzYwMCBzaW5j ZSBpdCBleHBlY3RzIGRpYWxvZ3MgdG8gZXhwaXJlDQo+Pj4gYWZ0ZXIgYW4gaG91cg0KPj4+IDMu IFdpdGhpbiBJTlZJVEUgdHJhbnNhY3Rpb24gVUFDIHNlbmRzIGFuIFVQREFURSB3aXRoIFMtRSBz ZXQgdG8gMTgwMA0KPj4+IDQuIFByb3h5IGRvZXMgbm90IHVwZGF0ZSBTLUUgaW4gVVBEQVRFIHNp bmNlICBkaWFsb2cgd2lsbCBiZSByZWZyZXNoZWQNCj4+PiBiZWZvcmUgaXQgaXMgZXhwaXJlZCBi eSBwcm94eQ0KPj4+DQo+Pj4gVUFTIGlzIGNvbmZ1c2VkIHNpbmNlIGl0IGdvdCB0d28gbWVzc2Fn ZXMsIG9uZSB3aXRoIFMtRSAzNjAwIGFuZA0KPj4+YW5vdGhlcg0KPj4+IHdpdGggUy1FIDE4MDAu DQo+PiANCj4+IDMpIHdvdWxkIG5vdCBiZSBhbGxvd2VkLiBUaGUgVURQQVRFIG11c3QgbWlycm9y IHRoZSBJTlZJVEUuDQo+PiANCj4+IEFuZCwgZXZlbiBpZiAzKSBoYXBwZW5zLCB0aGUgVUFTIHdv dWxkIGRpc2NhcmQgdGhlIFMtRSAxODAwLg0KPj4gDQo+PiANCj4+PiBJdCB3b3VsZCBiZSBoYXJk IGZvciB0aGUgcHJveHkgdG8gdHJhY2sgd2hhdCBTLUUgdmFsdWUgd2FzIHVzZWQgaW4gdGhlDQo+ Pj4gSU5WSVRFLCBzaW5jZSBwcm94aWVzIGFyZSBnZW5lcmFsbHkgbm90IGRpYWxvZyBzdGF0ZWZ1 bGwuIEV2ZW4gaWYgcHJveHkNCj4+PiBkaWQgdHJhY2sgdGhhdCB2YWx1ZSwgaXQgY2Fubm90IHNp bXBseSBpbmNyZWFzZSB0aGUgUy1FIGluIGNsaWVudA0KPj4+VVBEQVRFLg0KPj4+DQo+Pj4gUHJv cG9zZWQgc29sdXRpb24gLS0gVUFTIHNob3VsZCBwaWNrIHRoZSBzbWFsbGVzdCBTLUUgdmFsdWUg YW5kIHVzZQ0KPj4+dGhhdC4NCj4+IA0KPj4gSSBkb3VidCBBTlkgVUEgZG9lcyB0aGF0IHRvZGF5 LCB3aGljaCBtZWFucyB0aGF0IEVWRVJZIGRlcGxveWVkIFVBIHdvdWxkDQo+PiBoYXZlIHRvIGJl IHVwZGF0ZWQgaW4gb3JkZXIgZm9yIHRoYXQgdG8gd29yay4NCj4+IA0KPj4gSW4gYWRkaXRpb24s IGl0oa9zIG5vdCBvbmx5IGFib3V0IHRoZSB0aW1lciB2YWx1ZS4gV2hhdCBpZiB0aGUgVUFDDQo+ PmNoYW5nZXMNCj4+IHRoZSByZWZyZXNoZXIgdmFsdWUgaW4gdGhlIFVQREFURT8gVGhlIFVBUyB3 aWxsIHJlY2VpdmUgobB1YWOhsSBpbiB0aGUNCj4+IElOVklURSwgYW5kIKGwdWFzobEgaW4gdGhl IFVQREFURT8gV2hhdCBkb2VzIGl0IGRvPw0KPj4gDQo+PiBTbywgSSBzdGlsbCB0aGluayB0aGUg ZWFzaWVzdCBzb2x1dGlvbiBpcyB0byBzaW1wbHkgc2F5IHRoYXQgdGhlDQo+PiBVUERBVEUtaW5z aWRlLUlOVklURSBtdXN0IG1pcnJvciB0aGUgSU5WSVRFLg0KPg0KPkJ1dCB0aGUgTVVTVCB3aWxs IG9ubHkgYXBwbHkgdG8gVUFzIHRoYXQgaW1wbGVtZW50IHRoaXMgcmV2aXNpb24uIEZvcg0KPm1h eGltdW0gZWZmZWN0IEkgdGhpbmsgd2UgbmVlZCB0byBzcGVjaWZ5IGhvdyB0byBwYXRjaCB0aGlu Z3MgdXAgd2hlbg0KPm9ubHkgb25lIGVuZCBzdXBwb3J0cyBpdCBhbmQgdGhlIG90aGVyIGVuZCAo b3IgYSBwcm94eSkgaXMgYmVoYXZpbmcgaW4gYQ0KPnByb2JsZW1hdGljIHdheS4NCg0KQWdhaW4s IHRoZSBvbmx5IGltcGFjdGVkIFVBcyB0aGF0IHdlIGFyZSBjdXJyZW50bHkgYXdhcmUgb2YgKHRo ZXJlIG1heSBvZg0KY291cnNlIGJlIG90aGVycykgYXJlIHRvIGJlIGZpeGVkLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQo= From nobody Mon Dec 4 03:20:14 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527501272E1 for ; Mon, 4 Dec 2017 03:20:14 -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 9xpEVdn_awOb for ; Mon, 4 Dec 2017 03:20:12 -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 7EE53126E7A for ; Mon, 4 Dec 2017 03:20:12 -0800 (PST) X-AuditID: c1b4fb25-385ff70000000151-b2-5a252f6aedf7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.B2.00337.A6F252A5; Mon, 4 Dec 2017 12:20:10 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Mon, 4 Dec 2017 12:20:10 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Session timer fix Thread-Index: AQHTUnT/mHDlbsAmdUSIh4IbJdtiB6L+SqVAgAM88gCAAAWigIAABYIAgBhmKiCAAIblAIAAmIIAgAEbM4CAAJm2UIABB0sAgAQhNICAAIe6AIAA2AoAgAIT6ACAAqOkgIAA0dwAgADK3wCAAKRtAIAAEWVg///6T4CAACJbgIAACTGAgAAb1oCAAA5lAIAAhseAgABz6ACAATFKAIAAYfuAgAAzyoCAAPUZgIAAgwsAgAAR8YCAAB85AIAEN1CA Date: Mon, 4 Dec 2017 11:20:09 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> 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.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <58849DEEACC6824180792F20367B6B79@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7pW6WvmqUwaSbxhYrNhxgtZhxYSqz xdcfm9gcmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyJl1qYSnokag4sPQtYwPj RaEuRk4OCQETid9b7jJ3MXJxCAkcZpT4sfA+K4SzmFGi6/UOti5GDg42AQuJ7n/aIA0iAt4S E+avZgOxmQU0JR7t3MsEYgsLaEgc2vObBaJGU+LiqWVMIHNEBPqYJLouLWEHSbAIqEg0fn7H DGLzClhL7Nn3CmrZTA6JL+fegE3lFHCQ6N02C6yBUUBM4vupNUwQ28Qlbj2ZzwRxtoDEkj3n mSFsUYmXj/+xgtiiAnoSG07cZoeIK0q0P21ghOjVk7gxdQrU1dYSJ/tboGZqSyxb+BrqIEGJ kzOfsExgFJ+FZN0sJO2zkLTPQtI+C0n7AkbWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiB UXhwy2/VHYyX3zgeYhTgYFTi4V0grxolxJpYVlyZe4hRgoNZSYTXgQEoxJuSWFmVWpQfX1Sa k1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgdGsYN+27SXMW7++ku4wj/NVevDw fUzypw2R3Vskp2u9F1Z6d/mu+9Od8i/EpCTEyw6l39hevPSgSof87SUtC11r4uM0pi1vY306 ZWG4l6/9OttFJoqX7lpsU148YTcXUMeSk2wV+jYz+g5aTwnv+7x7ztTq9aXzWIonumfXMZ1g LShSCOUyUWIpzkg01GIuKk4EAEa0lk6+AgAA Archived-At: Subject: Re: [sipcore] Session timer fix X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 11:20:14 -0000 Hi, >>On Fri, Dec 1, 2017 at 1:10 PM, Paul Kyzivat > > wrote: >>=20 >> I doubt ANY UA does that today, which means that EVERY deployed >> UA would >> have to be updated in order for that to work. >>=20 >> In addition, it=B9s not only about the timer value. What if the >> UAC changes >> the refresher value in the UPDATE? The UAS will receive =B3uac= =B2 >>in the >> INVITE, and =B3uas=B2 in the UPDATE? What does it do? >>=20 >> So, I still think the easiest solution is to simply say that the >> UPDATE-inside-INVITE must mirror the INVITE. >>=20 >>=20 >> But the MUST will only apply to UAs that implement this revision. >> For maximum effect I think we need to specify how to patch things up >> when only one end supports it and the other end (or a proxy) is >> behaving in a problematic way. >>=20 >>=20 >> This was my point exactly. We should suggest the behavior which will >> result in highest chance of success if only one of the UA implements >>it.=20 >> I think there are still scenarios which will break, like UA which >>simply=20 >> refuse the INVITE transaction with S-E if they got an UPDATE with S-E >> during this transaction (even if S-E values matched). If only one UA >> implements the update, all we hope for is to minimize the number of >> failures. From this point of view, I am not sure, what would be better: >>=20 >> a. Refusing UPDATE with mismatching S-E during INVITE transaction >> b. Accepting UPDATE and have some sort of logic which makes the safest >> possible choice between the messages (pick smallest S-E, pick largest >> Min-S-E, pick refresher option where current UA is doing the refreshing) > >Refusing an UPDATE within an INVITE has all sorts of nasty implications. >It may be doing more than just the s-t stuff. E.g. I might be doing >preconditions. IMO this is a bad path to pursue. > >Aside from accepting the UPDATE I don't think it matters much what >assumptions you make about how it impacts the s-t negotiations. Whatever >you assume has a chance to be right or wrong. Better to simply do a s-t >refresh immediately after the INVITE. Your guessing can then be limited >to what values to use in that refresh. (Note that my use of "refresh" if >the end doing this was not clearly chosen as the refresher. So maybe it >would be better to call it something else.) I don=B9t understand why you are trying to create problems that we don=B9t even know exist. So far, we are aware of an application server that sends UPDATE with changed S-E. By saying that it must not do so, we will fix that problem, because the application server is to be updated based on the correction. When you say =B3one UA=B2, it is a huge difference if that UA is an endpoin= t of which there may be thousands of deployments, or if that UA is a much smaller number of network elements (that typically are also easier to update). Regards, Christer From nobody Mon Dec 4 08:18: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 9B466127B5A for ; Mon, 4 Dec 2017 08:18:46 -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 Twq0VRI-0eIx for ; Mon, 4 Dec 2017 08:18:44 -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 EF92B127BA3 for ; Mon, 4 Dec 2017 08:18:36 -0800 (PST) X-AuditID: 12074413-38bff70000007929-8d-5a25755b5a75 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 0C.0A.31017.B55752A5; Mon, 4 Dec 2017 11:18:36 -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 vB4GIY5J014972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 4 Dec 2017 11:18:35 -0500 To: sipcore@ietf.org References: <3b6cc11a-db9b-d708-e216-fb0750c11721@gmail.com> From: Paul Kyzivat Message-ID: Date: Mon, 4 Dec 2017 11:18:34 -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: <3b6cc11a-db9b-d708-e216-fb0750c11721@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixO6iqBtTqhplcG8xl8XXH5vYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMe3rCsaCZwoVc66uY29gXCTdxcjJISFgItHy7iBTFyMXh5DA DiaJVQ8nskE435kkXs07xNrFyMEhLGAocfhFHkiDiICIxLPp/9hAbCEBG4kPs94xg9hsAloS cw79ZwEp5xWwl7hyUggkzCKgIrFzzikmEFtUIE1iz4UOFhCbV0BQ4uTMJ2A2p4CtxIbJi1hB bGYBM4l5mx8yQ9jiEreezGeCsOUlmrfOZp7AyD8LSfssJC2zkLTMQtKygJFlFaNcYk5prm5u YmZOcWqybnFyYl5eapGuuV5uZoleakrpJkZISArvYNx1Uu4QowAHoxIP7w1f1Sgh1sSy4src Q4ySHExKorwM+UAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwd6UA53pTEyqrUonyYlDQHi5I4 r9oSdT8hgfTEktTs1NSC1CKYrAwHh5IEL3cJUKNgUWp6akVaZk4JQpqJgxNkOA/QcIYikOHF BYm5xZnpEPlTjMYcPT03/jBxPJv5uoFZiCUvPy9VSpzXG2ScAEhpRmke3DRYWnnFKA70nDDv UpAqHmBKgpv3CmgVE9CqnDXKIKtKEhFSUg2M4dcbH14/w/3i5LL7b/I+dyVNmssbmj4/6PWE uNt3bpbzmiVmnv7wN3KP++f7T23klx/6wuug/YY3+eKM9lUx7al6wqG3T+Vul66Ivnj8lJPB Z9/LD5O+8pTNqjvtn/OtT/7b1xnF9QV71ka82r55luyJqGuq7i3fJvxsNYzTlqrmV7ywMrHn pRJLcUaioRZzUXEiAHDFJSIGAwAA Archived-At: Subject: Re: [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: Mon, 04 Dec 2017 16:18:47 -0000 On 11/22/17 8:16 AM, 奥村伸二 wrote: > 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     | > +--------+--------------+ The point of Min-SE is so that the UAs can avoid being forced to incur an unacceptable load of refreshes. Proxies don't do refreshes, so they don't get a say in this. Note that Min-SE does not limit the overall message rate - only the s-t refresh rate. If the proxy has a problem handling the messaging rate, then changing Min-SE isn't likely to solve that problem. > 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". Since the UAS didn't support s-t, it certainly won't be able to assume the refresher role. So the only possibilities are that the UAC act as the refresher, or else there is no s-t at all. Thanks, Paul From nobody Tue Dec 5 03:42:57 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C898B129418 for ; Tue, 5 Dec 2017 03:42:55 -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 XeOSSAI2FCPp for ; Tue, 5 Dec 2017 03:42:54 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 10667129413 for ; Tue, 5 Dec 2017 03:42:54 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id q20so10511558pgv.2 for ; Tue, 05 Dec 2017 03:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=BLGWTaj52Zm+jY5LNlJWdKpVEMkWFMM/+rKUTxr3G/E=; b=pv5bKecCk6oq4UqtwaP85SC8bN5wblPzunWCS2ev2V9taNVtJYh/6dxoHSRAZqU9Gc JAQYYq6EUHWYsoQcgnCCg1/NlfXB6TXkcZTTXFyIL2HaU6xjXq2I/pL4oA6TTnysLc4Y Y4arYyQTi/BbIFNxGWrHvV6UGVgmsaWqJfdbmSjFnGvdNM9G2bph63sPvKyqhFcF/NSq kVcnUwjw0FUjo4XAXekz9jbznhNRS9+1OsOe3fAJfKq65KmIQRLc7HiS1OSkf0VfARQx IZZwgKakMmJTeOFAf/pdR2scdgTAtNPIsI0iIqnrA+gCQhgqdH+GsRXte2UNcKE+0wKG l+hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=BLGWTaj52Zm+jY5LNlJWdKpVEMkWFMM/+rKUTxr3G/E=; b=GnTXdQAXMx5ygXI5VJIkAPwpbz+Tab3QFDiIVM/oUH8N4FvfRu12PGX3ZRmZwfdW7s GlwE21wRbZrQEqtM6KBLsjLSzLnw2iE6gzJ7jxTkpfcNCH9uM9W4CBtTDW4dgYUn3lvU HFtZi5NoxHAFN4cLgDrXgaMZDrXX9Dd3olJJaZ9p/+4lG7P/hK4q91Xde0qsU+HToOzd w07wRGk1hie27XjEUBaVegIwWvDBNuoDibCgBNcqceRRWtEFxEPlB0zxXxEFlYdCCVRN fw2zG9XSjVejv1wa9dMQyRJZOD+jLCE+mPN6SdXSasz2BTWwtAGFMLOa0BqEQ3iMPtsa jdLA== X-Gm-Message-State: AJaThX7pPXGGxY/Qidq/8swRdeC+XFp06HdPZqpY5Y7ZNKUqZI/g1EkS uL/roiz9huyhyBAciX1TmutL6PB/ X-Google-Smtp-Source: AGs4zMa+fbRE+D4xp+EmCO5AqfJ3+i4XODDf9sEbaK1FD10l7A0nXXErB58YDnK6ND8S91sQKH6nxA== X-Received: by 10.84.128.4 with SMTP id 4mr18302247pla.406.1512474173300; Tue, 05 Dec 2017 03:42:53 -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 t4sm30212703pfj.56.2017.12.05.03.42.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 03:42:52 -0800 (PST) From: OKUMURA Shinji References: <3b6cc11a-db9b-d708-e216-fb0750c11721@gmail.com> To: sipcore@ietf.org Message-ID: <89db70f2-e226-b58c-3959-9f36f4c19a13@gmail.com> Date: Tue, 5 Dec 2017 20:42:39 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 171204-2, 2017/12/04), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [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: Tue, 05 Dec 2017 11:42:56 -0000 Hi, On 2017/12/05 1:18, Paul Kyzivat wrote: > On 11/22/17 8:16 AM, OKUMURA Shinji wrote: >> 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     | >> +--------+--------------+ > > The point of Min-SE is so that the UAs can avoid being forced to incur > an unacceptable load of refreshes. Proxies don't do refreshes, so they > don't get a say in this. Note that Min-SE does not limit the overall > message rate - only the s-t refresh rate. If the proxy has a problem > handling the messaging rate, then changing Min-SE isn't likely to > solve that problem. Proxies don't do refreshes, but they get a say in this. Because proxies reject the request with a 422 response. IMO if proxies increase the value of the Min-SE in a proxied request, this problem can be solved. In the above example, if P1 modifies the value of the Min-SE to 3600, P2 can not decrease the value of the Session-Expires. >> 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". > > Since the UAS didn't support s-t, it certainly won't be able to assume > the refresher role. So the only possibilities are that the UAC act as > the refresher, or else there is no s-t at all. I've understood what you say. But in this case proxy should remember the value of refresher and if its value is "uas", I think proxy does not need to do this. UA that supports sessiontimer seems to have no freedom not to use sessiontimer. Regards, Shinji From nobody Wed Dec 6 02:56: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 2FBA8127876 for ; Wed, 6 Dec 2017 02:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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] 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 HPgQF3x_jXfQ for ; Wed, 6 Dec 2017 02:56:28 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0117.outbound.protection.outlook.com [104.47.33.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332A41296CD for ; Wed, 6 Dec 2017 02:56:28 -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=khrtmg/KkhqMLE/TJo+DyzlZztCpIL+ck1KoNk59gso=; b=O6w0Tr2FJoUMM46yS7/Ji3NEPRRDEy8cqnCXcRCvpVkzxFBlZXwy/gpuI9wOdrEWI9RcnZYpXK9PoR7sr4xwatTJhdCyKbvp8CZFNYfWw6doCtHHtxFc04HElvwJJYtRrc5Jeark2eAhloee9F8Jz7cy8GP6M5ZkosWzLMosXTs= Received: from CY1PR02MB1262.namprd02.prod.outlook.com (10.163.16.155) by BN6PR02MB2836.namprd02.prod.outlook.com (10.175.96.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Wed, 6 Dec 2017 10:56:25 +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.012; Wed, 6 Dec 2017 10:56:24 +0000 From: Mickey Arnold To: Christer Holmberg CC: "sipcore@ietf.org" Thread-Topic: Draft new version: holmberg-sip-push-03 Thread-Index: AQHTZDbjH+bahhtpbkKBjZ0zic+MfqM2Lsig Date: Wed, 6 Dec 2017 10:56:24 +0000 Message-ID: References: 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:90f5:b864:b9ce:de42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR02MB2836; 6:Bnwg+E99DjCElGlEo6A3bsleZd+IWRhc8NLve3JdkvqBXosFWPH9BQHUH7tEnTXLBnV/UBJrWJKYAlh+LASaTueXLYPA7A/RmCflMPIh0V+8yGTnNkA9zkKYG5prkChkNbiLFmVc3xC6hp0VS9/N4Hfbyj1iF7N+dj6T2GSnro5NnAIcMeT4Y4gKsNrzF0HnB2r7LFORiLExBt/yxQPZVb92Hw4pk/rIzLNoXQZMB/1zzixm58mHL7cNSP4zBGod391a6cMukjlsuFjt+jJDp79Iuldrk+5whLUGnHKI2TlVIJpj/mEyuQDLT1J1sceYWVlucnlzhwAZmfj9cikmxGVZG79RS5xsY9pXEhNA4ms=; 5:pTH1JG7cBVL4ez+X68XA/Pj217sopyRSxvgvxbQVUNh1gJ40I7l8NzP2o56hKx4UjPOimWdszNQRRlGqFQXuzVaJslAYGBFz3MuyQxUDc6fz3aFb0d55F4YOShSuYCzKXcdkFwL0LhVvvCTG7paSBA69OEuxI2jow/LhjaxK7nA=; 24:XXtkfpH3UpBiVsR7whY2iqXTex/ttlUPTclYMHycXGa0H1GbgGfkVL6hUdBxNvam7idLsM/JcdBYPlI96VoQyvgS0Q7DACV/Dy2XR3ZXaYw=; 7:IL4MyUmI0O2HhVMeCx8af4u56yanqTS2G3zkR/sak1d+6cy7oAFP6W0alX/HC+iQ+ZdYzYh/MlDxgJxm1nH32uJQH46UgWyvCywakzjclbxOtWRV/ex1ZTTIhp2lDFgq1qsXfrld03lr0/GJcOP3dowFyCOgXXpbTX1qM5/UPAp6qvFtfWUrbJFOBbrRTU3CuGHL2miXs3BfbbU4bmdp+a4dRF14DVD0HLN2IB1yXN5A29oD+1LFVEtG+0DrpYFI x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(199004)(189003)(790700001)(478600001)(25786009)(316002)(68736007)(229853002)(230783001)(86362001)(99286004)(74316002)(7736002)(2950100002)(3280700002)(81156014)(3660700001)(6916009)(102836003)(101416001)(8936002)(9326002)(8676002)(53546010)(55016002)(33656002)(2906002)(5660300001)(6506006)(2900100001)(6116002)(81166006)(105586002)(53946003)(97736004)(9686003)(53936002)(54896002)(14454004)(6246003)(77096006)(4326008)(106356001)(6436002)(7696005)(72206003)(6306002)(76176011)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR02MB2836; H:CY1PR02MB1262.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: c1891b8a-9331-42a6-e906-08d53c97fe0b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:BN6PR02MB2836; x-ms-traffictypediagnostic: BN6PR02MB2836: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231022)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:BN6PR02MB2836; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR02MB2836; x-forefront-prvs: 05134F8B4F 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_CY1PR02MB12622A105E77DF36909BDE13E9320CY1PR02MB1262namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: c1891b8a-9331-42a6-e906-08d53c97fe0b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 10:56:24.1933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR02MB2836 Archived-At: Subject: Re: [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: Wed, 06 Dec 2017 10:56:32 -0000 --_000_CY1PR02MB12622A105E77DF36909BDE13E9320CY1PR02MB1262namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, As we're considering adopting this draft (which I support), I reviewed it a= nd had the following comments, which I'd like to see addressed once it's ad= opted. There's also a few smaller things that I think could use tweaking bu= t those are mostly dependent on the overall solution so I'll save them for = now. General * It would be useful to have a name for the logical function of sending= the push notifications as it gets a bit confusing trying to refer to multi= ple SIP Proxys, some of which may be sending push notifications and/or be a= SIP registrar. I'm going to use the term PNG (Push Notification Gateway) h= ere to help disambiguate but I'd be perfectly happy with a different name . * I believe the implication in this document is that the SIP UA must al= ways have REGISTER requests sent via the PNG, please can you confirm? * I'm a little confused about the overall design proposed here. So taki= ng a step back, my understanding from your draft is the following. The SIP registrar is responsible for: * Keeping track of the state of the push notification subscriptions = as communicated by the UA (as part of a SIP registration). * Adding the correct URI parameters to SIP requests based on these s= ubscriptions embedded in the SIP registrations. * Serving information to the PNG to send push notifications for re-r= egistrations. The PNG is then responsible for: * Prompting the UA to re-register based on information stored on the re= gistrar. * Taking URI parameters from SIP requests, generating the push notifica= tions, then forwarding on the request once a re-registration is received. With some optimisations if the PNG is also the SIP registrar. However, in the case where the PNG is not also the SIP registrar I don't th= ink this solution quite works, as I'll outline below. Section 5.2 If the SIP UA needs to perform periodic re-registrations, the SIP proxy needs to have information about when those re-registrations are to be performed. The SIP proxy either needs to contain the SIP registrar functionality, or the SIP proxy needs to retreive the information from the registrar using some other mechanism. If my view of the overall design above is correct then I think we've alread= y hit a snag. If the PNG is on a non-registrar SIP Proxy then how does the = PNG know what SIP UAs to query the registrar for? Given that the REGISTER r= equests must go through the PNG it seems simpler for the PNG to save off th= e push notification in a mapping with the registration and take responsibil= ity for generating the push notification for refreshing the registration. T= his avoids adding another (presumably non-SIP?) interface between the regis= trar and the PNG. If the PNG is also the registrar then it needs to generate notifications fo= r each of its registrations every time a registration would expire. That's = not a huge problem but does seem like a big increase in load on the registr= ar. I also don't think it's conceptually correct for the registrar in the c= ore of the network to need to take responsibility for interoperating with d= evices that require push notifications to be able to communicate reliably. Section 5.3 When the SIP proxy receives a SIP request for a new dialog (e.g., a SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE request) aimed for a SIP UA, if the Request-URI of the request contains a pn-prid URI parameter, the SIP proxy triggers a push request towards the push notification server associated with the PRID. If the PNG is also the registrar then the parameter won't be on the inbound= SIP request and shouldn't be required to trigger a push notification. I su= spect this is the intention but it would be good to have it clarified. Agai= n, this also feels like the wrong place in the network for this functionali= ty to be invoked and is a big load increase on the registrar. If the PNG is on a non-registrar SIP Proxy then there is a reliance on the = registrar to be compliant and store/add the push notification parameters an= d all intervening network elements to not remove the push notification para= meters. In theory that should be fine but in practice requires a handful of= other pieces of network equipment to be RFC compliant. Given my comments o= n section 5.2 I think it makes sense that if the PNG is on a non-registrar = SIP Proxy then it is permitted to use locally stored subscription details = to generate push notifications when receiving inbound SIP requests, as an a= lternative to requiring URI parameters to be present. This allows a PNG on = a non-registrar SIP Proxy that supports this standard to operate independen= tly of a core network that doesn't support this standard. Given this is a r= elatively thin layer of access network functionality it will likely be easi= er for network operators to add in at the edge of their network rather than= replace their registrar. The introduction's 5th paragraph also implies thi= s is allowable so maybe this was the intention? If the proxy is not able to contact the push notification provider, or even determine which push notification provider to contact, it SHOULD reject the SIP request. If the PNG is on a non-registrar SIP proxy and doesn't support a push notif= ication service required by the UA then we get the following scenario: * UA registers successfully using a PNS that the PNG doesn't suppor= t. * Inbound call is routed to the UA. * PNG rejects the call. * UA requires being woken up to re-register. * PNG cannot contact the PNS to generate a notification to prompt f= or this. I believe that the PNG needs to be able to reject register requests that re= quire an unsupported push notification service. That gives immediate feedba= ck to the UA rather than a "silent failure" case where the registration is = successful but there's no way for the UA to reliably receive inbound calls. Section 7 I think the SIP parameters can be simplified here. Take the following cases= , a UA using APNs would send the following parameters (from section 9): pn-type =3D apns:DEF123GHIJ.com.yourcompany.yourexampleapp pn-prid =3D 00fc13adff78512 Given the description in Section 5.1: In some cases the push notification provider can be retrieved from the pn-prid URI parameter. In other cases the pn-type URI parameter is used to identity the push notification provider." I think a PNS that provides information based on a URI would look like this= : pn-type =3D ???: pn-prid =3D genericPNS ? How the data is handled is PNS specific, but in all cases the first thing a= ny SIP proxy implementation would need to do is work out what type of push = notification service is being used. I think it makes it simpler to read and= implement (less escaping) if the pn-type is split into two URI parameters = (possibly but not necessarily renamed). For APNs that would look something = like this. pns-provider =3D apns pn-prid =3D 00fc13adff78512 pns-param =3D DEF123GHIJ.com.yourcompany.yourexampleapp For the generic service is would look like pns-provider =3D genericPNS pn-prid =3D pns-param =3D That nominally splits into: * Name of provider, which the PNG can use to decide a) whether the serv= ice is supported b) how to handle it if it is. * Token used to identify the SIP UA's subscription with the PNS. * Extra PNS specific details used for contacting either the push notifi= cation service or the UA application on the target device. Conclusion I'd recommend allowing a PNG on a non-registrar SIP proxy to store off mini= mal details of push notification services in a mapping with the Contact hea= der SIP URI from successful registration flows through the PNG. The PNG on = a non-registrar SIP proxy can then handle re-registrations and outbound cal= ls without any requirement on the capabilities of the rest of the network. = This allows the work to be distributed across several such SIP Proxys at th= e edge of the core network, requires only one spec compliant network elemen= t and can easily be added on an existing, or new, light-weight SIP proxy wi= thout too much disturbance to the network. In the case of the PNG being on a non-registrar SIP proxy we'd then have th= e following responsibilities: The SIP registrar is responsible for: * Nothing special other than being a SIP registrar. The PNG is then responsible for: * Storing off push notification details on successful REGISTER requests= flowing through the SIP proxy in a mapping with the registration. * Keeping track of registration expiry and prompting the UA to re-regis= ter. * Policing register requests to check that an acceptable push notificat= ion service is requested. * Taking URI parameters from SIP requests, generating the push notifica= tions, then forwarding on the request once a re-registration is received OR= matching inbound SIP requests with stored registration details and generat= ing push notifications. I hope that's useful, please let me know if you have any questions or would= like any clarifications. Thanks very much, Michael Arnold From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 23 November 2017 08:42 To: sipcore@ietf.org Subject: [sipcore] Draft new version: holmberg-sip-push-03 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_CY1PR02MB12622A105E77DF36909BDE13E9320CY1PR02MB1262namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

As we’re considering adopting this draft (whi= ch I support), I reviewed it and had the following comments, which I’= d like to see addressed once it’s adopted. There’s also a few smaller things that I think could use tweaking bu= t those are mostly dependent on the overall solution so I’ll save the= m for now.

 

General

  • <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= It would be useful to have a name for the logical function of sending the p= ush notifications as it gets a bit confusing trying to refer to multiple SIP Proxys, some of which may be sending push notific= ations and/or be a SIP registrar. I’m going to use the term PNG (Push= Notification Gateway) here to help disambiguate but I’d be perfectly= happy with a different name .
  • I believe the implicat= ion in this document is that the SIP UA must always have REGISTER requests = sent via the PNG, please can you confirm?
  • I’m a little confused about the o= verall design proposed here. So taking a step back, my understanding from y= our draft is the following.

The SIP registrar is responsible for:

    • <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= Keeping track of the state of the push notification subscriptions as commun= icated by the UA (as part of a SIP registration).
      • Add= ing the correct URI parameters to SIP requests based on these subscriptions= embedded in the SIP registrations.
    • Serving informati= on to the PNG to send push notifications for re-registrations.

The PNG is then responsible for:

  • Prompting the UA to re-register based on information stored on the= registrar.
  • Taking URI parameters from SIP requests= , generating the push notifications, then forwarding on the request once a = re-registration is received.

With some optimisation= s if the PNG is also the SIP registrar.

However, in the case w= here the PNG is not also the SIP registrar I don’t think this solutio= n quite works, as I’ll outline below.

 

Section 5.2

   If the SIP UA needs to p=
erform periodic re-registrations, the SIP
   proxy needs to have info=
rmation about when those re-registrations are
   to be performed.  T=
he SIP proxy either needs to contain the SIP
   registrar functionality,=
 or the SIP proxy needs to retreive the
   information from the reg=
istrar using some other mechanism.
 

If my view of the overall design above is correct t= hen I think we’ve already hit a snag. If the PNG is on a non-registra= r SIP Proxy then how does the PNG know what SIP UAs to query the registrar for? Given that the REGISTER requests must go throu= gh the PNG it seems simpler for the PNG to save off the push notification i= n a mapping with the registration and take responsibility for generating th= e push notification for refreshing the registration. This avoids adding another (presumably non-SIP?) interfa= ce between the registrar and the PNG.

 

If the PNG is also the registrar then it needs to g= enerate notifications for each of its registrations every time a registrati= on would expire. That’s not a huge problem but does seem like a big increase in load on the registrar. I also don’t= think it’s conceptually correct for the registrar in the core of the= network to need to take responsibility for interoperating with devices tha= t require push notifications to be able to communicate reliably.

 

Section 5.3

   When the SIP proxy recei=
ves a SIP request for a new dialog (e.g., a
   SIP INVITE request) or a=
 non-dialog SIP request (e.g., a SIP MESSAGE
   request) aimed for a SIP=
 UA, if the Request-URI of the request
   contains a pn-prid URI p=
arameter, the SIP proxy triggers a push
   request towards the push=
 notification server associated with the
   PRID. =

 
If the PNG is also the registrar then the parameter won’t be on=
 the inbound SIP request and shouldn’t be required to trigger a push =
notification. I suspect this is the intention but it would be good to have =
it clarified. Again, this also feels like the wrong place in the network fo=
r this functionality to be invoked and is a big load increase on the regist=
rar.
 
If the PNG is on a non-registrar SIP Proxy then there is a reliance o=
n the registrar to be compliant and store/add the push notification paramet=
ers and all intervening network elements to not remove the push notificatio=
n parameters. In theory that should be fine but in practice requires a hand=
ful of other pieces of network equipment to be RFC compliant. Given my comm=
ents on section 5.2 I think it makes sense that if the PNG is on a non-regi=
strar SIP Proxy then it is permitted to use  locally stored subscripti=
on details to generate push notifications when receiving inbound SIP reques=
ts, as an alternative to requiring URI parameters to be present. This allow=
s a PNG on a non-registrar SIP Proxy that supports this standard to operate=
 independently of a core network that doesn’t support this standard. =
Given this is a relatively thin layer of access network functionality it wi=
ll likely be easier for network operators to add in at the edge of their ne=
twork rather than replace their registrar. The introduction’s 5t=
h paragraph also implies this is allowable so maybe this was the inte=
ntion?
 
   If the proxy is not able=
 to contact the push notification provider,
   or even determine which =
push notification provider to contact, it
   SHOULD reject the SIP re=
quest.
 
If the PNG is on a non-registrar SIP proxy and doesn’t support =
a push notification service required by the UA then we get the following sc=
enario: 
·         UA registers successfully using a PNS that the P=
NG doesn’t support.
·         Inbound call is routed to the UA.
·         PNG rejects the call.
·         UA requires being woken up to re-register.<=
/o:p>
·         PNG cannot contact the PNS to generate a notific=
ation to prompt for this.
I believe that the PNG needs to be able to reject register requests t=
hat require an unsupported push notification service. That gives immediate =
feedback to the UA rather than a “silent failure” case where th=
e registration is successful but there’s no way for the UA to reliabl=
y receive inbound calls.
 

Section 7

I think the SIP parameters can be simplified here. = Take the following cases, a UA using APNs would send the following paramete= rs (from section 9):

pn-type =3D apns:DEF123GHIJ.com.yourcompany.yourexampleapp= 

pn-prid =3D 00fc13adff78512

 

Given the description in Section 5.1:

   In some cases the push n=
otification provider can be retrieved from

   the pn-prid URI parameter.  In other cas= es the pn-type URI parameter

   is used to identity the push notification pro= vider."

 

I think a PNS that provides information based on a = URI would look like this:

pn-type =3D ???: <generic PNS token>

pn-prid =3D genericPNS <URL>?

 

How the data is handled is PNS specific, but in all= cases the first thing any SIP proxy implementation would need to do is wor= k out what type of push notification service is being used. I think it makes it simpler to read and implement (less escapi= ng) if the pn-type is split into two URI parameters (possibly but not neces= sarily renamed). For APNs that would look something like this.

pns-provider =3D apns

pn-prid =3D 00fc13adff78512

pns-param =3D DEF123GHIJ.com.yourcompany.yourexampleapp

 

For the generic service is would look like

pns-provider =3D genericPNS

pn-prid =3D <generic PNS token>

pns-param =3D <URL>

 

That nominally splits into:

  • <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= Name of provider, which the PNG can use to decide a) whether the service is= supported b) how to handle it if it is.
  • Token used= to identify the SIP UA’s subscription with the PNS.
  • Extra PNS specific details used for contacting either the push notifi= cation service or the UA application on the target device.

 

Conclusion

I’d recommend allowing a PNG on a non-registr= ar SIP proxy to store off minimal details of push notification services in = a mapping with the Contact header SIP URI from successful registration flows through the PNG. The PNG on a non-registrar SIP proxy c= an then handle re-registrations and outbound calls without any requirement = on the capabilities of the rest of the network. This allows the work to be = distributed across several such SIP Proxys at the edge of the core network, requires only one spec complia= nt network element and can easily be added on an existing, or new, light-we= ight SIP proxy without too much disturbance to the network.

 

In the case of the PNG being on a non-registrar SIP= proxy we’d then have the following responsibilities:

The SIP registrar is responsible for:

  • <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= Nothing special other than being a SIP registrar.

    • The PNG is then responsible for:<= /p>

    • <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= Storing off push notification details on successful REGISTER requests flowi= ng through the SIP proxy in a mapping with the registration.
    • Keeping track of registration expiry and prompting the UA to re-reg= ister.
    • Policing register requests to check that an ac= ceptable push notification service is requested.
    • Taki= ng URI parameters from SIP requests, generating the push notifications, the= n forwarding on the request once a re-registration is received OR matching inbound SIP requests with stored registration deta= ils and generating push notifications.

     

    I hope that’s useful, please let me know if y= ou have any questions or would like any clarifications.

     

    Thanks very much,

    Michael Arnold

     =

    From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
    Sent: 23 November 2017 08:42
    To: sipcore@ietf.org
    Subject: [sipcore] Draft new version: holmberg-sip-push-03

     

    Hi,

     

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

     

    The draft now also covers re-registrati= ons:

    • UA performing re-registrations when a push notification is received.<= /o:p>
    • Proxy forwarding SIP request when it receives the re-registration request.=

    Regards,

     

    Christer

--_000_CY1PR02MB12622A105E77DF36909BDE13E9320CY1PR02MB1262namp_-- From nobody Wed Dec 6 09:00: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 C9DCF127F0E for ; Wed, 6 Dec 2017 09:00:06 -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 Yp2_hmFo9B4i for ; Wed, 6 Dec 2017 09:00:03 -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 E6D6F1275C5 for ; Wed, 6 Dec 2017 09:00:02 -0800 (PST) X-AuditID: c1b4fb30-cc1ff700000029e3-f5-5a2822105607 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.94.10723.012282A5; Wed, 6 Dec 2017 18:00:01 +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; Wed, 6 Dec 2017 18:00:00 +0100 From: Christer Holmberg To: Mickey Arnold CC: "sipcore@ietf.org" Thread-Topic: Draft new version: holmberg-sip-push-03 Thread-Index: AQHTZDbjH+bahhtpbkKBjZ0zic+MfqM2LsiggABetiA= Date: Wed, 6 Dec 2017 16:59:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C04063D@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.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7va6gkkaUwbZHnBaHWzayW3z9sYnN gcljyZKfTB5Hb85lDmCK4rJJSc3JLEst0rdL4Mp4uXkLY8E0p4olN90aGL+bdDFyckgImEi8 mzCLqYuRi0NI4DCjxM+XC5ghnMWMEuuv/QZyODjYBCwkuv9pgzSICBhK/Nl5ghXEZhbQlHi0 cy8TiC0MNOjy/o2sEDWmEg3HljNB2FYSk65PZAIZwyKgIrFxWjJImFfAV+LEqyksEKv6GCW6 l39gA0lwCsRKrJ/1mwXEZhQQk/h+ag0TxC5xiVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ksSi 25+h6vUkbkydwgZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbQ4tTgp N93ISC+1KDO5uDg/Ty8vtWQTIzBKDm75bbCD8eVzx0OMAhyMSjy8h6U1ooRYE8uKK3MPMUpw MCuJ8F6+rB4lxJuSWFmVWpQfX1Sak1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1Oq gXGFgsuih6Uzb86Z8l3u3RnedZovfJ9dfLNJ7F6XeMjsp5bBl9rXvmNauIDng8ivJ7svLVon 0aYQv+jG2vgzp14l9F59urM2+uJWnd6ts+eu3qTcyHS34rBeiqjspxNb1lmdyrt8veDgjeJp thseh2V81P5wqL9zttOG5HaNEJfDtQIud3N4Sxa/VGIpzkg01GIuKk4EACZ5mV6OAgAA Archived-At: Subject: Re: [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: Wed, 06 Dec 2017 17:00:07 -0000 Hi Mickey, Thanks for your comments! Please see my replies inline. General > . It would be useful to have a name for the logical function of sending t= he push notifications as it gets a bit confusing trying to=20 > refer to multiple SIP Proxys, some of which may be sending push notificat= ions and/or be a SIP registrar. I'm going to use the=20 > term PNG (Push Notification Gateway) here to help disambiguate but I'd be= perfectly happy with a different name . Unlike e.g., 3GPP, in IETF we normally don't define new SIP functions. We d= efine SIP features, and then we describe the feature impacts on SIP UAs and= /or SIP proxies. > . I believe the implication in this document is that the SIP UA must alwa= ys have REGISTER requests sent via the PNG, please can you confirm? That is correct. > . I'm a little confused about the overall design proposed here. So taking= a step back, my understanding from your draft is the following.=20 > The SIP registrar is responsible for: > o Keeping track of the state of the push notification subscriptions as co= mmunicated by the UA (as part of a SIP registration). > o Adding the correct URI parameters to SIP requests based on these subscr= iptions embedded in the SIP registrations. > o Serving information to the PNG to send push notifications for re-regist= rations. > The PNG is then responsible for: > o Prompting the UA to re-register based on information stored on the regi= strar. > o Taking URI parameters from SIP requests, generating the push notificati= ons, then forwarding on the request once a re-registration is received. > With some optimisations if the PNG is also the SIP registrar.=20 > However, in the case where the PNG is not also the SIP registrar I = don't think this solution quite works, as I'll outline below. > > Section 5.2 >=A0=A0 If the SIP UA needs to perform periodic re-registrations, the SIP >=A0=A0 proxy needs to have information about when those re-registrations a= re >=A0=A0 to be performed.=A0 The SIP proxy either needs to contain the SIP >=A0=A0 registrar functionality, or the SIP proxy needs to retrieve the >=A0=A0 information from the registrar using some other mechanism. > > If my view of the overall design above is correct then I think we've alre= ady hit a snag. If the PNG is on a non-registrar SIP Proxy=20 > then how does the PNG know what SIP UAs to query the registrar for? Given= that the REGISTER requests must go through the=20 > PNG it seems simpler for the PNG to save off the push notification in a m= apping with the registration and take responsibility=20 > for generating the push notification for refreshing the registration. Thi= s avoids adding another (presumably non-SIP?) interface=20 > between the registrar and the PNG. > > If the PNG is also the registrar then it needs to generate notifications = for each of its registrations every time a registration would expire. That'= s=20 > not a huge problem but does seem like a big increase in load on the regis= trar. I also don't think it's conceptually correct for the registrar in the > core of the network to need to take responsibility for interoperating wit= h devices that require push notifications to be able to communicate reliabl= y. You raise concern about implementing the PNG as part of the registrar in a = number of places, but I will address it here. Section 5.2. allows the PNG to be part of the registrar, or to be part of a= non-registrar - in which case it "needs to retrieve the information from t= he registrar using some other mechanism". The mapping table you mention wou= ld be an example of such "other mechanism", but I don't think that is somet= hing we want to standardize. And, there are also other mechanisms that can = be used. I don't think the document shall prevent people from implementing the PNG a= s part of the registrar, if that's what they want to do. Vendors and operat= ors need to figure out what works best for them. > Section 5.3 >=A0=A0 When the SIP proxy receives a SIP request for a new dialog (e.g., a >=A0=A0 SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAG= E >=A0=A0 request) aimed for a SIP UA, if the Request-URI of the request >=A0=A0 contains a pn-prid URI parameter, the SIP proxy triggers a push >=A0=A0 request towards the push notification server associated with the >=A0=A0 PRID.=20 > > If the PNG is also the registrar then the parameter won't be on the inbou= nd SIP request and shouldn't be required to trigger a=20 > push notification. I suspect this is the intention but it would be good t= o have it clarified. That's a good point. We need to clarify that. > If the PNG is on a non-registrar SIP Proxy then there is a reliance on th= e registrar to be compliant and store/add the push=20 > notification parameters and all intervening network elements to not remov= e the push notification parameters. The reason the PNS parameters are defined as URI parameters is because the = registrar will store them, and include them in requests, using standard reg= istrar procedures - we don't need to define new push-specific registrar fun= ctionality. >=A0=A0If the proxy is not able to contact the push notification provider, >=A0 or even determine which push notification provider to contact, it >=A0=A0SHOULD reject the SIP request. > > If the PNG is on a non-registrar SIP proxy and doesn't support a push not= ification service required by the UA then we get the following scenario:=20 > . UA registers successfully using a PNS that the PNG doesn't support. > . Inbound call is routed to the UA. > . PNG rejects the call. > . UA requires being woken up to re-register. > . PNG cannot contact the PNS to generate a notification to prompt for thi= s. > I believe that the PNG needs to be able to reject register requests that = require an unsupported push notification service.=20 > That gives immediate feedback to the UA rather than a "silent failure" ca= se where the registration is successful but there's=20 > no way for the UA to reliably receive inbound calls. I agree. I was supposed to include text about that in the current version, = but I realize I forgot. There are also mechanisms (e.g., RFC 6809) that can be used to inform the U= A what PNS the proxy supports. > Section 7 > I think the SIP parameters can be simplified here. Take the following cas= es, a UA using APNs would send the following parameters (from section 9): > pn-type =3D apns:DEF123GHIJ.com.yourcompany.yourexampleapp > pn-prid =3D 00fc13adff78512 > > Given the description in Section 5.1: >=A0=A0 In some cases the push notification provider can be retrieved from >=A0=A0 the pn-prid URI parameter.=A0 In other cases the pn-type URI parame= ter >=A0=A0 is used to identity the push notification provider." > > I think a PNS that provides information based on a URI would look like th= is: > pn-type =3D ???: > pn-prid =3D genericPNS ? > > How the data is handled is PNS specific, but in all cases the first thing= any SIP proxy implementation would need to do is work out=20 > what type of push notification service is being used. I think it makes it= simpler to read and implement (less escaping) if the pn-type=20 > is split into two URI parameters (possibly but not necessarily renamed). = For APNs that would look something like this. > pns-provider =3D apns > pn-prid =3D 00fc13adff78512 > pns-param =3D DEF123GHIJ.com.yourcompany.yourexampleapp > > For the generic service is would look like > pns-provider =3D genericPNS > pn-prid =3D > pns-param =3D > > That nominally splits into: > . Name of provider, which the PNG can use to decide a) whether the servic= e is supported b) how to handle it if it is. > . Token used to identify the SIP UA's subscription with the PNS. > . Extra PNS specific details used for contacting either the push notifica= tion service or the UA application on the target device. I will double check my notes at work tomorrow (I am out of office today), b= ut from a first look I don't see any issues with your suggestion. I did remove quite a bit of your text, as much was about the PNG-in-the-reg= istrar. Please let me know if I forgot to address some of your comments - i= f I did, it was not on purpose :) Regards, Christer From nobody Thu Dec 7 04:55: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 3080C129353 for ; Thu, 7 Dec 2017 04:55: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, 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 NnbPVnNl6Xnh for ; Thu, 7 Dec 2017 04:55:27 -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 62283124D6C for ; Thu, 7 Dec 2017 04:55:26 -0800 (PST) X-AuditID: c1b4fb30-ca9ff700000029e3-e6-5a293a3c3032 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.DD.10723.C3A392A5; Thu, 7 Dec 2017 13:55:24 +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; Thu, 7 Dec 2017 13:55:24 +0100 From: Christer Holmberg To: Mickey Arnold CC: "sipcore@ietf.org" Thread-Topic: Draft new version: holmberg-sip-push-03 - URI parameters Thread-Index: AQHTb1qlTatFuNGMRU+TW0K/440psg== Date: Thu, 7 Dec 2017 12:55:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D64F06EB2718Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7q66NlWaUwaobJhaHWzayW3z9sYnN gcljyZKfTB5Hb85lDmCK4rJJSc3JLEst0rdL4Mq4sKaTseDjfsaKj9d+szQwNq1k7GLk4JAQ MJHYPCmyi5GLQ0jgMKPEiTufWCGcxYwSPV9Ws4IUsQlYSHT/0+5i5OQQETCU+LPzBCuIzSyg KfFo514mkBJhAVeJYxeDIUrcJB5emc8KYetJrHjQwQhiswioSJzsv8cGYvMKWEtMvHMCzGYU EJP4fmoNE8RIcYlbT+aD2RICAhJL9pxnhrBFJV4+/gc2UxRo5oYTt9khzleUWN4vB9GaIPHh wD1GiPGCEidnPmGZwCg8C8nUWUjKZiEpg4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNta4tPx NhZkNQsYOVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbVwS2/DXYwvnzueIhRgINRiYf3 l6ZmlBBrYllxZe4hRgkOZiUR3it8QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Jz15o4QE0hNL UrNTUwtSi2CyTBycUg2Mm/+qdNzJn8gdwrmkQmphpcZz4fWXGU0X7LT+JGvYzxORIbJcmoHJ vmSLmrmh91quRg2m+qCzGY+bDmfPCytgu37snOP56dwdxfOuLIzqs553fWHEvl/ZEYwXC6SM /ytZu1mu3i+vOnHTF9OXHmydc7ZIsXfqyUXXfIpb07t/6sKHVl/3t89RYinOSDTUYi4qTgQA E+6O86YCAAA= Archived-At: Subject: Re: [sipcore] Draft new version: holmberg-sip-push-03 - URI parameters 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, 07 Dec 2017 12:55:30 -0000 --_000_D64F06EB2718Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mickey, =85 >Section 7 >I think the SIP parameters can be simplified here. Take the following case= s, a UA using APNs would send the following parameters (from section 9): >pn-type =3D apns:DEF123GHIJ.com.yourcompany.yourexampleapp >pn-prid =3D 00fc13adff78512 > >Given the description in Section 5.1: > In some cases the push notification provider can be retrieved from > the pn-prid URI parameter. In other cases the pn-type URI parameter > is used to identity the push notification provider." > >I think a PNS that provides information based on a URI would look like thi= s: >pn-type =3D ???: >pn-prid =3D genericPNS ? > >How the data is handled is PNS specific, but in all cases the first thing = any SIP proxy implementation would need to do is work out what type of push= notification service is being used. I think it makes it simpler >to read and implement (less escaping) if the pn-type is split into two URI= parameters (possibly but not necessarily renamed). For APNs that would loo= k something like this. >pns-provider =3D apns >pn-prid =3D 00fc13adff78512 >pns-param =3D DEF123GHIJ.com.yourcompany.yourexampleapp > >For the generic service is would look like >pns-provider =3D genericPNS >pn-prid =3D >pns-param =3D I had a look at this, and in general I have no problem to place the pns par= ameters in a separate URI parameter (pns-param). However, I don=92t think we can use syntax for the pns-param. In the= case of Firebase, the value represents the Sender ID, which is not a URL. = I don=92t even think the value in your apps example above is a valid URL, a= s it lacks the scheme :) So, I suggest to keep pvalue: pns-param =3D pvalue ;pvalue as defined in RFC 3261 Regards, Christer --_000_D64F06EB2718Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <75F432BCA41A7046A4BF620AF89E44A1@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Mickey,

=85
 

>Section 7

>I think the SIP parameters can be simplified he= re. Take the following cases, a UA using APNs would send the following para= meters (from section 9):

>pn-type =3D apns:DEF123GHIJ.com.yourcompany.yourexampl= eapp

>pn-prid =3D 00fc13adff78512<=
/o:p>

> 

>Given the description in Section 5.1:

>   In some cases the pu=
sh notification provider can be retrieved from

>   the pn-prid URI parameter.  In other case= s the pn-type URI parameter

>   is used to identity the push notification prov= ider."

> 

>I think a PNS that provides information based o= n a URI would look like this:

>pn-type =3D ???: <generic PNS token><= /span>

>pn-prid =3D genericPNS <URL>?<= /p>

> 

>How the data is handled is PNS specific, but in= all cases the first thing any SIP proxy implementation would need to do is= work out what type of push notification service is being used. I think it makes it simpler

>to read and implement (less escap= ing) if the pn-type is split into two URI parameters (possibly but not nece= ssarily renamed). For APNs that would look something like this.

>pns-provider =3D apns

>pn-prid =3D 00fc13adff78512<=
/o:p>

>pns-param =3D DEF123GHIJ.com.yourcompany.yourexampleap= p

> 

>For the generic service is would look like=

>pns-provider =3D genericPNS

>pn-prid =3D <generic PNS token>

>pns-param =3D <URL>

I had a look at this, and in general I have no problem to place the pn= s parameters in a separate URI parameter (pns-param).

 
However, I don=92t think we can use <URL> syntax for the pns-par= am.  In the case of Firebase, the value represents the Sender ID, whic= h is not a URL. I don=92t even think the value in your apps example above i= s a valid URL, as it lacks the scheme :)

So, I suggest to keep pvalue:

       pns-param =3D pvalue    ;pvalue a= s defined in RFC 3261

Regards,

Christer

--_000_D64F06EB2718Dchristerholmbergericssoncom_-- From nobody Fri Dec 8 05:36: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 1A4C1124D6C for ; Fri, 8 Dec 2017 05:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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] 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 4-6Nxm_Y3qDK for ; Fri, 8 Dec 2017 05:36:42 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0134.outbound.protection.outlook.com [104.47.32.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4615124B17 for ; Fri, 8 Dec 2017 05:36:42 -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=gL5AZ1iHJN5TGsXJXRGhcV/LtXhVlhWcRdXtUA0T0kw=; b=W4yxzjo+M3YgB8Y5e+mHMLlD1+30WNfuZ8mGApTU/CHsiWdgabyri/Ns9YeVrdRM3Rl/Vfr3n2kB16dRwkDrNb73UBhe1BjFYzApk6XQ5LEFdxw5r+xYWEl0ugYeUmXi6X91coqi1UKOKwCvhn5BL1YYn4Gf8/tdSGDDt1iZ3rg= 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.302.9; Fri, 8 Dec 2017 13:36:40 +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.0302.011; Fri, 8 Dec 2017 13:36:40 +0000 From: Mickey Arnold To: Christer Holmberg CC: "sipcore@ietf.org" Thread-Topic: Draft new version: holmberg-sip-push-03 - URI parameters Thread-Index: AQHTb1qlTatFuNGMRU+TW0K/440psqM5cdEg Date: Fri, 8 Dec 2017 13:36:39 +0000 Message-ID: References: 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:90f5:b864:b9ce:de42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR02MB1262; 6:4g/yv2ATysKJ+T8eGrZzagQTe50vhcv7WxbSYqb/jewQvU3Kuv1KeJbwWVbMLAXj5YCwDPxqqeIXfPi0rkRZX6t21biq3mkKh7jibyEt0mNnT4hnoj7dn0Un4MyWzptR9PGdClE2YqOiM4KKv20cYI/+LnX3oD4RCeBsZyvQr4f3dmMjp38clOoouIrYnlh6YuGhzRIpAuqjtGIRkdNB/Zvr+McrZgpuAnW900Nc5IbleEHi43seqMe0nQx6J9K+idw2DvkO+i6jgC68Bnm//wPWE8JfUz8GaUO1AUTHpfIMXwYnZz4Bmfej8h/PyxXfVqmR5qoq6ARQIHxaMXmj7ovLmO1lXGjl1y4Xhj6tV7o=; 5:V8rJab5sYQTPUC9intul4oxaBTSB9u/ersx5WjNN6+YRtH1L0SMC655SMpC4FYsfuTUbs7RbW8uPDeGLxke8KotzHo15Zp7QE6/8leonscUe9aDbRWg8d+D6cqhqq9fIpsmpxKcWc9c+w6AuGnIcyJ/9G76/oC+AMvNocG2/J74=; 24:a0P6NPrZWnu5H/Zg5fsZRgeQztd597Ys9rOMJBGiUdAwhmaQQdb2FuFAyUEGV/Q0A2/mTbTXLx0nAj6fJffnwP1txy5+5IHxXgJ4fx+pvT8=; 7:3Nula2LVI8/cBKZJvBYa2GvSPq+5ytddWfVINm4hho84qMqdPc843mKa8v7OllAhr1EomQJ3Ueqbf5YEV/afg0zbx/4fjEKoOMmYYmi10endAzaNF+5y7YA0J+SSu5pk1XKXLxyirNUJ8Fo+E36b2u4lhTwpmB1razp60A0nix8Lcv+9oeGDo1j2cV3vBAMPjpWHDo9ygnm0wmRSyRnWdY2qBeRmkv76rH7OF61kn+WcP/R25Cge78oNice0CAEB x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8a36e948-5bd4-46fc-1216-08d53e40b65a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:CY1PR02MB1262; x-ms-traffictypediagnostic: CY1PR02MB1262: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(48300812402016)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:CY1PR02MB1262; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR02MB1262; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(199004)(189003)(51914003)(229853002)(9326002)(2950100002)(3280700002)(3660700001)(2906002)(86362001)(6916009)(105586002)(4326008)(97736004)(5660300001)(6436002)(316002)(76176011)(77096006)(8936002)(6506006)(102836003)(6116002)(99286004)(68736007)(790700001)(7696005)(55016002)(33656002)(8676002)(81166006)(81156014)(54896002)(6306002)(9686003)(25786009)(230783001)(53936002)(7736002)(2900100001)(14454004)(6246003)(478600001)(74316002)(106356001)(72206003); 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_CY1PR02MB12629E5937E7294EFA5CFD57E9300CY1PR02MB1262namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8a36e948-5bd4-46fc-1216-08d53e40b65a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 13:36:39.9728 (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] Draft new version: holmberg-sip-push-03 - URI parameters 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, 08 Dec 2017 13:36:45 -0000 --_000_CY1PR02MB12629E5937E7294EFA5CFD57E9300CY1PR02MB1262namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks for the responses, I believe you've addressed everything. Similar to= you, I've stripped out a lot of text here so let me know if I've missed an= ything this time! > I don't think the document shall prevent people from implementing the PNG= as part of the registrar, if that's what they want to do. Vendors and oper= ators need to figure out what works best for them. Agreed that it's fine if vendors wish to do so. I just wanted to highlight = some of the flaws, as I don't think we should mandate it must be on the reg= istrar which could have been the logical conclusion from me raising lots of= concerns related to having the function on a non-registrar! > The mapping table you mention would be an example of such "other mechanis= m", but I don't think that is something we want to standardize. And, there = are also other mechanisms that can be used. > I don't think the document shall prevent people from implementing the PNG= as part of the registrar, if that's what they want to do. Vendors and oper= ators need to figure out what works best for them. Agree that it's good to be as permissive as possible, I was suggesting this= as one of the additional mechanisms. Can I suggest you specifically highli= ght that a non-registrar proxy storing registration details is permissible = in the next draft? With the text as written my understanding was that wasn'= t permissible. > I had a look at this, and in general I have no problem to place the pns p= arameters in a separate URI parameter (pns-param). > However, I don't think we can use syntax for the pns-param. In the= case of Firebase, the value represents the Sender ID, which is not a URL. = I don't even think the value in your apps example above is a valid URL, as = it lacks the scheme :) > So, I suggest to keep pvalue: > pns-param =3D pvalue ;pvalue as defined in RFC 3261 This sounds good and I agree that pns-param shouldn't be restricted to bein= g a URL. I was just using the URL as some example data, as you note that's = not the case for APNs. > The reason the PNS parameters are defined as URI parameters is because th= e registrar will store them, and include them in requests, using standard r= egistrar procedures - we don't need to define new push-specific registrar f= unctionality. That was the behaviour that I expect some SIP Proxys or registrars not to a= dhere to. In practice some implementations of intervening SIP Proxys or reg= istrars may remove parameters they don't support so as not to indicate capa= bilities they don't have or due to simply being a bad implementation. In th= e interests of being permissive, can we not allow the alternative where the= SIP proxy sending the push notifications uses stored information rather th= an URI parameters? This could allow a SIP proxy at the edge of the network = to function correctly despite a misbehaving core network. To clarify, I'm t= hinking of this as an alternative to the mechanism you've suggested, defini= tely not a replacement. Thanks, Mickey --_000_CY1PR02MB12629E5937E7294EFA5CFD57E9300CY1PR02MB1262namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,<= /span>

 =

Thanks for the responses= , I believe you’ve addressed everything. Similar to you, I’ve s= tripped out a lot of text here so let me know if I’ve missed anything this time!

 =

> I don't think the document shall prevent peo= ple from implementing the PNG as part of the registrar, if that's what they= want to do. Vendors and operators need to figure out what works best for t= hem.

 

Agreed that it’s f= ine if vendors wish to do so. I just wanted to highlight some of the flaws,= as I don’t think we should mandate it must be on the registrar which could have been the logical conclusion from me raising lot= s of concerns related to having the function on a non-registrar!=

 =

> The mapping table you mention would be an exam= ple of such "other mechanism", but I don't think that is somethin= g we want to standardize. And, there are also other mechanisms that can be used.

> I don't think the document shall prevent peo= ple from implementing the PNG as part of the registrar, if that's what they= want to do. Vendors and operators need to figure out what works best for t= hem.

 

Agree that it’s go= od to be as permissive as possible, I was suggesting this as one of the add= itional mechanisms. Can I suggest you specifically highlight that a non-registrar proxy storing registration details is permissible in = the next draft? With the text as written my understanding was that wasnR= 17;t permissible.

 

> I had a look at this, and in general I have no = problem to place the pns parameters in a separate URI parameter (pns-param)= .

> However, I don’t think we can use <URL= > syntax for the pns-param.  In the case of Firebase, the value rep= resents the Sender ID, which is not a URL. I don’t even think the val= ue in your apps example above is a valid URL, as it lacks the scheme :)

> So, I suggest to keep pvalue:=

>        pns-param =3D pvalue =    ;pvalue as defined in RFC 3261

 

This sounds good and I agree that pns-param shouldn= ’t be restricted to being a URL. I was just using the URL as some exa= mple data, as you note that’s not the case for APNs.

 

> The reason the PNS parameters are defined as= URI parameters is because the registrar will store them, and include them = in requests, using standard registrar procedures - we don't need to define = new push-specific registrar functionality.

 

That was the behaviour that I expect some SIP Proxy= s or registrars not to adhere to. In practice some implementations of inter= vening SIP Proxys or registrars may remove parameters they don’t support so as not to indicate capabilities they don’= ;t have or due to simply being a bad implementation. In the interests of be= ing permissive, can we not allow the alternative where the SIP proxy sendin= g the push notifications uses stored information rather than URI parameters? This could allow a SIP proxy at the edge of th= e network to function correctly despite a misbehaving core network. To clar= ify, I’m thinking of this as an alternative to the mechanism you̵= 7;ve suggested, definitely not a replacement.

 

Thanks, Mickey

--_000_CY1PR02MB12629E5937E7294EFA5CFD57E9300CY1PR02MB1262namp_-- From nobody Mon Dec 11 05:58: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 728BC126CD8 for ; Mon, 11 Dec 2017 05:58:30 -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 MV4GSpPYh8fi for ; Mon, 11 Dec 2017 05:58:28 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E049120727 for ; Mon, 11 Dec 2017 05:58:28 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id l24so11599494pfj.6 for ; Mon, 11 Dec 2017 05:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=3Df63XL+LwQCr8TnPhGAoCq6N7Zlz9xDgZ1NqkQI8+o=; b=AJ2u40qpTR8d3F/71vqbzzu5E+qXHcDEWaZdT00zr5nVo2uo3+Ol/O7n61w7ePU/oj uSATDLnax/BeKS2PDJrTncGy8ArwapaU39zxnT/aJo2+uGzjRysXDDi9QoRVE8n0K2hi am7cuHDFuDCjEXVBfMPfa04V83cZ7UcJz6ZfG6pKrh3mYbvGT3kECgqZgpqTgg2K5SNQ rvKNq8kng67TgIbqIKUcCNLoXFJMwwZdRXf1HT0Cda7MhoEes5AN/XVU/XcsoCpB6JMP rHqHzDtsqomO9BeHO3WZGDvgDi4cmqBPii9x9IO4XlLOBX4rRnAAK5iKnoSFeDpfd+R7 8e/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=3Df63XL+LwQCr8TnPhGAoCq6N7Zlz9xDgZ1NqkQI8+o=; b=hR7INwo5EseegannZUa7hNcud9Ps7fcY/JVHM55h9bZYqVgqHnCWVmO++bjkN5XF8J uC1K8W22tCSnSQLaii4oeAySsqCRMZW6QnAz5fTadiQiH8peaCHjOUKKEO3Ez+89qntJ e3R2+lt2nGD2UTWr3XIEYfHZYGnHvtv6KYU8bVkG5fYxXPZXZWyWh63AbmOF9MmGArjW 8LJ1fvkLg/woWrTkXP6yTUhWvODZsq3jANvLGCMnhpURLt86KzqE3zdsh/cOxxpz70Ew HeS+/phc6gIHnpX4GRVv8m0LWEagzQBVTOBnM4s/HCtpDG0D9h0usec/ECRkSBRXkCSj FBzw== X-Gm-Message-State: AKGB3mIg5f8wUQ5p6ox76dp66tARQzu3hszhigp6G85i2mXhp88/Sof4 gE4U1YxLPGgC5gkLvML/k5dY78DH X-Google-Smtp-Source: ACJfBouDhUxTE385ooVlzW940usLL5QemchqmKvtR5GtqhDvVs7Lt73nGP9/9LWpmQfNZ3yOS2MmeQ== X-Received: by 10.84.216.26 with SMTP id m26mr453653pli.432.1513000707724; Mon, 11 Dec 2017 05:58:27 -0800 (PST) Received: from [192.168.128.64] (61.245.63.46.er.eaccess.ne.jp. [61.245.63.46]) by smtp.gmail.com with ESMTPSA id b20sm25171072pgn.91.2017.12.11.05.58.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 05:58:27 -0800 (PST) From: OKUMURA Shinji References: <7594FB04B1934943A5C02806D1A2204B6C02989E@ESESSMB109.ericsson.se> <375782e0-a840-d4ae-0ffa-89a5dccc480b@alum.mit.edu> To: sipcore@ietf.org Message-ID: Date: Mon, 11 Dec 2017 22:58:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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-Transfer-Encoding: 7bit Content-Language: en-US X-Antivirus: Avast (VPS 171210-2, 2017/12/10), Outbound message X-Antivirus-Status: Clean 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, 11 Dec 2017 13:58:30 -0000 Hi, Roman > 1. Define conditions when S-E state is dangerously ambiguous and recommend for UA to send an UPDATE to clarify the S-E state During a successful INVITE transaction(between INVITE and ACK), when UA sends or receives UPDATE and the transaction has succeeded as a result, if interval or refresher are semantically different from those of 200 response for the INVITE, According to the Session-Expires header in 200 response for the INVITE, refresher(?) is recommended to send an UPDATE immediately(or within 10-30 seconds?). After waiting 30(?) seconds for the session refresh request, if non-refresher has not received that, it is recommended to send an UPDATE immediately. > 2. Define recommended rules for UA and Proxies to avoid ambiguous situations My suggestion: Additional rules allow proxies to add or increase Min-SE header in a request. Additional rules allow uas to add Min-SE header in 200 response. UA should not change semantically the interval or refresher of Session-Expires header in a request and 200 response. Regards, Shinji On 2017/11/30 3:38, Roman Shpount wrote: > 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 situations > > 1 should be sufficient to provide resilient implementations. 2 should help > to avoid the extra UPDATE. From nobody Wed Dec 13 06:24: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 0D0C2126D3F for ; Wed, 13 Dec 2017 06:24:48 -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 UpzmNVsEdeq6 for ; Wed, 13 Dec 2017 06:24:46 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 58EAE126BF6 for ; Wed, 13 Dec 2017 06:24:45 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id u184so2122896qkd.6 for ; Wed, 13 Dec 2017 06:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xMqr87E96aKW+2w8JY+ZkHcWhmF4M+qp93AgD6fkjpk=; b=DlhwpJIIz8Hp+nvzx9h90ftSC/xCMhmcMLGGKniwpwadEgqXjoVJjK4gu38eXuLmD6 kmbhVewfU6siEg4BIcncieHak3vBBF5QTHdVTwe1aPclPR8jspGd7lfzXh3O7VTBux/d 3D0q0Jc+WdqQeOQ/arJ1iVwl/7ZLIVLsdE63GPdsBahNhhqpNPsugyZFJAbXxkV13SRF LIsVhsKmDjMLDNmmCahEbIrL4vs9vwsSuRc2QOk58UYIgD8sIbzJc09Ajxj2nxl1v/tW vCLRkSjfVdrC0PGwIlTLkPfGVe90Ek8uEraWAjhmtRonpOupk02rF+YDvmeIQixBAIqX qNTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xMqr87E96aKW+2w8JY+ZkHcWhmF4M+qp93AgD6fkjpk=; b=Kzn8kuC6jHDTtPnVDT8yYyHITtgsMZREMCI8+WlI2SuTcyc5TduGnYItqRJTR0ZIyO vhzkSSVx73eFNg/sKsp2198UhBUBZrjp+vn6TXHsrTYqs4hcmrFoxvP+QhcQJBHQjpF3 Gc3zF8vwrEVT2qT9ngpX5vIOcKm72cL09lQAFtQrgB8HaI7WKjcLclilvFDTDgs2n6ms ZV3i0rO5XBh5bV7l+bp7CVY6+QJJnG2NeMWHSLG/YPDzTZBAk6pibht5rneHchqKFj3Y 08L/YDWZVO6KQ+AZmxx3EbRknkvM2zlKsg0fo1fYMzEgCi/5pAolC2lvG3oBNCmKJiHH IdqA== X-Gm-Message-State: AKGB3mKInCwbsLHazMH+ivVM17s4lrTtalpf7B3MIk48w5PTWfCRZpjK tbFigCGVp50IGGCiJMokbEVGTQ== X-Google-Smtp-Source: ACJfBouua1/Ic2edjADNTcLRuaO0PigUSZuDAF+aaxcnSFB0/L0OJW+vgFpRdYMBuYYS7Nkkzd9T/g== X-Received: by 10.55.82.84 with SMTP id g81mr10918753qkb.263.1513175084401; Wed, 13 Dec 2017 06:24:44 -0800 (PST) Received: from [10.33.192.11] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id r22sm1101800qtc.71.2017.12.13.06.24.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 06:24:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C031C89@ESESSMB109.ericsson.se> Date: Wed, 13 Dec 2017 09:24:41 -0500 Cc: Ranjit Avasarala , SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: <7CBC6ABF-21E1-4DF8-B158-B910038C89CA@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B6C031C89@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3273) 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, 13 Dec 2017 14:24:48 -0000 We have had quite a few responses in favor of adopting this draft and no = opposition. We will request a milestone for this draft. Christer, = please submit a draft-ietf-sipcore-.. Brian > On Nov 30, 2017, at 12:49 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 >> I have one comment on the draft >>=20 >> In section 3, Push Resource ID (PRID), the sentence should be = modified to - When an entity registers with a=20 >> Push Notification Server (PNS), it (instead of is) receives a unique = Push Resource ID (PRID) , which is a value=20 >> associated with the registration=20 >=20 > I will fix that in the next version. >=20 > Thanks! >=20 > Regards, >=20 > Christer >=20 >=20 > 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 >=20 From nobody Wed Dec 13 06:55: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 EA02C127241 for ; Wed, 13 Dec 2017 06:55:39 -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 bRrU6nn7jv9l for ; Wed, 13 Dec 2017 06:55:37 -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 575C9120227 for ; Wed, 13 Dec 2017 06:55:37 -0800 (PST) X-AuditID: c1b4fb2d-d6fff700000036aa-b4-5a313f67edd9 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7F.BC.13994.76F313A5; Wed, 13 Dec 2017 15:55:35 +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; Wed, 13 Dec 2017 15:55:35 +0100 From: Christer Holmberg To: Brian Rosen CC: Ranjit Avasarala , SIPCORE Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sip-push Thread-Index: AQHTaRlSj083iGbuAUSRkgieoJz4pqMtEJWAgAAjcVCAFCU+gIAALMEA Date: Wed, 13 Dec 2017 14:55:34 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C031C89@ESESSMB109.ericsson.se> <7CBC6ABF-21E1-4DF8-B158-B910038C89CA@brianrosen.net> In-Reply-To: <7CBC6ABF-21E1-4DF8-B158-B910038C89CA@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <71368813082DB24CBC1ADF43F8D7F862@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7tG66vWGUwdk92hZP709js9jV38tq 8fXHJjYHZo/73/6ye+ycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGR1/fzMWHOOtOLtiDXsD YwN3FyMnh4SAicTbCx/Yuhi5OIQEDjNKdOx8zwLhLGGU+L2mlbmLkYODTcBCovufNkiDiICy xM5bnewgNrOAl8TGtv9MILawgIfEicWdzBA1nhJ7L35kgrDdJPou3mYFGcMioCrx5aI1SJhX wFpi2pLfTBCrWpgkzjXPB5vJKeAksf3HY0YQm1FATOL7qTVMELvEJW49mc8EcbSAxJI955kh bFGJl4//sYLYogJ6EhtO3GaHiCtJ/NhwiQWiV0/ixtQpbBC2tcT81s2MELa2xLKFr5khDhKU ODnzCcsERvFZSNbNQtI+C0n7LCTts5C0L2BkXcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokR GIMHt/zW3cG4+rXjIUYBDkYlHt5fRoZRQqyJZcWVuYcYJTiYlUR4ZVmAQrwpiZVVqUX58UWl OanFhxilOViUxHlPevJGCQmkJ5akZqemFqQWwWSZODilGhit3DULnb6/OaNV1t0ZcX3BHLZW xs9Lcjtd38dtfS250uqZ1h0Ro0BzyzuWz2fEJWw/fXkiv77TPUk7E4vIs3rOcYtUjtwyzG/Z uvXSk5I/D9Z9WZes6rWRX+ExY//5psTt7b6ntS3s1L/yNW9KC3zPa5Pg4fr855acuzwOXy+v 3bjl5ceDMsVKLMUZiYZazEXFiQBIaTiUvQIAAA== 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, 13 Dec 2017 14:55:40 -0000 Thank You! I have submitted the -00 version of draft-ietf-sipcore-sip-push (the chairs need to approve the submission, but after that it should become available). The only changes from the previous (individual) version is the editorial nit found by Ranjit, and I=B9ve updated the webpush-encryption reference from draft-webpush-encryption to RFC 8291. I will create a pull request for the changes requested by Mickey (and others), and if approved they will be implemented in the -01 version of the document. Regards, Christer On 13/12/17 16:24, "Brian Rosen" wrote: >We have had quite a few responses in favor of adopting this draft and no >opposition. We will request a milestone for this draft. Christer, >please submit a draft-ietf-sipcore-.. > >Brian > >> On Nov 30, 2017, at 12:49 PM, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >>> I have one comment on the draft >>>=20 >>> 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 unique >>>Push Resource ID (PRID) , which is a value >>> associated with the registration >>=20 >> I will fix that in the next version. >>=20 >> Thanks! >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> 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 >>=20 > From nobody Wed Dec 13 07:10:15 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A7E127869; Wed, 13 Dec 2017 07:10:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151317780986.30085.18037736526217866881@ietfa.amsl.com> Date: Wed, 13 Dec 2017 07:10:09 -0800 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 15:10:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Push Notification with the Session Initiation Protocol (SIP) Author : Christer Holmberg Filename : draft-ietf-sipcore-sip-push-00.txt Pages : 12 Date : 2017-12-13 Abstract: This document describes how push notification mechanisms can be used to wake up suspended Session Initiation Protocol (SIP) User Agents (UAs), in order to be able to receive and generate SIP requests. The document defines new SIP URI parameters, that can be used in a SIP REGISTER request to provide push notification information from the SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in this document) that will send a push request to the push server in order to trigger a push notification towards the SIP UA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-00 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 13 23: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 41A12124D37 for ; Wed, 13 Dec 2017 23:38:51 -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 x-gUitmdztmm for ; Wed, 13 Dec 2017 23:38:49 -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 1652C1200CF for ; Wed, 13 Dec 2017 23:38:48 -0800 (PST) X-AuditID: c1b4fb25-859119c00000341b-ae-5a322a86fdee Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CC.D2.13339.68A223A5; Thu, 14 Dec 2017 08:38:46 +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; Thu, 14 Dec 2017 08:38:45 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: SIP Push: Pull request for upcoming version -01 Thread-Index: AQHTdK6StaXj3QVMl0y095492+eCWg== Date: Thu, 14 Dec 2017 07:38:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D657F95627B5Echristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7tG6bllGUwfOT8hZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtIpf1kKvshWfDrxj62BcbNUFyMnh4SAiUTXnF5mEFtI4DCj xOr5Fl2MXED2EkaJG633mLoYOTjYBCwkuv9pg9SICGhKLP+2lR0kLAwU7r3sDGKKCNhK/N8Y BWHqSaw9XgRSzCKgKrFo/w42EJtXwFri86lJjCA2o4CYxPdTa5hAbGYBcYlbT+YzQRwjILFk z3lmCFtU4uXjf6wgtijQyA0nbrNDxJUkfmy4xALRmyDxY9cLJoj5ghInZz5hmcAoNAvJ2FlI ymYhKYOIG0i8PzefGcLWlli28DWUrS+x8ctZRgjbWuLBnEusyGoWMHKsYhQtTi1Oyk03MtZL LcpMLi7Oz9PLSy3ZxAiMkYNbfqvuYLz8xvEQowAHoxIPb4G0UZQQa2JZcWXuIUYJDmYlEV61 iYZRQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5akZqemFqQWwWSZODilGhhVMs79 zQ9SEpB9d09tFsvacgkGz3fzrN6mPZ2p9OX0+7C1Zl+9Xx/+FvNOS0NLLdlQ1j+jTk7phP1T CavXN2Y22OVseiVy50uzvWuxQrpuA0f23Kg6v+iOQpujYcbGzrsX5QZPuh2x4u/xOB7TbS7H Cm4k3Ml22hb0RNjuwQYmTQcjlRxTByWW4oxEQy3mouJEAKX+FrSNAgAA Archived-At: Subject: [sipcore] SIP Push: Pull request for upcoming version -01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 07:38:51 -0000 --_000_D657F95627B5Echristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments from Mickey, I have created a pull request for SIP pu= sh. The main technical changes are: * pn-type URI parameter split into separate pn-provider and pn-param UR= I parameters. * Clarifying that a proxy rejects (or redirects) a REGISTER with a PNS = it doesn=92t support In addition I=92ve done some editorial clarifications. https://github.com/cdh4u/draft-sip-push/pull/4 Regards, Christer --_000_D657F95627B5Echristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the comments from Mickey, I have created a p= ull request for SIP push.

 

The main technical changes are:

 

  • pn-type URI parameter split into separate pn-provider = and pn-param URI parameters.
  • Clarifying that a proxy rejects (or redirects) a REGIS= TER with a PNS it doesn=92t support

 

In addition I=92ve done some editorial clarifications= .

 

https://github.com/cdh4u/draft-si= p-push/pull/4

 

Regards,

 

Christer

--_000_D657F95627B5Echristerholmbergericssoncom_-- From nobody Wed Dec 13 23:57: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 04A92126E64 for ; Wed, 13 Dec 2017 23:57:26 -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 4yBt6-sGzWtc for ; Wed, 13 Dec 2017 23:57:24 -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 F322C1200CF for ; Wed, 13 Dec 2017 23:57:23 -0800 (PST) X-AuditID: c1b4fb3a-90dff7000000028c-54-5a322ee11493 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BD.DD.00652.1EE223A5; Thu, 14 Dec 2017 08:57:21 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Thu, 14 Dec 2017 08:57:21 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: SIP Push: PNS-specific SIP response code? Thread-Index: AQHTdLErsERfCgaO8UmFU8mX7KL7pg== Date: Thu, 14 Dec 2017 07:57:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D657FDB127B88christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7qO5DPaMog78PzCy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEmn7rIULOOvmLntOEsD43eeLkZODgkBE4mFn3pYuxi5OIQE DjNKXPm/jg3CWcIosWTzYSCHg4NNwEKi+582SIOIgKbE8m9b2UFsYQEjib0LZjFBxM0llrbf Z4Ww9ST+dmwCi7MIqEos2v2FDcTmFbCWeDXvNlgvo4CYxPdTa8BqmAXEJW49mc8EcZCAxJI9 55khbFGJl4//gc0UBZq54QREr4SAksSPDZdYIHoTJO4c+gs1X1Di5MwnLBMYhWYhGTsLSdks JGUQcR2JBbs/sUHY2hLLFr5mhrHPHHgM1Wst8W7DRRQ1Cxg5VjGKFqcWF+emGxnppRZlJhcX 5+fp5aWWbGIExsrBLb+tdjAefO54iFGAg1GJhzdG2ihKiDWxrLgy9xCjBAezkgiv2kTDKCHe lMTKqtSi/Pii0pzU4kOM0hwsSuK8Jz15o4QE0hNLUrNTUwtSi2CyTBycUg2MfaqH2Gc/szHi 97bV++hk3ytkdW6z0rX2IradHu82WptMEt6lI3fll+4Sx4hba5pDpWafOW+pkei1e/ehkgt1 XpK/jqxhyFhk3uBafX1brFDchfjlD8TTtPmNrCrDo7Z9T/jZt4wzJOtigf67OUb14Zlzfj9+ O3dvyta/x9/PkvXhFOJqnPNLiaU4I9FQi7moOBEAJLIA2ZECAAA= Archived-At: Subject: [sipcore] SIP Push: PNS-specific SIP response code? 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, 14 Dec 2017 07:57:26 -0000 --_000_D657FDB127B88christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It is currently suggested (see pull request in other e-mail) that a proxy t= hat receives a SIP REGISTER request with pn- parameters for a PNS provider = it does not support sends a 501 (Not Implemented) response code. The question is whether it would be useful to define a PNS-specific respons= e code for this? E.g., 514 (Push Notification Service Not Supported). In ad= dition, we could define a feature capability indicator that could be added = to the response and list the PNS providers supported by the proxy. Regards, Christer --_000_D657FDB127B88christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

It is currently suggested (see pull request in other e-mail) that a pr= oxy that receives a SIP REGISTER request with pn- parameters for a PNS prov= ider it does not support sends a 501 (Not Implemented) response code. =

The question is whether it would be useful to define a PNS-specific re= sponse code for this? E.g., 514 (Push Notification Service Not Supported). = In addition, we could define a feature capability indicator that could be a= dded to the response and list the PNS providers supported by the proxy.

Regards,

Christer
--_000_D657FDB127B88christerholmbergericssoncom_-- From nobody Thu Dec 14 03:35: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 F2D27128B51 for ; Thu, 14 Dec 2017 03:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 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, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WutIFACH8jBO for ; Thu, 14 Dec 2017 03:34:58 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE23128B37 for ; Thu, 14 Dec 2017 03:34:58 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id PRmoe4z9oiILVPRmze6OPq; Thu, 14 Dec 2017 11:34:57 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-08v.sys.comcast.net with SMTP id PRmyeoopjCr36PRmyeswfb; Thu, 14 Dec 2017 11:34:57 +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 vBEBYtAM015687; Thu, 14 Dec 2017 06:34:55 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vBEBYsmJ015684; Thu, 14 Dec 2017 06:34:54 -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: Christer Holmberg Cc: sipcore@ietf.org In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 14 Dec 2017 06:34:54 -0500 Message-ID: <87r2rxy23l.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHp7NyQXm3M6launOiIS/gOeelCyE4kC3GZlw242m/ngu3oD5Rii9FQ7b2q85gtIPYiwgbdOdsjmmdhCjyXZVbg/LhYOIR39+yBhOHAHYQYz6gpdFb7j ZiCs4nb3lk68SXQrCD72Lfw8A9XylGzgYwApaRBLXPUbfBLNOe3fM71p9QfKM3IK38YU0nrWERu0gPHgPh9gIfuM02lHBgc3ofU= Archived-At: Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? 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, 14 Dec 2017 11:35:00 -0000 Christer Holmberg writes: > It is currently suggested (see pull request in other e-mail) that a > proxy that receives a SIP REGISTER request with pn- parameters for a > PNS provider it does not support sends a 501 (Not Implemented) > response code. I took a quick look at the draft, and I might have missed it, but how does the UA verify that the registrar (the UAS receiving its REGISTER request) supports the push notifications that it expects? Or rather, how does it register so that the response tells it whether this proxy/registrar implements push in one or another way vs. whether it's an ordinary proxy registrar? These upward-compatibility procedures need to be laid out carefully. Also, as a general design question, it seems to me that these pn- parameters would do better as header parameters than URI parameters. E.g.: REGISTER sip:alice@example.com SIP/2.0 ... Contact: ; pn-type=acme:acme-param; pn-prid="ZTY4ZDJlMzODE1NmUgKi0K" Because the pn- parameters are more *properties of* the contact that is being registered than intrinsic *parts of* the contact. There's also this oddity in the text: When a SIP UA registers to a push service, it will receive a unique Push Resource ID (PRID) associated to that registration. The SIP UA will provide the PRID to the SIP network in a SIP REGISTER request. A SIP proxy (e.g., the SIP registrar) will store a mapping between the registered contact and the PRID. The first sentence suggests that the PRID is assigned by the registrar and supplied in the REGISTER response, whereas the second sentence suggests the PRID is presumably assigned by the UA and supplied in the REGISTER *request*. Do you mean "The SIP UA will provide the PRID to the SIP network in the subsequent SIP REGISTER requests of the same registration pseudo-dialog."? Dale From nobody Thu Dec 14 03:42:15 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880B8128B91 for ; Thu, 14 Dec 2017 03:42:14 -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 fpaUTz7ssFmr for ; Thu, 14 Dec 2017 03:42:12 -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 1C9CB128B37 for ; Thu, 14 Dec 2017 03:42:11 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-fc-5a3263911f4c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BB.FC.27591.193623A5; Thu, 14 Dec 2017 12:42:10 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Thu, 14 Dec 2017 12:42:09 +0100 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Push: PNS-specific SIP response code? Thread-Index: AQHTdLErsERfCgaO8UmFU8mX7KL7pqNCpPkAgAAmKYA= Date: Thu, 14 Dec 2017 11:42:08 +0000 Message-ID: References: <87r2rxy23l.fsf@hobgoblin.ariadne.com> In-Reply-To: <87r2rxy23l.fsf@hobgoblin.ariadne.com> 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="us-ascii" Content-ID: <3D6DC4CF3BACC14D80488D083C726742@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7lO6kZKMog113OC2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlTHn5if2gt+CFQdmdbA0MK7i62Lk5JAQMJFY e/AlWxcjF4eQwGFGiUufNjOCJIQEljBKTN2j0cXIwcEmYCHR/U8bxBQR0JToWJADUsEMZD7a uZcJxBYWcJBY0nOCBcQWEXCUOHv6HRuEbSVx/8QLVpBWFgFViRPL1UDCvALWEpf2LmSHWJQi 8ebOMbBWTgFjicbt68AOYBQQk/h+ag0TxCpxiVtP5jNBXCwgsWTPeWYIW1Ti5eN/rCC2qICe xIYTt9kh4ooSV6cvh+rVkViw+xMbhG0tcWj9TyhbW2LZwtfMEPcISpyc+YRlAqP4LCTrZiFp n4WkfRaS9llI2hcwsq5iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIyzg1t+G+xgfPnc8RCj AAejEg+vk6VRlBBrYllxZe4hRgkOZiUR3tZooBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568 UUIC6YklqdmpqQWpRTBZJg5OqQbGyUHT2o6tMH9w5YHBr2O/tt13qJ3063C2YL+NQkPzpue/ dzvYvN3WN4HjwL3aHLaSDl414VnK3YseBSt2/1g5904IzxWDqyutVA+4PlnvcfTonX1+6w1d NVxXrL1bMrl4Y46cXz3Lt42bruxU3/qUR202A4eu7lT228WRBybNzLBjbLhjUKzTqsRSnJFo qMVcVJwIAFRHZtSvAgAA Archived-At: Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? 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, 14 Dec 2017 11:42:14 -0000 Hi Dale, >>It is currently suggested (see pull request in other e-mail) that a >> proxy that receives a SIP REGISTER request with pn- parameters for a >> PNS provider it does not support sends a 501 (Not Implemented) >> response code. > >I took a quick look at the draft, and I might have missed it, but how >does the UA verify that the registrar (the UAS receiving its REGISTER >request) supports the push notifications that it expects? Or rather, >how does it register so that the response tells it whether this >proxy/registrar implements push in one or another way vs. whether it's >an ordinary proxy registrar? These upward-compatibility procedures need >to be laid out carefully. We could use a feature capability tag for that. >Also, as a general design question, it seems to me that these pn- >parameters would do better as header parameters than URI parameters. >E.g.: > > REGISTER sip:alice@example.com SIP/2.0 > ... > Contact: ; > pn-type=3Dacme:acme-param; > pn-prid=3D"ZTY4ZDJlMzODE1NmUgKi0K" > >Because the pn- parameters are more *properties of* the contact that is >being registered than intrinsic *parts of* the contact. The reason they are defined as URI parameters is because the SIP registrar will add them to the SIP INVITE/MESSAGE request using normal registrar procedures.=20 >There's also this oddity in the text: > > When a SIP UA registers to a push service, it will receive a unique > Push Resource ID (PRID) associated to that registration. The SIP UA > will provide the PRID to the SIP network in a SIP REGISTER request. > A SIP proxy (e.g., the SIP registrar) will store a mapping between > the registered contact and the PRID. > >The first sentence suggests that the PRID is assigned by the registrar >and supplied in the REGISTER response, whereas the second sentence >suggests the PRID is presumably assigned by the UA and supplied in the >REGISTER *request*. Do you mean "The SIP UA will provide the PRID to >the SIP network in the subsequent SIP REGISTER requests of the same >registration pseudo-dialog."? The SIP UA registers to the push service using a non-SIP protocol. Perhaps that could be more clear. Regards, Christer From nobody Thu Dec 14 07:35:37 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11FE124319 for ; Thu, 14 Dec 2017 07:35:35 -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 lxTPJkhSpKzu for ; Thu, 14 Dec 2017 07:35: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 6A462120227 for ; Thu, 14 Dec 2017 07:35:33 -0800 (PST) X-AuditID: 1207440c-7fdff7000000143e-29-5a329a410ee1 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 2C.DC.05182.14A923A5; Thu, 14 Dec 2017 10:35:30 -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 vBEFZS54004430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 14 Dec 2017 10:35:28 -0500 To: sipcore@ietf.org References: <87r2rxy23l.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <2c80e804-426f-97de-276b-fb31384cddeb@alum.mit.edu> Date: Thu, 14 Dec 2017 10:35:28 -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+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqOs0yyjKYM4jHYuvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+VJ1YJ5khXnNx1lbGBsEeli5OSQEDCR+Pf2M0sXIxeHkMAO JonlHbehnB9MEp929jGDVAkLOEgs6TnBAmKLCIhIPJv+jw2iaBqjxN6uXrAEm4CWxJxD/8Fs XgF7iZk3XgI1c3CwCKhKPHhhARIWFUiT2HOhA6pEUOLkzCdgNqeAjcSlu5MZQWxmATOJeZsf MkPY4hK3nsxngrDlJba/ncM8gZF/FpL2WUhaZiFpmYWkZQEjyypGucSc0lzd3MTMnOLUZN3i 5MS8vNQiXUO93MwSvdSU0k2MkKDk2cH4bZ3MIUYBDkYlHl6LNqMoIdbEsuLK3EOMkhxMSqK8 x3uAQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4r7QC5XhTEiurUovyYVLSHCxK4ryqS9T9hATS E0tSs1NTC1KLYLIyHBxKErzXZgA1ChalpqdWpGXmlCCkmTg4QYbzAA1fB1LDW1yQmFucmQ6R P8VozNHTc+MPE8ezma8bmIVY8vLzUqXEeS+BlAqAlGaU5sFNgyWWV4ziQM8J86bNBKriASYl uHmvgFYxAa163qIPsqokESEl1cBo+Mu/6r/Ou5b6taXaXZzTw9f2sdSr8k+Uzy33cArhOn6u ZqLd+f+HPH0fFFgxinjMtCoLebtg612hnXw32neczMnoiprSJsFVc57fo/JegiNP7R2r+ZXH ZiS7Gfbu7s/YwXNxxcbjcvkuOvFxe35Z7Ww6WJkRKNNg7vFZlvmndG3j37bf+UosxRmJhlrM RcWJAE6Kmi8HAwAA Archived-At: Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? 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, 14 Dec 2017 15:35:36 -0000 On 12/14/17 6:42 AM, Christer Holmberg wrote: > Hi Dale, > >>> It is currently suggested (see pull request in other e-mail) that a >>> proxy that receives a SIP REGISTER request with pn- parameters for a >>> PNS provider it does not support sends a 501 (Not Implemented) >>> response code. >> >> I took a quick look at the draft, and I might have missed it, but how >> does the UA verify that the registrar (the UAS receiving its REGISTER >> request) supports the push notifications that it expects? Or rather, >> how does it register so that the response tells it whether this >> proxy/registrar implements push in one or another way vs. whether it's >> an ordinary proxy registrar? These upward-compatibility procedures need >> to be laid out carefully. > > We could use a feature capability tag for that. IMO the sip options mechanism is appropriate here. The UA would include a Require:push in the REGISTER, and the registrar, if it supports push, will include Supported:push in the response. It gets a bit more subtle regarding the particular push mechanism. Suppose that the registrar supports the push mechanism for some PNS providers but not the requested one. There is a temptation to indicate this by returning Unsupported:push. But this would be a distortion. It is probably better to find a different way to indicate this. Using some error code, and perhaps also a Reason code, is a possibility. Thanks, Paul >> Also, as a general design question, it seems to me that these pn- >> parameters would do better as header parameters than URI parameters. >> E.g.: >> >> REGISTER sip:alice@example.com SIP/2.0 >> ... >> Contact: ; >> pn-type=acme:acme-param; >> pn-prid="ZTY4ZDJlMzODE1NmUgKi0K" >> >> Because the pn- parameters are more *properties of* the contact that is >> being registered than intrinsic *parts of* the contact. > > The reason they are defined as URI parameters is because the SIP registrar > will add them to the SIP INVITE/MESSAGE request using normal registrar > procedures. > >> There's also this oddity in the text: >> >> When a SIP UA registers to a push service, it will receive a unique >> Push Resource ID (PRID) associated to that registration. The SIP UA >> will provide the PRID to the SIP network in a SIP REGISTER request. >> A SIP proxy (e.g., the SIP registrar) will store a mapping between >> the registered contact and the PRID. >> >> The first sentence suggests that the PRID is assigned by the registrar >> and supplied in the REGISTER response, whereas the second sentence >> suggests the PRID is presumably assigned by the UA and supplied in the >> REGISTER *request*. Do you mean "The SIP UA will provide the PRID to >> the SIP network in the subsequent SIP REGISTER requests of the same >> registration pseudo-dialog."? > > The SIP UA registers to the push service using a non-SIP protocol. Perhaps > that could be more clear. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Dec 14 11: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 341BE12714F for ; Thu, 14 Dec 2017 11:27:36 -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 RWSk3J6seGXX for ; Thu, 14 Dec 2017 11:27:33 -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 ED326124D6C for ; Thu, 14 Dec 2017 11:27:32 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-f9-5a32d0a2d67a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.E5.13339.2A0D23A5; Thu, 14 Dec 2017 20:27:30 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Thu, 14 Dec 2017 20:27:30 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Push: PNS-specific SIP response code? Thread-Index: AQHTdLErsERfCgaO8UmFU8mX7KL7pqNCpPkAgAAmKYCAAB0NAIAAUDSA Date: Thu, 14 Dec 2017 19:27:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C05725B@ESESSMB109.ericsson.se> References: <87r2rxy23l.fsf@hobgoblin.ariadne.com> <2c80e804-426f-97de-276b-fb31384cddeb@alum.mit.edu> In-Reply-To: <2c80e804-426f-97de-276b-fb31384cddeb@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7ge6iC0ZRBk+/W1us2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGnh2bmQoWylQ8X7KPuYHxjlgXIyeHhICJ xLojH5i7GLk4hAQOM0q0d35lgXCWMErMbFzB3sXIwcEmYCHR/U8bpEFEIFDi6pIJzCC2sICD xOmDu9gg4o4SZ0+/g7LdJKavPs8OYrMIqEp8/LuNBcTmFfCVWLB7AVhcSOAMo0THdxkQmxNo zt7Wd4wgNqOAmMT3U2uYQGxmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELaSxKLbn6HqdYDm f2KDsLUlli18zQyxV1Di5MwnLBMYRWYhGTsLScssJC2zkLQsYGRZxShanFqclJtuZKyXWpSZ XFycn6eXl1qyiREYDwe3/FbdwXj5jeMhRgEORiUe3jU7jKKEWBPLiitzDzFKcDArifBeaQUK 8aYkVlalFuXHF5XmpBYfYpTmYFES5z3pyRslJJCeWJKanZpakFoEk2Xi4JRqYPRaplj38UfJ e72UV8G188PYBTc8EMt79mNrnbL9nu8qF8Lrju8+G+UUtXW5W9ccIdut00MsfLh+SptE/XF9 ZPNx78VNry00N3Xbf1g4abFWbsOX28yqBwsXOiZUTxH5cWjiw4akg3y8rzfLv3hwxSXk2lnm IL39V8/OigoUn+754HYWx6qlrx4qsRRnJBpqMRcVJwIAFCHd24MCAAA= Archived-At: Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? 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, 14 Dec 2017 19:27:36 -0000 Hi, >>>> It is currently suggested (see pull request in other e-mail) that a=20 >>>> proxy that receives a SIP REGISTER request with pn- parameters for a=20 >>>> PNS provider it does not support sends a 501 (Not Implemented)=20 >>>> response code. >>> >>> I took a quick look at the draft, and I might have missed it, but how=20 >>> does the UA verify that the registrar (the UAS receiving its REGISTER >>> request) supports the push notifications that it expects? Or rather,=20 >>> how does it register so that the response tells it whether this=20 >>> proxy/registrar implements push in one or another way vs. whether=20 >>> it's an ordinary proxy registrar? These upward-compatibility=20 >>> procedures need to be laid out carefully. >>=20 >> We could use a feature capability tag for that. > > IMO the sip options mechanism is appropriate here. The UA would include a= Require:push in=20 > the REGISTER, and the registrar, if it supports push, will include Suppor= ted:push in the response. The push functionality may not necessarily be supported by the registrar - = it may be handled by an intermediary SIP proxy. >It gets a bit more subtle regarding the particular push mechanism. >Suppose that the registrar supports the push mechanism for some PNS provid= ers but not the requested one. There is a temptation to indicate this by re= turning >Unsupported:push. But this would be a distortion. It is probably b= etter to find a different way to indicate this. Using some error code, and = perhaps also a Reason code, is a >possibility. I think a new error code would be justified for this. Regards, Christer >> Also, as a general design question, it seems to me that these pn-=20 >> parameters would do better as header parameters than URI parameters. >> E.g.: >> >> REGISTER sip:alice@example.com SIP/2.0 >> ... >> Contact: ; >> pn-type=3Dacme:acme-param; >> pn-prid=3D"ZTY4ZDJlMzODE1NmUgKi0K" >> >> Because the pn- parameters are more *properties of* the contact that=20 >> is being registered than intrinsic *parts of* the contact. >=20 > The reason they are defined as URI parameters is because the SIP=20 > registrar will add them to the SIP INVITE/MESSAGE request using normal=20 > registrar procedures. >=20 >> There's also this oddity in the text: >> >> When a SIP UA registers to a push service, it will receive a unique >> Push Resource ID (PRID) associated to that registration. The SIP UA >> will provide the PRID to the SIP network in a SIP REGISTER request. >> A SIP proxy (e.g., the SIP registrar) will store a mapping between >> the registered contact and the PRID. >> >> The first sentence suggests that the PRID is assigned by the=20 >> registrar and supplied in the REGISTER response, whereas the second=20 >> sentence suggests the PRID is presumably assigned by the UA and=20 >> supplied in the REGISTER *request*. Do you mean "The SIP UA will=20 >> provide the PRID to the SIP network in the subsequent SIP REGISTER=20 >> requests of the same registration pseudo-dialog."? >=20 > The SIP UA registers to the push service using a non-SIP protocol.=20 > Perhaps that could be more clear. >=20 > Regards, >=20 > Christer >=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 Thu Dec 14 13:54: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 2AD25127599 for ; Thu, 14 Dec 2017 13:54:44 -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 bciX60WnjMmo for ; Thu, 14 Dec 2017 13:54:42 -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 E2CDB1243F3 for ; Thu, 14 Dec 2017 13:54:41 -0800 (PST) X-AuditID: 12074414-0d3ff70000006ddf-17-5a32f320e01a 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 6E.6E.28127.023F23A5; Thu, 14 Dec 2017 16:54: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 vBELsdiR026825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Dec 2017 16:54:40 -0500 To: Christer Holmberg , "sipcore@ietf.org" References: <87r2rxy23l.fsf@hobgoblin.ariadne.com> <2c80e804-426f-97de-276b-fb31384cddeb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B6C05725B@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <9d127d65-0679-df12-d463-66abaed16fda@alum.mit.edu> Date: Thu, 14 Dec 2017 16:54:39 -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: <7594FB04B1934943A5C02806D1A2204B6C05725B@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixO6iqKvw2SjKoHuiucWFmYcZLb7+2MTm wOTx6+tVNo8lS34yBTBFcdmkpOZklqUW6dslcGVcn3qJteCVXMXyu7uZGxhPSXQxcnJICJhI vP77j62LkYtDSGAHk8TrjxNYQBJCAg+ZJO795wSxhQUcJJb0nACLiwikSfRM7GeHaJjAJPFu +QNWkASbgJbEnEP/wYp4Bewl3t09AGazCKhKTG7dAFYjCtS850IHVI2gxMmZT8BsTgE/ib/f PoDZzAJmEvM2P2SGsMUlbj2ZzwRhy0tsfzuHeQIj/ywk7bOQtMxC0jILScsCRpZVjHKJOaW5 urmJmTnFqcm6xcmJeXmpRboWermZJXqpKaWbGCGhKrKD8chJuUOMAhyMSjy8Fm1GUUKsiWXF lbmHGCU5mJREeUs2AYX4kvJTKjMSizPii0pzUosPMUpwMCuJ8F5pBcrxpiRWVqUW5cOkpDlY lMR5vy1W9xMSSE8sSc1OTS1ILYLJynBwKEnwRnwCahQsSk1PrUjLzClBSDNxcIIM5wEafvIj yPDigsTc4sx0iPwpRmOOnp4bf5g4ns183cAsxJKXn5cqJc67HGScAEhpRmke3DRYunnFKA70 nDDvSpCBPMBUBTfvFdAqJqBVz1v0QVaVJCKkpBoY583bkZg2T2t907aLU41l5a5M+daaa+Er 9PjxgdiHW/ew853r+XTOwuJptEpMun60uHhD3wWn6c1PgvxVbv5xOXrjyJ9Ia6/qNY3v/+iZ ac6f9eDepCcVF3Uf37WY1cE5cc8cEU35f9vsts3a/vky04RvE6v44+ZH6M7+Y7r1zrmg/QEP JM8EsSqxFGckGmoxFxUnAgDNiq/DEgMAAA== Archived-At: Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? 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, 14 Dec 2017 21:54:44 -0000 On 12/14/17 2:27 PM, Christer Holmberg wrote: > Hi, > >>>>> It is currently suggested (see pull request in other e-mail) that a >>>>> proxy that receives a SIP REGISTER request with pn- parameters for a >>>>> PNS provider it does not support sends a 501 (Not Implemented) >>>>> response code. >>>> >>>> I took a quick look at the draft, and I might have missed it, but how >>>> does the UA verify that the registrar (the UAS receiving its REGISTER >>>> request) supports the push notifications that it expects? Or rather, >>>> how does it register so that the response tells it whether this >>>> proxy/registrar implements push in one or another way vs. whether >>>> it's an ordinary proxy registrar? These upward-compatibility >>>> procedures need to be laid out carefully. >>> >>> We could use a feature capability tag for that. >> >> IMO the sip options mechanism is appropriate here. The UA would include a Require:push in >> the REGISTER, and the registrar, if it supports push, will include Supported:push in the response. > > The push functionality may not necessarily be supported by the registrar - it may be handled by an intermediary SIP proxy. Hmm. In that case piggybacking everything on the REGISTER at least seems a bit sleazy. In that case it might be better for the proxy to use a feature-capability-indicator to supply the URI where the UA can register for the push service. Thanks, Paul >> It gets a bit more subtle regarding the particular push mechanism. >> Suppose that the registrar supports the push mechanism for some PNS providers but not the requested one. There is a temptation to indicate this by returning >Unsupported:push. But this would be a distortion. It is probably better to find a different way to indicate this. Using some error code, and perhaps also a Reason code, is a >possibility. > > I think a new error code would be justified for this. > > Regards, > > Christer > > > > > > >>> Also, as a general design question, it seems to me that these pn- >>> parameters would do better as header parameters than URI parameters. >>> E.g.: >>> >>> REGISTER sip:alice@example.com SIP/2.0 >>> ... >>> Contact: ; >>> pn-type=acme:acme-param; >>> pn-prid="ZTY4ZDJlMzODE1NmUgKi0K" >>> >>> Because the pn- parameters are more *properties of* the contact that >>> is being registered than intrinsic *parts of* the contact. >> >> The reason they are defined as URI parameters is because the SIP >> registrar will add them to the SIP INVITE/MESSAGE request using normal >> registrar procedures. >> >>> There's also this oddity in the text: >>> >>> When a SIP UA registers to a push service, it will receive a unique >>> Push Resource ID (PRID) associated to that registration. The SIP UA >>> will provide the PRID to the SIP network in a SIP REGISTER request. >>> A SIP proxy (e.g., the SIP registrar) will store a mapping between >>> the registered contact and the PRID. >>> >>> The first sentence suggests that the PRID is assigned by the >>> registrar and supplied in the REGISTER response, whereas the second >>> sentence suggests the PRID is presumably assigned by the UA and >>> supplied in the REGISTER *request*. Do you mean "The SIP UA will >>> provide the PRID to the SIP network in the subsequent SIP REGISTER >>> requests of the same registration pseudo-dialog."? >> >> The SIP UA registers to the push service using a non-SIP protocol. >> Perhaps that could be more clear. >> >> 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 > From nobody Thu Dec 14 23:39: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 D99B1124BFA for ; Thu, 14 Dec 2017 23:39:00 -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 XcGsKIIWuV_j for ; Thu, 14 Dec 2017 23:38:58 -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 EB6B9126FB3 for ; Thu, 14 Dec 2017 23:38:57 -0800 (PST) X-AuditID: c1b4fb30-11d5e9c000006bc7-f5-5a337c0f06e7 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.D4.27591.F0C733A5; Fri, 15 Dec 2017 08:38:56 +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; Fri, 15 Dec 2017 08:38:50 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Push: PNS-specific SIP response code? Thread-Index: AQHTdLErsERfCgaO8UmFU8mX7KL7pqNCpPkAgAAmKYCAAB0NAIAAUDSAgAAZvoCAAMdegA== Date: Fri, 15 Dec 2017 07:38:49 +0000 Message-ID: References: <87r2rxy23l.fsf@hobgoblin.ariadne.com> <2c80e804-426f-97de-276b-fb31384cddeb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B6C05725B@ESESSMB109.ericsson.se> <9d127d65-0679-df12-d463-66abaed16fda@alum.mit.edu> In-Reply-To: <9d127d65-0679-df12-d463-66abaed16fda@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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7iK5AjXGUQf8WLosVGw6wWnz9sYnN gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY/vQXU0GXUsW++RkNjGukuxg5OSQETCQ6 dqxk7mLk4hASOMwocenFexaQhJDAEkaJWRdUuhg5ONgELCS6/2mDhEUEAiWuLpnADGILCzhI LOk5wQIRd5Q4e/odG4QdJjF/TRMbSCuLgKrE8ZZYkDCvgLXEn2tXGSFWHWOSWDN3K9gcTqA5 MyZNYwKxGQXEJL6fWgNmMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//YwWxRQX0JDacuM0OEVeS +LHhEgtEr57EjalT2CBsa4m/b+ZD2doSyxa+ZoY4SFDi5MwnLBMYxWYhWTcLSfssJO2zkLTP QtK+gJF1FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgTB3c8ttgB+PL546HGAU4GJV4eM8W G0cJsSaWFVfmHmKU4GBWEuG95wYU4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvSkzdKSCA9sSQ1 OzW1ILUIJsvEwSnVwCh6kGnhonP+LDc9Pr46+GVlTKQ5r9iD1PrdeZEX/9vnP2icd9C38ikv N1uH2+XW5BanRKYP51ZGhc5NM17Odu6TqLenvPa0hSt+ziyvr/AXe7OR65ZerbvSndMHddd8 SpcyYXfgCyi5Na/wtviUvOpNJ87y9LEHWPa1fmHZb/zZf9sW6+XGm5RYijMSDbWYi4oTAfNk KGGlAgAA Archived-At: Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? 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, 15 Dec 2017 07:39:01 -0000 Hi, >>>>>>It is currently suggested (see pull request in other e-mail) that a >>>>>> proxy that receives a SIP REGISTER request with pn- parameters for a >>>>>> PNS provider it does not support sends a 501 (Not Implemented) >>>>>> response code. >>>>> >>>>> I took a quick look at the draft, and I might have missed it, but how >>>>> does the UA verify that the registrar (the UAS receiving its REGISTER >>>>> request) supports the push notifications that it expects? Or rather, >>>>> how does it register so that the response tells it whether this >>>>> proxy/registrar implements push in one or another way vs. whether >>>>> it's an ordinary proxy registrar? These upward-compatibility >>>>> procedures need to be laid out carefully. >>>> >>>> We could use a feature capability tag for that. >>> >>> IMO the sip options mechanism is appropriate here. The UA would >>>include a Require:push in >>> the REGISTER, and the registrar, if it supports push, will include >>>Supported:push in the response. >>=20 >> The push functionality may not necessarily be supported by the >>registrar - it may be handled by an intermediary SIP proxy. > >Hmm. In that case piggybacking everything on the REGISTER at least seems >a bit sleazy. In that case it might be better for the proxy to use a >feature-capability-indicator to supply the URI where the UA can register >for the push service. The idea is that the proxy itself could send the error response. Also, I don=B9t think we need a URI. The URI, and other credentials, is normally part of the device iOS, and at least in the case of iOS and Android you can=B9t register with any other push service. Regards, Christer > > Thanks, > Paul > >>> It gets a bit more subtle regarding the particular push mechanism. >>> Suppose that the registrar supports the push mechanism for some PNS >>>providers but not the requested one. There is a temptation to indicate >>>this by returning >Unsupported:push. But this would be a distortion. It >>>is probably better to find a different way to indicate this. Using some >>>error code, and perhaps also a Reason code, is a >possibility. >>=20 >> I think a new error code would be justified for this. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>>> Also, as a general design question, it seems to me that these pn- >>>> parameters would do better as header parameters than URI parameters. >>>> E.g.: >>>> >>>> REGISTER sip:alice@example.com SIP/2.0 >>>> ... >>>> Contact: ; >>>> pn-type=3Dacme:acme-param; >>>> pn-prid=3D"ZTY4ZDJlMzODE1NmUgKi0K" >>>> >>>> Because the pn- parameters are more *properties of* the contact that >>>> is being registered than intrinsic *parts of* the contact. >>> >>> The reason they are defined as URI parameters is because the SIP >>> registrar will add them to the SIP INVITE/MESSAGE request using normal >>> registrar procedures. >>> >>>> There's also this oddity in the text: >>>> >>>> When a SIP UA registers to a push service, it will receive a >>>>unique >>>> Push Resource ID (PRID) associated to that registration. The SIP >>>>UA >>>> will provide the PRID to the SIP network in a SIP REGISTER >>>>request. >>>> A SIP proxy (e.g., the SIP registrar) will store a mapping between >>>> the registered contact and the PRID. >>>> >>>> The first sentence suggests that the PRID is assigned by the >>>> registrar and supplied in the REGISTER response, whereas the second >>>> sentence suggests the PRID is presumably assigned by the UA and >>>> supplied in the REGISTER *request*. Do you mean "The SIP UA will >>>> provide the PRID to the SIP network in the subsequent SIP REGISTER >>>> requests of the same registration pseudo-dialog."? >>> >>> The SIP UA registers to the push service using a non-SIP protocol. >>> Perhaps that could be more clear. >>> >>> 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 >>=20 > From nobody Fri Dec 15 03:04:17 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F281277BB for ; Fri, 15 Dec 2017 03:04:15 -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 etcra6MItSTl for ; Fri, 15 Dec 2017 03:04:13 -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 BCD1E12773A for ; Fri, 15 Dec 2017 03:04:12 -0800 (PST) X-AuditID: c1b4fb25-859119c00000341b-6b-5a33ac2af36c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 83.36.13339.A2CA33A5; Fri, 15 Dec 2017 12:04:10 +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; Fri, 15 Dec 2017 12:04:09 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Push: PNS-specific SIP response code? Thread-Index: AQHTdZRusERfCgaO8UmFU8mX7KL7pg== Date: Fri, 15 Dec 2017 11:04:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D6597ACE27C61christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2J7oK7WGuMogyXN5hZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoW+BWwFZxQqPiw6yNjAOFemi5GTQ0LARGLeqiaWLkYuDiGB w4wS23+dZoJwljBK3Pgzga2LkYODTcBCovufNkiDiICmxPJvW9lBbGEBB4klPSdYIOKOEmdP v2ODsPUkLv98DGazCKhKrLq4BGwMr4C1xMLNYGMYBcQkvp9awwRiMwuIS9x6Mp8J4h4BiSV7 zjND2KISLx//YwWxRYFGbjhxmx0irijR/rSBEaI3QeLfkV9gvbwCghInZz5hmcAoNAvJ2FlI ymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGOoXmuJG2deMSGrWcDIsYpRtDi1OCk33chYL7Uo M7m4OD9PLy+1ZBMjMFIObvmtuoPx8hvHQ4wCHIxKPLxb5xlHCbEmlhVX5h5ilOBgVhLhvecG FOJNSaysSi3Kjy8qzUktPsQozcGiJM570pM3SkggPbEkNTs1tSC1CCbLxMEp1cBovH6vzIdF S+J6dlXPPDPn4heHhCe9++J6psq0RSsFH3l0Nn6WuUOd5Pc83o2fVsbH9G/z0lBu2uxjvbF1 1obKeepuph7X2CMVbbuTqqrudvxv3yXLsZHv+qHlT/Mf10yunf163bYfL4JS3px0WNP1qLl7 3tKc2QdEli7ZdfnpWofzTfpPJ5XpKrEUZyQaajEXFScCAHx2UNOQAgAA Archived-At: Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? 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, 15 Dec 2017 11:04:15 -0000 --_000_D6597ACE27C61christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have updated the pull request by adding a new SIP response code, 555 (Pus= h Notification Service Not Supported). https://github.com/cdh4u/draft-sip-push/pull/4 Regards, Christer From: sipcore > o= n behalf of Christer Holmberg > Date: Thursday 14 December 2017 at 09:57 To: "sipcore@ietf.org" > Subject: [sipcore] SIP Push: PNS-specific SIP response code? Hi, It is currently suggested (see pull request in other e-mail) that a proxy t= hat receives a SIP REGISTER request with pn- parameters for a PNS provider = it does not support sends a 501 (Not Implemented) response code. The question is whether it would be useful to define a PNS-specific respons= e code for this? E.g., 514 (Push Notification Service Not Supported). In ad= dition, we could define a feature capability indicator that could be added = to the response and list the PNS providers supported by the proxy. Regards, Christer --_000_D6597ACE27C61christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3CDAEF86B33D7E4991B7BD0F29D74021@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I have updated the pull request by adding a new SIP response code, 555= (Push Notification Service Not Supported).


Regards,

Christer

From: sipcore <sipcore-bounces@ietf.org> on behalf of Ch= rister Holmberg <chris= ter.holmberg@ericsson.com>
Date: Thursday 14 December 2017 at = 09:57
To: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: [sipcore] SIP Push: PNS-sp= ecific SIP response code?

Hi,

It is currently suggested (see pull request in other e-mail) that a pr= oxy that receives a SIP REGISTER request with pn- parameters for a PNS prov= ider it does not support sends a 501 (Not Implemented) response code. =

The question is whether it would be useful to define a PNS-specific re= sponse code for this? E.g., 514 (Push Notification Service Not Supported). = In addition, we could define a feature capability indicator that could be a= dded to the response and list the PNS providers supported by the proxy.

Regards,

Christer
 --_000_D6597ACE27C61christerholmbergericssoncom_-- From nobody Mon Dec 18 00:30:14 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D05126CC4 for ; Mon, 18 Dec 2017 00:30:12 -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 5YQPs11LxmcX for ; Mon, 18 Dec 2017 00:30:10 -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 B6BC512421A for ; Mon, 18 Dec 2017 00:30:09 -0800 (PST) X-AuditID: c1b4fb25-859119c00000341b-ca-5a377c8fc80b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 99.23.13339.F8C773A5; Mon, 18 Dec 2017 09:30:08 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Mon, 18 Dec 2017 09:29:44 +0100 From: Christer Holmberg To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Push: PNS-specific SIP response code? Thread-Index: AQHTdZRusERfCgaO8UmFU8mX7KL7pqNI3PyA Date: Mon, 18 Dec 2017 08:29:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D65D4B0527CC1christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7iO6EGvMog9v3mC2+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPU9b5kKvptU3OtdyNjA+Ee3i5GTQ0LARGL1nDUsXYxcHEIC hxkllvevZoVwljBKNG95CORwcLAJWEh0/9MGaRARiJfYt+AlI4gtLOAgsaTnBAtE3FHi7Ol3 bBC2kcSOHQeYQGwWAVWJo6fvg9XzClhLPJowmRnEFgKytyxaDNbLKWAjsWftHrBeRgExie+n 1oD1MguIS9x6Mp8J4lABiSV7zjND2KISLx//YwWxRQX0JDacuM0OcqaEgJLEtK1pICazQILE 6s2cEFsFJU7OfMIygVFkFpKhsxCqZiGpgijRkViw+xMbhK0tsWzha2YY+8yBx0wQtrXEupdT mZDVLGDkWMUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGFUHt/xW3cF4+Y3jIUYBDkYlHt4P OeZRQqyJZcWVuYcYJTiYlUR4U4uBQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5ak ZqemFqQWwWSZODilGhgzHdO2Pw5KfvRi5v1l90o3dh6/wtFjOYGpSMi5RnNpSvN1iUrFPwwB Vh0ZZ7aYPZ3LEC132NeJMWvvqypP47daHK9uPzx2esuHraXzQttmpE9fXvWFT3Cua7ztrR1Z rzL2XDui0rBX0CtI3K0u7gz7WbUC7S/Jry6lJaUJ7CnaFpxyZQZP+yclluKMREMt5qLiRADk I+L3pgIAAA== Archived-At: Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? 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, 18 Dec 2017 08:30:13 -0000 --_000_D65D4B0527CC1christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have updated the pull request, but clarifying that the SIP UA uses the pr= otocol/procedures associated with the PNS when registering with that PNS. So far nobody has objected to the changes/additions in the pull request, so= I intend to merge it, and submit a new version of the draft. https://github.com/cdh4u/draft-sip-push/pull/4 Regards, Christer From: sipcore > o= n behalf of Christer Holmberg > Date: Friday 15 December 2017 at 13:04 To: "sipcore@ietf.org" > Subject: Re: [sipcore] SIP Push: PNS-specific SIP response code? Hi, I have updated the pull request by adding a new SIP response code, 555 (Pus= h Notification Service Not Supported). https://github.com/cdh4u/draft-sip-push/pull/4 Regards, Christer From: sipcore > o= n behalf of Christer Holmberg > Date: Thursday 14 December 2017 at 09:57 To: "sipcore@ietf.org" > Subject: [sipcore] SIP Push: PNS-specific SIP response code? Hi, It is currently suggested (see pull request in other e-mail) that a proxy t= hat receives a SIP REGISTER request with pn- parameters for a PNS provider = it does not support sends a 501 (Not Implemented) response code. The question is whether it would be useful to define a PNS-specific respons= e code for this? E.g., 514 (Push Notification Service Not Supported). In ad= dition, we could define a feature capability indicator that could be added = to the response and list the PNS providers supported by the proxy. Regards, Christer --_000_D65D4B0527CC1christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0B3128EBFE9F1D44B5533BB85F822696@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I have updated the pull request, but clarifying that the SIP UA uses t= he protocol/procedures associated with the PNS when registering with that P= NS.

So far nobody has objected to the changes/additions in the pull reques= t, so I intend to merge it, and submit a new version of the draft.


Regards,

Christer

From: sipcore <sipcore-bounces@ietf.org> on behalf of Ch= rister Holmberg <chris= ter.holmberg@ericsson.com>
Date: Friday 15 December 2017 at 13= :04
To: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] SIP Push: PN= S-specific SIP response code?

Hi,

I have updated the pull request by adding a new SIP response code, 555= (Push Notification Service Not Supported).


Regards,

Christer

From: sipcore <sipcore-bounces@ietf.org> on behalf of Ch= rister Holmberg <chris= ter.holmberg@ericsson.com>
Date: Thursday 14 December 2017 at = 09:57
To: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: [sipcore] SIP Push: PNS-sp= ecific SIP response code?

Hi,

It is currently suggested (see pull request in other e-mail) that a pr= oxy that receives a SIP REGISTER request with pn- parameters for a PNS prov= ider it does not support sends a 501 (Not Implemented) response code. =

The question is whether it would be useful to define a PNS-specific re= sponse code for this? E.g., 514 (Push Notification Service Not Supported). = In addition, we could define a feature capability indicator that could be a= dded to the response and list the PNS providers supported by the proxy.

Regards,

Christer
 --_000_D65D4B0527CC1christerholmbergericssoncom_-- From nobody Tue Dec 19 01:07:13 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E335A127077; Tue, 19 Dec 2017 01:07:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151367443191.7482.2696529892653541011@ietfa.amsl.com> Date: Tue, 19 Dec 2017 01:07:11 -0800 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 09:07:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Push Notification with the Session Initiation Protocol (SIP) Author : Christer Holmberg Filename : draft-ietf-sipcore-sip-push-01.txt Pages : 13 Date : 2017-12-19 Abstract: This document describes how push notification mechanisms can be used to wake up suspended Session Initiation Protocol (SIP) User Agents (UAs), in order to be able to receive and generate SIP requests. The document defines new SIP URI parameters, that can be used in a SIP REGISTER request to provide push notification information from the SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in this document) that will send a push request to the push server in order to trigger a push notification towards the SIP UA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 19 01:15:28 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ED8126C0F for ; Tue, 19 Dec 2017 01:15: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 vzo_FsygFTuR for ; Tue, 19 Dec 2017 01:15: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 856DC1201F2 for ; Tue, 19 Dec 2017 01:15:25 -0800 (PST) X-AuditID: c1b4fb25-473ff7000000341b-95-5a38d8ab36d0 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.B0.13339.BA8D83A5; Tue, 19 Dec 2017 10:15:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Tue, 19 Dec 2017 10:15:22 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: sip-push-01 Thread-Index: AQHTeKnlIkNzrMluhEygCkuPB/YSFQ== Date: Tue, 19 Dec 2017 09:15:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D65EA78A27E79christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7ou7qGxZRBo1bNSy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFWf37IUnJKs2LWqgbmB8aBoFyMnh4SAicTRppWsXYxcHEIC hxkltq3uhXKWMEps+n2NuYuRg4NNwEKi+582SIOIgKbE8m9b2UFsYQF1iW/fF7NBxHUkvt/f A2XrSdz+vIkRxGYRUJXYu2wvE4jNK2AtsXfFFbBeRgExie+n1oDFmQXEJW49mc8EcZCAxJI9 55khbFGJl4//sYLYokAzN5y4zQ4RV5T4+GofI0RvgsSP2+8ZIeYLSpyc+YRlAqPQLCRjZyEp m4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxriSf/r7Ijq1nAyLGKUbQ4tTgpN93IWC+1 KDO5uDg/Ty8vtWQTIzBWDm75rbqD8fIbx0OMAhyMSjy8iQctooRYE8uKK3MPMUpwMCuJ8C7c CRTiTUmsrEotyo8vKs1JLT7EKM3BoiTOe9KTN0pIID2xJDU7NbUgtQgmy8TBKdXAKHLJKMmI s9T3uV2rr7xE0benjF+fe57qULW8wOsyY4HEruW955Q3iW1x8MsTELl5evdVjexNx/wTv7zx usLY+WJtfmSuluzetxXK5gaBR0JZJq87G19x0/PHxDunT03bWvj7nvOKvBqjmGKNbZlb+Sck 1snmPO3fUr7TK/bfrCSGax9Yt837rsRSnJFoqMVcVJwIAHOvK+eRAgAA Archived-At: Subject: [sipcore] Draft new version: sip-push-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 09:15:27 -0000 --_000_D65EA78A27E79christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I have merged the following pull request: https://github.com/cdh4u/draft-sip-push/pull/4 =85and submitted a new version (-01) of draft-ietf-sipcore-sip-push. The main technical changes/additions: * Modified/added URI parameters, based on comments from Mickey * Added 555 (Push Notification Service Not Supported) response code The main editorial changes/additions: * Clarified that the SIP Proxy can reject a REGISTER request that conta= ins PNS parameters not supported by the proxy, based on comments from Micke= y * Clarified that the SIP UA, when registering with a PNS, uses whatever= protocol and procedures associated with that PNS, based on comments from D= ale Remaining open issues: * There were talks about whether to define a media feature tag and/or f= eature capability indicator that can be used to indicate what PNS(s) a SIP = UA and SIP Proxy supports. I intend to provide a pull request for that. Please take a look, and let me know whether you still think there are open = issues, missing text etc. Regards, Christer --_000_D65EA78A27E79christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I have merged the following pull request:


=85and submitted a new version (-01) of draft-ietf-sipcore-sip-push.

The main technical changes/additions:
  • Modified/added URI parameters, based on comments from Mickey
  • Ad= ded 555 (Push Notification Service Not Supported) response code
The main editorial changes/additions:
  • Clarified that the SIP Proxy can reject a REGISTER request that contain= s PNS parameters not supported by the proxy, based on comments from Mickey<= /li>
  • Clarified that the SIP UA, when registering with a PNS, uses whatev= er protocol and procedures associated with that PNS, based on comments from= Dale

Remaining open issues:
  • There were talks about whether to define a media feature tag and/or fea= ture capability indicator that can be used to indicate what PNS(s) a SIP UA= and SIP Proxy supports. I intend to provide a pull request for that.
    • <= /ul>
    Please take a look, and let me know whether you still think there are = open issues, missing text etc.

    Regards,

    Christer
    --_000_D65EA78A27E79christerholmbergericssoncom_-- From nobody Tue Dec 19 04:20: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 1D34C12DA72 for ; Tue, 19 Dec 2017 04:20:01 -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 8XvfsATp8HmV for ; Tue, 19 Dec 2017 04:19:59 -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 B4D9012DA70 for ; Tue, 19 Dec 2017 04:19:58 -0800 (PST) X-AuditID: c1b4fb25-859119c00000341b-1b-5a3903ecbffd Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D5.5D.13339.CE3093A5; Tue, 19 Dec 2017 13:19:56 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Tue, 19 Dec 2017 13:19:56 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: SIP Push: sip.pns Feature-Capability Indicator Thread-Index: AQHTeMOu7pfLgaboM0yFGTjmqdXxFA== Date: Tue, 19 Dec 2017 12:19:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D65ED2CC27E9Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7ou4bZssog5mNlhZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrlb31kL9nNXvL52lbWBsZ2ri5GTQ0LARGJ59wvWLkYuDiGB w4wSOw5OZ4ZwljBKrOj9wtbFyMHBJmAh0f1PG6RBREBTYvm3rewgtrCAuUT7qdtsEHEbiWsf +pkgbD2J5c3vWUBsFgFVidUT/zOD2LwC1hLzG7rB4owCYhLfT60Bq2cWEJe49WQ+E8RBAhJL 9pxnhrBFJV4+/scKYosCzdxw4jY7yDkSAooSy/vlIFoTJHZd7GOBGC8ocXLmE5YJjEKzkEyd haRsFpIyiLiBxPtz85khbG2JZQtfQ9n6Ehu/nGWEsK0l7i5ex4KsZgEjxypG0eLU4qTcdCNj vdSizOTi4vw8vbzUkk2MwEg5uOW36g7Gy28cDzEKcDAq8fBGf7CIEmJNLCuuzD3EKMHBrCTC u3AnUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgsEwenVAOjyrHY Of7aN1IVJyjNDb7zkYnp679pj/ZOOpL46hXH7Rk3D2saCH5M2fu0TOZG+KHSsg7fzdbv3+h2 G20qOMySU1qvsuGa+IZZmd/Y7++98ZaVy8l8q3ZDsoCZ8jq3eTUdTWnVK647VJxkLfssndj9 MCmxxm2p5sEZe/K0zC7+SpVsu3xzzgEWJZbijERDLeai4kQASId8b5ACAAA= Archived-At: Subject: [sipcore] SIP Push: sip.pns Feature-Capability Indicator 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, 19 Dec 2017 12:20:01 -0000 --_000_D65ED2CC27E9Achristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve created a pull request, that defines a feature-capability indicator = that can be used by a SIP proxy, in a 555 response, to indicate which push = notification services the proxy supports. https://github.com/cdh4u/draft-sip-push/pull/5 Regards, Christer --_000_D65ED2CC27E9Achristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <76C916F9C78FC3439A15295E94DEC432@ericsson.com> Content-Transfer-Encoding: quoted-printable
    Hi,

    I=92ve created a pull request, that defines a feature-capability indic= ator that can be used by a SIP proxy, in a 555 response, to indicate which = push notification services the proxy supports.


    Regards,

    Christer
    --_000_D65ED2CC27E9Achristerholmbergericssoncom_-- From nobody Tue Dec 19 08:21: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 BBC971270AC for ; Tue, 19 Dec 2017 08:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 TkrjGGBPsx3n for ; Tue, 19 Dec 2017 08:21:29 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 69486128C0A for ; Tue, 19 Dec 2017 08:21:29 -0800 (PST) X-AuditID: 12074412-1fdff7000000748d-60-5a393c874113 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C6.38.29837.78C393A5; Tue, 19 Dec 2017 11:21: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 vBJGLQ4r030176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Dec 2017 11:21:27 -0500 To: sipcore@ietf.org References: <151367443191.7482.2696529892653541011@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <5fd71bcd-00be-f6d1-996d-ece6143a639d@alum.mit.edu> Date: Tue, 19 Dec 2017 11:21:26 -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: <151367443191.7482.2696529892653541011@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixO6iqNthYxll8Psso8XXH5vYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWhjF2PBKvmK/SsmsTYwrpfoYuTkkBAwkbi96R4LiC0ksINJ 4swMrS5GLiD7B5PE0/mf2UESwgKuEhe2HWQDsUUERCSeTf/HBtHgJNHXM4MZxGYT0JKYc+g/ 0CAODl4Be4nvby1AwiwCqhIPfqxlArFFBdIk9lzoANvFKyAocXLmEzCbU8BZ4vzZM2BjmAXM JOZtfghli0vcejKfCcKWl9j+dg7zBEb+WUjaZyFpmYWkZRaSlgWMLKsY5RJzSnN1cxMzc4pT k3WLkxPz8lKLdM30cjNL9FJTSjcxQkJSaAfj+pNyhxgFOBiVeHgV9CyjhFgTy4orcw8xSnIw KYnynp1iESXEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHfhTqAcb0piZVVqUT5MSpqDRUmc9+di dT8hgfTEktTs1NSC1CKYrAwHh5IEb5c10B7BotT01Iq0zJwShDQTByfIcB6g4WYgNbzFBYm5 xZnpEPlTjMYcPT03/jBxPJv5uoFZiCUvPy9VSpy30gqoVACkNKM0D24aLK28YhQHek6Y9xpI FQ8wJcHNewW0iglo1dQIc5BVJYkIKakGxozWAO30y7m/bSakOvvtleid2PVP1vj96d1xcosO OE/ulrTiPNv/K2rLB37DTEXZH6dvrChv2VLON/+T6BQ1nqMSfbP6Jb//tY374lD225Zjc6Dh vEvbj7qoLZ6h8YjtOc/dezoJLbfTv08zuK75mH+yyxn2hcrNJt8evntexiVVE7G3VnpashJL cUaioRZzUXEiAPVGz+QGAwAA Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 16:21:32 -0000 Hi Christer, A few comments on this version: Section 5.3 says: If the proxy is aware of another proxy that supports the PNS provider, the proxy MAY redirect the SIP request (using a SIP 3xx response code) to that proxy. I think this needs to be more specific. I guess you have in mind to use 305 (Use Proxy), since no other response seems suitable. Unfortunately AFAIK the details of how to use 305 have never been specified. In particular, suppose you sent the prior request with a Route header containing one or more URIs. How should the Contact URI in the 305 influence how the request is updated? Does that URI replace all the URIs in the Route, does it replace the first or the last, or does it get added to the front or the back of the list in the Route? I'm not suggesting that the this document fix that. Instead, if the proxy knows of another proxy that can support the PNS provider, why not simply forward the request to it? I also have a question about the mechanics of this. There could be multiple proxies in the path to the registrar. Potentially more than one of them might support this feature. If a proxy returns 555 it is in effect saying that it knows that neither it, nor any proxy further along the route to the registrar, supports this PNS. I think the implications of that should be discussed. Later in the section is the following: If the SIP proxy is able to assume that the SIP UA is awake, and that the UA is able to receive the SIP request, the proxy MAY choose to not trigger a push notification request before trying to forward the SIP request towards the UA. The proxy can make such assumption e.g., if a TLS connection previously established by the UA is still open. Is this a valid assumption? The timeout for a TCP/TLS connection is quite long. Unless the UA overtly tears it down before sleeping then it might still be up even though the device is sleeping. Also a nit in this section: s/receival/receipt/ Thanks, Paul On 12/19/17 4:07 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core WG of the IETF. > > Title : Push Notification with the Session Initiation Protocol (SIP) > Author : Christer Holmberg > Filename : draft-ietf-sipcore-sip-push-01.txt > Pages : 13 > Date : 2017-12-19 > > Abstract: > This document describes how push notification mechanisms can be used > to wake up suspended Session Initiation Protocol (SIP) User Agents > (UAs), in order to be able to receive and generate SIP requests. The > document defines new SIP URI parameters, that can be used in a SIP > REGISTER request to provide push notification information from the > SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in > this document) that will send a push request to the push server in > order to trigger a push notification towards the SIP UA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Dec 19 11:22: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 4A4E61270AC for ; Tue, 19 Dec 2017 11:22:48 -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 XxLU0KXsuI1X for ; Tue, 19 Dec 2017 11:22:46 -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 59C011200F1 for ; Tue, 19 Dec 2017 11:22:46 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-c9-5a396704e55a Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 66.39.14322.407693A5; Tue, 19 Dec 2017 20:22:44 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Tue, 19 Dec 2017 20:22:43 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-01.txt Thread-Index: AQHTeOVxeU1DX0WTI0GYq+ocDjUi+6NLCSCQ Date: Tue, 19 Dec 2017 19:22:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0CD71E@ESESSMB109.ericsson.se> References: <151367443191.7482.2696529892653541011@ietfa.amsl.com> <5fd71bcd-00be-f6d1-996d-ece6143a639d@alum.mit.edu> In-Reply-To: <5fd71bcd-00be-f6d1-996d-ece6143a639d@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7qC5LumWUwfrLohYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxYeJ0xoILqhW3Jrg0MJ6Q7WLk5JAQMJH4 dHIFYxcjF4eQwGFGiQWrn0M5Sxgl/j64z9bFyMHBJmAh0f1PG6RBRCBQ4uqSCcwgtrCAq8SG 3zuZQUpEBNwkLv2whigxkrjacgCshEVAVaL3734wm1fAV6Jx0VRWEFtIoEJi4rNmsDingIPE /mVXWEBsRgExie+n1jCB2MwC4hK3nsxngrhTQGLJnvPMELaoxMvH/1ghbCWJxiVPWCHqdSQW 7P7EBmFrSyxb+Bpqr6DEyZlPWCYwisxCMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfdyEgvtSgz ubg4P08vL7VkEyMwFg5u+W21g/Hgc8dDjAIcjEo8vI5pllFCrIllxZW5hxglOJiVRHgX7rSI EuJNSaysSi3Kjy8qzUktPsQozcGiJM7rlAaUEkhPLEnNTk0tSC2CyTJxcEo1MK7XUj/MPH+5 8iwTzXeuv71F+cNtjY/J/l9++V5GhNFZrvSk9asrFp876LzAL92YKf/M5+7ZLvx7ZebvMmne 9Wpq45Ro5bKHdxU0fmu9nd+XV+m6Z63+wd/V3u0LDv6zc1C5fZez5ED0xPSQGP35R7wcC3h7 68o8d/Er361Jr/67YHWvYGiltRJLcUaioRZzUXEiANF5YWOBAgAA Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 19:22:48 -0000 Hi Paul, >A few comments on this version: > >Section 5.3 says: > > If the proxy is aware of another proxy that > supports the PNS provider, the proxy MAY redirect the SIP request > (using a SIP 3xx response code) to that proxy. > > I think this needs to be more specific. I guess you have in mind to use > 305 (Use Proxy), since no other response seems suitable. Unfortunately AF= AIK the details of how to use 305 have never been specified.=20 > In particular, suppose you sent the > prior request with a Route header c= ontaining one or more URIs. How should the Contact URI in the > 305 influence how the request is updated? Does that URI replace all the U= RIs in the Route, does it replace the first or the last, or does it > get added to the front or the back of the list in the Route? > > I'm not suggesting that the this document fix that. Instead, if the proxy= knows of another proxy that can support the PNS provider,=20 > why not simply forward the request to it? Works for me. We can fix 305 once we're done with the session-timer fix :) > I also have a question about the mechanics of this. There could be multip= le proxies in the path to the registrar.=20 > Potentially more than one of them might support this feature. If a proxy = returns 555 it is in effect saying that it=20 > knows that neither it, nor any proxy further along the route to the regis= trar, supports this PNS. I think the implications=20 > of that should be discussed. The draft could allow forwarding the request, based on configuration. Peopl= e deploying this can then do what works best for them. > Later in the section is the following: > > If the SIP proxy is able to assume that the SIP UA is awake, and that > the UA is able to receive the SIP request, the proxy MAY choose to > not trigger a push notification request before trying to forward the > SIP request towards the UA. The proxy can make such assumption e.g., > if a TLS connection previously established by the UA is still open. > > Is this a valid assumption? The timeout for a TCP/TLS connection is quite= long. Unless the UA overtly tears it down > before sleeping then it might still be up even though the device is sleep= ing. Sure, the text about TCP/TLS was just to give an example where the proxy mi= ght try to forward the request before triggering the push notification.=20 But, I can either remove it, or add text clarifying that a TLS connection d= oes not guarantee that the request will reach the UA. > Also a nit in this section: s/receival/receipt/ Will be fixed in the next version. Thanks! Regards, Christer On 12/19/17 4:07 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core WG of t= he IETF. >=20 > Title : Push Notification with the Session Initiation = Protocol (SIP) > Author : Christer Holmberg > Filename : draft-ietf-sipcore-sip-push-01.txt > Pages : 13 > Date : 2017-12-19 >=20 > Abstract: > This document describes how push notification mechanisms can be used > to wake up suspended Session Initiation Protocol (SIP) User Agents > (UAs), in order to be able to receive and generate SIP requests. The > document defines new SIP URI parameters, that can be used in a SIP > REGISTER request to provide push notification information from the > SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in > this document) that will send a push request to the push server in > order to trigger a push notification towards the SIP UA. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-push-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 Dec 20 03:14: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 E4B6C1200F3 for ; Wed, 20 Dec 2017 03:14: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 Aswo8Lsw9p5N for ; Wed, 20 Dec 2017 03:14:21 -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 9BAA012D88D for ; Wed, 20 Dec 2017 03:14:20 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-b7-5a3a460a060c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 02.33.14322.A064A3A5; Wed, 20 Dec 2017 12:14:18 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Wed, 20 Dec 2017 12:14:18 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-01.txt Thread-Index: AQHTeOVxeU1DX0WTI0GYq+ocDjUi+6NLCSCQgAEf3QA= Date: Wed, 20 Dec 2017 11:14:17 +0000 Message-ID: References: <151367443191.7482.2696529892653541011@ietfa.amsl.com> <5fd71bcd-00be-f6d1-996d-ece6143a639d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B6C0CD71E@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C0CD71E@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F072F377D203D46A884E26CA5E48282@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7li6Xm1WUwYNZChYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxaOUbloKDWhWPf15kbmB8q9jFyMkhIWAi sXt1E2sXIxeHkMBhRokzt84yQjhLGCW2r2oCcjg42AQsJLr/aYPERQRaGSW2bLjLCNItLOAq cWHbQTaQGhEBN4lLP6xBwiICVhLzj89mA7FZBFQlft37zApi8wpYS0zeeJcdYv4eRokVR3vY QRKcAn4SH/73MoPYjAJiEt9PrWECsZkFxCVuPZnPBHGpgMSSPeeZIWxRiZeP/4ENFRXQk9hw 4jY7RFxRYufZdmaIXj2JG1OnsEHY1hLTj39mgbC1JZYtfM0McZCgxMmZT1gmMIrNQrJuFpL2 WUjaZyFpn4WkfQEj6ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwMg6uOW31Q7Gg88dDzEK cDAq8fDG2VlFCbEmlhVX5h5ilOBgVhLhrf5sGSXEm5JYWZValB9fVJqTWnyIUZqDRUmc1ynN IkpIID2xJDU7NbUgtQgmy8TBKdXAyFGk/tVh2Yngterhd2/77Lct63EVutxjyn/nxb4pPz78 3ezO2JgzMzUq3ej5i52fc1+//aT2/+rhpTE5zcmbUvs7Eo6vXdyeuFO19lJui2uqecOaCg6h in2pNsu6bv2//59x5tPAWyd0o9cqTXn53demrOBIKWvePrnSkPdtSvmu1ZMmPnnSqcRSnJFo qMVcVJwIALtZ//GoAgAA Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 11:14:25 -0000 Hi, I updated the feature-tag pull request based on Paul=B9s comments: https://github.com/cdh4u/draft-sip-push/pull/5 I intend to submit a new version of the draft at the end of the week, so please take a look. Regards, Christer On 19/12/17 21:22, "sipcore on behalf of Christer Holmberg" wrote: >Hi Paul, > >>A few comments on this version: >> >>Section 5.3 says: >> >> If the proxy is aware of another proxy that >> supports the PNS provider, the proxy MAY redirect the SIP request >> (using a SIP 3xx response code) to that proxy. >> >> I think this needs to be more specific. I guess you have in mind to use >> 305 (Use Proxy), since no other response seems suitable. Unfortunately >>AFAIK the details of how to use 305 have never been specified. >> In particular, suppose you sent the > prior request with a Route header >>containing one or more URIs. How should the Contact URI in the >> 305 influence how the request is updated? Does that URI replace all the >>URIs in the Route, does it replace the first or the last, or does it >> get added to the front or the back of the list in the Route? >> >> I'm not suggesting that the this document fix that. Instead, if the >>proxy knows of another proxy that can support the PNS provider, >> why not simply forward the request to it? > >Works for me. > >We can fix 305 once we're done with the session-timer fix :) > >> I also have a question about the mechanics of this. There could be >>multiple proxies in the path to the registrar. >> Potentially more than one of them might support this feature. If a >>proxy returns 555 it is in effect saying that it >> knows that neither it, nor any proxy further along the route to the >>registrar, supports this PNS. I think the implications >> of that should be discussed. > >The draft could allow forwarding the request, based on configuration. >People deploying this can then do what works best for them. > >> Later in the section is the following: >> >> If the SIP proxy is able to assume that the SIP UA is awake, and that >> the UA is able to receive the SIP request, the proxy MAY choose to >> not trigger a push notification request before trying to forward the >> SIP request towards the UA. The proxy can make such assumption e.g., >> if a TLS connection previously established by the UA is still open. >> >> Is this a valid assumption? The timeout for a TCP/TLS connection is >>quite long. Unless the UA overtly tears it down >> before sleeping then it might still be up even though the device is >>sleeping. > >Sure, the text about TCP/TLS was just to give an example where the proxy >might try to forward the request before triggering the push notification. > >But, I can either remove it, or add text clarifying that a TLS connection >does not guarantee that the request will reach the UA. > >> Also a nit in this section: s/receival/receipt/ > >Will be fixed in the next version. > >Thanks! > >Regards, > >Christer > > > > >On 12/19/17 4:07 AM, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Session Initiation Protocol Core WG of >>the IETF. >>=20 >> Title : Push Notification with the Session >>Initiation Protocol (SIP) >> Author : Christer Holmberg >> Filename : draft-ietf-sipcore-sip-push-01.txt >> Pages : 13 >> Date : 2017-12-19 >>=20 >> Abstract: >> This document describes how push notification mechanisms can be used >> to wake up suspended Session Initiation Protocol (SIP) User Agents >> (UAs), in order to be able to receive and generate SIP requests. >>The >> document defines new SIP URI parameters, that can be used in a SIP >> REGISTER request to provide push notification information from the >> SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in >> this document) that will send a push request to the push server in >> order to trigger a push notification towards the SIP UA. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-01 >> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-01 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-push-01 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >>tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Dec 20 07:32: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 58A5D120727 for ; Wed, 20 Dec 2017 07:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nxr7DHHufVYQ for ; Wed, 20 Dec 2017 07:32:05 -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 8907A1200FC for ; Wed, 20 Dec 2017 07:32:05 -0800 (PST) X-AuditID: 1207440d-853ff70000000f42-4f-5a3a8272399b 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 1D.CE.03906.2728A3A5; Wed, 20 Dec 2017 10:32:03 -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 vBKFW0iM001508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Dec 2017 10:32:01 -0500 To: Christer Holmberg , "sipcore@ietf.org" References: <151367443191.7482.2696529892653541011@ietfa.amsl.com> <5fd71bcd-00be-f6d1-996d-ece6143a639d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B6C0CD71E@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Wed, 20 Dec 2017 10:32:00 -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+NgFvrPIsWRmVeSWpSXmKPExsUixO6iqFvcZBVlMPeVhcWFmYcZLb7+2MTm wOTx6+tVNo8lS34yBTBFcdmkpOZklqUW6dslcGW0fpnDWLBTp+LH47WsDYzdyl2MnBwSAiYS i8+9Z+ti5OIQEtjBJHHqxg8WCOchk8SNa93MIFXCAq4SF7YdZAOxRQTSJHom9rNDFL1jlOhZ fIMdJMEmoCUx59B/FhCbV8BeYs2PTYwgNouAqsSxdR1gcVGg5j0XOqBqBCVOznwCZHNwcArY SCzZFgESZhYwk5i3+SEzhC0ucevJfCYIW16ieets5gmM/LOQdM9C0jILScssJC0LGFlWMcol 5pTm6uYmZuYUpybrFicn5uWlFuka6eVmluilppRuYoSEKu8Oxv/rZA4xCnAwKvHwNiRbRQmx JpYVV+YeYpTkYFIS5V3kARTiS8pPqcxILM6ILyrNSS0+xCjBwawkwlv92TJKiDclsbIqtSgf JiXNwaIkzqu2RN1PSCA9sSQ1OzW1ILUIJivDwaEkwfu9AWioYFFqempFWmZOCUKaiYMTZDgP 0HDveqAa3uKCxNzizHSI/ClGY46enht/mDiezXzdwCzEkpeflyolznsIZJwASGlGaR7cNFi6 ecUoDvScMG99I1AVDzBVwc17BbSKCWjV1AhzkFUliQgpqQZGZ8UrB90T9rSXFWuk/p7/4pms 2hlBM5m3s/dGdLEfujBFr+5Q2U/Zqri5t8RmHlmc+V3Yn3Hb4menPikbf95V8EL/wrc837nf QrbuKJMOc2K/JXOz7GCWennwHCGvqcvUIsV0d7afvnaxeFO4mQvPgQaNVT9kDzHKrWl+9UFC 52mn59o02754JZbijERDLeai4kQA7FjBvRIDAAA= Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 15:32:11 -0000 On 12/20/17 6:14 AM, Christer Holmberg wrote: > Hi, > > I updated the feature-tag pull request based on PaulÂąs comments: > > https://github.com/cdh4u/draft-sip-push/pull/5 Looks good. > I intend to submit a new version of the draft at the end of the week, so > please take a look. > > Regards, > > Christer > > > On 19/12/17 21:22, "sipcore on behalf of Christer Holmberg" > > wrote: > >> Hi Paul, >> >>> A few comments on this version: >>> >>> Section 5.3 says: >>> >>> If the proxy is aware of another proxy that >>> supports the PNS provider, the proxy MAY redirect the SIP request >>> (using a SIP 3xx response code) to that proxy. >>> >>> I think this needs to be more specific. I guess you have in mind to use >>> 305 (Use Proxy), since no other response seems suitable. Unfortunately >>> AFAIK the details of how to use 305 have never been specified. >>> In particular, suppose you sent the > prior request with a Route header >>> containing one or more URIs. How should the Contact URI in the >>> 305 influence how the request is updated? Does that URI replace all the >>> URIs in the Route, does it replace the first or the last, or does it >>> get added to the front or the back of the list in the Route? >>> >>> I'm not suggesting that the this document fix that. Instead, if the >>> proxy knows of another proxy that can support the PNS provider, >>> why not simply forward the request to it? >> >> Works for me. >> >> We can fix 305 once we're done with the session-timer fix :) >> >>> I also have a question about the mechanics of this. There could be >>> multiple proxies in the path to the registrar. >>> Potentially more than one of them might support this feature. If a >>> proxy returns 555 it is in effect saying that it >>> knows that neither it, nor any proxy further along the route to the >>> registrar, supports this PNS. I think the implications >>> of that should be discussed. >> >> The draft could allow forwarding the request, based on configuration. >> People deploying this can then do what works best for them. >> >>> Later in the section is the following: >>> >>> If the SIP proxy is able to assume that the SIP UA is awake, and that >>> the UA is able to receive the SIP request, the proxy MAY choose to >>> not trigger a push notification request before trying to forward the >>> SIP request towards the UA. The proxy can make such assumption e.g., >>> if a TLS connection previously established by the UA is still open. >>> >>> Is this a valid assumption? The timeout for a TCP/TLS connection is >>> quite long. Unless the UA overtly tears it down >>> before sleeping then it might still be up even though the device is >>> sleeping. >> >> Sure, the text about TCP/TLS was just to give an example where the proxy >> might try to forward the request before triggering the push notification. >> >> But, I can either remove it, or add text clarifying that a TLS connection >> does not guarantee that the request will reach the UA. >> >>> Also a nit in this section: s/receival/receipt/ >> >> Will be fixed in the next version. >> >> Thanks! >> >> Regards, >> >> Christer >> >> >> >> >> On 12/19/17 4:07 AM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Session Initiation Protocol Core WG of >>> the IETF. >>> >>> Title : Push Notification with the Session >>> Initiation Protocol (SIP) >>> Author : Christer Holmberg >>> Filename : draft-ietf-sipcore-sip-push-01.txt >>> Pages : 13 >>> Date : 2017-12-19 >>> >>> Abstract: >>> This document describes how push notification mechanisms can be used >>> to wake up suspended Session Initiation Protocol (SIP) User Agents >>> (UAs), in order to be able to receive and generate SIP requests. >>> The >>> document defines new SIP URI parameters, that can be used in a SIP >>> REGISTER request to provide push notification information from the >>> SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in >>> this document) that will send a push request to the push server in >>> order to trigger a push notification towards the SIP UA. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-01 >>> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-01 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-01 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> 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 Dec 21 03:49:14 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2D512D833 for ; Thu, 21 Dec 2017 03:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 Zz2hl-ltXDrE for ; Thu, 21 Dec 2017 03:49:12 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 0FB2512421A for ; Thu, 21 Dec 2017 03:49:11 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id RzLZeDRHG5x03RzLbea6k6; Thu, 21 Dec 2017 11:49:11 +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 RzLaeyCNzbSXWRzLaeJ9tv; Thu, 21 Dec 2017 11:49:11 +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 vBLBn9YC001468 for ; Thu, 21 Dec 2017 06:49:09 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vBLBn9RY001465; Thu, 21 Dec 2017 06:49:09 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 21 Dec 2017 06:49:09 -0500 Message-ID: <87zi6cuwqy.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfNivKTElPR7YyZCJk+CaS4oFX82C8uHUDuo+6gOIQK2BZ0yh9NMuvhnkPVQVHa+cZtRHv9xcpWs6fHXtuIVzyR59YlFBH7TFy8+sAB8yR6BpBqSeFzmh HqEeypK5gnnl3OPCJoHuZigbtxvXYCTZaNxe31/nYNGJ3ixIL8i7X3zD Archived-At: Subject: [sipcore] Comments regarding sip-push registration 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, 21 Dec 2017 11:49:14 -0000 * Design questions - Reregistration The discussion touches on the topic of registration maintenance without discussing it thoroughly. My expectation is that once a UA obtains a registration, it will set itself a wakeup call for whatever time it wants to perform a re-registration. (For UAs I've worked on, this was 1/3 of the registration time minus epsilon, so as to protect against network instability.) It seems that the draft envisions situations where the UA *can't* set a wakeup call for a future time, and thus the proxy must wake it up using the push notification service. However, the mechanism to control this isn't made clear -- What sets the time interval for the wakeup? And surely we don't need to have this be a mandatory feature of all push-notification registrations. - Put the responsibility on the Registrar Formally, this mechanism should be described as behaviors of the registrar and its dependent redirector for AORs, that is, the UAS of the REGISTER requests. Some of the work may be delegated to intermediate proxies, but that is an implementation detail that isn't visible to the UA. Interestingly, if the proxy is willing to manipulate the registered contact URIs (details upon request), it can implement push-notification without modification of the register. (See Christer's comments and the next comment here.) OTOH, the registrar/redirector can implement the push-notification operations in an environment where the proxies are unaware of push-notification. (Details upon request.) - Header field parameters Really, the use of URI parameters for controlling push-notification registration is a Bad Idea from the design point of view. Header parameters should be used. (Note that ":" must be quoted in header parameters.) If you want to use a registrar that can't add another column to its registrations table, the proxy should manipulate the REGISTER before forwarding it to the registrar to stash the push-notification information in the contact URI. But we should design the message flow between the UA and the proxy to be as clean as we can, and allow implementors to devise clever ways to support that message flow. - Examples The examples are thin, and no responses to REGISTER messages are shown. For this example REGISTER sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: sip:alice@alicemobile.example.com; pn-type="acme:acme-param"; pn-prid="ZTY4ZDJlMzODE1NmUgKi0K" Expires: 7200 Content-Length: 0 the response would be SIP/2.0 200 OK Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 To: Alice ;tag=eksofdk From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: sip:alice@alicemobile.example.com; pn-type="acme:acme-param" Expires: 7200 Content-Length: 0 In addition, the presence of the pn-type header parameter in the response is needed to show that the proxy understands push-notification and can implement registrations using the acme:acme-param service. Otherwise, there's no way for the UA to verify that the proxy understood its need for push-notification. - Negotiation Note that the document assumes that the UA knows which push service is needed for registering with the proxy. This means that the mechanism works only if the push-notification configuration of the UA and the proxy is made to match in advance. Requiring configuration rather than implementing negotiation makes systems less likely to work. Let us define that if the pn-type is a *list* of values, then it is a request for the proxy to tell which service it supports/prefers from the list. E.g., REGISTER sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: sip:alice@alicemobile.example.com; pn-type="acme:acme-param/acme:other/-" Expires: 7200 Content-Length: 0 This is a request to the proxy to identify which push service it implements/prefers given that the UA prefers services in this order: acme:acme-param, acme:other, and no push service (identified by "-"). The server can respond SIP/2.0 200 OK Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 To: Alice ;tag=eksofdk From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ; pn-type="acme:acme-param"; expires=0 Expires: 7200 Content-Length: 0 Since the server chose acme:acme-param, and that requires a pn-prid value to implement, the server sent "expires=0" with the Contact. But the UA can then send the first REGISTER example above to obtain a registration, now that it knows what push service to register with. It seems that a use of this mechanism requires that expires is 0 -- since the UAC doesn't know which notification service the UAS will choose, it can't send the correct pn-prid, and so a push registration can't be created. This requires defining a separator character that cannot appear in a pn-type value. Which leads to: - Quoting Be careful to define the procedures based on the *values* of parameter fields, that is, the values after any quoting is removed. E.g., the effect of header parameters 'foo=bar', 'foo="bar"', and 'foo="b\ar" should be exactly the same, the (semantic) value of the parameter is the same regardless of how that value is represented. If we don't follow this rule, then it is impossible to define a generic parser for SIP headers that reduces parameters to sets of name/value pairs. - Require and option-tag It would probably also be helpful to define an option-tag for this feature, so that the UA can require the registrar to reject its REGISTER in a way that is definitive that the registrar doesn't support push registrations. Perhaps use "pn" as the option-tag. * Editorial things The capitalization of the section titles is inconsistent. When the SIP proxy receives a SIP request for a new session, or a s/session/dialog/ the SIP proxy will send a push request to the push notification service used by the SIP UA, using the push resource ID associated with the registered contact of the SIP UA, in order to trigger a push notification towards the SIP UA. The SIP proxy will then forward the SIP request towards the SIP UA using normal SIP routing procedures. Once the SIP UA receives the push notification, it will be to receive the SIP request, and to generate a SIP request (e.g., a SIP REGISTER) itself. This description is incomplete, as it leaves out the step between the first and second sentences, "the proxy waits to receive a re-registration from the UA". The other descriptions of the process for sending requests to the UA need to be checked for this as well. The abbreviation "pn-prid" is redundant, as it means "push notification - push registration id". Perhaps reduce it to "pn-rid" or "pn-id". The format of the PRID may vary depending on the PNS provider. The PRID may be part of a URI that can be used to retrieve the address and port of the PNS when sending push requests to the PNS. The PRID may also be a token value, in which case the address and port of the PNS needs to be provided using other means. It's not clear what "may be part of a URI" means, since just about any string could be part of a URI. In any case, the format of the PRID is outside the scope of this document; from our point of view, it's an opaque string. The only real restriction is that it's a sequence of Unicode characters and can be represented as a quoted-string (RFC 3261 section 25.1). If the SIP UA at some point wants to stop the SIP proxy from sending push requests, the SIP UA MUST send a SIP REGISTER request without the pn-prid and pn-type URI parameters. It should be added, "or remove the registration". If the SIP UA expects to receive payload in the push notification, the SIP UA MAY add a pn-enckey and a pn-encsec Contact header field URI parameter, in order to allow encryption of the data using the mechanism in [I-D.ietf-webpush-encryption]. The pn-enckey URI parameter contains the public key, and the pn-encsec URI parameter contains the authentication secret [I-D.ietf-webpush-encryption]. Need to mention that the format and use of such a payload is outside the scope of this document; all we're doing here is defining the parameters that make such payloads possible. In some cases the push notification provider can be retrieved from the pn-prid URI parameter. In other cases the pn-type URI parameter is used to identity the push notification provider. Exactly how you retrieve Apple Corp. from the parameters is unclear; I know of no media-type for Apple Corp. I think you mean, "Together, the pn-prid and pn-type parameters suffice to identify which push notification provider is to be used and how to direct it to notify the UA." If the proxy is not able to contact the push notification provider, or even determine which push notification provider to contact, it SHOULD reject the SIP request. This sentence conflates two situations that should be handled differently. If the redirector is unable to contact the push notification provider, it must necessarily reject the request. (Do we need to define a 4xx code to indicate that?) If the redirector is unable to determine the push notification provider, it is able to detect that during registration, and the REGISTER should have been rejected. It is currently suggested (see pull request in other e-mail) that a proxy that receives a SIP REGISTER request with pn- parameters for a PNS provider it does not support sends a 501 (Not Implemented) response code. The question is whether it would be useful to define a PNS-specific response code for this? E.g., 514 (Push Notification Service Not Supported). In addition, we could define a feature capability indicator that could be added to the response and list the PNS providers supported by the proxy. And also, I have updated the pull request by adding a new SIP response code, 555 (Push Notification Service Not Supported). Defining 514/555 like this doesn't really help, because the baseline incompatibility case is when the registrar/redirector doesn't understand the push notification mechanism at all, and happily provides an ordinary registration when the UA wanted a push-notification registration. See comments about an option-tag above. Dale From nobody Thu Dec 21 04:47:15 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC1812D85E for ; Thu, 21 Dec 2017 04:47:14 -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 Q8SfMC-hhdKF for ; Thu, 21 Dec 2017 04:47:11 -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 367A4127869 for ; Thu, 21 Dec 2017 04:47:10 -0800 (PST) X-AuditID: c1b4fb3a-335ff700000037f2-46-5a3bad4c679e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.60.14322.C4DAB3A5; Thu, 21 Dec 2017 13:47:08 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Thu, 21 Dec 2017 13:47:08 +0100 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments regarding sip-push registration Thread-Index: AQHTelG8t/VN7Cx2bUChJJKlQ6bgMqNN0naA Date: Thu, 21 Dec 2017 12:47:08 +0000 Message-ID: References: <87zi6cuwqy.fsf@hobgoblin.ariadne.com> In-Reply-To: <87zi6cuwqy.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7lq7PWusogzkXjS2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbH1/wGWgv3ZFQ96lrM2MP4O7WLk5JAQMJF4 1LSStYuRi0NI4DCjxNar99khnCWMEjMvbmTsYuTgYBOwkOj+pw3SICIQJLGpcwUziC0sYC/x 8Mo0NpASEQEHiUtXeCFKjCR+nOpgAQmzCKhKLH+gABLmFbCWWP30KzuILQRUMuX/UzYQm1PA WOJtyzdWEJtRQEzi+6k1TCA2s4C4xK0n85kgzhSQWLLnPDOELSrx8vE/sHpRAT2JDSdus0PE lSR+bLjEAtGrJ3Fj6hQ2CNtaYsav6VC2tsSyha+ZIe4RlDg58wnLBEaxWUjWzULSPgtJ+ywk 7bOQtC9gZF3FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERhRB7f8ttrBePC54yFGAQ5GJR5e m8XWUUKsiWXFlbmHGCU4mJVEeA8vAQrxpiRWVqUW5ccXleakFh9ilOZgURLndUqziBISSE8s Sc1OTS1ILYLJMnFwSjUwMonOsZdXfPXwvIGOkbJf0lS3wNDIqbWMwvdfFFuWrTJdGGVisaXs +rXTilsPXFgxw/QAA393gKig5fKtxet0w7Mij6bl6Jw3l/c6JXhW7/ZWw7zNOypNJjG9WF5h eX/L2RdXdmk+tlSaNscofMb0RwaHExISZIWXTbXY5c/l7Hnbsv5VWV6dEktxRqKhFnNRcSIA efGOQaQCAAA= Archived-At: Subject: Re: [sipcore] Comments regarding sip-push registration 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, 21 Dec 2017 12:47:14 -0000 Hi, >* Design questions > >- Reregistration > >The discussion touches on the topic of registration maintenance >without discussing it thoroughly. My expectation is that once a UA >obtains a registration, it will set itself a wakeup call for whatever >time it wants to perform a re-registration. (For UAs I've worked on, >this was 1/3 of the registration time minus epsilon, so as to protect >against network instability.) > >It seems that the draft envisions situations where the UA *can't* set >a wakeup call for a future time, and thus the proxy must wake it up >using the push notification service. However, the mechanism to >control this isn't made clear -- What sets the time interval for the >wakeup? And surely we don't need to have this be a mandatory feature >of all push-notification registrations. The interval will be based on the registration expiration. And, similar to the UA wakeup behaviour you mention, the push notification should be triggered prior to the actual registration expiration. >- Put the responsibility on the Registrar > >Formally, this mechanism should be described as behaviors of the >registrar and its dependent redirector for AORs, that is, the UAS of >the REGISTER requests. Some of the work may be delegated to >intermediate proxies, but that is an implementation detail that isn't >visible to the UA. > >Interestingly, if the proxy is willing to manipulate the registered >contact URIs (details upon request), it can implement >push-notification without modification of the register. (See >Christer's comments and the next comment here.) > >OTOH, the registrar/redirector can implement the push-notification >operations in an environment where the proxies are unaware of >push-notification. (Details upon request.) The mechanism does not have to be part of the registrar. It for sure can be. >- Header field parameters > >Really, the use of URI parameters for controlling push-notification >registration is a Bad Idea from the design point of view. Header >parameters should be used. (Note that ":" must be quoted in header >parameters.) > >If you want to use a registrar that can't add another column to its >registrations table, the proxy should manipulate the REGISTER before >forwarding it to the registrar to stash the push-notification >information in the contact URI. But we should design the message flow >between the UA and the proxy to be as clean as we can, and allow >implementors to devise clever ways to support that message flow. The usage of URI parameters will make the deployment easier as it does not mandate updating the registrars (unless the push notification triggering will be done by the registrar, of course). Also, unlike some of the proprietary ideas I have seen, it does not mandate intermediaries to modify the REGISTER and/or the contact, etc. In some environments =B3adding another table=B2 can be a very big task. As the schedule for deploying this is very tight in many cases, there is a strong wish from the industry to be able to deploy this without having to update the registrar. >- Examples > >The examples are thin, and no responses to REGISTER messages are >shown. For this example > > REGISTER sip:alice@example.com SIP/2.0 > Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=3Dz9hG4bKnashds7 > Max-Forwards: 70 > To: Alice > From: Alice ;tag=3D456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: sip:alice@alicemobile.example.com; > pn-type=3D"acme:acme-param"; > pn-prid=3D"ZTY4ZDJlMzODE1NmUgKi0K" > Expires: 7200 > Content-Length: 0 > >the response would be > > SIP/2.0 200 OK > Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=3Dz9hG4bKnashds7 > To: Alice ;tag=3Deksofdk > From: Alice ;tag=3D456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: sip:alice@alicemobile.example.com; > pn-type=3D"acme:acme-param" > Expires: 7200 > Content-Length: 0 > >In addition, the presence of the pn-type header parameter in the >response is needed to show that the proxy understands >push-notification and can implement registrations using the >acme:acme-param service. Otherwise, there's no way for the UA to >verify that the proxy understood its need for push-notification. In the latest pull request, a feature-capability indicator is defined for this. The proxy will insert that in the REGISTER 200 OK response, in order to inform the SIP UA that push-notification is supported. >- Negotiation > >Note that the document assumes that the UA knows which push service is >needed for registering with the proxy. This means that the mechanism >works only if the push-notification configuration of the UA and the >proxy is made to match in advance. Requiring configuration rather >than implementing negotiation makes systems less likely to work. > >Let us define that if the pn-type is a *list* of values, then it is a >request for the proxy to tell which service it supports/prefers from >the list. E.g., > > REGISTER sip:alice@example.com SIP/2.0 > Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=3Dz9hG4bKnashds7 > Max-Forwards: 70 > To: Alice > From: Alice ;tag=3D456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: sip:alice@alicemobile.example.com; > pn-type=3D"acme:acme-param/acme:other/-" > Expires: 7200 > Content-Length: 0 > >This is a request to the proxy to identify which push service it >implements/prefers given that the UA prefers services in this order: >acme:acme-param, acme:other, and no push service (identified by "-"). >The server can respond > > SIP/2.0 200 OK > Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=3Dz9hG4bKnashds7 > To: Alice ;tag=3Deksofdk > From: Alice ;tag=3D456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: ; > pn-type=3D"acme:acme-param"; > expires=3D0 > Expires: 7200 > Content-Length: 0 > >Since the server chose acme:acme-param, and that requires a pn-prid >value to implement, the server sent "expires=3D0" with the Contact. But >the UA can then send the first REGISTER example above to obtain a >registration, now that it knows what push service to register with. > >It seems that a use of this mechanism requires that expires is 0 -- >since the UAC doesn't know which notification service the UAS will >choose, it can't send the correct pn-prid, and so a push registration >can't be created. > >This requires defining a separator character that cannot appear in a >pn-type value. Which leads to: > >- Quoting > >Be careful to define the procedures based on the *values* of parameter >fields, that is, the values after any quoting is removed. E.g., the >effect of header parameters 'foo=3Dbar', 'foo=3D"bar"', and 'foo=3D"b\ar" >should be exactly the same, the (semantic) value of the parameter is >the same regardless of how that value is represented. If we don't >follow this rule, then it is impossible to define a generic parser for >SIP headers that reduces parameters to sets of name/value pairs. It was requested to use separate parameters, to be able to avoid separators, and to minimise the need to potentially have to escape characters. And, in reality, clients will only support one push notification mechanism (and it will be part of the OS). One of the main reasons for using push to begin with is having to maintain only a single connection (the connection between the device and the push notification server), in order to save battery etc. Having said that, the feature-capability indicator (defined in the pull request) can be used to negotiate and query the network, should there be a need for that. >- Require and option-tag > >It would probably also be helpful to define an option-tag for this >feature, so that the UA can require the registrar to reject its >REGISTER in a way that is definitive that the registrar doesn't >support push registrations. Perhaps use "pn" as the option-tag. If there push notifications are handled by an intermediary, there is no need to mandate support in the registrar. I will look at and address your editorial comments later. Regards, Christer >* Editorial things > >The capitalization of the section titles is inconsistent. > > When the SIP proxy receives a SIP request for a new session, or a > >s/session/dialog/ > > the SIP proxy will send a push request to the push notification > service used by the SIP UA, using the push resource ID associated > with the registered contact of the SIP UA, in order to trigger a push > notification towards the SIP UA. The SIP proxy will then forward the > SIP request towards the SIP UA using normal SIP routing procedures. > Once the SIP UA receives the push notification, it will be to receive > the SIP request, and to generate a SIP request (e.g., a SIP REGISTER) > itself. > >This description is incomplete, as it leaves out the step between the >first and second sentences, "the proxy waits to receive a >re-registration from the UA". The other descriptions of the process >for sending requests to the UA need to be checked for this as well. > >The abbreviation "pn-prid" is redundant, as it means "push >notification - push registration id". Perhaps reduce it to "pn-rid" >or "pn-id". > > The format of the PRID may vary depending on the PNS provider. The > PRID may be part of a URI that can be used to retrieve the address > and port of the PNS when sending push requests to the PNS. The PRID > may also be a token value, in which case the address and port of the > PNS needs to be provided using other means. > >It's not clear what "may be part of a URI" means, since just about any >string could be part of a URI. In any case, the format of the PRID is >outside the scope of this document; from our point of view, it's an >opaque string. The only real restriction is that it's a sequence of >Unicode characters and can be represented as a quoted-string (RFC 3261 >section 25.1). > > If the SIP UA at some point wants to stop the SIP proxy from sending > push requests, the SIP UA MUST send a SIP REGISTER request without > the pn-prid and pn-type URI parameters. > >It should be added, "or remove the registration". > > If the SIP UA expects to receive payload in the push notification, > the SIP UA MAY add a pn-enckey and a pn-encsec Contact header field > URI parameter, in order to allow encryption of the data using the > mechanism in [I-D.ietf-webpush-encryption]. The pn-enckey URI > parameter contains the public key, and the pn-encsec URI parameter > contains the authentication secret [I-D.ietf-webpush-encryption]. > >Need to mention that the format and use of such a payload is outside >the scope of this document; all we're doing here is defining the >parameters that make such payloads possible. > > In some cases the push notification provider can be retrieved from > the pn-prid URI parameter. In other cases the pn-type URI parameter > is used to identity the push notification provider. > >Exactly how you retrieve Apple Corp. from the parameters is unclear; I >know of no media-type for Apple Corp. > >I think you mean, "Together, the pn-prid and pn-type parameters >suffice to identify which push notification provider is to be used and >how to direct it to notify the UA." > > If the proxy is not able to contact the push notification provider, > or even determine which push notification provider to contact, it > SHOULD reject the SIP request. > >This sentence conflates two situations that should be handled >differently. If the redirector is unable to contact the push >notification provider, it must necessarily reject the request. (Do we >need to define a 4xx code to indicate that?) If the redirector is >unable to determine the push notification provider, it is able to >detect that during registration, and the REGISTER should have been >rejected. > > It is currently suggested (see pull request in other e-mail) that > a proxy that receives a SIP REGISTER request with pn- parameters > for a PNS provider it does not support sends a 501 (Not > Implemented) response code. > > The question is whether it would be useful to define a > PNS-specific response code for this? E.g., 514 (Push Notification > Service Not Supported). In addition, we could define a feature > capability indicator that could be added to the response and list > the PNS providers supported by the proxy. > >And also, > > I have updated the pull request by adding a new SIP response code, > 555 (Push Notification Service Not Supported). > >Defining 514/555 like this doesn't really help, because the baseline >incompatibility case is when the registrar/redirector doesn't >understand the push notification mechanism at all, and happily >provides an ordinary registration when the UA wanted a >push-notification registration. See comments about an option-tag >above. > >Dale > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Dec 21 05:45:00 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C429E120725; Thu, 21 Dec 2017 05:44:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151386389876.12757.13783547539087083504@ietfa.amsl.com> Date: Thu, 21 Dec 2017 05:44:58 -0800 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 13:44:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Push Notification with the Session Initiation Protocol (SIP) Author : Christer Holmberg Filename : draft-ietf-sipcore-sip-push-02.txt Pages : 14 Date : 2017-12-21 Abstract: This document describes how push notification mechanisms can be used to wake up suspended Session Initiation Protocol (SIP) User Agents (UAs), in order to be able to receive and generate SIP requests. The document defines new SIP URI parameters, that can be used in a SIP REGISTER request to provide push notification information from the SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in this document) that will send a push request to the push server in order to trigger a push notification towards the SIP UA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-02 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 21 05: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 9966A12D86E for ; Thu, 21 Dec 2017 05:46:29 -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 nic3jawYlVlb for ; Thu, 21 Dec 2017 05:46:28 -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 ADA02120725 for ; Thu, 21 Dec 2017 05:46:27 -0800 (PST) X-AuditID: c1b4fb2d-b35ff70000007932-cd-5a3bbb31e2f7 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7F.50.31026.13BBB3A5; Thu, 21 Dec 2017 14:46:26 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Thu, 21 Dec 2017 14:46:25 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: SIP Push -02 Thread-Index: AQHTemIX9iLDK5rnNESqgeXDl7dhrQ== Date: Thu, 21 Dec 2017 13:46:25 +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.20] Content-Type: multipart/alternative; boundary="_000_D6618A1928111christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7ja7Rbusogy5Fi68/NrE5MHosWfKT KYAxissmJTUnsyy1SN8ugSvj1N5HLAVdXBUv3s1ha2B8wNHFyMkhIWAise7jGuYuRi4OIYHD jBI3LvdAOUsYJfbfX8zUxcjBwSZgIdH9TxukQURAU2L5t63sILawgIZE49IWVoi4rsS1o79Z IGw9idlLGsFsFgFViYnXrrCB2LwC1hKffp5iBLEZBcQkvp9awwRiMwuIS9x6Mp8J4iABiSV7 zjND2KISLx//A5svCjRzw4nb7BBxRYmr05dD9SZIzJv6ixVivqDEyZlPWCYwCs1CMnYWkrJZ SMog4gYS78/NZ4awtSWWLXwNZetLbPxylhHCtpb4MK+TEVnNAkaOVYyixanFxbnpRsZ6qUWZ ycXF+Xl6eaklmxiBkXJwy2/dHYyrXzseYhTgYFTi4c3eZR0lxJpYVlyZe4hRgoNZSYT38BKg EG9KYmVValF+fFFpTmrxIUZpDhYlcd6TnrxRQgLpiSWp2ampBalFMFkmDk6pBkavv95/s2uM hEKnK1zbaDdXjcvuVaFxPOPsL1zGWrui9kmLp332W/Wjxymb8feaCwF5a9u5X+az/dlcujXQ b/fkTzV/mzWq9NQyGCWcD0zWz9r/Ie2RXEzrNu6ltrsl/vd28/BwKWm1iB2W/2KSsIhNaX22 9pEHn3gV+mSUL2yz/HCmw/7ffyWW4oxEQy3mouJEAEheGGaQAgAA Archived-At: Subject: [sipcore] Draft new version: SIP Push -02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 13:46:29 -0000 --_000_D6618A1928111christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-03) of draft-sip-push. The new version defines a feature-capability indicator, which can be used t= o indicate the PNS(s) supported by the SIP proxy. Regards, Christer --_000_D6618A1928111christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    Hi,

    I=92ve submitted a new version  (-03) of draft-sip-push.

    The new version defines a feature-capability indicator, which can be u= sed to indicate the PNS(s) supported by the SIP proxy.

    Regards,

    Christer
    --_000_D6618A1928111christerholmbergericssoncom_-- From nobody Thu Dec 21 06:40: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 5EBF4124D68 for ; Thu, 21 Dec 2017 06:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tVxtL5X1nxwP for ; Thu, 21 Dec 2017 06:40:09 -0800 (PST) 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 E45A012D87B for ; Thu, 21 Dec 2017 06:40:01 -0800 (PST) X-AuditID: 1207440e-bf9ff70000007085-66-5a3bc7ae2a0d 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 87.1B.28805.EA7CB3A5; Thu, 21 Dec 2017 09:39:42 -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 vBLEdep9005255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 21 Dec 2017 09:39:41 -0500 To: sipcore@ietf.org References: <87zi6cuwqy.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Thu, 21 Dec 2017 09:39:40 -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+NgFvrKIsWRmVeSWpSXmKPExsUixO6iqLv+uHWUweVtwhZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpdzW5kLHvNUHFiwg7WBcQ5XFyMnh4SAicTXGdNYuxi5OIQE djBJ3Ju1mAnC+cEksWzWbUaQKmEBe4mHV6axgdgiAiISz6b/A7OFBFIk/l/qYwGx2QS0JOYc +g9m8wLVb5jyAKyXRUBV4snEXewgtqhAmsSeCx1QNYISJ2c+AbM5BWwkjm7/AFbDLGAmMW/z Q2YIW1zi1pP5TBC2vETz1tnMExj5ZyFpn4WkZRaSlllIWhYwsqxilEvMKc3VzU3MzClOTdYt Tk7My0st0jXWy80s0UtNKd3ECAlLvh2M7etlDjEKcDAq8fBy7LGOEmJNLCuuzD3EKMnBpCTK e2YeUIgvKT+lMiOxOCO+qDQntfgQowQHs5II7+ElQDnelMTKqtSifJiUNAeLkjiv2hJ1PyGB 9MSS1OzU1ILUIpisDAeHkgSv3DGgRsGi1PTUirTMnBKENBMHJ8hwHqDhF0BqeIsLEnOLM9Mh 8qcYjTl6em78YeJ4NvN1A7MQS15+XqqUOO/xo0ClAiClGaV5cNNgqeUVozjQc8K8ziADeYBp CW7eK6BVTECrpgeBrSpJREhJNTBGPPoQH5z4aaK62776Zfuqiv6umhv39E/ZJ0MNtmydPWcm Mjp7P+KVSF6hrP5/1r/Iy5OKPLTXJyjdZ7tzhV3BwX7u142PnkU4z2qcvGnBnhzjPReNJYtL Lacw1X57oizrxMn9NEi0/vtcB/MvIfwd+Wz3753g7wu+9torLT6B5fCaUMF5Kw4psRRnJBpq MRcVJwIAOJDt8ggDAAA= Archived-At: Subject: Re: [sipcore] Comments regarding sip-push registration 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, 21 Dec 2017 14:40:11 -0000 On 12/21/17 7:47 AM, Christer Holmberg wrote: >> - Header field parameters >> >> Really, the use of URI parameters for controlling push-notification >> registration is a Bad Idea from the design point of view. Header >> parameters should be used. (Note that ":" must be quoted in header >> parameters.) >> >> If you want to use a registrar that can't add another column to its >> registrations table, the proxy should manipulate the REGISTER before >> forwarding it to the registrar to stash the push-notification >> information in the contact URI. But we should design the message flow >> between the UA and the proxy to be as clean as we can, and allow >> implementors to devise clever ways to support that message flow. > > The usage of URI parameters will make the deployment easier as it does not > mandate updating the registrars (unless the push notification triggering > will be done by the registrar, of course). Also, unlike some of the > proprietary ideas I have seen, it does not mandate intermediaries to > modify the REGISTER and/or the contact, etc. > > In some environments ³adding another table² can be a very big task. > > As the schedule for deploying this is very tight in many cases, there is a > strong wish from the industry to be able to deploy this without having to > update the registrar. Why does using header field parameters rather than uri parameters impact the choice of proxy or registrar to implement this feature? The proxy can observe header field parameters, and a registrar will ignore header field parameters it doesn't understand. Thanks, Paul From nobody Thu Dec 21 07:07: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 6F10912D889 for ; Thu, 21 Dec 2017 07:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ZERUcmxXWwsP for ; Thu, 21 Dec 2017 07:07:50 -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 01AB512D885 for ; Thu, 21 Dec 2017 07:07:49 -0800 (PST) X-AuditID: 1207440d-86bff70000000f42-61-5a3bce330ddc 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 BF.0B.03906.33ECB3A5; Thu, 21 Dec 2017 10:07:32 -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 vBLF7URs006656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 21 Dec 2017 10:07:30 -0500 To: sipcore@ietf.org References: <151386389876.12757.13783547539087083504@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <0e2f65ea-c74e-e6ce-7b09-43ff4d60577c@alum.mit.edu> Date: Thu, 21 Dec 2017 10:07:30 -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: <151386389876.12757.13783547539087083504@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixO6iqGtyzjrKoGOBhsXXH5vYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXzicbaCVpmKf+u2MzYw3hLpYuTgkBAwkdi/Mb6LkYtDSGAH k8SdfRNYIZwfTBKb7kxi62Lk5BAWcJX49uUVM4gtIiAi8Wz6PzaQZiEBF4mmp3wgYTYBLYk5 h/6zgIR5Bewl9qzPAQmzCKhK/Fq8ngnEFhVIk9hzoYMFxOYVEJQ4OfMJmM0JNP3Hl01gNcwC ZhLzNj9khrDFJW49mQ8Vl5fY/nYO8wRG/llI2mchaZmFpGUWkpYFjCyrGOUSc0pzdXMTM3OK U5N1i5MT8/JSi3SN9HIzS/RSU0o3MUICkncH4/91MocYBTgYlXh4OfZYRwmxJpYVV+YeYpTk YFIS5T0zDyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPfwEqAcb0piZVVqUT5MSpqDRUmcV22J up+QQHpiSWp2ampBahFMVoaDQ0mCN+ssUKNgUWp6akVaZk4JQpqJgxNkOA/QcC2QGt7igsTc 4sx0iPwpRmOOnp4bf5g4ns183cAsxJKXn5cqJc4rD1IqAFKaUZoHNw2WVF4xigM9J8wbBVLF A0xIcPNeAa1iAlo1PQhsVUkiQkqqgVEx069PPsGyeeuF5Efyb340yZ5fzfdWuO7sC63I03yr Z/1Sto5ZOoWv6xvHSrG5DE3fOPRy/jbnPVvJXvdw6ar0BectH3scNz30f0LrzVuRS/cc+zD5 frT/78iuRXGFriKsrtWRv3exzihacbJIapV4Q0fpRt5nhlE11m57Zrav4OLJFNy/Q0mJpTgj 0VCLuag4EQCnwXulBQMAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-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, 21 Dec 2017 15:07:52 -0000 Christer, I just looked more closely at the ABNF for the indicator. It has some problems. sip.pns = "<" pns-list ">" pns-list = pns *(COMMA pns) pns = pvalue ; pvalue as defined in RFC 3261 First, 'sip.pns' isn't a valid rulename. I presume you simply mean that the name of this feature-capability indicator is "sip.pns", or "pns" in the "sip" tree. This would be taken care of if you filled in a registration template as specified in rfc6809. I can find no such template. Next, according to rfc3840 the syntax of a feature param is: feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list / string-value ) RDQUOT] ... tag-value-list = tag-value *("," tag-value) tag-value = ["!"] (token-nobang / boolean / numeric) token-nobang = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) boolean = "TRUE" / "FALSE" numeric = "#" numeric-relation number numeric-relation = ">=" / "<=" / "=" / (number ":") number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">" qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D / %x3F-5B / %x5D-7E / UTF8-NONASCII Notably, the value of the feature-param is always enclosed in double quotes. Also, I think your use of "<" and ">" means that you intend this to be a string-value with a particular syntax, but possibly the tag-value-list syntax would work for you. Thanks, Paul On 12/21/17 8:44 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core WG of the IETF. > > Title : Push Notification with the Session Initiation Protocol (SIP) > Author : Christer Holmberg > Filename : draft-ietf-sipcore-sip-push-02.txt > Pages : 14 > Date : 2017-12-21 > > Abstract: > This document describes how push notification mechanisms can be used > to wake up suspended Session Initiation Protocol (SIP) User Agents > (UAs), in order to be able to receive and generate SIP requests. The > document defines new SIP URI parameters, that can be used in a SIP > REGISTER request to provide push notification information from the > SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in > this document) that will send a push request to the push server in > order to trigger a push notification towards the SIP UA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-02 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Dec 21 07:27: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 33CB912D93E for ; Thu, 21 Dec 2017 07:27:08 -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 64Cq2wAJ2TrS for ; Thu, 21 Dec 2017 07:27: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 A3A2312D890 for ; Thu, 21 Dec 2017 07:26:53 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-a7-5a3bd2bbb4bd Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E5.0F.14322.BB2DB3A5; Thu, 21 Dec 2017 16:26:51 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Thu, 21 Dec 2017 16:26:50 +0100 From: Christer Holmberg To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-02.txt Thread-Index: AQHTem18W6DHQaFzL0WVrPaHP1V/AaNN62Mw Date: Thu, 21 Dec 2017 15:26:50 +0000 Message-ID: <77A587A9-0193-4889-932C-E911C1DB0783@ericsson.com> References: <151386389876.12757.13783547539087083504@ietfa.amsl.com>, <0e2f65ea-c74e-e6ce-7b09-43ff4d60577c@alum.mit.edu> In-Reply-To: <0e2f65ea-c74e-e6ce-7b09-43ff4d60577c@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_77A587A901934889932CE911C1DB0783ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdRXf3JesogynvRS1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj/V+/gslZFet3HWdtYGyL6WLk5JAQMJE4 +/kmO4gtJHCYUaJ1cX0XIxeQvYRR4uv0E4xdjBwcbAIWEt3/tEFMEQENiUlb1UDKmQU0JR7t 3MsEYgsLuEp8+/KKGcQWEXCT2HftEpRtJPF47RGwKSwCqhJXD+aAhHkF7CU+dU5jgthaIXFr C0Q5p4CDRMvkz2DXMAqISXw/tYYJYpW4xK0n85kgLhaQWLLnPDOELSrx8vE/VoiaZInOX5uZ IOYLSpyc+YRlAqPwLCTts5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2Vcxihan FhfnphsZ6aUWZSYXF+fn6eWllmxiBMbNwS2/rXYwHnzueIhRgINRiYf33nnrKCHWxLLiytxD jBIczEoivIeXAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOqVZRAkJpCeWpGanphakFsFkmTg4 pRoY63bPCfmW73BXsbb1SE65hfL+jR5hb+dzFB2fXL3ok3rvXtGnuUmnBLLY8uutyjfv0te2 V9jQ+Evp12fH/c5rOjj7Vxjc0OxX49olVdrB8/nu4ulbJI4kndXi2/XQWYjnQKdAkZVa68ul wk/UfmZKSmtyel2Mag17ztWYKZU/VUaN9eBMw2olluKMREMt5qLiRACO6QhWlwIAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-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, 21 Dec 2017 15:27:08 -0000 --_000_77A587A901934889932CE911C1DB0783ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, I will double check the syntax. Regards, Christer Sent from my iPhone On 21 Dec 2017, at 17.07, Paul Kyzivat > wrote: Christer, I just looked more closely at the ABNF for the indicator. It has some probl= ems. sip.pns =3D "<" pns-list ">" pns-list =3D pns *(COMMA pns) pns =3D pvalue ; pvalue as defined in RFC 3261 First, 'sip.pns' isn't a valid rulename. I presume you simply mean that the= name of this feature-capability indicator is "sip.pns", or "pns" in the "s= ip" tree. This would be taken care of if you filled in a registration templ= ate as specified in rfc6809. I can find no such template. Next, according to rfc3840 the syntax of a feature param is: feature-param =3D enc-feature-tag [EQUAL LDQUOT (tag-value-list / string-value ) RDQUOT] ... tag-value-list =3D tag-value *("," tag-value) tag-value =3D ["!"] (token-nobang / boolean / numeric) token-nobang =3D 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) boolean =3D "TRUE" / "FALSE" numeric =3D "#" numeric-relation number numeric-relation =3D ">=3D" / "<=3D" / "=3D" / (number ":") number =3D [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] string-value =3D "<" *(qdtext-no-abkt / quoted-pair ) ">" qdtext-no-abkt =3D LWS / %x21 / %x23-3B / %x3D / %x3F-5B / %x5D-7E / UTF8-NONASCII Notably, the value of the feature-param is always enclosed in double quotes= . Also, I think your use of "<" and ">" means that you intend this to be a = string-value with a particular syntax, but possibly the tag-value-list synt= ax would work for you. Thanks, Paul On 12/21/17 8:44 AM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core WG of the= IETF. Title : Push Notification with the Session Initiation Pro= tocol (SIP) Author : Christer Holmberg Filename : draft-ietf-sipcore-sip-push-02.txt Pages : 14 Date : 2017-12-21 Abstract: This document describes how push notification mechanisms can be used to wake up suspended Session Initiation Protocol (SIP) User Agents (UAs), in order to be able to receive and generate SIP requests. The document defines new SIP URI parameters, that can be used in a SIP REGISTER request to provide push notification information from the SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in this document) that will send a push request to the push server in order to trigger a push notification towards the SIP UA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-02 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-push-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_77A587A901934889932CE911C1DB0783ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul,

    I will double check the syntax.

    Regards,

    Christer 

    Sent from my iPhone

    On 21 Dec 2017, at 17.07, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

    Christer,

    I just looked more closely at the ABNF for the indicator. It has some= problems.

        sip.pns       &= nbsp; =3D "<" pns-list ">"
        pns-list       =  =3D pns *(COMMA pns)
        pns        = ;     =3D pvalue

        ; pvalue as defined in RFC 3261

    First, 'sip.pns' isn't a valid rulename. I presume you simply mean th= at the name of this feature-capability indicator is "sip.pns", or= "pns" in the "sip" tree. This would be taken care of i= f you filled in a registration template as specified in rfc6809. I can find no such template.

    Next, according to rfc3840 the syntax of a feature param is:
      feature-param    =3D  enc-feature-tag= [EQUAL LDQUOT (tag-value-list
               &nb= sp;          / string-val= ue ) RDQUOT]
    ...
      tag-value-list  =3D  tag-value *("," = tag-value)
      tag-value       =3D  [= "!"] (token-nobang / boolean / numeric)
      token-nobang    =3D  1*(alphanum / &q= uot;-" / "." / "%" / "*"
               &nb= sp;         / "_" / = "+" / "`" / "'" / "~" )<= br>   boolean         = =3D  "TRUE" / "FALSE"
      numeric         = =3D  "#" numeric-relation number
      numeric-relation  =3D  ">=3D" / &q= uot;<=3D" / "=3D" / (number ":")
      number         &n= bsp;=3D  [ "+" / "-" ] 1*DIGIT ["." = 0*DIGIT]
      string-value    =3D  "<"= *(qdtext-no-abkt / quoted-pair ) ">"
      qdtext-no-abkt  =3D  LWS / %x21 / %x23-3B / %x3= D
               &nb= sp;            =   / %x3F-5B / %x5D-7E / UTF8-NONASCII

    Notably, the value of the feature-param is always enclosed in double = quotes. Also, I think your use of "<" and ">" mea= ns that you intend this to be a string-value with a particular syntax, but = possibly the tag-value-list syntax would work for you.

       Thanks,
       Paul


    On 12/21/17 8:44 AM, inte= rnet-drafts@ietf.org wrote:
    A New Internet-Draft is available from the = on-line Internet-Drafts directories.
    This draft is a work item of the Session In= itiation Protocol Core WG of the IETF.
           &= nbsp;Title           : Pu= sh Notification with the Session Initiation Protocol (SIP)
           &= nbsp;Author          : Christe= r Holmberg
       Filename    &nb= sp;   : draft-ietf-sipcore-sip-push-02.txt
       Pages     =       : 14
       Date     &= nbsp;      : 2017-12-21
    Abstract:
       This document describes h= ow push notification mechanisms can be used
       to wake up suspended Sess= ion Initiation Protocol (SIP) User Agents
       (UAs), in order to be abl= e to receive and generate SIP requests.  The
       document defines new SIP = URI parameters, that can be used in a SIP
       REGISTER request to provi= de push notification information from the
       SIP User Agent (UA) to th= e SIP entity (realized as a SIP proxy in
       this document) that will = send a push request to the push server in
       order to trigger a push n= otification towards the SIP UA.
    The IETF datatracker status page for this d= raft is:
    https://datatracker.ietf.org/doc/draft-ietf-= sipcore-sip-push/
    There are also htmlized versions available = at:
    https://tools.ietf.org/html/draft-ietf-sipcore-= sip-push-02
    https://datatracker.ietf.org/doc/html= /draft-ietf-sipcore-sip-push-02
    A diff from the previous version is availab= le at:
    https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-sipcore-sip-push-02
    Please note that it may take a couple of mi= nutes from the time of submission
    until the htmlized version and diff are ava= ilable at tools.ietf.org.
    Internet-Drafts are also available by anony= mous FTP at:
    ftp://ftp.ietf.org/internet-drafts/
    ___________________________________________= ____
    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
    --_000_77A587A901934889932CE911C1DB0783ericssoncom_-- From nobody Thu Dec 21 07:33: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 3407012D889 for ; Thu, 21 Dec 2017 07:33:58 -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 zDxbj29uYITQ for ; Thu, 21 Dec 2017 07:33:55 -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 3006D124D85 for ; Thu, 21 Dec 2017 07:33:54 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-ba-5a3bd460c874 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 00.40.14322.064DB3A5; Thu, 21 Dec 2017 16:33:53 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Thu, 21 Dec 2017 16:33:52 +0100 From: Christer Holmberg To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Comments regarding sip-push registration Thread-Index: AQHTelG8t/VN7Cx2bUChJJKlQ6bgMqNN0naA///7MwCAAB/oFw== Date: Thu, 21 Dec 2017 15:33:51 +0000 Message-ID: References: <87zi6cuwqy.fsf@hobgoblin.ariadne.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F58C1D167BC94BD6BDD3516F67AAA5FBericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdVzfxinWUweVudosVGw6wWnz9sYnN gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4ueMbY8E824rn13UbGLeadDFycEgImEi0 3QnrYuTiEBI4zCgx5dZfFghnCaPE+UPvWECK2AQsJLr/aYOYIgIaEpO2qnUxcnIwC2hKPNq5 lwnEFhawl3h4ZRobRImDxKUrvCBhEQEniYvbtrCDhFkEVCVW9+uAhHmBqp+cucUIYgsJzGCU mL4vBMTmBOpcveoW2ERGATGJ76fWMEFsEpe49WQ+mC0hICCxZM95ZghbVOLl43+sEDXJEhNW d7BDzBeUODnzCcsERuFZSNpnISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKv YhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMmoNbflvtYDz43PEQowAHoxIP773z1lFCrIll xZW5hxglOJiVRHgPLwEK8aYkVlalFuXHF5XmpBYfYpTmYFES53VKs4gSEkhPLEnNTk0tSC2C yTJxcEo1MCqa/tgS43BJevPGXLYjCyZdmrSn/TO78ry/NYrLVRy/sM7NWaN2ZC+37Mvyn//L 1jAfcJk7V/4Dh/EJuzMRe3U8NmV3hoUc2vxi2sWLS7f0TI8Xvq8YeNk2vcBxZeS9C1qPl042 u1/Gx1rmNueJ5Lw3Ty1DLk15x6a368DGb47uEzTWhTJmGVcpsRRnJBpqMRcVJwIAQf1BgJYC AAA= Archived-At: Subject: Re: [sipcore] Comments regarding sip-push registration 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, 21 Dec 2017 15:33:58 -0000 --_000_F58C1D167BC94BD6BDD3516F67AAA5FBericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, Maybe I was unclear and/or I misunderstood your question. I did not mean to= say that it would impact the choice. Using URI parameters in the REGISTER request, they will automatically be co= pied into the INVITE request using normal SIP registrar procedures. There i= s no need to update the registrar, or having intermediaries modifying the R= EGISTER, contact etc. Using header parameters, you would need to update the SIP registrar to inse= rt them in the INVITE request. Regards, Christer Sent from my iPhone On 21 Dec 2017, at 16.40, Paul Kyzivat > wrote: On 12/21/17 7:47 AM, Christer Holmberg wrote: - Header field parameters Really, the use of URI parameters for controlling push-notification registration is a Bad Idea from the design point of view. Header parameters should be used. (Note that ":" must be quoted in header parameters.) If you want to use a registrar that can't add another column to its registrations table, the proxy should manipulate the REGISTER before forwarding it to the registrar to stash the push-notification information in the contact URI. But we should design the message flow between the UA and the proxy to be as clean as we can, and allow implementors to devise clever ways to support that message flow. The usage of URI parameters will make the deployment easier as it does not mandate updating the registrars (unless the push notification triggering will be done by the registrar, of course). Also, unlike some of the proprietary ideas I have seen, it does not mandate intermediaries to modify the REGISTER and/or the contact, etc. In some environments =B3adding another table=B2 can be a very big task. As the schedule for deploying this is very tight in many cases, there is a strong wish from the industry to be able to deploy this without having to update the registrar. Why does using header field parameters rather than uri parameters impact th= e choice of proxy or registrar to implement this feature? The proxy can obs= erve header field parameters, and a registrar will ignore header field para= meters it doesn't understand. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_F58C1D167BC94BD6BDD3516F67AAA5FBericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul,

    Maybe I was unclear and/or I misunderstood your question. I did not me= an to say that it would impact the choice.

    Using URI parameters in the REGISTER request, they will automatically = be copied into the INVITE request using normal SIP registrar procedures. Th= ere is no need to update the registrar, or having intermediaries modifying = the REGISTER, contact etc.

    Using header parameters, you would need to update the SIP registrar to= insert them in the INVITE request.

    Regards,

    Christer 

    Sent from my iPhone

    On 21 Dec 2017, at 16.40, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

    On 12/21/17 7:47 AM, Christer Holmberg wrote:

    - Header field parameters

    Really, the use of URI parameters for contr= olling push-notification
    registration is a Bad Idea from the design = point of view.  Header
    parameters should be used.  (Note that= ":" must be quoted in header
    parameters.)

    If you want to use a registrar that can't a= dd another column to its
    registrations table, the proxy should manip= ulate the REGISTER before
    forwarding it to the registrar to stash the= push-notification
    information in the contact URI.  But w= e should design the message flow
    between the UA and the proxy to be as clean= as we can, and allow
    implementors to devise clever ways to suppo= rt that message flow.
    The usage of URI parameters will make the d= eployment easier as it does not
    mandate updating the registrars (unless the= push notification triggering
    will be done by the registrar, of course). = Also, unlike some of the
    proprietary ideas I have seen, it does not = mandate intermediaries to
    modify the REGISTER and/or the contact, etc= .
    In some environments =B3adding another tabl= e=B2 can be a very big task.
    As the schedule for deploying this is very = tight in many cases, there is a
    strong wish from the industry to be able to= deploy this without having to
    update the registrar.

    Why does using header field parameters rather than uri parameters imp= act the choice of proxy or registrar to implement this feature? The proxy c= an observe header field parameters, and a registrar will ignore header fiel= d parameters it doesn't understand.

       Thanks,
       Paul

    _______________________________________________
    sipcore mailing list
    sipcore@ietf.org
    https://www= .ietf.org/mailman/listinfo/sipcore
    --_000_F58C1D167BC94BD6BDD3516F67AAA5FBericssoncom_-- From nobody Thu Dec 21 11:47:28 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA065129C6F for ; Thu, 21 Dec 2017 11:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 qQE7cAENITIR for ; Thu, 21 Dec 2017 11:47:25 -0800 (PST) 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 A91B1129C6E for ; Thu, 21 Dec 2017 11:47:24 -0800 (PST) X-AuditID: 1207440e-bf9ff70000007085-3d-5a3c0fc916f9 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 58.6A.28805.9CF0C3A5; Thu, 21 Dec 2017 14:47:21 -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 vBLJlIlr022489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Dec 2017 14:47:19 -0500 To: Christer Holmberg Cc: "sipcore@ietf.org" References: <87zi6cuwqy.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Thu, 21 Dec 2017 14:47:18 -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=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixO6iqHuK3ybKoPOWqMWFmYcZLb7+2MTm wOTx6+tVNo8lS34yBTBFcdmkpOZklqUW6dslcGVM+/afreCkaMWOC1eZGxhXC3YxcnJICJhI XNh1gKWLkYtDSGAHk8TEhVtZQRJCAg+ZJO7dtgOxhQXsJR5emcYGYosImElc/9zLBGIzC2hK bF53gR2i/gKjxNLzzCA2m4CWxJxD/1lAbF6g3qbWz2D1LAKqEgeXngWrFxVIk9hzoQOqRlDi 5MwnYDangIPEqWPnWSHm20rcmbubGcIWl7j1ZD7UXnmJ5q2zmScwCsxC0j4LScssJC2zkLQs YGRZxSiXmFOaq5ubmJlTnJqsW5ycmJeXWqRrrJebWaKXmlK6iRESwHw7GNvXyxxiFOBgVOLh 5dhjHSXEmlhWXJl7iFGSg0lJlPc5m02UEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHew0uAynlT EiurUovyYVLSHCxK4rxqS9T9hATSE0tSs1NTC1KLYLIyHBxKErxSfEBDBYtS01Mr0jJzShDS TBycIMN5gIYrgtTwFhck5hZnpkPkTzFacvT03PjDxLHu9D0g+Wzm6wZmIZa8/LxUKXHenbxA DQIgDRmleXAzYQnpFaM40IvCvMdAxvIAkxnc1FdAC5mAFk4PAvmmuCQRISXVwOh8vajqrysX 0ytByeWvzBZ+WOvTM1Gs4+RrbU22GclzMov3/dx7Utrif/6X6JXbnuySP/zpzvrKPUzRHQYc Sy8JXN5R1Co/48Hq7ab3Z/quNvPYc/9zbHDuL6tPRuEl/6ynL2ra57FH6YGSheyfwk/JWzdX 3Q5O8b+6SPDoqXSjj6wfRE58c2FXYinOSDTUYi4qTgQAg7M76CMDAAA= Archived-At: Subject: Re: [sipcore] Comments regarding sip-push registration 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, 21 Dec 2017 19:47:27 -0000 On 12/21/17 10:33 AM, Christer Holmberg wrote: > Hi Paul, > > Maybe I was unclear and/or I misunderstood your question. I did not mean > to say that it would impact the choice. > > Using URI parameters in the REGISTER request, they will automatically be > copied into the INVITE request using normal SIP registrar procedures. > There is no need to update the registrar, or having intermediaries > modifying the REGISTER, contact etc. > > Using header parameters, you would need to update the SIP registrar to > insert them in the INVITE request. Ahh, I missed that. OK, I acknowledge that this will allow you to get by without modifying the registrar. Thanks, Paul > Regards, > > Christer > > Sent from my iPhone > > On 21 Dec 2017, at 16.40, Paul Kyzivat > wrote: > >> On 12/21/17 7:47 AM, Christer Holmberg wrote: >> >>>> - Header field parameters >>>> >>>> Really, the use of URI parameters for controlling push-notification >>>> registration is a Bad Idea from the design point of view.  Header >>>> parameters should be used.  (Note that ":" must be quoted in header >>>> parameters.) >>>> >>>> If you want to use a registrar that can't add another column to its >>>> registrations table, the proxy should manipulate the REGISTER before >>>> forwarding it to the registrar to stash the push-notification >>>> information in the contact URI.  But we should design the message flow >>>> between the UA and the proxy to be as clean as we can, and allow >>>> implementors to devise clever ways to support that message flow. >>> The usage of URI parameters will make the deployment easier as it >>> does not >>> mandate updating the registrars (unless the push notification triggering >>> will be done by the registrar, of course). Also, unlike some of the >>> proprietary ideas I have seen, it does not mandate intermediaries to >>> modify the REGISTER and/or the contact, etc. >>> In some environments ładding another table˛ can be a very big task. >>> As the schedule for deploying this is very tight in many cases, there >>> is a >>> strong wish from the industry to be able to deploy this without having to >>> update the registrar. >> >> Why does using header field parameters rather than uri parameters >> impact the choice of proxy or registrar to implement this feature? The >> proxy can observe header field parameters, and a registrar will ignore >> header field parameters it doesn't understand. >> >>    Thanks, >>    Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Dec 21 12:36: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 165D9126B6E for ; Thu, 21 Dec 2017 12:36:47 -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 4B-Z7CudvsRX for ; Thu, 21 Dec 2017 12:36:45 -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 B4F601241F5 for ; Thu, 21 Dec 2017 12:36:44 -0800 (PST) X-AuditID: c1b4fb3a-335ff700000037f2-11-5a3c1b5a7c8a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FD.77.14322.A5B1C3A5; Thu, 21 Dec 2017 21:36:42 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Thu, 21 Dec 2017 21:36:41 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-02.txt Thread-Index: AQHTem18W6DHQaFzL0WVrPaHP1V/AaNOPMRg Date: Thu, 21 Dec 2017 20:36:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0D2E81@ESESSMB109.ericsson.se> References: <151386389876.12757.13783547539087083504@ietfa.amsl.com> <0e2f65ea-c74e-e6ce-7b09-43ff4d60577c@alum.mit.edu> In-Reply-To: <0e2f65ea-c74e-e6ce-7b09-43ff4d60577c@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7q26UtE2UwckfGhYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUx48gq9oLNShXz/nxjbGC8K9nFyMkhIWAi cfbiQ5YuRi4OIYHDjBI7Vh1ig3CWMErM3zmXvYuRg4NNwEKi+582SIOIQKDE1SUTmEFsYQFX iQmzL7BBxN0k9l27xAxhG0nMurWZFcRmEVCVeDf7PxOIzSvgK7H8400wW0igSuLVmiVg9ZwC DhItkz+zg9iMAmIS30+tAathFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSaw9vJ0Fol5H YsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKjyCwkY2chaZmFpGUWkpYFjCyrGEWLU4uLc9ONjPRS izKTi4vz8/TyUks2MQLj4eCW31Y7GA8+dzzEKMDBqMTD+1PYJkqINbGsuDL3EKMEB7OSCO/h JdZRQrwpiZVVqUX58UWlOanFhxilOViUxHmd0iyihATSE0tSs1NTC1KLYLJMHJxSDYyTWQVn LIx25T1kudxz8uRfbbwPuB4Kl7EYtfx4zH3DZuMURS1+T5YEoQ85LnNlRF7I1G7OY5EwubJQ fFraXo89zUWv6gTnRJV+068385Od/a0x8/QctrN5R2/+M5EMqQq8LMg7Q/jfFJazoso6Z9Tv b0q7ocyz1PvbjMPds48na2y+/tLASV+JpTgj0VCLuag4EQDKk6clgwIAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-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, 21 Dec 2017 20:36:47 -0000 Hi, >I just looked more closely at the ABNF for the indicator. It has some prob= lems. > > sip.pns =3D "<" pns-list ">" > pns-list =3D pns *(COMMA pns) > pns =3D pvalue > > ; pvalue as defined in RFC 3261 > > First, 'sip.pns' isn't a valid rulename. I presume you simply mean that t= he name of this feature-capability indicator=20 > is "sip.pns", or "pns" in the "sip" tree. This would be taken care of if = you filled in a registration template as specified=20 > in rfc6809. I can find no such template. It's in section 12.3. (I note that I have forgot the contact information, but the name, descripti= on and reference is there.) > Next, according to rfc3840 the syntax of a feature param is: > > feature-param =3D enc-feature-tag [EQUAL LDQUOT (tag-value-list > / string-value ) RDQUOT] ... > tag-value-list =3D tag-value *("," tag-value) > tag-value =3D ["!"] (token-nobang / boolean / numeric) > token-nobang =3D 1*(alphanum / "-" / "." / "%" / "*" > / "_" / "+" / "`" / "'" / "~" ) > boolean =3D "TRUE" / "FALSE" > numeric =3D "#" numeric-relation number > numeric-relation =3D ">=3D" / "<=3D" / "=3D" / (number ":") > number =3D [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] > string-value =3D "<" *(qdtext-no-abkt / quoted-pair ) ">" > qdtext-no-abkt =3D LWS / %x21 / %x23-3B / %x3D > / %x3F-5B / %x5D-7E / UTF8-NONASCII > > Notably, the value of the feature-param is always enclosed in double quot= es. Also, I think your use of "<" and ">" means that=20 > you intend this to be a string-value with a particular syntax, but possib= ly the tag-value-list syntax would work for you. Yes. We don't need to use pvalue - tag-value is more than enough (the same = applies to the pn-provider URI parameter, which will carry the same values)= . So, how would the syntax look like? Something like: pns-feature-cap =3D "+" "sip.pns" [EQUAL LDQUOT pns-list RDQUOT] pns-list =3D pns *(COMMA pns) pns =3D tag-value ;tag-value defined in RFC 3840 Regards, Christer On 12/21/17 8:44 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core WG of t= he IETF. >=20 > Title : Push Notification with the Session Initiation = Protocol (SIP) > Author : Christer Holmberg > Filename : draft-ietf-sipcore-sip-push-02.txt > Pages : 14 > Date : 2017-12-21 >=20 > Abstract: > This document describes how push notification mechanisms can be used > to wake up suspended Session Initiation Protocol (SIP) User Agents > (UAs), in order to be able to receive and generate SIP requests. The > document defines new SIP URI parameters, that can be used in a SIP > REGISTER request to provide push notification information from the > SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in > this document) that will send a push request to the push server in > order to trigger a push notification towards the SIP UA. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-02 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-push-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 Thu Dec 21 14:11:30 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7015126BF0; Thu, 21 Dec 2017 14:11:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, sipcore@ietf.org, brian.rosen@gmail.com, sipcore-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151389428871.27953.17946406112283313085.idtracker@ietfa.amsl.com> Date: Thu, 21 Dec 2017 14:11:28 -0800 Archived-At: Subject: [sipcore] sipcore - New Meeting Session Request for IETF 101 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 22:11:28 -0000 A new meeting session request has just been submitted by Brian Rosen, a Chair of the sipcore working group. --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Brian Rosen Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: avtcore dispatch ice modern stir Second Priority: mmusic rtcweb sipbrandy People who must be present: Ben Campbell Brian Rosen Jean Mahoney Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Dec 23 05:07:14 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534C7129C6F for ; Sat, 23 Dec 2017 05:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMYTZIFWi50S for ; Sat, 23 Dec 2017 05:07:10 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 5B1AF128954 for ; Sat, 23 Dec 2017 05:07:10 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id SjVfehmSH2Dj5SjW9eogD6; Sat, 23 Dec 2017 13:07:09 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with SMTP id SjW7e0NUKEmODSjW8eD6q4; Sat, 23 Dec 2017 13:07:08 +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 vBND77RA002656; Sat, 23 Dec 2017 08:07:07 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vBND77w8002653; Sat, 23 Dec 2017 08:07:07 -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: Christer Holmberg Cc: sipcore@ietf.org In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Sat, 23 Dec 2017 08:07:06 -0500 Message-ID: <874lohtwxx.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLTlnnTG0OXhCLJpEfF1aZ2d8BGSf3N/97U/RTSXRNnra6JheUP2zmbN70F4Q/Eh9Fk/SENWqXZBPcoRyE1FdMZdbF9LHve6cI3KO+QEgAqHBf+PSno0 qOjroKxUsNjnII2ZPQCNhR6xDwXJ7v4Mq9o+IowJNa/eHdLnIa/A4VSfyOlY2avLkibNxBy4IGXIG5mvKQw3jqzI9aUbyrVLOGQ= Archived-At: Subject: Re: [sipcore] Comments regarding sip-push registration 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, 23 Dec 2017 13:07:12 -0000 Christer Holmberg writes: > The interval will be based on the registration expiration. > > And, similar to the UA wakeup behaviour you mention, the push notification > should be triggered prior to the actual registration expiration. You need to explain this behavior completely. It seems that the UA is likely to depend on it, but in order for the UA to do that, it has to have a clear specification as to how the registrar will perform these wake-ups, and precisely *when* they will happen. > The usage of URI parameters will make the deployment easier as it does not > mandate updating the registrars (unless the push notification triggering > will be done by the registrar, of course). Also, unlike some of the > proprietary ideas I have seen, it does not mandate intermediaries to > modify the REGISTER and/or the contact, etc. > > In some environments 'adding another table' can be a very big task. > > As the schedule for deploying this is very tight in many cases, there is a > strong wish from the industry to be able to deploy this without having to > update the registrar. OK, but you don't have to muddy the documented wire protocol to support unmodified registrars, because the proxy can compensate for that. And you're already expecting to modify the proxy. Dale From nobody Wed Dec 27 11:27: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 90DEA1275AB for ; Wed, 27 Dec 2017 11:27:06 -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 cxXeZn2chUbT for ; Wed, 27 Dec 2017 11:27:04 -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 6A670126D74 for ; Wed, 27 Dec 2017 11:27:04 -0800 (PST) X-AuditID: c1b4fb3a-716549c0000037f2-90-5a43f405b13b Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.E8.14322.504F34A5; Wed, 27 Dec 2017 20:27:02 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Wed, 27 Dec 2017 20:27:00 +0100 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Comments regarding sip-push registration Thread-Index: AQHTelG8t/VN7Cx2bUChJJKlQ6bgMqNN0naAgAMGAACABr8bYA== Date: Wed, 27 Dec 2017 19:27:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0DD967@ESESSMB109.ericsson.se> References: <874lohtwxx.fsf@hobgoblin.ariadne.com> In-Reply-To: <874lohtwxx.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2J7uC7bF+cog5tbuS2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbGjYx17wVnhinu/TjM2MN7j72Lk5JAQMJFY u2krSxcjF4eQwGFGiYaO44wQzhJGibPn3rF2MXJwsAlYSHT/0wYxRQQ0JToW5ID0MgOZj3bu ZQKxhQXsJRYsfs0MUeIgcekKL0hYRMBJ4vabs0wgYRYBVYnt3/xBwrwCvhK3pr1gA7GFBFIk Ln29DDaFU8BYYsqpVWA2o4CYxPdTa5ggNolL3HoynwniYgGJJXvOM0PYohIvH/9jhbCVJNYe 3s4CUa8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcXF uelGRnqpRZnJxcX5eXp5qSWbGIHxcXDLb6sdjAefOx5iFOBgVOLhbX/qHCXEmlhWXJl7iFGC g1lJhDevHSjEm5JYWZValB9fVJqTWnyIUZqDRUmc1ynNIkpIID2xJDU7NbUgtQgmy8TBKdXA qDLxa3G07qOoZF4f4ateC7ifni/mmJZ1INUl+WrHhKWa5+x3HBZ/WmHA1DAj5JNBUuTtXcet ZrQ6TN24MbT5TNzcVQefLyr7XS5pu/0Ey9IvFrkOs/xOrYz563r98ZSzhrnm8swREyb/fR3h /5/TKSvd64rFHVURFruX8e/WBTiFakgIPQytUWIpzkg01GIuKk4EALiSq1OLAgAA Archived-At: Subject: Re: [sipcore] Comments regarding sip-push registration 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, 27 Dec 2017 19:27:06 -0000 Hi, >> The interval will be based on the registration expiration. >> >> And, similar to the UA wakeup behaviour you mention, the push=20 >> notification should be triggered prior to the actual registration expira= tion. > > You need to explain this behavior completely. It seems that the UA is li= kely to depend on it, but > in order for the UA to do that, it has to have a clear specification as t= o how the registrar will perform=20 > these wake-ups, and precisely *when* they will happen. I don't think we need to mandate how the wake-ups are triggered, because th= ere are different ways of doing that. If the proxy triggering the push noti= fications is not part of the registrar, there needs to be A way for it to k= now when to trigger the push notifications. I can add text pointing out that the push notifications triggering the re-r= egistrations need to be triggered before the registration expires (eventhou= gh a UA sending re-register before registration expiration as such that is = normal SIP behavior). >>> The usage of URI parameters will make the deployment easier as it does= =20 >>> not mandate updating the registrars (unless the push notification=20 >> triggering will be done by the registrar, of course). Also, unlike=20 >> some of the proprietary ideas I have seen, it does not mandate=20 >> intermediaries to modify the REGISTER and/or the contact, etc. >> >> In some environments 'adding another table' can be a very big task. >> >> As the schedule for deploying this is very tight in many cases, there=20 >> is a strong wish from the industry to be able to deploy this without=20 >> having to update the registrar. > > OK, but you don't have to muddy the documented wire protocol to support u= nmodified registrars, because the proxy can=20 > compensate for that. And you're already expecting to modify the proxy. A proxy processing URI parameters (triggering the push notifications etc) i= s much less impact than the registrar having to be able to store new header= parameters: in 3GPP networks that would most likely impact the HSS, the in= terface between to the HSS etc - thing would require much more standardizat= ion. In addition to being a standardized solution (in addition to different prop= rietary solutions people are looking at), the solution has been sold as eas= y to implement, as it does not impact the registrar, user databases etc. I = really hope we can keep it that way. Regards, Christer From nobody Thu Dec 28 04:23: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 3B1C812D87C for ; Thu, 28 Dec 2017 04:23:01 -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 zBjj7mjFh3Y7 for ; Thu, 28 Dec 2017 04:22:58 -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 656A4126CBF for ; Thu, 28 Dec 2017 04:22:58 -0800 (PST) X-AuditID: c1b4fb30-11d5e9c000006bc7-35-5a44e220c703 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 73.A3.27591.022E44A5; Thu, 28 Dec 2017 13:22:56 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Thu, 28 Dec 2017 13:22:41 +0100 From: Christer Holmberg To: Christer Holmberg , "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Comments regarding sip-push registration - pull request Thread-Index: AdN/1nMjNEh0voaRT0qU5ViocPOeyw== Date: Thu, 28 Dec 2017 12:22:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0DE33C@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM2K7rq7CI5cog7O/xSy+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlTH15HXmgm7JitMXXzI2MG4V6WLk5JAQMJF4 tHcNI4gtJHCYUaL9iySEvYRR4sl16S5GDg42AQuJ7n/aIGERgXiJ7y9fgpUzC2hKPNq5lwnE FhYIkNiweDkbRE2gxLFfV6BsPYl975ewgNgsAqoSc7eeYwexeQV8JbbuXsEKYjMKiEl8P7WG CWKmuMStJ/OZIE4TkFiy5zwzhC0q8fLxP1YIW0micckTVoh6HYkFuz+xQdjaEssWvmaGmC8o cXLmE5YJjMKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIDPiD W34b7GB8+dzxEKMAB6MSD+/WCy5RQqyJZcWVuYcYJTiYlUR4T/QBhXhTEiurUovy44tKc1KL DzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTDabD5upXE34+LX2COZV2MUOj/ESXcJ nV6av1Ga47DZnRObZKNWqR+e8Dnhm9m33745dcfNCn/4+fR9Wsfz886js5d+vusV3W3ao7hT 5l2u79OM7RmXVikIryhKaY1UFpbRifu9rO92R4iT8eFIwa+1n+dW5L19veZkxv5SC+FNrC5l H/j/m8xXYinOSDTUYi4qTgQAPlmaoHQCAAA= Archived-At: Subject: Re: [sipcore] Comments regarding sip-push 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: Thu, 28 Dec 2017 12:23:01 -0000 Hi, I've created a pull request, which points out that a re-registration needs = to be triggered early enough in order for the re-registration request to re= ach the registrar before the registration expires. https://github.com/cdh4u/draft-sip-push/pull/6 Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 27 December 2017 21:27 To: Dale R. Worley Cc: sipcore@ietf.org Subject: Re: [sipcore] Comments regarding sip-push registration Hi, >> The interval will be based on the registration expiration. >> >> And, similar to the UA wakeup behaviour you mention, the push=20 >> notification should be triggered prior to the actual registration expira= tion. > > You need to explain this behavior completely. It seems that the UA is=20 > likely to depend on it, but in order for the UA to do that, it has to=20 > have a clear specification as to how the registrar will perform these wak= e-ups, and precisely *when* they will happen. I don't think we need to mandate how the wake-ups are triggered, because th= ere are different ways of doing that. If the proxy triggering the push noti= fications is not part of the registrar, there needs to be A way for it to k= now when to trigger the push notifications. I can add text pointing out that the push notifications triggering the re-r= egistrations need to be triggered before the registration expires (eventhou= gh a UA sending re-register before registration expiration as such that is = normal SIP behavior). >>> The usage of URI parameters will make the deployment easier as it=20 >>> does not mandate updating the registrars (unless the push=20 >>> notification >> triggering will be done by the registrar, of course). Also, unlike=20 >> some of the proprietary ideas I have seen, it does not mandate=20 >> intermediaries to modify the REGISTER and/or the contact, etc. >> >> In some environments 'adding another table' can be a very big task. >> >> As the schedule for deploying this is very tight in many cases, there=20 >> is a strong wish from the industry to be able to deploy this without=20 >> having to update the registrar. > > OK, but you don't have to muddy the documented wire protocol to=20 > support unmodified registrars, because the proxy can compensate for that.= And you're already expecting to modify the proxy. A proxy processing URI parameters (triggering the push notifications etc) i= s much less impact than the registrar having to be able to store new header= parameters: in 3GPP networks that would most likely impact the HSS, the in= terface between to the HSS etc - thing would require much more standardizat= ion. In addition to being a standardized solution (in addition to different prop= rietary solutions people are looking at), the solution has been sold as eas= y to implement, as it does not impact the registrar, user databases etc. I = really hope we can keep it that way. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore