Push-to-talk in PDC Packet data network - umu.se · Push-to-talk in PDC Packet data network Internal Supervisor: Pedher Johansson External Supervisor: Håkan Nordmark. Abstract Push-to-talk

Umeå University 2004-10-05 Department of Computing Science Master Thesis, 20 credits Olof Burman [email protected]

Push-to-talk in PDC Packet data network

Internal Supervisor: Pedher Johansson External Supervisor: Håkan Nordmark

Abstract Push-to-talk is a walkie-talkie type of service over mobile phones. By combining the benefits of a walkie-talkie and a mobile phone it creates a fast, cheap and easy way to communicate with multiple people at once. Push-to-talk services already exist but they only work within their own system. To eliminate this problem and achieve interoperability between operators, terminals and networks a specification, Push-to-talk over Cellular, is being constructed. It is a jointly developed specification by mobile industry leaders, Ericsson, Nokia, Motorola and Siemens. This master thesis studies the specification for PoC and investigates to what extend it can be applied to the Japanese mobile cellular system PDC. A prototype of a push-to-talk system, following the PoC specification, has also been implemented.

Acknowledgements I would foremost like to thank my supervisors, Pedher Johansson and Håkan Nordmark, for their help during this master thesis. I would also like to thank Roger Sjölin, Tomas Röjmyr and Jan Halvarsson for their involvement in my work. Last but not least I would like to thank the employees at TietoEnator for making this a fun and educational experience.

Table of contents 1. Introduction ................................................................................................. 11

1.1. Goal ....................................................................................................... 12 1.2. Thesis outline ........................................................................................ 12

2. PDC............................................................................................................... 13

2.1. PPDC..................................................................................................... 13 2.2. Network overview ................................................................................. 14

3. Push-to-talk over Cellular .......................................................................... 17

3.1. Standards and Protocols ........................................................................ 17 3.1.1. SIP - Session Initiation Protocol ................................................... 18 3.1.2. RTP – Real-time Transport Protocol............................................. 21 3.1.3. XML - Extensible Mark-up Language .......................................... 24 3.1.4. XCAP – XML Configuration Access Protocol ............................. 25

3.2. Architecture ........................................................................................... 25 3.3. Entities................................................................................................... 26

3.3.1. PoC Client ..................................................................................... 26 3.3.2. PoC Server..................................................................................... 27 3.3.3. GLMS – Group List Management Server ..................................... 27 3.3.4. Presence Server ............................................................................. 28 3.3.5. SIP/IP Core.................................................................................... 28

3.4. Interfaces ............................................................................................... 29 3.4.1. Is interface ..................................................................................... 29 3.4.2. It interface...................................................................................... 29 3.4.3. Itn interface.................................................................................... 29 3.4.4. Im interface.................................................................................... 29 3.4.5. In interface..................................................................................... 30 3.4.6. Ik interface..................................................................................... 30 3.4.7. If interface ..................................................................................... 30 3.4.8. Ipl interface.................................................................................... 30 3.4.9. Ips interface ................................................................................... 30 3.4.10. Igs interface ................................................................................... 30 3.4.11. Ie interface ..................................................................................... 30

3.5. Identification and Usage........................................................................ 31 3.6. PoC applicability to PDC ...................................................................... 33

4. Implementation of a PoC prototype .......................................................... 35

4.1. Hardware and software.......................................................................... 35 4.2. Limitations............................................................................................. 35 4.3. Design and implementation................................................................... 36

4.3.1. The Client ...................................................................................... 37 4.3.2. The SIP Core ................................................................................. 38 4.3.3. The PoC Server ............................................................................. 38

4.4. Testing ................................................................................................... 38 4.5. Problems encountered ........................................................................... 38

5. Conclusions...................................................................................................41 6. References.....................................................................................................43 A Abbreviations 45 B User Guide 47

List of figures Figure 1: PDC network overview.......................................................................... 14 Figure 2: SIP signaling flow.................................................................................. 20 Figure 3: RTP packet............................................................................................. 22 Figure 4: SR packet ............................................................................................... 23 Figure 5: The PoC architecture.............................................................................. 26 Figure 6: Instant personal talk signaling flow. ...................................................... 32 Figure 7: Implemented parts of the PoC architecture............................................ 36 Figure 8: The Client with the user tree opened. .................................................... 37

11

1. Introduction As the Internet and mobile telecommunications becomes more and more integrated new ways to communicate appears. Some of them, like WAP and MMS, have already made their way into every day life and others are on the way. One of the new upcoming applications is Push-to-talk (PTT), a walkie-talkie type of service that gives the user the capability to simultaneously communicate with one or more persons. Push-to-talk uses Voice over IP[17] (VoIP), a way of packaging and transmitting voice data over the Internet, or any other packet data network. Since Push-to-talk uses some kind of network to transport the data, unlike a walkie-talkie that sends it directly to the receivers, it has the potential to communicate worldwide. It also minimizes the bandwidth needed by only sending data when someone is talking, which makes it very cost-efficient when used with a packet-switched network like GPRS. Push-to-talk is however not a new concept. It was first introduced by the US operator Nextel on their iDen network about ten years ago. Nextel has a proprietary solution that only works in their network. Since then a few other companies have launched their own software Push-to-talk services, one example is the Swedish company Sapio. Their Push-to-talk client comes in the form of a Java application that is installed on the mobile phone. In the last couple of months there has been a tremendous increase in telecommunication companies trying to make their way into the Push-to-talk market. SonyEricsson, Nokia and Motorola are, or soon will be, offering phones with Push-to-talk. To achieve interoperability between operators, terminals and networks, a Push-to-talk specification over standard mobile networks, PoC (Push-to-talk over Cellular), is being developed by the mobile industry leaders, Ericsson, Nokia, Motorola and Siemens [8]. PoC is also supported by AT&T Wireless Services, Cingular, Sonim Technologies and SonyEricsson [10]. Since the specification is not frozen there might be some inconsistencies between this report and the final PoC specification. At TietoEnator the PDC (Personal Digital Cellular) system for the Japanese mobile telephone market is developed, verified and maintained. The PDC mobile telephone standard is a variant of the GSM standard and is used in the Japanese mobile telephony network. Among other things it includes a service for sending IP packet based traffic over the radio network, a system called Packet PDC (PPDC) which is the Japanese version of GSM:s GPRS service. As Push-to-talk is becoming a recognised concept in GSM networks, but something similar is missing in the PDC network, TietoEnator wants to examine the Push-to-talk standard and investigate if it could be applied to PDC.

Chapter 1. Introduction

12

1.1. Goal The goal of this master thesis is to investigate the Push-to-talk specification for GSM and to which extent it can be applied to the Japanese mobile cellular system PDC. An in-depth study of the Push-to-talk specification and an overview study of the PDC system will be conducted. It will then be concluded to which extent the Push-to-talk specification for GSM can be applied to the PDC network. A prototype of a Push-to-talk system, following the specification, will be implemented. The client will be implemented in Java to ease portability.

1.2. Thesis outline The second chapter gives an introduction to the PDC mobile system. The history of PDC and the techniques it uses are described. The packet switched part (PPDC) of the system is also described. Finally an overview of the system components is given. In the third chapter the Push-to-talk specification for GSM, PoC, is described. It is explained why it is developed and by whom. The standards and protocols on which it is built and its architecture, with all of its components and interfaces, are also described. The chapter is ended with the concluding of to which extent PoC can be applied to the PDC system. The fourth chapter describes the implemented prototype. It is explained which hardware and software that were used and limitation and design decisions that were made. Furthermore the implemented components, test results and problems encountered are described. The fifth chapter concludes the master thesis.

13

2. PDC PDC (Personal Digital Cellular or Pacific Digital Cellular) is a second-generation mobile phone system. It was first introduced by NTT DoCoMo in 1991 as a replacement for the earlier analog networks. Even thou it only exists in Japan it accounts for about 10% of the world market for second-generation mobile phone users. PDC is very similar to GSM (Global System for Mobile Communication) and they both use TDMA (Time Division Multiple Access) to share a frequency channel. TDMA divides each channel into individual time slots in order to increase the amount of data that can be carried, or in this case number of users. PDC operates in the 800 and 1500 MHz bands and uses 25 kHz channel spacing. PDC supports two operating modes, full-rate and half-rate. In full-rate mode, normally used, it can support three users per frequency channel. If the traffic levels are high it can use half-rate and double the supported users to six per channel, this will of course reduce the sound quality. PDC is the most spectrally efficient TDMA technology in use today. GSM only supports eight users over a 200 kHz channel compared to PDC that can support up to six users over a 25 kHz channel. Both GSM and PDC, in full-rate, have a digital data transfer rate of 9.6 kbps. PDC in half-rate only offers a transfer rate of 5.6 kbps. Even though it results in a significantly lower sound quality the speech is still understandable [6, 13]. Like other second-generation technologies PDC offers an impressive array of advanced features. It has the usual features like text messaging and caller identification. Furthermore it utilizes its Intelligent Network (IN) capabilities to support features like pre-paid calling, Universal Access Numbers, advanced charging schemes, personal numbers and virtual private networks (VPN). VPNs are limited access groups that allow people working in different locations to communicate through the mobile phone network as though they were using a conventional office phone system [6, 13]. One very important feature in Japan is that of coverage, especially within buildings such as shopping malls, offices and subway stations. PDC has been designed to solve this with a network of micro and pico cells that can be deployed indoors. The base stations for these cells use low power combined with distributed antenna systems and repeaters to ensure the required coverage [6, 13].

2.1. PPDC PPDC (Packet PDC) or PDC-P (PDC mobile Packet Data Communication System) has been introduced in the PDC system to enable data transmissions. PPDC utilizes a packet switch system instead of the usual circuit switch, which makes it far more efficient when bursty applications such as web browsing are used. PPDC allows a user to use an entire channel at once allowing a data transfer

Chapter 2. PDC

14

rate on the downlink of 28.8 kbps. The uplink on the other hand only supports the usage of one time slot, lowering the transfer rate to 9.6 kbps. PPDC also charges the user differently. Instead of paying for the connected time the user pays for the amount of data transmitted. This allows a user to be online a long time without it costing a fortune [6, 13]. It is also possible to combine packet data and circuit data on the same frequency [4].

2.2. Network overview The PDC and PPDC network consist of the components shown in Figure 1 and listed below.

Figure 1: PDC network overview

Chapter 2. PDC

15

MS – The Mobile System communicates over the air with a Base Station (BS). The MS can be assigned an IP address and thereby connect to an Application Server (AS) that stores the IP-based content. The MS can access this content by establishing a radio link to a PMSC. The IP address is dynamically assigned by the PMSC and is retained by the MS until it deregisters. BS – The Base Station is connected to antennas that transmit and receives information over the air to enable the BS to communicate with MSs in their covered area. The BS separates circuit- and packet-switched calls before forwarding them to the VMSC. VMSC – The Visited Mobile Services Switching Center is the main component in the circuit-switched network. It is responsible for the operation and maintenance of the radio network resources. It provides functions for switching, call setup, circuit-switched charging and so on. Each VMSC controls multiple BSs and provides the interface to the HLR and GLR database. It also maintains and updates subscription information about the subscribers currently served, and stores information about the location of the MS. When used with packet-switched communication it controls if the MS is allowed to use packet data. All the packet-switched user data and control signaling data is carried transparently through the VMSC. PMSC - The Packet Mobile services Switching Center is the main component in the PPDC system. It handles the packet data switching functionality between MSs and ASs, and provides IP-based connectivity by assigning dynamic IP addresses to MSs wishing to setup an end-to-end packet data session to an AS. It also routes and forwards incoming and outgoing IP packets within the PMSC’s Terminal Registration Area (TRA). The TRA is the geographical area covered by one PMSC. The PMSC provides mobility management functions that allow MSs to keep their communication links while moving. These functions include registration and deregistration, authentication and update of routing information. OSS – The Operations Support System is used by the operator to plan, operate and maintain the system. It contains a database of all the parameters the operator has set and the information about the current status of the network. NOC – The Network Operational Center is used to configure and manage the PMSCs. The NOC is only needed for the PPDC system. CHSe – The Charging Server collects charging data that is generated by the PMSC periodically or after a call is completed. The CHSe only collects charging data for packet-switched connections. HLR – The Home Location Register is a database that contains the subscription information for all users. It contains information like supplementary services,

Chapter 2. PDC

16

authentication parameters, the location of the MS and if the MS is allowed to use packet data communication. GLR – The Gateway Location Server is the database that contains subscriptions for subscribers visiting from other mobile networks. GMSC – The Gateway Mobile services Switching Center switches all the circuit-switched calls between the PDC network and the Public Switched Telephone Network (PSTN). It is not used by the PPDC. AS – The Application Server provides the content that the operators offer. It can include IP-based services from both local and external sources like the Internet. For security reasons a firewall is installed between the AS and the Internet [4].

17

3. Push-to-talk over Cellular On the 25:th of August 2003, a specification for Push-to-talk over Cellular (PoC) was submitted to the Open Mobile Alliance (OMA). It is a jointly developed specification by the mobile industry leaders, Ericsson, Nokia, Motorola and Siemens [8], and supported by AT&T Wireless Services, Cingular, Sonim Technologies and SonyEricsson [10]. The specification outlines a Push-to-talk type of service over standard mobile networks. It defines a half-duplex Voice over IP solution. PoC is primary designed for GSM/GPRS/EGPRS packet switch networks, but can easily be expanded to other networks that use the IP protocol. Therefore, it can also be used in PPDC, UMTS, LAN and Wi-Fi networks. The solution outlined is based on the IP Multimedia Subsystem (IMS), as defined by Third Generation Partnership Project (3GPP), and it is built on established standards like Session Initiation Protocol (SIP), Real Time Protocol (RTP) and Hyper Text Transfer Protocol (HTTP). The main idea behind the standardization of PoC is to attain interoperability between operators and between terminals and networks. However, the specification is still not frozen and work will continue throughout 2004. This master thesis is based on Release 1.0 of the PoC Specification. The unfrozen specification has resulted in a minor crack between Nokia and the others. Nokia has chosen a slightly different solution for their first Push-to-talk mobile phones. It is however based on the PoC standard and it will be upgradeable to the standard when it is finished [8]. Another Push-to-talk service that is based on the PoC specification is Ericsson Instant Talk[2]. PoC should not be seen as a cheap alternative to regular phone calls, due to the half-duplex mode, latencies and group functionality. Nor is it a SMS or e-mail replacement, since the massage is not stored and forwarded. It should rather be seen as a complement to existing voice and messaging services and is believed to place it self between regular phone calls and SMS [12].

3.1. Standards and Protocols The Core of the PoC network is IMS (IP Multimedia Subsystem), a standardized architecture for peer-to-peer communication over IP. IMS in its turn is based on SIP (Session Initiation Protocol), see below for further information about SIP. The PoC network also uses some other standardized protocols, for example RTP and HTTP. These protocols have already been used in the Internet and mobile community for quite some time. As a service platform IMS aims at real-time multimedia services that easily integrate with each other and telephone services. By bringing together call control and service provision into a horizontally integrated system IMS enables new combinations of services and service elements.

Chapter 3. Push-to-talk over Cellular

18

3.1.1. SIP - Session Initiation Protocol Session Initiation Protocol (SIP) was developed in the mid-1990s by the IETF (Internet Engineering Task Force) as a real-time communication protocol for IP voice. Since then it has expanded into video, interactive games, virtual reality and instant-messaging applications. SIP is firmly grounded in the culture of the Internet and has drawn heavily from the experiences of developing protocols such as HTTP. It is a text-based request-response protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. SIP was designed to specifically reuse as many existing protocols and protocol design concepts as possible. For example, SIP was modeled after HTTP, using URLs and SDP. Much of the syntax in message headers and many HTTP codes are reused. For example: the error code 404 for an address not found is identical to that used in HTTP. SIP also re-uses the SMTP for address schemes. A SIP address, such as sip:[email protected], has the same structure as an email address. SIP even leverages Web architectures, such as DNS, making messaging among SIP users even more extensible. SIP runs on top of several different transport protocols, UDP being one of them [16]. Since SIP was designed for the Internet there where no big concerns regarding bandwidth and latencies. This meant that the size of the messages was not a priority. But when SIP is used in a mobile environment the priorities change. To solve this new problem Signal Compression (SigComp) is used. SigComp can use any compression algorithm to compress ASCII-based protocols, such as SIP, to a fraction of their original size [10]. SIP does not have any way to describe the content and its characteristics. SIP therefore uses SDP (Session Description Protocol) to convey session information. SDP includes description of: media to use (codec, sampling and so on), media destination (IP address and port number), session name and purpose, times the session is active and contact information. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types [7]. SIP was designed to solve only a few problems and to work with a broad spectrum of existing and future IP telephony protocols. To this end SIP provides four basic functions:

• SIP allows for the establishment of user location (translating from a user's name to their current network address).

• SIP provides for feature negotiation so that all of the participants in a session can agree on the features to be supported among them.

• SIP provides call management - adding, dropping and transferring participants.

• SIP allows for changing features of a session while it is in progress [15]. To provide these functions SIP sessions utilize up to four major components: SIP User Agents, SIP Registrar Servers, SIP Proxy Servers and SIP Redirect Servers.


19

Together, these systems deliver messages embedded with the SDP protocol defining their content and characteristics to complete a SIP session. Below is a high-level description of each SIP component and the role it plays in this process:

• User Agents (UA) are the end-user devices, such as cell phones, PCs, PDAs, etc. used to create and manage a SIP session. The User Agent Client initiates the message and the User Agent Server responds to it.

• Registrar Servers are databases that contain the location of all User Agents within a domain. In SIP messaging, these servers retrieve and send participants IP addresses and other pertinent information to the SIP Proxy Server.

• Proxy Servers accept session requests made by a UA and query the SIP Registrar Server to obtain the recipient UA’s addressing information. It then forwards the session invitation directly to the recipient UA if it is located in the same domain or to a Proxy Server if the UA resides in another domain. It also authenticates and authorizes users for services.

• Redirect Servers allow SIP Proxy Servers to direct SIP session invitations to external domains. SIP Redirect Servers may reside in the same hardware as SIP Registrar Servers and SIP Proxy Servers [16].

SIP supports a variety of methods, below is a list of the most important:

• INVITE initiates sessions

• ACK confirms session establishment, can only be used with

INVITE

• BYE terminates sessions

• REGISTER binds a permanent address to current location [1]

When used for telephony the SIP protocol performs basic call-control tasks such as session set up and tear down, and signaling for call initiation, dial tone and termination. SIP also controls other signaling for features such as hold, caller ID and call transferring. Its functions are similar to the Signaling System 7 protocol in standard telephony and H.323 in IP telephony. The SIP model for telephony puts most of the intelligence for call setup and features on the SIP device or user agent - such as an IP phone or a PC with voice or instant-messaging software. This lets SIP user agents provide more features and operate in more of a peer-to-peer fashion. The method is different from traditional telephony where most call processing and control intelligence reside on a centralized phone switch or server. Example The example below describes a normal talk session using SIP. It shows the signaling flow (Figure 2), the contents of the INVITE and a description of the contents in the INVITE.


20

The talk session consists of four user actions:

1. Alice calls Bob using his SIP URI ([email protected]).

2. Bob accepts the call.

3. They talk.

4. Bob ends the call.

These actions result in the following signaling flow:

Figure 2: SIP signaling flow The first signal sent was an INVITE. The INVITE in this example has the following contents:

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown)

atlanta.com biloxi.comproxy proxy

Alice Bob

INVITEINVITE

100 Trying INVITE100 Trying

180 Ringing180 Ringing

180 Ringing 200 OK200 OK

200 OK

ACK

Media Session

BYE

200 OK


21

The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below:

• Via contains the address at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction.

• Max-Forwards limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.

• To contains a display name (Bob) and a SIP or SIPS URI (sip:[email protected]) towards which the request was originally directed.

• From also contains a display name (Alice) and a SIP or SIPS URI (sip:[email protected]) that indicate the originator of the request. This header field also has a tag parameter containing a random string (1928301774) that was added to the URI by the user equipment. It is used for identification purposes.

• Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the user equipments host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog.

• CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.

• Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While a FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests.

• Content-Type contains a description of the message body (not shown). • Content-Length contains an octet (byte) count of the message body [7].

3.1.2. RTP – Real-time Transport Protocol RTP provides end-to-end delivery services for data with real-time characteristics, such as audio, video or simulation data, over multicast or unicast network services. Those services include payload type identification, sequence numbering, time stamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services, both protocols contribute parts of the transport protocol functionality. RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying


22

network is reliable and delivers packets in sequence. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. Figure 3, shows the RTP packet contents.

Figure 3: RTP packet [5] Version (V)(2 bit): Indicating the current version of RTP. The current version of RTP is 2.0. Padding (P)(1 bit): If P is set the packet contains one or more additional padding octets at the end, which are not part of the payload. Padding is needed by some encryption algorithms, which require fixed block sizes, or for carrying several RTP packets in a lower-layer protocol data unit (PDU). Extension (X)(1): If X is set, the fixed header is followed by exactly one header extension. CSRC count (CC)(4): The field indicates the number of CSRC identifiers that follow the fixed headers. This number is more than one if the payload of the RTP packet contains data from several sources. Marker bit (M)(1): If M is set it indicates some significant events, like frame boundaries, to be marked in the packet stream. For example, an RTP marker bit is set if the packet contains a few bits of the previous frame along with the current frame. Payload type (PT)(7): PT indicates the payload type carried by the RTP packet. RTP Audio Video Profile (AVP) contains a default static mapping of payload type codes to payload formats. Additional payload types can be registered with IANA. Sequence number (16): The number increments by one for each RTP data packet sent, with the initial value set to a random value. The receiver can use the sequence number not only to detect packet loss but also to restore the packet sequence. Time stamp (32): The time stamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter

0 2 3 4 8 9 16 31


23

calculations at the receiver. The initial value should be random, to prevent known plain text attacks. For example, if the RTP source is using a codec, which is buffering 20 ms of audio data, the RTP time stamp must be incremented by 160 for every packet irrespective of the fact that the packet is transmitted or dropped as silence. SSRC (32): This field identifies the source that is generating the RTP packets for this session. The identifier is chosen randomly so that no two sources within the same RTP session have the same value. CSRC list: The list identifies the contributing sources for the payload contained in this packet. The maximum number of identifiers is limited to 15, as is apparent from the CC field. If there are more than 15 contributing sources, only the first 15 sources are identified [5]. RTCP RTP receivers provide reception quality feedback using RTCP report packets. The report packets can be of sender type or receiver type. The receiver sends SR (sender reports) if it is actively participating in the session, otherwise it will send RR (receiver reports). RTCP also has three other packet types: SDES, BYE and APP. SDES contain a source description, BYE ends the RTP session and APP defines the application [5].

Figure 4: SR packet [5]

0 2 3 8 16 31V

SSRC of Sender NTP (MSB) NTP (LSB)

RTP Timestamp Sender’s packet count Sender’s octet count

Inter arrival jitter

Fraction lost Extended highest seq number received

SSRC_1

Last SR Delay since last SR

Length PT = SR = 200 RC P

Cumulative number of packets lost

SSRC_2 ….................


24

Version (V)(2): Same as in RTP. Padding (P)(1): Same as in RTP. Reception report count (RC)(5): Indicates the number of reception report blocks it contains. Packet type (PT)(8): SR report packet has a packet type of 200. Length (16): The length of the packet is given in 32 bit words minus one. SSRC: Same as in RTP. NTP Time stamp (64): NTP indicates the wall clock time when this packet is sent. This information is used to measure round-trip propagation delay. RTP Time stamp: Same as in RTP. These time stamps are used for media synchronization. Sender’s packet count (32): This field indicates the number of RTP data packets transmitted by the sender from the starting of the session up until this SR packet has been transmitted. Sender’s octet count (32): The total number of payload octets sent from the start of the session. Fraction lost: The fraction of RTP packets lost since the previous SR or RR packet is sent. Cumulative number of packets lost (24): The total number of RTP data packets lost from the beginning of the session. Extended highest sequence number received (32): The low 16 bits contain the highest sequence number received in an RTP data packet and the high 16 bits extend that sequence number with the corresponding number of sequence number cycles. Inter-arrival jitter (32): An estimation of the statistical variance of the RTP data packet arrival time measured in time stamp units and expressed as an unsigned integer. Last SR timestamp (32): Contains the middle 32 bits of 64 bits in the NTP time stamp received as part of the most recent RTCP SR packet. Delay since last SR (DLSR) (32): The delay expressed in units of 1 in 65536 seconds, between the last SR packet and this RR packet. The RR packet structure is same as that of SR, except that it will not contain the sender related fields (NTP, RTP time stamps, packet and octet count). 3.1.3. XML - Extensible Mark-up Language XML is a mark-up language for documents containing structured information. Structured information contains both content (words, pictures, etc.) and some indication of what role that content plays (for example, content in a section heading has a different meaning from content in a footnote). Almost all documents have some structure. A mark-up language is a mechanism to identify structures in a document. The XML specification defines a standard way to add mark-up to documents [6].


25

3.1.4. XCAP – XML Configuration Access Protocol XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP.

3.2. Architecture The PoC architecture is constructed by several small entities, each entity handling a different part of the system. The architecture consists of the following central entities:

• PoC Client – Gives the user access to the PoC service.

• PoC Server – Contains the PoC service.

• SIP/IP Core – Handles sessions, SIP routing, authentication and

authorization.

• GLMS – Stores and manages groups and lists.

• Presence Server – Manages presence information.

The PoC architecture entities, and the interfaces between them, are shown in Figure 5. They are also described in detail further down in the report.


26

PoC Client

GLMS

Im

Is

If

It

AC

CESS N

ETWO

RK

SIP / IP Core

Ik Presence Server

Ipl

Ips

PoC Server

Rem

ote PoC N

etwork

In

Itn

GLMS Management/Administration

Ie

Igs

Figure 5: The PoC architecture.

3.3. Entities 3.3.1. PoC Client The PoC Client resides on the mobile terminal. It gives the user access to PoC services. The main purpose for the PoC Client is to send and receive messages via the PoC Server. It uses three different interfaces (Im, Is and It) to communicate with the PoC infrastructure. The Im interface is used for list and group management, the Is interface for session and presence handling and the It interface for media transmissions. The PoC Client performs the following functions:

• PoC session initiation, participation and termination.

• Generate talk bursts for transmission and reproduce received talk bursts.

• Registration and authentication with the PoC Infrastructure.

• Provide access to PoC group lists.


27

• Support floor control procedures.

• Provide access to PoC subscriber for managing PoC group lists.

• Provide access to presence conditions of the PoC subscriber.

3.3.2. PoC Server The PoC Server contains the PoC service. The main goal for the PoC Server is to handle sessions and to distribute media from one user to all other users in the talk session. The PoC Server also handles the following functions:

• Access control

• Do Not Disturb

• Floor control

• Talker identification

• Participants information

• Quality feedback

• Charging reports

3.3.3. GLMS – Group List Management Server The GLMS is used for storage and management of the groups and lists that are needed for the PoC service. It handles the creation, modification, retrieval and deletion of groups and lists. There are three types of lists:

• Contact lists – stores contact entities in the GLMS.

• Group lists – defines PoC groups.

• Access lists – defines who’s allowed to reach a specific user.

A contact list is a kind of address book that may be used by PoC users to establish an instant talk session with other PoC users or PoC Groups. A user may have one or several contact lists, containing identities of other PoC users or PoC Groups. A group list is a list of user defined PoC groups. The end user may select one group from the list to initiate an instant group talk session or a chat group talk session depending on the type of the group.


28

An access list is used by the end user as means of controlling who is allowed to initiate instant talk sessions to the end user. An access list contains end user defined identities of other PoC end users or groups. The end user may have one reject list and one accept list. 3.3.4. Presence Server The Presence Server manages presence information. It is responsible for combining the presence-related information for a certain user from the information it receives from multiple sources into a single presence document. The presence server handles the publication, watching and fetching of Presence Information, it also handles the authorization for watching and fetching. The authorization is done based on authorization rules stored in the Presence Server. A user can have one of the following statuses:

• Reachable

• Do Not Disturb

• Busy

• Unavailable

• Offline

3.3.5. SIP/IP Core The SIP/IP Core is the first point of contact for the PoC client. It is based on IMS and includes a number of SIP proxies and SIP registrars. The PoC client sends all of its SIP messages to the IP address of the outbound proxy, after resolving the SIP URI of the outbound proxy to an IP address. The SIP/IP Core handles all routing of SIP signaling between the PoC Client and the PoC Server. The SIP/IP Core also performs the following functions that are needed in support of the PoC Service:

• Discovery and address resolution

• SIP compression

• Authentication and authorization of PoC Clients

• Maintains the registration state

• Charging information


29

3.4. Interfaces The entities in the system communicate through a series of interfaces. Most of the interfaces use well-known protocols like SIP and RTP. There are however interfaces that have not been specified yet. 3.4.1. Is interface The Is interface supports the communication between the PoC Client and the SIP/IP Core. The protocol for the Is interface is SIP (Session Initiation Protocol), transported with UDP. The Is interface supports:

• Session signaling between the PoC client and the PoC server

• Discovery and address resolution

• Authentication and authorization

• Registration

• Publishing of presence information

• Subscribing to presence information

• Receiving of presence notifications

• Subscription to modification by the GLMS of lists.

• Notification of modification by the GLMS of lists

3.4.2. It interface The It interface is used for transporting media, floor control and link quality messages between the PoC Client and the PoC Server. It uses RTP and RTCP. 3.4.3. Itn interface The Itn interface supports the communication between the PoC servers. It supports media transport and floor control procedures. It uses RTP and RTCP. 3.4.4. Im interface The Im interface is used for the communication between the PoC Client and the GLMS for the purpose of managing the groups, contact lists and access lists. The Im interface uses the XCAP protocol and gives the PoC Client the capability to create, modify, retrieve and delete groups and lists


30

3.4.5. In interface The In interface supports the communication and forwarding of SIP signaling messaging between SIP/IP Cores. The interface is based on SIP. 3.4.6. Ik interface The Ik interface supports the communication between the PoC Server and the GLMS. It enables the PoC Server to retrieve the groups and access lists from the GLMS. It is not yet specified which protocol it will use. 3.4.7. If interface The If interface supports the communication between the SIP/IP Core and the PoC Server for session control. The If interface is based on SIP. It supports session signaling, address resolution, charging information and publication, subscription and notification of Presence Information by the Presence Server to the PoC Server 3.4.8. Ipl interface The Ipl interface supports the communication between the GLMS and the Presence Server. It enables transference of presence lists, group lists and subscription authorization policies to the Presence Server. It is not yet specified which protocol it will use. 3.4.9. Ips interface The Ips interface supports the communication between the SIP/IP Core and the Presence Server. It enables uploading of the registration status from the SIP/IP Core to the Presence Server and the distribution of the presence information between the presence server and the PoC Client. Ips is based on SIP. 3.4.10. Igs interface The Igs interface supports the communication between the GLMS and the SIP/IP Core. It handles subscription and notification of the modification of lists. It is not yet specified which protocol it will use. 3.4.11. Ie interface The Ie interface is between the GLMS and GLMS Management/Administration entity. This entity can act on behalf of end users and administrators subject to service providers access control policies. Access may be provided via the intranet, internet or corporate networks. The Ie interface provides the capability to create, modify, retrieve and delete groups and lists. It is not yet specified which protocol it will use, but it will most likely be XCAP.


31

3.5. Identification and Usage Each user shall be assigned a public user identity and a private user identity. The public identifier is in the form of a SIP URI and consists of a user and a host part. The user part uniquely identifies the user while the host part identifies a domain owned by the operator. A SIP URI should look something like this [email protected]. The private URI has a similar purpose but it is hidden from other users and can not be used for addressing. It shall take the form of a NAI and has the form username@realm. Each group has a group identifier, it is associated with the individual identifiers of all group members. The group identifier is generated by the GLMS and has the form of a SIP URI. The PoC Clients uses the group identifier to address the group, the PoC server then distributes the message to all members of the group. A user can also be addressed by a phone number, TEL URI. The PoC Client sends the TEL URI to the SIP/IP Core that resolves it to a SIP URI. This is done by using a DNS/ENUM or other local database. The PoC Client must register itself with the SIP/IP Core before using the PoC Service. This gives the SIP/IP Core the opportunity to bind the current IP address and port to the public user identity. Once it is registered it can invite, or be invited by, other users to talk sessions. A Talk session can be with one person or a group of persons. The groups can be either predefined or ad-hoc. The talk session will use the media capability of the user with the lowest bandwidth. The establishment phase of the talk session is different depending on how the following alternatives are combined. Early Session – Both parties have an early session established. Early Media Procedure – The inviter can begin to talk before someone accepts. Late Media Procedure – The inviter has to wait until someone accepts. Auto Answer – Calls are automatically accepted. Manuel Answer – Calls have to be manually accepted. Once the talk session has been initialized the inviter is given the floor, the right to talk, and can send his message to the others. When he is finished he releases the PTT-button and the floor becomes idle so that anyone can take it and send their message to the group. Example (Instant personal talk scenario) This example describes an instant personal talk end-to-end session combining early media establishment with auto answering. The signaling flow in Figure 6 is built on the following scenario: The user at Client 1:

1. Presses the PTT-button.

2. Receives a “beeping” signal when a media channel is established.


32

3. The user starts to talk.

4. Releases the PTT-button.

5. Receives a “beeping” sound that the floor is taken by the other user.

6. Receives speech from the other user.

7. Receives a beeping sound when the floor is idle again.

The user at Client 2 (configured for auto answer):

1. Receives a “beeping” sound in the loud speaker.

2. Listens to the user at Client 1 speech phrase.

3. Receives a “beeping” sound that the floor is idle.

4. Presses the PTT-button.

5. Receives a “beeping” sound that that the user can start to speak.

6. The user talks.

7. The user releases the PTT-button.

Client 1 Client 2 SIP/IP Core PoC Server SIP/IP Core

Figure 6: Instant personal talk signaling flow [3].


33

3.6. PoC applicability to PDC The PPDC system enables data transmissions in the PDC system. It utilizes a packet switch system allowing a data transfer rate of 28.8 kbps in downlink and 9.6 kbps in uplink. The Mobile System (MS) is dynamically assigned an IP address that is retained until it deregisters. The MS can connect to an Application Server (AS), which can contain IP-based services from both local and external sources like the Internet. The packet data switching functionality between MSs and ASs is handled by the Packet Mobile services Switching Center (PMSC). It routes and forwards IP packets and provides mobility management functions that allow MSs to keep their communication links while moving. The PoC specification defines a half-duplex Voice over IP solution over standard mobile networks. The Core of the PoC network is IMS (IP Multimedia Subsystem), a standardized architecture for peer-to-peer communication over IP. It uses SIP to handle talk sessions and RTP to transfer the audio. SIP can run on top of several different transport protocols, UDP being one of them. It uses Signal Compression (SigComp) to compress messages to a fraction of their original size. RTP is designed to be independent of the underlying transport and network layers. It typically runs on top of UDP to make use of its multiplexing and checksum services. The audio is encoded by using the AMR (Adaptive Multi Rate) codec, which allows it to encode the audio at different frequencies depending on the bandwidth available. Since the PoC specification can be implemented on any IP network and that the PPDC network is an IP network it is concluded that PoC is completely applicable to the PDC network. The PoC client will run on a MS, a PPDC enabled mobile phone. It will receive an IP-address from the PMSC, enabling it to communicate with an AS where the PoC server, SIP core, Presence server and GLMS is running. The AS is also connected to the Internet making it possible to connect a PDC PoC client with a PoC client on another IP-network. The AS uses an ordinary UNIX platform, so it is not a problem running applications on it. The only possible problem is the low bandwidth of the uplink, 9.6 kbps, which might result in a low sound quality.

34

35

4. Implementation of a PoC prototype To test the applicability of the PoC specification to the PDC network a prototype was implemented. Due to the size of the PoC specification only the most central parts of the system was implemented. A user guide to the implemented prototype can be found in Appendix B.

4.1. Hardware and software The prototype was implemented in Java (J2SE 1.4.2) under Windows 2000 and Redhat 8.0. It uses two additional packages, JMF [14] (Java Media Framework 2.1.1e) and JAIN SIP[9]. JMF enables audio, video and other time-based media to be added to applications and applets built on Java technology. It can capture, play, stream, and transcode multiple media formats. JAIN SIP is a SIP API that supplies the tools for SIP communication. Java was selected because it was required that the client would be implemented in Java, to ease portability, and that there are programming synergises if all components are implemented in the same programming language. The code was mainly written using the text editor jEdit, with the exception of the initial GUI that was written in Borland JBuilder 4 Professional. The prototype was tested on three PCs with Windows XP. This test was mainly performed so that the SIP Core and the PoC Server application could be executed on one machine and two separate PoC clients on separate machines. There is also a PDC test lab at TietoEnator where it was originally planed to test the prototype, this was later cut due to new safety procedures and time deficiency. It is however not a problem that the prototype was not tested in the PDC network. The difference for the prototype would have been the platform, the platform used in the PDC lab is UNIX. Since Java is platform independent this would not have been any problem. There are of course other differences, like the network, but they would not affect the prototype.

4.2. Limitations Because of the size of the PoC specification, and the lack of information in it, some parts where dropped. The GLMS and the network-to-network communication were dropped in an early stage. The reason for this was that they had the least effect on the system and that XML and XCAP could be dropped. It was also decided that a codec that already exists in JMF would be used instead of AMR, which is specified in the PoC standard, and that no compression would be used. These changes will result in a higher bandwidth usage. Both the early session and early media procedure were also dropped. Later on the Presence

Chapter 4. Implementation of a PoC prototype

36

server was also dropped, which means that it will not be possible to distinguish the presence status of the other users.

4.3. Design and implementation Three separate applications will be implemented in the prototype, the PoC Client, the SIP/IP Core and the PoC Server, shown in Figure 7. Since all of them communicate with one or more of the parts that are not implemented in the prototype it will diverge from the PoC specification as follows:

• There will be no presence information shown, the status of the other users will always be display as online.

• The contact list will only exist on the client, due to the absence of the GLMS.

• The PoC server will contain static group lists instead of receiving them from the GLMS. This means that the clients can not contact users in a new group using the group’s address.

• The sound will use the GSM audio format instead of AMR. • Only the late media procedure will be used. • There will be no accept list or reject list, everyone will be treated as if they

are in the accept list.

PoCclient

Is (SIP) If (SIP)

It (RTP)

SIP

/ IP Core (IM

S)

PoC Server

Figure 7: Implemented parts of the PoC architecture.


37

4.3.1. The Client The main purpose for the client is to give the user access to the PoC service in a fast and easy way. It accomplishes this by combining a graphical user interface with the two communication protocols SIP and RTP. The client has to wait for user actions, SIP messages and RTP messages at once. This is accomplished by using threads. The client also handles sound recording and playback. All this combined makes it by far the most complex component in the system. The client’s user interface is built to resemble both a mobile phone and an instant message application. The reason for this is to make it as realistic as possible and use an already well-known design. It has about the same size as a large mobile phone display and uses many icons that resemble those used on mobile phones and in instant message applications. The user interface can be divided into two areas, data area and tool area.

Figure 8: The Client with the user tree opened. The data area displays and collects most of the information, like the user tree, settings, active sessions and so on. It changes content depending on what the user is doing. The tool area on the other hand pretty much remains the same, its appearance may change some depending on the status of the user. The tool area is mostly used to perform actions, but it also displays some information like the status of the user and the floor. The tool area can be separated into four parts, the status list, the settings list, the talk button and the disconnect button. The status list is used to choose and display the current status of the user. There are five different states to choose from, Online, Offline, Do Not Disturb, Busy and Not available. The settings list is a little bit more complicated. It supplies a list of options for the user to select from. It always has the Settings option available, but the rest of the list changes based on whether a contact list, group or user is selected. The talk button is used to invite users, take the floor and release the floor. The disconnect button is only used to end the current session.

Data area

Tool area


38

4.3.2. The SIP Core The SIP Core uses JAIN SIP to communicate and basically just waits for incoming SIP-messages. Its main purpose is to keep track of who is registered and to which IP-address, and to forward the messages to the right IP-address. When it receives a register-message it will bind the clients SIP URI to its current IP-address. All other messages are essentially just forwarded to the right address, a PoC server or another client. 4.3.3. The PoC Server The PoC Server utilizes both JAIN SIP and JMF to communicate over both SIP and RTP. Its main purpose is to handle talk sessions and forward sound streams to the users in the talk sessions. It uses SIP for setting them up and taking them down. When a session is up RTCP is used to control the floor, it is a control protocol for RTP. For the actual sound streaming RTP is used.

4.4. Testing The system has been tested on three PCs running Windows XP. One was used for the SIP Core and the PoC Server. The other two were used for clients. The SIP Core and Server was at the longest up for twenty-four hours and there where at the most six clients online at the same time. The SIP Core and the PoC Server experienced no problems during the testing. Although the tests were short and that the number of clients was low it indicates that the SIP Core and the PoC Server are stable. The clients that were used during the tests also worked without any problems. There is at most a one second delay in the speech and a session setup takes less than two seconds, when automatic answer is used. The PoC specification defines that the speech delay should typically be no more then 1.6 seconds and the setup time should be below 4 seconds. The bandwidth used is most of the time minimal, the only exception is when speech is sent, it then uses 2.5 Kbytes/s.

4.5. Problems encountered The main problem was the PoC specification. It was incomplete and some parts had hardly any information, which of course made it impossible to follow it accurately. The other part was the size of the assignment in relationship to the time given, which resulted in that a lot of important parts had to be left out of the prototype, both the GLMS and the presence server were dropped. This resulted in a somewhat crippled prototype. Besides the PoC specification the only real problem was JMF. JMF does not give full access to RTCP, for example the creation of RTCP APP packets was not


39

supported in normal usage. This meant that the RTP-connection had to be created and used in a slightly different way then it was initially planed, an RTP connection is created for each user instead of a common one for each Session. The second problem with JMF, which might be a result of the first, was the duplication of media streams. When the duplication was initially tested, as a separate program, there were no problems. But when it was implemented in the PoC server it did not work. The difference in the two implementations is that the RTP-connection is used in a slightly different way and that the stream is received from an RTP-connection and then duplicated, instead of being duplicated first and then transmitted.

40

41

5. Conclusions The PoC specification can be implemented on any IP network and is designed to use a low bandwidth. Since the PPDC network is an IP network it is concluded that PoC is completely applicable to the PDC network. The PoC server, SIP core, Presence server and GLMS could run on the Application Server and the PoC client could then reach them from a PPDC enabled mobile phone. Since the Application Server is also connected to the Internet it is possible to connect PDC PoC clients with PoC clients on other IP-networks. The resulting prototype uses both SIP and RTP in a manor similar to the PoC specification. Even thou the PoC specification were followed as much as possible it is unlikely that the prototype is compatible with other existing PoC implementations. This because there were too many unclear and undefined parts in the specification and that some parts were not implemented. The prototype works as planed except for one thing, group sessions. The reason for this is that the data source in the server could not be cloned, which means that only one data stream could be sent out of the server making it impossible for more the one client to receive the data stream. Hence there are no group sessions available in the prototype. The excluding of group sessions means that it is impossible to join sessions, since there is never only one person in a session. The prototype uses 2.5 Kbyte/s (20 Kbit/s) of bandwidth when sound is transmitted. Since the PPDC system only supports 9.6 Kbit/s in the uplink the prototype can not be used in the PPDC system. This problem should be taken care of if the AMR codec is used, as defined in the PoC specification.

42

43

6. References [1] Dorgham Sisalem, Jiri Kuthan, Understanding SIP,

http://www.iptel.org/sip/siptutorial.pdf, 2004-04-15 [2] Ericsson, Instant Talk,

http://www.ericsson.com/products/product_selector/-Inst_Talk_hpsol.shtml, 2004-08-09

[3] Ericsson, Motorola, Nokia, Siemens, PoC-Signalling Flows-1.1.3, PoC-Signalling Flows-1.1.3.pdf, 2004-04-14 [4] Ericsson Radio System AB, PPDC System Description [5] Hellosoft, Real Time Protocol, http://www.hellosoft.com/resources/documents/rtp.pdf, 2004-04-13 [6] Ian Poole, Personal Digital Cellular (PDC), http://www.radio-

electronics.com/-info/cellulartelecomms/pdc/pdcsummary.htm, 2004-08-20 [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R.

Sparks, M. Handley, E. Schooler, SIP: Session Initiation Protocol, http://www.ietf.org/rfc/rfc3261.txt?number=3261, 2004-03-29 [8] Mats Lewan, Nokia och Ericsson oense om mobil walkie-talkie, http://www.nyteknik.se/pub/ipsart.asp?art_id=33839, 2004-04-13 [9] National Institute of Standards and Technology, About the IP telephony

project, http://snad.ncsl.nist.gov/proj/iptel/, 2004-08-10 [10] Niclas Medman, Krister Svanbro, Per Synnergren, Ericsson Instant Talk, http://www.ericsson.com/about/publications/review/2004_01/files/200401

2.pdf, 2004-08-09 [11] Norman Walsh, A Technical Introduction to XML, http://www.xml.com/pub/a/98/10/guide0.html, 2004-03-24 [12] Northstream AB, Overview and comparison of Push-to-talk solutions,

http://www.northstream.se/download/Overview%20and%20comparison%20of%20Push-to-talk%20solutions.pdf, 2004-08-09

[13] SPG Media Limited, PDC (PERSONAL DIGITAL CELLULAR)

TELEPHONE TECHNOLOGY, http://www.mobilecomms-technology.com/projects/pdc/, 2004-08-20

Chapter 6. References

44

[14] Sun Microsystems, Java Media Framework API, http://java.sun.com/products/java-media/jmf/, 2004-08-10 [15] The SIP Center, What is SIP?, http://www.sipcenter.com/aboutsip/whatissip.html, 2004-03-24 [16] Ubiquity Software Corporation, Understanding SIP,

http://www.ubiquity.net/pdf/UnderstandSIP_WP_072203.pdf, 2004-03-24 [17] Wikipedia, Voice over IP, http://en.wikipedia.org/wiki/Voice_over_IP,

2004-09-12

45

Appendix A Abbreviations 3GPP Third Generation Partnership Project AMR Adaptive Multi Rate EGPRS Enhanced GPRS ETSI European Telecommunications Standards Institute GLMS Group List Management Server GPRS General Packet Radio Service IETF Internet Engineering Task Force ITU International Telecommunications Union JMF Java Media Framework OMA Open Mobile Alliance HTTP Hyper Text Transfer protocol NAI Network Access Identifier PoC Push-to-talk over Cellular PTT Push-to-talk RTP Real-time Transfer Protocol RTCP Real-time Transfer Control Protocol SDP Session Description Protocol SIP Session Initiation Protocol SMTP Simple Mail Transfer Protocol TIA Telecommunications Industry Association UDP User Datagram Protocol UE User Equipment UMTS Universal Mobile Telecommunications Service URI Uniform Resource Identifier VoIP Voice over IP XCAP XML Configuration Access Protocol XML Extensible Mark-up Language

46

47

Appendix B User guide The user guide explains how the client part of the prototype is used.

When the system is started it automatically displays the user tree. In this case it is almost empty, the Default node is merely there to show that there should be a tree here. The next step is to create the user tree. This is done with the options list. By pressing it while the Default node is selected the following options will appear:

• Settings is used to edit one’s own client.

• Add Group is used to add a group to the CL (Contact List).

• The other three are used to add a new CL, edit an existing or delete one.

If New Contact L is chosen the following window will appear. The user can now set the options for the Contact List.

• Name is the name of the CL. • Type is the type of the CL, user or

group type. A CL can either contain users or groups, not both.

• Default is used to decide if the CL is the default one, there can only be one default CL.

In this case the new CL is named Friends and it will contain groups. The CL is also set to be default.

Appendix B. User guide

48

When the CL has been added it appears in the user tree. The next step is to add a group to the CL. This is done by marking the Friends CL and choosing the Add Group option from the options list. The Add Group window lets the user create and set the options for a new group.

• Group Name is the name of the group. • Max users are the maximum number of

users allowed in a group session with this group.

• Type is the type of the group, Instant or Chat and Restricted or Open.

• The Reject list is a list containing users that are not allowed to join the group.

When the group has been added it will appear in the user tree. Since the CL is no longer empty it will change its appearance. The next step is to add a user to the group. This is done by selecting the group and then using the options list to add a user. The options list will now display a different list of options to choose from.


49

If the user decides to add a user to the group the Add User window will appear.

• SIP URI is the address of the user to be added.

• Name is the nickname of the user, this is the name that will be displayed in the user tree.

The user has now been added to the group. Since there is no presence server in this prototype all the users are shown as online. If the user selects a user the options list will change accordingly. The next step is to add more CLs, groups and users to the user tree. A finished user tree can look something like this. The next step is to enter the settings. This is done by selecting Settings from the options list.


50

The following settings can be set: • SIP URI is the address of the client. • Proxy is the IP-address to the SIP Core. • Port is the port number that the user will

use for SIP communication. • Auto Answer is used to determine if the

user wants to manually or automatically accept calls.

• Early media is not implemented in this prototype.

• Resizable is used to enable the size of the client to be changed.

Once the settings are correctly entered the user can go online. This is done by selecting the Online status in the status list. The status list contains five different statuses of availability stretching from the least available Offline to the most available Online. When the user becomes online the Talk and the Stop button becomes enabled. The client is now ready to participate in talk sessions. To invite someone the user selects that user from the user list. The user then presses the Talk button, the green phone. The invite is then sent through the PoC network to the selected client.


51

If the invited user accepts the invite its available status will change in the user tree to show that they are connected. The inviting user will then automatically be granted the floor. This is indicated by the red mouth on the Talk button. The user can now talk to the other user. To release the floor the user pushes the Talk button again. The floor then becomes idle and the Talk button once again becomes a green phone. When the floor is idle any of the two precipitants can request it by pushing the Talk button. If the other user takes the floor the user tree will display this by changing the other users available status to talking, a red mouth. The Talk button is also changed to display a loudspeaker. As long as the loudspeaker is shown the user can not take the floor. To end the talk session the user simply pushes the Stop button, the red phone. This can be done at any time. If a user is invited and auto answer is not selected the following window will appear. The window displays the SIP URI of the inviting user and lets the user chose to either accept or deny the invitation.

Documents

Push-to-talk in PDC Packet data network - umu.se · Push-to-talk in PDC Packet data network Internal Supervisor: Pedher Johansson External Supervisor: Håkan Nordmark. Abstract Push-to-talk