File: rfc3262.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (787 lines) | stat: -rw-r--r-- 29,643 bytes parent folder | download | duplicates (5)
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






Network Working Group                                       J. Rosenberg
Request for Comments: 3262                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                             Columbia U.
                                                               June 2002


                 Reliability of Provisional Responses
               in the Session Initiation Protocol (SIP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document specifies an extension to the Session Initiation
   Protocol (SIP) providing reliable provisional response messages.
   This extension uses the option tag 100rel and defines the Provisional
   Response ACKnowledgement (PRACK) method.

Table of Contents

   1     Introduction ........................................    2
   2     Terminology .........................................    3
   3     UAS Behavior ........................................    3
   4     UAC Behavior ........................................    6
   5     The Offer/Answer Model and PRACK ....................    9
   6     Definition of the PRACK Method ......................   10
   7     Header Field Definitions ............................   10
   7.1   RSeq ................................................   10
   7.2   RAck ................................................   11
   8     IANA Considerations .................................   11
   8.1   IANA Registration of the 100rel Option Tag ..........   11
   8.2   IANA Registration of RSeq and RAck Headers ..........   12
   9     Security Considerations .............................   12
   10    Collected BNF .......................................   12
   11    Acknowledgements ....................................   12
   12    Normative References ................................   13
   13    Informative References ..............................   13



Rosenberg & Schulzrinne     Standards Track                     [Page 1]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   14    Authors' Addresses ..................................   13
   15.   Full Copyright Statement.............................   14

1 Introduction

   The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a request-
   response protocol for initiating and managing communications
   sessions.  SIP defines two types of responses, provisional and final.
   Final responses convey the result of the request processing, and are
   sent reliably.  Provisional responses provide information on the
   progress of the request processing, but are not sent reliably in RFC
   3261.

   It was later observed that reliability was important in several
   cases, including interoperability scenarios with the PSTN.
   Therefore, an optional capability was needed to support reliable
   transmission of provisional responses.  That capability is provided
   in this specification.

   The reliability mechanism works by mirroring the current reliability
   mechanisms for 2xx final responses to INVITE.  Those requests are
   transmitted periodically by the Transaction User (TU) until a
   separate transaction, ACK, is received that indicates reception of
   the 2xx by the UAC.  The reliability for the 2xx responses to INVITE
   and ACK messages are end-to-end.  In order to achieve reliability for
   provisional responses, we do nearly the same thing.  Reliable
   provisional responses are retransmitted by the TU with an exponential
   backoff.  Those retransmissions cease when a PRACK message is
   received.  The PRACK request plays the same role as ACK, but for
   provisional responses.  There is an important difference, however.
   PRACK is a normal SIP message, like BYE.  As such, its own
   reliability is ensured hop-by-hop through each stateful proxy.  Also
   like BYE, but unlike ACK, PRACK has its own response.  If this were
   not the case, the PRACK message could not traverse proxy servers
   compliant to RFC 2543 [4].

   Each provisional response is given a sequence number, carried in the
   RSeq header field in the response.  The PRACK messages contain an
   RAck header field, which indicates the sequence number of the
   provisional response that is being acknowledged.  The acknowledgments
   are not cumulative, and the specifications recommend a single
   outstanding provisional response at a time, for purposes of
   congestion control.








Rosenberg & Schulzrinne     Standards Track                     [Page 2]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


2 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
   indicate requirement levels for compliant SIP implementations.

3 UAS Behavior

   A UAS MAY send any non-100 provisional response to INVITE reliably,
   so long as the initial INVITE request (the request whose provisional
   response is being sent reliably) contained a Supported header field
   with the option tag 100rel.  While this specification does not allow
   reliable provisional responses for any method but INVITE, extensions
   that define new methods that can establish dialogs may make use of
   the mechanism.

   The UAS MUST send any non-100 provisional response reliably if the
   initial request contained a Require header field with the option tag
   100rel.  If the UAS is unwilling to do so, it MUST reject the initial
   request with a 420 (Bad Extension) and include an Unsupported header
   field containing the option tag 100rel.

   A UAS MUST NOT attempt to send a 100 (Trying) response reliably.
   Only provisional responses numbered 101 to 199 may be sent reliably.
   If the request did not include either a Supported or Require header
   field indicating this feature, the UAS MUST NOT send the provisional
   response reliably.

      100 (Trying) responses are hop-by-hop only.  For this reason, the
      reliability mechanisms described here, which are end-to-end,
      cannot be used.

   An element that can act as a proxy can also send reliable provisional
   responses.  In this case, it acts as a UAS for purposes of that
   transaction.  However, it MUST NOT attempt to do so for any request
   that contains a tag in the To field.  That is, a proxy cannot
   generate reliable provisional responses to requests sent within the
   context of a dialog.  Of course, unlike a UAS, when the proxy element
   receives a PRACK that does not match any outstanding reliable
   provisional response, the PRACK MUST be proxied.

   There are several reasons why a UAS might want to send a reliable
   provisional response.  One reason is if the INVITE transaction will
   take some time to generate a final response.  As discussed in Section
   13.3.1.1 of RFC 3261, the UAS will need to send periodic provisional
   responses to request an "extension" of the transaction at proxies.
   The requirement is that a proxy receive them every three minutes, but



Rosenberg & Schulzrinne     Standards Track                     [Page 3]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   the UAS needs to send them more frequently (once a minute is
   recommended) because of the possibility of packet loss.  As a more
   efficient alternative, the UAS can send the response reliably, in
   which case the UAS SHOULD send provisional responses once every two
   and a half minutes.  Use of reliable provisional responses for
   extending transactions is RECOMMENDED.

   The rest of this discussion assumes that the initial request
   contained a Supported or Require header field listing 100rel, and
   that there is a provisional response to be sent reliably.

   The provisional response to be sent reliably is constructed by the
   UAS core according to the procedures of Section 8.2.6 of RFC 3261.
   In addition, it MUST contain a Require header field containing the
   option tag 100rel, and MUST include an RSeq header field.  The value
   of the header field for the first reliable provisional response in a
   transaction MUST be between 1 and 2**31 - 1.  It is RECOMMENDED that
   it be chosen uniformly in this range.  The RSeq numbering space is
   within a single transaction.  This means that provisional responses
   for different requests MAY use the same values for the RSeq number.

   The reliable provisional response MAY contain a body.  The usage of
   session descriptions is described in Section 5.

   The reliable provisional response is passed to the transaction layer
   periodically with an interval that starts at T1 seconds and doubles
   for each retransmission (T1 is defined in Section 17 of RFC 3261).
   Once passed to the server transaction, it is added to an internal
   list of unacknowledged reliable provisional responses.  The
   transaction layer will forward each retransmission passed from the
   UAS core.

      This differs from retransmissions of 2xx responses, whose
      intervals cap at T2 seconds.  This is because retransmissions of
      ACK are triggered on receipt of a 2xx, but retransmissions of
      PRACK take place independently of reception of 1xx.

   Retransmissions of the reliable provisional response cease when a
   matching PRACK is received by the UA core.  PRACK is like any other
   request within a dialog, and the UAS core processes it according to
   the procedures of Sections 8.2 and 12.2.2 of RFC 3261.  A matching
   PRACK is defined as one within the same dialog as the response, and
   whose method, CSeq-num, and response-num in the RAck header field
   match, respectively, the method from the CSeq, the sequence number
   from the CSeq, and the sequence number from the RSeq of the reliable
   provisional response.





Rosenberg & Schulzrinne     Standards Track                     [Page 4]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   If a PRACK request is received by the UA core that does not match any
   unacknowledged reliable provisional response, the UAS MUST respond to
   the PRACK with a 481 response.  If the PRACK does match an
   unacknowledged reliable provisional response, it MUST be responded to
   with a 2xx response.  The UAS can be certain at this point that the
   provisional response has been received in order.  It SHOULD cease
   retransmissions of the reliable provisional response, and MUST remove
   it from the list of unacknowledged provisional responses.

   If a reliable provisional response is retransmitted for 64*T1 seconds
   without reception of a corresponding PRACK, the UAS SHOULD reject the
   original request with a 5xx response.

   If the PRACK contained a session description, it is processed as
   described in Section 5 of this document.  If the PRACK instead
   contained any other type of body, the body is treated in the same way
   that body in an ACK would be treated.

   After the first reliable provisional response for a request has been
   acknowledged, the UAS MAY send additional reliable provisional
   responses.  The UAS MUST NOT send a second reliable provisional
   response until the first is acknowledged.  After the first, it is
   RECOMMENDED that the UAS not send an additional reliable provisional
   response until the previous is acknowledged.  The first reliable
   provisional response receives special treatment because it conveys
   the initial sequence number.  If additional reliable provisional
   responses were sent before the first was acknowledged, the UAS could
   not be certain these were received in order.

   The value of the RSeq in each subsequent reliable provisional
   response for the same request MUST be greater by exactly one.  RSeq
   numbers MUST NOT wrap around.  Because the initial one is chosen to
   be less than 2**31 - 1, but the maximum is 2**32 - 1, there can be up
   to 2**31 reliable provisional responses per request, which is more
   than sufficient.

   The UAS MAY send a final response to the initial request before
   having received PRACKs for all unacknowledged reliable provisional
   responses, unless the final response is 2xx and any of the
   unacknowledged reliable provisional responses contained a session
   description.  In that case, it MUST NOT send a final response until
   those provisional responses are acknowledged.  If the UAS does send a
   final response when reliable responses are still unacknowledged, it
   SHOULD NOT continue to retransmit the unacknowledged reliable
   provisional responses, but it MUST be prepared to process PRACK
   requests for those outstanding responses.  A UAS MUST NOT send new
   reliable provisional responses (as opposed to retransmissions of
   unacknowledged ones) after sending a final response to a request.



Rosenberg & Schulzrinne     Standards Track                     [Page 5]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


4 UAC Behavior

   When the UAC creates a new request, it can insist on reliable
   delivery of provisional responses for that request.  To do that, it
   inserts a Require header field with the option tag 100rel into the
   request.  A Require header with the value 100rel MUST NOT be present
   in any requests excepting INVITE, although extensions to SIP may
   allow its usage with other request methods.











































Rosenberg & Schulzrinne     Standards Track                     [Page 6]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


               Header field          where   PRACK
               ___________________________________
               Accept                  R       o
               Accept                 2xx      -
               Accept                 415      c
               Accept-Encoding         R       o
               Accept-Encoding        2xx      -
               Accept-Encoding        415      c
               Accept-Language         R       o
               Accept-Language        2xx      -
               Accept-Language        415      c
               Alert-Info              R       -
               Alert-Info             180      -
               Allow                   R       o
               Allow                  2xx      o
               Allow                   r       o
               Allow                  405      m
               Authentication-Info    2xx      o
               Authorization           R       o
               Call-ID                 c       m
               Call-Info                       -
               Contact                 R       -
               Contact                1xx      -
               Contact                2xx      -
               Contact                3xx      o
               Contact                485      o
               Content-Disposition             o
               Content-Encoding                o
               Content-Language                o
               Content-Length                  t
               Content-Type                    *
               CSeq                    c       m
               Date                            o
               Error-Info           300-699    o
               Expires                         -
               From                    c       m
               In-Reply-To             R       -
               Max-Forwards            R       m
               Min-Expires            423      -
               MIME-Version                    o
               Organization                    -

               Table 1: Summary of header fields, A--O








Rosenberg & Schulzrinne     Standards Track                     [Page 7]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


            Header field              where      PRACK
            __________________________________________
            Priority                    R          -
            Proxy-Authenticate         407         m
            Proxy-Authenticate         401         o
            Proxy-Authorization         R          o
            Proxy-Require               R          o
            Record-Route                R          o
            Record-Route             2xx,18x       o
            Reply-To                               -
            Require                                c
            Retry-After          404,413,480,486   o
                                     500,503       o
                                     600,603       o
            Route                       R          c
            Server                      r          o
            Subject                     R          -
            Supported                   R          o
            Supported                  2xx         o
            Timestamp                              o
            To                          c          m
            Unsupported                420         m
            User-Agent                             o
            Via                         c          m
            Warning                     r          o
            WWW-Authenticate           401         m

            Table 2: Summary of header fields, P--Z

   If the UAC does not wish to insist on usage of reliable provisional
   responses, but merely indicate that it supports them if the UAS needs
   to send one, a Supported header MUST be included in the request with
   the option tag 100rel.  The UAC SHOULD include this in all INVITE
   requests.

   If a provisional response is received for an initial request, and
   that response contains a Require header field containing the option
   tag 100rel, the response is to be sent reliably.  If the response is
   a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be
   ignored, and the procedures below MUST NOT be used.











Rosenberg & Schulzrinne     Standards Track                     [Page 8]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   The provisional response MUST establish a dialog if one is not yet
   created.

   Assuming the response is to be transmitted reliably, the UAC MUST
   create a new request with method PRACK.  This request is sent within
   the dialog associated with the provisional response (indeed, the
   provisional response may have created the dialog).  PRACK requests
   MAY contain bodies, which are interpreted according to their type and
   disposition.

   Note that the PRACK is like any other non-INVITE request within a
   dialog.  In particular, a UAC SHOULD NOT retransmit the PRACK request
   when it receives a retransmission of the provisional response being
   acknowledged, although doing so does not create a protocol error.

   Once a reliable provisional response is received, retransmissions of
   that response MUST be discarded.  A response is a retransmission when
   its dialog ID, CSeq, and RSeq match the original response.  The UAC
   MUST maintain a sequence number that indicates the most recently
   received in-order reliable provisional response for the initial
   request.  This sequence number MUST be maintained until a final
   response is received for the initial request.  Its value MUST be
   initialized to the RSeq header field in the first reliable
   provisional response received for the initial request.

   Handling of subsequent reliable provisional responses for the same
   initial request follows the same rules as above, with the following
   difference: reliable provisional responses are guaranteed to be in
   order.  As a result, if the UAC receives another reliable provisional
   response to the same request, and its RSeq value is not one higher
   than the value of the sequence number, that response MUST NOT be
   acknowledged with a PRACK, and MUST NOT be processed further by the
   UAC.  An implementation MAY discard the response, or MAY cache the
   response in the hopes of receiving the missing responses.

   The UAC MAY acknowledge reliable provisional responses received after
   the final response or MAY discard them.

5 The Offer/Answer Model and PRACK

   RFC 3261 describes guidelines for the sets of messages in which
   offers and answers [3] can appear.  Based on those guidelines, this
   extension provides additional opportunities for offer/answer
   exchanges.

   If the INVITE contained an offer, the UAS MAY generate an answer in a
   reliable provisional response (assuming these are supported by the
   UAC).  That results in the establishment of the session before



Rosenberg & Schulzrinne     Standards Track                     [Page 9]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   completion of the call.  Similarly, if a reliable provisional
   response is the first reliable message sent back to the UAC, and the
   INVITE did not contain an offer, one MUST appear in that reliable
   provisional response.

   If the UAC receives a reliable provisional response with an offer
   (this would occur if the UAC sent an INVITE without an offer, in
   which case the first reliable provisional response will contain the
   offer), it MUST generate an answer in the PRACK.  If the UAC receives
   a reliable provisional response with an answer, it MAY generate an
   additional offer in the PRACK.  If the UAS receives a PRACK with an
   offer, it MUST place the answer in the 2xx to the PRACK.

   Once an answer has been sent or received, the UA SHOULD establish the
   session based on the parameters of the offer and answer, even if the
   original INVITE itself has not been responded to.

   If the UAS had placed a session description in any reliable
   provisional response that is unacknowledged when the INVITE is
   accepted, the UAS MUST delay sending the 2xx until the provisional
   response is acknowledged.  Otherwise, the reliability of the 1xx
   cannot be guaranteed, and reliability is needed for proper operation
   of the offer/answer exchange.

   All user agents that support this extension MUST support all
   offer/answer exchanges that are possible based on the rules in
   Section 13.2 of RFC 3261, based on the existence of INVITE and PRACK
   as requests, and 2xx and reliable 1xx as non-failure reliable
   responses.

6 Definition of the PRACK Method

   This specification defines a new SIP method, PRACK.  The semantics of
   this method are described above.  Tables 1 and 2 extend Tables 2 and
   3 from RFC 3261 for this new method.

7 Header Field Definitions

   This specification defines two new header fields, RAck and RSeq.
   Table 3 extends Tables 2 and 3 from RFC 3261 for these headers.

7.1 RSeq

   The RSeq header is used in provisional responses in order to transmit
   them reliably.  It contains a single numeric value from 1 to 2**32 -
   1.  For details on its usage, see Section 3.





Rosenberg & Schulzrinne     Standards Track                    [Page 10]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   Example:

   RSeq: 988789

      Header field  where  proxy ACK BYE CAN INV OPT REG PRA
      ______________________________________________________
      RAck            R           -   -   -   -   -   -   m
      RSeq           1xx          -   -   -   o   -   -   -


      Table 3: RAck and RSeq Header Fields

7.2 RAck

   The RAck header is sent in a PRACK request to support reliability of
   provisional responses.  It contains two numbers and a method tag.
   The first number is the value from the RSeq header in the provisional
   response that is being acknowledged.  The next number, and the
   method, are copied from the CSeq in the response that is being
   acknowledged.  The method name in the RAck header is case sensitive.

   Example:

      RAck: 776656 1 INVITE

8 IANA Considerations

   This document registers a new option tag and two new headers, based
   on the IANA registration process of RFC 3261.

8.1 IANA Registration of the 100rel Option Tag

   This specification registers a single option tag, 100rel.  The
   required information for this registration, as specified in RFC 3261,
   is:

      Name: 100rel

      Description: This option tag is for reliability of provisional
         responses.  When present in a Supported header, it indicates
         that the UA can send or receive reliable provisional responses.
         When present in a Require header in a request, it indicates
         that the UAS MUST send all provisional responses reliably.
         When present in a Require header in a reliable provisional
         response, it indicates that the response is to be sent
         reliably.





Rosenberg & Schulzrinne     Standards Track                    [Page 11]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


8.2 IANA Registration of RSeq and RAck Headers

   The following is the registration for the RSeq header:

      RFC Number: RFC3262

      Header Name: RSeq

      Compact Form: none

   The following is the registration for the RAck header:

      RFC Number: RFC3262

      Header Name: RAck

      Compact Form: none

9 Security Considerations

   The PRACK request can be injected by attackers to force
   retransmissions of reliable provisional responses to cease.  As these
   responses can convey important information, PRACK messages SHOULD be
   authenticated as any other request.  Authentication procedures are
   specified in RFC 3261.

10 Collected BNF

   The BNF for the RAck and RSeq headers and the PRACK method are
   defined here.

   PRACKm        =  %x50.52.41.43.4B ; PRACK in caps
   Method        =  INVITEm / ACKm / OPTIONSm / BYEm
                    / CANCELm / REGISTERm / PRACKm
                    / extension-method
   RAck          =  "RAck" HCOLON response-num LWS CSeq-num LWS Method
   response-num  =  1*DIGIT
   CSeq-num      =  1*DIGIT
   RSeq          =  "RSeq" HCOLON response-num

11 Acknowledgements

   The authors would like to thank Jo Hornsby, Jonathan Lennox, Rohan
   Mahy, Allison Mankin, Adam Roach, and Tim Schroeder for the comments
   on this document.






Rosenberg & Schulzrinne     Standards Track                    [Page 12]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


12 Normative References

   [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [2]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         SDP", RFC 3264, June 2002.

13 Informative References

   [4]   Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
         "SIP: Session Initiation Protocol", RFC 2543, March 1999.

14 Authors' Addresses

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936

   EMail: jdrosen@dynamicsoft.com


   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003

   EMail: schulzrinne@cs.columbia.edu
















Rosenberg & Schulzrinne     Standards Track                    [Page 13]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


15.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rosenberg & Schulzrinne     Standards Track                    [Page 14]