forked from cdh4u/draft-sip-push
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-sipcore-sip-push.xml
1603 lines (1484 loc) · 91 KB
/
draft-ietf-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
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?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">
<!ENTITY RFC4320 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4320.xml">
<!ENTITY RFC4321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4321.xml">
]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-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>christer.holmberg@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Arnold" fullname="Michael Arnold">
<organization>Metaswitch Networks</organization>
<address>
<postal>
<street>100 Church Street</street>
<city>Enfield</city>
<country>United Kingdom</country>
<code>EN2 6BQ</code>
</postal>
<email>Michael.Arnold@metaswitch.com</email>
</address>
</author>
<date year="2019"/>
<area>Transport</area>
<workgroup>SIPCORE Working Group</workgroup>
<keyword>SIP</keyword>
<keyword>Push</keyword>
<keyword>Notification</keyword>
<abstract>
<t>
This document describes how a Push Notification Service (PNS) can be used to wake
suspended Session Initiation Protocol (SIP) User Agents (UAs), using push notifications,
for the UA to be able to send binding-refresh REGISTER requests and to receive receive incoming SIP requests.
The document defines new SIP URI parameters and new feature-capability
indicators that can be used in SIP messages to indicate support of the mechanism defined in this
document, to exchange PNS information between the SIP User Agent (UA) and the SIP entity that will
request that push notifications are sent to the UA, and to trigger such push notification requests.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>
In order to save resources (e.g., battery life) some devices (especially mobile devices)
and operating systems will suspend applications when not used. In some cases,
internal timers cannot be used to wake such applications, nor will incoming network
traffic wake the application. Instead, one way to wake the application is by using a
Push Notification Service (PNS). A PNS is a service from where a user application can
receive messages, referred to as push notifications, requested by other applications.
Push notifications might contain payload data, depending on the application. An application
can request that a push notification is sent to a single user application, or to multiple
user applications.
</t>
<t>
Typically each operating system uses a dedicated PNS.
For example, Apple iOS devices use the Apple Push Notification service (APNs)
while Android devices use the Firebase Cloud Messaging (FCM) service.
</t>
<t>
Because of the restrictions above, Session Initiation Protocol (SIP) User Agents (UAs)
<xref target="RFC3261"/> can not be awoken, in order to send binding-refresh SIP REGISTER
requests and to receive incoming SIP requests, without using a PNS to wake the UA
in order to perform those functions.
</t>
<t>
Also, without being able to use internal timers in order to wake applications, a UA
will not be able to maintain connections e.g., using the SIP Outbound Mechanism
<xref target="RFC5626"/>, as it requires the UA to send periodic keep-alive messages.
</t>
<t>
This document describes how PNSs can be used to wake suspended UAs, using push notifications, to be able to send
binding-refresh REGISTER requests and to receive incoming SIP requests. The document defines
new SIP URI parameters and new feature-capability indicators <xref target="RFC6809"/>
that can be used in SIP messages to indicate support of the mechanism defined in this document,
to exchange PNS information between the UA and the SIP entity (realized as a SIP proxy in this document)
that will request that push notifications are sent to the UA, and to request such push notification requests.
</t>
<t>
NOTE: Even if a UA is able to be awakened by other means than receiving push notifications (e.g., by using internal timers) in order to
send periodic binding-refresh REGISTER requests, it might still be useful to suspend the application
between the sending of binding-refresh requests (as it will save battery life) and use push notifications
to wake the UA when an incoming SIP request UA arrives.
</t>
<t>
When a UA registers to a PNS, it will receive a unique Push Resource ID (PRID)
associated with the push notification registration. The UA will use a REGISTER request to
provide the PRID to the SIP proxy that will request push that notifications are sent to the UA.
</t>
<t>
When the proxy receives
a SIP request for a new dialog or a stand-alone SIP request addressed towards a UA,
or when the proxy determines that the UA needs to send a binding-refresh REGISTER request, the proxy will
request that a push notification is sent to the UA, using the PNS of the UA. Once the UA receives
the push notification, it will be able to send a binding-refresh REGISTER request and receive
the incoming SIP request. The proxy will receive the REGISTER request. If the push notification request was
triggered by a SIP request addressed towards the UA (see above), once the REGISTER request has been
accepted by the SIP registrar <xref target="RFC3261"/>, and the associated SIP 2xx response has been forwarded by the proxy towards the UA,
the proxy can forward the SIP request towards the UA using normal SIP routing procedures. In some cases the proxy can forward the SIP
request without waiting for the SIP 2xx response to the REGISTER request. Note that this mechanism necessarily adds
delay to responding to requests requiring push notification. The consequences of that delay are discussed
in <xref target="section.proxy.req.oth"/>.
</t>
<t>
If there are Network Address Translators (NATs) between the UA and the proxy, the REGISTER request sent by the UA will create NAT bindings
that will allow the incoming SIP request that triggered the push notification to reach the UA.
</t>
<t>
NOTE: The lifetime of any NAT binding created by the REGISTER request only needs to be long enough in order for the
SIP request that triggered the push notification to reach the UA.
</t>
<t>
Different PNSs exist today. Some are based on the 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>
<t>
Each PNS uses PNS-specific terminology and function names. The terminology in this document is meant to
be PNS-independent. If the PNS is based on <xref target="RFC8030"/>, the SIP proxy takes the role of
the application server.
</t>
<t>
The proxy MUST be in the signalling path of REGISTER requests sent by the UA towards the registrar, and of SIP requests (for a new dialog or a stand-alone)
forwarded by the proxy responsible for the UA's domain (sometimes referred to as home proxy, S-CSCF, etc) towards the UA. The proxy can also be co-located with
the proxy responsible for the UA's domain. This will also ensure that the Request-URI of SIP requests (for a new dialog or a stand-alone) can be matched against
contacts in REGISTER requests.
</t>
<figure title="SIP Push Information Flow" anchor="fig-sip-pn-arch"
align="center"><artwork>
<![CDATA[
+--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+
| | | |
| Subscribe | | |
|---------------->| | |
| | | |
| PRID | | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| | | |
| | | |
| | | SIP INVITE (PRID) |
| | |<==================|
| | | |
| |Push Request (PRID) |
| |<-----------------| |
|Push Message (PRID) | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| SIP INVITE | | |
|<===================================| |
| | | |
------- Push Notification API
======= SIP
]]></artwork></figure>
<figure title="SIP REGISTER Example" anchor="fig-sip-pn-reg"
align="center"><artwork>
<![CDATA[
Example of a SIP REGISTER request in the flow above:
REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=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", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="Push Resource ID (PRID)">
<t>
When a SIP UA registers with a PNS it receives a unique Push Resource ID (PRID),
which is a value associated with the registration that can be used to generate
push notifications.
</t>
<t>
The format of the PRID varies depending on the PNS.
</t>
<t>
The details regarding discovery of the PNS, and the procedures regarding 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 of the device.
</t>
</section>
<section anchor="section.ua" title="SIP User Agent (UA) Behavior">
<section anchor="section.ua.reg.req" title="REGISTER">
<t>
This section describes how a SIP UA sends SIP REGISTER requests (initial REGISTER request
for a binding, or a binding-refresh REGISTER request) in order to request and disable
push notifications from a SIP network, and to query the types of PNSs supported by the SIP network.
</t>
<t>
Unless specified otherwise, the normal SIP UA registration procedures <xref target="RFC3261"/> apply.
The additional procedures described in this section apply when the REGISTER request contains a pn-provider SIP URI parameter
in the Contact header field URI of the request.
</t>
<t>
The procedures in this section apply to individual bindings <xref target="RFC3261"/>. If a UA creates multiple bindings
(e.g., one for IPv4 and one for IPv6) the UA needs to perform the procedures for each binding.
</t>
<t>
NOTE: If a SIP UA creates multiple bindings, since a push notification will trigger the UA to refresh all bindings,
it is preferable if one can ensure that all bindings expire at the same time. That will help preventing that some bindings
are refreshed earlier than needed.
</t>
<t>
For privacy and security reasons, a UA MUST NOT insert the SIP URI parameters (except for the pn-purr parameter)
defined in this specification in non-REGISTER request, to prevent the PNS information associated with the UA from reaching
the remote peer. For example, the UA MUST NOT insert the pn-prid SIP URI parameter in the Contact header field URI of an INVITE request.
REGISTER requests will not reach the remote peer, as they will be terminated by the registrar of the UA. However, the registrar
MUST still ensure that the parameters are not sent to other users, e.g., using the SIP event package for
registrations mechanism <xref target="RFC3680"/>. See <xref target="section.sec"></xref> for more information.
</t>
<section anchor="section.ua.req.req.push.req" title="Request Push Notifications">
<t>
This section describes the procedures when a SIP UA requests push notifications from the SIP network.
The procedures assume that the UA has retrieved a PRID from a PNS. The procedures how the
UA retrieves the PRID from the PNS are PNS-specific, and outside the scope of this specification.
See PNS specific documentation for more details.
</t>
<t>
If a SIP UA wants to use push notifications for other usages than to trigger binding-refresh REGISTER requests
(e.g., for sending periodic subscription-refresh SUBSCRIBE requests <xref target="RFC6665"/>), this specification does not
define a mechanism to explicitly request push notifications from the SIP network for such usages, and how to distinguish
push notifications associated with such usages from the push notifications used to trigger binding-refresh REGISTER requests.
However, by using the same refresh interval that is used for the binding-refreshes, the UA can perform actions associated with such usages
(in addition to sending a binding-refresh REGISTER request) whenever it receives a push notification.
</t>
<t>
When a UA requests push notifications, the UA MUST insert the following SIP URI parameters in the SIP Contact header field
URI of the REGISTER request: pn-provider, pn-prid and pn-param (if required for the specific PNS). The pn-provider URI parameter
parameter indicates the type of PNS to be used for the push notifications.
</t>
<t>
If the UA receives a 2xx response to the REGISTER request that contains a Feature-Caps header field <xref target="RFC6809"></xref>
with a 'sip.pns' feature-capability indicator, with a indicator value identifying the same type of PNS that was identified by the pn-provider
URI parameter in the REGISTER request, it indicates that a SIP Proxy in the SIP network will request that push notifications are sent to the UA.
In addition, if the samd Feature-Caps header field contains a 'sip.vapid' feature-capability indicator, it indicates that
the proxy supports use of the Voluntary Application Server Identification (VAPID) mechanism <xref target="RFC8292"></xref> to restrict
push notifications to the UA.
</t>
<t>
NOTE: The VAPID specific procedures of the SIP UA are outside the scope of this document.
</t>
<t>
If the UA receives a non-2xx response to the REGISTER, or if the UA receives a 2xx response that does not contain a Feature-Caps
header field <xref target="RFC6809"></xref> with a 'sip.pns' feature-capability indicator, the UA MUST NOT assume a the proxy will
request that push notifications are sent to the UA. The actions taken by the UA in such cases are outside the scope of this document.
</t>
<t>
If the PRID is only valid for a limited time then the UA is responsible for retrieving a new PRID from the PNS and sending a
binding-refresh REGISTER request with the updated pn- parameters. If a PRID is no longer valid, and the UA is not able to retrieve
a new PRID, the UA MUST disable the push notifications associated with the PRID (<xref target="section.ua.req.req.push.dis"></xref>).
</t>
</section>
<section anchor="section.ua.req.req.push.dis" title="Disable Push Notifications">
<t>
When a UA wants to disable previously requested push notifications, the UA SHOULD remove the binding <xref target="RFC3261"></xref>,
unless the UA is no longer able to perform SIP procedures (e.g., due to a forced shutdown of the UA). When the UA sends the
REGISTER request for removing the binding, the UA MUST include the pn-pric SIP URI parameter in the Contact header field URI
of the REGISTER request, in order to inform the SIP network that the UA no longer wants to receive push notifications associated
with the PRID.
</t>
</section>
<section anchor="section.ua.recv" title="Receive Push Notifications">
<t>
When a UA receives a push notification, the UA MUST send a binding-refresh REGISTER request. The UA MUST insert the same set of pn- SIP URI
parameters in the SIP Contact header field URI of the REGISTER request that it inserted when it requested push notifications
(<xref target="section.ua.req.req.push.req"></xref>). Note that, in some cases the PNS might update the PRID value, in which case the UA will
insert the new value in the pn-prid SIP URI parameter of the binding-refresh REGISTER request.
</t>
<t>
Once the UA has received a 2xx response to the REGISTER request, the UA might receive a SIP request for a new dialog (e.g., a SIP INVITE),
or a stand-alone SIP request (e.g., a SIP MESSAGE), if such SIP request has triggered a proxy to request that the push notification
is sent to the UA.. Note that, depending on which transport protocol is used, the SIP request might reach the UA before the REGISTER response.
</t>
<t>
If the SIP UA has created multiple bindings, the UA MUST send a binding-refresh REGISTER request for each of those bindings when it receives
a push notification.
</t>
<t>
This specification does not define any usage of push notification payload. If a SIP UA receives a push notification that contains a payload
the UA can discard the payload, but the UA will still send a binding-refresh REGISTER request.
</t>
</section>
<section anchor="section.ua-non-push" title="Sending Binding-Refresh Requests Using Non-Push Mechanism">
<t>
If a UA is able to send binding-refresh REGISTER requests using a non-push mechanism (e.g., using
an internal timer that periodically wakes the UA) the UA MUST insert a 'sip.pnsreg' media feature tag
<xref target="RFC3840"></xref> in the Contact header field of each REGISTER request.
</t>
<t>
If the UA receives a 2xx response to the REGISTER request that contains a Feature-Caps header field with a 'sip.pnsreq'
feature-capability indicator, the UA MUST send a binging-refresh REGISTER request prior to binding expiration. The indicator
value indicates the minimum time (given in seconds), prior to the binding expiration when the UA MUST send the REGISTER request.
</t>
<t>
If the UA receives a 2xx response to the REGISTER request that does not contain a Feature-Caps header field with a 'sip.pnsreq'
feature-capability indicator, the UA SHOULD only send a binding-refresh REGISTER request when it receives a push notification (even if
the UA is able to use a non-push mechanism for sending binding-refresh REGISTER requests), or when there are circumstances (e.g., if the
UA is assigned new contact parameters due to a network configuration change) that require an immediate REGISTER request to be sent.
</t>
<t>
Even if the UA is able to to send binding-refresh REGISTER requests using a non-push mechanism, the UA MUST still send a binding-refresh REGISTER
request whenever it receives a push notification (<xref target="section.ua.recv"></xref>).
</t>
<t>
NOTE: If the UA uses a non-push mechanism to wake and send a binding-refresh REGISTER request, such REGISTER
request will update the binding expiration timer, and the proxy does not need to request that a push notification is sent
to the UA in order to wake the UA. The proxy will still request that a push notification is sent to the UA when the proxy receives
a SIP request addressed towards the UA (<xref target="section.proxy.req.oth"></xref>). This allows the UA to e.g., use timers for sending
binding-refresh REGISTER requests, but to be suspended (in order to save battery resources etc) between sending
the REGISTER requests and use push notification to wake the UA to process incoming calls.
</t>
</section>
<section anchor="section.ua.que" title="Query Network PNS Capabilities">
<t>
This section describes how a SIP UA can query the types of PNSs supported by a SIP network, and PNS-related capabilities (e.g., support
of the VAPID mechanism). When a UA performs a query, it does not request push notifications from the SIP network. Therefore, the UA
can perform the query before it has registered to a PNS and received a PRID.
</t>
<t>
In order to perform a query, the UA MUST insert a pn-provider SIP URI parameter in the Contact header field URI of the REGISTER request:
<list>
<t>
If the UA inserts a pn-provider parameter value, indicating support of a type of PNS, the SIP network will only inform the UA whether that
type of PNS is supported.
</t>
<t>
If the UA does not insert a pn-provider parameter value (i.e., it inserts an "empty pn-provider parameter") the SIP network will inform
the UA about all types of PNSs supported by the network. This is useful e.g., if the UA supports more than one type of PNS. Note that
it is not possible to insert multiple parameter values in the pn-provider parameter.
</t>
</list>
</t>
<t>
The UA MUST NOT insert a pn-prid SIP URI parameter in the Contact header field URI of the REGISTER request.
</t>
<t>
If the UA receives a 2xx response to the REGISTER request, the response will contain one or more Feature-Caps header fields with
a 'sip.pns' feature-capability indicator, indicating the types of PNSs supported by the SIP network. If the UA inserted a pn-provider
SIP URI parameter value in the REGISTER request, the response will only indicate whether the SIP network supports the type of PNS
supported by the UA.
</t>
<t>
If the UA receives a 555 (Push Notification Service Not Supported) response to the REGISTER request, the response will contain
the response will contain one or more Feature-Caps header fields with a 'sip.pns' feature-capability indicator, indicating the types
of PNSs supported by the SIP network.
</t>
<t>
NOTE: It is optional for a UA to perform a query before it requests push notifications from the SIP network.
</t>
</section>
</section>
</section>
<section anchor="section.proxy" title="SIP Proxy Behavior">
<section anchor="section.proxy.pnid" title="PNS Provider">
<t>
The type of PNS is identified by the pn-provider SIP URI parameter. In some cases there might
only be one PNS provider for a given type of PNS, while in other cases there might be multiple
providers. The pn-param SIP URI parameter will provide more details associated with the actual
PNS provider to be used.
</t>
<t>
The protocol and format used for the push notification requests are PNS-specific,
and the details for constructing and sending a push notification request are outside
the scope of this specification.
</t>
</section>
<section anchor="section.proxy.queue" title="SIP Request Push Queue">
<t>
When a SIP proxy receives a SIP request, addressed towards a UA, that will trigger the proxy to request that a push
notification is sent to the UA, the proxy will place the request in a queue referred to as the
SIP Request Push Queue. A SIP request is removed from the queue once the proxy either forwards the request towards
the UA or when the proxy sends an error response to the request. The detailed procedures are described in the sections below.
</t>
<t>
Exactly how the SIP Request Push Queue is implemented is outside the scope of this document. One option is to
use the PRID as a key to search for SIP requests in the queue. Note that mid-dialog requests
(<xref target="section.subscription"></xref>) do not carry the PRID in the SIP request itself.
</t>
</section>
<section anchor="section.proxy.compare" title="SIP URI Comparison Rules">
<t>
When a SIP proxy compares two SIP URIs, the proxy uses the URI comparison rules defined
in <xref target="RFC3261"></xref>, meaning that in order for a comparison to be successful
the pn-prid, pn-provider and pn-param SIP URI parameters must also match.
</t>
<t>
If only the pn- SIP URI parameters listed above match, but other parts of the compared URIs
do not match, a proxy MAY still consider the comparison successful, based on local policy.
This can occur in a race condition when the proxy compares the Contact header field URI
of a 2xx response to a REGISTER request with a Request-URI of a SIP request in the
SIP Request Push Queue (<xref target="section.proxy.queue"></xref>), if the UA that sent
the associated REGISTER request modified some parts of the Contact header field URI
in the REGISTER request, but the Request-URI of the SIP request in the SIP Request Push Queue
still contains the old parts.
</t>
</section>
<section anchor="section.proxy.indicate" title="Indicate Support of Type of PNS">
<t>
A SIP proxy uses feature-capability indicators <xref target="RFC6809"/> to indicate support of types of PNSs,
and additional features (e.g., VAPID) associated associated with a type of PNS. A proxy MUST use a separate
Feature-Cap header fields for each supported type of PNS. A feature-capability indicator that indicates support
of an additional feature associated with a given type of PNS MUST be inserted in the same Feature-Caps header field
that is used to indicate support of the type of PNS.
</t>
<t>
This specification defines the following feature-capability indicators that a proxy can use to indicate support of
additional features associated with a given type of PNS: 'sip.vapid', 'sip.pnsreg' and 'sip.pnspurr'. These
feature-capability indicators MUST only be inserted in a Feature-Caps header field that also contains a 'sip.pns'
feature-capability indicator.
</t>
</section>
<section anchor="section.proxy.rereg" title="Trigger Periodic Binding Refresh">
<t>
In order to request that a push notification is sent to a SIP UA, a SIP proxy needs to have information about when a binding
will expire. The proxy needs to be able to retrieve the information from the registrar using some mechanism, or run its own
registration timers. Such mechanisms are outside the scope of this document, but could be implemented e.g., using the SIP event package
for registrations mechanism <xref target="RFC3680"/>.
</t>
<t>
When the proxy receives an indication that the UA needs to send a binding-refresh REGISTER
request, the proxy will request that a push notification is sent to the UA.
</t>
<t>
Note that the push notification needs to be requested early enough for the associated
binding-refresh REGISTER request to reach the registrar before the binding expires. It is
RECOMMENDED that the proxy requests the push notification at least 120 seconds before the binding
expires.
</t>
<t>
If the UA has indicated, using the 'sip.pnsreg' media feature tag, that it is able to wake using
a non-push mechanism in order to send binding-refresh REGISTER requests, and if the proxy does not receive
a REGISTER request prior to 120 seconds before the binding expires, the proxy MAY request that a
push notification is sent to the UA, to trigger the UA to send a binding-refresh REGISTER request.
</t>
<t>
NOTE: As described in <xref target="section.ua.que"></xref>, a UA might send a REGISTER request
without including a pn-prid SIP URI parameter, in order to retrieve push notification capabilities from
the network before the UA expects to receive push notifications from the network.
A proxy will not request that push notifications are sent to a UA that has not provided a pn-prid SIP URI parameter
(<xref target="section.proxy.req.oth"></xref>).
</t>
<t>
If the proxy receives information that a binding associated with a PRID has expired, or that a binding has been removed, the proxy
MUST NOT request that further push notifications are sent to the UA using that PRID.
</t>
</section>
<section anchor="section.proxy.reg" title="SIP Requests">
<section anchor="section.proxy.req.reg" title="REGISTER">
<t>
This section describes how a SIP proxy processes SIP REGISTER requests (initial REGISTER request
for a binding, or a binding-refresh REGISTER request).
</t>
<t>
The procedures in this section apply when the REGISTER request contains a pn-provider SIP URI parameter
in the Contact header field URI of the request. In other cases the proxy MUST skip the procdures
in this section, and process the REGISTER request using normal SIP procedures.
</t>
<section anchor="section.proxy.req.reg.push" title="Request Push Notifications">
<t>
This section describes the SIP proxy procedures when a SIP UA requests push notifications from the SIP network.
</t>
<t>
The procedures in this section apply when the SIP REGISTER request contains, in addition to the pn-provider SIP URI parameter,
a pn-prid SIP URI parameter in the Contact header field URI of the request.
</t>
<t>
When a proxy receives a REGISTER request, if the REGISTER request contains a Feature-Caps header field
with a 'sip.pns' feature-capability indicator, it indicates that a proxy between this proxy and the UA supports
the type of PNS supported by the UA, and will request that push notifications are sent to the UA. In such case,
the proxy MUST skip the rest of the procedures in this section, and process the REGISTER request using normal
SIP procedures.
</t>
<t>
When a proxy receives a REGISTER request, and the request does not contain a Feature-Caps header field
with a 'sip.pns' feature-capability indicator, the proxy processes the request according to the procedures below:
<list style="symbols">
<t>
If the proxy does not support the type of PNS supported by the UA, or if the REGISTER request does not contain all
information required for the type of PNS, the proxy SHOULD forward the request towards the registrar and skip the
rest of the procedures in this section. If the proxy knows (by means of local configuration) that no other proxies
between itself and the registrar support the type of PNS supported by the UA, the proxy MAY send a
SIP 555 (Push Notification Service Not Supported) response instead of forwarding the request.
</t>
<t>
If the proxy supports the type of PNS supported by the UA, but considers the requested binding expiration interval <xref target="RFC3261"/>
to be too short (see below), the proxy MUST either send a 423 (Interval Too Brief) response to the REGISTER request
or forward the request towards the registrar and skip the rest of the procedures in this section. If the proxy sends a 423 (Interval Too Brief)
response, the proxy SHOULD insert one or more Feature-Caps header fields with a 'sip.pns' feature-capability indicator
in the response, indicating each type of PNS that the proxy supports.
</t>
<t>
If the proxy supports the type of of PNS supported by the UA, the proxy MUST indicate support of that type of PNS
(<xref target="section.proxy.indicate"></xref>) in the REGISTER request before it forwards the request towards the registrar.
This will inform proxies between the proxy and the registrar that the proxy supports the type of PNS supported by the UA,
and that the proxy will request that push notifications are sent to the UA.
</t>
</list>
</t>
<t>
A binding expiration interval MUST be considered too short if the the binding would expire before the proxy would request
that a push notification is sent to the UA, in order to trigger the UA to send a binding-refresh REGISTER request. The proxy
MAY consider the interval too short based on its own policy so as to reduce load on the system.
</t>
<t>
If the proxy sends a SIP 555 (Push Notification Service Not Supported) response, the proxy SHOULD indicate each type
of PNS that the proxy supports in the response.
</t>
<t>
When a proxy receives a 2xx response to the REGISTER request, if the proxy indicated support of a type of PNS in the
REGISTER request (see above), the proxy performs the following actions:
<list style="symbols">
<t>
If the proxy considers the binding expiration interval indicated by the registrar too short (see above),
the proxy forwards the response towards the UA and MUST skip the rest of the procedures in this section.
</t>
<t>
The proxy MUST indicate support of the same type of PNS in the REGISTER response. In addition:
<list style="symbols">
<t>
If the proxy supports the VAPID mechanism <xref target="RFC8292"></xref>, the proxy MUST indicate support
of the mechanism, using the 'sip.vapid' feature-capability indicator, in the REGISTER response. The indicator
value contains the public key identifying the proxy . The proxy MUST determine whether the PNS provider supports the
VAPID mechanism before it indicates support of it.
</t>
<t>
If the proxy received a 'sip.pnsreg' media feature tag in the REGISTER request, the proxy SHOULD insert a 'sip.pnsreg'
feature-capability indicator with an indicator value bigger than 120 in the response, unless the proxy always wants
to request that push notifications are sent to the UA in order to trigger the UA to send a binding-refresh REGISTER request.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="section.proxy.req.reg.que" title="Query Network PNS Capabilities">
<t>
This section describes the SIP proxy procedures when a SIP UA queries about the push notification support in the SIP network
(<xref target="section.ua.que"></xref>).
</t>
<t>
The procedures in this section apply when the REGISTER request contains a pn-provider SIP URI parameter,
but does not contain a pn-prid SIP URI parameter, in the Contact header field URI of the REGISTER request.
</t>
<t>
When a proxy receives a REGISTER request, if the pn-provider SIP URI parameter contains a parameter value
that indicates the type of PNS supported by the UA, the proxy MUST perform the following actions:
<list>
<t>
If the proxy supports the type of of PNS supported by the UA, the proxy MUST indicate support of that type of PNS
(<xref target="section.proxy.indicate"></xref>) in the REGISTER request before it forwards the request towards the registrar.
This will inform proxies betwen the proxy and the registrar that the proxy supports the type of PNS supported by the UA.
</t>
<t>
If the proxy does not support the type of PNS supported by the UA, and if the REGISTER request contains Feature-Caps
header fields indicating support of one or more types of PNSs, the proxy forwards the request towards
the registrar.
</t>
<t>
If the proxy does not support the type of PNS supported by the UA, and if the REGISTER
request does not contain Feature-Caps header fields indicating support of one or more types of PNSs,
the proxy MUST either forward the request towards the registrar, or send a SIP 555 (Push Notification Service Not Supported)
response towards the UA. The proxy MUST NOT send a SIP 555 (Push Notification Service Not Supported) response unless
it knows (by means of local configuration) that no other proxy supports any of the types of PNSs supported by the UA.
</t>
</list>
</t>
<t>
If the proxy sends a SIP 555 (Push Notification Service Not Supported) response, the proxy SHOULD indicate each type
of PNS that the proxy supports in the response.
</t>
<t>
When a proxy receives a REGISTER request, if the pn-provider SIP URI parameter does not contain a parameter value, the
proxy MUST indicate support of each type of PNS supported by the proxy before it forwards the request towards the registrar.
</t>
<t>
When a proxy receives a 2xx response to the REGISTER request, if the proxy indicated support of one or more types of PNSs
in the REGISTER request (see above), the proxy MUST indicate support of the same set of types of PNSs in the response.
In addition, if the proxy supports the VAPID mechanism for one or more types of PNSs, the proxy MUST indicate support of
the mechanism for thoses PNSs in the response.
</t>
</section>
</section>
<section anchor="section.proxy.req.oth" title="Initial Request for Dialog or Stand-Alone Request">
<t>
The procedures in this section apply when a SIP proxy has indicated that the it will request that push notifications
are sent to the SIP UA.
</t>
<t>
When the proxy receives a SIP request for a new dialog (e.g., a SIP INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE request)
addressed towards a SIP UA, if the Request-URI of the request contains a pn-provider, a pn-prid and a pn-param (if required for the specific PNS provider)
SIP URI parameter, the proxy requests that a push notification is sent to the UA, using the information in the pn- SIP URI parameters. The proxy then places
the SIP request in the SIP Request Push Queue (<xref target="section.proxy.queue"/>). The push notification will trigger the UA to send a binding-refresh REGISTER request,
that the proxy will process as described in <xref target="section.proxy.req.reg"/>. In addition, the proxy MUST store the Contact URI of the REGISTER request during the
lifetime of the REGISTER transaction.
</t>
<t>
NOTE: If the proxy receives a SIP request does not contain the pn- SIP URI parameters listed above, the proxy processing
of the request is based on local policy. If the proxy also serves requests for UAs that do not use the SIP push mechanism,
the proxy can forward the request towards the UA. Otherwise the proxy can reject the request.
</t>
<t>
When the proxy receives a 2xx response to the REGISTER request, the proxy performs the following actions:
<list>
<t>
The proxy processes the REGISTER response as described in <xref target="section.proxy.req.reg"/>.
</t>
<t>
The proxy checks whether the SIP Request Push Queue contains a SIP request associated with the REGISTER transaction. If the
queue contains such request the proxy compares (<xref target="section.proxy.compare"></xref>) the Contact header field URI
in the REGISTER response with the Request-URIs of the SIP requests in the queue. If there is a match, the proxy MUST remove
the SIP request from the waiting queue and forward it towards the UA.
</t>
</list>
</t>
<t>
The reason the proxy needs to wait for the REGISTER response before forwarding a SIP request towards a UA is to make sure
that the REGISTER request has been accepted by the registrar, and that the UA that initiated the REGISTER request is
authorized to receive messages for the Request-URI.
</t>
<t>
If the proxy receives a non-2xx response to the REGISTER request, the proxy compares the Contact URI stored from the
REGISTER request (see above) with the Request-URIs of the SIP requests in the SIP Request Push Queue. If there is a match,
the proxy SHOULD remove the associated request from the queue and send an error response to the request. It is RECOMMENDED
that the proxy sends either a 404 (Not Found) response or a 480 (Temporarily Unavailable) response to the SIP request, but
other response codes can be used as well. However, if the REGISTER response is expected to trigger a new REGISTER request
from the UA (e.g., if the registrar is requesting the UA to perform authentication) the proxy MAY keep the SIP request in
the queue.
</t>
<t>
If the push notification request fails (see PNS-specific documentation for details), the proxy MUST remove the SIP request
from the queue and send an error response to the SIP request. It is RECOMMENDED that the proxy sends either a 404 (Not Found)
response or a 480 (Temporarily Unavailable) response, but other response codes can be used as well.
</t>
<t>
When the proxy has requested that a push notification is sent to a UA, if the proxy does not receive a REGISTER response
with a Contact URI that matches the Request-URI of the SIP request, the transaction timer of the SIP request will eventually
time out. When that happens the proxy MUST remove the SIP request from the queue and send a 480 (Temporarily Unavailable) response. The timer expiration value is set based
on local policy, taking the guidelines below into consideration.
</t>
<t>
As discussed in <xref target="RFC4320"/> and <xref target="RFC4321"/>, non-INVITE transactions must complete immediately or risk losing a race that results
in stress on intermediaries and state misalignment at the endpoints. The mechanism defined in this document inherently delays the final response to any
non-INVITE request that requires a push notification. In particular, while waiting for the push notification request
to succeed, and the associated REGISTER request to arrive from the SIP UA, the proxy needs to take into consideration that the transaction associated
with the SIP request will eventually time out at the sender of the request (UAC), and the sender will consider the transaction a failure. If the proxy
forwards the SIP request towards the SIP UA, the SIP UA accepts the request and the transaction times out at the sender before it receives the successful
response, this will cause state misalignment between the endpoints (the sender will consider the transaction a failure, while the receiver will consider
the transaction a success). The SIP proxy needs to take this into account when deciding for how long to wait before it considers the transaction associated
with the SIP request a failure, to make sure that the error response reaches the sender before the transaction times out. If the accumulated delay of this
mechanism combined with any other mechanisms in the path of processing the non-INVITE transaction is not kept short, this mechanism should not be used.
For networks encountering such conditions, an alternative (left for possible future work) would be for the proxy to immediately return an new error code
meaning "wait at least the number of seconds specified in this response, and retry your request" before initiating the push notification.
</t>
<t>
NOTE: While this work on this document was ongoing, implementation test results showed that the time it takes for a proxy to receive the REGISTER request, from when the proxy has
requested a push notification, is typically around 2 seconds. However, the time might vary depending on the characteristics and load of the SIP network and the PNS.
</t>
<t>
In addition to the procedures described above there are two cases where a proxy, as an optimization, can forward a SIP request towards a UA
without waiting for a 2xx response to a REGISTER request, or without even requesting that a push notification is sent to the UA:
<list>
<t>
If the proxy is able to authorize the sender of the REGISTER request, the proxy does not need to wait for the 2xx response before it
forwards the SIP request towards the UA. In such cases, the proxy will use the Contact URI of the REGISTER request when comparing it
against the Request-URIs of the SIP requests in the SIP Request Push Queue.
</t>
<t>
If the proxy has knowledge that the UA is awake, and that the UA is able to receive the SIP request without first
sending a binding-refresh REGISTER request, the proxy does not need to request that a push notification is sent
to the UA (the UA will not send a binding-refresh REGISTER request) before it forwards the SIP request
towards the UA. The mechanisms for getting such knowledge might be dependent on implementation or deployment architecture,
and are outside the scope of this document.
</t>
</list>
</t>
<t>
Some PNS providers allow payload in the push notifications. This specification does not define usage of such
payload (in addition to any payload that might be required by the PNS itself).
</t>
</section>
</section>
</section>
<section anchor="section.subscription" title="Support Of Longlived SIP Dialogs">
<t>
Some SIP dialogs might have a long lifetime, with little activity. For example, when
the SIP event notification mechanism <xref target="RFC6665"/> is used, there might be a
long period between mid-dialog requests are sent. Because of this a SIP UA might get
suspended, and needs to be awaken in order to be able to receive mid-dialog requests.
</t>
<t>
When the proxy receives a SIP request for a new dialog, or a stand-alone SIP request, addressed
towards a UA, the request will contain information (pn- SIP URI parameters) that allows proxy
to request that a push notification is sent to the UA <xref target="section.proxy.req.oth"/>. However,
this information will not be present in mid-dialog requests addressed towards the UA. Instead, the proxy
need to support a mechanism where it stores the information needed to request that a push notification
is sent to the UA, and to be able to retrieve that information when it receives a mid-dialog
request addressed towards the UA. This section defines such mechanism. This section describes such
mechanism. The SIP UA and SIP proxy procedures in this section are applied in addition to the generic
procedures defined in this specification.
</t>
<figure title="SIP Push Longlived Dialog Flow" anchor="fig-sip-pn-mid"
align="center"><artwork>
<![CDATA[
+--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+
| | | |
| Subscribe | | |
|---------------->| | |
| | | |
| PRID | | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | +-----------------------+ |
| | | Store PRID (key=PURR) | |
| | +-----------------------+ |
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK (PURR) | |
|<===================================| |
| | | |
| | | |
| SIP INVITE (PURR) | |
|===================================>| |
| | |SIP INVITE (PURR) |
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| | | |
| | | |
| | |SIP UPDATE (PURR) |
| | |<==================|
| | | |
| | +-----------------------+ |
| | | Fetch PRID (key=PURR) | |
| | +-----------------------+ |
| | | |
| |Push Request (PRID) |
| |<-----------------| |
|Push Message (PRID) | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| SIP UPDATE | | |
|<===================================| |
| | | |
------- Push Notification API
======= SIP
]]></artwork></figure>
<section anchor="section.subscription.ua" title="SIP UA Behavior">
<section anchor="section.subscription.ua.sub" title="Initial Request for Dialog">
<t>
When a UA sends an initial request for a dialog, or a 2xx response to such requests, if the UA is
willing to receive push notifications when a proxy receives a mid-dialog request addressed towards the UA,
the UA MUST insert a 'pn-purr' SIP URI parameter in the Contact header field URI of the request or response.
The UA MUST insert a parameter value identical to the the last 'sip.pnspurr' feature-capability indicator
that it received in a REGISTER response (<xref target="section.subscription.proxy.reg"/>). If the UA has
not recived a 'sip.pnspurr' feature-capability indicator, the UA MUST NOT insert a 'pn-purr' SIP URI
parameter in a request or response.
</t>
<t>
The UA decision whether it is willing to receive push notifications triggered by incoming mid-dialog requests
is done based on local policy. Such policy might be based on the type of SIP dialog, the type of media (if any)
negotiated for the dialog <xref target="RFC3264"/>, etc.
</t>
<t>
NOTE: As the 'pn-purr' SIP URI parameter only applies to a given dialog, the UA needs to insert a 'pn-purr' parameter
in the Contact header field URI of the request or response for each dialog in which the UA is willing to receive
push notifications triggered by incoming mid-dialog requests.
</t>
</section>
</section>
<section anchor="section.subscription.proxy" title="SIP Proxy Behavior">
<section anchor="section.subscription.proxy.reg" title="REGISTER">
<t>
When a proxy receives an initial REGISTER request for a binding from the UA, if the proxy supports
requesting that push notifications triggered by mid-dialog requests are sent to the registered UA, the proxy MUST
store the information (the pn- SIP URI parameters) needed to request that push notifications are sent to the UA.
In addition, the proxy MUST generate a unique (within the context of the proxy) value, referred to as
the PURR (Proxy Unique Registration Reference), that can be used as a key to retrieve the information.
</t>
<t>
In order to prevent client fingerprinting, the proxy MUST periodically generate a new PURR value
(even if pn- parameters did not change). However, as long as there are ongoing dialogs associated with
the old value, the proxy MUST store it so that it can request that push notifications
are sent to the UA when it receives a mid-dialog request addressed towards the UA. In addition,
the PURR value MUST be generated in such a way so that it cannot be used to retrieve information
about the user or associate it with registrations. It can be generated e.g., by utilizing a cryptographically
secure random function.
</t>
<t>
Whenever the proxy receives a 2xx response to a REGISTER request, the proxy MUST insert a 'sip.pnspurr'
feature-capability indicator with the latest PURR value (see above) in the response.
</t>
<t>
</t>
</section>
<section anchor="section.subscription.proxy.sub" title="Initial Request for Dialog">
<t>
When a proxy receives an initial request for a dialog from a UA, if the request contains a 'pn-purr' SIP URI parameter
in the Contact header field URI of the request with a PURR value that the proxy has generated
(<xref target="section.subscription.proxy.sub"/>), the proxy MUST add a Record-Route header to the request,
to insert itself in the dialog route <xref target="RFC3261"/> before forwarding the request.
</t>
<t>
When the proxy receives an initial request for a dialog addressed towards the UA, if the proxy has generated
a PURR value associated with the pn- parameters inserted in the SIP URI of the
request <xref target="section.subscription.proxy.sub"/>, the proxy MUST add a Record-Route header to the request,
to insert itself in the dialog route <xref target="RFC3261"/> before forwarding the request.
</t>
</section>
<section anchor="section.subscription.proxy.not" title="Mid-Dialog Request">
<t>
When the proxy receives a mid-dialog SIP request addressed towards the UA, if the request contains
a 'pn-purr' SIP URI parameter and if the proxy is able to retrieve the stored information needed to request
that a push notification is sent the UA (<xref target="section.subscription.proxy.reg"></xref>), the proxy MUST
place the SIP request in the SIP Request Push Queue and request that a push notification is sent to the UA.
</t>
<t>
NOTE: The 'pn-purr' SIP URI parameter will either be carried in the Request-URI or in a Route header field
<xref target="RFC3261"/> of the SIP request, depending on how the route set <xref target="RFC3261"/> of the
mid-dialog SIP request has been constructed.
</t>
<t>
When the proxy receives a 2xx response to a REGISTER request, the proxy checks whether the SIP Request Push Queue
contains a mid-dialog SIP request associated with the REGISTER transaction. If the queue contains such request
the proxy MUST remove the SIP request from the waiting queue and forward it towards the UA.
</t>
<t>
Note that the proxy does not perform a URI comparison (<xref target="section.proxy.compare"/>) when processing
mid-dialog requests, as a mid-dialog request will not contain the pn-prid, pn-provider and pn-param SIP URI parameters.
The proxy only checks for a mid-dialog request that contains the PURR value associated with the REGISTER 2xx response.
</t>
<t>
As described in <xref target="section.proxy.req.oth"></xref>, while waiting for the push notification request to
succeed, and the associated REGISTER request and 2xx response, the proxy needs to take into consideration
that the transaction associated with the mid-dialog request will eventually time out at the sender of the request (UAC),
and the sender will consider the transaction a failure.
</t>
<t>
When a proxy sends an error response to a mid-dialog request (e.g., due to a transaction time out), the proxy SHOULD
select a response code that only impacts the transaction associated with the request (<xref target="RFC5079"/>).
</t>
</section>
</section>
</section>
<section anchor="section.replaces" title="Support Of SIP Replaces">
<t>
<xref target="RFC3891"/> defines a mechanism that allows a SIP UA to replace a dialog
with another dialog. A UA that wants to replace a dialog with another one will send
an initial request for the new dialog. The Request-URI of the request will contain
Contact header field URI of the peer.
</t>
<t>
If a SIP proxy wants to be able to request that a push notification is sent to a UA when it receives an initial
request for a dialog that replaces an existing dialog, using the mechanism in <xref target="RFC3891"/>, the proxy
and the UA MUST perform the following actions:
<list style="symbols">
<t>
The proxy MUST provide a PURR to the UA during registration <xref target="section.subscription.proxy.reg"></xref>.
</t>
<t>
The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact header field URI of the initial request
for a dialog, or a 2xx response to such requests <xref target="section.subscription.ua.sub"></xref>. This
includes dialogs replacing other dialogs, as those dialogs might also get replaced.
</t>
<t>
The proxy MUST apply the mechanism defined in <xref target="section.subscription.proxy.not"></xref> to place
and retrieve the request from the waiting queue.
</t>
</list>
</t>
<t>
In addition, the operator needs to make sure that the initial request for dialogs, addressed towards the UA using the
contact of the replaced dialog, will be routed to the SIP proxy (in order to request that a push notification is sent
to the UA). The procedures for doing that are operator specific, and are outside the scope of this specification.
</t>
</section>
<section anchor="section.grammar" title="Grammar">
<section anchor="section.grammar.555" title="555 (Push Notification Service Not Supported) Response Code">
<t>
The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to indicate
that the server did not support the push notification service identified in a
'pn-provider' SIP URI parameter.
</t>
<t>
The use of the SIP 555 response code is only defined for SIP REGISTER responses.