Chapter 25 - Push-to-talk over Cellular potx

Chapter 25

Push-to-talk over Cellular

Push-to-talk over Cellular (PoC) was the first IMS-based service deployed by several mobile

operators because it does not require the deployment of new radio technologies. PoC can

run on top of low-bandwidth and high-delay links, which are inappropriate for running other

types of services, such as voice calls.

PoC is a walkie-talkie type of service. Users press (and hold) a button when they want to

say something, but they do not start speaking until their terminal tells them to do so (usually

by beeping). At this point, users say whatever they want to say and signal the end of their

speech by releasing the button.

Unlike regular voice calls, which are full-duplex, PoC is a half-duplex service; that is,

only one user can speak at a time.

PoC sessions can have more than two participants. At a given time, one user speaks and

the rest listen (as in the two-party case). A simple way of understanding a multiparty PoC is

a group of friends going to the movies. One at a time, they take turns to tell the rest which

movie they want to watch, at which point they can make the final choice (usually after some

extra rounds of discussions).

Even though Push-to-talk was originally designed to be a voice-only service, it currently

supports different media types such as streamed video and instant messages.

25.1 PoC Standardization

When the definition of the PoC service started there were several incompatible PoC

specifications. Many were not based on the IMS, but consisted of proprietary solutions

implemented by a single vendor. As a result these PoC solutions generally could not

interoperate with equipment from other vendors.

Many operators willing to provide PoC services felt uncomfortable with the situation

just described and asked a few vendors for a standard solution based on the IMS. As a

consequence, a group of vendors teamed up to develop an open PoC industry standard. These

vendors were Ericsson, Motorola, Nokia, and Siemens. The result of this collaboration was

a set of publicly available PoC specifications.

It was clear that a widely-accepted PoC standard which took into account the require￾ments of most of the industry was needed. The industry standard was a good starting point,

but there was still a long way to go before having a fully-featured PoC service. This situation

prompted the OMA (Open Mobile Alliance) to create the PoC working group to start working

ıa- ´ Martın´

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition

Gonzalo Camarillo and Miguel A. Garc

© 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1

504 CHAPTER 25. PUSH-TO-TALK OVER CELLULAR

on the OMA PoC service. (For a description of OMA, its structure, and the different types of

recommendations it produces, see Section 2.6.)

OMA decided to base its PoC service on the IMS. So, the consortium that developed the

PoC industry standard provided OMA with their PoC specifications, which were also based

on the IMS. These specifications were taken as the starting point for the OMA PoC standard.

At the same time the IETF started working on some building blocks that were missing in

SIP and in the conferencing architecture to be able to provide a fully-featured PoC service.

These building blocks were needed by the OMA for its PoC service.

Section 25.2 covers the building blocks developed by the IETF that are relevant to PoC.

Section 25.3 describes the PoC service as standardized by the OMA.

As you have probably noticed, we have not introduced a chapter called “PoC on the

Internet” as we have done with other services covered in this book. Instead, we describe

the relevant IETF specifications in Section 25.2. We have chosen to do so because the IETF

has not defined a PoC framework. The IETF has a conferencing framework and, from the

IETF perspective, PoC is just a conference. A conference that uses a set of extensions (e.g.,

conference establishment using request-contained lists) and a particular floor control policy,

but a conference nevertheless.

25.2 IETF Work Relevant to PoC

Given that a PoC session is, at the end of the day, a conference, all of the work developed

in the IETF on conferencing is very relevant to PoC. As described in Chapter 23, there are

two main IETF Working Groups (WGs) involved in this conferencing work: SIPPING and

XCON.

The SIPPING WG has developed a set of extensions to establish conferences using SIP.

However, conferencing-related issues that do not have to do with SIP (e.g., floor control) are

outside the scope of the SIPPING WG. These issues are typically handled by the XCON WG,

which focuses on centralized conferences.

Chapter 23 discusses the work on general conferencing developed by these two WGs.

This work includes BFCP (specified RFC 4582 [106]), which is a floor control protocol

specifically designed so that its messages are small enough to be used with BFCP in low￾bandwidth radio environments such as those in which PoC is expected to work.

In addition to the work on general conferencing just discussed, the IETF has developed

a set of extensions to SIP that are referred to as URI-list services (see Section 25.2.1). The

IETF developed these extensions after noticing that some of the OMA PoC requirements

related to multiparty sessions could not be met by existing IETF technology.

The IETF has also developed two SIP extensions that only apply to the OMA PoC service:

an event package to discover the settings of a PoC terminal (specified in RFC 4354 [148])

and a set of SIP header fields (specified in RFC 4964 [73] and the Internet-Draft “Requesting

Answering Modes for SIP” [315]).

25.2.1 URI-list Services

Some services involve multiple very similar transactions. For example, a user may need to

send a page-mode instant message to a number of friends telling them at what time they

should meet in the movie theater. The user would send one message to each friend; however,

all of the messages would have the same contents (e.g., “Let’s meet at seven.”). If the user of

our example sits on a low-bandwidth access, sending all of those messages can take a while.