SIP addresses are called URIs (Uniform Resource Identifiers). URIs are really names (except those SIP addresses that use an IP host address, such as the address used in our simple call example), they do not refer directly to the transport address to be called but to an abstract entity that can reach the user directly or indirectly.
Registration change
REGISTER sip:registrar.provider.com SIP/2.0 Via: SIP/2.0/UDP 192.190.12.14 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] CSeq: 1 REGISTER Contact: ∗ Expires: 0 [email protected] 192.190.12.14(host2.company.com) 192.190.12.2 (registrar.provider.com) IP Src : 192.190.12.14, Dest 224.0.1.75, TTL 1
INVITE sip: [email protected] SIP/2.0 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] CSeq: 1 INVITE Content-Type : … ...
INVITE sip: [email protected] SIP/2.0 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] CSeq: 1 INVITE Content-Type : … IP Src: 192.190.12.2, Dest 192.190.12.14 port 4321 IP Src : ..., Dest 192.190.12.2 REGISTER sip:registrar.provider.com SIP/2.0
Via: SIP/2.0/UDP 192.190.12.14 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sip:[email protected]:4321> IP Src : 192.190.12.14, Dest 224.0.1.75, TTL 1
Figure 3.23 Updating registration information.
SIP URIs have two major forms, an email-like form, and a telephone number form: • The general format of email-form SIP URIs is user@host, where host is usually a fully
qualified domain name that can be resolved to an IP address using the DNS system. In many cases the SIP address of a user will be the same as his email address.
• The general format of a telephone number-form SIP is phone-number@host; user=phone. Because SIP is still mainly used for telephone calls, this is one of the most widely used formats in SIP networks. The host part is optional and may indicate a server that can reach this phone number, which can be used to specify a preferred service provider. Most telephony systems, however, can decide where to route the phone call based on the phone number only (through prefix analysis or a local number portability query); so, the domain name part is not present in most telephony applications. There is also another type of URI which serves a different purpose; this is a sort of command line requiring some action from the user agent, described by a method attribute.
Table 3.3 Common SIP URL formats
[email protected]:1234 Vanilla SIP URI . . .
Userdomain.com No user part, default port will
be 5060
[email protected]:2345;transport=UDP Wants to be contacted using
UDP
192.190.234.3:8001 Contact the server at this IP
address
[email protected];maddr=239.255.255.1;ttl=32 Override normal host name to
transport address
mechanism: use multicast to 239.255.255.1 with a TTL of 32 instead
[email protected];user=phone Global phone number
0231759329;isub=10;[email protected];user=phone Local phone number with ISDN subaddress, wait for dial tone, then dial 11 (pause) 11 using DTMF
[email protected]?priority=hign&customercode=1234 Using proprietary extension
headers to control priority in an ACD system . . .
[email protected];METHOD=REGISTER Previous URIs would trigger a
SIP INVITE request, this one initiates a registration to the registrar of usergroup: reg.usergroup.com
Optionally, a SIP URI may also specify a port number and a transport mode if the SIP default transport (UDP) and port (5060) is not to be used. A list of example SIP URIs is given in Table 3.3.
Most of the extensions (headers, maddr, etc.) are not allowed in the To, From parameters of SIP requests and responses, but can be used in the contact parameters.
3.4.1.2.1 The original RFC 2543
RFC 2543 describes how to locate the physical endpoint using its SIP URI; this is done in two stages:
• First, the SIP URI allows the calling endpoint to locate a SIP server. This SIP server will be the destination of the initial INVITE message. The SIP server can be the final destination of the call, and even if it is not it is supposed to know how to reach the called endpoint.
• If the SIP server is not the final destination of the call, it will redirect the INVITE request to the called endpoint. This can be done in two ways: either by instructing the calling endpoint to send a new INVITE request to another location using the 302 MOVED reply (redirect server behavior), or by transparently relaying the INVITE message to the
appropriate transport address (proxy behavior). The first model is similar to the H.323 direct call model, and the second similar to the H.323 gatekeeper routed call model. In order to locate the SIP server, a SIP terminal will use DNS. A SIP URI domain name must have an SRV record, an MX record, a CNAME or an A record. The resolution algorithm is represented in Figure 3.24.
First, the terminal will retrieve the SRV resource records for the considered domain name. Then, it will only keep records of typesip.udporsip.tcp (RFC 3263 seems to consider that it should be sip. udp or sip. tcp). If there is a sip.udp record, the terminal will contact the SIP server using UDP at the specified transport address. It will use the port specified in the SIP URL or default to the port specified in the sip.udp
record. If there is asip.tcprecord, the same method will be used, but over TCP. If no SRV record is found, the terminal will try to retrieve the IP address of a SIP server by looking at the MX records first (normally used to point to a mail server), then CNAME records (pointing to an alias name), and finally an A record (pointing to an IP address).
Pointing to a SIP server instead of the called endpoint directly allows the called endpoint to move (the transport address changes), while enabling the use of DNS caching. If the address of the called endpoint was stored directly in DNS, there could be a lot of trouble with DNS caching. Normally, all DNS records can be cached by the DNS resolver. The cached record expires after a certain period once it has been first retrieved by a DNS
Host part isIP address? Y Send INVITE to that address
N
SRV records present? N
Type sip.udp records present? N
Y
Port in URL? Y
N
Send INVITE to lowest precedence SRV record address and URL port using UDP
Send INVITE to lowest precedence SRV record address and port using UDP
Type sip.tcp records present? N
Y
Port in URL? Y
N
Send INVITE to lowest precedence SRV record address and URL port using TCP
Send INVITE to lowest precedence SRV record address and port using TCP MX records present?
N
Port in URL? Y
N
Send INVITE to lowest precedence
MX record address and URL port using UDP first, then TCP
Send INVITE to lowest precedence
MX record address and default SIP port 5060 using UDP first, then TCP
DNS CNAME record present? N
Y
Restart procedure replacing the ‘host’ part of the URL with the new name contained in the CNAME record
A records present? N
Y
Port in URL? Y
N
Send INVITE to IP address pointed by A record
and URL port using UDP first, then TCP, using URL port or port 5060
Send INVITE to IP address pointed by A record
and default SIP port using UDP first, then TCP, using URL port or port 5060 Proprietary method?
Y
Y
query; this period is called the Time To Live (TTL, in seconds). The value of the TTL is stored in the DNS record. Therefore, when the terminal moves, the caller could still have a wrong address in the DNS resolver cache, and the call would fail. The only solution is to set the TTL to zero and update the primary DNS record as the terminal moves; this is neither very easy nor cache-friendly, and therefore not scalable.
On the other hand, a SIP proxy server is not likely to move very often, and storing its address in a DNS SRV, MX, or A record does not cause any trouble. This SIP proxy server needs to know the current location of the called terminal (e.g., by implementing SIP registrar functionality), and can redirect the INVITE request to the appropriate location.
3.4.1.2.2 RFC 3263 and the use of NAPTR records
The newer RFC 3263 (‘Locating SIP Servers’) brings substantial changes to RFC 2543. It first states (for ‘backward compatibility’) that if the URI contains a numeric IP address (and optional port), but without a protocol specifier, the UDP should be used to reach this IP address. Similarly, if the target is not a numeric IP address, but a port is provided instead, then UDP should be preferred. This is because UDP was the preferred transport in RFC 2543.
In all other cases (i.e., if the URI is not a numeric IP address and contains no protocol specifier or explicit port), then the Naming Authority Pointer Record (NAPTR) DNS mechanism defined in RFC 2915 should be used to resolve the URI into a next hop address. NAPTR records are also used by ENUM (see Chapter 2).
When a SIP server needs to locate the appropriate resource to reach user@subdomain. domain.org, it will query the DNS for the new NAPTR of the DNS (DNS type code 35, defined in RFC 2168 and RFC 2915) for subdomain.domain.org.
The NAPTR record is used to attach a rewrite rule, based on a regular expression, to the DNS domain name. Once rewritten, the resulting string can be interpreted as a new domain name for further queries, or a URI (Uniform Resource Identifier) which can be used to delegate the name lookup. The syntax of the NAPTR RR is as follows:
Domain TTL Class Type Order Preference Flags Service RegExp Replacement Domain, TTL, and class are standard DNS fields. The type field is set to 35 in the case of the NAPTR. The order and preference field specifies the order in which records must be processed when multiple NAPTR records are returned in response to a single query. The ordering is lexicographic, order is used first, then preference.
The ‘S’, ‘A’, and ‘U’ flags indicate that this NAPTR record is the last one and that the next query should be made using SRV records (flag ‘S’), an A record (flag ‘A’), a protocol-specific algorithm (flag ‘P’). In all these cases the ‘replacement’ field will be used as the new name to fetch the corresponding resource record. If the flag is ‘U’, the regular expression15 specified in the RegExp field should be applied to the domain name
in order to get a new URI.
15An expression composed of a series of symbols each defining a specific modification to a string,
The service field defines the protocol that should be used after this step of the resolution (H323, LDAP, SIP, TEL, SIPS), and the type of service that will be provided: D2U (UDP transport), D2T (TCP transport), or D2S (SCTP transport). For memory, ENUM uses E2U as the type of service.
A SIP server looking for a next hop protocol for a SIP call will therefore look for NAPTR resource records with the service field set to:
• SIP+D2U for a list of next hops that must be reached via SIP/UDP. • SIP+D2T for a list of next hops that must be reached via SIP/TCP. • SIP+D2S for a list of next hops that must be reached via SIP/SCTP. • SIPS+D2T for a list of next hops that must be reached via SIPS/TCP.
All other service fields are discarded, as well as the options that are not supported by the requesting server (e.g., SCTP), the responses are sorted according to the preference value (lower values have a higher priority), and the server must try them out in the allotted order. Resource records with the SIP+D2U, SIP+D2T, SIP+D2S, or SIPS+D2T service codes also have the ‘S’ flag: full resolution requires a request for SRV resource records for the resource indicated in the ‘replacement’. The regular expression field will be empty. For instance, if we have the following NAPTR records for subdomain.domain.org:
; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.subdomain.domain.org.
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.subdomain.domain.org.
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.subdomain.domain.org.
This indicates that the server supports TLS over TCP, TCP, and UDP, in that order of preference. If the client supports TCP and UDP, TCP will be used, targeted to a host determined by an SRV lookup of sip. tcp..subdomain.domain.org. The lookup will, for instance, return this list of SRV records:
;; Priority Weight Port Target
IN SRV 0 1 5060 proxy1.domain.com IN SRV 0 2 5060 proxy2.domain.com
In theory, the NAPTR record could change subdomain.domain.org into anything. RFC 3263 says that if this is the case then SRV records with the original name must also be present, for backwards compatibility with RFC 2543.
The whole procedure requires at least three DNS queries for each transaction (one to resolve the URI into NAPTR records, one to resolve the new resource name specified by the NAPTR resource field into a set of SRV resource records, and at least one to resolve the selected SRV record target into an IP address). In fact, most of the time, more requests will be required if the URI contains many subdomain components, because in the more general case, these domains will not all be in cache. For subdomain.domain.org, this is five DNS requests, each request lasting about 100 ms!
The procedure introduced by RFC 3263 requires one more DNS lookup than the previ- ous RFC 2543 mechanism which looked for SRV records directly. However, it does not bring anything new because it does not make use of any of the possibilities of NAPTR records, which go beyond anything that can be achieved with SRV records. Overall, this an overly complicated and verbose RFC (with many exceptions to the general rule) for a very simple address resolution problem. It could evolve into something more interesting if the full power of NAPTR records, with the use of regular expressions, was used. It would then become very similar to ENUM. As it stands now, it seems to be chasing the same concepts as ENUM, keeping the complexity and leaving important features out.