Unregistered calls to the IMS domain

All tested SIP clients were able to initiate a call to a registered user in the IMS domain. The clients were not registered to any service themselves.

The clients resolved the _sip._udp.open-ims.test SRV record in DNS and learned the address of icscf.open-ims.test listening on the port 5060. The initial INVITE request was sent to this address and then forwarded from I-CSCF to the S- CSCF inside the IMS domain. S-CSCF sent the request to the called user's P-CSCF (the user was registered, so his location was known) and forwarded to the UE from there. Provisional responses, as well as the 200 OK final response sent after the call was answered, were sent along the same route in the opposite direction.

The subsequent ACK request was sent from the SIP client directly to the S- CSCF (as the I-CSCF did not insert its URI to the Record-Route header field) and through the P-CSCF to the called user's UE. Also the BYE request for termination Figure 5.7: SIP-to-IMS call directly from a SIP client

was routed this way. Handling of the SIP messages by the entities in the IMS domain was identical to the handling described above.

These tests have shown that an IMS user can be reached by a SIP client that simply places a call to his public SIP URI. The call in opposite direction is not possible for obvious reasons, the IMS user can reach the other party by placing a call directly to his IP address and port number, but this is not likely scenario. Even in this case the IMS specification does not hinder the initiation of the SIP call and it is successfully established.

It must be noted though that I-CSCF in IMS architecture is a transition point to and from other IMS domains and it might not be always reachable from any address. Because the I-CSCF is also responsible for inserting the correct charging- related information to the SIP headers, it might be deployment- and operator's policy- dependent whether the call will succeed.

5.5 Encountered problems and suggested solutions

While capturing the call flow messages, two different dumps needed to be done at once - one for each virtual server. It wouldn't suffice to sniff the traffic flowing between the virtual machines, as messages passed inside one virtual server needed to be tracked. Combining of these dumps turned out to be problematic and thus use of automatic SIP analysis software (such as SIP Scenario Generator6_{) was}

complicated. The call flow analysis was thus done by hand, by examining the captured data in Wireshark network analyzer.

6 Conclusion and future work

In this thesis SIP protocol was introduced and its features, architecture and provided services were described. Also IMS with its standardization processes was characterized. An IMS example deployment was done and the process was documented. To ensure that the IMS can communicate with a different IMS domain, the IMS was installed on two servers and their interconnectivity was verified.

Several scenarios testing the interworking capabilities between an IMS domain and a SIP domain (served by either the OpenSER or Asterisk server) were carried out and evaluated. A call initiation procedure between the two heterogeneous VoIP networks was examined in detail and every step was compared to the specifications and standards defining this process. Some minor non-conformities were found, but in general the interworking does work and calls to and from both domains can be placed with both tested server solutions.

Also, possibility of using a non-IMS SIP-based VoIP client in an IMS network was tested but with less success. It was revealed that a SIP client adhering to the standard procedures might work in certain cases, but tested implementations can not be reliably used in an IMS network. The extensions needed for a fully-working IMS client are substantial and the non-IMS clients can not be expected to work as they were not developed with possible IMS use in mind. Using of these clients as ordinary VoIP clients calling to the IMS network was successful, though, and the IMS turned out to be compatible with SIP without IMS-specific extensions.

Based on this work, several topics might be interesting for further research: A more complete evaluation of specification conformance of all processes in the IMS network can be carried out.

It can be interesting to research charging procedures and possibilities of user charging within a single operator domain and charging of inter-operator calls.

Security of IMS is also a topic worth researching, whether in IMS itself (analysis of the current state of security and possibilities of securing the IMS network) or between IMS and SIP domains.

Although IMS is designed to work with IPv6, where NAT is not a problem anymore, the transition from IPv4 to IPv6 is still pending, so it would be interesting to evaluate the ways of NAT traversal for IMS needs.

7 List of abbreviations

ANSI American National Standards Institute

ARIB Association of Radio Industries and Businesses ADSL Asynchronous Digital Subscriber Line

B2BUA Back-to-back User Agent

BGCF Breakout Gateway Control Function CSCF Call Session Control Function

FOKUS Das Fraunhofer-Institut für Offene Kommunikationssysteme

DNS Domain Name System

EDGE Entanced Data rates for GSM Evolution

ETSI European Telecommunication Standards Institute FQDN Fully-Qualified Domain Name

GPRS General Packet Radio Service GPL General Public License

GSM Global System for Mobile communications

GNU GNU's Not Unix

HSS Home Subscriber Server HTTP HyperText Transfer Protocol

ISDN Integrated Services Digital Network IAX Inter-Asterisk Exchange

IVR Interactive Voice Response

IBCF Interconnection Border Control Function

ITU-T International Telecommunication Union - Telecommunication Standardization Sector

IANA Internet Assigned Numbers Authority IETF Internet Engineering Task Force

IP Internet Protocol

I-CSCF Interrogating Call Session Control Function IMS IP Multimedia Subsystem

IPTV IP Television

MGCF Media Gateway Control Function

MRFC Multimedia Resource Function Controller NAPTR Naming Authority Pointer

NA(P)T Network Address (Port) Translation NAT Network Address Translation NGN Next Generation Network POTS Plain Old Telephone System PTR Pointer (DNS record type) PBX Private Branch Exchange

P-CSCF Proxy Call Session Control Function PES PSTN/ISDN emulation subsystem PSTN Public Switched Telephone Network PoC Push-to-talk over Cellular

QoS Quality of Service

RFC Request For Comment

S-CSCF Serving Call Session Control Function SDP Session Description Protocol

SIP Session Initiation Protocol

SER SIP Express Router

SIPS SIP Secure

SCTP Stream Control Transmission Protocol SQL Structured Query Language

TR Technical Report

TS Technical Specification

TTA Telecommunications Technology Association TTC Telecommunications Technology Committee ENUM tElephone NUMber mapping

3G Third Generation

3GPP Third Generation Partnership Project 3GPP2 Third Generation Partnership Project 2 TCP Transmission Control Protocol

TLS Transport Layer Security URI Universal Resource Identifier

UA User Agent

UAC User Agent Client

UAS User Agent Server

UDP User Datagram Protocol

UE User Equipment

VoIP Voice over IP

8 References

[1] AHSON, Syed A., ILYAS, Mohammad, SIP handbook: services, technologies, and security of Session Initiation Protocol, CRC Press, 2008

[2] POIKSELKA, Miikka, NIEMI, Aki, KHARTABIL, Hisham, MAYER Georg, The IMS: IP Multimedia Concepts and Services, John Wiley & Sons Ltd., 2006

[3] http://www.sipcenter.com/sip.nsf/html/Architecture

[4] ROSENBERG, J., SCHULZRINNE, H., CAMARILLO, G., JOHNSTON, A., PETERSON, J., SPARKS, R., HANDLEY, M., SCHOOLER, E. SIP: Session Initiation Protocol. 2002. RFC 3261 [5] http://www.iana.org/assignments/uri-schemes

[6] MEALLING, M., DENENBERG, R. Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations. 2002. RFC 3305

[7] ROACH, A. B. Session Initiation Protocol (SIP)-Specific Event Notification. 2002. RFC 2543

[8] NIEMI, A. Session Initiation Protocol (SIP) Extension for Event State Publication. 2004. RFC 3903

[9] CAMPBELL, B., ROSENBERG, J., SCHULZRINNE, H., HUITEMA, C., GURLE, D. Session Initiation Protocol (SIP) Extension for Instant Messaging. 2002. RFC 3428

[10] SINNREICH, Henry, JOHNSTON, Alan B., Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol, Second Edition, Wiley Publishing, Inc., 2006 [11] CAMPBELL, B., MAHY, R., JENNINGS, C. The Message Session

Relay Protocol (MSRP). 2007. RFC 4975

[12] HANDLEY, M., JACOBSON, V., PERKINS, C. SDP: Session Description Protocol. 2006. RFC 4566

[13] SCHULZRINNE, H., CASNER, S., FREDERICK, R., JACOBSON, V. RTP: A Transport Protocol for Real-Time Applications. 2003. RFC 3550 [14] http://www.telecomspace.com/latesttrends-ims.html

[15] http://www.itu.int/ITU-

T/studygroups/com13/ngn2004/working_definition.html] [16] KOVACIKOVA, Tatiana, SEGEC, Pavol, BRUNCKO, Michal.

Standardization paths for NGN IMS-based architecture. In:

Communications: Scientific Letters of the University of Žilina - ISSN 1335-4205. - Vol. 10, No. 4 (2008), pp. 15-18

[17] ETSI ES 282 001: Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture

[18] ETSI TS 123 002: Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Network architecture

[19] http://www.3gpp.org/ftp/Inbox/2008_web_files/3gppagre.pdf [20] 3GPP TS 23.517: 3rd Generation Partnership Project; Technical

Specification Group Technical Specification Group Services and System Aspects; Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture

[21] 3GPP TS 23.228: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2

[22] 3GPP TS 24.229: 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3

[23] http://www.enterprisemessagingnews.com/ [24] http://www.openimscore.org/

[25] http://uctimsclient.berlios.de/

[26] ROSENBERG, J., SCHULZRINNE, H. Reliability of Provisional Responses in the Session Initiation Protocol (SIP). 2002. RFC3262 [27] http://www.iptel.org/ser

Appendix A: Header fields in SIP

● Accept: specifies the content types of bodies the UA understands and wishes to

receive.

● Accept-Encoding: restricts the content-codings that are acceptable in the response. ● Accept-Language: indicates the preferred languages for reason phrases, session

descriptions, or status responses carried as message bodies in the response.

● Alert-Info: is used to specify an alternative ring tone or ringback tone. ● Allow: lists the set of methods supported by the UA generating the message. ● Authentication-Info: is used for mutual authentication with HTTP Digest. ● Authorization: contains authentication credentials of a UA.

● Call-ID: uniquely identifies a particular invitation or all registrations of a particular

client.

● Call-Info: provides additional information about the caller or callee.

● Contact: provides a URI whose meaning depends on the type of request or

response it is in.

● Content-Disposition: describes how the message body (or message body part for

multipart messages) is to be interpreted by the UAC or UAS

● Content-Encoding: indicates (when present) what additional content codings have

been applied to the entity-body.

● Content-Language: describes natural language of the intended audience of the

message.

● Content-Length: indicates the size of the message body.

● Content-Type: indicates the media type of the message body sent to the recipient. ● CSeq: contains a single decimal sequence number and the request method. This

header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if both the sequence number and the request method are identical.

● Date: contains the date and time.

● Error-Info: provides a pointer to additional information about the error status

response.

● Expires: gives the relative time after which the message (or content) expires.

● From: indicates the initiator of the request. This header field may contain an

optional “display-name” meant to be rendered by a human user interface.

● In-Reply-To: enumerates the Call-IDs that this call references or returns.

● Max-Forwards: is used to limit the number of proxies or gateways that can

forward the request to the next downstream server.

● Min-Expires: conveys the minimum refresh interval supported for soft-state

elements managed by that server.

● MIME-Version: is used to indicate what version of MIME was used to construct

the message.

● Organization: conveys the name of the organization to which the SIP element

issuing the request of response belongs.

● Priority: indicates the urgency of the request as perceived by the client. This is

intended for the receiving human or its agent. This header field does not influence the use of communications resources of network elements.

● Proxy-Authenticate: contains an authentication challenge.

● Proxy-Authorization: allows the client to identify itself to a proxy that requires

authentication.

● Proxy-Require: is used to indicate proxy-sensitive features that must be supported

by the proxy.

● Record-Route: is inserted by proxies in a request to force future requests in the

dialog to be routed through the proxy.

● Reply-To: contains a logical return URI that may be different from the From

header field.

● Require: is used by UACs to tell UASs about options that the UAC expects the

UAS to support in order to process the request. Although this is an optional header field, it MUST not be ignored if it is present. Only option tags corresponding to standards-track RFCs can be used in this header field.

● Retry-After: can be used with some error responses to indicate when the called

party anticipates being available again.

● Route: is used to force routing for a request through the listed set of proxies.

● Server: contains information about the software used by the UAS to handle the

request.

● Subject: provides a summary or indicates the nature of the call.

● Supported: enumerates all the extensions supported by the UAC or UAS. Like in

Required header field, only option tags corresponding to standards-track RFCs can be used in this header field.

● Timestamp: describes when the UAC sent the request to the UAS. ● To: specifies the logical recipient of the request.

● Unsupported: lists the features not supported by the UAS.

● User-Agent: contains information about the UAC originating the request.

● Via: indicates the path taken by the request so far and indicates the path that should

be followed in routing responses. The branch ID parameter in the Via header field values serves as a transaction identifier, and is used by proxies to detect loops.

● Warning: is used to carry additional information about the status of a response. ● WWW-Authenticate: contains an authentication challenge.

Appendix B: Packages installed prior to

OpenIMSCore installation

acpid adduser ant apt apt-utils aptitude base-files base-passwd bash bind9 binutils bison bsdmainutils bsdutils build-essential busybox bzip2 console-common console-data console-tools coreutils cpio cpp cpp-4.1 cron debconf debconf-i18n debian-archive-keyring debianutils dhcp3-client dhcp3-common diff dmidecode dnsutils dpkg dpkg-dev dselect e2fslibs e2fsprogs ed eject file findutils flex g++ g++-4.1 gcc gcc-4.1 gcc-4.1-base gnupg gpgv grep groff-base grub gzip host hostname ifupdown info initramfs-tools initscripts installation-report iproute iptables iputils-ping java-common klibc-utils klogd laptop-detect less libacl1 libapr1 libaprutil1 libatm1 libattr1 libbind9-0 libblkid1 libbz2-1.0 libc6 libc6-dev libc6-i686 libcap1 libcomerr2 libconsole libdb4.2 libdb4.3 libdb4.4 libdbd-mysql-perl libdbi-perl libdevmapper1.02 libdns22 libedit2 libexpat1 libgcc1 libgcrypt11 libgdbm3 libglib2.0-0 libgnutls13 libgpg-error0 libgpmg1 libisc11 libisccc0 libisccfg1 libjaxp1.3-java libklibc libkrb53 libldap2 liblocale-gettext-perl libltdl3 liblwres9 liblzo1 libmagic1 libmysql++-dev libmysql++2c2a libmysqlclient15-dev libmysqlclient15off libncurses5 libncursesw5 libneon26 libnet-daemon-perl libnewt0.52 libopencdk8 libpam-modules libpam-runtime libpam0g libpcap0.8 libplrpc-perl libpopt0 libpq4 libreadline5 libsasl2 libsasl2-2 libselinux1 libsepol1 libsigc++-2.0-0c2a libslang2 libsqlite3-0 libss2 libssl0.9.8 libssp0 libstdc++6 libstdc++6-4.1-dev libsvn1 libtasn1-3 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libusb-0.1-4 libuuid1 libvolume-id0 libwrap0 libx11-6 libx11-data libxau6 libxdmcp6 libxerces2-java libxml2 libxml2-dev linux-image-2.6-686 linux-image-2.6.18-6- 686 linux-kernel-headers locales login logrotate lsb-base m4 make makedev man-db manpages mawk mc mktemp module-init-tools mount mysql-client-5.0 mysql-common mysql-server mysql-server-5.0 nano ncurses-base ncurses-bin net-tools netbase netcat ntp ntpdate odbcinst1debian1 openbsd-inetd openssh-blacklist openssh-client openssh-server passwd patch perl perl-base perl-modules procps psmisc readline-common screen sed ssh subversion sun-java5-bin sun-java5-demo sun-java5-jdk sun-java5-jre sysklogd sysv-rc sysvinit sysvinit-utils tar tasksel tasksel-data tcpd tcpdump traceroute tzdata udev unixodbc update-inetd usbutils util-linux vim vim-common vim-runtime vim-tiny wget whiptail x11-common zlib1g zlib1g-dev 79

Appendix C: SIP Messages for described call flows

IMS-to-SIP session establishment

F1

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 192.168.0.42:5063;rport;branch=z9hG4bK1785354332 Route: <sip:[email protected]:6060;lr>

From: "Alice" <sip:[email protected]>;tag=998562695 To: <sip:[email protected]>

Call-ID: 1518053909 CSeq: 20 INVITE

Contact: <sip:[email protected]:5063> Content-Type: application/sdp

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Max-Forwards: 70

User-Agent: UCT IMS Client Subject: IMS Call

Expires: 120

P-Preferred-Identity: "Alice" <sip:[email protected]> P-Preferred-Service: urn:xxx:3gpp-service.ims.icsi.mmtel Privacy: none P-Access-Network-Info: IEEE-802.11a Require: sec-agree Proxy-Require: sec-agree Supported: 100rel Content-Length: 520 F2

SIP/2.0 100 trying -- your call is important to us

Via: SIP/2.0/UDP 192.168.0.42:5063;rport=5063;branch=z9hG4bK1785354332 From: "Alice" <sip:[email protected]>;tag=998562695

To: <sip:[email protected]> Call-ID: 1518053909

CSeq: 20 INVITE

Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0

F3

INVITE sip:[email protected] SIP/2.0

Record-Route: <sip:[email protected]:4060;lr>

Via: SIP/2.0/UDP 192.168.0.250:4060;branch=z9hG4bK93ba.0c676815.0 Via: SIP/2.0/UDP 192.168.0.42:5063;rport=5063;branch=z9hG4bK1785354332 Route: <sip:[email protected]:6060;lr>

From: "Alice" <sip:[email protected]>;tag=998562695 To: <sip:[email protected]>

Call-ID: 1518053909 CSeq: 20 INVITE

Contact: <sip:[email protected]:5063> Content-Type: application/sdp

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Max-Forwards: 16

User-Agent: UCT IMS Client Subject: IMS Call

Expires: 120 P-Preferred-Service: urn:xxx:3gpp-service.ims.icsi.mmtel Privacy: none P-Access-Network-Info: IEEE-802.11a Supported: 100rel Content-Length: 520 80

P-Asserted-Identity: "Alice" <sip:[email protected]>

P-Charging-Vector: icid-value="P-CSCFabcd4a0e1f120000001d";icid-generated- at=192.168.0.250;orig-ioi="open-ims.test"

F4

SIP/2.0 100 trying -- your call is important to us

Via: SIP/2.0/UDP 192.168.0.250:4060;branch=z9hG4bK93ba.0c676815.0 Via: SIP/2.0/UDP 192.168.0.42:5063;rport=5063;branch=z9hG4bK1785354332 From: "Alice" <sip:[email protected]>;tag=998562695

To: <sip:[email protected]> Call-ID: 1518053909

CSeq: 20 INVITE

Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0

F5

INVITE sip:[email protected] SIP/2.0

Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip:[email protected]:4060;lr>

Via: SIP/2.0/UDP 192.168.0.250:6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP 192.168.0.250:4060;branch=z9hG4bK93ba.0c676815.0 Via: SIP/2.0/UDP 192.168.0.42:5063;rport=5063;branch=z9hG4bK1785354332 From: "Alice" <sip:[email protected]>;tag=998562695

To: <sip:[email protected]> Call-ID: 1518053909

CSeq: 20 INVITE

Contact: <sip:[email protected]:5063> Content-Type: application/sdp

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Max-Forwards: 15

User-Agent: UCT IMS Client Subject: IMS Call

Expires: 120 P-Preferred-Service: urn:xxx:3gpp-service.ims.icsi.mmtel Privacy: none P-Access-Network-Info: IEEE-802.11a Supported: 100rel Content-Length: 520

P-Asserted-Identity: "Alice" <sip:[email protected]>

P-Charging-Vector: icid-value="P-CSCFabcd4a0e1f120000001d";icid-generated- at=192.168.0.250;orig-ioi="open-ims.test"

F6

SIP/2.0 100 trying -- your call is important to us

Via: SIP/2.0/UDP 192.168.0.250:6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP 192.168.0.250:4060;branch=z9hG4bK93ba.0c676815.0

In document UNIVERSITY OF ŽILINA DIPLOMA THESIS (Page 69-98)