-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-holmberg-sipcore-sip-push.xml
497 lines (446 loc) · 21.7 KB
/
draft-holmberg-sipcore-sip-push.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
<?xml version="1.0" encoding="windows-1252"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0822 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3311 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC4028 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4028.xml">
]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="trust200902" category="std" docName="draft-holmberg-sipcore-sip-push-latest" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="SIP PUSH">
Push Notification with the Session Initiation Protocol (SIP)
</title>
<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2017"/>
<area>Transport</area>
<workgroup>SIPCORE Working Group</workgroup>
<keyword>SIP</keyword>
<keyword>Push</keyword>
<keyword>Notification</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>
In order to save resources (e.g, battery life) some devices and operating
systems require suspended Session Initiation Protocol (SIP) User Agents (UAs)
<xref target="RFC3261"/> to be woken up using a push notification
service. Typically each operating system uses a dedicated push notification
service. For example, Apple iOS devices use the Apple Push Notification service (APNs).
</t>
<t>
Due to the restriction above, applications can not be woken up by non-push notification
traffic. This means that a suspended SIP UA will not be able to receive an incoming
SIP request (e.g., a SIP INVITE request), or to send periodic re-registration requests.
</t>
<t>
This document describes how push notification mechanisms can be used to wake up
suspended SIP 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 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.
</t>
<t>
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.
</t>
<t>
When the SIP proxy receives a SIP request for a new session, or a stand-alone SIP request,
addressed towards a SIP UA, or when the SIP proxy determines that the SIP UA needs to perform
a re-registration, 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.
</t>
<t>
Different push notification mechanisms exist today. Some are based on there
standardized mechanism defined in <xref target="RFC8030"/>, while others are
proprietary (e.g., the Apple Push Notification service). <xref target="fig-sip-pn-arch"/>
shows the generic push notification architecture supported by the mechanism
in this document.
</t>
<figure title="SIP Push Notification Architecture" anchor="fig-sip-pn-arch"
align="center"><artwork>
<![CDATA[
+--------+ +--------------+ +-----------------+
| SIP UA | | Push Service | | SIP Proxy |
+--------+ +--------------+ +-----------------+
| | |
| Subscribe | |
|--------------------->| |
| | |
| Push Resource ID | |
|<---------------------| |
| | |
| SIP REGISTER (Push Resource ID) |
|===============================================>|
| | |
| | Push Message |
| | (Push Resource ID) |
| Push Message |<------------------------|
| (Push Resource ID) | |
|<---------------------| |
| | |
------- Push Notification API
======= SIP
REGISTER sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected];
pn-type=acme:acme-param;
pn-prid="ZTY4ZDJlMzODE1NmUgKi0K">
Expires: 7200
Content-Length: 0
]]></artwork></figure>
</section>
<section title="Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"></xref>.
</t>
</section>
<section title="Push Resource ID (PRID)">
<t>
When an entity registers with a Push Notification Server (PNS) is receives
a unique Push Resource ID (PRID), which is a value associated with the
registration.
</t>
<t>
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.
</t>
<t>
The details regarding discovery of the PNS, and the procedures for the
push notification registration and maintenance are outside the scope of
this document. The information needed to contact the PNS is typically
pre-configured in the operating system (OS) of the device.
</t>
</section>
<section anchor="section.ua" title="SIP User Agent (UA) Behavior">
<t>
Once the SIP UA has registered with the PNS and received the PRID, and when the
UA wants to receive push notifications triggered by the SIP proxy, the UA MUST
send a SIP REGISTER using normal SIP registration procedures. The UA MUST add
a pn-prid URI parameter and a pn-type URI parameter to the SIP Contact header
field URI of the request. The pn-prid URI parameter contains the PRID value.
The pn-type contains additional, PNS-specific, information.
</t>
<t>
When the SIP UA receives a push notification, it MUST perform a SIP re-registration
<xref target="RFC3261"/> by sending a SIP REGISTER request. If there are
Network Address Translators (NATs) between the SIP UA and the SIP proxy, the SIP REGISTER
request will create NAT bindings allowing incoming SIP requests to reach the SIP UA.
If the SIP proxy triggered the push notification because it wants to forward a SIP request
towards the SIP UA, the receival of the SIP REGISTER request can be used by the SIP proxy
as a trigger to forward the SIP request.
</t>
<t>
As long as the UA wants the SIP proxy to continue sending push requests, the
UA MUST include the pn-prid and pn-type URI parameters in every re-registration
SIP REGISTER request sent towards the SIP proxy. Note that, in some cases, the
PNS might update the PRID value, in which case the re-registration SIP REGISTER request
will contain the new value.
</t>
<t>
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.
</t>
<t>
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 <xref target="I-D.ietf-webpush-encryption"/>.
The pn-enckey URI parameter contains the public key, and the pn-encsec URI parameter
contains the authentication secret <xref target="I-D.ietf-webpush-encryption"/>.
</t>
<t>
NOTE: End-to-end encryption of the payload between the SIP proxy and the SIP UA cannot
be used if the push notification request payload contains information that needs to be
accessible by the push notification server.
</t>
</section>
<section anchor="section.proxy" title="SIP Proxy Behavior">
<section anchor="section.proxy.pnid" title="Push Notification Provider Information">
<t>
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.
</t>
<t>
The protocol and format used for the push request depends on the push notification provider,
and the details for constructing and sending the messages are outside the scope of this
specification.
</t>
</section>
<section anchor="section.proxy.rereg" title="Trigger Periodic Re-registration">
<t>
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.
</t>
<t>
When the SIP proxy receives an indication that the SIP UA needs to perform a
re-registration, the SIP proxy triggers a push request towards the push notification
server associated with the PRID.
</t>
</section>
<section anchor="section.proxy.inv" title="SIP Request">
<t>
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. After that,
the SIP proxy forwards the SIP request towards the SIP UA using normal SIP procedures.
</t>
<t>
As the push notification will trigger the SIP UA to perform a re-registration, the
SIP proxy can use the receival of the SIP REGISTER request as a trigger to forward
SIP request towards the SIP UA.
</t>
<t>
The SIP proxy MUST NOT transport the SIP request as push request payload, instead of
forwarding the request using normal SIP procedures.
</t>
<t>
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.
</t>
<t>
If the SIP proxy is able to assume that the SIP UA is awake, and that the SIP UA
is able to receive the SIP request, the SIP proxy MAY choose to not trigger a push
notification request before trying to forward the SIP request towards the SIP UA.
The SIP proxy can make such assumption e.g., if a TLS connection previously established
by the SIP UA is still open.
</t>
</section>
</section>
<section anchor="section.nat" title="Network Address Translator (NAT) Considerations">
<t>
Whenever the UA receives a push notification, if the SIP UA is located behind a
Network Address Translator (NAT), the UA might need to take actions in order to
establish a binding in the NAT, in order for an incoming SIP request to reach the
UA. By performing the re-registration the SIP UA will establish such NAT binding.
</t>
</section>
<section anchor="section.grammar" title="Grammar">
<t>
The section defines new SIP URI parameters, by extending the grammar for "uri-parameter"
as defined in <xref target="RFC3261"/>. The ABNF is as follows:
</t>
<figure align="center"><artwork>
<![CDATA[
uri-parameter =/ pn-prid / pn-type / pn-enccode / pn-enckey
pn-prid = "pn-prid" EQUAL pvalue
pn-type = "pn-type" EQUAL pns-provider COLON pns-param
pn-enccode = "pn-enccode" EQUAL pvalue
pn-enckey = "pn-enckey" EQUAL pvalue
pns-provider = pvalue ; Colon (":") characters MUST be escaped
pns-param = pvalue ; Colon (":") characters MUST be escaped
; pvalue as defined in RFC 3261
; EQUAL as defined in RFC 3261
; COLON as defined in RFC 3261
The format and semantics of pns-param is specific to a given
pns-provider value.
]]></artwork></figure>
</section>
<section anchor="section.sec-reqs" title="PNS Registration Requirements">
<t>
When a new value is registered to the PNS Sub-registry, a reference to a specification which
describes the push notification service associated with the value is provided. That specification
MUST contain the following information:
<list style="symbols">
<t>
How the values for the pn-prid parameter is retrieved and set by the SIP UA.
</t>
<t>
The format of the pns-param part of the pns-type parameter, and how the value of the pns-param part is retrieved and set by the SIP UA.
</t>
<t>
Whether there are any restrictions regarding usage of payload encryption <xref target="I-D.ietf-webpush-encryption"/>
with the associated push notification service.
</t>
</list>
</t>
</section>
<section anchor="section.sec-apns" title="pn-prid and pn-type URI parameters for Apple Push Notification service">
<t>
When the Apple Push Notification service (APNs) is used, the value of the pn-type URI parameter
pns-provider parameter part is "apns". The pns-param part contains the APNs App ID, which is encoded
by two values, separated by a period (.): Team ID and Bundle ID. The Team ID is provided by Apple and
is unique to a development team. The Bundle ID is unique to a development team, and is a string that will
can match a single application or a group of applications.
</t>
<t>
Example: pn-type = apns:DEF123GHIJ.com.yourcompany.yourexampleapp
</t>
<t>
When the Apple Push Notification service (APNs) is used, pn-type URI parameter pns-prid parameter
part contains the device token, which is a unique identifier assigned by Apple to a specific app
on a specific device.
</t>
<t>
Example: pn-prid = 00fc13adff78512
</t>
<t>
For more information on the APNs App ID:
</t>
<t>
https://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/AppID.html
</t>
<t>
For more information on the APNs device token:
</t>
<t>
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW13
</t>
</section>
<section anchor="section.sec-fcm" title="pn-prid and pn-type URI parameters for Google Firebase Cloud Messaging (FCM) push notification service">
<t>
When Firebase Cloud Messaging (FCM) is used, the value of the pn-type URI parameter
pns-provider parameter part is "fcm". The pns-param part contains the Sender ID.
</t>
<t>
When Firebase Cloud Messaging (FCM) is used, pn-type URI parameter pns-prid parameter
part contains the Registration token, which generated by the FCM SDK for each client app instance.
</t>
<t>
For more information on the Sender ID and Registration token:
</t>
<t>
https://firebase.google.com/docs/cloud-messaging/concept-options
</t>
</section>
<section anchor="section.sec" title="Security considerations">
<t>
In addition to the information exchanged between a device and its
PNS in order to establish a push notification subscription, the mechanism
in this document does not require entities to provide any additional
information to the PNS.
</t>
<t>
Push notification mechanisms provide different methods to ensure that malicious
user cannot trigger push notifications to a device. Users of the mechanism
in this document MUST take measures to prevent push notifications from being
sent to a device from a malicious user.
</t>
<t>
In case entities do want to include payload in the push notifications, this document
defines the means for using end-to-end payload encryption between the entity sending
the push request and the entity receiving the associated push notification.
</t>
</section>
<section anchor="section.iana" title="IANA considerations">
<t>
This specification defines new SIP URI parameters that extend the
registry created by <xref target="RFC3969"/>:
</t>
<section anchor="section.iana.pn-prid" title="pn-prid">
<figure align="center"><artwork>
<![CDATA[
Parameter Name: pn-prid
Predefined Values: No
Reference: RFC XXXX
]]></artwork></figure>
</section>
<section anchor="section.iana.pn-type" title="pn-type">
<figure align="center"><artwork>
<![CDATA[
Parameter Name: pn-type
Predefined Values: No
Reference: RFC XXXX
]]></artwork></figure>
</section>
<section anchor="section.iana.pn-enckey" title="pn-enckey">
<figure align="center"><artwork>
<![CDATA[
Parameter Name: pn-enckey
Predefined Values: No
Reference: RFC XXXX
]]></artwork></figure>
</section>
<section anchor="section.iana.pn-encsec" title="pn-enccode">
<figure align="center"><artwork>
<![CDATA[
Parameter Name: pn-enccode
Predefined Values: No
Reference: RFC XXXX
]]></artwork></figure>
</section>
<section anchor="section.iana.pns-sub" title="PNS Sub-registry Establishment">
<t>
This section creates a new sub-registry, "PNS", under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters.
</t>
<t>
The purpose of the sub-registry is to register SIP URI pn-type values.
</t>
<figure align="center"><artwork>
<![CDATA[
This sub-registry is defined as a table that contains the following
three columns:
Value: The token under registration
Description: The name of the push notification service
Document: A reference to the document defining the registration
]]></artwork></figure>
<figure align="center"><artwork>
<![CDATA[
This specification registers the following values:
Value Description Document
------- ---------------------------------- ----------
apns Apple Push Notification service [RFC XXXX]
fcm Firebase Cloud Messaging [RFC XXXX]
]]></artwork></figure>
</section>
</section>
</middle>
<back>
<references title="Normative references">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3969"?>
<?rfc include="reference.RFC.8030"?>
</references>
<references title="Informative references">
<?rfc include="reference.I-D.ietf-webpush-encryption"?>
</references>
</back>
</rfc>