Chapter 25 - Push-to-talk over Cellular potx

For example, the interface between the SharedXDMS and the Presence Server is referred to as PRS-5 and is based on XCAP.The PoC Server uses SIP to communicate with the SIP/IP Core over th

Chapter 25

Push-to-talk over Cellular

Push-to-talk over Cellular (PoC) was the first IMS-based service deployed by several mobileoperators because it does not require the deployment of new radio technologies PoC canrun on top of low-bandwidth and high-delay links, which are inappropriate for running othertypes of services, such as voice calls

PoC is a walkie-talkie type of service Users press (and hold) a button when they want tosay 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 theirspeech 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 andthe 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 whichmovie they want to watch, at which point they can make the final choice (usually after someextra rounds of discussions)

Even though Push-to-talk was originally designed to be a voice-only service, it currentlysupports 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 PoCspecifications Many were not based on the IMS, but consisted of proprietary solutionsimplemented by a single vendor As a result these PoC solutions generally could notinteroperate with equipment from other vendors

Many operators willing to provide PoC services felt uncomfortable with the situationjust described and asked a few vendors for a standard solution based on the IMS As aconsequence, a group of vendors teamed up to develop an open PoC industry standard Thesevendors 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 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 situationprompted the OMA (Open Mobile Alliance) to create the PoC working group to start working

require-´ıa- M ar t´ı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

on the OMA PoC service (For a description of OMA, its structure, and the different types ofrecommendations it produces, see Section 2.6.)

OMA decided to base its PoC service on the IMS So, the consortium that developed thePoC 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 inSIP 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 theInternet” as we have done with other services covered in this book Instead, we describethe relevant IETF specifications in Section 25.2 We have chosen to do so because the IETFhas not defined a PoC framework The IETF has a conferencing framework and, from theIETF 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 aretwo main IETF Working Groups (WGs) involved in this conferencing work: SIPPING andXCON

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) areoutside 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 protocolspecifically 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) TheIETF developed these extensions after noticing that some of the OMA PoC requirementsrelated 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 “RequestingAnswering Modes for SIP” [315])

25.2.1 URI-list Services

Some services involve multiple very similar transactions For example, a user may need tosend a page-mode instant message to a number of friends telling them at what time theyshould 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 ofour example sits on a low-bandwidth access, sending all of those messages can take a while

25.2 IETF WORK RELEVANT TO PoC 505

URI-list services were designed for this type of situation (their framework is specified in theInternet-Draft “Requirements and Framework for Session Initiation Protocol (SIP) UniformResource Identifier (URI)-List Services” [107])

Servers providing a URI-list service perform a similar transaction to all of the members(identified by URIs) of a list provided by the user agent invoking the service InSection 21.6.1, we introduced a URI-list service for MESSAGE requests URI-list servicescan be applied to other requests as well The idea is always the same The URI-list servicereceives a request with a URI-list and sends similar requests to the URIs on the list

In addition to the URI-list service for MESSAGE (specified in the Internet-Draft

“Multiple-Recipient MESSAGE Requests in SIP” [153]), there are URI-list services definedfor methods such as INVITE (specified in the Internet-Draft “Conference EstablishmentUsing Request-Contained Lists in SIP” [102]) and SUBSCRIBE (specified in the Internet-Draft “Subscriptions to Request-Contained Resource Lists in SIP” [108]) The INVITEURI-list service can be used to establish a conference with multiple participants and theSUBSCRIBE URI-list service can be used to subscribe to the presence information of severalusers

25.2.1.1 Multiple REFER

An extension that may seem like a URI-service but is not is the multiple-REFER extension(specified in the Internet-Draft “Referring to Multiple Resources in SIP” [105]) Thedifference between this extension and the URI-list services is that, while a URI-list servicereplicates the same transaction towards a set of users, the recipient of a multiple REFERexecutes the transaction identified by the Refer-To header field (which does not need to be

a REFER transaction) For example, a user may send a REFER to a conference focus so thatthe focus INVITEs a number of new users into the conference, as shown in Figure 25.1

Figure 25.1: Multiple REFER

Since multiple REFERs are typically used within the context of an application, the useragent generating it generally has an application-specific means to discover the result ofthe transactions initiated by the server (in our example, the INVITE transactions initiated

by the conference focus) In the conferencing example, the user may use the conference

event package to discover which users were brought into the conference successfully.Consequently, multiple REFERs are normally combined with an extension (specified inRFC 4488 [207]) that eliminates the implicit subscription that is usually linked to REFER.Once again, the subscription to the results of the transactions initiated by the server iseliminated by that extension That is why Figure 25.1 does not show any NOTIFY requestsfrom the conference focus to Alice (see Section 4.18 for a discussion of the REFER methodand its implicit subscription).

Both URI-list services and multiple-REFER are used by PoC URI-list services are used

to establish multiparty PoC sessions (INVITE URI-list service) and to send multiple-recipientpage-mode instant messages (MESSAGE URI-list service) Multiple-REFER is used to invitemultiple users to a PoC session

25.2.1.2 URI-list Format

A user agent using a URI-list service or generating a multiple REFER needs to include alist of URIs in its request The default format for these lists is supposed to be service-specific, but effectively, all of the URI-list services defined so far and multiple-REFERuse the same URI-list format This format is based on XML and is a simplified version(e.g., hierarchical lists are not allowed) of the general format for representing resource lists(specified in RFC 4826 [273])

Figure 25.2 shows an example of an INVITE request that carries two body parts: an SDPsession description and a URI list in the XML-based format just described

URIs in a URI lists can also carry copyControl attributes (specified in the Internet Draft

“XML Format Extension for Representing Copy Control Attributes in Resource Lists” [152])

A copyControl describes why a message was delivered to a particular URI It performs thesame function as the To: and Cc: header fields in email

25.2.1.3 Consent-based Communications

As we have already stated, URI-list services allow user agents using low-bandwidth accesses

to request the generation of a potentially large number of transactions towards a set of URIs.While this type of service is a great tool for implementing services such as PoC, serversproviding URI-list services could be used as traffic amplifiers to launch DoS attacks

An attacker would just need to generate a single request with a URI list containing theURIs of the victims The attacker would send this request to a URI-list service The URI-listservice would then flood the members of the list with undesired traffic

This type of attack is similar to a form of email SPAM, where the attacker places theemail address of the victim on a distribution list The victim keeps receiving the messagessent to the distribution list but has no means to unsubscribe from the list

In order to avoid this type of attack in SIP, URI-list services need to obtain permissionfrom the recipients before sending them any traffic Effectively, they implement a form ofconsent-based communication (as specified in the Internet-Draft “A Framework for Consent-Based Communications in SIP” [279]) where entities need to agree to communicate beforethe actual communication takes place

OMA has not yet studied how to apply this consent framework to PoC Therefore, at thispoint, PoC does not use this framework

25.2 IETF WORK RELEVANT TO PoC 507

INVITE sip:conf-fact@example.com SIP/2.0

Via: SIP/2.0/TCP client.chicago.example.com

;branch=z9hG4bKhjhs8ass83

Max-Forwards: 70

To: Conf Factory <sip:conf-fact@example.com>

From: Carol <sip:carol@chicago.example.com>;tag=32331

25.2.2 Event Package for PoC Settings

In the PoC service, situations in which the network needs to be informed about the settings of

a PoC terminal occur For example, if a PoC terminal is in don’t disturb mode (i.e., the

terminal will reject all incoming session invitations) the network can reject directly anysession invitation for the terminal Sending the invitation to the terminal, only to have itrejected, would consume radio resources unnecessarily

A terminal keeps its home PoC server updated on the terminal’s settings by sendingPUBLISH requests (whose bodies follow the format specified in RFC 4354 [148])

25.2.3 SIP Header Fields

The PoC server defines the concept of answer mode, which can be set to automatic or manual

A terminal in automatic answer mode accepts session invitations automatically, without anyuser intervention

The Answer-Mode header field (specified in the Internet-Draft “Requesting AnsweringModes for SIP” [315]) carries information related to the answer mode The Answer-Modeheader field can be inserted into an INVITE request to request a particular answer mode fromthe callee In addition, the callee can insert this header field in a response to indicate whichanswer mode was actually applied

The P-Answer-State header field (specified in RFC 4964 [73]) can be included in aresponse to an INVITE to indicate which entity (the user agent server or an intermediary)generated the response The use of both header fields is further described in the followingsections

25.3 Architecture

In this section we look at the architecture of the PoC service (as specified in the CandidateEnabler Release Package for PoC Version 2.0 [243]) Figure 25.3 indicates the nodes involved

in PoC and the interfaces between them

The User Equipment contains six logical elements: the DM (Device Management) client,the presence source, the watcher, the PoC client, the UE (User Equipment) PoC Box, andthe XDMC (XML Document Management Client) The DM client uses the OMA DeviceManagement Protocol (as specified in the OMA Device Management Enabler [241]) tocommunicate with the DM server over the DM-1 interface

The presence source and the watcher use SIP (as specified in the OMA Presence SimpleEnabler [242]) to communicate with the SIP/IP core over the PRS-1 and PRS-2 interfaces,respectively The PoC client uses SIP to communicate with the SIP/IP Core over the POC-1interface, and RTP, MSRP, and MBCP (Media Burst Control Protocol) to communicate withthe PoC server over the POC-3 interface MBCP is a floor control protocol based on RTCPthat is used to signal which user is allowed to send media at a given time

The UE PoC Box uses SIP to communicate with the SIP/IP Core over the POC-9interface, and RTP, MSRP, and MBCP to communicate with the PoC server over the POC-10interface The UE PoC Box (and the NW PoC Box) can store data that can be retrieved bythe user at a later point

The XDMC (as specified in the OMA XML Document Management Candidate abler [244]) uses SIP to communicate with the SIP/IP Core over the XDM-1 interface andXCAP to communicate with the Aggregation Proxy over the XDM-3 interface The XDM-3

En-25.3 ARCHITECTURE 509

Figure 25.3: PoC architecture

Figure 25.4: Structure of the Shared XDMS

interface is used to perform document management (e.g., set up a URI list with the user’sgolf buddies) and the XDM-2 interface is used to subscribe to changes in documents that arestored in the network

The Aggregation Proxy acts as a single point for the XDMC to contact the network TheAggregation Proxy performs user authentication and routes the XCAP messages from theXDMC (received over the XDM-3 interface) to the appropriate XDMS The Aggregationproxy uses XCAP to communicate with the NW PoC Box over the PB-1 interface and withthe Shared XDMS over the XDM-4 interface

The NW PoC Box uses SIP to communicate with the SIP/IP Core over the POC-11interface, and RTP, MSRP, and MBCP to communicate with the PoC server over the POC-12interface

The Shared XDMS uses XCAP to communicate with the Aggregation Proxy over theXDM-4 interface and with the PoC Server over the POC-13 interface Since the documentsmanaged by the Shared XDMS may be shared with other services, the Shared XDMS hasadditional interfaces towards those services For example, the interface between the SharedXDMS and the Presence Server is referred to as PRS-5 and is based on XCAP.

The PoC Server uses SIP to communicate with the SIP/IP Core over the POC-2 interface

In addition, it uses RTP and MBCP to communicate with the PoC Client over the POC-3interface and with other PoC networks over the POC-4 interface Furthermore, the PoCserver uses XCAP to communicate with the Shared XDMS over the POC-13 interface.The SIP/IP Core can be realized in different ways Nevertheless, we expect that it willusually be realized by using the IMS Consequently, the SIP/IP Core cloud would correspond

to the IMS (as described in 3GPP TR 23.979 [6])

Table 25.1 shows the protocols used in the different interfaces

Table 25.1: PoC interfaces

Interface Protocol

POC-3 RTP / MSRP / MBCPPOC-4 RTP / MSRP / MBCP

POC-10 RTP / MSRP / MBCPPOC-11 SIP

The +g.poc.talkburst feature tag indicates that the terminal can handle PoC sessions.The +g.poc.groupad feature tag indicates that the terminal can handle group advertisement(see Section 25.8)

25.5 PoC SERVER ROLES 511

25.5 PoC Server Roles

A PoC server within a session can perform two roles: Controlling PoC Function orParticipating PoC Function A given PoC server in a given PoC session will be performingone or both roles However, only one PoC server in a session performs the Controlling PoCFunction This server may or may not perform the Participating PoC Function as well Therest of the PoC servers, assuming that there are several PoC servers involved in the session,will only perform the Participating PoC Function

The PoC server performing the Controlling PoC Function is usually referred to as thecontrolling PoC server Similarly, the PoC servers performing the Participating PoC Functionare usually referred to as participating PoC servers

Figure 25.5 shows a PoC session with one controlling and four participating PoC servers.Each of the PoC servers is in a different domain In order to simplify this and other figures

in this chapter, we do not show all of the elements involved in the session That is, we do notshow the IMS nodes between the different PoC entities

Controlling PoC Server

Participating PoC Server Participating

PoC Server

Participating

SIP + media + floor control traffic

Figure 25.5: PoC session with a central controlling PoC server

The controlling PoC server provides centralized PoC session handling This includesmedia distribution, centralized floor control, and policy enforcement for participation ingroup sessions The participating PoC server exchanges SIP signaling with the client andwith the controlling PoC server and, optionally, relays media and floor control messagesbetween them When a participating PoC server chooses not to be on the media path, clientsexchange media and floor control traffic directly with the controlling PoC server

Figure 25.6 shows another PoC session where the controlling PoC server is co-locatedwith a participating PoC server That is, the same PoC server performs both roles at the sametime

The process of determining which of the PoC servers involved in a session acts as thecontrolling PoC server depends on the type of the session Section 25.6 describes the different

Participating PoC Server Participating

SIP + media + floor control traffic

Figure 25.6: Controlling and participating PoC server

PoC session types and discusses the procedures to determine the controlling PoC server ineach

25.6 PoC Session Types

PoC defines the following session types or communication modes

One-to-one A PoC session between two users.

Ad-hoc PoC Group A user selects a set of users in an ad-hoc fashion (e.g., picking them

from the terminal’s address book) and invites all of them into a multiparty PoC session

Pre-arranged PoC Group Similar to the ad-hoc PoC group, the pre-arranged PoC group

also consists of a multiparty PoC session Nevertheless, the users participating in the

session are selected beforehand, not in an ad-hoc manner when it is established That

is, a pre-arranged PoC group includes a predefined set of users (e.g., the user’s golfbuddies)

Chat PoC Group Chat PoC groups are also multiparty PoC sessions However, when a

user joins a chat PoC group, no invitations are sent to other users Conversely, when auser joins a pre-arranged PoC group, all of the users that belong to that PoC group areinvited to the PoC session

These PoC session types are classified into two forms of PoC sessions: one-to-one and

one-to-many One-to-many PoC sessions include ad-hoc, pre-arranged, and chat PoC groups.

Now, let us look at the signaling involved in the establishment of the different sessiontypes In addition, we discuss which PoC server is selected as the controlling PoC server

25.6 PoC SESSION TYPES 513

in each session type However, before looking at these issues, we would like to provide animportant clarification

PoC defines two session establishment types: using on-demand signaling and using a pre-established session Both session establishment types are discussed in Section 25.9 In the following message flows, we discuss session establishment procedures using only on- demand signaling The use of a pre-established session is an optimization, which is described

in Section 25.9

25.6.1 One-to-one PoC Sessions

In one-to-one PoC sessions, the controlling PoC server is the inviting user’s PoC server That

is, this PoC server is, at the same time, the participating PoC server of the inviting user andthe controlling PoC server for the session

Figure 25.7 shows the message flow for one-to-one PoC session establishment In thismessage flow, we have included the SIP/IP Core in order to illustrate how filter criteria areused to route requests to the PoC servers In subsequent message flows, we do not show theSIP/IP Core for the sake of clarity

Figure 25.7: One-to-one PoC session establishment

The PoC terminal generates an INVITE (1) which is addressed to its home PoC server.The INVITE contains two body parts: an SDP session description and a URI list The URIlist contains the URI of the callee.

On receiving the INVITE (1), the originating user’s S-CSCF, as usual, evaluates the initialfilter criteria for the user and finally forwards the INVITE request on to the PoC server.When the PoC server receives the INVITE request (3), it forwards it (5) towards the homedomain of the callee

The S-CSCF of the terminating user receives the INVITE (5) and evaluates the initialfilter criteria for the terminating user According to the filter criteria, an incoming INVITErequest with the +g.poc.talkburst feature tag should be routed to the PoC server of thedomain

When the PoC server receives the INVITE (7), it generates a new INVITE (9) that will

be routed by the SIP/IP Core towards the terminating user

25.6.2 Ad-hoc PoC Group

In ad-hoc PoC group sessions, the controlling PoC server is the PoC server of the inviting

user That is, this PoC server is, at the same time, the inviting user’s participating PoC serverand the controlling PoC server for the session

Figure 25.8 shows the message flow for an ad-hoc PoC session establishment The

message flow is the same as that for one-to-one PoC sessions The only difference betweenboth cases is that, in the one-to-one case, the URI list contains the address of a single callee

whereas in the ad-hoc PoC group case the URI list contains the URIs of all of the callees.

On receiving INVITE (1), the controlling PoC server generates an INVITE towards each

of the URIs in the URI list This results in two INVITEs: (3) and (4) These INVITEscontain a single body part: an SDP session description The participating PoC servers routethese INVITEs towards the terminating terminals

25.6.3 Pre-arranged PoC Group

In pre-arranged PoC group sessions, the controlling PoC server is the PoC server hosting thepre-arranged PoC group That is, the controlling PoC server is the PoC server of the domainthat owns the URI that identifies the pre-arranged PoC group

Figure 25.9 shows the message flow for pre-arranged PoC group session establishment

In this example, the inviting user’s participating PoC server is not the controlling PoC serverbecause the pre-arranged PoC group is hosted in another domain

The INVITE (1) generated by the inviting terminal does not carry a URI list becausethe members of the pre-arranged PoC group have been previously set up in the network TheRequest-URI of this INVITE (1) identifies the pre-arranged PoC group at the controlling PoCserver

The inviting user’s PoC server behaves as a participating PoC server and, thus, relays theINVITE (3) to the controlling PoC server On receiving this INVITE (3), the controlling PoCserver invites all of the members of the pre-arranged PoC group

Some pre-arranged PoC groups use a special media distribution policy whereby a user(called the distinguished participant) can talk to the whole group and listen to the answersfrom each individual user (called ordinary participants) However, the rest of the users (theordinary participants) cannot talk or listen to each other They only talk and listen to the

25.6 PoC SESSION TYPES 515

Figure 25.8: Ad-hoc PoC group session establishment

distinguished participant When this form of media distribution is used in a pre-arrangedPoC group, the session is referred to as a one-to-many-to-one PoC session

There are scenarios where one-to-many-to-one PoC sessions are useful For example, ataxi dispatcher needs to inform all of the drivers about customers waiting for a taxi, but theindividual drivers answer only to the dispatcher Any given driver does not hear the answersfrom the other drivers to the dispatcher The terms of PoC Dispatcher and PoC Fleet Memberare defined to cover the scenario just described

The PoC Dispatcher of a pre-arranged PoC group can also send media to a subset of thePoC Fleet Members In order to indicate which PoC Fleet Members should be receiving

a given media burst, the PoC Dispatcher inserts a URI list in its INVITE request with theintended receivers

25.6.4 Chat PoC Group

In Chat PoC group sessions, the controlling PoC server is the PoC server hosting the chat PoCgroup That is, the controlling PoC server is the PoC server of the domain that owns the URIthat identifies the chat PoC group Chat PoC groups can be open or restricted A restrictedchat PoC group can only be joined only by users that are members of the chat PoC group