. 121
( 132 .)


information is not needed to route the call on the SIP network, but may cause problems
when more complex tandem routing is involved.

SIP Gateway PABX
SIP User Agent

Audio (Call Progress)
200 OK

RTP audio session Duplex speech

200 OK

Figure 9.24 Incoming PSTN to SIP call

Figure 9.25 shows an example con¬guration, where an intermediate SIP network is
used between two PSTN segments. This type of setup could be, for example, used to
route long-distance calls over an IP backbone between two regional PSTN networks. In
this case, the loss of information may generate signi¬cant problems since the ISUP ¬elds
in the originating network may need to be present to indicate SS7 service requirements
in the destination network. To resolve this problem, a form of ISUP encapsulation called
SIP bridging has been de¬ned. In this, all the original data ¬elds in the IAM message (or
other ISUP messages) are attached to the SIP INVITE (and other SIP messages) when the
translation is done at the ingress gateway. This encapsulated data is used to reconstruct
the ISUP message at the egress gateway, with the SIP network providing transparent
transport between the two PSTNs.
The SIP bridging solution is not ideal, and does have a number of drawbacks. First,
the SS7 protocols come in different national variants, e.g. ITU ISUP based signalling

Information loss on translation Information loss on translation


SIP network

Ingress Egress
Gateway Gateway

Figure 9.25 Tandem call routing

such as TUP (China), BTNUP (UK) and SSUTR2 (France), as well as ANSI ISUP type
signalling used in North America. For the gateways to be able to handle each of these,
complex ISUP to ISUP translation is required. Additionally, because of the sensitivity of
the ISUP data (e.g. calling party number) it may be necessary to encrypt and authenticate
the traf¬c.

9.5.20 Conferencing with SIP
Conferencing where many parties can participate in the same call is now a common
feature of audio and multimedia communication systems. SIP supports three different
modes of conference: meet-me, interactive broadcast and ad hoc. The meet-me conference
involves all the media being mixed together using a central server commonly called
a conferencing bridge. Each user is given a scheduled time to communicate with the
conferencing bridge or multi-conference unit (MCU). Each user establishes a point-to-
point call to the conferencing bridge which then mixes and forwards media on behalf of
each client.
In an interactive broadcast conference, a conferencing bridge is also used but the mixed
media is sent to a multicast address instead of being unicast to each participant in turn.
This allows two types of conference participants, passive, who only receive media (i.e.
listen and watch), and active, who send as well as receive. SIP signalling is only required
for active participants. The interactive broadcast SIP signalling for active users is the
same is the SIP signalling for the meet-me conference.
Finally, there is the ad hoc conference where a point-to-point conversation is expanded
with a series of INVITEs.

9.5.21 SIP event noti¬cation
There are many circumstances when it is useful to be able to be informed of events as
and when they happen. These events could be, for example:

• arrival of new email;
• arrival of a new instant message;
• a user becoming available after being busy;
• a user switching on their phone.

The event noti¬cation extensions to SIP are speci¬ed in RFC 3265, which de¬nes two
new messages: SUBSCRIBE and NOTIFY. Subscribe
SUBSCRIBE is sent by a UA to indicate to another UA of which events it needs to be
noti¬ed. SUBSCRIBE can be used to turn event noti¬cation either on or off. The header
¬elds relevant to subscribe are:

• Expires: time for which the subscription is valid. A value of 0 indicates that the UA
would like to unsubscribe
• Event: states the event package and optionally an integer ID.

Event packages
Events are grouped into packages. Each package de¬nes the internal states of a resource,
for example the state of an email inbox. If the internal state changes (e.g. a new email
arrives), this event plus the current internal state (e.g. the total current number of unread
emails) can be signalled to the subscriber. Notify
NOTIFY is sent by a UA to another UA to signal the occurrence of an event. The
event header in the NOTIFY message will contain the package name of the original
SUBSCRIBE message plus the integer ID.

9.5.22 SIP and instant messaging services
UMTS speci¬es the use of SIP to provide instant messaging (IM) within the IMS. The
use of SIP for instant messaging gives UMTS the simplest route to interoperating with
other IM networks since it is IETF™s preferred choice and the only IM proposed standard
which is vendor independent.
The extension that provides instant messaging for SIP is de¬ned in RFC 3428. This
document de¬nes a SIP method call MESSAGE. SIP instant messages are sent in what
is called near real-time. This means that the message is expected to be delivered without
delay directly to the receiver. Even though direct delivery is the case for most messages,
SIP IM, like SMS, allows for instant messages to be stored (in case, for example, the
user is of¬‚ine).
Here is an example of a SIP instant message:

MESSAGE sip: jeff@orbitage.com SIP/2.0
Via: SIP/2.0/UDP proxy.orbitage.com
To: sip:jeff@orbitage.com
From: sip:seb@orbitage.com
Call-ID: 123254caa121@pc1.orbitage.com
Content-Type: text/plain
Content-Length: 28
Development meeting at 4 pm?
9.6 E.164 NUMBERS (ENUM) 597

Usually the content in this case is text, but can be other formats. For example, the
message format can support the delivery of multimedia content (e.g. for MMS service)
by the use of the multi-part MIME format. This is essentially the same way that ¬le
attachments are handled by email.
If the destination for the MESSAGE is a UA and the message is accepted the response
should be 200 OK. On the other hand if the destination is a message relay server, the
response will be a 202 accepted.

9.6 E.164 NUMBERS (ENUM)

For calls handled purely within the IP network, SIP uses DNS and IP routing to forward
the requests. For calls from IP to PSTN, the destination™s telephone number can be
represented as a SIP URI. For these calls, the gateway strips out the telephone number
and uses it to initiate the call using ISUP signalling.
A problem arises when a caller on the PSTN network is attempting to call a user on the
IP network. Since it is not possible to represent an IP address (or DNS name) in an ISUP
message, when the call reaches the PSTN/SIP gateway there must be some mechanism to
route the call to its ¬nal destination. The solution to this problem is to provide a mapping
between E.164 telephone numbers and IP addresses using DNS. To do this the IETF has
speci¬ed a domain for telephone numbers and a mechanism for generating DNS addresses
from them. The process is de¬ned in RFC 2916 and operates as follows.
As an example, consider the following E.164 telephone number, including country
code (44):
To perform the DNS conversion, the digits are reversed, dots put between them and
e164.arpa concatenated to the end, so for the example the DNS address will be:
This effectively splits up the DNS domain for telephone numbers based on country
code then area code, since the DNS name de¬nes domains from right to left in terms of
coverage. The namespace of these numbers can be managed in the same way as any DNS
namespace, so if an organization controls the telephone pre¬x 65780 (Singapore number)
it can manage the set of DNS mappings that end with
To resolve this address, the DNS client makes its ¬rst query to the top-level domain,
i.e. e164.arpa, to ascertain the name server for the particular country code, and will then
contact this name server to look for the particular subscriber. In practice, it may be referred
to another DNS server if the domain is large enough to be split into subdomains. It is also
possible to translate this address using a lightweight directory access protocol (LDAP)
directory server.
Using this scheme, each user on the IP network can be allocated a unique E.164 number
which must also be entered into the DNS server. The DNS resource records either point
to another name server (to indicate the ENUM service provider) or can use the naming
authority pointer (NAPTR) resource records (RFC 2915) format.

9.6.1 NAPTR
NAPTR provides a DNS service which instead of resolving names directly to IP addresses,
provides string translation. The result of this process is usually a URI. NAPTR is useful
since it can translate between different types of protocol and service. For example, a user
starting off with a URI as http://www.orbitage.com/∼contacts might have it translated
directly by DNS to mailto:mail1.orbitage.com, redirecting the user to send an email. This
is particularly applicable for ENUM, which starts with telephone strings and needs to
translate them to SIP URIs.

9.6.2 ENUM examples
Here are some examples of ENUM records.
$ORIGIN e164.arpa. 4.4 IN NS ns1.4.4.e164.arpa
This indicates the address of the name server for the UK ENUM domain (44). It is
also possible to have a record indicating that the next server will be LDAP.
$ORIGIN 4.4.e164.arpa.

IN NAPTR 100 10 “u” “ldap+E2U” “!ˆ+ 44(.*)$!ldap://ldap.uk/cn=01!”.
The — in the record indicates that all addresses that start with 4.4.e164.arpa. will match
the NAPTR record. For example, the number string +4467254907 would ¬rst be translated
to the domain name:
Then the original string is acted upon by the NAPTR record to produce the URI:
ldap://ldap.uk/cn =067254907
This request can then be sent by the client to the LDAP server.
The ¬nal example shows how a set of DNS entries for a particular user are represented
in ENUM:
IN NAPTR 10 10 “u” “sip+E2U” “!ˆ.*$!sip:seb@orbitage.com”.
IN NAPTR 10 10 “u” “mailto+E2U” !ˆ.*$!mailto:seb@orbitage.com”.
IN NAPTR 10 10 “u” “tel+E2U” “!ˆ.*$!tel:+44 7789 123654”.
This is for the telephone number +4413531234, and the possible resulting URIs
would be:
tel:+44 7789 123654

The client could then choose which way they would prefer to contact the caller. In
the case that the telephone number is chosen then the ENUM translation process will
start again.

The call signalling protocol for the IMS is based wholly on SIP and SDP and is described
in 3GPP TS 24.229. The different CSCF components each act as SIP servers as well as
containing extra functionality to perform functions such as accounting. The P-CSCF and
I-CSCF act as proxy servers, the P-CSCF to provide service to the UE, and the I-CSCF
as an incoming proxy for the home network.
The S-CSCF acts as a proxy and registrar server. It performs authentication of sub-
scribers. It uses the registration contact information to route incoming calls for its own
subscriber list to an appropriate P-CSCF, which then forwards them to the UE. For mobile
originated calls it must decide if the call should be forwarded to a P-CSCF (for IMS to
IMS calls), to a BGCF (for IMS to PSTN call) or to the Internet (for public SIP calls).
Before the subscriber can use the IMS to make a multimedia call, the following three
operations must be carried out:

• perform a successful GPRS attach procedure to establish a bearer for the call;
• discover the address of their serving P-CSCF;
• register their current contact details and authenticate themselves with the S-CSCF.

Call ¬‚ows for session initiation/termination use the same techniques as standard SIP
except a number of new headers are added to the messages to assist in routing and
accounting for network usage. Some examples of these are headers to provide information
on radio access technology, network identity, cell identity, etc.

9.7.1 IMS security


. 121
( 132 .)