100 |
SIP: Understanding the Session Initiation Protocol |
Figure 4.12 and the following show an example of an UPDATE message.
UPDATE sips:beale@bufords.bedford.va.us SIP/2.0
Via SIP/2.0/TLS client.crypto.org:5061;branch=z9hG4bK342 Max-Forwards: 70
To: T. Beale <sips:beale@bufords.bedford.va.us>;tag=71 From: Blaise Vigenere <sips:bvigenere@crypto.org>;tag=19438 Call-ID: 170189761183162948
CSeq: 94 UPDATE
Contact: <sips:client.crypto.org> Content-Type: application/sdp Content-Length: ...
(SDP Message body not shown...)
Table 4.16 lists the mandatory header fields in an UPDATE request.
4.2 URI and URL Schemes Used by SIP
SIP supports a number of URI and URL schemes including sip, sips, tel, pres, and im for SIP, secure SIP, telephone, presence, and instant message URIs as described in the following sections. In addition, other URI schemes can be present in SIP header fields as listed in Table 1.2.
Figure 4.12 An UPDATE call flow example showing an offer/answer exchange.
SIP Request Messages |
101 |
Table 4.16
Mandatory Header Fields in an UPDATE
To
Via
To
From
Call-ID
CSeq
Max-Forwards
Contact
4.2.1SIP and SIPS URIs
The addressing scheme of SIP URLs and URIs has been previously mentioned. SIP URIs are used in a number of places including the To, From, and Contact headers, as well as in the Request-URI, which indicates the destination. SIP URIs are similar to the mailto URL [29] and can be used in hyperlinks on Web pages, for example. They can also include telephone numbers. The information in a SIP URI indicates the way in which the resource (user) should be contacted using SIP.
An example SIP URI contains the scheme sip a “:”, then a username@host or IPv4 or IPv6 address followed by an optional “:”, then the port number, or a list of “;” separated URI parameters:
sip:joseph.fourier@transform.org:5060;transport=udp;user=ip;m
ethod=INVITE;ttl=1;maddr=240.101.102.103?Subject=FFT
Note that URIs may not contain spaces or line breaks, so this example would be on a single line. Some SIP URIs, such as a REGISTER Request-URI do not have a username, but begin with the host or IP address. In this example, the port number is shown as 5060, the well-known port number for SIP. For a SIP URI, if the port number is not present 5060 is assumed. For a SIPS URI, port number 5061 is assumed. The transport parameter indicates UDP is to be used, which is the default. TCP, TLS, and SCTP are alternative transport parameters.
The user parameter is used by parsers to determine if a telephone number is present in the username portion of the URI. The assumed default is that it is not, indicated by the value ip. If a telephone number is present, it is indicated by the value phone. This parameter must not be used to guess at the characteristics or capabilities of the user agent. For example, the presence of a user=phone parameter must not be interpreted that the user agent is a SIP telephone (which may have limited display and processing capabilities). In a telephony environment, IP telephones and IP/PSTN gateways may in fact use the reverse assump-
102 |
SIP: Understanding the Session Initiation Protocol |
tion, interpreting any digits in a username as digits regardless of the presence of
user=phone.
The method parameter is used to indicate the method to be used. The default is INVITE. This parameter has no meaning in To or From header fields or in a Request-URI but can be used in Contact headers for registration, for example, or in a Refer-To header field.
The ttl parameter is the time-to-live, which must only be used if the maddr parameter contains a multicast address and the transport parameter contains udp. The default value is 1. This value scopes the multicast session broadcast.
The maddr usually contains the multicast address to which the request should be directed, overriding the address in the host portion of the URI. It can also contain a unicast address of an alternative server for requests.
The method, maddr, ttl, and header parameters must not be included in To or From headers, but may be included in Contact headers or in Request-URIs. In addition to these parameters, a SIP URI may contain other user-defined parameters.
Following the “?” parameter, names can be specified to be included in the request. This is similar to the operation of the mailto URL, which allows Subject and Priority to be set for the request. Additional headers can be specified, separated by an “&”. The header name body indicates that the contents of a message body for an INVITE request are being specified in the URI.
If the parameter user=phone is present, then the username portion of the URI can be interpreted as a telephone number. This allows additional parameters in the username portion of the URI, which allows the parameters and structure of a tel URL [30] to be present in the user part of the SIP URI as described in the next section.
The sips URI scheme has the same structure as the sip URI but begins with the sips scheme name. Note that a sips URI is not equivalent to a sip URI with transport=tls, since the sip URI does not have the same security requirements as the sips URI. The requirement is that TLS transport is used end-to-end for the SIP path. The only exception is a hop between the final proxy and the UAS, which may use another security mechanism besides TLS (IPSec, for example).
Not shown in the example is the loose route parameter lr, which can be present in sip or sips Record-Route and Route URIs to indicate that the proxy server identified by the URI supports loose routing.
4.2.2Telephone URLs
The telephone URI scheme, tel, [30] can be used to represent a resource identified by a telephone number. Telephone numbers can be of two general forms, local or global. A local number is only valid in a particular geographic area and has
SIP Request Messages |
103 |
only local significance. If the number is used outside of this area, it will either fail or return the wrong resource. A global telephone number, also called an E.164 number, is one that is, in principle, valid anywhere. It contains enough information about the country, region, and locality for the PSTN network to route calls to the correct resource. An example of a local phone number is:
tel:411;phone-context=+1314
This indicates a call to directory assistance valid only within country code 1 and area code 314 as identified in the required phone-context parameter. An example of a global phone number is:
tel:+13145551212
Global phone numbers always begin with the “+” identifier followed by the country code, 1 in this case, followed by the remaining telephone digits.
A tel URL can also contain some characters and information about dialing strings and patterns. For example:
tel:#70555-1212;isub=1000
In this example, the dialed digit string, interpreted by a PSTN gateway, would be the DTMF digit # then 70 (to cancel call waiting, for example), then the digits 555–1212. Additional parameters include an ISDN subaddress of 1000. This example shows both types of optional visual separators allowed, either “-” or “.” as the separator.
Tel URLs can also be embedded in Web pages and can be included in HTML as, for example:
Click <A HREF=”tel:+1972.555.1212”>here</A> to get information about Dallas.
The syntax and parameters of the tel URL may be used in the user portion of a sip URI. For example, the first tel example could be represented as a sip URI as follows:
sip:411;phone-context=+1314@gateway.example.com
The SIP URI adds a domain portion which represents the domain or gateway that will route the request.