TelecommunicationSystems-SIP Protocol Extensions

7/31/2019 TelecommunicationSystems-SIP Protocol Extensions

1/133


2/133

2

Content

1 Overview .......................................................................................................................................... 51.1 Topic and Goal of Lesson...................................................................................................... 51.2 Exercises .................................................................................................................................. 51.3 Audience and Preconditions.................................................................................................. 5

2 The best way to proceed ............................................................................................................... 62.1 Recommendation of the Lecturer ......................................................................................... 62.2 Schedule and Timing.............................................................................................................. 6

3 Event State Publication ................................................................................................................. 73.1 The state publication model .................................................................................................. 83.2 Protocol overview .................................................................................................................. 103.3 Publish framework applied for presence ........................................................................... 11

4 Event Packages ............................................................................................................................ 154.1 Presence Event Package .................................................................................................... 15

4.1.1 Package definition ......................................................................................................... 154.1.2 Presence information .................................................................................................... 16

4.2 Watcher Information Event Template-Package............................................................... 224.3 An INVITE-Initiated Dialog Event Package for SIP......................................................... 244.4 Further event packages ....................................................................................................... 28

4.4.1 Message Summary and Message Waiting Indication Event .................................. 284.4.2 Event Package for Conference State......................................................................... 294.4.3 Event Package for Registrations................................................................................. 294.4.4 Refer event ..................................................................................................................... 304.4.5 Debug Event ................................................................................................................... 30

5 The UPDATE method .................................................................................................................. 316 Resource Management ............................................................................................................... 33

6.1 Protocol overview .................................................................................................................. 346.2 SDP parameters and attributes .......................................................................................... 366.3 Option Tag.............................................................................................................................. 38

7 Third Party Session Control........................................................................................................ 398 REFER Method ............................................................................................................................. 40

8.1 Referred-By header field ...................................................................................................... 428.2 Replaces header field........................................................................................................... 43

9 Conferencing ................................................................................................................................. 489.1 Tightly Coupled SIP Conference ........................................................................................ 49

9.1.1 Creation of an Ad-hoc conference .............................................................................. 509.1.2 Immediate Conference creation with a URI list ........................................................ 51


3/133

3

9.1.3 Floor Control ................................................................................................................... 529.2 Decentralized Conferencing ................................................................................................ 529.3 Joining a conference............................................................................................................. 529.4 Join header field .................................................................................................................... 53

10 SIP Based Messaging ............................................................................................................... 5410.1 Page Mode Instant Messaging ......................................................................................... 5410.2 Session Mode Instant Messaging with MSRP ............................................................... 55

11 INFO method............................................................................................................................... 5912 Service Configuration ................................................................................................................ 62

12.1 Overview on XML................................................................................................................ 6212.2 The XML Configuration Access Protocol (XCAP) ......................................................... 6312.2.1 XCAP Overview ........................................................................................................... 6312.2.2 XCAP Application usage ............................................................................................ 6512.2.3 XCAP URIs ................................................................................................................... 6512.2.4 Entity Tags and conditional operations.................................................................... 6612.2.5 Subscriptions to changes in XML documents......................................................... 68

13 NAT and Firewall Traversal ...................................................................................................... 7113.1 Network Address Translation............................................................................................ 7113.2 Firewalls................................................................................................................................ 7213.3 Problems caused by NAT and Firewall Traversal ......................................................... 7313.4 SIP Protocol Enhancements ............................................................................................. 75

13.4.1 Symmetric Response Routing ................................................................................... 7513.4.2 Symmetric RTP/RTCP................................................................................................ 7613.4.3 RTCP attribute in SDP................................................................................................ 77

13.5 Classical NAT and FW Traversal Solutions ................................................................... 7713.5.1 NAT and FW categorisation....................................................................................... 7813.5.2 (Classic) STUN protocol ............................................................................................. 79

13.6 The perfect NAT and FW Traversal Solution ................................................................. 8013.6.1 NAT and FW Behavior Requirements...................................................................... 8113.6.2 The new STUN protocol ............................................................................................. 8213.6.3 Traversal Using Relays around NAT (TURN)......................................................... 8613.6.4 Interactive Connectivity establishment .................................................................... 8913.6.5 Client initiated connections ........................................................................................ 92

13.7 External and proprietary Solutions ................................................................................... 9413.7.1 Application Layer Gateways ...................................................................................... 9413.7.2 UPnP.............................................................................................................................. 9513.7.3 Skype ............................................................................................................................. 9513.7.4 SIP Express Router..................................................................................................... 95

14 Session Timer ............................................................................................................................. 9715 Caller Preferences and UA Capabilities ............................................................................... 101

15.1 User Agent Capabilities ................................................................................................... 10115.1.1 Feature tags ............................................................................................................... 102


4/133

4

15.1.2 Expression of capabilities......................................................................................... 10315.2 Caller Preferences ............................................................................................................ 104

15.2.1 Feature preferences .................................................................................................. 10415.2.2 Request handling preferences ................................................................................ 105

16 Global Routable User URI (GRUU)....................................................................................... 10717 Identity Management ............................................................................................................... 11118 ENUM ......................................................................................................................................... 11519 Privacy Mechanism .................................................................................................................. 11720 Reason ....................................................................................................................................... 11921 Path............................................................................................................................................. 12022 Service-Route ........................................................................................................................... 12223 Request History ........................................................................................................................ 12424 SIP-Connected-Id..................................................................................................................... 12725 Questions................................................................................................................................... 129


5/133

5

1 Overview1.1 Topic and Goal of LessonThe main topic of the Lecture is the basic understanding of the Session Initiation Protocol (SIP).

This protocol has its origin in the Internet standardization but was later on also accepted by

traditional network operators as the basis for a modern IP based network architecture.

This is the second lecture note on SIP. It builds on the content of the first lecture note (basic SIP

protocol) and covers some of the most important protocol extensions to SIP with a specific view of

the application of SIP in commercial operator networks including IMS1

.

At the end of the lesson the student will have a good understanding of SIP. He will be able to

analyze SIP message flows and perhaps find bugs and is able to identify misbehavior in

implementations. In ideal case the lesson will be accompanied by practical exercises in the lab

using e.g. open source implementations of SIP servers2 and free SIP clients. A VMware3 image is

always available at the University institute which enables the student to verify and enhance the

basic knowledge on SIP by running a SIP server on the own notebook computer.

The lecture will also encourage the interested student to look into RFCs in certain situations to get

first-hand information on more details of the protocol and to get acquainted with reading an RFC.

1.2 ExercisesThe last chapter of the lecture note includes a list of questions on each chapter which the student

should be able to answer after the lecture. These questions are also good basis for preparing to

the final examination.

1.3 Audience and PreconditionsThe lecture is targeted to students of the University of Applied Sciences in master courses. A

good understanding of the basic Internet protocols (TCP/IP, DNS etc) is required.

1 IMS = IP Multimedia Subsystem; a SIP based network architecture used by fixed and mobile network operators2

Examples of open source SIP servers are:

Kamailio - the Open Source SIP Server athttp://www.kamailio.org/

The OpenSIPS Project at:http://www.opensips.org/SER - SIP Express Router (the mother of above projects) at:http://www.iptel.org/

3 VMware: A SW - virtualization product to run e.g. a GNU/Linux server on a notebook computer on top of

Windows
http://www.kamailio.org/http://www.kamailio.org/http://www.kamailio.org/http://www.opensips.org/http://www.opensips.org/http://www.opensips.org/http://www.iptel.org/http://www.iptel.org/http://www.iptel.org/http://www.iptel.org/http://www.opensips.org/http://www.kamailio.org/


6/133

6

2 The best way to proceed2.1 Recommendation of the LecturerThe lecturer expects the students to prepare themselves according to the schedule of the lecture.

The student should read the relevant chapters of the lecture note in advance, listen to the lecture

and raise hands for questions if something is not as clear as it should be.

2.2 Schedule and TimingThe actual schedule of the lesson can be found on the intranet web-site.

Do not under-estimate the complexity of SIP and start early to ask questions!

In ideal case as already mentioned the theoretical stuff should be accompanied by practical

experience. Ask the lecturer for advice if required.


7/133

7

3 Event State PublicationThe event notification framework4 has already been explained in the first lecture note. It is based

on SUBSCRIBE and NOTIFY requests. It enables a watcher to subscribe on a specific event and a

notifier to send spontaneous notifications about state changes. This model has sometimes

scalability problems in case of many resources and watchers. The principle problem is shown in

Figure 1. There are six users where some of them subscribe to the presence state of some other

users. The scalability problem becomes obvious when we imagine a group of 20 or more users

interested in each other presence state.

Alice Bob

Charly

David

Esther

Frank

Figure 1: Mutual subscription to presence state information

To overcome the scalability issue a framework for publishing event states5 has been defined.

Without this extension a resource has to send all NOTIFY requests itself and will probably run into

performance problems when the group of watchers becomes large. The event publishing

framework enables an event publishing agent (EPA) to publish its state change to an event state

compositor (ESC) which aggregates the state from various EPAs of a resource. The aggregated

state is offered to a state agent, which acts on behalf of the resource and processes SUBSCRIBE

4 RFC 3265: SIP-Specific Event Notification5 RFC 3903: SIP Extension for Event State Publication


8/133

8

requests from watchers and sends NOTIFY requests in response. The resources never get any of

the SUBSCRIBE requests.

Thus the task of sending NOTIFY requests is delegated to a state agent which is implemented on

a powerful server. A further advantage of publishing mechanism is that the state agent may

correlate and composite state information of a distributed resource to a single NOTIFY request,

which means a reduction in network traffic.

3.1 The state publication modelThe above mentioned state publication model is shown in Figure 2.

Event StateCompositor

Event PublishingAgent 2


StateAgent

PUB

LISH

PUB

LISH PU

BLIS

H

Watcher 2

SUBSCRIBENOTIFY


Watcher 1

SUBSCRIBENOTIFY

Figure 2: State publication model

In this example the event state compositor receives state information about a distributed resource,

aggregates this information and offers it to a state agent. The state agent acts on behalf of the

resources, receives the SUBSCRIBE requests of watchers and sends NOTIFY requests when the

(composite) state changes.

As a practical example we may apply this concept to the well-known presence state. This means:

A resource (the presence state of a person6) may use three user agents which publish

presence state (e.g. notebook, PDA and phone). Each of the user agents publishes its

actual state (on-line/off-line) to the event state compositor using a PUBLISH request.

6For the presence entity of a person also the term presentity has been defined.


9/133


10/133

10

3.2 Protocol overviewRFC 3903 defines a new SIP method, PUBLISH, for publishing event state. A PUBLISH request iscomparable to a REGISTER request. It allows a user to create, modify, and remove state in a

State Agent (compareable to a registrar). The State Agent manages the state on behalf of the user.

The user may have multiple User Agents or endpoints that publish event state. Each endpoint may

publish its own unique state, out of which the event state compositor generates the composite

event state of the resource. In addition to a particular resource, all published event state is

associated with a specific event package. With a subscription to that event package, a watcher is

able to discover the composite event state of all of the active publications.

The User Agent Client (UAC) that publishes event state is called an Event Publication Agent(EPA). The entity that processes the PUBLISH request is called an Event State Compositor

(ESC).

An interesting question is how the Request URI of PUBLISH and SUBSCRIBE requests is

populated. The answer is: The R-URI of PUBLISH and SUBSCRIBE requests is set to the AoR of

the resource. This means that unlike an INVITE request, where the inbound proxy queries the

location database and forwards the request to the actual location of a user agent, SUBSCRIBE

and PUBLISH requests have to be routed to the State Agent if a State Agent is used. This requires

a special handling of SUBSCRIBE and PUBLISH requests at an inbound proxy server.

PUBLISH requests create soft state information in the ESC. This event soft state has a defined

lifetime and will expire after a negotiated amount of time, requiring the publication to be refreshed

by subsequent PUBLISH requests. There may also be a hard state information provisioned for

each resource for a particular event package. The hard state represents state information that is

present at all times and does not expire. The ESC may use event hard state in the absence of, or

in addition to, soft state information provided through the PUBLISH mechanism.

The body of a PUBLISH request carries the published event state. In response to every

successful PUBLISH request, the ESC assigns an identifier to the publication in the form of an

entity-tag (ETag). The entity tag is used to keep state information in-sync between the resource(EPA) and state agent. The EPA includes a SIP-ETag header field in any subsequent PUBLISH

request that modifies, refreshes or removes the event state of that publication. When the event

state expires or is explicitly removed, the entity-tag associated with it becomes invalid.

An Expires header field in a PUBLISH request designates the life time of a published soft state.

The ESC may accept or perhaps shorten that interval but it will never increase that value. If the life-

time interval of a published state is too short for an ESC it will reject the PUBLISH request with a

423 (Interval Too Brief) response containing a Min-Expires value which the EPA has to follow. This

is the same mechanism as used by the REGISTRAR with the Expires header field value in

REGISTER requests.

For the PUBLISH request two new header fields are defined:


11/133

11

SIP-ETag: This header field is generated by the ESC and contains an Entity-Tag.

Whenever an ESC receives a PUBLISH request it marks its actual state with a SIP-ETag

value and returns this value in an 200 (OK) response. The ETag value is then used by the

EPA to distinguish initial state publication from refreshes and modifications.

SIP-If-Match: The EPA re-uses the latest SIP-ETag value received from the ESC and

repeats that value in a new PUBLISH request. The first (initial) PUBLISH request of an EPA

does not contain a SIP-If-Match header field.

The different publication operations are distinguished by the presence of the SIP-If-Match header

field, the presence of a message body and the value of the Expires header field according to table

below.

Operation PUBLISH contains a

message body

PUBLISH contains a

SIP-If-Match header field

Expires

value

Initial yes no > 0

Refresh no yes > 0

Modify yes yes > 0

Remove no yes 0

In case the entity tag in the SIP-If-Match header field in a PUBLISH request does not contain the

expected value the ESC will reject the request with a failure response 412 (Conditional Request

Failed). This is a new failure response code defined by RFC 3903.

3.3 Publish framework applied for presenceThe first application for the PUBLISH framework was the presence event. In this case a specific

terminology is used:

The Event Publishing Agent (EPA) is called the Presence User Agent (PUA)

The Event State Compositor is called Presence Compositor

The State Agent is called Presence Agent (PA)

More details on the presence event package can be found in chapter 4.1 on page 15.

Figure 4 shows the content of an initial PUBLISH request and the 200 (OK) response for a

presence event. The actual state information for presence within the message body is not shown in

this figure. It is an XML formatted Presence Information Data Format (PIDF) document.


12/133

12

PUBLISH sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge

To:

From: ;tag=1234wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Max-Forwards: 70

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: ...

[Published PIDF document]

SIP/2.0 200 OK

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge

;received=192.0.2.3

To: ;tag=1a2b3c4d

From: ;tag=1234wxyz


CSeq: 1 PUBLISH

SIP-ETag: dx200xyz

Expires: 1800

Figure 4: PUBLISH initial state publication

The initial PUBLISH request does not include an SIP-If-Match header field but the 200 (OK)

contains a SIP-ETag header field as expected. The example also shows that the Presence Server

has reduced the Expires header field value in 200 (OK) from 3600 to 1800 (seconds).

The next figure (Figure 5) shows a state refresh cycle when the presence agent determines that

the previously published state of Figure 4 is about to expire. The PUBLISH request now uses the

value of the previously received SIP-ETag in the SIP-If-Match header field. It does not contain amessage body because the state did not change.

In the 200 (OK) response the presence server inserts a new SIP-ETag value. As no state change

has occurred the presence server in this case does not send any NOTIFY requests (refer also to

Figure 3).


13/133

13

PUBLISH sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02To:

From: ;tag=1234kljk


CSeq: 1 PUBLISH

Max-Forwards: 70

SIP-If-Match: dx200xyz

Expires: 1800

Event: presence

Content-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP

pua.example.com;branch=z9hG4bK771ash02;received=192.0.2.3

To: ;tag=2affde434

From: ;tag=1234kljk


CSeq: 1 PUBLISH

SIP-ETag: kwj449x

Expires: 1800

Figure 5: PUBLISH state refresh

Figure 6 shows the situation of a state change of a presence user agent. When the PUA detects a

change of state it sends a PUBLISH request with an updated state information in the message

body. The SIP-If-Match header field again refers to the last received entity tag value.


14/133

14

PUBLISH sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2To:

From: ;tag=54321mm


CSeq: 1 PUBLISH

Max-Forwards: 70

SIP-If-Match: kwj449x

Expires: 1800

Event: presence

Content-Type: application/pidf+xml

Content-Length: ...

[Published PIDF Document]

SIP/2.0 200 OK

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2

;received=192.0.2.3

To: ;tag=effe22aa

From: ;tag=54321mm


CSeq: 1 PUBLISH

SIP-ETag: qwi982ks

Expires: 1800

Figure 6: PUBLISH state change


15/133


16/133

16

XML document server (XDMS). Centralised XML documents can be provisioned by the XCAP9

protocol.

The authorisation rules may define different levels of authorisation, so that not every watcher will

get the same amount of information. A geographic location information can be part of the presence

state but will perhaps not be offered to everybody.

In case an authorisation cannot be solved immediately via some policy rules the SUBSCRIBE

request is answered with a 202 (Accepted) response and the Subscription-State header field is set

to pending. The NOTIFY request in this case (which must be sent in any case when a

SUBSCRIBE has been received) will only contain a neutral or dummy state information. The owner

of the presentity may be notified of the new authorisation request by subscribing to a watcherinformation event on its own presence. The watcher information event is a kind of meta event

which can be applied to every event package. Further details on the watcher information event can

be found in chapter 4.2 on page 18.

Message Bodies

The SUBSCRIBE request may contain a message body describing some filter information. A filter

may reduce the amount of state information to only a specific aspect where the watcher may be

interested in, e.g. the possibility to send instant messages.

The NOTIFY request contains the presence state information, the format of which may havedifferent levels. It may be the simple PIDF based information or enriched by various extensions

(see next chapter). In any case the format of the NOTIFY message body must correlate to the

format the watcher is able to understand (Accept header field of SUBSCRIBE request).

4.1.2 Presence information

The structure of a presence document is based on the PIDF data model defined in RFC 385910

which is compliant to the Common Profile for Presence (CPP11). Both documents define the

protocol neutral presence data format.

PIDF data format

The PIDF based presence information is very limited in describing presence (this was the price for

interoperability). It is denoted as application/pidf+xml in the Accept and Content-type header

field of SIP messages (e.g. SUBSCRIBE and NOTIFY requests).

Figure 7 shows a simple PIDF example and Figure 8 shows the structure behind PIDF.

9RFC 4825: The XML Configuration Access Protocol (XCAP)

10 RFC 3859: Presence Information Data Format11 RFC 3589: Common Profile for Presence


17/133

17

open

tel:+09012345678

Figure 7: Simple presence data in PIDF structure

#n

#n

#n

#n

The element contains- an entity element with the name of the presentity- the namespace declaration

Tuples provide a way of segmenting presence information;Each element must contain an id attribute

The optional element contains either open or closed,expressing the ability to receive instant messages

element is optional, contains a communicatiuons address,may contain a priority attribute

element is optional, may contain a human readable comment

element is optional and contains date and time of statuschange of this tuple

The Presence Data Model (RFC 4479) uses this two extensionelements for the and components

#n

#n

Figure 8: Structure of PIDF (Presence Information Data Format)


18/133

18

Data model for presence

The PIDF data format for presence has been used by the SIMPLE group as the basis of a

presence data model12. This data model for presence offers the possibility to map real-world

communications systems built around SIP in particular into a presence document.

There are three components assigned to a presentity in the data model: the person, the service

and the device. Each attribute in a presence document is affiliated to the service, person or device

because they describe a facet of that service, presentity or device. Figure 9 shows that model and

possible relationships between the components.

The person component models information about the presentity under consideration. A person

may represent a group such as a help desk. Examples of presence attributes related to a person

are her/his activity, her/his willingness to communicate, her/his picture. The model supports only

one person component per presentity.

The service data components model the forms of commun ications for interacting with the

presentity. Examples of services through which a presentity may communicate are sessions

(audio, video), Instant Messaging, E-mail etc.

The device data components model the physical equipment in which services execute: for

instance a PC, a PDA, or a mobile phone. A given service may execute in more than one device,

therefore the mapping of services to devices is many to many. Devices are uniquely identified witha device ID.

Presentity URIPerson

Service Service Service

Device Device Device

Figure 9: Presence Data Model of SIMPLE

12 RFC 4479: A Data Model for Presence


19/133


20/133

20

The element describes what the person is currently doing. A person can be engagedin multiple activities at the same time, e.g., traveling and having a meal. This information enables a

watcher to evaluate how appropriate a communication attempt is and what is the better way for

communicating. Here are some examples of activities: away, appointment, meeting, meal,

breakfast, lunch, dinner, busy, holiday, in-transit, looking-for-work (for paid work), sleeping, travel...

Most of them can be derived from calendar information.

The element describes the class of the service, device, or person. Multiple elements can

have the same class name within a presence document, but each person, service, or device can

only have one class label. The naming of classes is left to the presentity.

The element represents a way to map a service component to a device component.

One service can be provided by multiple devices, so that each service tuple may contain zero or

more elements.

The element describes the mood of the person. For example: confused, amazed.

The element describes properties of the place the person is currently at. This offers the

watcher an indication of what kind of communication is likely to be successful. Each major media

type has its own set of attributes:

- audio (noisy, ok, quiet, unknown)

- video (toobright, ok, dark, unknown)

- text (uncomfortable, inappropriate, ok, unknown)

The element describes the type of place the person is currently at. This offers the

watcher an indication of what kind of communication is likely to be appropriate. The initial set of

values is defined in RFC458914

The element indicates which types of communication third parties in the vicinity of the

presentity are unlikely to be able to intercept accidentally or intentionally.

The element extends and designates the type of relationship an alternate

contact has with the presentity. This element is provided only if the tuple refers to somebody other

than the presentity. Relationship values include "family", "friend", "associate" (e.g., for a colleague),

"assistant", "supervisor", "self", and "unknown". The default is "self".

The element extends and designates the type of service offered:

electronic, postal, courier, freight, in-person...

The element designates the current state and role that the person plays. For example, it

might describe whether the person is in a work mode, at home, or participating in activities related

to some other organization such as the IETF or a church. RFC4480 does not define names for

these spheres except for two common ones, "work" and "home", as well as "unknown".

14 RFC4589: Location Types Registry


21/133


22/133

22

4.2 Watcher Information Event Template-PackageThe Watcher Information Event Template-Package18is a special meta-package which can beapplied to any event package. It is a regular SIP event package but it is always associated with

some other event package. The Watcher Information Event Template-Package is denoted with the

token "winfo" which is appended to the event name where it is applied.

For any event package, such as presence, there exists a set (perhaps an empty set) of

subscriptions that have been created or are requested by users trying to get the state of a resource

in that package. This set of subscriptions changes over time as new subscriptions are requested

by users, old subscriptions expire, and subscriptions are approved or rejected by the owners of

that resource. The set of users subscribed to a particular resource for a specific event package,and the state of their subscriptions, is referred to as watcher information. Since this state is itself

dynamic, it is reasonable to subscribe to it in order to learn about changes to it. The watcher

information event template-package is meant to facilitate exactly that - tracking the state of

subscriptions to a resource in another package.

The most prominent example usage of this event package is the presence event. When the

presence function is handled by a centralized presence agent the presentity does not recognize

anymore when a new watcher attempts to subscribe to its presence state. The watcher information

event package enables now the presentity to get notifications when the number or state of

watchers changes. The event package in this case is named presence.winfo".

Watcher

Watcher

PresenceAgent

Watcher

SUBSCRIBENOTIFY

SUBSCRIBENOTIFYSU

BSCRIBE

NOTIFY

Presentity

SUBSCR

IBE

presence

.winfo

NOTIFY

presence

.winfo

PUA

Figure 10: Application of Watcher Info event package to the presence event

18 RFC 3857: A Watcher Information Event Template-Package for SIP


23/133

23

The application of the watcher info event package to the presence event is illustrated in Figure 10.

An example SUBSCRIBE and NOTIFY request for presence.winfo package is shown inFigure

11. It shows the SUBSCRIBE request of the presentity B to its own watcher information event state

and the NOTIFY request it receives when A subscribes to B's presence. In this case the presence

subscription of A requires authorisation (status pending)..

SUBSCRIBE sip:[email protected]/2.0

Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7

From: sip:[email protected];tag=123s8a

To: sip:[email protected]


Max-Forwards: 70

CSeq: 9887 SUBSCRIBE

Contact: sip:[email protected]

Event: presence.winfo

NOTIFY sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna66g

From: sip:[email protected];tag=xyz887

To: sip:[email protected];tag=123s8a


Max-Forwards: 70

CSeq: 1288 NOTIFYContact: sip:[email protected]

Event: presence.winfo

Content-Type: application/watcherinfo+xml

Content-Length: ...

sip:[email protected]

Figure 11: SUBSCRIBE an NOTIFY on presence.winfo event package

The message body of the NOTIFY request contains a watcher information document. This

document describes some or all of the watchers for a resource within a given package, and the

state of their subscriptions. The format of the document is named application/watcherinfo+xml

and is defined in RFC 385819.

19 RFC 3858: An XML Based Format for Watcher Information


24/133

24

4.3 An INVITE-Initiated Dialog Event Package for SIPThere are situations before session setup or during a session where the knowledge about thedialog state of session partners may enable advanced applications. Examples for such applications

are:

Automatic call-back: This feature is already used in PSTN. When user A calls user B but

User B is busy user A would like to get a call-back when user B hangs up. When B hangs

up, user A's phone rings. When A picks up, they hear ringing, while they are being

connected to B. To implement this with SIP, a mechanism is required for A to receive a

notification when the dialogs at B are complete.

Presence enabled conferencing: In this application, user A wishes to set up a conferencecall with users B and C. Rather than being scheduled, the call is created automatically

when A, B and C are all available. To do this, the server providing the application would

like to know whether A, B, and C are "online", not idle, and not in a phone call. If the server

subscribes to the dialog state of those users it will receive notifications as these states

change.

Shared line services: These are services where a group of user agents share some

common identities and each user agent requires knowledge about the state of each other.

These applications can be supported by the INVITE-initiated dialog event package20. This event

package enables a user to subscribe to the dialog state of another user agent. Whenever the state

of the monitored user changes a NOTIFY request is sent.

There are of course some privacy concerns regarding this event package. Not everybody should

be able to see all details of activities of a user agent. Therefore several options are defined with the

event package. Provided that the user is authorised at all to get any dialog state information the

minimum information offered is the actual dialog state (e.g. idle/terminated, trying, proceeding,

confirmed) only. In contrast a maximum amount of state information may include detailed some

header fields and even SDP data about the sessions of the monitored user agent.

The event is named dialog and the message body of the NOTIFY requests carries the dialog

state information. The dialog state is transported in the message body of a NOTIFY request

formatted as an XML document named "application/dialog-info+xml".

20 RFC 4235: An INVITE-Initiated Dialog Event Package for SIP


25/133

25

Figure 12 shows an example of a minimum dialog state information carried in a dialog state XML

document.

confirmed

Figure 12: Minimum dialog state information XML document

The state information in Figure 12 shows the actual state of a dialog: confirmed. This means that

the user agent sending this information has received 200 (OK) and is engaged in a session. When

the session is finished the state information will change to terminated and again a NOTIFY

request will be sent. RFC 4235 defines a dialog state machine which specifies when a certain state

transition happens.

The XML document contains also a version, state and entity attribute. The version contains a

number which is incremented with every NOTIFY request, the state attribute describes the

information as either full or partial and the entity contains the URI that identifies the userwhose dialog information is provided.

The next example shows more detailed dialog state information. Figure 14 shows an INVITE

request sent by a UAC which is monitored by an INVITE-Initiated Dialog Event. This INVITE

request evokes a NOTIFY request with the XML document shown in Figure 14.

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8

Max-Forwards: 70

To: Bob

From: Alice ;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact:

Content-Type: application/sdp

Content-Length: 142

[SDP not shown]

Figure 13: Example INVITE request


26/133

26

trying

Figure 14: Corresponding XML document in a NOTIFY request

The XML document in Figure 14 also includes details of the dialog-ID . When the dialog setup

proceeds additional NOTIFY requests are sent with the state elements early and confirmed and

also the remote-tag attribute will be included.

The event package definition also allows to send partial state information where only the changed

parts are included.

The application of the INVITE initiated dialog event to implement an automatic call-back service is

shown in Figure 15.


27/133

27

User Agent A(Caller)

INVITE486 Busy

User Agent B(Callee)

ACK

User Agent A invites User Agent B.User Agent B is already engaged in a session andresponds with 486 (Busy).

User Agent A activates automatic call-back by

Subscription on the dialog event. The immediate

delivered XML document in NOTIFY message body

may look like:

terminated

When the dialog terminates also the subscriptionends automatically.

Now an automatic call-back may be started by

User Agent A.

SUBSCRIBE dialog200 OK

NOTIFY200 OK

After some time the session ofUser Agent B ends and sends a

NOTIFY request to User Agent A

NOTIFY200 OK

INVITE180 Ringing

. . .

Figure 15: Call-back service based on an INVITE initiated dialog event

RFC 4235 also defines two new media feature tags (see chapter 15.1 on page 101), whichsometimes are used in combination with an INVITE initiated dialog event:

sip.rendering: This feature tag indicates if the user agent is actually rendering any media stream.

It may take the values "yes", "no", and "unknown". The feature tag

sip.rendering=no indicates that the user agent actually ignores the media

stream received. This is typically used when putting a session partner on hold.

sip.byeless: This feature tag indicates that the user agent is able to terminate a session on its

own. This may be used by an announcement machine continuously playing an

announcement.


28/133

28

4.4 Further event packagesThe following event packages are not described in detail but only by a short description. Themethod is always the same. Whenever a possible application for a specific event is found an RFC

defining the details of the event package is created.

An actual overview on already defined event packages can be found at IANA, the official

registration authority for Internet numbers and protocol parameters. Event packages are registered

at:http://www.iana.org/assignments/sip-events/sip-events.xml

4.4.1 Message Summary and Message Waiting Indication Event

RFC 384221

defines an event to carry message waiting status and message summaries from amessaging system to an interested User Agent

Message Waiting Indication is a common feature of telephone networks. It typically involves an

audible or visible indication that messages are waiting, such as playing a special dial tone (which in

telephone networks is called message-waiting dial tone), lighting a light or indicator on the phone,

displaying icons or text, or some combination.

A User Agent (typically an IP phone or SIP software User Agent) subscribes to the status of its

messages. The notifier then notifies the Subscriber each time the messaging account's messages

have changed. It sends a message summary in the body of a NOTIFY, encoded as shown below

in Figure 16.

NOTIFY sip:[email protected] SIP/2.0

To: ;tag=78923

From: ;tag=4442

Date: Mon, 10 Jul 2000 04:28:53 GMT

Contact:


CSeq: 31 NOTIFY

Event: message-summary

Subscription-State: active

Content-Type: application/simple-message-summary

Content-Length: 503

Messages-Waiting: yes

Message-Account: sip:[email protected]

Voice-Message: 4/8 (1/2)

Figure 16: Message Summary and Message Waiting Indication Event

In this case the Content-type of message body is defined as application/simple-message-

summary, which is plain text based and not XML format. The numbers in the last line of the

21 RFC 3842: A Message Summary and Message Waiting Indication Event Package for SIP
http://www.iana.org/assignments/sip-events/sip-events.xmlhttp://www.iana.org/assignments/sip-events/sip-events.xmlhttp://www.iana.org/assignments/sip-events/sip-events.xmlhttp://www.iana.org/assignments/sip-events/sip-events.xml


29/133

29

message body show the summary of new/old messages and in parenthesis the summary of urgent

messages.

A User Agent may also explicitly fetch the current status by sending a SUBSCRIBE request with

Expires header field set to zero.

4.4.2 Event Package for Conference State

RFC 4575 defines an event package for conferencing state22.

In SIP, conferences are represented by URIs. These URIs identify a SIP user agent called a focus

that is responsible for ensuring that all users in the conference can communicate with each other.The conference package allows users to subscribe to a conference URI. Notifications are sent

about changes in the membership of this conference and optionally about changes in the state of

additional conference components.

The message body is defined as an XML document named conference -info+xml. The structure of

the XML document contains

- conference description

- conference-state

- users (identity, media information)

- sidebars

. etc

Due to the huge amount of data Notifications do not normally contain full state; rather, they only

indicate the state that has changed.

4.4.3 Event Package for Registrations

A rather unexpected event package has been required by the IMS (IP Multimedia Subsystem23)

standardisation group. This package fills a gap at registration procedure.

The registration is only a one-way procedure which allows the user to register at the network, butthere is no way for a network operator to actively de-register a user. Such a procedure is required

in commercial networks e.g. in case a user advises the operator that his/her mobile terminal was

lost or stolen. In this case the network nodes at the border of the network (P-CSCF24), which are

responsible for offering access to the network, are immediately informed about the user being de-

registered. To get this information the P-CSCFs subscribe to the registration event25.

22 RFC 4575: Event Package for Conference State23

IMS defines the SIP based the network architecture for carrier networks24 P-CSCF: Proxy Call Session Control Function25 RFC 3680: A SIP Event Package for Registrations


30/133

30

4.4.4 Refer event

The REFER request enables a user agent to request the recipient of the REFER request to refer to

a resource provided in the request. It also provides an implicit subscription mechanism allowing the

party sending the REFER to be notified of the outcome of the referenced request.

The NOTIFY sent after receipt of the REFER request informs the referrer about the outcome of

the requested action. Further details can be found in chapter 7 on page 39 at the description of the

REFER method.

4.4.5 Debug Event

For debugging purposes user agents and network nodes should be able to log and transfer debug-

messages (SIP trace) on occasion. This is handled by user agents and network nodes subscribing

to a debug event. The actual trigger conditions for starting the logging are transferred by a NOTIFY

request26.

26 SIP Event Package for Debugging: draft-dawes-sipping-debug-event


31/133


32/133

32


INVITE (with SDP offer 1)

180 Ringing (with SDP answer 1)

PRACK

200 OK

ACK

200 OK (on INVITE)

UPDATE (with SDP offer 2)

200 OK (with SDP answer 2)




Figure 17: UPDATE Call Flow

A user agent should be sure that the peer user agent supports the UPDATE method. Therefore the

INVITE request and the 180 (Ringing) response should contain an Allow header field showing

support for the UPDATE method.

An UPDATE request may also be used during confirmed dialogs (after INVITE transaction is

finished), but in that case a re-INVITE is recommended. The re-INVITE allows an approval of the

user due to the longer duration an INVITE-ACK may have, while an UPDATE request has to be

answered immediately.

The main application of the UPDATE requests is Resource Management as explained in the next

chapter.


33/133

33

6 Resource ManagementSome networks (e.g. mobile networks using SIP) require that at session establishment time, once

the callee has been alerted, the chances of a session establishment failure are a minimum. One

major source of failure in particular in mobile networks is the inability to reserve network resources

for a session. This could lead to so called ghost rings, where the callee is alerted but the session

cannot be setup successfully due to lack of resources. In order to minimize "ghost rings", it is

necessary to reserve network resources for the session before the callee is alerted.

However, the reservation of network resources frequently requires knowledge about the session

parameters from the callee. This information is obtained as a result of the initial offer/answer

exchange carried in SIP. This exchange normally causes the "phone to ring", thus introducing a

chicken-and-egg problem: resources cannot be reserved without performing an initial offer/answer

exchange, and the initial offer/answer exchange always causes alerting which might not be

appropriate as long as necessary resource are not reserved.

The solution to this problem is the concept of preconditions. Preconditions are a set of constraints

about the session which are introduced in the offer. The recipient of an offer including

preconditions generates an answer, but does not alert the user or otherwise proceed with

session establishment until the preconditions are met. The session setup is stopped until an eventoccurs that the preconditions are met. This can be a local event (such as a confirmation of a

resource reservation), or through a new offer sent by the caller.

The precondition issue is media stream specific. Therefore the solution is based on extending SDP

rather than by extending SIP. The solution is specified in RFC 331230.

Additional remark on Updates: The original RFC 3312 based solution is QoS specific. In the

meantime two additional applications for preconditions were identified:

Usage of preconditions to enable mobility solutions31

Usage of preconditions to enable protection of media streams (media security)32

30RFC 3312: Integration of Resource Management and SIP

31 RFC 4032: Update to SIP preconditions Framework32 RFC 5027: Security preconditions for SDP media streams


34/133

34

6.1 Protocol overviewThe basic idea of extending SDP for support of preconditions is to define two state variables that

affect the media stream: current status and desired status.

The desired status defines a threshold for the current status that must be reached. Session

establishment stops until the current status reaches or surpasses this threshold. Once this

threshold is reached or surpassed, session establishment resumes. For example, the following

values for current and desired status would not allow session establishment to resume:

current status = resources reserved in the send directiondesired status = resources reserved in both (sendrecv) directions

On the other hand, the values of the example below would make session establishment resume:

current status = resources reserved in both (sendrecv) directions

desired status = resources reserved in the send direction

These two state variables are mapped to new attributes for the media stream in SDP and are

exchanged with the offer/answer cycle. Thus both session partners have a shared view on the

resource situation and they know when they have to stop session setup to wait for a condition to be

met.

Figure 18 shows a basic session setup using SDP preconditions as it is applied in mobile

networks. User Agent A includes quality of service preconditions in the SDP of the initial INVITE.

User Agent A does not want User Agent B to be alerted until there are network resources reserved

in both directions end-to-end. User Agent B agrees to reserve network resources for this session

before alerting the callee. Both user agents will handle resource reservation in their local access

segment. This is the segment where in fact resources have to be reserved in a mobile network

(radio link).


35/133

35


INVITE (with SDP offer 1)

183 Session Progress (with SDP answer 1)

PRACK (with offer 2)

200 OK (with answer 2)

ACK

200 OK (on INVITE)




ResourceRese

rvation

Resource

Reservation

180 Ringing Alerting

Figure 18: Basic Session Setup using preconditions

User Agent B returns a 183 (Session Progress) response to User Agent A asking A to confirm

when resources have been reserved in the local segment of A. In mobile networks it is necessary

to agree on a specific codec before resource reservation can start due to different bandwidth

requirements of different codecs. In SDP answer 1 of the 183 (Session Progress) response there

might be more the one codec at disposal. Now User Agent A decides on the codec to be used

(because he/she probably has to pay for the session) und tells its decision also User Agent B in a

PRACK request containing offer 2.

With sending / receiving the PRACK request both sides start the resource reservation

mechanism33. User Agent A finishes resource reservation and informs User Agent B with an

UPDATE request. User Agent B has already finished resource reservation in above example and

now alerts the user and sends a 180 (Ringing) response. Then the session setup proceeds as

usual.

33The resource reservation mechanism is independent from SDP signaling and depends on the transport network

technology in place. A transport layer mechanism for QoS supported by most routers is RSVP

(RFC 2205: Resource Reservation Protocol).


36/133

36

6.2 SDP parameters and attributesThree new SDP attributes for preconditions are defineda=curr precondition-type status-type direction-tag

a=des precondition-type strength-tag status-type direction-tag

a=conf precondition-type status-type direction-tag

The current statusattribute curr carries the current status of network resources for a particular

media stream:

The desired status attribute descarries the preconditions for a particular media stream. When

the direction-tag of the current status attribute, with a given precondition-type/status-type for a

particular stream is equal to (or better than) the direction-tag of the desired status attribute with the

same precondition-type/status- type, for that stream, then the preconditions are considered to be

met for that stream.

The confirmation statusattribute conf carries threshold conditions for a media stream. When

the status of network resources reach these conditions, the peer user agent must send an update

of the session description containing an updated current status attribute for this particular media

stream (a confirmation).

The attributes use the following parameters:

precondition-type: RFC 3312 defines only one type for Quality of Service qos.

RFC 5027 defines additionally a precondition type for security sec.

status-type: This parameter indicates if preconditions have to be met end-to-end or only

segmented (values are: e2e local, remote).

strength-tag: This tag indicates whether the callee can be alerted in case the network fails

to meet the preconditions (values are "mandatory","optional","none", "failure", unknown")

direction-tag: This parameter indicates the direction in which a particular attribute is

applicable to (values are "none","send","recv","sendrecv").

Coming back to the example session setup with preconditions in Figure 18 the precondition

attributes in the SDP parts may be look as follows:

Offer 1: a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

This is the initial position of User Agent A. It will care for QoS on the local segment but

cannot do that for the remote segement.


37/133

37

Answer 1: a=curr:qos local none



a=des:qos mandatory remote sendrecv

a=conf:qos remote sendrecv

User Agent B will take care for it own local segment but requires a confirmation when

resources are reserved at the remote side. Otherwise it will not alert the user.

Offer 2: a=curr:qos local none




Offer 2 reflects the qos mandatory condition from the remote side. In addition the list

of codecs has been reduced to exactly one not shown here.

Answer 2: a=curr:qos local none


a=des:qos mandatory local sendrecva=des:qos mandatory remote sendrecv

a=conf:qos remote sendrecv

Nothing has been changed since Answer 1.

Offer 3: a=curr:qos local sendrecv




Now User Agent A confirms QoS readiness in its local segment.

Answer 3: a=curr:qos local sendrecv

a=curr:qos remote sendrecv



User Agent B reflects the availability of OoS readiness on the remote and local side.The user will be alerted now.


38/133

38

6.3 Option TagAs with many extensions of SIP protocol also the precondition extension defines an option tag,which can be used in the Require and Supported header field. If the SDP preconditions contain a

mandatory strength-tag then the user agent must use the precondition option tag in the Require

header like:

Require: precondition

If the peer user agent does not support preconditions the session setup is rejected.


39/133

39

7 Third Party Session ControlSessions are usually controlled (set-up and terminated) by the session partners themselves. But

there are situations where a third party (a controller) may be involved in session set-up. A practical

example is a click-to-dial service, where a web-site offers the set-up of a call. The session is then

set-up by some SIP code embedded in the web-site (3 rd party). Figure 19 shows how such a SIP

session can be set-up.

Party AThe controller sets up a call to Awith no SDP in the INVITE.A respondes with connection SDPdata in 200 OK. Controller sendshold SDP in ACK

Controller Party B

INVITE with no SDP

200 OK with SDP from A

ACK

INVITE with no SDP

200 OK with SDP from B

INVITE with SDP from B

200 OK with SDP from A

The controller sets up a call to Bwith no SDP in the INVITE.A respondes with connection SDPdata in 200 OK.

The controller re-INVITEs A withSDP data from B.A respondes with connection SDPdata in 200 OK (again).

ACK with SDP from AThe controller sends SDP from A toB in ACK and sends ACK to A. ACK

Media stream

BYEBYE

200 OK200 OK

A terminates the session with BYEand the controller sends BYE to B.Both transactions are confirmed.

Figure 19: Third party call-control

The message flow in Figure 19 makes use of the fact that an INVITE may be sent without an SDP.

In this case the SDP offer/answer has to be exchanged in 200 OK and ACK. The message flow

above is only one possibility for 3 rd party session set-up. RFC 372534 gives some more examples.

The example above once again shows the flexibility of SIP and its nature as a toolbox of functions

which may be combined to create some service. Note that all signaling is originated/terminated at

the controller, but media is sent directly between party A and party B. No additional SIP protocol

extensions are required for above behavior, just basic SIP.

34 RFC 3725: Best Current Practices for Third Party Call Control (3pcc) in SIP.


40/133

40

8 REFER MethodThe REFER35method is a SIP extension that requests that the recipient refers to a resource

provided in the request. This can be used to enable many applications, including call transfer. The

REFER method also establishes implicitly (without sending a SUBSCRIBE request) a short-lived

subscription to the refer event. The refer event allows the party sending the REFER to be notified

of the outcome of the referenced request.

The NOTIFY body of a REFER has the Content-Type message/sipfrag which is defined in RFC

3420

36

. Compared with the Content-Type message/sip the sipfrag allows to selectively insertonly specific parts of a SIP message. In case of the refer event the message body of NOTIFY

contains typically the status line only in case of provisional responses and the full response

including the dialog data in case of 200 OK. The dialog data allow the recipient of the NOTIFY to

take control of the session later and get the session partner back again via the Replaces header

field of an INVITE request (see chapter8.2 on page 43).

The REFER request uses a new header field Refer-To which indicates the target to be referred.

When an User Agent sends a REFER request the recipient will contact the resource addressed by

the Refer-To header field in the request and it will also notify the referrer of the outcome (success

or no success) of the operation. In case of call transfer service (the usual case for REFER) theaddress in the Refer-To header contains the SIP-URI of person to whom the call will be

transferred. But the semantic of the Refer-To header is much broader: it also may contain the

address of a web-site. In addition various URI-parameters in the Refer-To address may further

define some conditions how the addressed resource should be contacted (e.g. the URI-parameter

method=INVITE causes the referee to use the INVITE method).

The REFER method maybe used within a dialog or outside of a dialog, but the most common case

is to transfer existing calls and in this case it is sent within an existing dialog. User Agents often do

not accept REFER request outside of a dialog.

If REFER is not used within a dialog a dialog is created. REFER and NOTIFY requests are part of

the dialog. SUBSCRIBE is not used due to implicit subscription.

Figure 20 shows a typical message flow of a simple unattended call transfer service using the

REFER request. The call transfer is called unattended because Alice (the referrer) does not setup

a session with the refer target (Carol) before the transfer to explain the reason why the call is

transferred. This is perhaps impolite but simpler to explain from a call flow perspective. Later we

will see the more realistic example of an attended call transfer (see chapter 8.2 on page 43).

35 RFC 3515: The SIP Refer Method36 RFC 3420: The media type message/sipfrag


41/133

41

The REFER request in Figure 20 is sent within an existing dialog. The Refer-To header field

contains the address of the Refer-Target (Carol). The REFER request is executed as a simpletransaction causing the referee (Bob) to respond immediately. At this time the referee does not

know the result of the action initiated by REFER request (in above example an INVITE request to

the refer target). Therefore the referee responds with 202 Accepted and sends NOTIFY requests to

the referrer (Alice) to keep her informed about the result of the initiated action.

REFERRefer-To: Carol

Session and Dialog

Alice(Referrer)

Bob(Referee)

A dialog and session existsbetween Alice and Bob

Alice starts a call transfer.A subscription to the refer eventis created implicitly.

The first NOTIFY informs that theUser Agent of Carol is ringing.

Alice user agent automaticallyterminates the session.

The second NOTIFY informs thatthe Carol has accepted thesession.

Carol(Refer Target)

INVITE202 Accepted

180 Ringing

NOTIFY

200 OK

200 OK

ACKNOTIFY

200 OK

Session and Dialog

BYE

200 OK

--- end of session ---and dialog

Figure 20: Call transfer example based on a REFER request

There are some situations where the implicit subscription to the refer event is not necessary. In

this case a further extension allows the referrer to suppress the implicit subscription

37

.

37 RFC 4488: SIP REFER without Subscription


42/133

42

8.1 Referred-By header fieldIf the Refer-To header field of a REFER request contains a SIP URI the refer target is usuallycontacted by a SIP INVITE request. This INVITE request (the INVITE sent from Bob to Carol in

Figure 20) cannot be distinguished from an INVITE sent by Bob without any REFER based action

behind. In many cases this is not enough, The refer target should recognise that the INVITE

request arriving has been referred.

This gap is closed by the Referred-By header field defined in RFC 389238 and is quite simple.

Figure 21 shows the Referred-By mechanism.

REFER refereeRefer-To: targetReferred-By: referrer

Referrer Referee Refer Target

INVITE targetReferred-By: referrer

Figure 21: Referred-By mechanism

The Referrer adds a Referred-By header field to the REFER request containing the identity of the

referrer. This header field is copied into the referenced request (INVITE).

Someone may detect a security issue in the simple mechanism shown in Figure 21, because it is

easy in this case for a man-in-the middle attack to fake a Referred-By header field. Imagine the

boss of a company who only might accept calls referred by his secretary. This would be easy to

fake.

RFC 3892 addresses this situation and offers a solution based on an Authenticated Identity Body39

(AIB). The AIB offers a signature which is included in the message body. Figure 22 shows how the

Referred-By header field is secured by an AIB. A content-identifier parameter (cid) is added to the

Referred-By header field and the identifier points to a separate part of the message body which

contains a signature on the Referred-By header field. The Refer Target has now a possibility to

verify the authenticity of the Referred-By header field.

38 RFC 3892: The SIP Referred-By Mechanism39 RFC 3893: SIP Authenticated Identity Body (AIB) Format


43/133

43

REFER refereeRefer-To: targetReferred-By: referrer; cid=X

Additional message body part (MIME)Content-ID: X

Referrer Referee Refer Target

INVITE targetReferred-By: referrer; cid=X

Additional message body part (MIME)Content-ID: X

Figure 22: Referred-By header field secured by an AIB

There is also the possibility for the refer target to reject a REFER request without a valid referrer

identity with the response 429 (Provide Referrer Identity).

8.2 Replaces header fieldThe Replaces header field enhances the possibilities of peer-to-peer call control procedures and is

often used in combination with procedures initiated by a REFER request. The Replaces headerfield is defined in RFC 389140 and is used to logically replace an existing SIP dialog with a new SIP

dialog. This mechanism can be used to enable a variety of features, for example: "Attended

Transfer" and "Call Pickup" as will be shown later.

The Replaces header field contains the components of a dialog-id (Call-ID, From-tag, To-tag) and

refers to an existing dialog. If an INVITE request contains a Replaces header field the new session

seamlessly replaces the existing session identified by the Replaces header field. If the dialog-id

within the Replaces header field does not match an existing dialog the request is rejected with 481

(Call/Transaction Does Not Exist).

Example:

Replaces: [email protected];from-tag=r33th4x0r;to-tag=ff87ff

The usage of the Replaces header field is best show in an example. Figure 23 shows the scenario

of an attended call transfer. A few details in the message content are explained below.

40 RFC 3891: The SIP Replaces Header


44/133

44

Alice Bob

Alice calls Bob

Bob puts Alice on hold.

Bob calls Carol

Bob puts Carol on hold.

Bob transfers the existingsession with Carol to Aliceincluding the Replaces headerfield.

Alice calls Carol replacing theexisting session with Bob.

Carol terminates the session withBob.

Alice reports the successfultransfer to Bob

Bob terminates the session withAlice.

Carol

INVITE

180 Ringing

INVITE

180 Ringing

200 OK

ACK

Session and Dialog

INVITE (hold)

200 OK

ACK

no RTP

200 OK

ACK

Session and Dialog

INVITE (hold)

200 OK

ACK

no RTPREFER Refer-To: Carol

202 Accepted

NOTIFY

200 OK

INVITE Replaces: dialog with Bob

200 OK

ACK

Session and Dialog

BYE200 OK

NOTIFY

200 OK

BYE

200 OK

1

2

3

Figure 23: Attended call transfer using REFER and Replaces

The INVITE request (1) of Bob to put Alice on hold is shown in Figure 24. To set a session partner

on hold the SDP attribute a=sendonly is used. In addition the media feature tag


45/133

45

sip.rendering="no" in the Contact header field is used to make sure that during hol d no received

media will be rendered.

The a=sendonly attribute of an SDP offer is reflected in the SDP answer with the attribute

a=recvonly.

INVITE sips:[email protected] SIP/2.0Via: SIP/2.0/TLS client.biloxi.example.com:5061

;branch=z9hG4bKnashds7

Max-Forwards: 70

From: Bob ;tag=23431

To: Alice ;tag=1234567


CSeq: 1024 INVITEContact: ;+sip.rendering="no"


Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY

Supported: replaces

Content-Length: ...

v=0

o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com

s=

c=IN IP4 client.biloxi.example.com

t=0 0

m=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000

a=sendonly

Figure 24: INVITE request to put Alice on hold (1)

The next interesting request is the REFER request (2) sent by Bob to Alice.

REFER sips:[email protected] SIP/2.0

Via: SIP/2.0/TLS client.biloxi.example.com:5061

;branch=z9hG4bKnashds2g

Max-Forwards: 70From: Bob ;tag=23431

To: Alice ;tag=1234567


CSeq: 1025 REFER

Refer-To:

Referred-By:

Contact:

Content-Length: 0

Figure 25: REFER request from Bob to Alice (2)


46/133

46

In contrast to the REFER request of an unattended call transfer this REFER request contains a

Replaces header field referring to the existing dialog between Bob and Carol and a Referred-By

header field. Figure 25 shows the REFER request.

The Refer-To header field contains the refer target address, which is the Contact address of Carol

(not the AoR) to guarantee that the right instance of the user agent is addressed. The Contact URI

is amended by the Replaces header field (after the question mark). One will notice that within the

Replaces header field control characters are escaped (%HEX notation for @, = and ;). This is a

syntax rule in SIP to avoid ambiguity. The Replaces header field contains the three parameters of

the dialog-id: Call-ID, To-tag and From-Tag.

The INVITE request (3) sent from Alice to Carol includes the (now unescaped) Replaces header

field as shown in Figure 26.

INVITE sips:[email protected];gr SIP/2.0

Via: SIP/2.0/TLS chicago.example.com:5061

;branch=z9hG4bKadfe4ko

To: Carol

Max-Forwards: 70

From: Alice ;tag=3461


CSeq: 1 INVITE

Require: replaces

Referred-By:

Replaces: [email protected]

;to-tag=5f35a3;from-tag=8675309

Contact:

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY

Supported: replaces


Content-Length: ...

v=0

o=alice 2890844989 2890844989 IN IP4 client.atlanta.example.com

s=

c=IN IP4 client.atlanta.example.com

t=0 0

m=audio 3458 RTP/AVP 0

a=rtpmap:0 PCMU/8000

Figure 26: INVITE with Replaces header field (3)


47/133

47

The full message flow with all details of the message contents can be studied in RFC 5359 41.

This RFC contains many examples of possible services and may be interesting to analyse. But an

important remark has to be mentioned: The services examples are only to be considered as

examples, because there are in some cases different choices to implement a service. This is the

result of the toolbox nature of SIP, where all functions (e.g. Replaces header field extension) have

to be seen as tools (service primitives) within the SIP toolbox. As long as the syntax and semantic

of an extension liker REFER method or Replaces header field is implemented correctly the

interoperability should not be an issue.

41 RFC 5359: SIP Service Examples


48/133

48

9 ConferencingThe core SIP specification provides a way to set up and manage sessions between two User

Agents. It is possible to create and control a multi-party conference using this specification.

However in such a scenario, referred to as the loosely coupled conference model, there does not

exist a relationship between every participant in the conference. Such conference situations can be

accomplished by using multicast.

Alternatively, a UA can maintain multiple dialogs with multiple User Agents while also acting as a

media mixer. While the User Agent that is acting as the conference controller/mixer has knowledge

of the other User Agents involved in the conference, the other User Agents do not know about

each other. Additionally this scenario puts extra strain on the resources of the controlling User

Agent by forcing it to both: controlling signaling and mixing media streams..

RFC 435342 introduces an architecture by which a central entity, called a focus, provides a variety

of conference functions and mixing of media. In this type of conference, referred to as the tightly

coupled conference model, each UA involved in the conference connects to the focus and

maintains its own SIP dialog with it. This specification also defines a logical function called a

conference policy server that stores conference policy, which is simply a set of rules governing a

particular conference. The focus must be able to access this conference policy to determine howthe conference should operate, such as if a particular UA is allowed to join the conference. The

specification also defines a second logical function called a conference notification service. This

is a service that a conference participant can subscribe to and receive notifications when changes

in conference state occur. In this model, a UA participating in a conference can SUBSCRIBE to the

conference URI and be alerted via SIP NOTIFY messages when the state of the conference

changes, such as when participants enter and leave the conference.

Often the conference focus, policy server, and notification service are located in the same physical

entity. RFC 457543 defines an event package for notifying participants of a tightly coupled

conferences of the conference state. RFC 457944 uses the concepts from RFC 4353 and RFC4575 to define a set of recommended practices for creating and controlling

42RFC 4353: A Framework for Conferencing with SIP

43 RFC 4575: A Session Initiation Protocol (SIP) Event Package for Conference State44 RFC 4579: SIP Call Control - Conferencing for User Agents


49/133

49

9.1 Tightly Coupled SIP ConferenceFigure 27 shows the architecture of a conferencing server for tightly coupled conferences. It is

designed as a one-box conferencing server and contains several functional elements:

Conference focus: The focus is a SIP user agent that is addressed by a conference URI

which identifies a conference. The conference focus maintains a SIP signaling relationship

with each participant in the conference and is responsible for ensuring, in some way, that

each participant receives the media that make up the conference.

Mixer: A mixer receives a set of media streams of the same type from the participants of

the conference. It combines (mixes) the media and redistributes the result to each

participant.

Conference Policy Server: A conference policy server stores and manipulates the

conference policy like maintaining the list of participants to be invited to a conference.

Conference Notification Server: The participants of a conference should get information

on all actual participants of a conference and when a new participant joins the conference

and another participant leaves the conference. For that function RFC 4575 defines the

conferencing event package. The notification server accepts subscriptions by the

participants to the conference state and notifies the participants about changes to that

state.

Conference Server

ConferenceFocus

ConferenceMixer

ConferencePolicyServer

ConferenceNotification

Server

Participant A Participant B Participant C

SIP

SIP

SIP

RTP

RTP RT

P

H.248

Figure 27: Conferencing Server architecture


50/133

50

Tightly coupled conferences are hosted by a central point of control the conference focus to

which every participant has a signaling connection. The conference focus uses a conferencespecific SIP address which is shared among the participants. Closely coupled with the conference

focus is a conference mixer. The mixer terminates and re-originates the media streams. The

conference focus controls the conference mixer. It knows the SDP parameters for mixing media

streams contained in the SIP signaling messages. The focus controls the mixer via the H.24845

protocol also known as MEGACO protocol46. The mixing does simply the following:

it receives media stream from A and sends a combined media from B+C to A,

it receives media stream from B and sends a combined media from A+C to B,

it receives media stream from C and sends a combined media from A+B to C.

9.1.1 Creation of an Ad-hoc conference

A network operator can allow a user to create an ad-hoc conference. Such a conference has no

specified start time and is automatically established as soon as the first user joins the conference.

In order to do this, the user creating a conference must call a so-called conference-factory URI

provided by the conference-focus:

INVITE sip:[email protected] SIP/2.0

The message body of the INVITE request contains all media streams that the user wants to

establish for this conference. The conference-focus then checks if the user is allowed to create an

ad-hoc conference (via the policy server) and if resources for that conference are available at the

mixer. If it the focus accepts the ad-hoc conference it sends a dedicated conference URI back to

the user within the Contact header field of the 200 OK response.

SIP/2.0 200 (OK)

Contact: sip:[email protected];isfocus

The conference-focus indicates in this address that it will act as a focus for the ad-hoc conference

by adding an isfocus feature-parameter (see chapter 15, page 101).

The next step for the creator of the conference is to get the participants invited to the conference.

This can be accomplished by e.g. sending the conference URI to the participants e.g. via

messaging (see chapter 10, page 54). The participants then individually set-up the session with the

conference-focus using the dedicate

TelecommunicationSystems-SIP Protocol Extensions

Documents

Transcript of TelecommunicationSystems-SIP Protocol Extensions