<<

. 115
( 132 .)



>>

Zb
SEG SEG
IPSEC IKE
IKE
Zb
IPS
EC EC
IPS Za
NE-2 NE-2
Zb Zb




Figure 9.5 IMS IP domain security architecture
564 RELEASE 5 AND BEYOND (ALL-IP)


number of shared secrets increases as the square of the number of domains. In this case
the use of public key cryptography and certi¬cates is a more appropriate choice.
Within the de¬nition of IPSec, support for the data encryption standard (DES) algorithm
is mandatory. With 3GPP, however, due to the perceived weaknesses in the DES transform
the advanced encryption standard (AES) must be used instead. AES is the latest US
Federal Information Processing Standard (FIPS) cipher and is speci¬ed as a replacement
for DES. It supports key lengths of 128, 192 or 256 bits.



9.5 SESSION INITIATION PROTOCOL (SIP)

SIP, as de¬ned by RFC 3261, is designed to allow multimedia sessions to be established
between users on an IP network. As well as call control, the baseline SIP RFC supports
functions such as user mobility and call redirection. As well as RFC 3261, a number of
extensions are de¬ned in supplementary RFCs and IETF drafts covering topics such as
SIP/PSTN interworking and SIP for instant messaging and presence detection. Currently
the following types of services are supported (note this list is not exhaustive):

• multimedia call establishment
• user mobility
• conference call
• supplementary services (call hold, call redirect, etc.)
• authentication and accounting
• uni¬ed messaging
• instant messaging and user presence detection.

Although SIP can provide all these services, currently R5 does not de¬ne call scenarios
for all of them. For example, multimedia conferencing will be made available as part
of R6. This, however, does not preclude an operator or vendor introducing them as a
value-added service.
The bene¬ts of SIP when moving to an all-IP architecture are as follows:

• end-to-end SIP signalling between mobile and ¬xed-line IP users;
• Internet SIP servers can provide value-added services to mobile users;
• SIP is designed as an IP protocol, therefore it integrates well with other IP protocols
and services;
• SIP is lightweight and (relatively) easy to implement.

The ¬rst point is of particular interest. As subscribers of the UMTS network start to
use services based on an IP infrastructure they may wish to communicate to ¬xed-line
Internet lines. Figure 9.6 shows an example of this. The mobile UE is participating in the
voice portion of a video call with a user using a voice or video application on a desktop.
9.5 SESSION INITIATION PROTOCOL (SIP) 565


SIP Video/VoIP call establishment

RAN

Desktop
user
IMS Internet
UE
GGSN
SGSN
RNC
WBTS
Packet Core
Uu Iu SIP application
server

Figure 9.6 End-to-end SIP signalling


The SIP application server shown in the ¬gure can be accessed by users on the Internet
or connected via the mobile network.
The use of SIP does have one potential drawback. The emulation of existing PSTN
supplementary telephony services using SIP may not provide an identical or complete
set of services. This issue has been addressed by the ITU-T with the use of the bearer-
independent call control (BICC) protocol for SS7/PS network interworking, as described
in Chapter 8. This is not seen as a serious drawback, however, for two reasons. First, as
SIP is maturing, so will SIP/PSTN interworking, with most of the service issues being
resolved over time. Second, and probably more importantly, users of next generation
networks are expecting a very different range of services (e.g. instant and multimedia
messaging, email, uni¬ed message, videoconferencing) than was possible with the con-
ventional telephone network. SIP is easily capable of delivering such a rich service set
over IP. To provide such services using BICC would be dif¬cult. This is because BICC
was designed to emulate call control for existing voice and circuit services and has no
facilities for multimedia and extra services such as instant messaging. Another added com-
plication is that BICC addressing is not based on IP addressing but on E.164, whereas
SIP supports both formats.



9.5.1 SIP addressing

SIP users are located via a SIP uniform resource indicator (URIs). Here are some examples
of SIP URIs:

sip:icurtis@orbitage.com
sip: + 447789005240@wcom.com;user = phone

In the ¬rst case, the SIP address de¬nes a user connected to the Internet; in the second, a
telephone number is given and the user must be contacted via a PSTN gateway. For UMTS
subscribers, the IP public identity of a subscriber (i.e. the SIP address) is contained within
the subscriber™s Internet multimedia system subscriber identity module (ISIM) application.
This is an application on the universal integrated circuit card (UICC), as is the UMTS
566 RELEASE 5 AND BEYOND (ALL-IP)


SIM (USIM). For a UE without an ISIM application, the SIP address (or public identity)
can be derived as follows:

sip:IMSI number @MNC.MCC.IMSI.3gppnetwork.org

where MNC is the mobile network code (the fourth and ¬fth digits of the IMSI) and MCC
is the mobile country code (the ¬rst three digits of the IMSI). This hierarchical scheme
makes it possible for DNS domains to be managed country by country and operator by
operator, making it easier to locate users on the mobile network, given their IMSI. The
following example shows an IMSI-derived SIP address:

sip:234150999999999@15.234.IMSI.3gppnetwork.org

This type of SIP address is only to be used within the IMS, i.e. between CSCF and
HLR, and not used externally. In this case the anonymity of the IMSI appears to be
somewhat compromised, since this temporary public identity must be used for all regis-
trations between UE and the S-CSCF. However, the identity can be kept private within
the operator™s network since the GPRS link can provide encryption at the link layer and
all other connections within the IMS are protected using IPSec.



9.5.2 SIP components
Figure 9.7 shows the basic component architecture for a SIP network. The SIP servers are
responsible for assisting in call setup and mobility management but SIP also allows users
to perform call setup directly with each other without a server being involved. Some SIP
servers (proxy and redirect) can be stateless (i.e. do not need to store transaction state
information). This is a desirable property since it makes it easier to scale the network to


Network A Network B
Direc UA
UA t call
Ca UA
U gis
ion




ll v
se tr
call arded



re




ia
r ati
trat




ser
ve
User
regis




r
w




on
For




Forwarded call registrar
proxy
registrar proxy
server
server
server server
loc
req ation
on
ati t location update
location ue
loc ues st
update
req
location
redirect
location redirect
Location server
server location
request server
server
request




Figure 9.7 SIP component architecture
9.5 SESSION INITIATION PROTOCOL (SIP) 567


large numbers of nodes. Commonly, logical SIP servers are often co-located within the
same physical device.

9.5.2.1 User agent (UA)
The user agent (UA) makes or accepts calls on behalf of a SIP user. The SIP user can be
an actual person or an application on a server. The UA terminates the SIP call signalling
and acts as the interface to the SIP network. The UA can act as either user agent server
(UAS) or user agent client (UAC). The UAS processes incoming SIP requests (call setup)
and generates appropriate responses (accept, reject, busy). The UAC generates requests on
behalf of the SIP user. For a UMTS network each UE will contain a UA to handle user calls.
UA functionality can also be located elsewhere in the network; for example, an application
server providing a video on demand service would act as a UA, accepting incoming call
requests from subscribers, and then streaming media to the calling parties. Another type of
server that would act as a UA would be voice/video mail service. In this case it would accept
calls that have been redirected in the case of the UE being switched off or the user busy.

9.5.2.2 Proxy server
The SIP proxy forwards requests on behalf of SIP agents. The SIP proxy may well rewrite
a SIP message before forwarding it to its correct location. For example, a user may have
moved from their work location where their proxy resides to a location at their home
address. In this case the destination URI will have to be rewritten. For incoming calls
the proxy will interrogate the location service to determine how to forward the call. The
proxy can also be con¬gured to provide authentication control and act as a point of control
between the internal private network and an outside public network.

9.5.2.3 Registrar server
The registrar server allows SIP agents to register their current location. In 3G the loca-
tion information includes the UE destination IP address assigned during PDP context
establishment, the station™s UTRAN cell ID and the identity of the P-CSCF. The reg-
istrar is responsible for keeping up-to-date information within the location service by
sending updates.

9.5.2.4 Redirect server
The redirect server responds to a UA request with a redirection response indicating the
current location of the called party. In this case the UA must establish a new call to the
indicated location.

9.5.2.5 Location service
A location service is used by a redirect or proxy server to obtain information about a
user™s whereabouts. The location service can be co-located with other SIP servers. The
interface between the location service and other servers is not de¬ned by SIP.
568 RELEASE 5 AND BEYOND (ALL-IP)

<<

. 115
( 132 .)



>>