Merge lp:~chris.gagnon/kubuntu-packaging/enable-unit-tests-qtbase-opensource-src into lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src
- enable-unit-tests-qtbase-opensource-src
- Merge into qtbase-opensource-src
Proposed by
Chris Gagnon
| Status: | Merged |
|---|---|
| Merged at revision: | 155 |
| Proposed branch: | lp:~chris.gagnon/kubuntu-packaging/enable-unit-tests-qtbase-opensource-src |
| Merge into: | lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src |
| Diff against target: |
17977 lines (+17897/-8) (has conflicts) 5 files modified
debian/changelog (+10/-0) debian/control (+1/-0) debian/patches/enable-tests.patch (+17872/-0) debian/patches/series (+2/-0) debian/rules (+12/-8) Text conflict in debian/changelog |
| To merge this branch: | bzr merge lp:~chris.gagnon/kubuntu-packaging/enable-unit-tests-qtbase-opensource-src |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Timo Jyrinki | Approve | ||
| PS Jenkins bot | continuous-integration | Approve | |
| Kubuntu Packagers | Pending | ||
|
Review via email:
|
|||
Commit message
enable tests in qtbase
Description of the change
To post a comment you must log in.
Revision history for this message
| Chris Gagnon (chris.gagnon) wrote : | # |
Revision history for this message
| Dmitry Shachnev (mitya57) wrote : | # |
I haven't looked at the code yet, but is it possible to skip tests that require such data and make it mergeable with Debian?
Revision history for this message
| Chris Gagnon (chris.gagnon) wrote : | # |
Those test can be skipped, but I think that's something Debian needs to do, as it skips a lot of tests. For instance all qnetworkreply tests will not run without a resource file that violates DFSG.
Ubuntu wants to know when tests brake in qtbase and doesn't have the same restrictions as Debian with the DFSG.
- 139. By Timo Jyrinki
-
Sync with archive 5.0.2 uploads
* No change rebuild against libicu52
* Positively restrict libopenvg1-mesa-dev build-dependency to only those
architectures where it is built (matching the mesa source), rather than
trying to simulate this with negative architecture restrictions.
* Drop [!arm64] restriction on libpulse-dev; we have libpulse-dev/arm64
now.
* Disable gdb build-dependency on ppc64el for now, until we have a working
gdb there. - 140. By Timo Jyrinki
-
Drop aarch64 patches that are reportedly not needed anymore
< doko> did you ask me about the arm64 patches?
< doko> checked. can be dropped - 141. By Timo Jyrinki
-
Sync with archive
* Build-depends on libxcb-sync-dev instead of libxcb-sync0-dev.
* No change rebuild against libxcb-sync1 - 142. By Timo Jyrinki
-
update qtbase5-
dev.install- common since the aarch64 patches were dropped
Revision history for this message
| Timo Jyrinki (timo-jyrinki) wrote : | # |
I'm getting test failure on x86 with this branch:
http://
Since it's x86 problem too, it should be testable in a PPA (if eg. pbuilder doesn't show the same problem) by creating a personal PPA and modifying it dependencies to build against canonical-
Secondly, I wonder if the RFC files could be simply be something completely else that is DFSG compliant, instead of the RFC texts? This is not that important as we will definitely not directly sync qtbase module as is from Debian, but it would be nice of course to enable tests in DFSG compliant way.
review:
Needs Fixing
- 143. By Timo Jyrinki
-
* Cherry-pick qdoc-Fix-
crash-in- Generator- generateInnerNo de.patch:
- Fix qdoc with libhud-qt (LP: #1271036)
Revision history for this message
| Timo Jyrinki (timo-jyrinki) wrote : | # |
I'm seeing the current version failing still in PPA:
Revision history for this message
| Chris Gagnon (chris.gagnon) wrote : | # |
I skipped those flaky tests that failed. with the latest revision it was successfully built in this ppa:
https:/
Revision history for this message
| Timo Jyrinki (timo-jyrinki) wrote : | # |
It unfortunately still seems quite flaky. In your PPA, amd64 failed. In my PPA, amd64 succeeded (!) while armhf + i386 failed:
review:
Needs Fixing
Revision history for this message
| Timo Jyrinki (timo-jyrinki) wrote : | # |
Build of rev 159, at least amd64 failing so far:
https:/
(I do bzr merge lp:~chris.gagnon/kubuntu-packaging/enable-unit-tests-qtbase-opensource-src on a clean branch and then modify the changelog and upload)
Revision history for this message
| Chris Gagnon (chris.gagnon) wrote : | # |
I am starting to think that these failures in the tests are underlying issues in qt itself instead of just flaky unit tests.
This is a ppa where you can see that the tests passed more times than not, when they fail it's always on a new test that has never failed previously (the tests that have failed previously have been disabled)
https:/
I am going to use canonistack to look for memoryleaks and threading issues with valgrind to see if I can find the root cause. If you can help out or have an idea where I should look first let me know. :)
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:159
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 144. By Timo Jyrinki
-
* Add 0001-Do-
not-overwrite- basePixmap- of-QIconLoader- PixmapEnt. patch:
- Backport an upstreamed fix to blurry icons (LP: #1271158)
Revision history for this message
| Timo Jyrinki (timo-jyrinki) wrote : | # |
I started building Qt 5.2.1 that was released a couple of hours ago, so you may want to check if the situation is any better with dget https:/
- 145. By Timo Jyrinki
-
New upstream release 5.2.1 (LP: #1256341) (LP: #1223032) (LP: #1222988)
(LP: #1223042) (LP: #1253120) (LP: #1251262) - 146. By Timo Jyrinki
-
* Sync with Debian 5.2.0+dfsg-7, remaining changes:
- No gdb required on ppc64el
- Define explicit list on which archs openvg required
+ and those listed further below
* Use canonical Vcs-Browser field.
* Install qmake's arch-specific data in an arch-specific path by using the
hostdatadir option while calling configure.
* Upload to unstable.
* Build-depend on libxcb-xkb-dev, to get more input languages support.
* Also, build-depend on libxcb-sync-dev instead of removed libxcb-sync0-dev.
* Fix misspelled DEB_HOST_ARCH_OS in debian/rules comments.
* Re-introduce qtbase5-doc-html package.
* Backport fix_crash_stale_pointer_ dereferencing. patch to solve a crash
while using harfbuzz-ng.
* Update symbols files with buildd's logs.
* Workaround sparc's FTBFS due to it's qatomic code.
* Build Qt against system's harfbuzz (Closes: #733972).
* Update symbol's files unsing buildd's logs.
* Remove unused piece of code in debian/rules.
* Enable processor detection for s390[x] and sparc.
- Do not use Wcast-align on header's tests on sparc, thus avoiding a FTBFS.
* Update symbols files using buildds' logs.
* Patch out Google-AdSense tracker from examples.
* Update Standars-Version to 3.9.5, no changes required.
* Further fix for MIPS, also in the orderedMemoryFence implementation;
patch mips_more_pre-mips32. diff.
* rules: small simplification in the platform_arg (mkspec) selection.
* Initial support for GNU/kFreeBSD:
- provide qmake mkspec, and use LD_LIBRARY_PATH; patch gnukfreebsd.diff
- rules: use the gnukfreebsd-g++ when configure'ing
* Get rid of our glibc-g++ qmake mkspec: it was a mistake with Qt4 (3?)
already, and it is no more working with non-Linux OSes; as a consequence,
error out for OSes with no qmake mkspec explicitly set in rules.
* Remove the Pre-Depends on dpkg >= 1.15.6~, since that version is available
in Squeeze already.
* Update symbols files with buildds' logs.
* Explicitly define all DEB_HOST_ARCH{,_ BITS} variables and remove duplicate
variables.
* Simplify and sort qtbase5-dev.install- armel and qtbase5- dev.install- armhf.
* Include sys/utsname.h for uname(3); patch uname_include.diff.
* Move few Linux-only files from qtbase5-dev.install- common to
qtbase5-dev.install- linux.
* Remove the cmake files of QtSql plugins on dh_auto_install phase instead
of dh_install. - 147. By Timo Jyrinki
-
Sync even more with Debian, qtbase5-doc building moves to qttools
- 148. By Chris Gagnon
-
enable unit tests
- 149. By Chris Gagnon
-
add xvfb to debian control for build dep
- 150. By Chris Gagnon
-
add enable-tests.patch
- 151. By Chris Gagnon
-
disable new failing test
- 152. By Chris Gagnon
-
version bump for ppa, add missing ;
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:152
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 153. By Chris Gagnon
-
skip failing test on arm
- 154. By Chris Gagnon
-
copied missing ; from build-area, oops
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:152
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
FAILURE: http://
ABORTED: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:152
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
ABORTED: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:154
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
Revision history for this message
| Chris Gagnon (chris.gagnon) wrote : | # |
The latest build failed due to timeout on jenkins
- 155. By Chris Gagnon
-
skip test that fails on arm
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:155
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 156. By Chris Gagnon
-
disable failing test on arm
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:156
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 157. By Chris Gagnon
-
disabling crashing arm test
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:157
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 158. By Chris Gagnon
-
add missing ;
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:158
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 159. By Chris Gagnon
-
skipping failing test
- 160. By Chris Gagnon
-
Merge with trunk
+ qdoc-Fix-crash-in- Generator- generateInnerNo de.patch
+ 0001-Do-not-overwrite- basePixmap- of-QIconLoader- PixmapEnt. patch
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:160
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 161. By Chris Gagnon
-
disabling test that crashes on arm
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:161
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 162. By Chris Gagnon
-
disable test that crashes on arm only
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:162
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 163. By Chris Gagnon
-
skipping arm test that crashes due to signal 11
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:163
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 164. By Chris Gagnon
-
disable another test failing on arm due to signal 11
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:164
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 165. By Chris Gagnon
-
skipping test on arm that crashes
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:165
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 166. By Chris Gagnon
-
disable failing test on arm
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:166
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 167. By Chris Gagnon
-
disable another arm tests
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:167
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 168. By Chris Gagnon
-
disable test that crashes on arm
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:168
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
- 169. By Chris Gagnon
-
disable test on arm that fails
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:169
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
review:
Needs Fixing
(continuous-integration)
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:169
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
review:
Approve
(continuous-integration)
Revision history for this message
| Timo Jyrinki (timo-jyrinki) wrote : | # |
Now it seems i386 + amd64 + armhf are fine, but powerpc fails:
I have to consult people what do here in this case. Maybe skipping tests on powerpc (and aarch64 too?)?
Revision history for this message
| Timo Jyrinki (timo-jyrinki) wrote : | # |
Ok let's not block on this one, but find something out later. Approved since armhf + i386 + amd64 passed!
review:
Approve
Revision history for this message
| Craig Odem (renox357) wrote : | # |
I don't know if the many emails were many but I'd there a way to have all
this information on a log and just send one email with a link to the log?
On Mar 18, 2014 8:48 AM, "Timo Jyrinki" <email address hidden> wrote:
>
> Review: Approve
>
> Ok let's not block on this one, but find something out later. Approved
since armhf + i386 + amd64 passed!
> --
>
https:/
> Your team Kubuntu Packagers is requested to review the proposed merge of
lp:~chris.gagnon/kubuntu-packaging/enable-unit-tests-qtbase-opensource-src
into lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src.
>
> --
> kubuntu-devel mailing list
> <email address hidden>
> Modify settings or unsubscribe at:
https:/
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
| 1 | === modified file 'debian/changelog' |
| 2 | --- debian/changelog 2014-02-27 15:47:15 +0000 |
| 3 | +++ debian/changelog 2014-02-27 16:13:07 +0000 |
| 4 | @@ -1,4 +1,14 @@ |
| 5 | +<<<<<<< TREE |
| 6 | qtbase-opensource-src (5.2.1+dfsg-1ubuntu1) trusty; urgency=low |
| 7 | +======= |
| 8 | +qtbase-opensource-src (5.2.1+dfsg-0ubuntu6) trusty; urgency=medium |
| 9 | + |
| 10 | + * enable unit tests |
| 11 | + |
| 12 | + -- Chris Gagnon <chris.gagnon@canonical.com> Mon, 10 Feb 2014 14:41:00 -0500 |
| 13 | + |
| 14 | +qtbase-opensource-src (5.2.1+dfsg-0ubuntu1) UNRELEASED; urgency=low |
| 15 | +>>>>>>> MERGE-SOURCE |
| 16 | |
| 17 | [ Dmitry Shachnev ] |
| 18 | * Update watch file (taken from Debian). |
| 19 | |
| 20 | === modified file 'debian/control' |
| 21 | --- debian/control 2014-02-10 07:24:57 +0000 |
| 22 | +++ debian/control 2014-02-27 16:13:07 +0000 |
| 23 | @@ -58,6 +58,7 @@ |
| 24 | libxrender-dev, |
| 25 | pkg-kde-tools (>= 0.14.2), |
| 26 | unixodbc-dev, |
| 27 | + xvfb, |
| 28 | zlib1g-dev |
| 29 | Standards-Version: 3.9.5 |
| 30 | Homepage: http://qt-project.org/ |
| 31 | |
| 32 | === added file 'debian/patches/enable-tests.patch' |
| 33 | --- debian/patches/enable-tests.patch 1970-01-01 00:00:00 +0000 |
| 34 | +++ debian/patches/enable-tests.patch 2014-02-27 16:13:07 +0000 |
| 35 | @@ -0,0 +1,17872 @@ |
| 36 | +Index: qtbase-opensource-src-5.2.1+dfsg/qtbase.pro |
| 37 | +=================================================================== |
| 38 | +--- qtbase-opensource-src-5.2.1+dfsg.orig/qtbase.pro 2014-02-20 11:14:36.916010266 -0500 |
| 39 | ++++ qtbase-opensource-src-5.2.1+dfsg/qtbase.pro 2014-02-20 11:14:36.844010265 -0500 |
| 40 | +@@ -2,6 +2,7 @@ |
| 41 | + # Main projectfile |
| 42 | + ##################################################################### |
| 43 | + |
| 44 | ++QT_BUILD_PARTS+=tests |
| 45 | + load(qt_parts) |
| 46 | + |
| 47 | + SUBDIRS += qmake/qmake-docs.pro |
| 48 | +Index: qtbase-opensource-src-5.2.1+dfsg/tests/auto/network/access/qnetworkreply/resource |
| 49 | +=================================================================== |
| 50 | +--- /dev/null 1970-01-01 00:00:00.000000000 +0000 |
| 51 | ++++ qtbase-opensource-src-5.2.1+dfsg/tests/auto/network/access/qnetworkreply/resource 2014-02-20 11:14:36.844010265 -0500 |
| 52 | +@@ -0,0 +1,283 @@ |
| 53 | ++ |
| 54 | ++ |
| 55 | ++ |
| 56 | ++ |
| 57 | ++ |
| 58 | ++ |
| 59 | ++Network Working Group L. Masinter |
| 60 | ++Request for Comments: 2397 Xerox Corporation |
| 61 | ++Category: Standards Track August 1998 |
| 62 | ++ |
| 63 | ++ |
| 64 | ++ The "data" URL scheme |
| 65 | ++ |
| 66 | ++Status of this Memo |
| 67 | ++ |
| 68 | ++ This document specifies an Internet standards track protocol for the |
| 69 | ++ Internet community, and requests discussion and suggestions for |
| 70 | ++ improvements. Please refer to the current edition of the "Internet |
| 71 | ++ Official Protocol Standards" (STD 1) for the standardization state |
| 72 | ++ and status of this protocol. Distribution of this memo is unlimited. |
| 73 | ++ |
| 74 | ++Copyright Notice |
| 75 | ++ |
| 76 | ++ Copyright (C) The Internet Society (1998). All Rights Reserved. |
| 77 | ++ |
| 78 | ++1. Abstract |
| 79 | ++ |
| 80 | ++ A new URL scheme, "data", is defined. It allows inclusion of small |
| 81 | ++ data items as "immediate" data, as if it had been included |
| 82 | ++ externally. |
| 83 | ++ |
| 84 | ++2. Description |
| 85 | ++ |
| 86 | ++ Some applications that use URLs also have a need to embed (small) |
| 87 | ++ media type data directly inline. This document defines a new URL |
| 88 | ++ scheme that would work like 'immediate addressing'. The URLs are of |
| 89 | ++ the form: |
| 90 | ++ |
| 91 | ++ data:[<mediatype>][;base64],<data> |
| 92 | ++ |
| 93 | ++ The <mediatype> is an Internet media type specification (with |
| 94 | ++ optional parameters.) The appearance of ";base64" means that the data |
| 95 | ++ is encoded as base64. Without ";base64", the data (as a sequence of |
| 96 | ++ octets) is represented using ASCII encoding for octets inside the |
| 97 | ++ range of safe URL characters and using the standard %xx hex encoding |
| 98 | ++ of URLs for octets outside that range. If <mediatype> is omitted, it |
| 99 | ++ defaults to text/plain;charset=US-ASCII. As a shorthand, |
| 100 | ++ "text/plain" can be omitted but the charset parameter supplied. |
| 101 | ++ |
| 102 | ++ The "data:" URL scheme is only useful for short values. Note that |
| 103 | ++ some applications that use URLs may impose a length limit; for |
| 104 | ++ example, URLs embedded within <A> anchors in HTML have a length limit |
| 105 | ++ determined by the SGML declaration for HTML [RFC1866]. The LITLEN |
| 106 | ++ (1024) limits the number of characters which can appear in a single |
| 107 | ++ |
| 108 | ++ |
| 109 | ++ |
| 110 | ++Masinter Standards Track [Page 1] |
| 111 | ++ |
| 112 | |
| 113 | ++RFC 2397 The "data" URL scheme August 1998 |
| 114 | ++ |
| 115 | ++ |
| 116 | ++ attribute value literal, the ATTSPLEN (2100) limits the sum of all |
| 117 | ++ lengths of all attribute value specifications which appear in a tag, |
| 118 | ++ and the TAGLEN (2100) limits the overall length of a tag. |
| 119 | ++ |
| 120 | ++ The "data" URL scheme has no relative URL forms. |
| 121 | ++ |
| 122 | ++3. Syntax |
| 123 | ++ |
| 124 | ++ dataurl := "data:" [ mediatype ] [ ";base64" ] "," data |
| 125 | ++ mediatype := [ type "/" subtype ] *( ";" parameter ) |
| 126 | ++ data := *urlchar |
| 127 | ++ parameter := attribute "=" value |
| 128 | ++ |
| 129 | ++ where "urlchar" is imported from [RFC2396], and "type", "subtype", |
| 130 | ++ "attribute" and "value" are the corresponding tokens from [RFC2045], |
| 131 | ++ represented using URL escaped encoding of [RFC2396] as necessary. |
| 132 | ++ |
| 133 | ++ Attribute values in [RFC2045] are allowed to be either represented as |
| 134 | ++ tokens or as quoted strings. However, within a "data" URL, the |
| 135 | ++ "quoted-string" representation would be awkward, since the quote mark |
| 136 | ++ is itself not a valid urlchar. For this reason, parameter values |
| 137 | ++ should use the URL Escaped encoding instead of quoted string if the |
| 138 | ++ parameter values contain any "tspecial". |
| 139 | ++ |
| 140 | ++ The ";base64" extension is distinguishable from a content-type |
| 141 | ++ parameter by the fact that it doesn't have a following "=" sign. |
| 142 | ++ |
| 143 | ++4. Examples |
| 144 | ++ |
| 145 | ++ A data URL might be used for arbitrary types of data. The URL |
| 146 | ++ |
| 147 | ++ data:,A%20brief%20note |
| 148 | ++ |
| 149 | ++ encodes the text/plain string "A brief note", which might be useful |
| 150 | ++ in a footnote link. |
| 151 | ++ |
| 152 | ++ The HTML fragment: |
| 153 | ++ |
| 154 | ++ <IMG |
| 155 | ++ SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw |
| 156 | ++ AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz |
| 157 | ++ ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp |
| 158 | ++ a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl |
| 159 | ++ ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis |
| 160 | ++ F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH |
| 161 | ++ hhx4dbgYKAAA7" |
| 162 | ++ ALT="Larry"> |
| 163 | ++ |
| 164 | ++ |
| 165 | ++ |
| 166 | ++ |
| 167 | ++Masinter Standards Track [Page 2] |
| 168 | ++ |
| 169 | |
| 170 | ++RFC 2397 The "data" URL scheme August 1998 |
| 171 | ++ |
| 172 | ++ |
| 173 | ++ could be used for a small inline image in a HTML document. (The |
| 174 | ++ embedded image is probably near the limit of utility. For anything |
| 175 | ++ else larger, data URLs are likely to be inappropriate.) |
| 176 | ++ |
| 177 | ++ A data URL scheme's media type specification can include other |
| 178 | ++ parameters; for example, one might specify a charset parameter. |
| 179 | ++ |
| 180 | ++ data:text/plain;charset=iso-8859-7,%be%fg%be |
| 181 | ++ |
| 182 | ++ can be used for a short sequence of greek characters. |
| 183 | ++ |
| 184 | ++ Some applications may use the "data" URL scheme in order to provide |
| 185 | ++ setup parameters for other kinds of networking applications. For |
| 186 | ++ example, one might create a media type |
| 187 | ++ application/vnd-xxx-query |
| 188 | ++ |
| 189 | ++ whose content consists of a query string and a database identifier |
| 190 | ++ for the "xxx" vendor's databases. A URL of the form: |
| 191 | ++ |
| 192 | ++ data:application/vnd-xxx- |
| 193 | ++ query,select_vcount,fcol_from_fieldtable/local |
| 194 | ++ |
| 195 | ++ could then be used in a local application to launch the "helper" for |
| 196 | ++ application/vnd-xxx-query and give it the immediate data included. |
| 197 | ++ |
| 198 | ++5. History |
| 199 | ++ |
| 200 | ++ This idea was originally proposed August 1995. Some versions of the |
| 201 | ++ data URL scheme have been used in the definition of VRML, and a |
| 202 | ++ version has appeared as part of a proposal for embedded data in HTML. |
| 203 | ++ Various changes have been made, based on requests, to elide the media |
| 204 | ++ type, pack the indication of the base64 encoding more tightly, and |
| 205 | ++ eliminate "quoted printable" as an encoding since it would not easily |
| 206 | ++ yield valid URLs without additional %xx encoding, which itself is |
| 207 | ++ sufficient. The "data" URL scheme is in use in VRML, new applications |
| 208 | ++ of HTML, and various commercial products. It is being used for object |
| 209 | ++ parameters in Java and ActiveX applications. |
| 210 | ++ |
| 211 | ++6. Security |
| 212 | ++ |
| 213 | ++ Interpretation of the data within a "data" URL has the same security |
| 214 | ++ considerations as any implementation of the given media type. An |
| 215 | ++ application should not interpret the contents of a data URL which is |
| 216 | ++ marked with a media type that has been disallowed for processing by |
| 217 | ++ the application's configuration. |
| 218 | ++ |
| 219 | ++ |
| 220 | ++ |
| 221 | ++ |
| 222 | ++ |
| 223 | ++ |
| 224 | ++Masinter Standards Track [Page 3] |
| 225 | ++ |
| 226 | |
| 227 | ++RFC 2397 The "data" URL scheme August 1998 |
| 228 | ++ |
| 229 | ++ |
| 230 | ++ Sites which use firewall proxies to disallow the retrieval of certain |
| 231 | ++ media types (such as application script languages or types with known |
| 232 | ++ security problems) will find it difficult to screen against the |
| 233 | ++ inclusion of such types using the "data" URL scheme. However, they |
| 234 | ++ should be aware of the threat and take whatever precautions are |
| 235 | ++ considered necessary within their domain. |
| 236 | ++ |
| 237 | ++ The effect of using long "data" URLs in applications is currently |
| 238 | ++ unknown; some software packages may exhibit unreasonable behavior |
| 239 | ++ when confronted with data that exceeds its allocated buffer size. |
| 240 | ++ |
| 241 | ++7. References |
| 242 | ++ |
| 243 | ++ [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, |
| 244 | ++ "Uniform Resource Identifiers (URI): Generic Syntax", RFC |
| 245 | ++ 2396, August 1998. |
| 246 | ++ |
| 247 | ++ [RFC1866] Berners-Lee, T., and D. Connolly, "Hypertext Markup |
| 248 | ++ Language - 2.0.", RFC 1866, November 1995. |
| 249 | ++ |
| 250 | ++ [RFC2045] Freed N., and N. Borenstein., "Multipurpose Internet Mail |
| 251 | ++ Extensions (MIME) Part One: Format of Internet Message |
| 252 | ++ Bodies", RFC 2045, November 1996. |
| 253 | ++ |
| 254 | ++Author contact information: |
| 255 | ++ |
| 256 | ++ Larry Masinter |
| 257 | ++ Xerox Palo Alto Research Center |
| 258 | ++ 3333 Coyote Hill Road |
| 259 | ++ Palo Alto, CA 94304 |
| 260 | ++ |
| 261 | ++ EMail: masinter@parc.xerox.com |
| 262 | ++ |
| 263 | ++ |
| 264 | ++ |
| 265 | ++ |
| 266 | ++ |
| 267 | ++ |
| 268 | ++ |
| 269 | ++ |
| 270 | ++ |
| 271 | ++ |
| 272 | ++ |
| 273 | ++ |
| 274 | ++ |
| 275 | ++ |
| 276 | ++ |
| 277 | ++ |
| 278 | ++ |
| 279 | ++ |
| 280 | ++ |
| 281 | ++Masinter Standards Track [Page 4] |
| 282 | ++ |
| 283 | |
| 284 | ++RFC 2397 The "data" URL scheme August 1998 |
| 285 | ++ |
| 286 | ++ |
| 287 | ++Full Copyright Statement |
| 288 | ++ |
| 289 | ++ Copyright (C) The Internet Society (1998). All Rights Reserved. |
| 290 | ++ |
| 291 | ++ This document and translations of it may be copied and furnished to |
| 292 | ++ others, and derivative works that comment on or otherwise explain it |
| 293 | ++ or assist in its implementation may be prepared, copied, published |
| 294 | ++ and distributed, in whole or in part, without restriction of any |
| 295 | ++ kind, provided that the above copyright notice and this paragraph are |
| 296 | ++ included on all such copies and derivative works. However, this |
| 297 | ++ document itself may not be modified in any way, such as by removing |
| 298 | ++ the copyright notice or references to the Internet Society or other |
| 299 | ++ Internet organizations, except as needed for the purpose of |
| 300 | ++ developing Internet standards in which case the procedures for |
| 301 | ++ copyrights defined in the Internet Standards process must be |
| 302 | ++ followed, or as required to translate it into languages other than |
| 303 | ++ English. |
| 304 | ++ |
| 305 | ++ The limited permissions granted above are perpetual and will not be |
| 306 | ++ revoked by the Internet Society or its successors or assigns. |
| 307 | ++ |
| 308 | ++ This document and the information contained herein is provided on an |
| 309 | ++ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
| 310 | ++ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
| 311 | ++ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
| 312 | ++ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
| 313 | ++ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
| 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 | ++Masinter Standards Track [Page 5] |
| 339 | ++ |
| 340 | |
| 341 | +Index: qtbase-opensource-src-5.2.1+dfsg/tests/auto/corelib/io/qtextstream/rfc3261.txt |
| 342 | +=================================================================== |
| 343 | +--- /dev/null 1970-01-01 00:00:00.000000000 +0000 |
| 344 | ++++ qtbase-opensource-src-5.2.1+dfsg/tests/auto/corelib/io/qtextstream/rfc3261.txt 2014-02-20 11:14:36.860010265 -0500 |
| 345 | +@@ -0,0 +1,15067 @@ |
| 346 | ++ |
| 347 | ++ |
| 348 | ++ |
| 349 | ++ |
| 350 | ++ |
| 351 | ++ |
| 352 | ++Network Working Group J. Rosenberg |
| 353 | ++Request for Comments: 3261 dynamicsoft |
| 354 | ++Obsoletes: 2543 H. Schulzrinne |
| 355 | ++Category: Standards Track Columbia U. |
| 356 | ++ G. Camarillo |
| 357 | ++ Ericsson |
| 358 | ++ A. Johnston |
| 359 | ++ WorldCom |
| 360 | ++ J. Peterson |
| 361 | ++ Neustar |
| 362 | ++ R. Sparks |
| 363 | ++ dynamicsoft |
| 364 | ++ M. Handley |
| 365 | ++ ICIR |
| 366 | ++ E. Schooler |
| 367 | ++ AT&T |
| 368 | ++ June 2002 |
| 369 | ++ |
| 370 | ++ SIP: Session Initiation Protocol |
| 371 | ++ |
| 372 | ++Status of this Memo |
| 373 | ++ |
| 374 | ++ This document specifies an Internet standards track protocol for the |
| 375 | ++ Internet community, and requests discussion and suggestions for |
| 376 | ++ improvements. Please refer to the current edition of the "Internet |
| 377 | ++ Official Protocol Standards" (STD 1) for the standardization state |
| 378 | ++ and status of this protocol. Distribution of this memo is unlimited. |
| 379 | ++ |
| 380 | ++Copyright Notice |
| 381 | ++ |
| 382 | ++ Copyright (C) The Internet Society (2002). All Rights Reserved. |
| 383 | ++ |
| 384 | ++Abstract |
| 385 | ++ |
| 386 | ++ This document describes Session Initiation Protocol (SIP), an |
| 387 | ++ application-layer control (signaling) protocol for creating, |
| 388 | ++ modifying, and terminating sessions with one or more participants. |
| 389 | ++ These sessions include Internet telephone calls, multimedia |
| 390 | ++ distribution, and multimedia conferences. |
| 391 | ++ |
| 392 | ++ SIP invitations used to create sessions carry session descriptions |
| 393 | ++ that allow participants to agree on a set of compatible media types. |
| 394 | ++ SIP makes use of elements called proxy servers to help route requests |
| 395 | ++ to the user's current location, authenticate and authorize users for |
| 396 | ++ services, implement provider call-routing policies, and provide |
| 397 | ++ features to users. SIP also provides a registration function that |
| 398 | ++ allows users to upload their current locations for use by proxy |
| 399 | ++ servers. SIP runs on top of several different transport protocols. |
| 400 | ++ |
| 401 | ++ |
| 402 | ++ |
| 403 | ++Rosenberg, et. al. Standards Track [Page 1] |
| 404 | ++ |
| 405 | |
| 406 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 407 | ++ |
| 408 | ++ |
| 409 | ++Table of Contents |
| 410 | ++ |
| 411 | ++ 1 Introduction ........................................ 8 |
| 412 | ++ 2 Overview of SIP Functionality ....................... 9 |
| 413 | ++ 3 Terminology ......................................... 10 |
| 414 | ++ 4 Overview of Operation ............................... 10 |
| 415 | ++ 5 Structure of the Protocol ........................... 18 |
| 416 | ++ 6 Definitions ......................................... 20 |
| 417 | ++ 7 SIP Messages ........................................ 26 |
| 418 | ++ 7.1 Requests ............................................ 27 |
| 419 | ++ 7.2 Responses ........................................... 28 |
| 420 | ++ 7.3 Header Fields ....................................... 29 |
| 421 | ++ 7.3.1 Header Field Format ................................. 30 |
| 422 | ++ 7.3.2 Header Field Classification ......................... 32 |
| 423 | ++ 7.3.3 Compact Form ........................................ 32 |
| 424 | ++ 7.4 Bodies .............................................. 33 |
| 425 | ++ 7.4.1 Message Body Type ................................... 33 |
| 426 | ++ 7.4.2 Message Body Length ................................. 33 |
| 427 | ++ 7.5 Framing SIP Messages ................................ 34 |
| 428 | ++ 8 General User Agent Behavior ......................... 34 |
| 429 | ++ 8.1 UAC Behavior ........................................ 35 |
| 430 | ++ 8.1.1 Generating the Request .............................. 35 |
| 431 | ++ 8.1.1.1 Request-URI ......................................... 35 |
| 432 | ++ 8.1.1.2 To .................................................. 36 |
| 433 | ++ 8.1.1.3 From ................................................ 37 |
| 434 | ++ 8.1.1.4 Call-ID ............................................. 37 |
| 435 | ++ 8.1.1.5 CSeq ................................................ 38 |
| 436 | ++ 8.1.1.6 Max-Forwards ........................................ 38 |
| 437 | ++ 8.1.1.7 Via ................................................. 39 |
| 438 | ++ 8.1.1.8 Contact ............................................. 40 |
| 439 | ++ 8.1.1.9 Supported and Require ............................... 40 |
| 440 | ++ 8.1.1.10 Additional Message Components ....................... 41 |
| 441 | ++ 8.1.2 Sending the Request ................................. 41 |
| 442 | ++ 8.1.3 Processing Responses ................................ 42 |
| 443 | ++ 8.1.3.1 Transaction Layer Errors ............................ 42 |
| 444 | ++ 8.1.3.2 Unrecognized Responses .............................. 42 |
| 445 | ++ 8.1.3.3 Vias ................................................ 43 |
| 446 | ++ 8.1.3.4 Processing 3xx Responses ............................ 43 |
| 447 | ++ 8.1.3.5 Processing 4xx Responses ............................ 45 |
| 448 | ++ 8.2 UAS Behavior ........................................ 46 |
| 449 | ++ 8.2.1 Method Inspection ................................... 46 |
| 450 | ++ 8.2.2 Header Inspection ................................... 46 |
| 451 | ++ 8.2.2.1 To and Request-URI .................................. 46 |
| 452 | ++ 8.2.2.2 Merged Requests ..................................... 47 |
| 453 | ++ 8.2.2.3 Require ............................................. 47 |
| 454 | ++ 8.2.3 Content Processing .................................. 48 |
| 455 | ++ 8.2.4 Applying Extensions ................................. 49 |
| 456 | ++ 8.2.5 Processing the Request .............................. 49 |
| 457 | ++ |
| 458 | ++ |
| 459 | ++ |
| 460 | ++Rosenberg, et. al. Standards Track [Page 2] |
| 461 | ++ |
| 462 | |
| 463 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 464 | ++ |
| 465 | ++ |
| 466 | ++ 8.2.6 Generating the Response ............................. 49 |
| 467 | ++ 8.2.6.1 Sending a Provisional Response ...................... 49 |
| 468 | ++ 8.2.6.2 Headers and Tags .................................... 50 |
| 469 | ++ 8.2.7 Stateless UAS Behavior .............................. 50 |
| 470 | ++ 8.3 Redirect Servers .................................... 51 |
| 471 | ++ 9 Canceling a Request ................................. 53 |
| 472 | ++ 9.1 Client Behavior ..................................... 53 |
| 473 | ++ 9.2 Server Behavior ..................................... 55 |
| 474 | ++ 10 Registrations ....................................... 56 |
| 475 | ++ 10.1 Overview ............................................ 56 |
| 476 | ++ 10.2 Constructing the REGISTER Request ................... 57 |
| 477 | ++ 10.2.1 Adding Bindings ..................................... 59 |
| 478 | ++ 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 |
| 479 | ++ 10.2.1.2 Preferences among Contact Addresses ................. 61 |
| 480 | ++ 10.2.2 Removing Bindings ................................... 61 |
| 481 | ++ 10.2.3 Fetching Bindings ................................... 61 |
| 482 | ++ 10.2.4 Refreshing Bindings ................................. 61 |
| 483 | ++ 10.2.5 Setting the Internal Clock .......................... 62 |
| 484 | ++ 10.2.6 Discovering a Registrar ............................. 62 |
| 485 | ++ 10.2.7 Transmitting a Request .............................. 62 |
| 486 | ++ 10.2.8 Error Responses ..................................... 63 |
| 487 | ++ 10.3 Processing REGISTER Requests ........................ 63 |
| 488 | ++ 11 Querying for Capabilities ........................... 66 |
| 489 | ++ 11.1 Construction of OPTIONS Request ..................... 67 |
| 490 | ++ 11.2 Processing of OPTIONS Request ....................... 68 |
| 491 | ++ 12 Dialogs ............................................. 69 |
| 492 | ++ 12.1 Creation of a Dialog ................................ 70 |
| 493 | ++ 12.1.1 UAS behavior ........................................ 70 |
| 494 | ++ 12.1.2 UAC Behavior ........................................ 71 |
| 495 | ++ 12.2 Requests within a Dialog ............................ 72 |
| 496 | ++ 12.2.1 UAC Behavior ........................................ 73 |
| 497 | ++ 12.2.1.1 Generating the Request .............................. 73 |
| 498 | ++ 12.2.1.2 Processing the Responses ............................ 75 |
| 499 | ++ 12.2.2 UAS Behavior ........................................ 76 |
| 500 | ++ 12.3 Termination of a Dialog ............................. 77 |
| 501 | ++ 13 Initiating a Session ................................ 77 |
| 502 | ++ 13.1 Overview ............................................ 77 |
| 503 | ++ 13.2 UAC Processing ...................................... 78 |
| 504 | ++ 13.2.1 Creating the Initial INVITE ......................... 78 |
| 505 | ++ 13.2.2 Processing INVITE Responses ......................... 81 |
| 506 | ++ 13.2.2.1 1xx Responses ....................................... 81 |
| 507 | ++ 13.2.2.2 3xx Responses ....................................... 81 |
| 508 | ++ 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 |
| 509 | ++ 13.2.2.4 2xx Responses ....................................... 82 |
| 510 | ++ 13.3 UAS Processing ...................................... 83 |
| 511 | ++ 13.3.1 Processing of the INVITE ............................ 83 |
| 512 | ++ 13.3.1.1 Progress ............................................ 84 |
| 513 | ++ 13.3.1.2 The INVITE is Redirected ............................ 84 |
| 514 | ++ |
| 515 | ++ |
| 516 | ++ |
| 517 | ++Rosenberg, et. al. Standards Track [Page 3] |
| 518 | ++ |
| 519 | |
| 520 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 521 | ++ |
| 522 | ++ |
| 523 | ++ 13.3.1.3 The INVITE is Rejected .............................. 85 |
| 524 | ++ 13.3.1.4 The INVITE is Accepted .............................. 85 |
| 525 | ++ 14 Modifying an Existing Session ....................... 86 |
| 526 | ++ 14.1 UAC Behavior ........................................ 86 |
| 527 | ++ 14.2 UAS Behavior ........................................ 88 |
| 528 | ++ 15 Terminating a Session ............................... 89 |
| 529 | ++ 15.1 Terminating a Session with a BYE Request ............ 90 |
| 530 | ++ 15.1.1 UAC Behavior ........................................ 90 |
| 531 | ++ 15.1.2 UAS Behavior ........................................ 91 |
| 532 | ++ 16 Proxy Behavior ...................................... 91 |
| 533 | ++ 16.1 Overview ............................................ 91 |
| 534 | ++ 16.2 Stateful Proxy ...................................... 92 |
| 535 | ++ 16.3 Request Validation .................................. 94 |
| 536 | ++ 16.4 Route Information Preprocessing ..................... 96 |
| 537 | ++ 16.5 Determining Request Targets ......................... 97 |
| 538 | ++ 16.6 Request Forwarding .................................. 99 |
| 539 | ++ 16.7 Response Processing ................................. 107 |
| 540 | ++ 16.8 Processing Timer C .................................. 114 |
| 541 | ++ 16.9 Handling Transport Errors ........................... 115 |
| 542 | ++ 16.10 CANCEL Processing ................................... 115 |
| 543 | ++ 16.11 Stateless Proxy ..................................... 116 |
| 544 | ++ 16.12 Summary of Proxy Route Processing ................... 118 |
| 545 | ++ 16.12.1 Examples ............................................ 118 |
| 546 | ++ 16.12.1.1 Basic SIP Trapezoid ................................. 118 |
| 547 | ++ 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120 |
| 548 | ++ 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121 |
| 549 | ++ 17 Transactions ........................................ 122 |
| 550 | ++ 17.1 Client Transaction .................................. 124 |
| 551 | ++ 17.1.1 INVITE Client Transaction ........................... 125 |
| 552 | ++ 17.1.1.1 Overview of INVITE Transaction ...................... 125 |
| 553 | ++ 17.1.1.2 Formal Description .................................. 125 |
| 554 | ++ 17.1.1.3 Construction of the ACK Request ..................... 129 |
| 555 | ++ 17.1.2 Non-INVITE Client Transaction ....................... 130 |
| 556 | ++ 17.1.2.1 Overview of the non-INVITE Transaction .............. 130 |
| 557 | ++ 17.1.2.2 Formal Description .................................. 131 |
| 558 | ++ 17.1.3 Matching Responses to Client Transactions ........... 132 |
| 559 | ++ 17.1.4 Handling Transport Errors ........................... 133 |
| 560 | ++ 17.2 Server Transaction .................................. 134 |
| 561 | ++ 17.2.1 INVITE Server Transaction ........................... 134 |
| 562 | ++ 17.2.2 Non-INVITE Server Transaction ....................... 137 |
| 563 | ++ 17.2.3 Matching Requests to Server Transactions ............ 138 |
| 564 | ++ 17.2.4 Handling Transport Errors ........................... 141 |
| 565 | ++ 18 Transport ........................................... 141 |
| 566 | ++ 18.1 Clients ............................................. 142 |
| 567 | ++ 18.1.1 Sending Requests .................................... 142 |
| 568 | ++ 18.1.2 Receiving Responses ................................. 144 |
| 569 | ++ 18.2 Servers ............................................. 145 |
| 570 | ++ 18.2.1 Receiving Requests .................................. 145 |
| 571 | ++ |
| 572 | ++ |
| 573 | ++ |
| 574 | ++Rosenberg, et. al. Standards Track [Page 4] |
| 575 | ++ |
| 576 | |
| 577 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 578 | ++ |
| 579 | ++ |
| 580 | ++ 18.2.2 Sending Responses ................................... 146 |
| 581 | ++ 18.3 Framing ............................................. 147 |
| 582 | ++ 18.4 Error Handling ...................................... 147 |
| 583 | ++ 19 Common Message Components ........................... 147 |
| 584 | ++ 19.1 SIP and SIPS Uniform Resource Indicators ............ 148 |
| 585 | ++ 19.1.1 SIP and SIPS URI Components ......................... 148 |
| 586 | ++ 19.1.2 Character Escaping Requirements ..................... 152 |
| 587 | ++ 19.1.3 Example SIP and SIPS URIs ........................... 153 |
| 588 | ++ 19.1.4 URI Comparison ...................................... 153 |
| 589 | ++ 19.1.5 Forming Requests from a URI ......................... 156 |
| 590 | ++ 19.1.6 Relating SIP URIs and tel URLs ...................... 157 |
| 591 | ++ 19.2 Option Tags ......................................... 158 |
| 592 | ++ 19.3 Tags ................................................ 159 |
| 593 | ++ 20 Header Fields ....................................... 159 |
| 594 | ++ 20.1 Accept .............................................. 161 |
| 595 | ++ 20.2 Accept-Encoding ..................................... 163 |
| 596 | ++ 20.3 Accept-Language ..................................... 164 |
| 597 | ++ 20.4 Alert-Info .......................................... 164 |
| 598 | ++ 20.5 Allow ............................................... 165 |
| 599 | ++ 20.6 Authentication-Info ................................. 165 |
| 600 | ++ 20.7 Authorization ....................................... 165 |
| 601 | ++ 20.8 Call-ID ............................................. 166 |
| 602 | ++ 20.9 Call-Info ........................................... 166 |
| 603 | ++ 20.10 Contact ............................................. 167 |
| 604 | ++ 20.11 Content-Disposition ................................. 168 |
| 605 | ++ 20.12 Content-Encoding .................................... 169 |
| 606 | ++ 20.13 Content-Language .................................... 169 |
| 607 | ++ 20.14 Content-Length ...................................... 169 |
| 608 | ++ 20.15 Content-Type ........................................ 170 |
| 609 | ++ 20.16 CSeq ................................................ 170 |
| 610 | ++ 20.17 Date ................................................ 170 |
| 611 | ++ 20.18 Error-Info .......................................... 171 |
| 612 | ++ 20.19 Expires ............................................. 171 |
| 613 | ++ 20.20 From ................................................ 172 |
| 614 | ++ 20.21 In-Reply-To ......................................... 172 |
| 615 | ++ 20.22 Max-Forwards ........................................ 173 |
| 616 | ++ 20.23 Min-Expires ......................................... 173 |
| 617 | ++ 20.24 MIME-Version ........................................ 173 |
| 618 | ++ 20.25 Organization ........................................ 174 |
| 619 | ++ 20.26 Priority ............................................ 174 |
| 620 | ++ 20.27 Proxy-Authenticate .................................. 174 |
| 621 | ++ 20.28 Proxy-Authorization ................................. 175 |
| 622 | ++ 20.29 Proxy-Require ....................................... 175 |
| 623 | ++ 20.30 Record-Route ........................................ 175 |
| 624 | ++ 20.31 Reply-To ............................................ 176 |
| 625 | ++ 20.32 Require ............................................. 176 |
| 626 | ++ 20.33 Retry-After ......................................... 176 |
| 627 | ++ 20.34 Route ............................................... 177 |
| 628 | ++ |
| 629 | ++ |
| 630 | ++ |
| 631 | ++Rosenberg, et. al. Standards Track [Page 5] |
| 632 | ++ |
| 633 | |
| 634 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 635 | ++ |
| 636 | ++ |
| 637 | ++ 20.35 Server .............................................. 177 |
| 638 | ++ 20.36 Subject ............................................. 177 |
| 639 | ++ 20.37 Supported ........................................... 178 |
| 640 | ++ 20.38 Timestamp ........................................... 178 |
| 641 | ++ 20.39 To .................................................. 178 |
| 642 | ++ 20.40 Unsupported ......................................... 179 |
| 643 | ++ 20.41 User-Agent .......................................... 179 |
| 644 | ++ 20.42 Via ................................................. 179 |
| 645 | ++ 20.43 Warning ............................................. 180 |
| 646 | ++ 20.44 WWW-Authenticate .................................... 182 |
| 647 | ++ 21 Response Codes ...................................... 182 |
| 648 | ++ 21.1 Provisional 1xx ..................................... 182 |
| 649 | ++ 21.1.1 100 Trying .......................................... 183 |
| 650 | ++ 21.1.2 180 Ringing ......................................... 183 |
| 651 | ++ 21.1.3 181 Call Is Being Forwarded ......................... 183 |
| 652 | ++ 21.1.4 182 Queued .......................................... 183 |
| 653 | ++ 21.1.5 183 Session Progress ................................ 183 |
| 654 | ++ 21.2 Successful 2xx ...................................... 183 |
| 655 | ++ 21.2.1 200 OK .............................................. 183 |
| 656 | ++ 21.3 Redirection 3xx ..................................... 184 |
| 657 | ++ 21.3.1 300 Multiple Choices ................................ 184 |
| 658 | ++ 21.3.2 301 Moved Permanently ............................... 184 |
| 659 | ++ 21.3.3 302 Moved Temporarily ............................... 184 |
| 660 | ++ 21.3.4 305 Use Proxy ....................................... 185 |
| 661 | ++ 21.3.5 380 Alternative Service ............................. 185 |
| 662 | ++ 21.4 Request Failure 4xx ................................. 185 |
| 663 | ++ 21.4.1 400 Bad Request ..................................... 185 |
| 664 | ++ 21.4.2 401 Unauthorized .................................... 185 |
| 665 | ++ 21.4.3 402 Payment Required ................................ 186 |
| 666 | ++ 21.4.4 403 Forbidden ....................................... 186 |
| 667 | ++ 21.4.5 404 Not Found ....................................... 186 |
| 668 | ++ 21.4.6 405 Method Not Allowed .............................. 186 |
| 669 | ++ 21.4.7 406 Not Acceptable .................................. 186 |
| 670 | ++ 21.4.8 407 Proxy Authentication Required ................... 186 |
| 671 | ++ 21.4.9 408 Request Timeout ................................. 186 |
| 672 | ++ 21.4.10 410 Gone ............................................ 187 |
| 673 | ++ 21.4.11 413 Request Entity Too Large ........................ 187 |
| 674 | ++ 21.4.12 414 Request-URI Too Long ............................ 187 |
| 675 | ++ 21.4.13 415 Unsupported Media Type .......................... 187 |
| 676 | ++ 21.4.14 416 Unsupported URI Scheme .......................... 187 |
| 677 | ++ 21.4.15 420 Bad Extension ................................... 187 |
| 678 | ++ 21.4.16 421 Extension Required .............................. 188 |
| 679 | ++ 21.4.17 423 Interval Too Brief .............................. 188 |
| 680 | ++ 21.4.18 480 Temporarily Unavailable ......................... 188 |
| 681 | ++ 21.4.19 481 Call/Transaction Does Not Exist ................. 188 |
| 682 | ++ 21.4.20 482 Loop Detected ................................... 188 |
| 683 | ++ 21.4.21 483 Too Many Hops ................................... 189 |
| 684 | ++ 21.4.22 484 Address Incomplete .............................. 189 |
| 685 | ++ |
| 686 | ++ |
| 687 | ++ |
| 688 | ++Rosenberg, et. al. Standards Track [Page 6] |
| 689 | ++ |
| 690 | |
| 691 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 692 | ++ |
| 693 | ++ |
| 694 | ++ 21.4.23 485 Ambiguous ....................................... 189 |
| 695 | ++ 21.4.24 486 Busy Here ....................................... 189 |
| 696 | ++ 21.4.25 487 Request Terminated .............................. 190 |
| 697 | ++ 21.4.26 488 Not Acceptable Here ............................. 190 |
| 698 | ++ 21.4.27 491 Request Pending ................................. 190 |
| 699 | ++ 21.4.28 493 Undecipherable .................................. 190 |
| 700 | ++ 21.5 Server Failure 5xx .................................. 190 |
| 701 | ++ 21.5.1 500 Server Internal Error ........................... 190 |
| 702 | ++ 21.5.2 501 Not Implemented ................................. 191 |
| 703 | ++ 21.5.3 502 Bad Gateway ..................................... 191 |
| 704 | ++ 21.5.4 503 Service Unavailable ............................. 191 |
| 705 | ++ 21.5.5 504 Server Time-out ................................. 191 |
| 706 | ++ 21.5.6 505 Version Not Supported ........................... 192 |
| 707 | ++ 21.5.7 513 Message Too Large ............................... 192 |
| 708 | ++ 21.6 Global Failures 6xx ................................. 192 |
| 709 | ++ 21.6.1 600 Busy Everywhere ................................. 192 |
| 710 | ++ 21.6.2 603 Decline ......................................... 192 |
| 711 | ++ 21.6.3 604 Does Not Exist Anywhere ......................... 192 |
| 712 | ++ 21.6.4 606 Not Acceptable .................................. 192 |
| 713 | ++ 22 Usage of HTTP Authentication ........................ 193 |
| 714 | ++ 22.1 Framework ........................................... 193 |
| 715 | ++ 22.2 User-to-User Authentication ......................... 195 |
| 716 | ++ 22.3 Proxy-to-User Authentication ........................ 197 |
| 717 | ++ 22.4 The Digest Authentication Scheme .................... 199 |
| 718 | ++ 23 S/MIME .............................................. 201 |
| 719 | ++ 23.1 S/MIME Certificates ................................. 201 |
| 720 | ++ 23.2 S/MIME Key Exchange ................................. 202 |
| 721 | ++ 23.3 Securing MIME bodies ................................ 205 |
| 722 | ++ 23.4 SIP Header Privacy and Integrity using S/MIME: |
| 723 | ++ Tunneling SIP ....................................... 207 |
| 724 | ++ 23.4.1 Integrity and Confidentiality Properties of SIP |
| 725 | ++ Headers ............................................. 207 |
| 726 | ++ 23.4.1.1 Integrity ........................................... 207 |
| 727 | ++ 23.4.1.2 Confidentiality ..................................... 208 |
| 728 | ++ 23.4.2 Tunneling Integrity and Authentication .............. 209 |
| 729 | ++ 23.4.3 Tunneling Encryption ................................ 211 |
| 730 | ++ 24 Examples ............................................ 213 |
| 731 | ++ 24.1 Registration ........................................ 213 |
| 732 | ++ 24.2 Session Setup ....................................... 214 |
| 733 | ++ 25 Augmented BNF for the SIP Protocol .................. 219 |
| 734 | ++ 25.1 Basic Rules ......................................... 219 |
| 735 | ++ 26 Security Considerations: Threat Model and Security |
| 736 | ++ Usage Recommendations ............................... 232 |
| 737 | ++ 26.1 Attacks and Threat Models ........................... 233 |
| 738 | ++ 26.1.1 Registration Hijacking .............................. 233 |
| 739 | ++ 26.1.2 Impersonating a Server .............................. 234 |
| 740 | ++ 26.1.3 Tampering with Message Bodies ....................... 235 |
| 741 | ++ 26.1.4 Tearing Down Sessions ............................... 235 |
| 742 | ++ |
| 743 | ++ |
| 744 | ++ |
| 745 | ++Rosenberg, et. al. Standards Track [Page 7] |
| 746 | ++ |
| 747 | |
| 748 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 749 | ++ |
| 750 | ++ |
| 751 | ++ 26.1.5 Denial of Service and Amplification ................. 236 |
| 752 | ++ 26.2 Security Mechanisms ................................. 237 |
| 753 | ++ 26.2.1 Transport and Network Layer Security ................ 238 |
| 754 | ++ 26.2.2 SIPS URI Scheme ..................................... 239 |
| 755 | ++ 26.2.3 HTTP Authentication ................................. 240 |
| 756 | ++ 26.2.4 S/MIME .............................................. 240 |
| 757 | ++ 26.3 Implementing Security Mechanisms .................... 241 |
| 758 | ++ 26.3.1 Requirements for Implementers of SIP ................ 241 |
| 759 | ++ 26.3.2 Security Solutions .................................. 242 |
| 760 | ++ 26.3.2.1 Registration ........................................ 242 |
| 761 | ++ 26.3.2.2 Interdomain Requests ................................ 243 |
| 762 | ++ 26.3.2.3 Peer-to-Peer Requests ............................... 245 |
| 763 | ++ 26.3.2.4 DoS Protection ...................................... 246 |
| 764 | ++ 26.4 Limitations ......................................... 247 |
| 765 | ++ 26.4.1 HTTP Digest ......................................... 247 |
| 766 | ++ 26.4.2 S/MIME .............................................. 248 |
| 767 | ++ 26.4.3 TLS ................................................. 249 |
| 768 | ++ 26.4.4 SIPS URIs ........................................... 249 |
| 769 | ++ 26.5 Privacy ............................................. 251 |
| 770 | ++ 27 IANA Considerations ................................. 252 |
| 771 | ++ 27.1 Option Tags ......................................... 252 |
| 772 | ++ 27.2 Warn-Codes .......................................... 252 |
| 773 | ++ 27.3 Header Field Names .................................. 253 |
| 774 | ++ 27.4 Method and Response Codes ........................... 253 |
| 775 | ++ 27.5 The "message/sip" MIME type. ....................... 254 |
| 776 | ++ 27.6 New Content-Disposition Parameter Registrations ..... 255 |
| 777 | ++ 28 Changes From RFC 2543 ............................... 255 |
| 778 | ++ 28.1 Major Functional Changes ............................ 255 |
| 779 | ++ 28.2 Minor Functional Changes ............................ 260 |
| 780 | ++ 29 Normative References ................................ 261 |
| 781 | ++ 30 Informative References .............................. 262 |
| 782 | ++ A Table of Timer Values ............................... 265 |
| 783 | ++ Acknowledgments ................................................ 266 |
| 784 | ++ Authors' Addresses ............................................. 267 |
| 785 | ++ Full Copyright Statement ....................................... 269 |
| 786 | ++ |
| 787 | ++1 Introduction |
| 788 | ++ |
| 789 | ++ There are many applications of the Internet that require the creation |
| 790 | ++ and management of a session, where a session is considered an |
| 791 | ++ exchange of data between an association of participants. The |
| 792 | ++ implementation of these applications is complicated by the practices |
| 793 | ++ of participants: users may move between endpoints, they may be |
| 794 | ++ addressable by multiple names, and they may communicate in several |
| 795 | ++ different media - sometimes simultaneously. Numerous protocols have |
| 796 | ++ been authored that carry various forms of real-time multimedia |
| 797 | ++ session data such as voice, video, or text messages. The Session |
| 798 | ++ Initiation Protocol (SIP) works in concert with these protocols by |
| 799 | ++ |
| 800 | ++ |
| 801 | ++ |
| 802 | ++Rosenberg, et. al. Standards Track [Page 8] |
| 803 | ++ |
| 804 | |
| 805 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 806 | ++ |
| 807 | ++ |
| 808 | ++ enabling Internet endpoints (called user agents) to discover one |
| 809 | ++ another and to agree on a characterization of a session they would |
| 810 | ++ like to share. For locating prospective session participants, and |
| 811 | ++ for other functions, SIP enables the creation of an infrastructure of |
| 812 | ++ network hosts (called proxy servers) to which user agents can send |
| 813 | ++ registrations, invitations to sessions, and other requests. SIP is |
| 814 | ++ an agile, general-purpose tool for creating, modifying, and |
| 815 | ++ terminating sessions that works independently of underlying transport |
| 816 | ++ protocols and without dependency on the type of session that is being |
| 817 | ++ established. |
| 818 | ++ |
| 819 | ++2 Overview of SIP Functionality |
| 820 | ++ |
| 821 | ++ SIP is an application-layer control protocol that can establish, |
| 822 | ++ modify, and terminate multimedia sessions (conferences) such as |
| 823 | ++ Internet telephony calls. SIP can also invite participants to |
| 824 | ++ already existing sessions, such as multicast conferences. Media can |
| 825 | ++ be added to (and removed from) an existing session. SIP |
| 826 | ++ transparently supports name mapping and redirection services, which |
| 827 | ++ supports personal mobility [27] - users can maintain a single |
| 828 | ++ externally visible identifier regardless of their network location. |
| 829 | ++ |
| 830 | ++ SIP supports five facets of establishing and terminating multimedia |
| 831 | ++ communications: |
| 832 | ++ |
| 833 | ++ User location: determination of the end system to be used for |
| 834 | ++ communication; |
| 835 | ++ |
| 836 | ++ User availability: determination of the willingness of the called |
| 837 | ++ party to engage in communications; |
| 838 | ++ |
| 839 | ++ User capabilities: determination of the media and media parameters |
| 840 | ++ to be used; |
| 841 | ++ |
| 842 | ++ Session setup: "ringing", establishment of session parameters at |
| 843 | ++ both called and calling party; |
| 844 | ++ |
| 845 | ++ Session management: including transfer and termination of |
| 846 | ++ sessions, modifying session parameters, and invoking |
| 847 | ++ services. |
| 848 | ++ |
| 849 | ++ SIP is not a vertically integrated communications system. SIP is |
| 850 | ++ rather a component that can be used with other IETF protocols to |
| 851 | ++ build a complete multimedia architecture. Typically, these |
| 852 | ++ architectures will include protocols such as the Real-time Transport |
| 853 | ++ Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and |
| 854 | ++ providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC |
| 855 | ++ 2326 [29]) for controlling delivery of streaming media, the Media |
| 856 | ++ |
| 857 | ++ |
| 858 | ++ |
| 859 | ++Rosenberg, et. al. Standards Track [Page 9] |
| 860 | ++ |
| 861 | |
| 862 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 863 | ++ |
| 864 | ++ |
| 865 | ++ Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling |
| 866 | ++ gateways to the Public Switched Telephone Network (PSTN), and the |
| 867 | ++ Session Description Protocol (SDP) (RFC 2327 [1]) for describing |
| 868 | ++ multimedia sessions. Therefore, SIP should be used in conjunction |
| 869 | ++ with other protocols in order to provide complete services to the |
| 870 | ++ users. However, the basic functionality and operation of SIP does |
| 871 | ++ not depend on any of these protocols. |
| 872 | ++ |
| 873 | ++ SIP does not provide services. Rather, SIP provides primitives that |
| 874 | ++ can be used to implement different services. For example, SIP can |
| 875 | ++ locate a user and deliver an opaque object to his current location. |
| 876 | ++ If this primitive is used to deliver a session description written in |
| 877 | ++ SDP, for instance, the endpoints can agree on the parameters of a |
| 878 | ++ session. If the same primitive is used to deliver a photo of the |
| 879 | ++ caller as well as the session description, a "caller ID" service can |
| 880 | ++ be easily implemented. As this example shows, a single primitive is |
| 881 | ++ typically used to provide several different services. |
| 882 | ++ |
| 883 | ++ SIP does not offer conference control services such as floor control |
| 884 | ++ or voting and does not prescribe how a conference is to be managed. |
| 885 | ++ SIP can be used to initiate a session that uses some other conference |
| 886 | ++ control protocol. Since SIP messages and the sessions they establish |
| 887 | ++ can pass through entirely different networks, SIP cannot, and does |
| 888 | ++ not, provide any kind of network resource reservation capabilities. |
| 889 | ++ |
| 890 | ++ The nature of the services provided make security particularly |
| 891 | ++ important. To that end, SIP provides a suite of security services, |
| 892 | ++ which include denial-of-service prevention, authentication (both user |
| 893 | ++ to user and proxy to user), integrity protection, and encryption and |
| 894 | ++ privacy services. |
| 895 | ++ |
| 896 | ++ SIP works with both IPv4 and IPv6. |
| 897 | ++ |
| 898 | ++3 Terminology |
| 899 | ++ |
| 900 | ++ In this document, the key words "MUST", "MUST NOT", "REQUIRED", |
| 901 | ++ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT |
| 902 | ++ RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as |
| 903 | ++ described in BCP 14, RFC 2119 [2] and indicate requirement levels for |
| 904 | ++ compliant SIP implementations. |
| 905 | ++ |
| 906 | ++4 Overview of Operation |
| 907 | ++ |
| 908 | ++ This section introduces the basic operations of SIP using simple |
| 909 | ++ examples. This section is tutorial in nature and does not contain |
| 910 | ++ any normative statements. |
| 911 | ++ |
| 912 | ++ |
| 913 | ++ |
| 914 | ++ |
| 915 | ++ |
| 916 | ++Rosenberg, et. al. Standards Track [Page 10] |
| 917 | ++ |
| 918 | |
| 919 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 920 | ++ |
| 921 | ++ |
| 922 | ++ The first example shows the basic functions of SIP: location of an |
| 923 | ++ end point, signal of a desire to communicate, negotiation of session |
| 924 | ++ parameters to establish the session, and teardown of the session once |
| 925 | ++ established. |
| 926 | ++ |
| 927 | ++ Figure 1 shows a typical example of a SIP message exchange between |
| 928 | ++ two users, Alice and Bob. (Each message is labeled with the letter |
| 929 | ++ "F" and a number for reference by the text.) In this example, Alice |
| 930 | ++ uses a SIP application on her PC (referred to as a softphone) to call |
| 931 | ++ Bob on his SIP phone over the Internet. Also shown are two SIP proxy |
| 932 | ++ servers that act on behalf of Alice and Bob to facilitate the session |
| 933 | ++ establishment. This typical arrangement is often referred to as the |
| 934 | ++ "SIP trapezoid" as shown by the geometric shape of the dotted lines |
| 935 | ++ in Figure 1. |
| 936 | ++ |
| 937 | ++ Alice "calls" Bob using his SIP identity, a type of Uniform Resource |
| 938 | ++ Identifier (URI) called a SIP URI. SIP URIs are defined in Section |
| 939 | ++ 19.1. It has a similar form to an email address, typically |
| 940 | ++ containing a username and a host name. In this case, it is |
| 941 | ++ sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP |
| 942 | ++ service provider. Alice has a SIP URI of sip:alice@atlanta.com. |
| 943 | ++ Alice might have typed in Bob's URI or perhaps clicked on a hyperlink |
| 944 | ++ or an entry in an address book. SIP also provides a secure URI, |
| 945 | ++ called a SIPS URI. An example would be sips:bob@biloxi.com. A call |
| 946 | ++ made to a SIPS URI guarantees that secure, encrypted transport |
| 947 | ++ (namely TLS) is used to carry all SIP messages from the caller to the |
| 948 | ++ domain of the callee. From there, the request is sent securely to |
| 949 | ++ the callee, but with security mechanisms that depend on the policy of |
| 950 | ++ the domain of the callee. |
| 951 | ++ |
| 952 | ++ SIP is based on an HTTP-like request/response transaction model. |
| 953 | ++ Each transaction consists of a request that invokes a particular |
| 954 | ++ method, or function, on the server and at least one response. In |
| 955 | ++ this example, the transaction begins with Alice's softphone sending |
| 956 | ++ an INVITE request addressed to Bob's SIP URI. INVITE is an example |
| 957 | ++ of a SIP method that specifies the action that the requestor (Alice) |
| 958 | ++ wants the server (Bob) to take. The INVITE request contains a number |
| 959 | ++ of header fields. Header fields are named attributes that provide |
| 960 | ++ additional information about a message. The ones present in an |
| 961 | ++ INVITE include a unique identifier for the call, the destination |
| 962 | ++ address, Alice's address, and information about the type of session |
| 963 | ++ that Alice wishes to establish with Bob. The INVITE (message F1 in |
| 964 | ++ Figure 1) might look like this: |
| 965 | ++ |
| 966 | ++ |
| 967 | ++ |
| 968 | ++ |
| 969 | ++ |
| 970 | ++ |
| 971 | ++ |
| 972 | ++ |
| 973 | ++Rosenberg, et. al. Standards Track [Page 11] |
| 974 | ++ |
| 975 | |
| 976 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 977 | ++ |
| 978 | ++ |
| 979 | ++ atlanta.com . . . biloxi.com |
| 980 | ++ . proxy proxy . |
| 981 | ++ . . |
| 982 | ++ Alice's . . . . . . . . . . . . . . . . . . . . Bob's |
| 983 | ++ softphone SIP Phone |
| 984 | ++ | | | | |
| 985 | ++ | INVITE F1 | | | |
| 986 | ++ |--------------->| INVITE F2 | | |
| 987 | ++ | 100 Trying F3 |--------------->| INVITE F4 | |
| 988 | ++ |<---------------| 100 Trying F5 |--------------->| |
| 989 | ++ | |<-------------- | 180 Ringing F6 | |
| 990 | ++ | | 180 Ringing F7 |<---------------| |
| 991 | ++ | 180 Ringing F8 |<---------------| 200 OK F9 | |
| 992 | ++ |<---------------| 200 OK F10 |<---------------| |
| 993 | ++ | 200 OK F11 |<---------------| | |
| 994 | ++ |<---------------| | | |
| 995 | ++ | ACK F12 | |
| 996 | ++ |------------------------------------------------->| |
| 997 | ++ | Media Session | |
| 998 | ++ |<================================================>| |
| 999 | ++ | BYE F13 | |
| 1000 | ++ |<-------------------------------------------------| |
| 1001 | ++ | 200 OK F14 | |
| 1002 | ++ |------------------------------------------------->| |
| 1003 | ++ | | |
| 1004 | ++ |
| 1005 | ++ Figure 1: SIP session setup example with SIP trapezoid |
| 1006 | ++ |
| 1007 | ++ INVITE sip:bob@biloxi.com SIP/2.0 |
| 1008 | ++ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds |
| 1009 | ++ Max-Forwards: 70 |
| 1010 | ++ To: Bob <sip:bob@biloxi.com> |
| 1011 | ++ From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
| 1012 | ++ Call-ID: a84b4c76e66710@pc33.atlanta.com |
| 1013 | ++ CSeq: 314159 INVITE |
| 1014 | ++ Contact: <sip:alice@pc33.atlanta.com> |
| 1015 | ++ Content-Type: application/sdp |
| 1016 | ++ Content-Length: 142 |
| 1017 | ++ |
| 1018 | ++ (Alice's SDP not shown) |
| 1019 | ++ |
| 1020 | ++ The first line of the text-encoded message contains the method name |
| 1021 | ++ (INVITE). The lines that follow are a list of header fields. This |
| 1022 | ++ example contains a minimum required set. The header fields are |
| 1023 | ++ briefly described below: |
| 1024 | ++ |
| 1025 | ++ |
| 1026 | ++ |
| 1027 | ++ |
| 1028 | ++ |
| 1029 | ++ |
| 1030 | ++Rosenberg, et. al. Standards Track [Page 12] |
| 1031 | ++ |
| 1032 | |
| 1033 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1034 | ++ |
| 1035 | ++ |
| 1036 | ++ Via contains the address (pc33.atlanta.com) at which Alice is |
| 1037 | ++ expecting to receive responses to this request. It also contains a |
| 1038 | ++ branch parameter that identifies this transaction. |
| 1039 | ++ |
| 1040 | ++ To contains a display name (Bob) and a SIP or SIPS URI |
| 1041 | ++ (sip:bob@biloxi.com) towards which the request was originally |
| 1042 | ++ directed. Display names are described in RFC 2822 [3]. |
| 1043 | ++ |
| 1044 | ++ From also contains a display name (Alice) and a SIP or SIPS URI |
| 1045 | ++ (sip:alice@atlanta.com) that indicate the originator of the request. |
| 1046 | ++ This header field also has a tag parameter containing a random string |
| 1047 | ++ (1928301774) that was added to the URI by the softphone. It is used |
| 1048 | ++ for identification purposes. |
| 1049 | ++ |
| 1050 | ++ Call-ID contains a globally unique identifier for this call, |
| 1051 | ++ generated by the combination of a random string and the softphone's |
| 1052 | ++ host name or IP address. The combination of the To tag, From tag, |
| 1053 | ++ and Call-ID completely defines a peer-to-peer SIP relationship |
| 1054 | ++ between Alice and Bob and is referred to as a dialog. |
| 1055 | ++ |
| 1056 | ++ CSeq or Command Sequence contains an integer and a method name. The |
| 1057 | ++ CSeq number is incremented for each new request within a dialog and |
| 1058 | ++ is a traditional sequence number. |
| 1059 | ++ |
| 1060 | ++ Contact contains a SIP or SIPS URI that represents a direct route to |
| 1061 | ++ contact Alice, usually composed of a username at a fully qualified |
| 1062 | ++ domain name (FQDN). While an FQDN is preferred, many end systems do |
| 1063 | ++ not have registered domain names, so IP addresses are permitted. |
| 1064 | ++ While the Via header field tells other elements where to send the |
| 1065 | ++ response, the Contact header field tells other elements where to send |
| 1066 | ++ future requests. |
| 1067 | ++ |
| 1068 | ++ Max-Forwards serves to limit the number of hops a request can make on |
| 1069 | ++ the way to its destination. It consists of an integer that is |
| 1070 | ++ decremented by one at each hop. |
| 1071 | ++ |
| 1072 | ++ Content-Type contains a description of the message body (not shown). |
| 1073 | ++ |
| 1074 | ++ Content-Length contains an octet (byte) count of the message body. |
| 1075 | ++ |
| 1076 | ++ The complete set of SIP header fields is defined in Section 20. |
| 1077 | ++ |
| 1078 | ++ The details of the session, such as the type of media, codec, or |
| 1079 | ++ sampling rate, are not described using SIP. Rather, the body of a |
| 1080 | ++ SIP message contains a description of the session, encoded in some |
| 1081 | ++ other protocol format. One such format is the Session Description |
| 1082 | ++ Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the |
| 1083 | ++ |
| 1084 | ++ |
| 1085 | ++ |
| 1086 | ++ |
| 1087 | ++Rosenberg, et. al. Standards Track [Page 13] |
| 1088 | ++ |
| 1089 | |
| 1090 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1091 | ++ |
| 1092 | ++ |
| 1093 | ++ example) is carried by the SIP message in a way that is analogous to |
| 1094 | ++ a document attachment being carried by an email message, or a web |
| 1095 | ++ page being carried in an HTTP message. |
| 1096 | ++ |
| 1097 | ++ Since the softphone does not know the location of Bob or the SIP |
| 1098 | ++ server in the biloxi.com domain, the softphone sends the INVITE to |
| 1099 | ++ the SIP server that serves Alice's domain, atlanta.com. The address |
| 1100 | ++ of the atlanta.com SIP server could have been configured in Alice's |
| 1101 | ++ softphone, or it could have been discovered by DHCP, for example. |
| 1102 | ++ |
| 1103 | ++ The atlanta.com SIP server is a type of SIP server known as a proxy |
| 1104 | ++ server. A proxy server receives SIP requests and forwards them on |
| 1105 | ++ behalf of the requestor. In this example, the proxy server receives |
| 1106 | ++ the INVITE request and sends a 100 (Trying) response back to Alice's |
| 1107 | ++ softphone. The 100 (Trying) response indicates that the INVITE has |
| 1108 | ++ been received and that the proxy is working on her behalf to route |
| 1109 | ++ the INVITE to the destination. Responses in SIP use a three-digit |
| 1110 | ++ code followed by a descriptive phrase. This response contains the |
| 1111 | ++ same To, From, Call-ID, CSeq and branch parameter in the Via as the |
| 1112 | ++ INVITE, which allows Alice's softphone to correlate this response to |
| 1113 | ++ the sent INVITE. The atlanta.com proxy server locates the proxy |
| 1114 | ++ server at biloxi.com, possibly by performing a particular type of DNS |
| 1115 | ++ (Domain Name Service) lookup to find the SIP server that serves the |
| 1116 | ++ biloxi.com domain. This is described in [4]. As a result, it |
| 1117 | ++ obtains the IP address of the biloxi.com proxy server and forwards, |
| 1118 | ++ or proxies, the INVITE request there. Before forwarding the request, |
| 1119 | ++ the atlanta.com proxy server adds an additional Via header field |
| 1120 | ++ value that contains its own address (the INVITE already contains |
| 1121 | ++ Alice's address in the first Via). The biloxi.com proxy server |
| 1122 | ++ receives the INVITE and responds with a 100 (Trying) response back to |
| 1123 | ++ the atlanta.com proxy server to indicate that it has received the |
| 1124 | ++ INVITE and is processing the request. The proxy server consults a |
| 1125 | ++ database, generically called a location service, that contains the |
| 1126 | ++ current IP address of Bob. (We shall see in the next section how |
| 1127 | ++ this database can be populated.) The biloxi.com proxy server adds |
| 1128 | ++ another Via header field value with its own address to the INVITE and |
| 1129 | ++ proxies it to Bob's SIP phone. |
| 1130 | ++ |
| 1131 | ++ Bob's SIP phone receives the INVITE and alerts Bob to the incoming |
| 1132 | ++ call from Alice so that Bob can decide whether to answer the call, |
| 1133 | ++ that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 |
| 1134 | ++ (Ringing) response, which is routed back through the two proxies in |
| 1135 | ++ the reverse direction. Each proxy uses the Via header field to |
| 1136 | ++ determine where to send the response and removes its own address from |
| 1137 | ++ the top. As a result, although DNS and location service lookups were |
| 1138 | ++ required to route the initial INVITE, the 180 (Ringing) response can |
| 1139 | ++ be returned to the caller without lookups or without state being |
| 1140 | ++ |
| 1141 | ++ |
| 1142 | ++ |
| 1143 | ++ |
| 1144 | ++Rosenberg, et. al. Standards Track [Page 14] |
| 1145 | ++ |
| 1146 | |
| 1147 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1148 | ++ |
| 1149 | ++ |
| 1150 | ++ maintained in the proxies. This also has the desirable property that |
| 1151 | ++ each proxy that sees the INVITE will also see all responses to the |
| 1152 | ++ INVITE. |
| 1153 | ++ |
| 1154 | ++ When Alice's softphone receives the 180 (Ringing) response, it passes |
| 1155 | ++ this information to Alice, perhaps using an audio ringback tone or by |
| 1156 | ++ displaying a message on Alice's screen. |
| 1157 | ++ |
| 1158 | ++ In this example, Bob decides to answer the call. When he picks up |
| 1159 | ++ the handset, his SIP phone sends a 200 (OK) response to indicate that |
| 1160 | ++ the call has been answered. The 200 (OK) contains a message body |
| 1161 | ++ with the SDP media description of the type of session that Bob is |
| 1162 | ++ willing to establish with Alice. As a result, there is a two-phase |
| 1163 | ++ exchange of SDP messages: Alice sent one to Bob, and Bob sent one |
| 1164 | ++ back to Alice. This two-phase exchange provides basic negotiation |
| 1165 | ++ capabilities and is based on a simple offer/answer model of SDP |
| 1166 | ++ exchange. If Bob did not wish to answer the call or was busy on |
| 1167 | ++ another call, an error response would have been sent instead of the |
| 1168 | ++ 200 (OK), which would have resulted in no media session being |
| 1169 | ++ established. The complete list of SIP response codes is in Section |
| 1170 | ++ 21. The 200 (OK) (message F9 in Figure 1) might look like this as |
| 1171 | ++ Bob sends it out: |
| 1172 | ++ |
| 1173 | ++ SIP/2.0 200 OK |
| 1174 | ++ Via: SIP/2.0/UDP server10.biloxi.com |
| 1175 | ++ ;branch=z9hG4bKnashds8;received=192.0.2.3 |
| 1176 | ++ Via: SIP/2.0/UDP bigbox3.site3.atlanta.com |
| 1177 | ++ ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 |
| 1178 | ++ Via: SIP/2.0/UDP pc33.atlanta.com |
| 1179 | ++ ;branch=z9hG4bK776asdhds ;received=192.0.2.1 |
| 1180 | ++ To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
| 1181 | ++ From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
| 1182 | ++ Call-ID: a84b4c76e66710@pc33.atlanta.com |
| 1183 | ++ CSeq: 314159 INVITE |
| 1184 | ++ Contact: <sip:bob@192.0.2.4> |
| 1185 | ++ Content-Type: application/sdp |
| 1186 | ++ Content-Length: 131 |
| 1187 | ++ |
| 1188 | ++ (Bob's SDP not shown) |
| 1189 | ++ |
| 1190 | ++ The first line of the response contains the response code (200) and |
| 1191 | ++ the reason phrase (OK). The remaining lines contain header fields. |
| 1192 | ++ The Via, To, From, Call-ID, and CSeq header fields are copied from |
| 1193 | ++ the INVITE request. (There are three Via header field values - one |
| 1194 | ++ added by Alice's SIP phone, one added by the atlanta.com proxy, and |
| 1195 | ++ one added by the biloxi.com proxy.) Bob's SIP phone has added a tag |
| 1196 | ++ parameter to the To header field. This tag will be incorporated by |
| 1197 | ++ both endpoints into the dialog and will be included in all future |
| 1198 | ++ |
| 1199 | ++ |
| 1200 | ++ |
| 1201 | ++Rosenberg, et. al. Standards Track [Page 15] |
| 1202 | ++ |
| 1203 | |
| 1204 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1205 | ++ |
| 1206 | ++ |
| 1207 | ++ requests and responses in this call. The Contact header field |
| 1208 | ++ contains a URI at which Bob can be directly reached at his SIP phone. |
| 1209 | ++ The Content-Type and Content-Length refer to the message body (not |
| 1210 | ++ shown) that contains Bob's SDP media information. |
| 1211 | ++ |
| 1212 | ++ In addition to DNS and location service lookups shown in this |
| 1213 | ++ example, proxy servers can make flexible "routing decisions" to |
| 1214 | ++ decide where to send a request. For example, if Bob's SIP phone |
| 1215 | ++ returned a 486 (Busy Here) response, the biloxi.com proxy server |
| 1216 | ++ could proxy the INVITE to Bob's voicemail server. A proxy server can |
| 1217 | ++ also send an INVITE to a number of locations at the same time. This |
| 1218 | ++ type of parallel search is known as forking. |
| 1219 | ++ |
| 1220 | ++ In this case, the 200 (OK) is routed back through the two proxies and |
| 1221 | ++ is received by Alice's softphone, which then stops the ringback tone |
| 1222 | ++ and indicates that the call has been answered. Finally, Alice's |
| 1223 | ++ softphone sends an acknowledgement message, ACK, to Bob's SIP phone |
| 1224 | ++ to confirm the reception of the final response (200 (OK)). In this |
| 1225 | ++ example, the ACK is sent directly from Alice's softphone to Bob's SIP |
| 1226 | ++ phone, bypassing the two proxies. This occurs because the endpoints |
| 1227 | ++ have learned each other's address from the Contact header fields |
| 1228 | ++ through the INVITE/200 (OK) exchange, which was not known when the |
| 1229 | ++ initial INVITE was sent. The lookups performed by the two proxies |
| 1230 | ++ are no longer needed, so the proxies drop out of the call flow. This |
| 1231 | ++ completes the INVITE/200/ACK three-way handshake used to establish |
| 1232 | ++ SIP sessions. Full details on session setup are in Section 13. |
| 1233 | ++ |
| 1234 | ++ Alice and Bob's media session has now begun, and they send media |
| 1235 | ++ packets using the format to which they agreed in the exchange of SDP. |
| 1236 | ++ In general, the end-to-end media packets take a different path from |
| 1237 | ++ the SIP signaling messages. |
| 1238 | ++ |
| 1239 | ++ During the session, either Alice or Bob may decide to change the |
| 1240 | ++ characteristics of the media session. This is accomplished by |
| 1241 | ++ sending a re-INVITE containing a new media description. This re- |
| 1242 | ++ INVITE references the existing dialog so that the other party knows |
| 1243 | ++ that it is to modify an existing session instead of establishing a |
| 1244 | ++ new session. The other party sends a 200 (OK) to accept the change. |
| 1245 | ++ The requestor responds to the 200 (OK) with an ACK. If the other |
| 1246 | ++ party does not accept the change, he sends an error response such as |
| 1247 | ++ 488 (Not Acceptable Here), which also receives an ACK. However, the |
| 1248 | ++ failure of the re-INVITE does not cause the existing call to fail - |
| 1249 | ++ the session continues using the previously negotiated |
| 1250 | ++ characteristics. Full details on session modification are in Section |
| 1251 | ++ 14. |
| 1252 | ++ |
| 1253 | ++ |
| 1254 | ++ |
| 1255 | ++ |
| 1256 | ++ |
| 1257 | ++ |
| 1258 | ++Rosenberg, et. al. Standards Track [Page 16] |
| 1259 | ++ |
| 1260 | |
| 1261 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1262 | ++ |
| 1263 | ++ |
| 1264 | ++ At the end of the call, Bob disconnects (hangs up) first and |
| 1265 | ++ generates a BYE message. This BYE is routed directly to Alice's |
| 1266 | ++ softphone, again bypassing the proxies. Alice confirms receipt of |
| 1267 | ++ the BYE with a 200 (OK) response, which terminates the session and |
| 1268 | ++ the BYE transaction. No ACK is sent - an ACK is only sent in |
| 1269 | ++ response to a response to an INVITE request. The reasons for this |
| 1270 | ++ special handling for INVITE will be discussed later, but relate to |
| 1271 | ++ the reliability mechanisms in SIP, the length of time it can take for |
| 1272 | ++ a ringing phone to be answered, and forking. For this reason, |
| 1273 | ++ request handling in SIP is often classified as either INVITE or non- |
| 1274 | ++ INVITE, referring to all other methods besides INVITE. Full details |
| 1275 | ++ on session termination are in Section 15. |
| 1276 | ++ |
| 1277 | ++ Section 24.2 describes the messages shown in Figure 1 in full. |
| 1278 | ++ |
| 1279 | ++ In some cases, it may be useful for proxies in the SIP signaling path |
| 1280 | ++ to see all the messaging between the endpoints for the duration of |
| 1281 | ++ the session. For example, if the biloxi.com proxy server wished to |
| 1282 | ++ remain in the SIP messaging path beyond the initial INVITE, it would |
| 1283 | ++ add to the INVITE a required routing header field known as Record- |
| 1284 | ++ Route that contained a URI resolving to the hostname or IP address of |
| 1285 | ++ the proxy. This information would be received by both Bob's SIP |
| 1286 | ++ phone and (due to the Record-Route header field being passed back in |
| 1287 | ++ the 200 (OK)) Alice's softphone and stored for the duration of the |
| 1288 | ++ dialog. The biloxi.com proxy server would then receive and proxy the |
| 1289 | ++ ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently |
| 1290 | ++ decide to receive subsequent messages, and those messages will pass |
| 1291 | ++ through all proxies that elect to receive it. This capability is |
| 1292 | ++ frequently used for proxies that are providing mid-call features. |
| 1293 | ++ |
| 1294 | ++ Registration is another common operation in SIP. Registration is one |
| 1295 | ++ way that the biloxi.com server can learn the current location of Bob. |
| 1296 | ++ Upon initialization, and at periodic intervals, Bob's SIP phone sends |
| 1297 | ++ REGISTER messages to a server in the biloxi.com domain known as a SIP |
| 1298 | ++ registrar. The REGISTER messages associate Bob's SIP or SIPS URI |
| 1299 | ++ (sip:bob@biloxi.com) with the machine into which he is currently |
| 1300 | ++ logged (conveyed as a SIP or SIPS URI in the Contact header field). |
| 1301 | ++ The registrar writes this association, also called a binding, to a |
| 1302 | ++ database, called the location service, where it can be used by the |
| 1303 | ++ proxy in the biloxi.com domain. Often, a registrar server for a |
| 1304 | ++ domain is co-located with the proxy for that domain. It is an |
| 1305 | ++ important concept that the distinction between types of SIP servers |
| 1306 | ++ is logical, not physical. |
| 1307 | ++ |
| 1308 | ++ Bob is not limited to registering from a single device. For example, |
| 1309 | ++ both his SIP phone at home and the one in the office could send |
| 1310 | ++ registrations. This information is stored together in the location |
| 1311 | ++ |
| 1312 | ++ |
| 1313 | ++ |
| 1314 | ++ |
| 1315 | ++Rosenberg, et. al. Standards Track [Page 17] |
| 1316 | ++ |
| 1317 | |
| 1318 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1319 | ++ |
| 1320 | ++ |
| 1321 | ++ service and allows a proxy to perform various types of searches to |
| 1322 | ++ locate Bob. Similarly, more than one user can be registered on a |
| 1323 | ++ single device at the same time. |
| 1324 | ++ |
| 1325 | ++ The location service is just an abstract concept. It generally |
| 1326 | ++ contains information that allows a proxy to input a URI and receive a |
| 1327 | ++ set of zero or more URIs that tell the proxy where to send the |
| 1328 | ++ request. Registrations are one way to create this information, but |
| 1329 | ++ not the only way. Arbitrary mapping functions can be configured at |
| 1330 | ++ the discretion of the administrator. |
| 1331 | ++ |
| 1332 | ++ Finally, it is important to note that in SIP, registration is used |
| 1333 | ++ for routing incoming SIP requests and has no role in authorizing |
| 1334 | ++ outgoing requests. Authorization and authentication are handled in |
| 1335 | ++ SIP either on a request-by-request basis with a challenge/response |
| 1336 | ++ mechanism, or by using a lower layer scheme as discussed in Section |
| 1337 | ++ 26. |
| 1338 | ++ |
| 1339 | ++ The complete set of SIP message details for this registration example |
| 1340 | ++ is in Section 24.1. |
| 1341 | ++ |
| 1342 | ++ Additional operations in SIP, such as querying for the capabilities |
| 1343 | ++ of a SIP server or client using OPTIONS, or canceling a pending |
| 1344 | ++ request using CANCEL, will be introduced in later sections. |
| 1345 | ++ |
| 1346 | ++5 Structure of the Protocol |
| 1347 | ++ |
| 1348 | ++ SIP is structured as a layered protocol, which means that its |
| 1349 | ++ behavior is described in terms of a set of fairly independent |
| 1350 | ++ processing stages with only a loose coupling between each stage. The |
| 1351 | ++ protocol behavior is described as layers for the purpose of |
| 1352 | ++ presentation, allowing the description of functions common across |
| 1353 | ++ elements in a single section. It does not dictate an implementation |
| 1354 | ++ in any way. When we say that an element "contains" a layer, we mean |
| 1355 | ++ it is compliant to the set of rules defined by that layer. |
| 1356 | ++ |
| 1357 | ++ Not every element specified by the protocol contains every layer. |
| 1358 | ++ Furthermore, the elements specified by SIP are logical elements, not |
| 1359 | ++ physical ones. A physical realization can choose to act as different |
| 1360 | ++ logical elements, perhaps even on a transaction-by-transaction basis. |
| 1361 | ++ |
| 1362 | ++ The lowest layer of SIP is its syntax and encoding. Its encoding is |
| 1363 | ++ specified using an augmented Backus-Naur Form grammar (BNF). The |
| 1364 | ++ complete BNF is specified in Section 25; an overview of a SIP |
| 1365 | ++ message's structure can be found in Section 7. |
| 1366 | ++ |
| 1367 | ++ |
| 1368 | ++ |
| 1369 | ++ |
| 1370 | ++ |
| 1371 | ++ |
| 1372 | ++Rosenberg, et. al. Standards Track [Page 18] |
| 1373 | ++ |
| 1374 | |
| 1375 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1376 | ++ |
| 1377 | ++ |
| 1378 | ++ The second layer is the transport layer. It defines how a client |
| 1379 | ++ sends requests and receives responses and how a server receives |
| 1380 | ++ requests and sends responses over the network. All SIP elements |
| 1381 | ++ contain a transport layer. The transport layer is described in |
| 1382 | ++ Section 18. |
| 1383 | ++ |
| 1384 | ++ The third layer is the transaction layer. Transactions are a |
| 1385 | ++ fundamental component of SIP. A transaction is a request sent by a |
| 1386 | ++ client transaction (using the transport layer) to a server |
| 1387 | ++ transaction, along with all responses to that request sent from the |
| 1388 | ++ server transaction back to the client. The transaction layer handles |
| 1389 | ++ application-layer retransmissions, matching of responses to requests, |
| 1390 | ++ and application-layer timeouts. Any task that a user agent client |
| 1391 | ++ (UAC) accomplishes takes place using a series of transactions. |
| 1392 | ++ Discussion of transactions can be found in Section 17. User agents |
| 1393 | ++ contain a transaction layer, as do stateful proxies. Stateless |
| 1394 | ++ proxies do not contain a transaction layer. The transaction layer |
| 1395 | ++ has a client component (referred to as a client transaction) and a |
| 1396 | ++ server component (referred to as a server transaction), each of which |
| 1397 | ++ are represented by a finite state machine that is constructed to |
| 1398 | ++ process a particular request. |
| 1399 | ++ |
| 1400 | ++ The layer above the transaction layer is called the transaction user |
| 1401 | ++ (TU). Each of the SIP entities, except the stateless proxy, is a |
| 1402 | ++ transaction user. When a TU wishes to send a request, it creates a |
| 1403 | ++ client transaction instance and passes it the request along with the |
| 1404 | ++ destination IP address, port, and transport to which to send the |
| 1405 | ++ request. A TU that creates a client transaction can also cancel it. |
| 1406 | ++ When a client cancels a transaction, it requests that the server stop |
| 1407 | ++ further processing, revert to the state that existed before the |
| 1408 | ++ transaction was initiated, and generate a specific error response to |
| 1409 | ++ that transaction. This is done with a CANCEL request, which |
| 1410 | ++ constitutes its own transaction, but references the transaction to be |
| 1411 | ++ cancelled (Section 9). |
| 1412 | ++ |
| 1413 | ++ The SIP elements, that is, user agent clients and servers, stateless |
| 1414 | ++ and stateful proxies and registrars, contain a core that |
| 1415 | ++ distinguishes them from each other. Cores, except for the stateless |
| 1416 | ++ proxy, are transaction users. While the behavior of the UAC and UAS |
| 1417 | ++ cores depends on the method, there are some common rules for all |
| 1418 | ++ methods (Section 8). For a UAC, these rules govern the construction |
| 1419 | ++ of a request; for a UAS, they govern the processing of a request and |
| 1420 | ++ generating a response. Since registrations play an important role in |
| 1421 | ++ SIP, a UAS that handles a REGISTER is given the special name |
| 1422 | ++ registrar. Section 10 describes UAC and UAS core behavior for the |
| 1423 | ++ REGISTER method. Section 11 describes UAC and UAS core behavior for |
| 1424 | ++ the OPTIONS method, used for determining the capabilities of a UA. |
| 1425 | ++ |
| 1426 | ++ |
| 1427 | ++ |
| 1428 | ++ |
| 1429 | ++Rosenberg, et. al. Standards Track [Page 19] |
| 1430 | ++ |
| 1431 | |
| 1432 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1433 | ++ |
| 1434 | ++ |
| 1435 | ++ Certain other requests are sent within a dialog. A dialog is a |
| 1436 | ++ peer-to-peer SIP relationship between two user agents that persists |
| 1437 | ++ for some time. The dialog facilitates sequencing of messages and |
| 1438 | ++ proper routing of requests between the user agents. The INVITE |
| 1439 | ++ method is the only way defined in this specification to establish a |
| 1440 | ++ dialog. When a UAC sends a request that is within the context of a |
| 1441 | ++ dialog, it follows the common UAC rules as discussed in Section 8 but |
| 1442 | ++ also the rules for mid-dialog requests. Section 12 discusses dialogs |
| 1443 | ++ and presents the procedures for their construction and maintenance, |
| 1444 | ++ in addition to construction of requests within a dialog. |
| 1445 | ++ |
| 1446 | ++ The most important method in SIP is the INVITE method, which is used |
| 1447 | ++ to establish a session between participants. A session is a |
| 1448 | ++ collection of participants, and streams of media between them, for |
| 1449 | ++ the purposes of communication. Section 13 discusses how sessions are |
| 1450 | ++ initiated, resulting in one or more SIP dialogs. Section 14 |
| 1451 | ++ discusses how characteristics of that session are modified through |
| 1452 | ++ the use of an INVITE request within a dialog. Finally, section 15 |
| 1453 | ++ discusses how a session is terminated. |
| 1454 | ++ |
| 1455 | ++ The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal |
| 1456 | ++ entirely with the UA core (Section 9 describes cancellation, which |
| 1457 | ++ applies to both UA core and proxy core). Section 16 discusses the |
| 1458 | ++ proxy element, which facilitates routing of messages between user |
| 1459 | ++ agents. |
| 1460 | ++ |
| 1461 | ++6 Definitions |
| 1462 | ++ |
| 1463 | ++ The following terms have special significance for SIP. |
| 1464 | ++ |
| 1465 | ++ Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI |
| 1466 | ++ that points to a domain with a location service that can map |
| 1467 | ++ the URI to another URI where the user might be available. |
| 1468 | ++ Typically, the location service is populated through |
| 1469 | ++ registrations. An AOR is frequently thought of as the "public |
| 1470 | ++ address" of the user. |
| 1471 | ++ |
| 1472 | ++ Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a |
| 1473 | ++ logical entity that receives a request and processes it as a |
| 1474 | ++ user agent server (UAS). In order to determine how the request |
| 1475 | ++ should be answered, it acts as a user agent client (UAC) and |
| 1476 | ++ generates requests. Unlike a proxy server, it maintains dialog |
| 1477 | ++ state and must participate in all requests sent on the dialogs |
| 1478 | ++ it has established. Since it is a concatenation of a UAC and |
| 1479 | ++ UAS, no explicit definitions are needed for its behavior. |
| 1480 | ++ |
| 1481 | ++ |
| 1482 | ++ |
| 1483 | ++ |
| 1484 | ++ |
| 1485 | ++ |
| 1486 | ++Rosenberg, et. al. Standards Track [Page 20] |
| 1487 | ++ |
| 1488 | |
| 1489 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1490 | ++ |
| 1491 | ++ |
| 1492 | ++ Call: A call is an informal term that refers to some communication |
| 1493 | ++ between peers, generally set up for the purposes of a |
| 1494 | ++ multimedia conversation. |
| 1495 | ++ |
| 1496 | ++ Call Leg: Another name for a dialog [31]; no longer used in this |
| 1497 | ++ specification. |
| 1498 | ++ |
| 1499 | ++ Call Stateful: A proxy is call stateful if it retains state for a |
| 1500 | ++ dialog from the initiating INVITE to the terminating BYE |
| 1501 | ++ request. A call stateful proxy is always transaction stateful, |
| 1502 | ++ but the converse is not necessarily true. |
| 1503 | ++ |
| 1504 | ++ Client: A client is any network element that sends SIP requests |
| 1505 | ++ and receives SIP responses. Clients may or may not interact |
| 1506 | ++ directly with a human user. User agent clients and proxies are |
| 1507 | ++ clients. |
| 1508 | ++ |
| 1509 | ++ Conference: A multimedia session (see below) that contains |
| 1510 | ++ multiple participants. |
| 1511 | ++ |
| 1512 | ++ Core: Core designates the functions specific to a particular type |
| 1513 | ++ of SIP entity, i.e., specific to either a stateful or stateless |
| 1514 | ++ proxy, a user agent or registrar. All cores, except those for |
| 1515 | ++ the stateless proxy, are transaction users. |
| 1516 | ++ |
| 1517 | ++ Dialog: A dialog is a peer-to-peer SIP relationship between two |
| 1518 | ++ UAs that persists for some time. A dialog is established by |
| 1519 | ++ SIP messages, such as a 2xx response to an INVITE request. A |
| 1520 | ++ dialog is identified by a call identifier, local tag, and a |
| 1521 | ++ remote tag. A dialog was formerly known as a call leg in RFC |
| 1522 | ++ 2543. |
| 1523 | ++ |
| 1524 | ++ Downstream: A direction of message forwarding within a transaction |
| 1525 | ++ that refers to the direction that requests flow from the user |
| 1526 | ++ agent client to user agent server. |
| 1527 | ++ |
| 1528 | ++ Final Response: A response that terminates a SIP transaction, as |
| 1529 | ++ opposed to a provisional response that does not. All 2xx, 3xx, |
| 1530 | ++ 4xx, 5xx and 6xx responses are final. |
| 1531 | ++ |
| 1532 | ++ Header: A header is a component of a SIP message that conveys |
| 1533 | ++ information about the message. It is structured as a sequence |
| 1534 | ++ of header fields. |
| 1535 | ++ |
| 1536 | ++ Header Field: A header field is a component of the SIP message |
| 1537 | ++ header. A header field can appear as one or more header field |
| 1538 | ++ rows. Header field rows consist of a header field name and zero |
| 1539 | ++ or more header field values. Multiple header field values on a |
| 1540 | ++ |
| 1541 | ++ |
| 1542 | ++ |
| 1543 | ++Rosenberg, et. al. Standards Track [Page 21] |
| 1544 | ++ |
| 1545 | |
| 1546 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1547 | ++ |
| 1548 | ++ |
| 1549 | ++ given header field row are separated by commas. Some header |
| 1550 | ++ fields can only have a single header field value, and as a |
| 1551 | ++ result, always appear as a single header field row. |
| 1552 | ++ |
| 1553 | ++ Header Field Value: A header field value is a single value; a |
| 1554 | ++ header field consists of zero or more header field values. |
| 1555 | ++ |
| 1556 | ++ Home Domain: The domain providing service to a SIP user. |
| 1557 | ++ Typically, this is the domain present in the URI in the |
| 1558 | ++ address-of-record of a registration. |
| 1559 | ++ |
| 1560 | ++ Informational Response: Same as a provisional response. |
| 1561 | ++ |
| 1562 | ++ Initiator, Calling Party, Caller: The party initiating a session |
| 1563 | ++ (and dialog) with an INVITE request. A caller retains this |
| 1564 | ++ role from the time it sends the initial INVITE that established |
| 1565 | ++ a dialog until the termination of that dialog. |
| 1566 | ++ |
| 1567 | ++ Invitation: An INVITE request. |
| 1568 | ++ |
| 1569 | ++ Invitee, Invited User, Called Party, Callee: The party that |
| 1570 | ++ receives an INVITE request for the purpose of establishing a |
| 1571 | ++ new session. A callee retains this role from the time it |
| 1572 | ++ receives the INVITE until the termination of the dialog |
| 1573 | ++ established by that INVITE. |
| 1574 | ++ |
| 1575 | ++ Location Service: A location service is used by a SIP redirect or |
| 1576 | ++ proxy server to obtain information about a callee's possible |
| 1577 | ++ location(s). It contains a list of bindings of address-of- |
| 1578 | ++ record keys to zero or more contact addresses. The bindings |
| 1579 | ++ can be created and removed in many ways; this specification |
| 1580 | ++ defines a REGISTER method that updates the bindings. |
| 1581 | ++ |
| 1582 | ++ Loop: A request that arrives at a proxy, is forwarded, and later |
| 1583 | ++ arrives back at the same proxy. When it arrives the second |
| 1584 | ++ time, its Request-URI is identical to the first time, and other |
| 1585 | ++ header fields that affect proxy operation are unchanged, so |
| 1586 | ++ that the proxy would make the same processing decision on the |
| 1587 | ++ request it made the first time. Looped requests are errors, |
| 1588 | ++ and the procedures for detecting them and handling them are |
| 1589 | ++ described by the protocol. |
| 1590 | ++ |
| 1591 | ++ Loose Routing: A proxy is said to be loose routing if it follows |
| 1592 | ++ the procedures defined in this specification for processing of |
| 1593 | ++ the Route header field. These procedures separate the |
| 1594 | ++ destination of the request (present in the Request-URI) from |
| 1595 | ++ |
| 1596 | ++ |
| 1597 | ++ |
| 1598 | ++ |
| 1599 | ++ |
| 1600 | ++Rosenberg, et. al. Standards Track [Page 22] |
| 1601 | ++ |
| 1602 | |
| 1603 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1604 | ++ |
| 1605 | ++ |
| 1606 | ++ the set of proxies that need to be visited along the way |
| 1607 | ++ (present in the Route header field). A proxy compliant to |
| 1608 | ++ these mechanisms is also known as a loose router. |
| 1609 | ++ |
| 1610 | ++ Message: Data sent between SIP elements as part of the protocol. |
| 1611 | ++ SIP messages are either requests or responses. |
| 1612 | ++ |
| 1613 | ++ Method: The method is the primary function that a request is meant |
| 1614 | ++ to invoke on a server. The method is carried in the request |
| 1615 | ++ message itself. Example methods are INVITE and BYE. |
| 1616 | ++ |
| 1617 | ++ Outbound Proxy: A proxy that receives requests from a client, even |
| 1618 | ++ though it may not be the server resolved by the Request-URI. |
| 1619 | ++ Typically, a UA is manually configured with an outbound proxy, |
| 1620 | ++ or can learn about one through auto-configuration protocols. |
| 1621 | ++ |
| 1622 | ++ Parallel Search: In a parallel search, a proxy issues several |
| 1623 | ++ requests to possible user locations upon receiving an incoming |
| 1624 | ++ request. Rather than issuing one request and then waiting for |
| 1625 | ++ the final response before issuing the next request as in a |
| 1626 | ++ sequential search, a parallel search issues requests without |
| 1627 | ++ waiting for the result of previous requests. |
| 1628 | ++ |
| 1629 | ++ Provisional Response: A response used by the server to indicate |
| 1630 | ++ progress, but that does not terminate a SIP transaction. 1xx |
| 1631 | ++ responses are provisional, other responses are considered |
| 1632 | ++ final. |
| 1633 | ++ |
| 1634 | ++ Proxy, Proxy Server: An intermediary entity that acts as both a |
| 1635 | ++ server and a client for the purpose of making requests on |
| 1636 | ++ behalf of other clients. A proxy server primarily plays the |
| 1637 | ++ role of routing, which means its job is to ensure that a |
| 1638 | ++ request is sent to another entity "closer" to the targeted |
| 1639 | ++ user. Proxies are also useful for enforcing policy (for |
| 1640 | ++ example, making sure a user is allowed to make a call). A |
| 1641 | ++ proxy interprets, and, if necessary, rewrites specific parts of |
| 1642 | ++ a request message before forwarding it. |
| 1643 | ++ |
| 1644 | ++ Recursion: A client recurses on a 3xx response when it generates a |
| 1645 | ++ new request to one or more of the URIs in the Contact header |
| 1646 | ++ field in the response. |
| 1647 | ++ |
| 1648 | ++ Redirect Server: A redirect server is a user agent server that |
| 1649 | ++ generates 3xx responses to requests it receives, directing the |
| 1650 | ++ client to contact an alternate set of URIs. |
| 1651 | ++ |
| 1652 | ++ |
| 1653 | ++ |
| 1654 | ++ |
| 1655 | ++ |
| 1656 | ++ |
| 1657 | ++Rosenberg, et. al. Standards Track [Page 23] |
| 1658 | ++ |
| 1659 | |
| 1660 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1661 | ++ |
| 1662 | ++ |
| 1663 | ++ Registrar: A registrar is a server that accepts REGISTER requests |
| 1664 | ++ and places the information it receives in those requests into |
| 1665 | ++ the location service for the domain it handles. |
| 1666 | ++ |
| 1667 | ++ Regular Transaction: A regular transaction is any transaction with |
| 1668 | ++ a method other than INVITE, ACK, or CANCEL. |
| 1669 | ++ |
| 1670 | ++ Request: A SIP message sent from a client to a server, for the |
| 1671 | ++ purpose of invoking a particular operation. |
| 1672 | ++ |
| 1673 | ++ Response: A SIP message sent from a server to a client, for |
| 1674 | ++ indicating the status of a request sent from the client to the |
| 1675 | ++ server. |
| 1676 | ++ |
| 1677 | ++ Ringback: Ringback is the signaling tone produced by the calling |
| 1678 | ++ party's application indicating that a called party is being |
| 1679 | ++ alerted (ringing). |
| 1680 | ++ |
| 1681 | ++ Route Set: A route set is a collection of ordered SIP or SIPS URI |
| 1682 | ++ which represent a list of proxies that must be traversed when |
| 1683 | ++ sending a particular request. A route set can be learned, |
| 1684 | ++ through headers like Record-Route, or it can be configured. |
| 1685 | ++ |
| 1686 | ++ Server: A server is a network element that receives requests in |
| 1687 | ++ order to service them and sends back responses to those |
| 1688 | ++ requests. Examples of servers are proxies, user agent servers, |
| 1689 | ++ redirect servers, and registrars. |
| 1690 | ++ |
| 1691 | ++ Sequential Search: In a sequential search, a proxy server attempts |
| 1692 | ++ each contact address in sequence, proceeding to the next one |
| 1693 | ++ only after the previous has generated a final response. A 2xx |
| 1694 | ++ or 6xx class final response always terminates a sequential |
| 1695 | ++ search. |
| 1696 | ++ |
| 1697 | ++ Session: From the SDP specification: "A multimedia session is a |
| 1698 | ++ set of multimedia senders and receivers and the data streams |
| 1699 | ++ flowing from senders to receivers. A multimedia conference is |
| 1700 | ++ an example of a multimedia session." (RFC 2327 [1]) (A session |
| 1701 | ++ as defined for SDP can comprise one or more RTP sessions.) As |
| 1702 | ++ defined, a callee can be invited several times, by different |
| 1703 | ++ calls, to the same session. If SDP is used, a session is |
| 1704 | ++ defined by the concatenation of the SDP user name, session id, |
| 1705 | ++ network type, address type, and address elements in the origin |
| 1706 | ++ field. |
| 1707 | ++ |
| 1708 | ++ SIP Transaction: A SIP transaction occurs between a client and a |
| 1709 | ++ server and comprises all messages from the first request sent |
| 1710 | ++ from the client to the server up to a final (non-1xx) response |
| 1711 | ++ |
| 1712 | ++ |
| 1713 | ++ |
| 1714 | ++Rosenberg, et. al. Standards Track [Page 24] |
| 1715 | ++ |
| 1716 | |
| 1717 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1718 | ++ |
| 1719 | ++ |
| 1720 | ++ sent from the server to the client. If the request is INVITE |
| 1721 | ++ and the final response is a non-2xx, the transaction also |
| 1722 | ++ includes an ACK to the response. The ACK for a 2xx response to |
| 1723 | ++ an INVITE request is a separate transaction. |
| 1724 | ++ |
| 1725 | ++ Spiral: A spiral is a SIP request that is routed to a proxy, |
| 1726 | ++ forwarded onwards, and arrives once again at that proxy, but |
| 1727 | ++ this time differs in a way that will result in a different |
| 1728 | ++ processing decision than the original request. Typically, this |
| 1729 | ++ means that the request's Request-URI differs from its previous |
| 1730 | ++ arrival. A spiral is not an error condition, unlike a loop. A |
| 1731 | ++ typical cause for this is call forwarding. A user calls |
| 1732 | ++ joe@example.com. The example.com proxy forwards it to Joe's |
| 1733 | ++ PC, which in turn, forwards it to bob@example.com. This |
| 1734 | ++ request is proxied back to the example.com proxy. However, |
| 1735 | ++ this is not a loop. Since the request is targeted at a |
| 1736 | ++ different user, it is considered a spiral, and is a valid |
| 1737 | ++ condition. |
| 1738 | ++ |
| 1739 | ++ Stateful Proxy: A logical entity that maintains the client and |
| 1740 | ++ server transaction state machines defined by this specification |
| 1741 | ++ during the processing of a request, also known as a transaction |
| 1742 | ++ stateful proxy. The behavior of a stateful proxy is further |
| 1743 | ++ defined in Section 16. A (transaction) stateful proxy is not |
| 1744 | ++ the same as a call stateful proxy. |
| 1745 | ++ |
| 1746 | ++ Stateless Proxy: A logical entity that does not maintain the |
| 1747 | ++ client or server transaction state machines defined in this |
| 1748 | ++ specification when it processes requests. A stateless proxy |
| 1749 | ++ forwards every request it receives downstream and every |
| 1750 | ++ response it receives upstream. |
| 1751 | ++ |
| 1752 | ++ Strict Routing: A proxy is said to be strict routing if it follows |
| 1753 | ++ the Route processing rules of RFC 2543 and many prior work in |
| 1754 | ++ progress versions of this RFC. That rule caused proxies to |
| 1755 | ++ destroy the contents of the Request-URI when a Route header |
| 1756 | ++ field was present. Strict routing behavior is not used in this |
| 1757 | ++ specification, in favor of a loose routing behavior. Proxies |
| 1758 | ++ that perform strict routing are also known as strict routers. |
| 1759 | ++ |
| 1760 | ++ Target Refresh Request: A target refresh request sent within a |
| 1761 | ++ dialog is defined as a request that can modify the remote |
| 1762 | ++ target of the dialog. |
| 1763 | ++ |
| 1764 | ++ Transaction User (TU): The layer of protocol processing that |
| 1765 | ++ resides above the transaction layer. Transaction users include |
| 1766 | ++ the UAC core, UAS core, and proxy core. |
| 1767 | ++ |
| 1768 | ++ |
| 1769 | ++ |
| 1770 | ++ |
| 1771 | ++Rosenberg, et. al. Standards Track [Page 25] |
| 1772 | ++ |
| 1773 | |
| 1774 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1775 | ++ |
| 1776 | ++ |
| 1777 | ++ Upstream: A direction of message forwarding within a transaction |
| 1778 | ++ that refers to the direction that responses flow from the user |
| 1779 | ++ agent server back to the user agent client. |
| 1780 | ++ |
| 1781 | ++ URL-encoded: A character string encoded according to RFC 2396, |
| 1782 | ++ Section 2.4 [5]. |
| 1783 | ++ |
| 1784 | ++ User Agent Client (UAC): A user agent client is a logical entity |
| 1785 | ++ that creates a new request, and then uses the client |
| 1786 | ++ transaction state machinery to send it. The role of UAC lasts |
| 1787 | ++ only for the duration of that transaction. In other words, if |
| 1788 | ++ a piece of software initiates a request, it acts as a UAC for |
| 1789 | ++ the duration of that transaction. If it receives a request |
| 1790 | ++ later, it assumes the role of a user agent server for the |
| 1791 | ++ processing of that transaction. |
| 1792 | ++ |
| 1793 | ++ UAC Core: The set of processing functions required of a UAC that |
| 1794 | ++ reside above the transaction and transport layers. |
| 1795 | ++ |
| 1796 | ++ User Agent Server (UAS): A user agent server is a logical entity |
| 1797 | ++ that generates a response to a SIP request. The response |
| 1798 | ++ accepts, rejects, or redirects the request. This role lasts |
| 1799 | ++ only for the duration of that transaction. In other words, if |
| 1800 | ++ a piece of software responds to a request, it acts as a UAS for |
| 1801 | ++ the duration of that transaction. If it generates a request |
| 1802 | ++ later, it assumes the role of a user agent client for the |
| 1803 | ++ processing of that transaction. |
| 1804 | ++ |
| 1805 | ++ UAS Core: The set of processing functions required at a UAS that |
| 1806 | ++ resides above the transaction and transport layers. |
| 1807 | ++ |
| 1808 | ++ User Agent (UA): A logical entity that can act as both a user |
| 1809 | ++ agent client and user agent server. |
| 1810 | ++ |
| 1811 | ++ The role of UAC and UAS, as well as proxy and redirect servers, are |
| 1812 | ++ defined on a transaction-by-transaction basis. For example, the user |
| 1813 | ++ agent initiating a call acts as a UAC when sending the initial INVITE |
| 1814 | ++ request and as a UAS when receiving a BYE request from the callee. |
| 1815 | ++ Similarly, the same software can act as a proxy server for one |
| 1816 | ++ request and as a redirect server for the next request. |
| 1817 | ++ |
| 1818 | ++ Proxy, location, and registrar servers defined above are logical |
| 1819 | ++ entities; implementations MAY combine them into a single application. |
| 1820 | ++ |
| 1821 | ++7 SIP Messages |
| 1822 | ++ |
| 1823 | ++ SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 |
| 1824 | ++ [7]). |
| 1825 | ++ |
| 1826 | ++ |
| 1827 | ++ |
| 1828 | ++Rosenberg, et. al. Standards Track [Page 26] |
| 1829 | ++ |
| 1830 | |
| 1831 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1832 | ++ |
| 1833 | ++ |
| 1834 | ++ A SIP message is either a request from a client to a server, or a |
| 1835 | ++ response from a server to a client. |
| 1836 | ++ |
| 1837 | ++ Both Request (section 7.1) and Response (section 7.2) messages use |
| 1838 | ++ the basic format of RFC 2822 [3], even though the syntax differs in |
| 1839 | ++ character set and syntax specifics. (SIP allows header fields that |
| 1840 | ++ would not be valid RFC 2822 header fields, for example.) Both types |
| 1841 | ++ of messages consist of a start-line, one or more header fields, an |
| 1842 | ++ empty line indicating the end of the header fields, and an optional |
| 1843 | ++ message-body. |
| 1844 | ++ |
| 1845 | ++ generic-message = start-line |
| 1846 | ++ *message-header |
| 1847 | ++ CRLF |
| 1848 | ++ [ message-body ] |
| 1849 | ++ start-line = Request-Line / Status-Line |
| 1850 | ++ |
| 1851 | ++ The start-line, each message-header line, and the empty line MUST be |
| 1852 | ++ terminated by a carriage-return line-feed sequence (CRLF). Note that |
| 1853 | ++ the empty line MUST be present even if the message-body is not. |
| 1854 | ++ |
| 1855 | ++ Except for the above difference in character sets, much of SIP's |
| 1856 | ++ message and header field syntax is identical to HTTP/1.1. Rather |
| 1857 | ++ than repeating the syntax and semantics here, we use [HX.Y] to refer |
| 1858 | ++ to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). |
| 1859 | ++ |
| 1860 | ++ However, SIP is not an extension of HTTP. |
| 1861 | ++ |
| 1862 | ++7.1 Requests |
| 1863 | ++ |
| 1864 | ++ SIP requests are distinguished by having a Request-Line for a start- |
| 1865 | ++ line. A Request-Line contains a method name, a Request-URI, and the |
| 1866 | ++ protocol version separated by a single space (SP) character. |
| 1867 | ++ |
| 1868 | ++ The Request-Line ends with CRLF. No CR or LF are allowed except in |
| 1869 | ++ the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed |
| 1870 | ++ in any of the elements. |
| 1871 | ++ |
| 1872 | ++ Request-Line = Method SP Request-URI SP SIP-Version CRLF |
| 1873 | ++ |
| 1874 | ++ Method: This specification defines six methods: REGISTER for |
| 1875 | ++ registering contact information, INVITE, ACK, and CANCEL for |
| 1876 | ++ setting up sessions, BYE for terminating sessions, and |
| 1877 | ++ OPTIONS for querying servers about their capabilities. SIP |
| 1878 | ++ extensions, documented in standards track RFCs, may define |
| 1879 | ++ additional methods. |
| 1880 | ++ |
| 1881 | ++ |
| 1882 | ++ |
| 1883 | ++ |
| 1884 | ++ |
| 1885 | ++Rosenberg, et. al. Standards Track [Page 27] |
| 1886 | ++ |
| 1887 | |
| 1888 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1889 | ++ |
| 1890 | ++ |
| 1891 | ++ Request-URI: The Request-URI is a SIP or SIPS URI as described in |
| 1892 | ++ Section 19.1 or a general URI (RFC 2396 [5]). It indicates |
| 1893 | ++ the user or service to which this request is being addressed. |
| 1894 | ++ The Request-URI MUST NOT contain unescaped spaces or control |
| 1895 | ++ characters and MUST NOT be enclosed in "<>". |
| 1896 | ++ |
| 1897 | ++ SIP elements MAY support Request-URIs with schemes other than |
| 1898 | ++ "sip" and "sips", for example the "tel" URI scheme of RFC |
| 1899 | ++ 2806 [9]. SIP elements MAY translate non-SIP URIs using any |
| 1900 | ++ mechanism at their disposal, resulting in SIP URI, SIPS URI, |
| 1901 | ++ or some other scheme. |
| 1902 | ++ |
| 1903 | ++ SIP-Version: Both request and response messages include the |
| 1904 | ++ version of SIP in use, and follow [H3.1] (with HTTP replaced |
| 1905 | ++ by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version |
| 1906 | ++ ordering, compliance requirements, and upgrading of version |
| 1907 | ++ numbers. To be compliant with this specification, |
| 1908 | ++ applications sending SIP messages MUST include a SIP-Version |
| 1909 | ++ of "SIP/2.0". The SIP-Version string is case-insensitive, |
| 1910 | ++ but implementations MUST send upper-case. |
| 1911 | ++ |
| 1912 | ++ Unlike HTTP/1.1, SIP treats the version number as a literal |
| 1913 | ++ string. In practice, this should make no difference. |
| 1914 | ++ |
| 1915 | ++7.2 Responses |
| 1916 | ++ |
| 1917 | ++ SIP responses are distinguished from requests by having a Status-Line |
| 1918 | ++ as their start-line. A Status-Line consists of the protocol version |
| 1919 | ++ followed by a numeric Status-Code and its associated textual phrase, |
| 1920 | ++ with each element separated by a single SP character. |
| 1921 | ++ |
| 1922 | ++ No CR or LF is allowed except in the final CRLF sequence. |
| 1923 | ++ |
| 1924 | ++ Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF |
| 1925 | ++ |
| 1926 | ++ The Status-Code is a 3-digit integer result code that indicates the |
| 1927 | ++ outcome of an attempt to understand and satisfy a request. The |
| 1928 | ++ Reason-Phrase is intended to give a short textual description of the |
| 1929 | ++ Status-Code. The Status-Code is intended for use by automata, |
| 1930 | ++ whereas the Reason-Phrase is intended for the human user. A client |
| 1931 | ++ is not required to examine or display the Reason-Phrase. |
| 1932 | ++ |
| 1933 | ++ While this specification suggests specific wording for the reason |
| 1934 | ++ phrase, implementations MAY choose other text, for example, in the |
| 1935 | ++ language indicated in the Accept-Language header field of the |
| 1936 | ++ request. |
| 1937 | ++ |
| 1938 | ++ |
| 1939 | ++ |
| 1940 | ++ |
| 1941 | ++ |
| 1942 | ++Rosenberg, et. al. Standards Track [Page 28] |
| 1943 | ++ |
| 1944 | |
| 1945 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 1946 | ++ |
| 1947 | ++ |
| 1948 | ++ The first digit of the Status-Code defines the class of response. |
| 1949 | ++ The last two digits do not have any categorization role. For this |
| 1950 | ++ reason, any response with a status code between 100 and 199 is |
| 1951 | ++ referred to as a "1xx response", any response with a status code |
| 1952 | ++ between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows |
| 1953 | ++ six values for the first digit: |
| 1954 | ++ |
| 1955 | ++ 1xx: Provisional -- request received, continuing to process the |
| 1956 | ++ request; |
| 1957 | ++ |
| 1958 | ++ 2xx: Success -- the action was successfully received, understood, |
| 1959 | ++ and accepted; |
| 1960 | ++ |
| 1961 | ++ 3xx: Redirection -- further action needs to be taken in order to |
| 1962 | ++ complete the request; |
| 1963 | ++ |
| 1964 | ++ 4xx: Client Error -- the request contains bad syntax or cannot be |
| 1965 | ++ fulfilled at this server; |
| 1966 | ++ |
| 1967 | ++ 5xx: Server Error -- the server failed to fulfill an apparently |
| 1968 | ++ valid request; |
| 1969 | ++ |
| 1970 | ++ 6xx: Global Failure -- the request cannot be fulfilled at any |
| 1971 | ++ server. |
| 1972 | ++ |
| 1973 | ++ Section 21 defines these classes and describes the individual codes. |
| 1974 | ++ |
| 1975 | ++7.3 Header Fields |
| 1976 | ++ |
| 1977 | ++ SIP header fields are similar to HTTP header fields in both syntax |
| 1978 | ++ and semantics. In particular, SIP header fields follow the [H4.2] |
| 1979 | ++ definitions of syntax for the message-header and the rules for |
| 1980 | ++ extending header fields over multiple lines. However, the latter is |
| 1981 | ++ specified in HTTP with implicit whitespace and folding. This |
| 1982 | ++ specification conforms to RFC 2234 [10] and uses only explicit |
| 1983 | ++ whitespace and folding as an integral part of the grammar. |
| 1984 | ++ |
| 1985 | ++ [H4.2] also specifies that multiple header fields of the same field |
| 1986 | ++ name whose value is a comma-separated list can be combined into one |
| 1987 | ++ header field. That applies to SIP as well, but the specific rule is |
| 1988 | ++ different because of the different grammars. Specifically, any SIP |
| 1989 | ++ header whose grammar is of the form |
| 1990 | ++ |
| 1991 | ++ header = "header-name" HCOLON header-value *(COMMA header-value) |
| 1992 | ++ |
| 1993 | ++ allows for combining header fields of the same name into a comma- |
| 1994 | ++ separated list. The Contact header field allows a comma-separated |
| 1995 | ++ list unless the header field value is "*". |
| 1996 | ++ |
| 1997 | ++ |
| 1998 | ++ |
| 1999 | ++Rosenberg, et. al. Standards Track [Page 29] |
| 2000 | ++ |
| 2001 | |
| 2002 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2003 | ++ |
| 2004 | ++ |
| 2005 | ++7.3.1 Header Field Format |
| 2006 | ++ |
| 2007 | ++ Header fields follow the same generic header format as that given in |
| 2008 | ++ Section 2.2 of RFC 2822 [3]. Each header field consists of a field |
| 2009 | ++ name followed by a colon (":") and the field value. |
| 2010 | ++ |
| 2011 | ++ field-name: field-value |
| 2012 | ++ |
| 2013 | ++ The formal grammar for a message-header specified in Section 25 |
| 2014 | ++ allows for an arbitrary amount of whitespace on either side of the |
| 2015 | ++ colon; however, implementations should avoid spaces between the field |
| 2016 | ++ name and the colon and use a single space (SP) between the colon and |
| 2017 | ++ the field-value. |
| 2018 | ++ |
| 2019 | ++ Subject: lunch |
| 2020 | ++ Subject : lunch |
| 2021 | ++ Subject :lunch |
| 2022 | ++ Subject: lunch |
| 2023 | ++ |
| 2024 | ++ Thus, the above are all valid and equivalent, but the last is the |
| 2025 | ++ preferred form. |
| 2026 | ++ |
| 2027 | ++ Header fields can be extended over multiple lines by preceding each |
| 2028 | ++ extra line with at least one SP or horizontal tab (HT). The line |
| 2029 | ++ break and the whitespace at the beginning of the next line are |
| 2030 | ++ treated as a single SP character. Thus, the following are |
| 2031 | ++ equivalent: |
| 2032 | ++ |
| 2033 | ++ Subject: I know you're there, pick up the phone and talk to me! |
| 2034 | ++ Subject: I know you're there, |
| 2035 | ++ pick up the phone |
| 2036 | ++ and talk to me! |
| 2037 | ++ |
| 2038 | ++ The relative order of header fields with different field names is not |
| 2039 | ++ significant. However, it is RECOMMENDED that header fields which are |
| 2040 | ++ needed for proxy processing (Via, Route, Record-Route, Proxy-Require, |
| 2041 | ++ Max-Forwards, and Proxy-Authorization, for example) appear towards |
| 2042 | ++ the top of the message to facilitate rapid parsing. The relative |
| 2043 | ++ order of header field rows with the same field name is important. |
| 2044 | ++ Multiple header field rows with the same field-name MAY be present in |
| 2045 | ++ a message if and only if the entire field-value for that header field |
| 2046 | ++ is defined as a comma-separated list (that is, if follows the grammar |
| 2047 | ++ defined in Section 7.3). It MUST be possible to combine the multiple |
| 2048 | ++ header field rows into one "field-name: field-value" pair, without |
| 2049 | ++ changing the semantics of the message, by appending each subsequent |
| 2050 | ++ field-value to the first, each separated by a comma. The exceptions |
| 2051 | ++ to this rule are the WWW-Authenticate, Authorization, Proxy- |
| 2052 | ++ Authenticate, and Proxy-Authorization header fields. Multiple header |
| 2053 | ++ |
| 2054 | ++ |
| 2055 | ++ |
| 2056 | ++Rosenberg, et. al. Standards Track [Page 30] |
| 2057 | ++ |
| 2058 | |
| 2059 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2060 | ++ |
| 2061 | ++ |
| 2062 | ++ field rows with these names MAY be present in a message, but since |
| 2063 | ++ their grammar does not follow the general form listed in Section 7.3, |
| 2064 | ++ they MUST NOT be combined into a single header field row. |
| 2065 | ++ |
| 2066 | ++ Implementations MUST be able to process multiple header field rows |
| 2067 | ++ with the same name in any combination of the single-value-per-line or |
| 2068 | ++ comma-separated value forms. |
| 2069 | ++ |
| 2070 | ++ The following groups of header field rows are valid and equivalent: |
| 2071 | ++ |
| 2072 | ++ Route: <sip:alice@atlanta.com> |
| 2073 | ++ Subject: Lunch |
| 2074 | ++ Route: <sip:bob@biloxi.com> |
| 2075 | ++ Route: <sip:carol@chicago.com> |
| 2076 | ++ |
| 2077 | ++ Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com> |
| 2078 | ++ Route: <sip:carol@chicago.com> |
| 2079 | ++ Subject: Lunch |
| 2080 | ++ |
| 2081 | ++ Subject: Lunch |
| 2082 | ++ Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, |
| 2083 | ++ <sip:carol@chicago.com> |
| 2084 | ++ |
| 2085 | ++ Each of the following blocks is valid but not equivalent to the |
| 2086 | ++ others: |
| 2087 | ++ |
| 2088 | ++ Route: <sip:alice@atlanta.com> |
| 2089 | ++ Route: <sip:bob@biloxi.com> |
| 2090 | ++ Route: <sip:carol@chicago.com> |
| 2091 | ++ |
| 2092 | ++ Route: <sip:bob@biloxi.com> |
| 2093 | ++ Route: <sip:alice@atlanta.com> |
| 2094 | ++ Route: <sip:carol@chicago.com> |
| 2095 | ++ |
| 2096 | ++ Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, |
| 2097 | ++ <sip:bob@biloxi.com> |
| 2098 | ++ |
| 2099 | ++ The format of a header field-value is defined per header-name. It |
| 2100 | ++ will always be either an opaque sequence of TEXT-UTF8 octets, or a |
| 2101 | ++ combination of whitespace, tokens, separators, and quoted strings. |
| 2102 | ++ Many existing header fields will adhere to the general form of a |
| 2103 | ++ value followed by a semi-colon separated sequence of parameter-name, |
| 2104 | ++ parameter-value pairs: |
| 2105 | ++ |
| 2106 | ++ field-name: field-value *(;parameter-name=parameter-value) |
| 2107 | ++ |
| 2108 | ++ |
| 2109 | ++ |
| 2110 | ++ |
| 2111 | ++ |
| 2112 | ++ |
| 2113 | ++Rosenberg, et. al. Standards Track [Page 31] |
| 2114 | ++ |
| 2115 | |
| 2116 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2117 | ++ |
| 2118 | ++ |
| 2119 | ++ Even though an arbitrary number of parameter pairs may be attached to |
| 2120 | ++ a header field value, any given parameter-name MUST NOT appear more |
| 2121 | ++ than once. |
| 2122 | ++ |
| 2123 | ++ When comparing header fields, field names are always case- |
| 2124 | ++ insensitive. Unless otherwise stated in the definition of a |
| 2125 | ++ particular header field, field values, parameter names, and parameter |
| 2126 | ++ values are case-insensitive. Tokens are always case-insensitive. |
| 2127 | ++ Unless specified otherwise, values expressed as quoted strings are |
| 2128 | ++ case-sensitive. For example, |
| 2129 | ++ |
| 2130 | ++ Contact: <sip:alice@atlanta.com>;expires=3600 |
| 2131 | ++ |
| 2132 | ++ is equivalent to |
| 2133 | ++ |
| 2134 | ++ CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600 |
| 2135 | ++ |
| 2136 | ++ and |
| 2137 | ++ |
| 2138 | ++ Content-Disposition: session;handling=optional |
| 2139 | ++ |
| 2140 | ++ is equivalent to |
| 2141 | ++ |
| 2142 | ++ content-disposition: Session;HANDLING=OPTIONAL |
| 2143 | ++ |
| 2144 | ++ The following two header fields are not equivalent: |
| 2145 | ++ |
| 2146 | ++ Warning: 370 devnull "Choose a bigger pipe" |
| 2147 | ++ Warning: 370 devnull "CHOOSE A BIGGER PIPE" |
| 2148 | ++ |
| 2149 | ++7.3.2 Header Field Classification |
| 2150 | ++ |
| 2151 | ++ Some header fields only make sense in requests or responses. These |
| 2152 | ++ are called request header fields and response header fields, |
| 2153 | ++ respectively. If a header field appears in a message not matching |
| 2154 | ++ its category (such as a request header field in a response), it MUST |
| 2155 | ++ be ignored. Section 20 defines the classification of each header |
| 2156 | ++ field. |
| 2157 | ++ |
| 2158 | ++7.3.3 Compact Form |
| 2159 | ++ |
| 2160 | ++ SIP provides a mechanism to represent common header field names in an |
| 2161 | ++ abbreviated form. This may be useful when messages would otherwise |
| 2162 | ++ become too large to be carried on the transport available to it |
| 2163 | ++ (exceeding the maximum transmission unit (MTU) when using UDP, for |
| 2164 | ++ example). These compact forms are defined in Section 20. A compact |
| 2165 | ++ form MAY be substituted for the longer form of a header field name at |
| 2166 | ++ any time without changing the semantics of the message. A header |
| 2167 | ++ |
| 2168 | ++ |
| 2169 | ++ |
| 2170 | ++Rosenberg, et. al. Standards Track [Page 32] |
| 2171 | ++ |
| 2172 | |
| 2173 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2174 | ++ |
| 2175 | ++ |
| 2176 | ++ field name MAY appear in both long and short forms within the same |
| 2177 | ++ message. Implementations MUST accept both the long and short forms |
| 2178 | ++ of each header name. |
| 2179 | ++ |
| 2180 | ++7.4 Bodies |
| 2181 | ++ |
| 2182 | ++ Requests, including new requests defined in extensions to this |
| 2183 | ++ specification, MAY contain message bodies unless otherwise noted. |
| 2184 | ++ The interpretation of the body depends on the request method. |
| 2185 | ++ |
| 2186 | ++ For response messages, the request method and the response status |
| 2187 | ++ code determine the type and interpretation of any message body. All |
| 2188 | ++ responses MAY include a body. |
| 2189 | ++ |
| 2190 | ++7.4.1 Message Body Type |
| 2191 | ++ |
| 2192 | ++ The Internet media type of the message body MUST be given by the |
| 2193 | ++ Content-Type header field. If the body has undergone any encoding |
| 2194 | ++ such as compression, then this MUST be indicated by the Content- |
| 2195 | ++ Encoding header field; otherwise, Content-Encoding MUST be omitted. |
| 2196 | ++ If applicable, the character set of the message body is indicated as |
| 2197 | ++ part of the Content-Type header-field value. |
| 2198 | ++ |
| 2199 | ++ The "multipart" MIME type defined in RFC 2046 [11] MAY be used within |
| 2200 | ++ the body of the message. Implementations that send requests |
| 2201 | ++ containing multipart message bodies MUST send a session description |
| 2202 | ++ as a non-multipart message body if the remote implementation requests |
| 2203 | ++ this through an Accept header field that does not contain multipart. |
| 2204 | ++ |
| 2205 | ++ SIP messages MAY contain binary bodies or body parts. When no |
| 2206 | ++ explicit charset parameter is provided by the sender, media subtypes |
| 2207 | ++ of the "text" type are defined to have a default charset value of |
| 2208 | ++ "UTF-8". |
| 2209 | ++ |
| 2210 | ++7.4.2 Message Body Length |
| 2211 | ++ |
| 2212 | ++ The body length in bytes is provided by the Content-Length header |
| 2213 | ++ field. Section 20.14 describes the necessary contents of this header |
| 2214 | ++ field in detail. |
| 2215 | ++ |
| 2216 | ++ The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. |
| 2217 | ++ (Note: The chunked encoding modifies the body of a message in order |
| 2218 | ++ to transfer it as a series of chunks, each with its own size |
| 2219 | ++ indicator.) |
| 2220 | ++ |
| 2221 | ++ |
| 2222 | ++ |
| 2223 | ++ |
| 2224 | ++ |
| 2225 | ++ |
| 2226 | ++ |
| 2227 | ++Rosenberg, et. al. Standards Track [Page 33] |
| 2228 | ++ |
| 2229 | |
| 2230 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2231 | ++ |
| 2232 | ++ |
| 2233 | ++7.5 Framing SIP Messages |
| 2234 | ++ |
| 2235 | ++ Unlike HTTP, SIP implementations can use UDP or other unreliable |
| 2236 | ++ datagram protocols. Each such datagram carries one request or |
| 2237 | ++ response. See Section 18 on constraints on usage of unreliable |
| 2238 | ++ transports. |
| 2239 | ++ |
| 2240 | ++ Implementations processing SIP messages over stream-oriented |
| 2241 | ++ transports MUST ignore any CRLF appearing before the start-line |
| 2242 | ++ [H4.1]. |
| 2243 | ++ |
| 2244 | ++ The Content-Length header field value is used to locate the end of |
| 2245 | ++ each SIP message in a stream. It will always be present when SIP |
| 2246 | ++ messages are sent over stream-oriented transports. |
| 2247 | ++ |
| 2248 | ++8 General User Agent Behavior |
| 2249 | ++ |
| 2250 | ++ A user agent represents an end system. It contains a user agent |
| 2251 | ++ client (UAC), which generates requests, and a user agent server |
| 2252 | ++ (UAS), which responds to them. A UAC is capable of generating a |
| 2253 | ++ request based on some external stimulus (the user clicking a button, |
| 2254 | ++ or a signal on a PSTN line) and processing a response. A UAS is |
| 2255 | ++ capable of receiving a request and generating a response based on |
| 2256 | ++ user input, external stimulus, the result of a program execution, or |
| 2257 | ++ some other mechanism. |
| 2258 | ++ |
| 2259 | ++ When a UAC sends a request, the request passes through some number of |
| 2260 | ++ proxy servers, which forward the request towards the UAS. When the |
| 2261 | ++ UAS generates a response, the response is forwarded towards the UAC. |
| 2262 | ++ |
| 2263 | ++ UAC and UAS procedures depend strongly on two factors. First, based |
| 2264 | ++ on whether the request or response is inside or outside of a dialog, |
| 2265 | ++ and second, based on the method of a request. Dialogs are discussed |
| 2266 | ++ thoroughly in Section 12; they represent a peer-to-peer relationship |
| 2267 | ++ between user agents and are established by specific SIP methods, such |
| 2268 | ++ as INVITE. |
| 2269 | ++ |
| 2270 | ++ In this section, we discuss the method-independent rules for UAC and |
| 2271 | ++ UAS behavior when processing requests that are outside of a dialog. |
| 2272 | ++ This includes, of course, the requests which themselves establish a |
| 2273 | ++ dialog. |
| 2274 | ++ |
| 2275 | ++ Security procedures for requests and responses outside of a dialog |
| 2276 | ++ are described in Section 26. Specifically, mechanisms exist for the |
| 2277 | ++ UAS and UAC to mutually authenticate. A limited set of privacy |
| 2278 | ++ features are also supported through encryption of bodies using |
| 2279 | ++ S/MIME. |
| 2280 | ++ |
| 2281 | ++ |
| 2282 | ++ |
| 2283 | ++ |
| 2284 | ++Rosenberg, et. al. Standards Track [Page 34] |
| 2285 | ++ |
| 2286 | |
| 2287 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2288 | ++ |
| 2289 | ++ |
| 2290 | ++8.1 UAC Behavior |
| 2291 | ++ |
| 2292 | ++ This section covers UAC behavior outside of a dialog. |
| 2293 | ++ |
| 2294 | ++8.1.1 Generating the Request |
| 2295 | ++ |
| 2296 | ++ A valid SIP request formulated by a UAC MUST, at a minimum, contain |
| 2297 | ++ the following header fields: To, From, CSeq, Call-ID, Max-Forwards, |
| 2298 | ++ and Via; all of these header fields are mandatory in all SIP |
| 2299 | ++ requests. These six header fields are the fundamental building |
| 2300 | ++ blocks of a SIP message, as they jointly provide for most of the |
| 2301 | ++ critical message routing services including the addressing of |
| 2302 | ++ messages, the routing of responses, limiting message propagation, |
| 2303 | ++ ordering of messages, and the unique identification of transactions. |
| 2304 | ++ These header fields are in addition to the mandatory request line, |
| 2305 | ++ which contains the method, Request-URI, and SIP version. |
| 2306 | ++ |
| 2307 | ++ Examples of requests sent outside of a dialog include an INVITE to |
| 2308 | ++ establish a session (Section 13) and an OPTIONS to query for |
| 2309 | ++ capabilities (Section 11). |
| 2310 | ++ |
| 2311 | ++8.1.1.1 Request-URI |
| 2312 | ++ |
| 2313 | ++ The initial Request-URI of the message SHOULD be set to the value of |
| 2314 | ++ the URI in the To field. One notable exception is the REGISTER |
| 2315 | ++ method; behavior for setting the Request-URI of REGISTER is given in |
| 2316 | ++ Section 10. It may also be undesirable for privacy reasons or |
| 2317 | ++ convenience to set these fields to the same value (especially if the |
| 2318 | ++ originating UA expects that the Request-URI will be changed during |
| 2319 | ++ transit). |
| 2320 | ++ |
| 2321 | ++ In some special circumstances, the presence of a pre-existing route |
| 2322 | ++ set can affect the Request-URI of the message. A pre-existing route |
| 2323 | ++ set is an ordered set of URIs that identify a chain of servers, to |
| 2324 | ++ which a UAC will send outgoing requests that are outside of a dialog. |
| 2325 | ++ Commonly, they are configured on the UA by a user or service provider |
| 2326 | ++ manually, or through some other non-SIP mechanism. When a provider |
| 2327 | ++ wishes to configure a UA with an outbound proxy, it is RECOMMENDED |
| 2328 | ++ that this be done by providing it with a pre-existing route set with |
| 2329 | ++ a single URI, that of the outbound proxy. |
| 2330 | ++ |
| 2331 | ++ When a pre-existing route set is present, the procedures for |
| 2332 | ++ populating the Request-URI and Route header field detailed in Section |
| 2333 | ++ 12.2.1.1 MUST be followed (even though there is no dialog), using the |
| 2334 | ++ desired Request-URI as the remote target URI. |
| 2335 | ++ |
| 2336 | ++ |
| 2337 | ++ |
| 2338 | ++ |
| 2339 | ++ |
| 2340 | ++ |
| 2341 | ++Rosenberg, et. al. Standards Track [Page 35] |
| 2342 | ++ |
| 2343 | |
| 2344 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2345 | ++ |
| 2346 | ++ |
| 2347 | ++8.1.1.2 To |
| 2348 | ++ |
| 2349 | ++ The To header field first and foremost specifies the desired |
| 2350 | ++ "logical" recipient of the request, or the address-of-record of the |
| 2351 | ++ user or resource that is the target of this request. This may or may |
| 2352 | ++ not be the ultimate recipient of the request. The To header field |
| 2353 | ++ MAY contain a SIP or SIPS URI, but it may also make use of other URI |
| 2354 | ++ schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. |
| 2355 | ++ All SIP implementations MUST support the SIP URI scheme. Any |
| 2356 | ++ implementation that supports TLS MUST support the SIPS URI scheme. |
| 2357 | ++ The To header field allows for a display name. |
| 2358 | ++ |
| 2359 | ++ A UAC may learn how to populate the To header field for a particular |
| 2360 | ++ request in a number of ways. Usually the user will suggest the To |
| 2361 | ++ header field through a human interface, perhaps inputting the URI |
| 2362 | ++ manually or selecting it from some sort of address book. Frequently, |
| 2363 | ++ the user will not enter a complete URI, but rather a string of digits |
| 2364 | ++ or letters (for example, "bob"). It is at the discretion of the UA |
| 2365 | ++ to choose how to interpret this input. Using the string to form the |
| 2366 | ++ user part of a SIP URI implies that the UA wishes the name to be |
| 2367 | ++ resolved in the domain to the right-hand side (RHS) of the at-sign in |
| 2368 | ++ the SIP URI (for instance, sip:bob@example.com). Using the string to |
| 2369 | ++ form the user part of a SIPS URI implies that the UA wishes to |
| 2370 | ++ communicate securely, and that the name is to be resolved in the |
| 2371 | ++ domain to the RHS of the at-sign. The RHS will frequently be the |
| 2372 | ++ home domain of the requestor, which allows for the home domain to |
| 2373 | ++ process the outgoing request. This is useful for features like |
| 2374 | ++ "speed dial" that require interpretation of the user part in the home |
| 2375 | ++ domain. The tel URL may be used when the UA does not wish to specify |
| 2376 | ++ the domain that should interpret a telephone number that has been |
| 2377 | ++ input by the user. Rather, each domain through which the request |
| 2378 | ++ passes would be given that opportunity. As an example, a user in an |
| 2379 | ++ airport might log in and send requests through an outbound proxy in |
| 2380 | ++ the airport. If they enter "411" (this is the phone number for local |
| 2381 | ++ directory assistance in the United States), that needs to be |
| 2382 | ++ interpreted and processed by the outbound proxy in the airport, not |
| 2383 | ++ the user's home domain. In this case, tel:411 would be the right |
| 2384 | ++ choice. |
| 2385 | ++ |
| 2386 | ++ A request outside of a dialog MUST NOT contain a To tag; the tag in |
| 2387 | ++ the To field of a request identifies the peer of the dialog. Since |
| 2388 | ++ no dialog is established, no tag is present. |
| 2389 | ++ |
| 2390 | ++ For further information on the To header field, see Section 20.39. |
| 2391 | ++ The following is an example of a valid To header field: |
| 2392 | ++ |
| 2393 | ++ To: Carol <sip:carol@chicago.com> |
| 2394 | ++ |
| 2395 | ++ |
| 2396 | ++ |
| 2397 | ++ |
| 2398 | ++Rosenberg, et. al. Standards Track [Page 36] |
| 2399 | ++ |
| 2400 | |
| 2401 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2402 | ++ |
| 2403 | ++ |
| 2404 | ++8.1.1.3 From |
| 2405 | ++ |
| 2406 | ++ The From header field indicates the logical identity of the initiator |
| 2407 | ++ of the request, possibly the user's address-of-record. Like the To |
| 2408 | ++ header field, it contains a URI and optionally a display name. It is |
| 2409 | ++ used by SIP elements to determine which processing rules to apply to |
| 2410 | ++ a request (for example, automatic call rejection). As such, it is |
| 2411 | ++ very important that the From URI not contain IP addresses or the FQDN |
| 2412 | ++ of the host on which the UA is running, since these are not logical |
| 2413 | ++ names. |
| 2414 | ++ |
| 2415 | ++ The From header field allows for a display name. A UAC SHOULD use |
| 2416 | ++ the display name "Anonymous", along with a syntactically correct, but |
| 2417 | ++ otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the |
| 2418 | ++ identity of the client is to remain hidden. |
| 2419 | ++ |
| 2420 | ++ Usually, the value that populates the From header field in requests |
| 2421 | ++ generated by a particular UA is pre-provisioned by the user or by the |
| 2422 | ++ administrators of the user's local domain. If a particular UA is |
| 2423 | ++ used by multiple users, it might have switchable profiles that |
| 2424 | ++ include a URI corresponding to the identity of the profiled user. |
| 2425 | ++ Recipients of requests can authenticate the originator of a request |
| 2426 | ++ in order to ascertain that they are who their From header field |
| 2427 | ++ claims they are (see Section 22 for more on authentication). |
| 2428 | ++ |
| 2429 | ++ The From field MUST contain a new "tag" parameter, chosen by the UAC. |
| 2430 | ++ See Section 19.3 for details on choosing a tag. |
| 2431 | ++ |
| 2432 | ++ For further information on the From header field, see Section 20.20. |
| 2433 | ++ Examples: |
| 2434 | ++ |
| 2435 | ++ From: "Bob" <sips:bob@biloxi.com> ;tag=a48s |
| 2436 | ++ From: sip:+12125551212@phone2net.com;tag=887s |
| 2437 | ++ From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 |
| 2438 | ++ |
| 2439 | ++8.1.1.4 Call-ID |
| 2440 | ++ |
| 2441 | ++ The Call-ID header field acts as a unique identifier to group |
| 2442 | ++ together a series of messages. It MUST be the same for all requests |
| 2443 | ++ and responses sent by either UA in a dialog. It SHOULD be the same |
| 2444 | ++ in each registration from a UA. |
| 2445 | ++ |
| 2446 | ++ In a new request created by a UAC outside of any dialog, the Call-ID |
| 2447 | ++ header field MUST be selected by the UAC as a globally unique |
| 2448 | ++ identifier over space and time unless overridden by method-specific |
| 2449 | ++ behavior. All SIP UAs must have a means to guarantee that the Call- |
| 2450 | ++ ID header fields they produce will not be inadvertently generated by |
| 2451 | ++ any other UA. Note that when requests are retried after certain |
| 2452 | ++ |
| 2453 | ++ |
| 2454 | ++ |
| 2455 | ++Rosenberg, et. al. Standards Track [Page 37] |
| 2456 | ++ |
| 2457 | |
| 2458 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2459 | ++ |
| 2460 | ++ |
| 2461 | ++ failure responses that solicit an amendment to a request (for |
| 2462 | ++ example, a challenge for authentication), these retried requests are |
| 2463 | ++ not considered new requests, and therefore do not need new Call-ID |
| 2464 | ++ header fields; see Section 8.1.3.5. |
| 2465 | ++ |
| 2466 | ++ Use of cryptographically random identifiers (RFC 1750 [12]) in the |
| 2467 | ++ generation of Call-IDs is RECOMMENDED. Implementations MAY use the |
| 2468 | ++ form "localid@host". Call-IDs are case-sensitive and are simply |
| 2469 | ++ compared byte-by-byte. |
| 2470 | ++ |
| 2471 | ++ Using cryptographically random identifiers provides some |
| 2472 | ++ protection against session hijacking and reduces the likelihood of |
| 2473 | ++ unintentional Call-ID collisions. |
| 2474 | ++ |
| 2475 | ++ No provisioning or human interface is required for the selection of |
| 2476 | ++ the Call-ID header field value for a request. |
| 2477 | ++ |
| 2478 | ++ For further information on the Call-ID header field, see Section |
| 2479 | ++ 20.8. |
| 2480 | ++ |
| 2481 | ++ Example: |
| 2482 | ++ |
| 2483 | ++ Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com |
| 2484 | ++ |
| 2485 | ++8.1.1.5 CSeq |
| 2486 | ++ |
| 2487 | ++ The CSeq header field serves as a way to identify and order |
| 2488 | ++ transactions. It consists of a sequence number and a method. The |
| 2489 | ++ method MUST match that of the request. For non-REGISTER requests |
| 2490 | ++ outside of a dialog, the sequence number value is arbitrary. The |
| 2491 | ++ sequence number value MUST be expressible as a 32-bit unsigned |
| 2492 | ++ integer and MUST be less than 2**31. As long as it follows the above |
| 2493 | ++ guidelines, a client may use any mechanism it would like to select |
| 2494 | ++ CSeq header field values. |
| 2495 | ++ |
| 2496 | ++ Section 12.2.1.1 discusses construction of the CSeq for requests |
| 2497 | ++ within a dialog. |
| 2498 | ++ |
| 2499 | ++ Example: |
| 2500 | ++ |
| 2501 | ++ CSeq: 4711 INVITE |
| 2502 | ++ |
| 2503 | ++ |
| 2504 | ++ |
| 2505 | ++ |
| 2506 | ++ |
| 2507 | ++ |
| 2508 | ++ |
| 2509 | ++ |
| 2510 | ++ |
| 2511 | ++ |
| 2512 | ++Rosenberg, et. al. Standards Track [Page 38] |
| 2513 | ++ |
| 2514 | |
| 2515 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2516 | ++ |
| 2517 | ++ |
| 2518 | ++8.1.1.6 Max-Forwards |
| 2519 | ++ |
| 2520 | ++ The Max-Forwards header field serves to limit the number of hops a |
| 2521 | ++ request can transit on the way to its destination. It consists of an |
| 2522 | ++ integer that is decremented by one at each hop. If the Max-Forwards |
| 2523 | ++ value reaches 0 before the request reaches its destination, it will |
| 2524 | ++ be rejected with a 483(Too Many Hops) error response. |
| 2525 | ++ |
| 2526 | ++ A UAC MUST insert a Max-Forwards header field into each request it |
| 2527 | ++ originates with a value that SHOULD be 70. This number was chosen to |
| 2528 | ++ be sufficiently large to guarantee that a request would not be |
| 2529 | ++ dropped in any SIP network when there were no loops, but not so large |
| 2530 | ++ as to consume proxy resources when a loop does occur. Lower values |
| 2531 | ++ should be used with caution and only in networks where topologies are |
| 2532 | ++ known by the UA. |
| 2533 | ++ |
| 2534 | ++8.1.1.7 Via |
| 2535 | ++ |
| 2536 | ++ The Via header field indicates the transport used for the transaction |
| 2537 | ++ and identifies the location where the response is to be sent. A Via |
| 2538 | ++ header field value is added only after the transport that will be |
| 2539 | ++ used to reach the next hop has been selected (which may involve the |
| 2540 | ++ usage of the procedures in [4]). |
| 2541 | ++ |
| 2542 | ++ When the UAC creates a request, it MUST insert a Via into that |
| 2543 | ++ request. The protocol name and protocol version in the header field |
| 2544 | ++ MUST be SIP and 2.0, respectively. The Via header field value MUST |
| 2545 | ++ contain a branch parameter. This parameter is used to identify the |
| 2546 | ++ transaction created by that request. This parameter is used by both |
| 2547 | ++ the client and the server. |
| 2548 | ++ |
| 2549 | ++ The branch parameter value MUST be unique across space and time for |
| 2550 | ++ all requests sent by the UA. The exceptions to this rule are CANCEL |
| 2551 | ++ and ACK for non-2xx responses. As discussed below, a CANCEL request |
| 2552 | ++ will have the same value of the branch parameter as the request it |
| 2553 | ++ cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx |
| 2554 | ++ response will also have the same branch ID as the INVITE whose |
| 2555 | ++ response it acknowledges. |
| 2556 | ++ |
| 2557 | ++ The uniqueness property of the branch ID parameter, to facilitate |
| 2558 | ++ its use as a transaction ID, was not part of RFC 2543. |
| 2559 | ++ |
| 2560 | ++ The branch ID inserted by an element compliant with this |
| 2561 | ++ specification MUST always begin with the characters "z9hG4bK". These |
| 2562 | ++ 7 characters are used as a magic cookie (7 is deemed sufficient to |
| 2563 | ++ ensure that an older RFC 2543 implementation would not pick such a |
| 2564 | ++ value), so that servers receiving the request can determine that the |
| 2565 | ++ branch ID was constructed in the fashion described by this |
| 2566 | ++ |
| 2567 | ++ |
| 2568 | ++ |
| 2569 | ++Rosenberg, et. al. Standards Track [Page 39] |
| 2570 | ++ |
| 2571 | |
| 2572 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2573 | ++ |
| 2574 | ++ |
| 2575 | ++ specification (that is, globally unique). Beyond this requirement, |
| 2576 | ++ the precise format of the branch token is implementation-defined. |
| 2577 | ++ |
| 2578 | ++ The Via header maddr, ttl, and sent-by components will be set when |
| 2579 | ++ the request is processed by the transport layer (Section 18). |
| 2580 | ++ |
| 2581 | ++ Via processing for proxies is described in Section 16.6 Item 8 and |
| 2582 | ++ Section 16.7 Item 3. |
| 2583 | ++ |
| 2584 | ++8.1.1.8 Contact |
| 2585 | ++ |
| 2586 | ++ The Contact header field provides a SIP or SIPS URI that can be used |
| 2587 | ++ to contact that specific instance of the UA for subsequent requests. |
| 2588 | ++ The Contact header field MUST be present and contain exactly one SIP |
| 2589 | ++ or SIPS URI in any request that can result in the establishment of a |
| 2590 | ++ dialog. For the methods defined in this specification, that includes |
| 2591 | ++ only the INVITE request. For these requests, the scope of the |
| 2592 | ++ Contact is global. That is, the Contact header field value contains |
| 2593 | ++ the URI at which the UA would like to receive requests, and this URI |
| 2594 | ++ MUST be valid even if used in subsequent requests outside of any |
| 2595 | ++ dialogs. |
| 2596 | ++ |
| 2597 | ++ If the Request-URI or top Route header field value contains a SIPS |
| 2598 | ++ URI, the Contact header field MUST contain a SIPS URI as well. |
| 2599 | ++ |
| 2600 | ++ For further information on the Contact header field, see Section |
| 2601 | ++ 20.10. |
| 2602 | ++ |
| 2603 | ++8.1.1.9 Supported and Require |
| 2604 | ++ |
| 2605 | ++ If the UAC supports extensions to SIP that can be applied by the |
| 2606 | ++ server to the response, the UAC SHOULD include a Supported header |
| 2607 | ++ field in the request listing the option tags (Section 19.2) for those |
| 2608 | ++ extensions. |
| 2609 | ++ |
| 2610 | ++ The option tags listed MUST only refer to extensions defined in |
| 2611 | ++ standards-track RFCs. This is to prevent servers from insisting that |
| 2612 | ++ clients implement non-standard, vendor-defined features in order to |
| 2613 | ++ receive service. Extensions defined by experimental and |
| 2614 | ++ informational RFCs are explicitly excluded from usage with the |
| 2615 | ++ Supported header field in a request, since they too are often used to |
| 2616 | ++ document vendor-defined extensions. |
| 2617 | ++ |
| 2618 | ++ If the UAC wishes to insist that a UAS understand an extension that |
| 2619 | ++ the UAC will apply to the request in order to process the request, it |
| 2620 | ++ MUST insert a Require header field into the request listing the |
| 2621 | ++ option tag for that extension. If the UAC wishes to apply an |
| 2622 | ++ extension to the request and insist that any proxies that are |
| 2623 | ++ |
| 2624 | ++ |
| 2625 | ++ |
| 2626 | ++Rosenberg, et. al. Standards Track [Page 40] |
| 2627 | ++ |
| 2628 | |
| 2629 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2630 | ++ |
| 2631 | ++ |
| 2632 | ++ traversed understand that extension, it MUST insert a Proxy-Require |
| 2633 | ++ header field into the request listing the option tag for that |
| 2634 | ++ extension. |
| 2635 | ++ |
| 2636 | ++ As with the Supported header field, the option tags in the Require |
| 2637 | ++ and Proxy-Require header fields MUST only refer to extensions defined |
| 2638 | ++ in standards-track RFCs. |
| 2639 | ++ |
| 2640 | ++8.1.1.10 Additional Message Components |
| 2641 | ++ |
| 2642 | ++ After a new request has been created, and the header fields described |
| 2643 | ++ above have been properly constructed, any additional optional header |
| 2644 | ++ fields are added, as are any header fields specific to the method. |
| 2645 | ++ |
| 2646 | ++ SIP requests MAY contain a MIME-encoded message-body. Regardless of |
| 2647 | ++ the type of body that a request contains, certain header fields must |
| 2648 | ++ be formulated to characterize the contents of the body. For further |
| 2649 | ++ information on these header fields, see Sections 20.11 through 20.15. |
| 2650 | ++ |
| 2651 | ++8.1.2 Sending the Request |
| 2652 | ++ |
| 2653 | ++ The destination for the request is then computed. Unless there is |
| 2654 | ++ local policy specifying otherwise, the destination MUST be determined |
| 2655 | ++ by applying the DNS procedures described in [4] as follows. If the |
| 2656 | ++ first element in the route set indicated a strict router (resulting |
| 2657 | ++ in forming the request as described in Section 12.2.1.1), the |
| 2658 | ++ procedures MUST be applied to the Request-URI of the request. |
| 2659 | ++ Otherwise, the procedures are applied to the first Route header field |
| 2660 | ++ value in the request (if one exists), or to the request's Request-URI |
| 2661 | ++ if there is no Route header field present. These procedures yield an |
| 2662 | ++ ordered set of address, port, and transports to attempt. Independent |
| 2663 | ++ of which URI is used as input to the procedures of [4], if the |
| 2664 | ++ Request-URI specifies a SIPS resource, the UAC MUST follow the |
| 2665 | ++ procedures of [4] as if the input URI were a SIPS URI. |
| 2666 | ++ |
| 2667 | ++ Local policy MAY specify an alternate set of destinations to attempt. |
| 2668 | ++ If the Request-URI contains a SIPS URI, any alternate destinations |
| 2669 | ++ MUST be contacted with TLS. Beyond that, there are no restrictions |
| 2670 | ++ on the alternate destinations if the request contains no Route header |
| 2671 | ++ field. This provides a simple alternative to a pre-existing route |
| 2672 | ++ set as a way to specify an outbound proxy. However, that approach |
| 2673 | ++ for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing |
| 2674 | ++ route set with a single URI SHOULD be used instead. If the request |
| 2675 | ++ contains a Route header field, the request SHOULD be sent to the |
| 2676 | ++ locations derived from its topmost value, but MAY be sent to any |
| 2677 | ++ server that the UA is certain will honor the Route and Request-URI |
| 2678 | ++ policies specified in this document (as opposed to those in RFC |
| 2679 | ++ 2543). In particular, a UAC configured with an outbound proxy SHOULD |
| 2680 | ++ |
| 2681 | ++ |
| 2682 | ++ |
| 2683 | ++Rosenberg, et. al. Standards Track [Page 41] |
| 2684 | ++ |
| 2685 | |
| 2686 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2687 | ++ |
| 2688 | ++ |
| 2689 | ++ attempt to send the request to the location indicated in the first |
| 2690 | ++ Route header field value instead of adopting the policy of sending |
| 2691 | ++ all messages to the outbound proxy. |
| 2692 | ++ |
| 2693 | ++ This ensures that outbound proxies that do not add Record-Route |
| 2694 | ++ header field values will drop out of the path of subsequent |
| 2695 | ++ requests. It allows endpoints that cannot resolve the first Route |
| 2696 | ++ URI to delegate that task to an outbound proxy. |
| 2697 | ++ |
| 2698 | ++ The UAC SHOULD follow the procedures defined in [4] for stateful |
| 2699 | ++ elements, trying each address until a server is contacted. Each try |
| 2700 | ++ constitutes a new transaction, and therefore each carries a different |
| 2701 | ++ topmost Via header field value with a new branch parameter. |
| 2702 | ++ Furthermore, the transport value in the Via header field is set to |
| 2703 | ++ whatever transport was determined for the target server. |
| 2704 | ++ |
| 2705 | ++8.1.3 Processing Responses |
| 2706 | ++ |
| 2707 | ++ Responses are first processed by the transport layer and then passed |
| 2708 | ++ up to the transaction layer. The transaction layer performs its |
| 2709 | ++ processing and then passes the response up to the TU. The majority |
| 2710 | ++ of response processing in the TU is method specific. However, there |
| 2711 | ++ are some general behaviors independent of the method. |
| 2712 | ++ |
| 2713 | ++8.1.3.1 Transaction Layer Errors |
| 2714 | ++ |
| 2715 | ++ In some cases, the response returned by the transaction layer will |
| 2716 | ++ not be a SIP message, but rather a transaction layer error. When a |
| 2717 | ++ timeout error is received from the transaction layer, it MUST be |
| 2718 | ++ treated as if a 408 (Request Timeout) status code has been received. |
| 2719 | ++ If a fatal transport error is reported by the transport layer |
| 2720 | ++ (generally, due to fatal ICMP errors in UDP or connection failures in |
| 2721 | ++ TCP), the condition MUST be treated as a 503 (Service Unavailable) |
| 2722 | ++ status code. |
| 2723 | ++ |
| 2724 | ++8.1.3.2 Unrecognized Responses |
| 2725 | ++ |
| 2726 | ++ A UAC MUST treat any final response it does not recognize as being |
| 2727 | ++ equivalent to the x00 response code of that class, and MUST be able |
| 2728 | ++ to process the x00 response code for all classes. For example, if a |
| 2729 | ++ UAC receives an unrecognized response code of 431, it can safely |
| 2730 | ++ assume that there was something wrong with its request and treat the |
| 2731 | ++ response as if it had received a 400 (Bad Request) response code. A |
| 2732 | ++ UAC MUST treat any provisional response different than 100 that it |
| 2733 | ++ does not recognize as 183 (Session Progress). A UAC MUST be able to |
| 2734 | ++ process 100 and 183 responses. |
| 2735 | ++ |
| 2736 | ++ |
| 2737 | ++ |
| 2738 | ++ |
| 2739 | ++ |
| 2740 | ++Rosenberg, et. al. Standards Track [Page 42] |
| 2741 | ++ |
| 2742 | |
| 2743 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2744 | ++ |
| 2745 | ++ |
| 2746 | ++8.1.3.3 Vias |
| 2747 | ++ |
| 2748 | ++ If more than one Via header field value is present in a response, the |
| 2749 | ++ UAC SHOULD discard the message. |
| 2750 | ++ |
| 2751 | ++ The presence of additional Via header field values that precede |
| 2752 | ++ the originator of the request suggests that the message was |
| 2753 | ++ misrouted or possibly corrupted. |
| 2754 | ++ |
| 2755 | ++8.1.3.4 Processing 3xx Responses |
| 2756 | ++ |
| 2757 | ++ Upon receipt of a redirection response (for example, a 301 response |
| 2758 | ++ status code), clients SHOULD use the URI(s) in the Contact header |
| 2759 | ++ field to formulate one or more new requests based on the redirected |
| 2760 | ++ request. This process is similar to that of a proxy recursing on a |
| 2761 | ++ 3xx class response as detailed in Sections 16.5 and 16.6. A client |
| 2762 | ++ starts with an initial target set containing exactly one URI, the |
| 2763 | ++ Request-URI of the original request. If a client wishes to formulate |
| 2764 | ++ new requests based on a 3xx class response to that request, it places |
| 2765 | ++ the URIs to try into the target set. Subject to the restrictions in |
| 2766 | ++ this specification, a client can choose which Contact URIs it places |
| 2767 | ++ into the target set. As with proxy recursion, a client processing |
| 2768 | ++ 3xx class responses MUST NOT add any given URI to the target set more |
| 2769 | ++ than once. If the original request had a SIPS URI in the Request- |
| 2770 | ++ URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD |
| 2771 | ++ inform the user of the redirection to an insecure URI. |
| 2772 | ++ |
| 2773 | ++ Any new request may receive 3xx responses themselves containing |
| 2774 | ++ the original URI as a contact. Two locations can be configured to |
| 2775 | ++ redirect to each other. Placing any given URI in the target set |
| 2776 | ++ only once prevents infinite redirection loops. |
| 2777 | ++ |
| 2778 | ++ As the target set grows, the client MAY generate new requests to the |
| 2779 | ++ URIs in any order. A common mechanism is to order the set by the "q" |
| 2780 | ++ parameter value from the Contact header field value. Requests to the |
| 2781 | ++ URIs MAY be generated serially or in parallel. One approach is to |
| 2782 | ++ process groups of decreasing q-values serially and process the URIs |
| 2783 | ++ in each q-value group in parallel. Another is to perform only serial |
| 2784 | ++ processing in decreasing q-value order, arbitrarily choosing between |
| 2785 | ++ contacts of equal q-value. |
| 2786 | ++ |
| 2787 | ++ If contacting an address in the list results in a failure, as defined |
| 2788 | ++ in the next paragraph, the element moves to the next address in the |
| 2789 | ++ list, until the list is exhausted. If the list is exhausted, then |
| 2790 | ++ the request has failed. |
| 2791 | ++ |
| 2792 | ++ |
| 2793 | ++ |
| 2794 | ++ |
| 2795 | ++ |
| 2796 | ++ |
| 2797 | ++Rosenberg, et. al. Standards Track [Page 43] |
| 2798 | ++ |
| 2799 | |
| 2800 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2801 | ++ |
| 2802 | ++ |
| 2803 | ++ Failures SHOULD be detected through failure response codes (codes |
| 2804 | ++ greater than 399); for network errors the client transaction will |
| 2805 | ++ report any transport layer failures to the transaction user. Note |
| 2806 | ++ that some response codes (detailed in 8.1.3.5) indicate that the |
| 2807 | ++ request can be retried; requests that are reattempted should not be |
| 2808 | ++ considered failures. |
| 2809 | ++ |
| 2810 | ++ When a failure for a particular contact address is received, the |
| 2811 | ++ client SHOULD try the next contact address. This will involve |
| 2812 | ++ creating a new client transaction to deliver a new request. |
| 2813 | ++ |
| 2814 | ++ In order to create a request based on a contact address in a 3xx |
| 2815 | ++ response, a UAC MUST copy the entire URI from the target set into the |
| 2816 | ++ Request-URI, except for the "method-param" and "header" URI |
| 2817 | ++ parameters (see Section 19.1.1 for a definition of these parameters). |
| 2818 | ++ It uses the "header" parameters to create header field values for the |
| 2819 | ++ new request, overwriting header field values associated with the |
| 2820 | ++ redirected request in accordance with the guidelines in Section |
| 2821 | ++ 19.1.5. |
| 2822 | ++ |
| 2823 | ++ Note that in some instances, header fields that have been |
| 2824 | ++ communicated in the contact address may instead append to existing |
| 2825 | ++ request header fields in the original redirected request. As a |
| 2826 | ++ general rule, if the header field can accept a comma-separated list |
| 2827 | ++ of values, then the new header field value MAY be appended to any |
| 2828 | ++ existing values in the original redirected request. If the header |
| 2829 | ++ field does not accept multiple values, the value in the original |
| 2830 | ++ redirected request MAY be overwritten by the header field value |
| 2831 | ++ communicated in the contact address. For example, if a contact |
| 2832 | ++ address is returned with the following value: |
| 2833 | ++ |
| 2834 | ++ sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> |
| 2835 | ++ |
| 2836 | ++ Then any Subject header field in the original redirected request is |
| 2837 | ++ overwritten, but the HTTP URL is merely appended to any existing |
| 2838 | ++ Call-Info header field values. |
| 2839 | ++ |
| 2840 | ++ It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID |
| 2841 | ++ used in the original redirected request, but the UAC MAY also choose |
| 2842 | ++ to update the Call-ID header field value for new requests, for |
| 2843 | ++ example. |
| 2844 | ++ |
| 2845 | ++ Finally, once the new request has been constructed, it is sent using |
| 2846 | ++ a new client transaction, and therefore MUST have a new branch ID in |
| 2847 | ++ the top Via field as discussed in Section 8.1.1.7. |
| 2848 | ++ |
| 2849 | ++ |
| 2850 | ++ |
| 2851 | ++ |
| 2852 | ++ |
| 2853 | ++ |
| 2854 | ++Rosenberg, et. al. Standards Track [Page 44] |
| 2855 | ++ |
| 2856 | |
| 2857 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2858 | ++ |
| 2859 | ++ |
| 2860 | ++ In all other respects, requests sent upon receipt of a redirect |
| 2861 | ++ response SHOULD re-use the header fields and bodies of the original |
| 2862 | ++ request. |
| 2863 | ++ |
| 2864 | ++ In some instances, Contact header field values may be cached at UAC |
| 2865 | ++ temporarily or permanently depending on the status code received and |
| 2866 | ++ the presence of an expiration interval; see Sections 21.3.2 and |
| 2867 | ++ 21.3.3. |
| 2868 | ++ |
| 2869 | ++8.1.3.5 Processing 4xx Responses |
| 2870 | ++ |
| 2871 | ++ Certain 4xx response codes require specific UA processing, |
| 2872 | ++ independent of the method. |
| 2873 | ++ |
| 2874 | ++ If a 401 (Unauthorized) or 407 (Proxy Authentication Required) |
| 2875 | ++ response is received, the UAC SHOULD follow the authorization |
| 2876 | ++ procedures of Section 22.2 and Section 22.3 to retry the request with |
| 2877 | ++ credentials. |
| 2878 | ++ |
| 2879 | ++ If a 413 (Request Entity Too Large) response is received (Section |
| 2880 | ++ 21.4.11), the request contained a body that was longer than the UAS |
| 2881 | ++ was willing to accept. If possible, the UAC SHOULD retry the |
| 2882 | ++ request, either omitting the body or using one of a smaller length. |
| 2883 | ++ |
| 2884 | ++ If a 415 (Unsupported Media Type) response is received (Section |
| 2885 | ++ 21.4.13), the request contained media types not supported by the UAS. |
| 2886 | ++ The UAC SHOULD retry sending the request, this time only using |
| 2887 | ++ content with types listed in the Accept header field in the response, |
| 2888 | ++ with encodings listed in the Accept-Encoding header field in the |
| 2889 | ++ response, and with languages listed in the Accept-Language in the |
| 2890 | ++ response. |
| 2891 | ++ |
| 2892 | ++ If a 416 (Unsupported URI Scheme) response is received (Section |
| 2893 | ++ 21.4.14), the Request-URI used a URI scheme not supported by the |
| 2894 | ++ server. The client SHOULD retry the request, this time, using a SIP |
| 2895 | ++ URI. |
| 2896 | ++ |
| 2897 | ++ If a 420 (Bad Extension) response is received (Section 21.4.15), the |
| 2898 | ++ request contained a Require or Proxy-Require header field listing an |
| 2899 | ++ option-tag for a feature not supported by a proxy or UAS. The UAC |
| 2900 | ++ SHOULD retry the request, this time omitting any extensions listed in |
| 2901 | ++ the Unsupported header field in the response. |
| 2902 | ++ |
| 2903 | ++ In all of the above cases, the request is retried by creating a new |
| 2904 | ++ request with the appropriate modifications. This new request |
| 2905 | ++ constitutes a new transaction and SHOULD have the same value of the |
| 2906 | ++ Call-ID, To, and From of the previous request, but the CSeq should |
| 2907 | ++ contain a new sequence number that is one higher than the previous. |
| 2908 | ++ |
| 2909 | ++ |
| 2910 | ++ |
| 2911 | ++Rosenberg, et. al. Standards Track [Page 45] |
| 2912 | ++ |
| 2913 | |
| 2914 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2915 | ++ |
| 2916 | ++ |
| 2917 | ++ With other 4xx responses, including those yet to be defined, a retry |
| 2918 | ++ may or may not be possible depending on the method and the use case. |
| 2919 | ++ |
| 2920 | ++8.2 UAS Behavior |
| 2921 | ++ |
| 2922 | ++ When a request outside of a dialog is processed by a UAS, there is a |
| 2923 | ++ set of processing rules that are followed, independent of the method. |
| 2924 | ++ Section 12 gives guidance on how a UAS can tell whether a request is |
| 2925 | ++ inside or outside of a dialog. |
| 2926 | ++ |
| 2927 | ++ Note that request processing is atomic. If a request is accepted, |
| 2928 | ++ all state changes associated with it MUST be performed. If it is |
| 2929 | ++ rejected, all state changes MUST NOT be performed. |
| 2930 | ++ |
| 2931 | ++ UASs SHOULD process the requests in the order of the steps that |
| 2932 | ++ follow in this section (that is, starting with authentication, then |
| 2933 | ++ inspecting the method, the header fields, and so on throughout the |
| 2934 | ++ remainder of this section). |
| 2935 | ++ |
| 2936 | ++8.2.1 Method Inspection |
| 2937 | ++ |
| 2938 | ++ Once a request is authenticated (or authentication is skipped), the |
| 2939 | ++ UAS MUST inspect the method of the request. If the UAS recognizes |
| 2940 | ++ but does not support the method of a request, it MUST generate a 405 |
| 2941 | ++ (Method Not Allowed) response. Procedures for generating responses |
| 2942 | ++ are described in Section 8.2.6. The UAS MUST also add an Allow |
| 2943 | ++ header field to the 405 (Method Not Allowed) response. The Allow |
| 2944 | ++ header field MUST list the set of methods supported by the UAS |
| 2945 | ++ generating the message. The Allow header field is presented in |
| 2946 | ++ Section 20.5. |
| 2947 | ++ |
| 2948 | ++ If the method is one supported by the server, processing continues. |
| 2949 | ++ |
| 2950 | ++8.2.2 Header Inspection |
| 2951 | ++ |
| 2952 | ++ If a UAS does not understand a header field in a request (that is, |
| 2953 | ++ the header field is not defined in this specification or in any |
| 2954 | ++ supported extension), the server MUST ignore that header field and |
| 2955 | ++ continue processing the message. A UAS SHOULD ignore any malformed |
| 2956 | ++ header fields that are not necessary for processing requests. |
| 2957 | ++ |
| 2958 | ++8.2.2.1 To and Request-URI |
| 2959 | ++ |
| 2960 | ++ The To header field identifies the original recipient of the request |
| 2961 | ++ designated by the user identified in the From field. The original |
| 2962 | ++ recipient may or may not be the UAS processing the request, due to |
| 2963 | ++ call forwarding or other proxy operations. A UAS MAY apply any |
| 2964 | ++ policy it wishes to determine whether to accept requests when the To |
| 2965 | ++ |
| 2966 | ++ |
| 2967 | ++ |
| 2968 | ++Rosenberg, et. al. Standards Track [Page 46] |
| 2969 | ++ |
| 2970 | |
| 2971 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 2972 | ++ |
| 2973 | ++ |
| 2974 | ++ header field is not the identity of the UAS. However, it is |
| 2975 | ++ RECOMMENDED that a UAS accept requests even if they do not recognize |
| 2976 | ++ the URI scheme (for example, a tel: URI) in the To header field, or |
| 2977 | ++ if the To header field does not address a known or current user of |
| 2978 | ++ this UAS. If, on the other hand, the UAS decides to reject the |
| 2979 | ++ request, it SHOULD generate a response with a 403 (Forbidden) status |
| 2980 | ++ code and pass it to the server transaction for transmission. |
| 2981 | ++ |
| 2982 | ++ However, the Request-URI identifies the UAS that is to process the |
| 2983 | ++ request. If the Request-URI uses a scheme not supported by the UAS, |
| 2984 | ++ it SHOULD reject the request with a 416 (Unsupported URI Scheme) |
| 2985 | ++ response. If the Request-URI does not identify an address that the |
| 2986 | ++ UAS is willing to accept requests for, it SHOULD reject the request |
| 2987 | ++ with a 404 (Not Found) response. Typically, a UA that uses the |
| 2988 | ++ REGISTER method to bind its address-of-record to a specific contact |
| 2989 | ++ address will see requests whose Request-URI equals that contact |
| 2990 | ++ address. Other potential sources of received Request-URIs include |
| 2991 | ++ the Contact header fields of requests and responses sent by the UA |
| 2992 | ++ that establish or refresh dialogs. |
| 2993 | ++ |
| 2994 | ++8.2.2.2 Merged Requests |
| 2995 | ++ |
| 2996 | ++ If the request has no tag in the To header field, the UAS core MUST |
| 2997 | ++ check the request against ongoing transactions. If the From tag, |
| 2998 | ++ Call-ID, and CSeq exactly match those associated with an ongoing |
| 2999 | ++ transaction, but the request does not match that transaction (based |
| 3000 | ++ on the matching rules in Section 17.2.3), the UAS core SHOULD |
| 3001 | ++ generate a 482 (Loop Detected) response and pass it to the server |
| 3002 | ++ transaction. |
| 3003 | ++ |
| 3004 | ++ The same request has arrived at the UAS more than once, following |
| 3005 | ++ different paths, most likely due to forking. The UAS processes |
| 3006 | ++ the first such request received and responds with a 482 (Loop |
| 3007 | ++ Detected) to the rest of them. |
| 3008 | ++ |
| 3009 | ++8.2.2.3 Require |
| 3010 | ++ |
| 3011 | ++ Assuming the UAS decides that it is the proper element to process the |
| 3012 | ++ request, it examines the Require header field, if present. |
| 3013 | ++ |
| 3014 | ++ The Require header field is used by a UAC to tell a UAS about SIP |
| 3015 | ++ extensions that the UAC expects the UAS to support in order to |
| 3016 | ++ process the request properly. Its format is described in Section |
| 3017 | ++ 20.32. If a UAS does not understand an option-tag listed in a |
| 3018 | ++ Require header field, it MUST respond by generating a response with |
| 3019 | ++ status code 420 (Bad Extension). The UAS MUST add an Unsupported |
| 3020 | ++ header field, and list in it those options it does not understand |
| 3021 | ++ amongst those in the Require header field of the request. |
| 3022 | ++ |
| 3023 | ++ |
| 3024 | ++ |
| 3025 | ++Rosenberg, et. al. Standards Track [Page 47] |
| 3026 | ++ |
| 3027 | |
| 3028 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3029 | ++ |
| 3030 | ++ |
| 3031 | ++ Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL |
| 3032 | ++ request, or in an ACK request sent for a non-2xx response. These |
| 3033 | ++ header fields MUST be ignored if they are present in these requests. |
| 3034 | ++ |
| 3035 | ++ An ACK request for a 2xx response MUST contain only those Require and |
| 3036 | ++ Proxy-Require values that were present in the initial request. |
| 3037 | ++ |
| 3038 | ++ Example: |
| 3039 | ++ |
| 3040 | ++ UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 |
| 3041 | ++ Require: 100rel |
| 3042 | ++ |
| 3043 | ++ UAS->UAC: SIP/2.0 420 Bad Extension |
| 3044 | ++ Unsupported: 100rel |
| 3045 | ++ |
| 3046 | ++ This behavior ensures that the client-server interaction will |
| 3047 | ++ proceed without delay when all options are understood by both |
| 3048 | ++ sides, and only slow down if options are not understood (as in the |
| 3049 | ++ example above). For a well-matched client-server pair, the |
| 3050 | ++ interaction proceeds quickly, saving a round-trip often required |
| 3051 | ++ by negotiation mechanisms. In addition, it also removes ambiguity |
| 3052 | ++ when the client requires features that the server does not |
| 3053 | ++ understand. Some features, such as call handling fields, are only |
| 3054 | ++ of interest to end systems. |
| 3055 | ++ |
| 3056 | ++8.2.3 Content Processing |
| 3057 | ++ |
| 3058 | ++ Assuming the UAS understands any extensions required by the client, |
| 3059 | ++ the UAS examines the body of the message, and the header fields that |
| 3060 | ++ describe it. If there are any bodies whose type (indicated by the |
| 3061 | ++ Content-Type), language (indicated by the Content-Language) or |
| 3062 | ++ encoding (indicated by the Content-Encoding) are not understood, and |
| 3063 | ++ that body part is not optional (as indicated by the Content- |
| 3064 | ++ Disposition header field), the UAS MUST reject the request with a 415 |
| 3065 | ++ (Unsupported Media Type) response. The response MUST contain an |
| 3066 | ++ Accept header field listing the types of all bodies it understands, |
| 3067 | ++ in the event the request contained bodies of types not supported by |
| 3068 | ++ the UAS. If the request contained content encodings not understood |
| 3069 | ++ by the UAS, the response MUST contain an Accept-Encoding header field |
| 3070 | ++ listing the encodings understood by the UAS. If the request |
| 3071 | ++ contained content with languages not understood by the UAS, the |
| 3072 | ++ response MUST contain an Accept-Language header field indicating the |
| 3073 | ++ languages understood by the UAS. Beyond these checks, body handling |
| 3074 | ++ depends on the method and type. For further information on the |
| 3075 | ++ processing of content-specific header fields, see Section 7.4 as well |
| 3076 | ++ as Section 20.11 through 20.15. |
| 3077 | ++ |
| 3078 | ++ |
| 3079 | ++ |
| 3080 | ++ |
| 3081 | ++ |
| 3082 | ++Rosenberg, et. al. Standards Track [Page 48] |
| 3083 | ++ |
| 3084 | |
| 3085 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3086 | ++ |
| 3087 | ++ |
| 3088 | ++8.2.4 Applying Extensions |
| 3089 | ++ |
| 3090 | ++ A UAS that wishes to apply some extension when generating the |
| 3091 | ++ response MUST NOT do so unless support for that extension is |
| 3092 | ++ indicated in the Supported header field in the request. If the |
| 3093 | ++ desired extension is not supported, the server SHOULD rely only on |
| 3094 | ++ baseline SIP and any other extensions supported by the client. In |
| 3095 | ++ rare circumstances, where the server cannot process the request |
| 3096 | ++ without the extension, the server MAY send a 421 (Extension Required) |
| 3097 | ++ response. This response indicates that the proper response cannot be |
| 3098 | ++ generated without support of a specific extension. The needed |
| 3099 | ++ extension(s) MUST be included in a Require header field in the |
| 3100 | ++ response. This behavior is NOT RECOMMENDED, as it will generally |
| 3101 | ++ break interoperability. |
| 3102 | ++ |
| 3103 | ++ Any extensions applied to a non-421 response MUST be listed in a |
| 3104 | ++ Require header field included in the response. Of course, the server |
| 3105 | ++ MUST NOT apply extensions not listed in the Supported header field in |
| 3106 | ++ the request. As a result of this, the Require header field in a |
| 3107 | ++ response will only ever contain option tags defined in standards- |
| 3108 | ++ track RFCs. |
| 3109 | ++ |
| 3110 | ++8.2.5 Processing the Request |
| 3111 | ++ |
| 3112 | ++ Assuming all of the checks in the previous subsections are passed, |
| 3113 | ++ the UAS processing becomes method-specific. Section 10 covers the |
| 3114 | ++ REGISTER request, Section 11 covers the OPTIONS request, Section 13 |
| 3115 | ++ covers the INVITE request, and Section 15 covers the BYE request. |
| 3116 | ++ |
| 3117 | ++8.2.6 Generating the Response |
| 3118 | ++ |
| 3119 | ++ When a UAS wishes to construct a response to a request, it follows |
| 3120 | ++ the general procedures detailed in the following subsections. |
| 3121 | ++ Additional behaviors specific to the response code in question, which |
| 3122 | ++ are not detailed in this section, may also be required. |
| 3123 | ++ |
| 3124 | ++ Once all procedures associated with the creation of a response have |
| 3125 | ++ been completed, the UAS hands the response back to the server |
| 3126 | ++ transaction from which it received the request. |
| 3127 | ++ |
| 3128 | ++8.2.6.1 Sending a Provisional Response |
| 3129 | ++ |
| 3130 | ++ One largely non-method-specific guideline for the generation of |
| 3131 | ++ responses is that UASs SHOULD NOT issue a provisional response for a |
| 3132 | ++ non-INVITE request. Rather, UASs SHOULD generate a final response to |
| 3133 | ++ a non-INVITE request as soon as possible. |
| 3134 | ++ |
| 3135 | ++ |
| 3136 | ++ |
| 3137 | ++ |
| 3138 | ++ |
| 3139 | ++Rosenberg, et. al. Standards Track [Page 49] |
| 3140 | ++ |
| 3141 | |
| 3142 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3143 | ++ |
| 3144 | ++ |
| 3145 | ++ When a 100 (Trying) response is generated, any Timestamp header field |
| 3146 | ++ present in the request MUST be copied into this 100 (Trying) |
| 3147 | ++ response. If there is a delay in generating the response, the UAS |
| 3148 | ++ SHOULD add a delay value into the Timestamp value in the response. |
| 3149 | ++ This value MUST contain the difference between the time of sending of |
| 3150 | ++ the response and receipt of the request, measured in seconds. |
| 3151 | ++ |
| 3152 | ++8.2.6.2 Headers and Tags |
| 3153 | ++ |
| 3154 | ++ The From field of the response MUST equal the From header field of |
| 3155 | ++ the request. The Call-ID header field of the response MUST equal the |
| 3156 | ++ Call-ID header field of the request. The CSeq header field of the |
| 3157 | ++ response MUST equal the CSeq field of the request. The Via header |
| 3158 | ++ field values in the response MUST equal the Via header field values |
| 3159 | ++ in the request and MUST maintain the same ordering. |
| 3160 | ++ |
| 3161 | ++ If a request contained a To tag in the request, the To header field |
| 3162 | ++ in the response MUST equal that of the request. However, if the To |
| 3163 | ++ header field in the request did not contain a tag, the URI in the To |
| 3164 | ++ header field in the response MUST equal the URI in the To header |
| 3165 | ++ field; additionally, the UAS MUST add a tag to the To header field in |
| 3166 | ++ the response (with the exception of the 100 (Trying) response, in |
| 3167 | ++ which a tag MAY be present). This serves to identify the UAS that is |
| 3168 | ++ responding, possibly resulting in a component of a dialog ID. The |
| 3169 | ++ same tag MUST be used for all responses to that request, both final |
| 3170 | ++ and provisional (again excepting the 100 (Trying)). Procedures for |
| 3171 | ++ the generation of tags are defined in Section 19.3. |
| 3172 | ++ |
| 3173 | ++8.2.7 Stateless UAS Behavior |
| 3174 | ++ |
| 3175 | ++ A stateless UAS is a UAS that does not maintain transaction state. |
| 3176 | ++ It replies to requests normally, but discards any state that would |
| 3177 | ++ ordinarily be retained by a UAS after a response has been sent. If a |
| 3178 | ++ stateless UAS receives a retransmission of a request, it regenerates |
| 3179 | ++ the response and resends it, just as if it were replying to the first |
| 3180 | ++ instance of the request. A UAS cannot be stateless unless the request |
| 3181 | ++ processing for that method would always result in the same response |
| 3182 | ++ if the requests are identical. This rules out stateless registrars, |
| 3183 | ++ for example. Stateless UASs do not use a transaction layer; they |
| 3184 | ++ receive requests directly from the transport layer and send responses |
| 3185 | ++ directly to the transport layer. |
| 3186 | ++ |
| 3187 | ++ The stateless UAS role is needed primarily to handle unauthenticated |
| 3188 | ++ requests for which a challenge response is issued. If |
| 3189 | ++ unauthenticated requests were handled statefully, then malicious |
| 3190 | ++ floods of unauthenticated requests could create massive amounts of |
| 3191 | ++ |
| 3192 | ++ |
| 3193 | ++ |
| 3194 | ++ |
| 3195 | ++ |
| 3196 | ++Rosenberg, et. al. Standards Track [Page 50] |
| 3197 | ++ |
| 3198 | |
| 3199 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3200 | ++ |
| 3201 | ++ |
| 3202 | ++ transaction state that might slow or completely halt call processing |
| 3203 | ++ in a UAS, effectively creating a denial of service condition; for |
| 3204 | ++ more information see Section 26.1.5. |
| 3205 | ++ |
| 3206 | ++ The most important behaviors of a stateless UAS are the following: |
| 3207 | ++ |
| 3208 | ++ o A stateless UAS MUST NOT send provisional (1xx) responses. |
| 3209 | ++ |
| 3210 | ++ o A stateless UAS MUST NOT retransmit responses. |
| 3211 | ++ |
| 3212 | ++ o A stateless UAS MUST ignore ACK requests. |
| 3213 | ++ |
| 3214 | ++ o A stateless UAS MUST ignore CANCEL requests. |
| 3215 | ++ |
| 3216 | ++ o To header tags MUST be generated for responses in a stateless |
| 3217 | ++ manner - in a manner that will generate the same tag for the |
| 3218 | ++ same request consistently. For information on tag construction |
| 3219 | ++ see Section 19.3. |
| 3220 | ++ |
| 3221 | ++ In all other respects, a stateless UAS behaves in the same manner as |
| 3222 | ++ a stateful UAS. A UAS can operate in either a stateful or stateless |
| 3223 | ++ mode for each new request. |
| 3224 | ++ |
| 3225 | ++8.3 Redirect Servers |
| 3226 | ++ |
| 3227 | ++ In some architectures it may be desirable to reduce the processing |
| 3228 | ++ load on proxy servers that are responsible for routing requests, and |
| 3229 | ++ improve signaling path robustness, by relying on redirection. |
| 3230 | ++ |
| 3231 | ++ Redirection allows servers to push routing information for a request |
| 3232 | ++ back in a response to the client, thereby taking themselves out of |
| 3233 | ++ the loop of further messaging for this transaction while still aiding |
| 3234 | ++ in locating the target of the request. When the originator of the |
| 3235 | ++ request receives the redirection, it will send a new request based on |
| 3236 | ++ the URI(s) it has received. By propagating URIs from the core of the |
| 3237 | ++ network to its edges, redirection allows for considerable network |
| 3238 | ++ scalability. |
| 3239 | ++ |
| 3240 | ++ A redirect server is logically constituted of a server transaction |
| 3241 | ++ layer and a transaction user that has access to a location service of |
| 3242 | ++ some kind (see Section 10 for more on registrars and location |
| 3243 | ++ services). This location service is effectively a database |
| 3244 | ++ containing mappings between a single URI and a set of one or more |
| 3245 | ++ alternative locations at which the target of that URI can be found. |
| 3246 | ++ |
| 3247 | ++ A redirect server does not issue any SIP requests of its own. After |
| 3248 | ++ receiving a request other than CANCEL, the server either refuses the |
| 3249 | ++ request or gathers the list of alternative locations from the |
| 3250 | ++ |
| 3251 | ++ |
| 3252 | ++ |
| 3253 | ++Rosenberg, et. al. Standards Track [Page 51] |
| 3254 | ++ |
| 3255 | |
| 3256 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3257 | ++ |
| 3258 | ++ |
| 3259 | ++ location service and returns a final response of class 3xx. For |
| 3260 | ++ well-formed CANCEL requests, it SHOULD return a 2xx response. This |
| 3261 | ++ response ends the SIP transaction. The redirect server maintains |
| 3262 | ++ transaction state for an entire SIP transaction. It is the |
| 3263 | ++ responsibility of clients to detect forwarding loops between redirect |
| 3264 | ++ servers. |
| 3265 | ++ |
| 3266 | ++ When a redirect server returns a 3xx response to a request, it |
| 3267 | ++ populates the list of (one or more) alternative locations into the |
| 3268 | ++ Contact header field. An "expires" parameter to the Contact header |
| 3269 | ++ field values may also be supplied to indicate the lifetime of the |
| 3270 | ++ Contact data. |
| 3271 | ++ |
| 3272 | ++ The Contact header field contains URIs giving the new locations or |
| 3273 | ++ user names to try, or may simply specify additional transport |
| 3274 | ++ parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) |
| 3275 | ++ response may also give the same location and username that was |
| 3276 | ++ targeted by the initial request but specify additional transport |
| 3277 | ++ parameters such as a different server or multicast address to try, or |
| 3278 | ++ a change of SIP transport from UDP to TCP or vice versa. |
| 3279 | ++ |
| 3280 | ++ However, redirect servers MUST NOT redirect a request to a URI equal |
| 3281 | ++ to the one in the Request-URI; instead, provided that the URI does |
| 3282 | ++ not point to itself, the server MAY proxy the request to the |
| 3283 | ++ destination URI, or MAY reject it with a 404. |
| 3284 | ++ |
| 3285 | ++ If a client is using an outbound proxy, and that proxy actually |
| 3286 | ++ redirects requests, a potential arises for infinite redirection |
| 3287 | ++ loops. |
| 3288 | ++ |
| 3289 | ++ Note that a Contact header field value MAY also refer to a different |
| 3290 | ++ resource than the one originally called. For example, a SIP call |
| 3291 | ++ connected to PSTN gateway may need to deliver a special informational |
| 3292 | ++ announcement such as "The number you have dialed has been changed." |
| 3293 | ++ |
| 3294 | ++ A Contact response header field can contain any suitable URI |
| 3295 | ++ indicating where the called party can be reached, not limited to SIP |
| 3296 | ++ URIs. For example, it could contain URIs for phones, fax, or irc (if |
| 3297 | ++ they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 |
| 3298 | ++ discusses implications and limitations of redirecting a SIPS URI to a |
| 3299 | ++ non-SIPS URI. |
| 3300 | ++ |
| 3301 | ++ The "expires" parameter of a Contact header field value indicates how |
| 3302 | ++ long the URI is valid. The value of the parameter is a number |
| 3303 | ++ indicating seconds. If this parameter is not provided, the value of |
| 3304 | ++ the Expires header field determines how long the URI is valid. |
| 3305 | ++ Malformed values SHOULD be treated as equivalent to 3600. |
| 3306 | ++ |
| 3307 | ++ |
| 3308 | ++ |
| 3309 | ++ |
| 3310 | ++Rosenberg, et. al. Standards Track [Page 52] |
| 3311 | ++ |
| 3312 | |
| 3313 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3314 | ++ |
| 3315 | ++ |
| 3316 | ++ This provides a modest level of backwards compatibility with RFC |
| 3317 | ++ 2543, which allowed absolute times in this header field. If an |
| 3318 | ++ absolute time is received, it will be treated as malformed, and |
| 3319 | ++ then default to 3600. |
| 3320 | ++ |
| 3321 | ++ Redirect servers MUST ignore features that are not understood |
| 3322 | ++ (including unrecognized header fields, any unknown option tags in |
| 3323 | ++ Require, or even method names) and proceed with the redirection of |
| 3324 | ++ the request in question. |
| 3325 | ++ |
| 3326 | ++9 Canceling a Request |
| 3327 | ++ |
| 3328 | ++ The previous section has discussed general UA behavior for generating |
| 3329 | ++ requests and processing responses for requests of all methods. In |
| 3330 | ++ this section, we discuss a general purpose method, called CANCEL. |
| 3331 | ++ |
| 3332 | ++ The CANCEL request, as the name implies, is used to cancel a previous |
| 3333 | ++ request sent by a client. Specifically, it asks the UAS to cease |
| 3334 | ++ processing the request and to generate an error response to that |
| 3335 | ++ request. CANCEL has no effect on a request to which a UAS has |
| 3336 | ++ already given a final response. Because of this, it is most useful |
| 3337 | ++ to CANCEL requests to which it can take a server long time to |
| 3338 | ++ respond. For this reason, CANCEL is best for INVITE requests, which |
| 3339 | ++ can take a long time to generate a response. In that usage, a UAS |
| 3340 | ++ that receives a CANCEL request for an INVITE, but has not yet sent a |
| 3341 | ++ final response, would "stop ringing", and then respond to the INVITE |
| 3342 | ++ with a specific error response (a 487). |
| 3343 | ++ |
| 3344 | ++ CANCEL requests can be constructed and sent by both proxies and user |
| 3345 | ++ agent clients. Section 15 discusses under what conditions a UAC |
| 3346 | ++ would CANCEL an INVITE request, and Section 16.10 discusses proxy |
| 3347 | ++ usage of CANCEL. |
| 3348 | ++ |
| 3349 | ++ A stateful proxy responds to a CANCEL, rather than simply forwarding |
| 3350 | ++ a response it would receive from a downstream element. For that |
| 3351 | ++ reason, CANCEL is referred to as a "hop-by-hop" request, since it is |
| 3352 | ++ responded to at each stateful proxy hop. |
| 3353 | ++ |
| 3354 | ++9.1 Client Behavior |
| 3355 | ++ |
| 3356 | ++ A CANCEL request SHOULD NOT be sent to cancel a request other than |
| 3357 | ++ INVITE. |
| 3358 | ++ |
| 3359 | ++ Since requests other than INVITE are responded to immediately, |
| 3360 | ++ sending a CANCEL for a non-INVITE request would always create a |
| 3361 | ++ race condition. |
| 3362 | ++ |
| 3363 | ++ |
| 3364 | ++ |
| 3365 | ++ |
| 3366 | ++ |
| 3367 | ++Rosenberg, et. al. Standards Track [Page 53] |
| 3368 | ++ |
| 3369 | |
| 3370 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3371 | ++ |
| 3372 | ++ |
| 3373 | ++ The following procedures are used to construct a CANCEL request. The |
| 3374 | ++ Request-URI, Call-ID, To, the numeric part of CSeq, and From header |
| 3375 | ++ fields in the CANCEL request MUST be identical to those in the |
| 3376 | ++ request being cancelled, including tags. A CANCEL constructed by a |
| 3377 | ++ client MUST have only a single Via header field value matching the |
| 3378 | ++ top Via value in the request being cancelled. Using the same values |
| 3379 | ++ for these header fields allows the CANCEL to be matched with the |
| 3380 | ++ request it cancels (Section 9.2 indicates how such matching occurs). |
| 3381 | ++ However, the method part of the CSeq header field MUST have a value |
| 3382 | ++ of CANCEL. This allows it to be identified and processed as a |
| 3383 | ++ transaction in its own right (See Section 17). |
| 3384 | ++ |
| 3385 | ++ If the request being cancelled contains a Route header field, the |
| 3386 | ++ CANCEL request MUST include that Route header field's values. |
| 3387 | ++ |
| 3388 | ++ This is needed so that stateless proxies are able to route CANCEL |
| 3389 | ++ requests properly. |
| 3390 | ++ |
| 3391 | ++ The CANCEL request MUST NOT contain any Require or Proxy-Require |
| 3392 | ++ header fields. |
| 3393 | ++ |
| 3394 | ++ Once the CANCEL is constructed, the client SHOULD check whether it |
| 3395 | ++ has received any response (provisional or final) for the request |
| 3396 | ++ being cancelled (herein referred to as the "original request"). |
| 3397 | ++ |
| 3398 | ++ If no provisional response has been received, the CANCEL request MUST |
| 3399 | ++ NOT be sent; rather, the client MUST wait for the arrival of a |
| 3400 | ++ provisional response before sending the request. If the original |
| 3401 | ++ request has generated a final response, the CANCEL SHOULD NOT be |
| 3402 | ++ sent, as it is an effective no-op, since CANCEL has no effect on |
| 3403 | ++ requests that have already generated a final response. When the |
| 3404 | ++ client decides to send the CANCEL, it creates a client transaction |
| 3405 | ++ for the CANCEL and passes it the CANCEL request along with the |
| 3406 | ++ destination address, port, and transport. The destination address, |
| 3407 | ++ port, and transport for the CANCEL MUST be identical to those used to |
| 3408 | ++ send the original request. |
| 3409 | ++ |
| 3410 | ++ If it was allowed to send the CANCEL before receiving a response |
| 3411 | ++ for the previous request, the server could receive the CANCEL |
| 3412 | ++ before the original request. |
| 3413 | ++ |
| 3414 | ++ Note that both the transaction corresponding to the original request |
| 3415 | ++ and the CANCEL transaction will complete independently. However, a |
| 3416 | ++ UAC canceling a request cannot rely on receiving a 487 (Request |
| 3417 | ++ Terminated) response for the original request, as an RFC 2543- |
| 3418 | ++ compliant UAS will not generate such a response. If there is no |
| 3419 | ++ final response for the original request in 64*T1 seconds (T1 is |
| 3420 | ++ |
| 3421 | ++ |
| 3422 | ++ |
| 3423 | ++ |
| 3424 | ++Rosenberg, et. al. Standards Track [Page 54] |
| 3425 | ++ |
| 3426 | |
| 3427 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3428 | ++ |
| 3429 | ++ |
| 3430 | ++ defined in Section 17.1.1.1), the client SHOULD then consider the |
| 3431 | ++ original transaction cancelled and SHOULD destroy the client |
| 3432 | ++ transaction handling the original request. |
| 3433 | ++ |
| 3434 | ++9.2 Server Behavior |
| 3435 | ++ |
| 3436 | ++ The CANCEL method requests that the TU at the server side cancel a |
| 3437 | ++ pending transaction. The TU determines the transaction to be |
| 3438 | ++ cancelled by taking the CANCEL request, and then assuming that the |
| 3439 | ++ request method is anything but CANCEL or ACK and applying the |
| 3440 | ++ transaction matching procedures of Section 17.2.3. The matching |
| 3441 | ++ transaction is the one to be cancelled. |
| 3442 | ++ |
| 3443 | ++ The processing of a CANCEL request at a server depends on the type of |
| 3444 | ++ server. A stateless proxy will forward it, a stateful proxy might |
| 3445 | ++ respond to it and generate some CANCEL requests of its own, and a UAS |
| 3446 | ++ will respond to it. See Section 16.10 for proxy treatment of CANCEL. |
| 3447 | ++ |
| 3448 | ++ A UAS first processes the CANCEL request according to the general UAS |
| 3449 | ++ processing described in Section 8.2. However, since CANCEL requests |
| 3450 | ++ are hop-by-hop and cannot be resubmitted, they cannot be challenged |
| 3451 | ++ by the server in order to get proper credentials in an Authorization |
| 3452 | ++ header field. Note also that CANCEL requests do not contain a |
| 3453 | ++ Require header field. |
| 3454 | ++ |
| 3455 | ++ If the UAS did not find a matching transaction for the CANCEL |
| 3456 | ++ according to the procedure above, it SHOULD respond to the CANCEL |
| 3457 | ++ with a 481 (Call Leg/Transaction Does Not Exist). If the transaction |
| 3458 | ++ for the original request still exists, the behavior of the UAS on |
| 3459 | ++ receiving a CANCEL request depends on whether it has already sent a |
| 3460 | ++ final response for the original request. If it has, the CANCEL |
| 3461 | ++ request has no effect on the processing of the original request, no |
| 3462 | ++ effect on any session state, and no effect on the responses generated |
| 3463 | ++ for the original request. If the UAS has not issued a final response |
| 3464 | ++ for the original request, its behavior depends on the method of the |
| 3465 | ++ original request. If the original request was an INVITE, the UAS |
| 3466 | ++ SHOULD immediately respond to the INVITE with a 487 (Request |
| 3467 | ++ Terminated). A CANCEL request has no impact on the processing of |
| 3468 | ++ transactions with any other method defined in this specification. |
| 3469 | ++ |
| 3470 | ++ Regardless of the method of the original request, as long as the |
| 3471 | ++ CANCEL matched an existing transaction, the UAS answers the CANCEL |
| 3472 | ++ request itself with a 200 (OK) response. This response is |
| 3473 | ++ constructed following the procedures described in Section 8.2.6 |
| 3474 | ++ noting that the To tag of the response to the CANCEL and the To tag |
| 3475 | ++ in the response to the original request SHOULD be the same. The |
| 3476 | ++ response to CANCEL is passed to the server transaction for |
| 3477 | ++ transmission. |
| 3478 | ++ |
| 3479 | ++ |
| 3480 | ++ |
| 3481 | ++Rosenberg, et. al. Standards Track [Page 55] |
| 3482 | ++ |
| 3483 | |
| 3484 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3485 | ++ |
| 3486 | ++ |
| 3487 | ++10 Registrations |
| 3488 | ++ |
| 3489 | ++10.1 Overview |
| 3490 | ++ |
| 3491 | ++ SIP offers a discovery capability. If a user wants to initiate a |
| 3492 | ++ session with another user, SIP must discover the current host(s) at |
| 3493 | ++ which the destination user is reachable. This discovery process is |
| 3494 | ++ frequently accomplished by SIP network elements such as proxy servers |
| 3495 | ++ and redirect servers which are responsible for receiving a request, |
| 3496 | ++ determining where to send it based on knowledge of the location of |
| 3497 | ++ the user, and then sending it there. To do this, SIP network |
| 3498 | ++ elements consult an abstract service known as a location service, |
| 3499 | ++ which provides address bindings for a particular domain. These |
| 3500 | ++ address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, |
| 3501 | ++ for example, to one or more URIs that are somehow "closer" to the |
| 3502 | ++ desired user, sip:bob@engineering.biloxi.com, for example. |
| 3503 | ++ Ultimately, a proxy will consult a location service that maps a |
| 3504 | ++ received URI to the user agent(s) at which the desired recipient is |
| 3505 | ++ currently residing. |
| 3506 | ++ |
| 3507 | ++ Registration creates bindings in a location service for a particular |
| 3508 | ++ domain that associates an address-of-record URI with one or more |
| 3509 | ++ contact addresses. Thus, when a proxy for that domain receives a |
| 3510 | ++ request whose Request-URI matches the address-of-record, the proxy |
| 3511 | ++ will forward the request to the contact addresses registered to that |
| 3512 | ++ address-of-record. Generally, it only makes sense to register an |
| 3513 | ++ address-of-record at a domain's location service when requests for |
| 3514 | ++ that address-of-record would be routed to that domain. In most |
| 3515 | ++ cases, this means that the domain of the registration will need to |
| 3516 | ++ match the domain in the URI of the address-of-record. |
| 3517 | ++ |
| 3518 | ++ There are many ways by which the contents of the location service can |
| 3519 | ++ be established. One way is administratively. In the above example, |
| 3520 | ++ Bob is known to be a member of the engineering department through |
| 3521 | ++ access to a corporate database. However, SIP provides a mechanism |
| 3522 | ++ for a UA to create a binding explicitly. This mechanism is known as |
| 3523 | ++ registration. |
| 3524 | ++ |
| 3525 | ++ Registration entails sending a REGISTER request to a special type of |
| 3526 | ++ UAS known as a registrar. A registrar acts as the front end to the |
| 3527 | ++ location service for a domain, reading and writing mappings based on |
| 3528 | ++ the contents of REGISTER requests. This location service is then |
| 3529 | ++ typically consulted by a proxy server that is responsible for routing |
| 3530 | ++ requests for that domain. |
| 3531 | ++ |
| 3532 | ++ An illustration of the overall registration process is given in |
| 3533 | ++ Figure 2. Note that the registrar and proxy server are logical roles |
| 3534 | ++ that can be played by a single device in a network; for purposes of |
| 3535 | ++ |
| 3536 | ++ |
| 3537 | ++ |
| 3538 | ++Rosenberg, et. al. Standards Track [Page 56] |
| 3539 | ++ |
| 3540 | |
| 3541 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3542 | ++ |
| 3543 | ++ |
| 3544 | ++ clarity the two are separated in this illustration. Also note that |
| 3545 | ++ UAs may send requests through a proxy server in order to reach a |
| 3546 | ++ registrar if the two are separate elements. |
| 3547 | ++ |
| 3548 | ++ SIP does not mandate a particular mechanism for implementing the |
| 3549 | ++ location service. The only requirement is that a registrar for some |
| 3550 | ++ domain MUST be able to read and write data to the location service, |
| 3551 | ++ and a proxy or a redirect server for that domain MUST be capable of |
| 3552 | ++ reading that same data. A registrar MAY be co-located with a |
| 3553 | ++ particular SIP proxy server for the same domain. |
| 3554 | ++ |
| 3555 | ++10.2 Constructing the REGISTER Request |
| 3556 | ++ |
| 3557 | ++ REGISTER requests add, remove, and query bindings. A REGISTER |
| 3558 | ++ request can add a new binding between an address-of-record and one or |
| 3559 | ++ more contact addresses. Registration on behalf of a particular |
| 3560 | ++ address-of-record can be performed by a suitably authorized third |
| 3561 | ++ party. A client can also remove previous bindings or query to |
| 3562 | ++ determine which bindings are currently in place for an address-of- |
| 3563 | ++ record. |
| 3564 | ++ |
| 3565 | ++ Except as noted, the construction of the REGISTER request and the |
| 3566 | ++ behavior of clients sending a REGISTER request is identical to the |
| 3567 | ++ general UAC behavior described in Section 8.1 and Section 17.1. |
| 3568 | ++ |
| 3569 | ++ A REGISTER request does not establish a dialog. A UAC MAY include a |
| 3570 | ++ Route header field in a REGISTER request based on a pre-existing |
| 3571 | ++ route set as described in Section 8.1. The Record-Route header field |
| 3572 | ++ has no meaning in REGISTER requests or responses, and MUST be ignored |
| 3573 | ++ if present. In particular, the UAC MUST NOT create a new route set |
| 3574 | ++ based on the presence or absence of a Record-Route header field in |
| 3575 | ++ any response to a REGISTER request. |
| 3576 | ++ |
| 3577 | ++ The following header fields, except Contact, MUST be included in a |
| 3578 | ++ REGISTER request. A Contact header field MAY be included: |
| 3579 | ++ |
| 3580 | ++ Request-URI: The Request-URI names the domain of the location |
| 3581 | ++ service for which the registration is meant (for example, |
| 3582 | ++ "sip:chicago.com"). The "userinfo" and "@" components of the |
| 3583 | ++ SIP URI MUST NOT be present. |
| 3584 | ++ |
| 3585 | ++ To: The To header field contains the address of record whose |
| 3586 | ++ registration is to be created, queried, or modified. The To |
| 3587 | ++ header field and the Request-URI field typically differ, as |
| 3588 | ++ the former contains a user name. This address-of-record MUST |
| 3589 | ++ be a SIP URI or SIPS URI. |
| 3590 | ++ |
| 3591 | ++ |
| 3592 | ++ |
| 3593 | ++ |
| 3594 | ++ |
| 3595 | ++Rosenberg, et. al. Standards Track [Page 57] |
| 3596 | ++ |
| 3597 | |
| 3598 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3599 | ++ |
| 3600 | ++ |
| 3601 | ++ From: The From header field contains the address-of-record of the |
| 3602 | ++ person responsible for the registration. The value is the |
| 3603 | ++ same as the To header field unless the request is a third- |
| 3604 | ++ party registration. |
| 3605 | ++ |
| 3606 | ++ Call-ID: All registrations from a UAC SHOULD use the same Call-ID |
| 3607 | ++ header field value for registrations sent to a particular |
| 3608 | ++ registrar. |
| 3609 | ++ |
| 3610 | ++ If the same client were to use different Call-ID values, a |
| 3611 | ++ registrar could not detect whether a delayed REGISTER request |
| 3612 | ++ might have arrived out of order. |
| 3613 | ++ |
| 3614 | ++ CSeq: The CSeq value guarantees proper ordering of REGISTER |
| 3615 | ++ requests. A UA MUST increment the CSeq value by one for each |
| 3616 | ++ REGISTER request with the same Call-ID. |
| 3617 | ++ |
| 3618 | ++ Contact: REGISTER requests MAY contain a Contact header field with |
| 3619 | ++ zero or more values containing address bindings. |
| 3620 | ++ |
| 3621 | ++ UAs MUST NOT send a new registration (that is, containing new Contact |
| 3622 | ++ header field values, as opposed to a retransmission) until they have |
| 3623 | ++ received a final response from the registrar for the previous one or |
| 3624 | ++ the previous REGISTER request has timed out. |
| 3625 | ++ |
| 3626 | ++ |
| 3627 | ++ |
| 3628 | ++ |
| 3629 | ++ |
| 3630 | ++ |
| 3631 | ++ |
| 3632 | ++ |
| 3633 | ++ |
| 3634 | ++ |
| 3635 | ++ |
| 3636 | ++ |
| 3637 | ++ |
| 3638 | ++ |
| 3639 | ++ |
| 3640 | ++ |
| 3641 | ++ |
| 3642 | ++ |
| 3643 | ++ |
| 3644 | ++ |
| 3645 | ++ |
| 3646 | ++ |
| 3647 | ++ |
| 3648 | ++ |
| 3649 | ++ |
| 3650 | ++ |
| 3651 | ++ |
| 3652 | ++Rosenberg, et. al. Standards Track [Page 58] |
| 3653 | ++ |
| 3654 | |
| 3655 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3656 | ++ |
| 3657 | ++ |
| 3658 | ++ bob |
| 3659 | ++ +----+ |
| 3660 | ++ | UA | |
| 3661 | ++ | | |
| 3662 | ++ +----+ |
| 3663 | ++ | |
| 3664 | ++ |3)INVITE |
| 3665 | ++ | carol@chicago.com |
| 3666 | ++ chicago.com +--------+ V |
| 3667 | ++ +---------+ 2)Store|Location|4)Query +-----+ |
| 3668 | ++ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com |
| 3669 | ++ +---------+ +--------+=======>+-----+ |
| 3670 | ++ A 5)Resp | |
| 3671 | ++ | | |
| 3672 | ++ | | |
| 3673 | ++ 1)REGISTER| | |
| 3674 | ++ | | |
| 3675 | ++ +----+ | |
| 3676 | ++ | UA |<-------------------------------+ |
| 3677 | ++ cube2214a| | 6)INVITE |
| 3678 | ++ +----+ carol@cube2214a.chicago.com |
| 3679 | ++ carol |
| 3680 | ++ |
| 3681 | ++ Figure 2: REGISTER example |
| 3682 | ++ |
| 3683 | ++ The following Contact header parameters have a special meaning in |
| 3684 | ++ REGISTER requests: |
| 3685 | ++ |
| 3686 | ++ action: The "action" parameter from RFC 2543 has been deprecated. |
| 3687 | ++ UACs SHOULD NOT use the "action" parameter. |
| 3688 | ++ |
| 3689 | ++ expires: The "expires" parameter indicates how long the UA would |
| 3690 | ++ like the binding to be valid. The value is a number |
| 3691 | ++ indicating seconds. If this parameter is not provided, the |
| 3692 | ++ value of the Expires header field is used instead. |
| 3693 | ++ Implementations MAY treat values larger than 2**32-1 |
| 3694 | ++ (4294967295 seconds or 136 years) as equivalent to 2**32-1. |
| 3695 | ++ Malformed values SHOULD be treated as equivalent to 3600. |
| 3696 | ++ |
| 3697 | ++10.2.1 Adding Bindings |
| 3698 | ++ |
| 3699 | ++ The REGISTER request sent to a registrar includes the contact |
| 3700 | ++ address(es) to which SIP requests for the address-of-record should be |
| 3701 | ++ forwarded. The address-of-record is included in the To header field |
| 3702 | ++ of the REGISTER request. |
| 3703 | ++ |
| 3704 | ++ |
| 3705 | ++ |
| 3706 | ++ |
| 3707 | ++ |
| 3708 | ++ |
| 3709 | ++Rosenberg, et. al. Standards Track [Page 59] |
| 3710 | ++ |
| 3711 | |
| 3712 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3713 | ++ |
| 3714 | ++ |
| 3715 | ++ The Contact header field values of the request typically consist of |
| 3716 | ++ SIP or SIPS URIs that identify particular SIP endpoints (for example, |
| 3717 | ++ "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. |
| 3718 | ++ A SIP UA can choose to register telephone numbers (with the tel URL, |
| 3719 | ++ RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) |
| 3720 | ++ as Contacts for an address-of-record, for example. |
| 3721 | ++ |
| 3722 | ++ For example, Carol, with address-of-record "sip:carol@chicago.com", |
| 3723 | ++ would register with the SIP registrar of the domain chicago.com. Her |
| 3724 | ++ registrations would then be used by a proxy server in the chicago.com |
| 3725 | ++ domain to route requests for Carol's address-of-record to her SIP |
| 3726 | ++ endpoint. |
| 3727 | ++ |
| 3728 | ++ Once a client has established bindings at a registrar, it MAY send |
| 3729 | ++ subsequent registrations containing new bindings or modifications to |
| 3730 | ++ existing bindings as necessary. The 2xx response to the REGISTER |
| 3731 | ++ request will contain, in a Contact header field, a complete list of |
| 3732 | ++ bindings that have been registered for this address-of-record at this |
| 3733 | ++ registrar. |
| 3734 | ++ |
| 3735 | ++ If the address-of-record in the To header field of a REGISTER request |
| 3736 | ++ is a SIPS URI, then any Contact header field values in the request |
| 3737 | ++ SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs |
| 3738 | ++ under a SIPS address-of-record when the security of the resource |
| 3739 | ++ represented by the contact address is guaranteed by other means. |
| 3740 | ++ This may be applicable to URIs that invoke protocols other than SIP, |
| 3741 | ++ or SIP devices secured by protocols other than TLS. |
| 3742 | ++ |
| 3743 | ++ Registrations do not need to update all bindings. Typically, a UA |
| 3744 | ++ only updates its own contact addresses. |
| 3745 | ++ |
| 3746 | ++10.2.1.1 Setting the Expiration Interval of Contact Addresses |
| 3747 | ++ |
| 3748 | ++ When a client sends a REGISTER request, it MAY suggest an expiration |
| 3749 | ++ interval that indicates how long the client would like the |
| 3750 | ++ registration to be valid. (As described in Section 10.3, the |
| 3751 | ++ registrar selects the actual time interval based on its local |
| 3752 | ++ policy.) |
| 3753 | ++ |
| 3754 | ++ There are two ways in which a client can suggest an expiration |
| 3755 | ++ interval for a binding: through an Expires header field or an |
| 3756 | ++ "expires" Contact header parameter. The latter allows expiration |
| 3757 | ++ intervals to be suggested on a per-binding basis when more than one |
| 3758 | ++ binding is given in a single REGISTER request, whereas the former |
| 3759 | ++ suggests an expiration interval for all Contact header field values |
| 3760 | ++ that do not contain the "expires" parameter. |
| 3761 | ++ |
| 3762 | ++ |
| 3763 | ++ |
| 3764 | ++ |
| 3765 | ++ |
| 3766 | ++Rosenberg, et. al. Standards Track [Page 60] |
| 3767 | ++ |
| 3768 | |
| 3769 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3770 | ++ |
| 3771 | ++ |
| 3772 | ++ If neither mechanism for expressing a suggested expiration time is |
| 3773 | ++ present in a REGISTER, the client is indicating its desire for the |
| 3774 | ++ server to choose. |
| 3775 | ++ |
| 3776 | ++10.2.1.2 Preferences among Contact Addresses |
| 3777 | ++ |
| 3778 | ++ If more than one Contact is sent in a REGISTER request, the |
| 3779 | ++ registering UA intends to associate all of the URIs in these Contact |
| 3780 | ++ header field values with the address-of-record present in the To |
| 3781 | ++ field. This list can be prioritized with the "q" parameter in the |
| 3782 | ++ Contact header field. The "q" parameter indicates a relative |
| 3783 | ++ preference for the particular Contact header field value compared to |
| 3784 | ++ other bindings for this address-of-record. Section 16.6 describes |
| 3785 | ++ how a proxy server uses this preference indication. |
| 3786 | ++ |
| 3787 | ++10.2.2 Removing Bindings |
| 3788 | ++ |
| 3789 | ++ Registrations are soft state and expire unless refreshed, but can |
| 3790 | ++ also be explicitly removed. A client can attempt to influence the |
| 3791 | ++ expiration interval selected by the registrar as described in Section |
| 3792 | ++ 10.2.1. A UA requests the immediate removal of a binding by |
| 3793 | ++ specifying an expiration interval of "0" for that contact address in |
| 3794 | ++ a REGISTER request. UAs SHOULD support this mechanism so that |
| 3795 | ++ bindings can be removed before their expiration interval has passed. |
| 3796 | ++ |
| 3797 | ++ The REGISTER-specific Contact header field value of "*" applies to |
| 3798 | ++ all registrations, but it MUST NOT be used unless the Expires header |
| 3799 | ++ field is present with a value of "0". |
| 3800 | ++ |
| 3801 | ++ Use of the "*" Contact header field value allows a registering UA |
| 3802 | ++ to remove all bindings associated with an address-of-record |
| 3803 | ++ without knowing their precise values. |
| 3804 | ++ |
| 3805 | ++10.2.3 Fetching Bindings |
| 3806 | ++ |
| 3807 | ++ A success response to any REGISTER request contains the complete list |
| 3808 | ++ of existing bindings, regardless of whether the request contained a |
| 3809 | ++ Contact header field. If no Contact header field is present in a |
| 3810 | ++ REGISTER request, the list of bindings is left unchanged. |
| 3811 | ++ |
| 3812 | ++10.2.4 Refreshing Bindings |
| 3813 | ++ |
| 3814 | ++ Each UA is responsible for refreshing the bindings that it has |
| 3815 | ++ previously established. A UA SHOULD NOT refresh bindings set up by |
| 3816 | ++ other UAs. |
| 3817 | ++ |
| 3818 | ++ |
| 3819 | ++ |
| 3820 | ++ |
| 3821 | ++ |
| 3822 | ++ |
| 3823 | ++Rosenberg, et. al. Standards Track [Page 61] |
| 3824 | ++ |
| 3825 | |
| 3826 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3827 | ++ |
| 3828 | ++ |
| 3829 | ++ The 200 (OK) response from the registrar contains a list of Contact |
| 3830 | ++ fields enumerating all current bindings. The UA compares each |
| 3831 | ++ contact address to see if it created the contact address, using |
| 3832 | ++ comparison rules in Section 19.1.4. If so, it updates the expiration |
| 3833 | ++ time interval according to the expires parameter or, if absent, the |
| 3834 | ++ Expires field value. The UA then issues a REGISTER request for each |
| 3835 | ++ of its bindings before the expiration interval has elapsed. It MAY |
| 3836 | ++ combine several updates into one REGISTER request. |
| 3837 | ++ |
| 3838 | ++ A UA SHOULD use the same Call-ID for all registrations during a |
| 3839 | ++ single boot cycle. Registration refreshes SHOULD be sent to the same |
| 3840 | ++ network address as the original registration, unless redirected. |
| 3841 | ++ |
| 3842 | ++10.2.5 Setting the Internal Clock |
| 3843 | ++ |
| 3844 | ++ If the response for a REGISTER request contains a Date header field, |
| 3845 | ++ the client MAY use this header field to learn the current time in |
| 3846 | ++ order to set any internal clocks. |
| 3847 | ++ |
| 3848 | ++10.2.6 Discovering a Registrar |
| 3849 | ++ |
| 3850 | ++ UAs can use three ways to determine the address to which to send |
| 3851 | ++ registrations: by configuration, using the address-of-record, and |
| 3852 | ++ multicast. A UA can be configured, in ways beyond the scope of this |
| 3853 | ++ specification, with a registrar address. If there is no configured |
| 3854 | ++ registrar address, the UA SHOULD use the host part of the address- |
| 3855 | ++ of-record as the Request-URI and address the request there, using the |
| 3856 | ++ normal SIP server location mechanisms [4]. For example, the UA for |
| 3857 | ++ the user "sip:carol@chicago.com" addresses the REGISTER request to |
| 3858 | ++ "sip:chicago.com". |
| 3859 | ++ |
| 3860 | ++ Finally, a UA can be configured to use multicast. Multicast |
| 3861 | ++ registrations are addressed to the well-known "all SIP servers" |
| 3862 | ++ multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well- |
| 3863 | ++ known IPv6 multicast address has been allocated; such an allocation |
| 3864 | ++ will be documented separately when needed. SIP UAs MAY listen to |
| 3865 | ++ that address and use it to become aware of the location of other |
| 3866 | ++ local users (see [33]); however, they do not respond to the request. |
| 3867 | ++ |
| 3868 | ++ Multicast registration may be inappropriate in some environments, |
| 3869 | ++ for example, if multiple businesses share the same local area |
| 3870 | ++ network. |
| 3871 | ++ |
| 3872 | ++10.2.7 Transmitting a Request |
| 3873 | ++ |
| 3874 | ++ Once the REGISTER method has been constructed, and the destination of |
| 3875 | ++ the message identified, UACs follow the procedures described in |
| 3876 | ++ Section 8.1.2 to hand off the REGISTER to the transaction layer. |
| 3877 | ++ |
| 3878 | ++ |
| 3879 | ++ |
| 3880 | ++Rosenberg, et. al. Standards Track [Page 62] |
| 3881 | ++ |
| 3882 | |
| 3883 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3884 | ++ |
| 3885 | ++ |
| 3886 | ++ If the transaction layer returns a timeout error because the REGISTER |
| 3887 | ++ yielded no response, the UAC SHOULD NOT immediately re-attempt a |
| 3888 | ++ registration to the same registrar. |
| 3889 | ++ |
| 3890 | ++ An immediate re-attempt is likely to also timeout. Waiting some |
| 3891 | ++ reasonable time interval for the conditions causing the timeout to |
| 3892 | ++ be corrected reduces unnecessary load on the network. No specific |
| 3893 | ++ interval is mandated. |
| 3894 | ++ |
| 3895 | ++10.2.8 Error Responses |
| 3896 | ++ |
| 3897 | ++ If a UA receives a 423 (Interval Too Brief) response, it MAY retry |
| 3898 | ++ the registration after making the expiration interval of all contact |
| 3899 | ++ addresses in the REGISTER request equal to or greater than the |
| 3900 | ++ expiration interval within the Min-Expires header field of the 423 |
| 3901 | ++ (Interval Too Brief) response. |
| 3902 | ++ |
| 3903 | ++10.3 Processing REGISTER Requests |
| 3904 | ++ |
| 3905 | ++ A registrar is a UAS that responds to REGISTER requests and maintains |
| 3906 | ++ a list of bindings that are accessible to proxy servers and redirect |
| 3907 | ++ servers within its administrative domain. A registrar handles |
| 3908 | ++ requests according to Section 8.2 and Section 17.2, but it accepts |
| 3909 | ++ only REGISTER requests. A registrar MUST not generate 6xx responses. |
| 3910 | ++ |
| 3911 | ++ A registrar MAY redirect REGISTER requests as appropriate. One |
| 3912 | ++ common usage would be for a registrar listening on a multicast |
| 3913 | ++ interface to redirect multicast REGISTER requests to its own unicast |
| 3914 | ++ interface with a 302 (Moved Temporarily) response. |
| 3915 | ++ |
| 3916 | ++ Registrars MUST ignore the Record-Route header field if it is |
| 3917 | ++ included in a REGISTER request. Registrars MUST NOT include a |
| 3918 | ++ Record-Route header field in any response to a REGISTER request. |
| 3919 | ++ |
| 3920 | ++ A registrar might receive a request that traversed a proxy which |
| 3921 | ++ treats REGISTER as an unknown request and which added a Record- |
| 3922 | ++ Route header field value. |
| 3923 | ++ |
| 3924 | ++ A registrar has to know (for example, through configuration) the set |
| 3925 | ++ of domain(s) for which it maintains bindings. REGISTER requests MUST |
| 3926 | ++ be processed by a registrar in the order that they are received. |
| 3927 | ++ REGISTER requests MUST also be processed atomically, meaning that a |
| 3928 | ++ particular REGISTER request is either processed completely or not at |
| 3929 | ++ all. Each REGISTER message MUST be processed independently of any |
| 3930 | ++ other registration or binding changes. |
| 3931 | ++ |
| 3932 | ++ |
| 3933 | ++ |
| 3934 | ++ |
| 3935 | ++ |
| 3936 | ++ |
| 3937 | ++Rosenberg, et. al. Standards Track [Page 63] |
| 3938 | ++ |
| 3939 | |
| 3940 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3941 | ++ |
| 3942 | ++ |
| 3943 | ++ When receiving a REGISTER request, a registrar follows these steps: |
| 3944 | ++ |
| 3945 | ++ 1. The registrar inspects the Request-URI to determine whether it |
| 3946 | ++ has access to bindings for the domain identified in the |
| 3947 | ++ Request-URI. If not, and if the server also acts as a proxy |
| 3948 | ++ server, the server SHOULD forward the request to the addressed |
| 3949 | ++ domain, following the general behavior for proxying messages |
| 3950 | ++ described in Section 16. |
| 3951 | ++ |
| 3952 | ++ 2. To guarantee that the registrar supports any necessary |
| 3953 | ++ extensions, the registrar MUST process the Require header field |
| 3954 | ++ values as described for UASs in Section 8.2.2. |
| 3955 | ++ |
| 3956 | ++ 3. A registrar SHOULD authenticate the UAC. Mechanisms for the |
| 3957 | ++ authentication of SIP user agents are described in Section 22. |
| 3958 | ++ Registration behavior in no way overrides the generic |
| 3959 | ++ authentication framework for SIP. If no authentication |
| 3960 | ++ mechanism is available, the registrar MAY take the From address |
| 3961 | ++ as the asserted identity of the originator of the request. |
| 3962 | ++ |
| 3963 | ++ 4. The registrar SHOULD determine if the authenticated user is |
| 3964 | ++ authorized to modify registrations for this address-of-record. |
| 3965 | ++ For example, a registrar might consult an authorization |
| 3966 | ++ database that maps user names to a list of addresses-of-record |
| 3967 | ++ for which that user has authorization to modify bindings. If |
| 3968 | ++ the authenticated user is not authorized to modify bindings, |
| 3969 | ++ the registrar MUST return a 403 (Forbidden) and skip the |
| 3970 | ++ remaining steps. |
| 3971 | ++ |
| 3972 | ++ In architectures that support third-party registration, one |
| 3973 | ++ entity may be responsible for updating the registrations |
| 3974 | ++ associated with multiple addresses-of-record. |
| 3975 | ++ |
| 3976 | ++ 5. The registrar extracts the address-of-record from the To header |
| 3977 | ++ field of the request. If the address-of-record is not valid |
| 3978 | ++ for the domain in the Request-URI, the registrar MUST send a |
| 3979 | ++ 404 (Not Found) response and skip the remaining steps. The URI |
| 3980 | ++ MUST then be converted to a canonical form. To do that, all |
| 3981 | ++ URI parameters MUST be removed (including the user-param), and |
| 3982 | ++ any escaped characters MUST be converted to their unescaped |
| 3983 | ++ form. The result serves as an index into the list of bindings. |
| 3984 | ++ |
| 3985 | ++ |
| 3986 | ++ |
| 3987 | ++ |
| 3988 | ++ |
| 3989 | ++ |
| 3990 | ++ |
| 3991 | ++ |
| 3992 | ++ |
| 3993 | ++ |
| 3994 | ++Rosenberg, et. al. Standards Track [Page 64] |
| 3995 | ++ |
| 3996 | |
| 3997 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 3998 | ++ |
| 3999 | ++ |
| 4000 | ++ 6. The registrar checks whether the request contains the Contact |
| 4001 | ++ header field. If not, it skips to the last step. If the |
| 4002 | ++ Contact header field is present, the registrar checks if there |
| 4003 | ++ is one Contact field value that contains the special value "*" |
| 4004 | ++ and an Expires field. If the request has additional Contact |
| 4005 | ++ fields or an expiration time other than zero, the request is |
| 4006 | ++ invalid, and the server MUST return a 400 (Invalid Request) and |
| 4007 | ++ skip the remaining steps. If not, the registrar checks whether |
| 4008 | ++ the Call-ID agrees with the value stored for each binding. If |
| 4009 | ++ not, it MUST remove the binding. If it does agree, it MUST |
| 4010 | ++ remove the binding only if the CSeq in the request is higher |
| 4011 | ++ than the value stored for that binding. Otherwise, the update |
| 4012 | ++ MUST be aborted and the request fails. |
| 4013 | ++ |
| 4014 | ++ 7. The registrar now processes each contact address in the Contact |
| 4015 | ++ header field in turn. For each address, it determines the |
| 4016 | ++ expiration interval as follows: |
| 4017 | ++ |
| 4018 | ++ - If the field value has an "expires" parameter, that value |
| 4019 | ++ MUST be taken as the requested expiration. |
| 4020 | ++ |
| 4021 | ++ - If there is no such parameter, but the request has an |
| 4022 | ++ Expires header field, that value MUST be taken as the |
| 4023 | ++ requested expiration. |
| 4024 | ++ |
| 4025 | ++ - If there is neither, a locally-configured default value MUST |
| 4026 | ++ be taken as the requested expiration. |
| 4027 | ++ |
| 4028 | ++ The registrar MAY choose an expiration less than the requested |
| 4029 | ++ expiration interval. If and only if the requested expiration |
| 4030 | ++ interval is greater than zero AND smaller than one hour AND |
| 4031 | ++ less than a registrar-configured minimum, the registrar MAY |
| 4032 | ++ reject the registration with a response of 423 (Interval Too |
| 4033 | ++ Brief). This response MUST contain a Min-Expires header field |
| 4034 | ++ that states the minimum expiration interval the registrar is |
| 4035 | ++ willing to honor. It then skips the remaining steps. |
| 4036 | ++ |
| 4037 | ++ Allowing the registrar to set the registration interval |
| 4038 | ++ protects it against excessively frequent registration refreshes |
| 4039 | ++ while limiting the state that it needs to maintain and |
| 4040 | ++ decreasing the likelihood of registrations going stale. The |
| 4041 | ++ expiration interval of a registration is frequently used in the |
| 4042 | ++ creation of services. An example is a follow-me service, where |
| 4043 | ++ the user may only be available at a terminal for a brief |
| 4044 | ++ period. Therefore, registrars should accept brief |
| 4045 | ++ registrations; a request should only be rejected if the |
| 4046 | ++ interval is so short that the refreshes would degrade registrar |
| 4047 | ++ performance. |
| 4048 | ++ |
| 4049 | ++ |
| 4050 | ++ |
| 4051 | ++Rosenberg, et. al. Standards Track [Page 65] |
| 4052 | ++ |
| 4053 | |
| 4054 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4055 | ++ |
| 4056 | ++ |
| 4057 | ++ For each address, the registrar then searches the list of |
| 4058 | ++ current bindings using the URI comparison rules. If the |
| 4059 | ++ binding does not exist, it is tentatively added. If the |
| 4060 | ++ binding does exist, the registrar checks the Call-ID value. If |
| 4061 | ++ the Call-ID value in the existing binding differs from the |
| 4062 | ++ Call-ID value in the request, the binding MUST be removed if |
| 4063 | ++ the expiration time is zero and updated otherwise. If they are |
| 4064 | ++ the same, the registrar compares the CSeq value. If the value |
| 4065 | ++ is higher than that of the existing binding, it MUST update or |
| 4066 | ++ remove the binding as above. If not, the update MUST be |
| 4067 | ++ aborted and the request fails. |
| 4068 | ++ |
| 4069 | ++ This algorithm ensures that out-of-order requests from the same |
| 4070 | ++ UA are ignored. |
| 4071 | ++ |
| 4072 | ++ Each binding record records the Call-ID and CSeq values from |
| 4073 | ++ the request. |
| 4074 | ++ |
| 4075 | ++ The binding updates MUST be committed (that is, made visible to |
| 4076 | ++ the proxy or redirect server) if and only if all binding |
| 4077 | ++ updates and additions succeed. If any one of them fails (for |
| 4078 | ++ example, because the back-end database commit failed), the |
| 4079 | ++ request MUST fail with a 500 (Server Error) response and all |
| 4080 | ++ tentative binding updates MUST be removed. |
| 4081 | ++ |
| 4082 | ++ 8. The registrar returns a 200 (OK) response. The response MUST |
| 4083 | ++ contain Contact header field values enumerating all current |
| 4084 | ++ bindings. Each Contact value MUST feature an "expires" |
| 4085 | ++ parameter indicating its expiration interval chosen by the |
| 4086 | ++ registrar. The response SHOULD include a Date header field. |
| 4087 | ++ |
| 4088 | ++11 Querying for Capabilities |
| 4089 | ++ |
| 4090 | ++ The SIP method OPTIONS allows a UA to query another UA or a proxy |
| 4091 | ++ server as to its capabilities. This allows a client to discover |
| 4092 | ++ information about the supported methods, content types, extensions, |
| 4093 | ++ codecs, etc. without "ringing" the other party. For example, before |
| 4094 | ++ a client inserts a Require header field into an INVITE listing an |
| 4095 | ++ option that it is not certain the destination UAS supports, the |
| 4096 | ++ client can query the destination UAS with an OPTIONS to see if this |
| 4097 | ++ option is returned in a Supported header field. All UAs MUST support |
| 4098 | ++ the OPTIONS method. |
| 4099 | ++ |
| 4100 | ++ The target of the OPTIONS request is identified by the Request-URI, |
| 4101 | ++ which could identify another UA or a SIP server. If the OPTIONS is |
| 4102 | ++ addressed to a proxy server, the Request-URI is set without a user |
| 4103 | ++ part, similar to the way a Request-URI is set for a REGISTER request. |
| 4104 | ++ |
| 4105 | ++ |
| 4106 | ++ |
| 4107 | ++ |
| 4108 | ++Rosenberg, et. al. Standards Track [Page 66] |
| 4109 | ++ |
| 4110 | |
| 4111 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4112 | ++ |
| 4113 | ++ |
| 4114 | ++ Alternatively, a server receiving an OPTIONS request with a Max- |
| 4115 | ++ Forwards header field value of 0 MAY respond to the request |
| 4116 | ++ regardless of the Request-URI. |
| 4117 | ++ |
| 4118 | ++ This behavior is common with HTTP/1.1. This behavior can be used |
| 4119 | ++ as a "traceroute" functionality to check the capabilities of |
| 4120 | ++ individual hop servers by sending a series of OPTIONS requests |
| 4121 | ++ with incremented Max-Forwards values. |
| 4122 | ++ |
| 4123 | ++ As is the case for general UA behavior, the transaction layer can |
| 4124 | ++ return a timeout error if the OPTIONS yields no response. This may |
| 4125 | ++ indicate that the target is unreachable and hence unavailable. |
| 4126 | ++ |
| 4127 | ++ An OPTIONS request MAY be sent as part of an established dialog to |
| 4128 | ++ query the peer on capabilities that may be utilized later in the |
| 4129 | ++ dialog. |
| 4130 | ++ |
| 4131 | ++11.1 Construction of OPTIONS Request |
| 4132 | ++ |
| 4133 | ++ An OPTIONS request is constructed using the standard rules for a SIP |
| 4134 | ++ request as discussed in Section 8.1.1. |
| 4135 | ++ |
| 4136 | ++ A Contact header field MAY be present in an OPTIONS. |
| 4137 | ++ |
| 4138 | ++ An Accept header field SHOULD be included to indicate the type of |
| 4139 | ++ message body the UAC wishes to receive in the response. Typically, |
| 4140 | ++ this is set to a format that is used to describe the media |
| 4141 | ++ capabilities of a UA, such as SDP (application/sdp). |
| 4142 | ++ |
| 4143 | ++ The response to an OPTIONS request is assumed to be scoped to the |
| 4144 | ++ Request-URI in the original request. However, only when an OPTIONS |
| 4145 | ++ is sent as part of an established dialog is it guaranteed that future |
| 4146 | ++ requests will be received by the server that generated the OPTIONS |
| 4147 | ++ response. |
| 4148 | ++ |
| 4149 | ++ Example OPTIONS request: |
| 4150 | ++ |
| 4151 | ++ OPTIONS sip:carol@chicago.com SIP/2.0 |
| 4152 | ++ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 |
| 4153 | ++ Max-Forwards: 70 |
| 4154 | ++ To: <sip:carol@chicago.com> |
| 4155 | ++ From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
| 4156 | ++ Call-ID: a84b4c76e66710 |
| 4157 | ++ CSeq: 63104 OPTIONS |
| 4158 | ++ Contact: <sip:alice@pc33.atlanta.com> |
| 4159 | ++ Accept: application/sdp |
| 4160 | ++ Content-Length: 0 |
| 4161 | ++ |
| 4162 | ++ |
| 4163 | ++ |
| 4164 | ++ |
| 4165 | ++Rosenberg, et. al. Standards Track [Page 67] |
| 4166 | ++ |
| 4167 | |
| 4168 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4169 | ++ |
| 4170 | ++ |
| 4171 | ++11.2 Processing of OPTIONS Request |
| 4172 | ++ |
| 4173 | ++ The response to an OPTIONS is constructed using the standard rules |
| 4174 | ++ for a SIP response as discussed in Section 8.2.6. The response code |
| 4175 | ++ chosen MUST be the same that would have been chosen had the request |
| 4176 | ++ been an INVITE. That is, a 200 (OK) would be returned if the UAS is |
| 4177 | ++ ready to accept a call, a 486 (Busy Here) would be returned if the |
| 4178 | ++ UAS is busy, etc. This allows an OPTIONS request to be used to |
| 4179 | ++ determine the basic state of a UAS, which can be an indication of |
| 4180 | ++ whether the UAS will accept an INVITE request. |
| 4181 | ++ |
| 4182 | ++ An OPTIONS request received within a dialog generates a 200 (OK) |
| 4183 | ++ response that is identical to one constructed outside a dialog and |
| 4184 | ++ does not have any impact on the dialog. |
| 4185 | ++ |
| 4186 | ++ This use of OPTIONS has limitations due to the differences in proxy |
| 4187 | ++ handling of OPTIONS and INVITE requests. While a forked INVITE can |
| 4188 | ++ result in multiple 200 (OK) responses being returned, a forked |
| 4189 | ++ OPTIONS will only result in a single 200 (OK) response, since it is |
| 4190 | ++ treated by proxies using the non-INVITE handling. See Section 16.7 |
| 4191 | ++ for the normative details. |
| 4192 | ++ |
| 4193 | ++ If the response to an OPTIONS is generated by a proxy server, the |
| 4194 | ++ proxy returns a 200 (OK), listing the capabilities of the server. |
| 4195 | ++ The response does not contain a message body. |
| 4196 | ++ |
| 4197 | ++ Allow, Accept, Accept-Encoding, Accept-Language, and Supported header |
| 4198 | ++ fields SHOULD be present in a 200 (OK) response to an OPTIONS |
| 4199 | ++ request. If the response is generated by a proxy, the Allow header |
| 4200 | ++ field SHOULD be omitted as it is ambiguous since a proxy is method |
| 4201 | ++ agnostic. Contact header fields MAY be present in a 200 (OK) |
| 4202 | ++ response and have the same semantics as in a 3xx response. That is, |
| 4203 | ++ they may list a set of alternative names and methods of reaching the |
| 4204 | ++ user. A Warning header field MAY be present. |
| 4205 | ++ |
| 4206 | ++ A message body MAY be sent, the type of which is determined by the |
| 4207 | ++ Accept header field in the OPTIONS request (application/sdp is the |
| 4208 | ++ default if the Accept header field is not present). If the types |
| 4209 | ++ include one that can describe media capabilities, the UAS SHOULD |
| 4210 | ++ include a body in the response for that purpose. Details on the |
| 4211 | ++ construction of such a body in the case of application/sdp are |
| 4212 | ++ described in [13]. |
| 4213 | ++ |
| 4214 | ++ |
| 4215 | ++ |
| 4216 | ++ |
| 4217 | ++ |
| 4218 | ++ |
| 4219 | ++ |
| 4220 | ++ |
| 4221 | ++ |
| 4222 | ++Rosenberg, et. al. Standards Track [Page 68] |
| 4223 | ++ |
| 4224 | |
| 4225 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4226 | ++ |
| 4227 | ++ |
| 4228 | ++ Example OPTIONS response generated by a UAS (corresponding to the |
| 4229 | ++ request in Section 11.1): |
| 4230 | ++ |
| 4231 | ++ SIP/2.0 200 OK |
| 4232 | ++ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 |
| 4233 | ++ ;received=192.0.2.4 |
| 4234 | ++ To: <sip:carol@chicago.com>;tag=93810874 |
| 4235 | ++ From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
| 4236 | ++ Call-ID: a84b4c76e66710 |
| 4237 | ++ CSeq: 63104 OPTIONS |
| 4238 | ++ Contact: <sip:carol@chicago.com> |
| 4239 | ++ Contact: <mailto:carol@chicago.com> |
| 4240 | ++ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE |
| 4241 | ++ Accept: application/sdp |
| 4242 | ++ Accept-Encoding: gzip |
| 4243 | ++ Accept-Language: en |
| 4244 | ++ Supported: foo |
| 4245 | ++ Content-Type: application/sdp |
| 4246 | ++ Content-Length: 274 |
| 4247 | ++ |
| 4248 | ++ (SDP not shown) |
| 4249 | ++ |
| 4250 | ++12 Dialogs |
| 4251 | ++ |
| 4252 | ++ A key concept for a user agent is that of a dialog. A dialog |
| 4253 | ++ represents a peer-to-peer SIP relationship between two user agents |
| 4254 | ++ that persists for some time. The dialog facilitates sequencing of |
| 4255 | ++ messages between the user agents and proper routing of requests |
| 4256 | ++ between both of them. The dialog represents a context in which to |
| 4257 | ++ interpret SIP messages. Section 8 discussed method independent UA |
| 4258 | ++ processing for requests and responses outside of a dialog. This |
| 4259 | ++ section discusses how those requests and responses are used to |
| 4260 | ++ construct a dialog, and then how subsequent requests and responses |
| 4261 | ++ are sent within a dialog. |
| 4262 | ++ |
| 4263 | ++ A dialog is identified at each UA with a dialog ID, which consists of |
| 4264 | ++ a Call-ID value, a local tag and a remote tag. The dialog ID at each |
| 4265 | ++ UA involved in the dialog is not the same. Specifically, the local |
| 4266 | ++ tag at one UA is identical to the remote tag at the peer UA. The |
| 4267 | ++ tags are opaque tokens that facilitate the generation of unique |
| 4268 | ++ dialog IDs. |
| 4269 | ++ |
| 4270 | ++ A dialog ID is also associated with all responses and with any |
| 4271 | ++ request that contains a tag in the To field. The rules for computing |
| 4272 | ++ the dialog ID of a message depend on whether the SIP element is a UAC |
| 4273 | ++ or UAS. For a UAC, the Call-ID value of the dialog ID is set to the |
| 4274 | ++ Call-ID of the message, the remote tag is set to the tag in the To |
| 4275 | ++ field of the message, and the local tag is set to the tag in the From |
| 4276 | ++ |
| 4277 | ++ |
| 4278 | ++ |
| 4279 | ++Rosenberg, et. al. Standards Track [Page 69] |
| 4280 | ++ |
| 4281 | |
| 4282 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4283 | ++ |
| 4284 | ++ |
| 4285 | ++ field of the message (these rules apply to both requests and |
| 4286 | ++ responses). As one would expect for a UAS, the Call-ID value of the |
| 4287 | ++ dialog ID is set to the Call-ID of the message, the remote tag is set |
| 4288 | ++ to the tag in the From field of the message, and the local tag is set |
| 4289 | ++ to the tag in the To field of the message. |
| 4290 | ++ |
| 4291 | ++ A dialog contains certain pieces of state needed for further message |
| 4292 | ++ transmissions within the dialog. This state consists of the dialog |
| 4293 | ++ ID, a local sequence number (used to order requests from the UA to |
| 4294 | ++ its peer), a remote sequence number (used to order requests from its |
| 4295 | ++ peer to the UA), a local URI, a remote URI, remote target, a boolean |
| 4296 | ++ flag called "secure", and a route set, which is an ordered list of |
| 4297 | ++ URIs. The route set is the list of servers that need to be traversed |
| 4298 | ++ to send a request to the peer. A dialog can also be in the "early" |
| 4299 | ++ state, which occurs when it is created with a provisional response, |
| 4300 | ++ and then transition to the "confirmed" state when a 2xx final |
| 4301 | ++ response arrives. For other responses, or if no response arrives at |
| 4302 | ++ all on that dialog, the early dialog terminates. |
| 4303 | ++ |
| 4304 | ++12.1 Creation of a Dialog |
| 4305 | ++ |
| 4306 | ++ Dialogs are created through the generation of non-failure responses |
| 4307 | ++ to requests with specific methods. Within this specification, only |
| 4308 | ++ 2xx and 101-199 responses with a To tag, where the request was |
| 4309 | ++ INVITE, will establish a dialog. A dialog established by a non-final |
| 4310 | ++ response to a request is in the "early" state and it is called an |
| 4311 | ++ early dialog. Extensions MAY define other means for creating |
| 4312 | ++ dialogs. Section 13 gives more details that are specific to the |
| 4313 | ++ INVITE method. Here, we describe the process for creation of dialog |
| 4314 | ++ state that is not dependent on the method. |
| 4315 | ++ |
| 4316 | ++ UAs MUST assign values to the dialog ID components as described |
| 4317 | ++ below. |
| 4318 | ++ |
| 4319 | ++12.1.1 UAS behavior |
| 4320 | ++ |
| 4321 | ++ When a UAS responds to a request with a response that establishes a |
| 4322 | ++ dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route |
| 4323 | ++ header field values from the request into the response (including the |
| 4324 | ++ URIs, URI parameters, and any Record-Route header field parameters, |
| 4325 | ++ whether they are known or unknown to the UAS) and MUST maintain the |
| 4326 | ++ order of those values. The UAS MUST add a Contact header field to |
| 4327 | ++ the response. The Contact header field contains an address where the |
| 4328 | ++ UAS would like to be contacted for subsequent requests in the dialog |
| 4329 | ++ (which includes the ACK for a 2xx response in the case of an INVITE). |
| 4330 | ++ Generally, the host portion of this URI is the IP address or FQDN of |
| 4331 | ++ the host. The URI provided in the Contact header field MUST be a SIP |
| 4332 | ++ or SIPS URI. If the request that initiated the dialog contained a |
| 4333 | ++ |
| 4334 | ++ |
| 4335 | ++ |
| 4336 | ++Rosenberg, et. al. Standards Track [Page 70] |
| 4337 | ++ |
| 4338 | |
| 4339 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4340 | ++ |
| 4341 | ++ |
| 4342 | ++ SIPS URI in the Request-URI or in the top Record-Route header field |
| 4343 | ++ value, if there was any, or the Contact header field if there was no |
| 4344 | ++ Record-Route header field, the Contact header field in the response |
| 4345 | ++ MUST be a SIPS URI. The URI SHOULD have global scope (that is, the |
| 4346 | ++ same URI can be used in messages outside this dialog). The same way, |
| 4347 | ++ the scope of the URI in the Contact header field of the INVITE is not |
| 4348 | ++ limited to this dialog either. It can therefore be used in messages |
| 4349 | ++ to the UAC even outside this dialog. |
| 4350 | ++ |
| 4351 | ++ The UAS then constructs the state of the dialog. This state MUST be |
| 4352 | ++ maintained for the duration of the dialog. |
| 4353 | ++ |
| 4354 | ++ If the request arrived over TLS, and the Request-URI contained a SIPS |
| 4355 | ++ URI, the "secure" flag is set to TRUE. |
| 4356 | ++ |
| 4357 | ++ The route set MUST be set to the list of URIs in the Record-Route |
| 4358 | ++ header field from the request, taken in order and preserving all URI |
| 4359 | ++ parameters. If no Record-Route header field is present in the |
| 4360 | ++ request, the route set MUST be set to the empty set. This route set, |
| 4361 | ++ even if empty, overrides any pre-existing route set for future |
| 4362 | ++ requests in this dialog. The remote target MUST be set to the URI |
| 4363 | ++ from the Contact header field of the request. |
| 4364 | ++ |
| 4365 | ++ The remote sequence number MUST be set to the value of the sequence |
| 4366 | ++ number in the CSeq header field of the request. The local sequence |
| 4367 | ++ number MUST be empty. The call identifier component of the dialog ID |
| 4368 | ++ MUST be set to the value of the Call-ID in the request. The local |
| 4369 | ++ tag component of the dialog ID MUST be set to the tag in the To field |
| 4370 | ++ in the response to the request (which always includes a tag), and the |
| 4371 | ++ remote tag component of the dialog ID MUST be set to the tag from the |
| 4372 | ++ From field in the request. A UAS MUST be prepared to receive a |
| 4373 | ++ request without a tag in the From field, in which case the tag is |
| 4374 | ++ considered to have a value of null. |
| 4375 | ++ |
| 4376 | ++ This is to maintain backwards compatibility with RFC 2543, which |
| 4377 | ++ did not mandate From tags. |
| 4378 | ++ |
| 4379 | ++ The remote URI MUST be set to the URI in the From field, and the |
| 4380 | ++ local URI MUST be set to the URI in the To field. |
| 4381 | ++ |
| 4382 | ++12.1.2 UAC Behavior |
| 4383 | ++ |
| 4384 | ++ When a UAC sends a request that can establish a dialog (such as an |
| 4385 | ++ INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., |
| 4386 | ++ the same SIP URI can be used in messages outside this dialog) in the |
| 4387 | ++ Contact header field of the request. If the request has a Request- |
| 4388 | ++ URI or a topmost Route header field value with a SIPS URI, the |
| 4389 | ++ Contact header field MUST contain a SIPS URI. |
| 4390 | ++ |
| 4391 | ++ |
| 4392 | ++ |
| 4393 | ++Rosenberg, et. al. Standards Track [Page 71] |
| 4394 | ++ |
| 4395 | |
| 4396 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4397 | ++ |
| 4398 | ++ |
| 4399 | ++ When a UAC receives a response that establishes a dialog, it |
| 4400 | ++ constructs the state of the dialog. This state MUST be maintained |
| 4401 | ++ for the duration of the dialog. |
| 4402 | ++ |
| 4403 | ++ If the request was sent over TLS, and the Request-URI contained a |
| 4404 | ++ SIPS URI, the "secure" flag is set to TRUE. |
| 4405 | ++ |
| 4406 | ++ The route set MUST be set to the list of URIs in the Record-Route |
| 4407 | ++ header field from the response, taken in reverse order and preserving |
| 4408 | ++ all URI parameters. If no Record-Route header field is present in |
| 4409 | ++ the response, the route set MUST be set to the empty set. This route |
| 4410 | ++ set, even if empty, overrides any pre-existing route set for future |
| 4411 | ++ requests in this dialog. The remote target MUST be set to the URI |
| 4412 | ++ from the Contact header field of the response. |
| 4413 | ++ |
| 4414 | ++ The local sequence number MUST be set to the value of the sequence |
| 4415 | ++ number in the CSeq header field of the request. The remote sequence |
| 4416 | ++ number MUST be empty (it is established when the remote UA sends a |
| 4417 | ++ request within the dialog). The call identifier component of the |
| 4418 | ++ dialog ID MUST be set to the value of the Call-ID in the request. |
| 4419 | ++ The local tag component of the dialog ID MUST be set to the tag in |
| 4420 | ++ the From field in the request, and the remote tag component of the |
| 4421 | ++ dialog ID MUST be set to the tag in the To field of the response. A |
| 4422 | ++ UAC MUST be prepared to receive a response without a tag in the To |
| 4423 | ++ field, in which case the tag is considered to have a value of null. |
| 4424 | ++ |
| 4425 | ++ This is to maintain backwards compatibility with RFC 2543, which |
| 4426 | ++ did not mandate To tags. |
| 4427 | ++ |
| 4428 | ++ The remote URI MUST be set to the URI in the To field, and the local |
| 4429 | ++ URI MUST be set to the URI in the From field. |
| 4430 | ++ |
| 4431 | ++12.2 Requests within a Dialog |
| 4432 | ++ |
| 4433 | ++ Once a dialog has been established between two UAs, either of them |
| 4434 | ++ MAY initiate new transactions as needed within the dialog. The UA |
| 4435 | ++ sending the request will take the UAC role for the transaction. The |
| 4436 | ++ UA receiving the request will take the UAS role. Note that these may |
| 4437 | ++ be different roles than the UAs held during the transaction that |
| 4438 | ++ established the dialog. |
| 4439 | ++ |
| 4440 | ++ Requests within a dialog MAY contain Record-Route and Contact header |
| 4441 | ++ fields. However, these requests do not cause the dialog's route set |
| 4442 | ++ to be modified, although they may modify the remote target URI. |
| 4443 | ++ Specifically, requests that are not target refresh requests do not |
| 4444 | ++ modify the dialog's remote target URI, and requests that are target |
| 4445 | ++ refresh requests do. For dialogs that have been established with an |
| 4446 | ++ |
| 4447 | ++ |
| 4448 | ++ |
| 4449 | ++ |
| 4450 | ++Rosenberg, et. al. Standards Track [Page 72] |
| 4451 | ++ |
| 4452 | |
| 4453 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4454 | ++ |
| 4455 | ++ |
| 4456 | ++ INVITE, the only target refresh request defined is re-INVITE (see |
| 4457 | ++ Section 14). Other extensions may define different target refresh |
| 4458 | ++ requests for dialogs established in other ways. |
| 4459 | ++ |
| 4460 | ++ Note that an ACK is NOT a target refresh request. |
| 4461 | ++ |
| 4462 | ++ Target refresh requests only update the dialog's remote target URI, |
| 4463 | ++ and not the route set formed from the Record-Route. Updating the |
| 4464 | ++ latter would introduce severe backwards compatibility problems with |
| 4465 | ++ RFC 2543-compliant systems. |
| 4466 | ++ |
| 4467 | ++12.2.1 UAC Behavior |
| 4468 | ++ |
| 4469 | ++12.2.1.1 Generating the Request |
| 4470 | ++ |
| 4471 | ++ A request within a dialog is constructed by using many of the |
| 4472 | ++ components of the state stored as part of the dialog. |
| 4473 | ++ |
| 4474 | ++ The URI in the To field of the request MUST be set to the remote URI |
| 4475 | ++ from the dialog state. The tag in the To header field of the request |
| 4476 | ++ MUST be set to the remote tag of the dialog ID. The From URI of the |
| 4477 | ++ request MUST be set to the local URI from the dialog state. The tag |
| 4478 | ++ in the From header field of the request MUST be set to the local tag |
| 4479 | ++ of the dialog ID. If the value of the remote or local tags is null, |
| 4480 | ++ the tag parameter MUST be omitted from the To or From header fields, |
| 4481 | ++ respectively. |
| 4482 | ++ |
| 4483 | ++ Usage of the URI from the To and From fields in the original |
| 4484 | ++ request within subsequent requests is done for backwards |
| 4485 | ++ compatibility with RFC 2543, which used the URI for dialog |
| 4486 | ++ identification. In this specification, only the tags are used for |
| 4487 | ++ dialog identification. It is expected that mandatory reflection |
| 4488 | ++ of the original To and From URI in mid-dialog requests will be |
| 4489 | ++ deprecated in a subsequent revision of this specification. |
| 4490 | ++ |
| 4491 | ++ The Call-ID of the request MUST be set to the Call-ID of the dialog. |
| 4492 | ++ Requests within a dialog MUST contain strictly monotonically |
| 4493 | ++ increasing and contiguous CSeq sequence numbers (increasing-by-one) |
| 4494 | ++ in each direction (excepting ACK and CANCEL of course, whose numbers |
| 4495 | ++ equal the requests being acknowledged or cancelled). Therefore, if |
| 4496 | ++ the local sequence number is not empty, the value of the local |
| 4497 | ++ sequence number MUST be incremented by one, and this value MUST be |
| 4498 | ++ placed into the CSeq header field. If the local sequence number is |
| 4499 | ++ empty, an initial value MUST be chosen using the guidelines of |
| 4500 | ++ Section 8.1.1.5. The method field in the CSeq header field value |
| 4501 | ++ MUST match the method of the request. |
| 4502 | ++ |
| 4503 | ++ |
| 4504 | ++ |
| 4505 | ++ |
| 4506 | ++ |
| 4507 | ++Rosenberg, et. al. Standards Track [Page 73] |
| 4508 | ++ |
| 4509 | |
| 4510 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4511 | ++ |
| 4512 | ++ |
| 4513 | ++ With a length of 32 bits, a client could generate, within a single |
| 4514 | ++ call, one request a second for about 136 years before needing to |
| 4515 | ++ wrap around. The initial value of the sequence number is chosen |
| 4516 | ++ so that subsequent requests within the same call will not wrap |
| 4517 | ++ around. A non-zero initial value allows clients to use a time- |
| 4518 | ++ based initial sequence number. A client could, for example, |
| 4519 | ++ choose the 31 most significant bits of a 32-bit second clock as an |
| 4520 | ++ initial sequence number. |
| 4521 | ++ |
| 4522 | ++ The UAC uses the remote target and route set to build the Request-URI |
| 4523 | ++ and Route header field of the request. |
| 4524 | ++ |
| 4525 | ++ If the route set is empty, the UAC MUST place the remote target URI |
| 4526 | ++ into the Request-URI. The UAC MUST NOT add a Route header field to |
| 4527 | ++ the request. |
| 4528 | ++ |
| 4529 | ++ If the route set is not empty, and the first URI in the route set |
| 4530 | ++ contains the lr parameter (see Section 19.1.1), the UAC MUST place |
| 4531 | ++ the remote target URI into the Request-URI and MUST include a Route |
| 4532 | ++ header field containing the route set values in order, including all |
| 4533 | ++ parameters. |
| 4534 | ++ |
| 4535 | ++ If the route set is not empty, and its first URI does not contain the |
| 4536 | ++ lr parameter, the UAC MUST place the first URI from the route set |
| 4537 | ++ into the Request-URI, stripping any parameters that are not allowed |
| 4538 | ++ in a Request-URI. The UAC MUST add a Route header field containing |
| 4539 | ++ the remainder of the route set values in order, including all |
| 4540 | ++ parameters. The UAC MUST then place the remote target URI into the |
| 4541 | ++ Route header field as the last value. |
| 4542 | ++ |
| 4543 | ++ For example, if the remote target is sip:user@remoteua and the route |
| 4544 | ++ set contains: |
| 4545 | ++ |
| 4546 | ++ <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> |
| 4547 | ++ |
| 4548 | ++ The request will be formed with the following Request-URI and Route |
| 4549 | ++ header field: |
| 4550 | ++ |
| 4551 | ++ METHOD sip:proxy1 |
| 4552 | ++ Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> |
| 4553 | ++ |
| 4554 | ++ If the first URI of the route set does not contain the lr |
| 4555 | ++ parameter, the proxy indicated does not understand the routing |
| 4556 | ++ mechanisms described in this document and will act as specified in |
| 4557 | ++ RFC 2543, replacing the Request-URI with the first Route header |
| 4558 | ++ field value it receives while forwarding the message. Placing the |
| 4559 | ++ Request-URI at the end of the Route header field preserves the |
| 4560 | ++ |
| 4561 | ++ |
| 4562 | ++ |
| 4563 | ++ |
| 4564 | ++Rosenberg, et. al. Standards Track [Page 74] |
| 4565 | ++ |
| 4566 | |
| 4567 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4568 | ++ |
| 4569 | ++ |
| 4570 | ++ information in that Request-URI across the strict router (it will |
| 4571 | ++ be returned to the Request-URI when the request reaches a loose- |
| 4572 | ++ router). |
| 4573 | ++ |
| 4574 | ++ A UAC SHOULD include a Contact header field in any target refresh |
| 4575 | ++ requests within a dialog, and unless there is a need to change it, |
| 4576 | ++ the URI SHOULD be the same as used in previous requests within the |
| 4577 | ++ dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. |
| 4578 | ++ As discussed in Section 12.2.2, a Contact header field in a target |
| 4579 | ++ refresh request updates the remote target URI. This allows a UA to |
| 4580 | ++ provide a new contact address, should its address change during the |
| 4581 | ++ duration of the dialog. |
| 4582 | ++ |
| 4583 | ++ However, requests that are not target refresh requests do not affect |
| 4584 | ++ the remote target URI for the dialog. |
| 4585 | ++ |
| 4586 | ++ The rest of the request is formed as described in Section 8.1.1. |
| 4587 | ++ |
| 4588 | ++ Once the request has been constructed, the address of the server is |
| 4589 | ++ computed and the request is sent, using the same procedures for |
| 4590 | ++ requests outside of a dialog (Section 8.1.2). |
| 4591 | ++ |
| 4592 | ++ The procedures in Section 8.1.2 will normally result in the |
| 4593 | ++ request being sent to the address indicated by the topmost Route |
| 4594 | ++ header field value or the Request-URI if no Route header field is |
| 4595 | ++ present. Subject to certain restrictions, they allow the request |
| 4596 | ++ to be sent to an alternate address (such as a default outbound |
| 4597 | ++ proxy not represented in the route set). |
| 4598 | ++ |
| 4599 | ++12.2.1.2 Processing the Responses |
| 4600 | ++ |
| 4601 | ++ The UAC will receive responses to the request from the transaction |
| 4602 | ++ layer. If the client transaction returns a timeout, this is treated |
| 4603 | ++ as a 408 (Request Timeout) response. |
| 4604 | ++ |
| 4605 | ++ The behavior of a UAC that receives a 3xx response for a request sent |
| 4606 | ++ within a dialog is the same as if the request had been sent outside a |
| 4607 | ++ dialog. This behavior is described in Section 8.1.3.4. |
| 4608 | ++ |
| 4609 | ++ Note, however, that when the UAC tries alternative locations, it |
| 4610 | ++ still uses the route set for the dialog to build the Route header |
| 4611 | ++ of the request. |
| 4612 | ++ |
| 4613 | ++ When a UAC receives a 2xx response to a target refresh request, it |
| 4614 | ++ MUST replace the dialog's remote target URI with the URI from the |
| 4615 | ++ Contact header field in that response, if present. |
| 4616 | ++ |
| 4617 | ++ |
| 4618 | ++ |
| 4619 | ++ |
| 4620 | ++ |
| 4621 | ++Rosenberg, et. al. Standards Track [Page 75] |
| 4622 | ++ |
| 4623 | |
| 4624 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4625 | ++ |
| 4626 | ++ |
| 4627 | ++ If the response for a request within a dialog is a 481 |
| 4628 | ++ (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC |
| 4629 | ++ SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if |
| 4630 | ++ no response at all is received for the request (the client |
| 4631 | ++ transaction would inform the TU about the timeout.) |
| 4632 | ++ |
| 4633 | ++ For INVITE initiated dialogs, terminating the dialog consists of |
| 4634 | ++ sending a BYE. |
| 4635 | ++ |
| 4636 | ++12.2.2 UAS Behavior |
| 4637 | ++ |
| 4638 | ++ Requests sent within a dialog, as any other requests, are atomic. If |
| 4639 | ++ a particular request is accepted by the UAS, all the state changes |
| 4640 | ++ associated with it are performed. If the request is rejected, none |
| 4641 | ++ of the state changes are performed. |
| 4642 | ++ |
| 4643 | ++ Note that some requests, such as INVITEs, affect several pieces of |
| 4644 | ++ state. |
| 4645 | ++ |
| 4646 | ++ The UAS will receive the request from the transaction layer. If the |
| 4647 | ++ request has a tag in the To header field, the UAS core computes the |
| 4648 | ++ dialog identifier corresponding to the request and compares it with |
| 4649 | ++ existing dialogs. If there is a match, this is a mid-dialog request. |
| 4650 | ++ In that case, the UAS first applies the same processing rules for |
| 4651 | ++ requests outside of a dialog, discussed in Section 8.2. |
| 4652 | ++ |
| 4653 | ++ If the request has a tag in the To header field, but the dialog |
| 4654 | ++ identifier does not match any existing dialogs, the UAS may have |
| 4655 | ++ crashed and restarted, or it may have received a request for a |
| 4656 | ++ different (possibly failed) UAS (the UASs can construct the To tags |
| 4657 | ++ so that a UAS can identify that the tag was for a UAS for which it is |
| 4658 | ++ providing recovery). Another possibility is that the incoming |
| 4659 | ++ request has been simply misrouted. Based on the To tag, the UAS MAY |
| 4660 | ++ either accept or reject the request. Accepting the request for |
| 4661 | ++ acceptable To tags provides robustness, so that dialogs can persist |
| 4662 | ++ even through crashes. UAs wishing to support this capability must |
| 4663 | ++ take into consideration some issues such as choosing monotonically |
| 4664 | ++ increasing CSeq sequence numbers even across reboots, reconstructing |
| 4665 | ++ the route set, and accepting out-of-range RTP timestamps and sequence |
| 4666 | ++ numbers. |
| 4667 | ++ |
| 4668 | ++ If the UAS wishes to reject the request because it does not wish to |
| 4669 | ++ recreate the dialog, it MUST respond to the request with a 481 |
| 4670 | ++ (Call/Transaction Does Not Exist) status code and pass that to the |
| 4671 | ++ server transaction. |
| 4672 | ++ |
| 4673 | ++ |
| 4674 | ++ |
| 4675 | ++ |
| 4676 | ++ |
| 4677 | ++ |
| 4678 | ++Rosenberg, et. al. Standards Track [Page 76] |
| 4679 | ++ |
| 4680 | |
| 4681 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4682 | ++ |
| 4683 | ++ |
| 4684 | ++ Requests that do not change in any way the state of a dialog may be |
| 4685 | ++ received within a dialog (for example, an OPTIONS request). They are |
| 4686 | ++ processed as if they had been received outside the dialog. |
| 4687 | ++ |
| 4688 | ++ If the remote sequence number is empty, it MUST be set to the value |
| 4689 | ++ of the sequence number in the CSeq header field value in the request. |
| 4690 | ++ If the remote sequence number was not empty, but the sequence number |
| 4691 | ++ of the request is lower than the remote sequence number, the request |
| 4692 | ++ is out of order and MUST be rejected with a 500 (Server Internal |
| 4693 | ++ Error) response. If the remote sequence number was not empty, and |
| 4694 | ++ the sequence number of the request is greater than the remote |
| 4695 | ++ sequence number, the request is in order. It is possible for the |
| 4696 | ++ CSeq sequence number to be higher than the remote sequence number by |
| 4697 | ++ more than one. This is not an error condition, and a UAS SHOULD be |
| 4698 | ++ prepared to receive and process requests with CSeq values more than |
| 4699 | ++ one higher than the previous received request. The UAS MUST then set |
| 4700 | ++ the remote sequence number to the value of the sequence number in the |
| 4701 | ++ CSeq header field value in the request. |
| 4702 | ++ |
| 4703 | ++ If a proxy challenges a request generated by the UAC, the UAC has |
| 4704 | ++ to resubmit the request with credentials. The resubmitted request |
| 4705 | ++ will have a new CSeq number. The UAS will never see the first |
| 4706 | ++ request, and thus, it will notice a gap in the CSeq number space. |
| 4707 | ++ Such a gap does not represent any error condition. |
| 4708 | ++ |
| 4709 | ++ When a UAS receives a target refresh request, it MUST replace the |
| 4710 | ++ dialog's remote target URI with the URI from the Contact header field |
| 4711 | ++ in that request, if present. |
| 4712 | ++ |
| 4713 | ++12.3 Termination of a Dialog |
| 4714 | ++ |
| 4715 | ++ Independent of the method, if a request outside of a dialog generates |
| 4716 | ++ a non-2xx final response, any early dialogs created through |
| 4717 | ++ provisional responses to that request are terminated. The mechanism |
| 4718 | ++ for terminating confirmed dialogs is method specific. In this |
| 4719 | ++ specification, the BYE method terminates a session and the dialog |
| 4720 | ++ associated with it. See Section 15 for details. |
| 4721 | ++ |
| 4722 | ++13 Initiating a Session |
| 4723 | ++ |
| 4724 | ++13.1 Overview |
| 4725 | ++ |
| 4726 | ++ When a user agent client desires to initiate a session (for example, |
| 4727 | ++ audio, video, or a game), it formulates an INVITE request. The |
| 4728 | ++ INVITE request asks a server to establish a session. This request |
| 4729 | ++ may be forwarded by proxies, eventually arriving at one or more UAS |
| 4730 | ++ that can potentially accept the invitation. These UASs will |
| 4731 | ++ frequently need to query the user about whether to accept the |
| 4732 | ++ |
| 4733 | ++ |
| 4734 | ++ |
| 4735 | ++Rosenberg, et. al. Standards Track [Page 77] |
| 4736 | ++ |
| 4737 | |
| 4738 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4739 | ++ |
| 4740 | ++ |
| 4741 | ++ invitation. After some time, those UASs can accept the invitation |
| 4742 | ++ (meaning the session is to be established) by sending a 2xx response. |
| 4743 | ++ If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is |
| 4744 | ++ sent, depending on the reason for the rejection. Before sending a |
| 4745 | ++ final response, the UAS can also send provisional responses (1xx) to |
| 4746 | ++ advise the UAC of progress in contacting the called user. |
| 4747 | ++ |
| 4748 | ++ After possibly receiving one or more provisional responses, the UAC |
| 4749 | ++ will get one or more 2xx responses or one non-2xx final response. |
| 4750 | ++ Because of the protracted amount of time it can take to receive final |
| 4751 | ++ responses to INVITE, the reliability mechanisms for INVITE |
| 4752 | ++ transactions differ from those of other requests (like OPTIONS). |
| 4753 | ++ Once it receives a final response, the UAC needs to send an ACK for |
| 4754 | ++ every final response it receives. The procedure for sending this ACK |
| 4755 | ++ depends on the type of response. For final responses between 300 and |
| 4756 | ++ 699, the ACK processing is done in the transaction layer and follows |
| 4757 | ++ one set of rules (See Section 17). For 2xx responses, the ACK is |
| 4758 | ++ generated by the UAC core. |
| 4759 | ++ |
| 4760 | ++ A 2xx response to an INVITE establishes a session, and it also |
| 4761 | ++ creates a dialog between the UA that issued the INVITE and the UA |
| 4762 | ++ that generated the 2xx response. Therefore, when multiple 2xx |
| 4763 | ++ responses are received from different remote UAs (because the INVITE |
| 4764 | ++ forked), each 2xx establishes a different dialog. All these dialogs |
| 4765 | ++ are part of the same call. |
| 4766 | ++ |
| 4767 | ++ This section provides details on the establishment of a session using |
| 4768 | ++ INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and |
| 4769 | ++ BYE. |
| 4770 | ++ |
| 4771 | ++13.2 UAC Processing |
| 4772 | ++ |
| 4773 | ++13.2.1 Creating the Initial INVITE |
| 4774 | ++ |
| 4775 | ++ Since the initial INVITE represents a request outside of a dialog, |
| 4776 | ++ its construction follows the procedures of Section 8.1.1. Additional |
| 4777 | ++ processing is required for the specific case of INVITE. |
| 4778 | ++ |
| 4779 | ++ An Allow header field (Section 20.5) SHOULD be present in the INVITE. |
| 4780 | ++ It indicates what methods can be invoked within a dialog, on the UA |
| 4781 | ++ sending the INVITE, for the duration of the dialog. For example, a |
| 4782 | ++ UA capable of receiving INFO requests within a dialog [34] SHOULD |
| 4783 | ++ include an Allow header field listing the INFO method. |
| 4784 | ++ |
| 4785 | ++ A Supported header field (Section 20.37) SHOULD be present in the |
| 4786 | ++ INVITE. It enumerates all the extensions understood by the UAC. |
| 4787 | ++ |
| 4788 | ++ |
| 4789 | ++ |
| 4790 | ++ |
| 4791 | ++ |
| 4792 | ++Rosenberg, et. al. Standards Track [Page 78] |
| 4793 | ++ |
| 4794 | |
| 4795 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4796 | ++ |
| 4797 | ++ |
| 4798 | ++ An Accept (Section 20.1) header field MAY be present in the INVITE. |
| 4799 | ++ It indicates which Content-Types are acceptable to the UA, in both |
| 4800 | ++ the response received by it, and in any subsequent requests sent to |
| 4801 | ++ it within dialogs established by the INVITE. The Accept header field |
| 4802 | ++ is especially useful for indicating support of various session |
| 4803 | ++ description formats. |
| 4804 | ++ |
| 4805 | ++ The UAC MAY add an Expires header field (Section 20.19) to limit the |
| 4806 | ++ validity of the invitation. If the time indicated in the Expires |
| 4807 | ++ header field is reached and no final answer for the INVITE has been |
| 4808 | ++ received, the UAC core SHOULD generate a CANCEL request for the |
| 4809 | ++ INVITE, as per Section 9. |
| 4810 | ++ |
| 4811 | ++ A UAC MAY also find it useful to add, among others, Subject (Section |
| 4812 | ++ 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) |
| 4813 | ++ header fields. They all contain information related to the INVITE. |
| 4814 | ++ |
| 4815 | ++ The UAC MAY choose to add a message body to the INVITE. Section |
| 4816 | ++ 8.1.1.10 deals with how to construct the header fields -- Content- |
| 4817 | ++ Type among others -- needed to describe the message body. |
| 4818 | ++ |
| 4819 | ++ There are special rules for message bodies that contain a session |
| 4820 | ++ description - their corresponding Content-Disposition is "session". |
| 4821 | ++ SIP uses an offer/answer model where one UA sends a session |
| 4822 | ++ description, called the offer, which contains a proposed description |
| 4823 | ++ of the session. The offer indicates the desired communications means |
| 4824 | ++ (audio, video, games), parameters of those means (such as codec |
| 4825 | ++ types) and addresses for receiving media from the answerer. The |
| 4826 | ++ other UA responds with another session description, called the |
| 4827 | ++ answer, which indicates which communications means are accepted, the |
| 4828 | ++ parameters that apply to those means, and addresses for receiving |
| 4829 | ++ media from the offerer. An offer/answer exchange is within the |
| 4830 | ++ context of a dialog, so that if a SIP INVITE results in multiple |
| 4831 | ++ dialogs, each is a separate offer/answer exchange. The offer/answer |
| 4832 | ++ model defines restrictions on when offers and answers can be made |
| 4833 | ++ (for example, you cannot make a new offer while one is in progress). |
| 4834 | ++ This results in restrictions on where the offers and answers can |
| 4835 | ++ appear in SIP messages. In this specification, offers and answers |
| 4836 | ++ can only appear in INVITE requests and responses, and ACK. The usage |
| 4837 | ++ of offers and answers is further restricted. For the initial INVITE |
| 4838 | ++ transaction, the rules are: |
| 4839 | ++ |
| 4840 | ++ o The initial offer MUST be in either an INVITE or, if not there, |
| 4841 | ++ in the first reliable non-failure message from the UAS back to |
| 4842 | ++ the UAC. In this specification, that is the final 2xx |
| 4843 | ++ response. |
| 4844 | ++ |
| 4845 | ++ |
| 4846 | ++ |
| 4847 | ++ |
| 4848 | ++ |
| 4849 | ++Rosenberg, et. al. Standards Track [Page 79] |
| 4850 | ++ |
| 4851 | |
| 4852 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4853 | ++ |
| 4854 | ++ |
| 4855 | ++ o If the initial offer is in an INVITE, the answer MUST be in a |
| 4856 | ++ reliable non-failure message from UAS back to UAC which is |
| 4857 | ++ correlated to that INVITE. For this specification, that is |
| 4858 | ++ only the final 2xx response to that INVITE. That same exact |
| 4859 | ++ answer MAY also be placed in any provisional responses sent |
| 4860 | ++ prior to the answer. The UAC MUST treat the first session |
| 4861 | ++ description it receives as the answer, and MUST ignore any |
| 4862 | ++ session descriptions in subsequent responses to the initial |
| 4863 | ++ INVITE. |
| 4864 | ++ |
| 4865 | ++ o If the initial offer is in the first reliable non-failure |
| 4866 | ++ message from the UAS back to UAC, the answer MUST be in the |
| 4867 | ++ acknowledgement for that message (in this specification, ACK |
| 4868 | ++ for a 2xx response). |
| 4869 | ++ |
| 4870 | ++ o After having sent or received an answer to the first offer, the |
| 4871 | ++ UAC MAY generate subsequent offers in requests based on rules |
| 4872 | ++ specified for that method, but only if it has received answers |
| 4873 | ++ to any previous offers, and has not sent any offers to which it |
| 4874 | ++ hasn't gotten an answer. |
| 4875 | ++ |
| 4876 | ++ o Once the UAS has sent or received an answer to the initial |
| 4877 | ++ offer, it MUST NOT generate subsequent offers in any responses |
| 4878 | ++ to the initial INVITE. This means that a UAS based on this |
| 4879 | ++ specification alone can never generate subsequent offers until |
| 4880 | ++ completion of the initial transaction. |
| 4881 | ++ |
| 4882 | ++ Concretely, the above rules specify two exchanges for UAs compliant |
| 4883 | ++ to this specification alone - the offer is in the INVITE, and the |
| 4884 | ++ answer in the 2xx (and possibly in a 1xx as well, with the same |
| 4885 | ++ value), or the offer is in the 2xx, and the answer is in the ACK. |
| 4886 | ++ All user agents that support INVITE MUST support these two exchanges. |
| 4887 | ++ |
| 4888 | ++ The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be |
| 4889 | ++ supported by all user agents as a means to describe sessions, and its |
| 4890 | ++ usage for constructing offers and answers MUST follow the procedures |
| 4891 | ++ defined in [13]. |
| 4892 | ++ |
| 4893 | ++ The restrictions of the offer-answer model just described only apply |
| 4894 | ++ to bodies whose Content-Disposition header field value is "session". |
| 4895 | ++ Therefore, it is possible that both the INVITE and the ACK contain a |
| 4896 | ++ body message (for example, the INVITE carries a photo (Content- |
| 4897 | ++ Disposition: render) and the ACK a session description (Content- |
| 4898 | ++ Disposition: session)). |
| 4899 | ++ |
| 4900 | ++ If the Content-Disposition header field is missing, bodies of |
| 4901 | ++ Content-Type application/sdp imply the disposition "session", while |
| 4902 | ++ other content types imply "render". |
| 4903 | ++ |
| 4904 | ++ |
| 4905 | ++ |
| 4906 | ++Rosenberg, et. al. Standards Track [Page 80] |
| 4907 | ++ |
| 4908 | |
| 4909 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4910 | ++ |
| 4911 | ++ |
| 4912 | ++ Once the INVITE has been created, the UAC follows the procedures |
| 4913 | ++ defined for sending requests outside of a dialog (Section 8). This |
| 4914 | ++ results in the construction of a client transaction that will |
| 4915 | ++ ultimately send the request and deliver responses to the UAC. |
| 4916 | ++ |
| 4917 | ++13.2.2 Processing INVITE Responses |
| 4918 | ++ |
| 4919 | ++ Once the INVITE has been passed to the INVITE client transaction, the |
| 4920 | ++ UAC waits for responses for the INVITE. If the INVITE client |
| 4921 | ++ transaction returns a timeout rather than a response the TU acts as |
| 4922 | ++ if a 408 (Request Timeout) response had been received, as described |
| 4923 | ++ in Section 8.1.3. |
| 4924 | ++ |
| 4925 | ++13.2.2.1 1xx Responses |
| 4926 | ++ |
| 4927 | ++ Zero, one or multiple provisional responses may arrive before one or |
| 4928 | ++ more final responses are received. Provisional responses for an |
| 4929 | ++ INVITE request can create "early dialogs". If a provisional response |
| 4930 | ++ has a tag in the To field, and if the dialog ID of the response does |
| 4931 | ++ not match an existing dialog, one is constructed using the procedures |
| 4932 | ++ defined in Section 12.1.2. |
| 4933 | ++ |
| 4934 | ++ The early dialog will only be needed if the UAC needs to send a |
| 4935 | ++ request to its peer within the dialog before the initial INVITE |
| 4936 | ++ transaction completes. Header fields present in a provisional |
| 4937 | ++ response are applicable as long as the dialog is in the early state |
| 4938 | ++ (for example, an Allow header field in a provisional response |
| 4939 | ++ contains the methods that can be used in the dialog while this is in |
| 4940 | ++ the early state). |
| 4941 | ++ |
| 4942 | ++13.2.2.2 3xx Responses |
| 4943 | ++ |
| 4944 | ++ A 3xx response may contain one or more Contact header field values |
| 4945 | ++ providing new addresses where the callee might be reachable. |
| 4946 | ++ Depending on the status code of the 3xx response (see Section 21.3), |
| 4947 | ++ the UAC MAY choose to try those new addresses. |
| 4948 | ++ |
| 4949 | ++13.2.2.3 4xx, 5xx and 6xx Responses |
| 4950 | ++ |
| 4951 | ++ A single non-2xx final response may be received for the INVITE. 4xx, |
| 4952 | ++ 5xx and 6xx responses may contain a Contact header field value |
| 4953 | ++ indicating the location where additional information about the error |
| 4954 | ++ can be found. Subsequent final responses (which would only arrive |
| 4955 | ++ under error conditions) MUST be ignored. |
| 4956 | ++ |
| 4957 | ++ All early dialogs are considered terminated upon reception of the |
| 4958 | ++ non-2xx final response. |
| 4959 | ++ |
| 4960 | ++ |
| 4961 | ++ |
| 4962 | ++ |
| 4963 | ++Rosenberg, et. al. Standards Track [Page 81] |
| 4964 | ++ |
| 4965 | |
| 4966 | ++RFC 3261 SIP: Session Initiation Protocol June 2002 |
| 4967 | ++ |
| 4968 | ++ |
| 4969 | ++ After having received the non-2xx final response the UAC core |
| 4970 | ++ considers the INVITE transaction completed. The INVITE client |
| 4971 | ++ transaction handles the generation of ACKs for the response (see |
| 4972 | ++ Section 17). |
| 4973 | ++ |
| 4974 | ++13.2.2.4 2xx Responses |
| 4975 | ++ |
| 4976 | ++ Multiple 2xx responses may arrive at the UAC for a single INVITE |
| 4977 | ++ request due to a forking proxy. Each response is distinguished by |
| 4978 | ++ the tag parameter in the To header field, and each represents a |
| 4979 | ++ distinct dialog, with a distinct dialog identifier. |
| 4980 | ++ |
| 4981 | ++ If the dialog identifier in the 2xx response matches the dialog |
| 4982 | ++ identifier of an existing dialog, the dialog MUST be transitioned to |
| 4983 | ++ the "confirmed" state, and the route set for the dialog MUST be |
| 4984 | ++ recomputed based on the 2xx response using the procedures of Section |
| 4985 | ++ 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be |
| 4986 | ++ constructed using the procedures of Section 12.1.2. |
| 4987 | ++ |
| 4988 | ++ Note that the only piece of state that is recomputed is the route |
| 4989 | ++ set. Other pieces of state such as the highest sequence numbers |
| 4990 | ++ (remote and local) sent within the dialog are not recomputed. The |
| 4991 | ++ route set only is recomputed for backwards compatibility. RFC |
| 4992 | ++ 2543 did not mandate mirroring of the Record-Route header field in |
| 4993 | ++ a 1xx, only 2xx. However, we cannot update the entire state of |
| 4994 | ++ the dialog, since mid-dialog requests may have been sent within |
| 4995 | ++ the early dialog, modifying the sequence numbers, for example. |
| 4996 | ++ |
| 4997 | ++ The UAC core MUST generate an ACK request for each 2xx received from |
| 4998 | ++ the transaction layer. The header fields of the ACK are constructed |
| 4999 | ++ in the same way as for any request sent within a dialog (see Section |
| 5000 | ++ 12) with the exception of the CSeq and the header fields related to |
The diff has been truncated for viewing.
I had to add /tests/
The the enable-tests.patch is in the ubuntu specific portion of debian/