19.1 SIP and SIPS Uniform Resource Indicators
A SIP or SIPS URI identifies a communications resource. Like all
URIs, SIP and SIPS URIs may be placed in web pages, email messages,
or printed literature. They contain sufficient information to
initiate and maintain a communication session with the resource.
Examples of communications resources include the following:
o a user of an online service
o an appearance on a multi-line phone
o a mailbox on a messaging system
o a PSTN number at a gateway service
o a group (such as "sales" or "helpdesk") in an organization
A SIPS URI specifies that the resource be contacted securely. This
means, in particular, that TLS is to be used between the UAC and the
domain that owns the URI. From there, secure communications are used
to reach the user, where the specific security mechanism depends on
the policy of the domain. Any resource described by a SIP URI can be
"upgraded" to a SIPS URI by just changing the scheme, if it is
desired to communicate with that resource securely.
19.1.1 SIP and SIPS URI Components
The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5].
They use a form similar to the mailto URL, allowing the specification
of SIP request-header fields and the SIP message-body. This makes it
possible to specify the subject, media type, or urgency of sessions
initiated by using a URI on a web page or in an email message. The
formal syntax for a SIP or SIPS URI is presented in Section 25. Its
general form, in the case of a SIP URI, is:
sip:user:password@host:port;uri-parameters?headers
The format for a SIPS URI is the same, except that the scheme is
"sips" instead of sip. These tokens, and some of the tokens in their
expansions, have the following meanings:
user: The identifier of a particular resource at the host being
addressed. The term "host" in this context frequently refers
to a domain. The "userinfo" of a URI consists of this user
field, the password field, and the @ sign following them. The
userinfo part of a URI is optional and MAY be absent when the
Rosenberg, et. al. Standards Track [Page 148]
RFC 3261 SIP: Session Initiation Protocol June 2002
destination host does not have a notion of users or when the
host itself is the resource being identified. If the @ sign is
present in a SIP or SIPS URI, the user field MUST NOT be empty.
If the host being addressed can process telephone numbers, for
instance, an Internet telephony gateway, a telephone-
subscriber field defined in RFC 2806 [9] MAY be used to
populate the user field. There are special escaping rules for
encoding telephone-subscriber fields in SIP and SIPS URIs
described in Section 19.1.2.
password: A password associated with the user. While the SIP and
SIPS URI syntax allows this field to be present, its use is NOT
RECOMMENDED, because the passing of authentication information
in clear text (such as URIs) has proven to be a security risk
in almost every case where it has been used. For instance,
transporting a PIN number in this field exposes the PIN.
Note that the password field is just an extension of the user
portion. Implementations not wishing to give special
significance to the password portion of the field MAY simply
treat "user:password" as a single string.
host: The host providing the SIP resource. The host part contains
either a fully-qualified domain name or numeric IPv4 or IPv6
address. Using the fully-qualified domain name form is
RECOMMENDED whenever possible.
port: The port number where the request is to be sent.
URI parameters: Parameters affecting a request constructed from
the URI.
URI parameters are added after the hostport component and are
separated by semi-colons.
URI parameters take the form:
parameter-name "=" parameter-value
Even though an arbitrary number of URI parameters may be
included in a URI, any given parameter-name MUST NOT appear
more than once.
This extensible mechanism includes the transport, maddr, ttl,
user, method and lr parameters.
Rosenberg, et. al. Standards Track [Page 149]
RFC 3261 SIP: Session Initiation Protocol June 2002
The transport parameter determines the transport mechanism to
be used for sending SIP messages, as specified in [4]. SIP can
use any network transport protocol. Parameter names are
defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP
(RFC 2960 [16]). For a SIPS URI, the transport parameter MUST
indicate a reliable transport.
The maddr parameter indicates the server address to be
contacted for this user, overriding any address derived from
the host field. When an maddr parameter is present, the port
and transport components of the URI apply to the address
indicated in the maddr parameter value. [4] describes the
proper interpretation of the transport, maddr, and hostport in
order to obtain the destination address, port, and transport
for sending a request.
The maddr field has been used as a simple form of loose source
routing. It allows a URI to specify a proxy that must be
traversed en-route to the destination. Continuing to use the
maddr parameter this way is strongly discouraged (the
mechanisms that enable it are deprecated). Implementations
should instead use the Route mechanism described in this
document, establishing a pre-existing route set if necessary
(see Section 8.1.1.1). This provides a full URI to describe
the node to be traversed.
The ttl parameter determines the time-to-live value of the UDP
multicast packet and MUST only be used if maddr is a multicast
address and the transport protocol is UDP. For example, to
specify a call to alice@atlanta.com using multicast to
239.255.255.1 with a ttl of 15, the following URI would be
used:
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
The set of valid telephone-subscriber strings is a subset of
valid user strings. The user URI parameter exists to
distinguish telephone numbers from user names that happen to
look like telephone numbers. If the user string contains a
telephone number formatted as a telephone-subscriber, the user
parameter value "phone" SHOULD be present. Even without this
parameter, recipients of SIP and SIPS URIs MAY interpret the
pre-@ part as a telephone number if local restrictions on the
name space for user name allow it.
The method of the SIP request constructed from the URI can be
specified with the method parameter.
Rosenberg, et. al. Standards Track [Page 150]
RFC 3261 SIP: Session Initiation Protocol June 2002
The lr parameter, when present, indicates that the element
responsible for this resource implements the routing mechanisms
specified in this document. This parameter will be used in the
URIs proxies place into Record-Route header field values, and
may appear in the URIs in a pre-existing route set.
This parameter is used to achieve backwards compatibility with
systems implementing the strict-routing mechanisms of RFC 2543
and the rfc2543bis drafts up to bis-05. An element preparing
to send a request based on a URI not containing this parameter
can assume the receiving element implements strict-routing and
reformat the message to preserve the information in the
Request-URI.
Since the uri-parameter mechanism is extensible, SIP elements
MUST silently ignore any uri-parameters that they do not
understand.
Headers: Header fields to be included in a request constructed
from the URI.
Headers fields in the SIP request can be specified with the "?"
mechanism within a URI. The header names and values are
encoded in ampersand separated hname = hvalue pairs. The
special hname "body" indicates that the associated hvalue is
the message-body of the SIP request.
Table 1 summarizes the use of SIP and SIPS URI components based on
the context in which the URI appears. The external column describes
URIs appearing anywhere outside of a SIP message, for instance on a
web page or business card. Entries marked "m" are mandatory, those
marked "o" are optional, and those marked "-" are not allowed.
Elements processing URIs SHOULD ignore any disallowed components if
they are present. The second column indicates the default value of
an optional element if it is not present. "--" indicates that the
element is either not optional, or has no default value.
URIs in Contact header fields have different restrictions depending
on the context in which the header field appears. One set applies to
messages that establish and maintain dialogs (INVITE and its 200 (OK)
response). The other applies to registration and redirection
messages (REGISTER, its 200 (OK) response, and 3xx class responses to
any method).
Rosenberg, et. al. Standards Track [Page 151]
RFC 3261 SIP: Session Initiation Protocol June 2002
19.1.2 Character Escaping Requirements
dialog
reg./redir. Contact/
default Req.-URI To From Contact R-R/Route external
user -- o o o o o o
password -- o o o o o o
host -- m m m m m m
port (1) o - - o o o
user-param ip o o o o o o
method INVITE - - - - - o
maddr-param -- o - - o o o
ttl-param 1 o - - o - o
transp.-param (2) o - - o o o
lr-param -- o - - - o o
other-param -- o o o o o o
headers -- - - - o - o
(1): The default port value is transport and scheme dependent. The
default is 5060 for sip: using UDP, TCP, or SCTP. The default is
5061 for sip: using TLS over TCP and sips: over TCP.
(2): The default transport is scheme dependent. For sip:, it is UDP.
For sips:, it is TCP.
Table 1: Use and default values of URI components for SIP header
field values, Request-URI and references
SIP follows the requirements and guidelines of RFC 2396 [5] when
defining the set of characters that must be escaped in a SIP URI, and
uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]:
The set of characters actually reserved within any given URI
component is defined by that component. In general, a character
is reserved if the semantics of the URI changes if the character
is replaced with its escaped US-ASCII encoding [5]. Excluded US-
ASCII characters (RFC 2396 [5]), such as space and control
characters and characters used as URI delimiters, also MUST be
escaped. URIs MUST NOT contain unescaped space and control
characters.
For each component, the set of valid BNF expansions defines exactly
which characters may appear unescaped. All other characters MUST be
escaped.
For example, "@" is not in the set of characters in the user
component, so the user "j@s0n" must have at least the @ sign encoded,
as in "j%40s0n".
Rosenberg, et. al. Standards Track [Page 152]
RFC 3261 SIP: Session Initiation Protocol June 2002
Expanding the hname and hvalue tokens in Section 25 show that all URI
reserved characters in header field names and values MUST be escaped.
The telephone-subscriber subset of the user component has special
escaping considerations. The set of characters not reserved in the
RFC 2806 [9] description of telephone-subscriber contains a number of
characters in various syntax elements that need to be escaped when
used in SIP URIs. Any characters occurring in a telephone-subscriber
that do not appear in an expansion of the BNF for the user rule MUST
be escaped.
Note that character escaping is not allowed in the host component of
a SIP or SIPS URI (the % character is not valid in its expansion).
This is likely to change in the future as requirements for
Internationalized Domain Names are finalized. Current
implementations MUST NOT attempt to improve robustness by treating
received escaped characters in the host component as literally
equivalent to their unescaped counterpart. The behavior required to
meet the requirements of IDN may be significantly different.
19.1.3 Example SIP and SIPS URIs
sip:alice@atlanta.com
sip:alice:secretword@atlanta.com;transport=tcp
sips:alice@atlanta.com?subject=project%20x&priority=urgent
sip:+1-212-555-1212:1234@gateway.com;user=phone
sips:1212@gateway.com
sip:alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
sip:alice;day=tuesday@atlanta.com
The last sample URI above has a user field value of
"alice;day=tuesday". The escaping rules defined above allow a
semicolon to appear unescaped in this field. For the purposes of
this protocol, the field is opaque. The structure of that value is
only useful to the SIP element responsible for the resource.
19.1.4 URI Comparison
Some operations in this specification require determining whether two
SIP or SIPS URIs are equivalent. In this specification, registrars
need to compare bindings in Contact URIs in REGISTER requests (see
Section 10.3.). SIP and SIPS URIs are compared for equality
according to the following rules:
o A SIP and SIPS URI are never equivalent.
Rosenberg, et. al. Standards Track [Page 153]
RFC 3261 SIP: Session Initiation Protocol June 2002
o Comparison of the userinfo of SIP and SIPS URIs is case-
sensitive. This includes userinfo containing passwords or
formatted as telephone-subscribers. Comparison of all other
components of the URI is case-insensitive unless explicitly
defined otherwise.
o The ordering of parameters and header fields is not significant
in comparing SIP and SIPS URIs.
o Characters other than those in the "reserved" set (see RFC 2396
[5]) are equivalent to their ""%" HEX HEX" encoding.
o An IP address that is the result of a DNS lookup of a host name
does not match that host name.
o For two URIs to be equal, the user, password, host, and port
components must match.
A URI omitting the user component will not match a URI that
includes one. A URI omitting the password component will not
match a URI that includes one.
A URI omitting any component with a default value will not
match a URI explicitly containing that component with its
default value. For instance, a URI omitting the optional port
component will not match a URI explicitly declaring port 5060.
The same is true for the transport-parameter, ttl-parameter,
user-parameter, and method components.
Defining sip:user@host to not be equivalent to
sip:user@host:5060 is a change from RFC 2543. When deriving
addresses from URIs, equivalent addresses are expected from
equivalent URIs. The URI sip:user@host:5060 will always
resolve to port 5060. The URI sip:user@host may resolve to
other ports through the DNS SRV mechanisms detailed in [4].
o URI uri-parameter components are compared as follows:
- Any uri-parameter appearing in both URIs must match.
- A user, ttl, or method uri-parameter appearing in only one
URI never matches, even if it contains the default value.
- A URI that includes an maddr parameter will not match a URI
that contains no maddr parameter.
- All other uri-parameters appearing in only one URI are
ignored when comparing the URIs.
Rosenberg, et. al. Standards Track [Page 154]
RFC 3261 SIP: Session Initiation Protocol June 2002
o URI header components are never ignored. Any present header
component MUST be present in both URIs and match for the URIs
to match. The matching rules are defined for each header field
in Section 20.
The URIs within each of the following sets are equivalent:
sip:%61lice@atlanta.com;transport=TCP
sip:alice@AtLanTa.CoM;Transport=tcp
sip:carol@chicago.com
sip:carol@chicago.com;newparam=5
sip:carol@chicago.com;security=on
sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
sip:alice@atlanta.com?subject=project%20x&priority=urgent
sip:alice@atlanta.com?priority=urgent&subject=project%20x
The URIs within each of the following sets are not equivalent:
SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames)
sip:alice@AtLanTa.CoM;Transport=UDP
sip:bob@biloxi.com (can resolve to different ports)
sip:bob@biloxi.com:5060
sip:bob@biloxi.com (can resolve to different transports)
sip:bob@biloxi.com;transport=udp
sip:bob@biloxi.com (can resolve to different port and transports)
sip:bob@biloxi.com:6000;transport=tcp
sip:carol@chicago.com (different header component)
sip:carol@chicago.com?Subject=next%20meeting
sip:bob@phone21.boxesbybob.com (even though that's what
sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to)
Note that equality is not transitive:
o sip:carol@chicago.com and sip:carol@chicago.com;security=on are
equivalent
o sip:carol@chicago.com and sip:carol@chicago.com;security=off
are equivalent
Rosenberg, et. al. Standards Track [Page 155]
RFC 3261 SIP: Session Initiation Protocol June 2002
o sip:carol@chicago.com;security=on and
sip:carol@chicago.com;security=off are not equivalent
19.1.5 Forming Requests from a URI
An implementation needs to take care when forming requests directly
from a URI. URIs from business cards, web pages, and even from
sources inside the protocol such as registered contacts may contain
inappropriate header fields or body parts.
An implementation MUST include any provided transport, maddr, ttl, or
user parameter in the Request-URI of the formed request. If the URI
contains a method parameter, its value MUST be used as the method of
the request. The method parameter MUST NOT be placed in the
Request-URI. Unknown URI parameters MUST be placed in the message's
Request-URI.
An implementation SHOULD treat the presence of any headers or body
parts in the URI as a desire to include them in the message, and
choose to honor the request on a per-component basis.
An implementation SHOULD NOT honor these obviously dangerous header
fields: From, Call-ID, CSeq, Via, and Record-Route.
An implementation SHOULD NOT honor any requested Route header field
values in order to not be used as an unwitting agent in malicious
attacks.
An implementation SHOULD NOT honor requests to include header fields
that may cause it to falsely advertise its location or capabilities.
These include: Accept, Accept-Encoding, Accept-Language, Allow,
Contact (in its dialog usage), Organization, Supported, and User-
Agent.
An implementation SHOULD verify the accuracy of any requested
descriptive header fields, including: Content-Disposition, Content-
Encoding, Content-Language, Content-Length, Content-Type, Date,
Mime-Version, and Timestamp.
If the request formed from constructing a message from a given URI is
not a valid SIP request, the URI is invalid. An implementation MUST
NOT proceed with transmitting the request. It should instead pursue
the course of action due an invalid URI in the context it occurs.
The constructed request can be invalid in many ways. These
include, but are not limited to, syntax error in header fields,
invalid combinations of URI parameters, or an incorrect
description of the message body.
Rosenberg, et. al. Standards Track [Page 156]
RFC 3261 SIP: Session Initiation Protocol June 2002
Sending a request formed from a given URI may require capabilities
unavailable to the implementation. The URI might indicate use of an
unimplemented transport or extension, for example. An implementation
SHOULD refuse to send these requests rather than modifying them to
match their capabilities. An implementation MUST NOT send a request
requiring an extension that it does not support.
For example, such a request can be formed through the presence of
a Require header parameter or a method URI parameter with an
unknown or explicitly unsupported value.
19.1.6 Relating SIP URIs and tel URLs
When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the
entire telephone-subscriber portion of the tel URL, including any
parameters, is placed into the userinfo part of the SIP or SIPS URI.
Thus, tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
or
sips:+358-555-1234567;postd=pp22@foo.com;user=phone
not
sip:+358-555-1234567@foo.com;postd=pp22;user=phone
or
sips:+358-555-1234567@foo.com;postd=pp22;user=phone
In general, equivalent "tel" URLs converted to SIP or SIPS URIs in
this fashion may not produce equivalent SIP or SIPS URIs. The
userinfo of SIP and SIPS URIs are compared as a case-sensitive
string. Variance in case-insensitive portions of tel URLs and
reordering of tel URL parameters does not affect tel URL equivalence,
but does affect the equivalence of SIP URIs formed from them.
For example,
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
are equivalent, while
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone
Rosenberg, et. al. Standards Track [Page 157]
RFC 3261 SIP: Session Initiation Protocol June 2002
are not.
Likewise,
tel:+358-555-1234567;postd=pp22;isub=1411
tel:+358-555-1234567;isub=1411;postd=pp22
are equivalent, while
sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone
are not.
To mitigate this problem, elements constructing telephone-subscriber
fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold
any case-insensitive portion of telephone-subscriber to lower case,
and order the telephone-subscriber parameters lexically by parameter
name, excepting isdn-subaddress and post-dial, which occur first and
in that order. (All components of a tel URL except for future-
extension parameters are defined to be compared case-insensitive.)
Following this suggestion, both
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
become
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
and both
tel:+358-555-1234567;tsp=a.b;phone-context=5
tel:+358-555-1234567;phone-context=5;tsp=a.b
become
sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone
浙公网安备 33010602011771号