08_FN41028EN52GLA1_sip

SIP-NNI and SIP-I: Protocol, Call Flow and Tracers

FN41028EN52GLA1 © 2010 Nokia Siemens Networks

1

Contents

1 Introduction to SIP 3

1.1 General 4

2 Main components of a SIP environment 13

2.1 Overview of SIP components 14

2.2 User Agent Client and Server (UAC/UAS) 16

2.3 Registration Server (Registrar) and SIP Location Server 17

2.4 SIP Proxy Server 18

2.5 Redirect Server 20

2.6 Back-to-Back User Agent (B2BUA) 22

3 SIP syntax 25

3.1 Request and response 26

3.2 SIP methods 29

3.3 Status codes 30

3.4 Header fields 32

3.5 Transaction and Dialog 39

4 Call flows with SIP 43

4.1 Registration 44

4.2 SIP digest authentication 48

4.3 SIP user to SIP user call 54

5 SIP Service Examples 63

5.1 Call Hold related flows 64

5.2 Transfer related flow 66

5.3 Call Forwarding Unconditional 68

5.4 3-Party Conference: Third Party is Add 69

5.5 Click to Dial 71

5.6 Presence with hiQ 4300 Com Manager 72

6 SIP Gateway and ISUP/SIP Inter-working 77

6.1 SIP-T/SIP-I 80

6.2 ISUP overlap signaling to SIP/SIP-I overlap signaling 86



FN41028EN52GLA1

© 2010 Nokia Siemens Networks 2

7 Call flows for SIP-NNI and SIP-I 89

7.1 JMSIP: SIP interworking program 90

7.2 Call flows PSTN (ISUP) to SIP (Basic call) 92

7.3 Call flows SIP to PSTN (ISUP) (Basic call) 98

7.4 CLIP/CLIR and Support of Additional Calling Party Number 102

7.5 Codec Mapping according to Q1912.6 107

7.6 Enhanced Codec Negotiation 111

7.7 Support of SIP Reason Header 116

7.8 Bearer Redirection Procedures 119

7.9 Call Completion Supplementary Services (CCSS) 127

7.10 Fixed Mobile Convergence Call Flows 132

7.11 Call flows SIP-I 136

8 Exercises 137



3

1 Introduction to SIP


FN41028EN52GLA1


1.1 General

1.1.1 History

SIP is an application-layer protocol that can establish, modify and terminate IP telephony calls and, more generally, multimedia sessions or conferences. "Call" is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. SIP was originally designed by Henning Schulzrinne (Columbia University) and Mark Handley (UCL) starting in 1996. A motivating goal for SIP was to provide a signaling and call setup protocol for IP-based communications that can support a superset of the call processing functions and features present in the public switched telephone network (PSTN). SIP by itself does not define these features; rather, its focus is call-setup and signaling. However, it has been designed to enable the building of such features in network elements known as Proxy Servers and User Agents. These are features that permit familiar telephone-like operations: dialing a number, causing a phone to ring, hearing ring-back tones or a busy signal. Implementation and terminology are different in the SIP world but to the end-user, the behavior is similar.

After years of intense debate and research in both the Internet and telecommunications communities, Session Initiation Protocol (SIP) is now starting to emerge in both public and enterprise networks.

Although many other VoIP signaling protocols exist, SIP is characterized by its proponents as having roots in the IP community rather than the telecom industry. SIP has been standardized and governed primarily by the IETF while the H.323 VoIP protocol has been traditionally more associated with the ITU.

The latest version of the specification is RFC 3261 from the IETF SIP Working Group. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IMS architecture.

Although two SIP endpoints can communicate without any intervening SIP infrastructure, which is why the protocol is described as peer-to-peer, this approach is impractical for a public service, where SIP servers act as proxy and registrar.

SIP is similar to HTTP and shares some of its design principles: It is human readable and request-response structured. SIP shares many HTTP status codes, such as the familiar '404 not found'. SIP proponents also claim it to be simpler than H.323. However, some would counter that while SIP originally had a goal of simplicity, in its current state it has become as complex as H.323. Others would argue that SIP is a stateless protocol, hence making it possible to easily implement failover and other features that are difficult in stateful protocols such as H.323. SIP and H.323 are not limited to voice communication but can mediate any kind of communication session from voice to video or future, unrealized applications. SIP has been designed in conformance with the Internet model. It is an end-to-end oriented signaling protocol which means, that all the logic is stored in end devices (except routing of SIP messages). SIP is capable of doing for next generation networks what HTTP did for the Internet.



5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

What is SIP?

SIP (Session Initiation Protocol) is a IETF signaling protocol (RFC2543, RFC3261) for establishing of multimedia sessions in IPnetworks.

SIP is a Peer-to-Peer Protocol

SIP has a client/server architecture. Main Entities in SIP Networks are:- User Agents (Client, Server)- SIP Proxy Servers- SIP Registrars

SIP is transaction based (requests and responses)

SIP messages are encoded as ASCII text

SIP messages may carry different contents, e.g. - SDP for the description of the bearer- ISUP for interworking with PSTN networks- Email content- Pictures (e.g. JPG)

Fig. 1


FN41028EN52GLA1


1.1.2 SIP Features

SIP is widely used as signaling protocol for Voice over IP and has the following features:

• Lightweight, in that SIP has only six methods, reducing complexity

• Transport-independent, because SIP can be used with UDP, TCP, ATM & so on.

• Text-based, easy to read and debug. Programming new services is easier and more intuitive for designers.

• SIP is addressing neutral, with addresses expressed as URL/URIs of various types, such as E.164 telephone numbers or email like addresses.

Its distinguishing feature is the transparent support of name mapping and re-direction services, which allows the implementation of very general, IN-like subscriber services and a high degree of personal mobility.

SIP handles the communication between the inviting party, the invited party and the endpoint addressing and user location. In the case of conferences, SIP is not tied to any particular conference control protocol; it neither offers nor prescribes conference control services.

An important feature of SIP is that it does not define the type of session that is being established, only how it should be managed. This flexibility means that SIP can be used for an enormous number of applications and services, including interactive gaming, music and video on demand as well as voice, video and Web conferencing. SIP can be used in any application where session initiation is a requirement. These include Event Subscription and Notification and Terminal mobility. Applications like presence and buddy list show how this event-based information sharing can increase the effectiveness of applications.

In particular, SIP handles the following aspects of establishing and terminating multimedia communications:

• User location: determination of the end system to be used for communication;

• User capabilities: determination of the media and media parameters to be used;

• User availability: determination of the willingness of the called party to engage;

• Call setup: “ringing”, the establishment of call parameters of both parties;

• Call handling: including the transfer and termination of calls.

SIP acts as a carrier for the Session Description Protocol (SDP), which describes the media content of the session, e.g. what IP ports to use, the codec being used etc. In typical use, SIP "sessions" are simply packet streams of the Real-time Transport Protocol (RTP). RTP is the carrier for the actual voice or video content itself.



7

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

User location: Determination of the end system to be used for communication

User capabilities: Determination of the media and media parameters to be used

User availability: Determination of the willingness of the called party to engage

Call setup: “Ringing”, the establishment of call parameters of both parties

Call handling: Including the transfer and termination of calls.

SIP handled aspects of comunication

Fig. 2 Aspects of communication


FN41028EN52GLA1


1.1.3 SIP and other protocols

SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the real-time transport protocol (RTP) (RFC 1889) for transporting real-time data and providing QoS feedback, the real-time streaming protocol (RTSP) (RFC 2326) for controlling delivery of streaming media, the Media Gateway Control Protocol (MEGACO) (RFC 3015) for controlling gateways to the Public Switched Telephone Network (PSTN). Since SIP is limited to the multi-media session control, there needs to be a description within a SIP request and response message about the multimedia session properties. IETF Session Description Protocol (SDP) (RFC 2327) is commonly used together with SIP to accomplish all the call signaling functions in IP telephony for describing multimedia sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete services to the users.

SIP enabled telephony networks can also implement many of the more advanced call processing features present in Signaling System 7 (SS7), though the two protocols themselves are very different. SS7 is a highly centralized protocol, characterized by highly complex central network architecture and dumb endpoints (traditional telephone handsets). SIP is a peer-to-peer protocol. As such it requires only a very simple (and thus highly scalable) core network with intelligence distributed to the network edge, embedded in endpoints (terminating devices built in either hardware or software). SIP features are implemented in the communicating endpoints (i.e. at the edge of the network) as opposed to traditional SS7 features, which are implemented in the network.



9

RTCPSIPRTP

UDPTCP SCTP

IP v4, IP v6

Ethernet

PPP

V .34Sone t ATM

P PP AAL3/4 AAL5 ...

...

mediaencaps

(G.711, ...)

T.38

Signalling Media transportQuality of

service

physical layer

network layer

transport layer

application layer

SIP embedding into the IP protocol suite

Fig. 3 SIP embedding into the IP protocol suite

IP Network

RTP

SIP signaling data

media data

Fig. 4 Data stream between two parties


FN41028EN52GLA1


1.1.4 SIP Standards

The first proposed standard version (SIP 2.0) was defined in RFC 2543. The protocol was further clarified in RFC 3261, although some implementations are still using interim draft versions. Note that the version number remains 2.0. Since SIP can be used in any application where session initiation is a requirement, there are a large number of SIP-related RFCs that define behavior for such applications. The Session Initiation Protocol (SIP) working group is chartered to maintain and continue the development of SIP, currently specified as proposed standard RFC 3261, and its family of extensions. Enhancements to security and authentication among other areas have been issued in several additional RFCs. RFC 3262, for example, governs Reliability of Provisional Responses. RFC 3263 establishes rules to locate SIP Proxy Servers. RFC 3264 provides an offer/answer model and RFC 3265 determines specific event notification.

SIP Standards (1)

RFC3261 SIP:Session Initiation Protocol (obsoletes RFC2543)

RFC3262 Reliability of Provisional Responses in SIP

RFC3264 An Offer/Answer Model with the Session Description Protocol (SDP)

RFC3265 Session Initiation Protocol (SIP)-Specific Event Notification

RFC3311 The Session Initiation Protocol (SIP) UPDATE Method

RFC4028 Session Timers in the Session Initiation Protocol (SIP)

RFC3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)

RFC3325 Private Extensions to SIP for Asserted Identity within Trusted Networks

RFC3204 MIME media types for ISUP and QSIG Objects

RFC3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures

RFC3398 ISUP to SIP Mapping

RFC2976 The SIP INFO Method

RFC2617 HTTP Authentication: Basic and Digest Access Authentication

RFC3515 The Session Initiation Protocol (SIP) Refer Method

RFC3665 Session Initiation Protocol (SIP) Basic Call Flow Examples

RFC3666 Session Initiation Protocol (SIP) PSTN Call Flows

RFC3725 Best Current Practices for Third Party Call Control (3pcc) in the SIP

RFC3824 Using E.164 numbers with the Session Initiation Protocol (SIP)

Fig. 5 SIP standards



11

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP Standards (2)

RFC2327 SDP: Session Description Protocol (see also draft-ietf-mmusic-sdp-new-25.txt!)

RFC3407 Session Description Protocol (SDP) Simple Capability Declaration

RFC3551 RTP Profile for Audio and Video Conferences with Minimal Control

RFC3555 MIME Type Registration of RTP Payload Formats

RFC3840 Indicating User Agent Capabilities in SIP

RFC3841 Caller Preferences for the Session Initiation Protocol (SIP)

RFC3842 A Message Summary and Message Waiting Indication Event Package for SIP

RFC3856 A Presence Event Package for the Session Initiation Protocol (SIP)

RFC3857 A Watcher Information Event Template-Package for SIP

RFC3891 The Session Initiation Protocol (SIP) "Replaces" Header

RFC3892 The Session Initiation Protocol (SIP) Referred-By Mechanism

RFC3966 The tel URI for Telephone Numbers

Q.1912.5 ITU Recommendation Q.1912.5: Interworking between SIP and BICC/ISUP

.... and some more .... see http://www1.cs.columbia.edu/sip/drafts.html !

Fig. 6 SIP standards


FN41028EN52GLA1




13

2 Main components of a SIP environment


FN41028EN52GLA1


2.1 Overview of SIP components

The main components of a SIP environment are:

• SIP Proxy Server (e.g. hiQ 6200, CSCF),

• SIP Redirect Server (e.g. hiQ 6200),

• SIP Registrars (e.g. hiQ 6200, hiQ 4200, hiQ 8000),

• SIP Gateways (e.g. hiE 9200),

• SIP User Agents (e.g.OptiClient, OptiPoint, MS Messenger, hiT@lk, iChat AV),

• SIP Back-to-Back User Agent /Application Servers (e.g. hiQ 4200, hiQ 8000).

Note that a combination of different server types can also be co-located at a server product or product release.



15

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP Servers and Clients

• UAC (User Agent Client)

– sends requests

– call stateful application

• UAS (User Agent Server)

– accepts, redirects, rejects requests

– call stateful application

• Registrar

– accepts REGISTER requests

– makes its information available through location server

• Redirect server

– map address to zero or more new addresses

• Proxy server

– server and client

– (transaction) stateful or stateless

– can stay in the path for the whole session by means of a Record-Route header field

Fig. 7


FN41028EN52GLA1


2.2 User Agent Client and Server (UAC/UAS)

A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.

SIP User Agents (UAs) are the end-user devices, such as cell phones, multimedia handsets, PCs, PDAs, etc. used to create and manage a SIP session. Also SIP gateways are in fact endpoints with user agent quality, which perform the inter-working from the IP- to the PSTN-World.

The user agent client (UAC) is an endpoint that initiates SIP requests such as initiating a call. A UAC is also known as the calling user agent. The calling user agent could be an IP phone, a multimedia PC, or more generally a SIP application server.

A user agent server (UAS) is an endpoint that receives SIP requests such as an incoming call and sends back responses to those requests. A UAS is also known as the called user agent.

SIP Request

SIP ResponseUAC

UAS

UACUAS

SIP Request

SIP R esponse

SIPPhones

SIPPhones

or

Fig. 8 SIP user agents



17

2.3 Registration Server (Registrar) and SIP Location Server

This type of server only accepts SIP user agent registration requests. These include the addressing information (URLs) for the user agent being known and alternative addresses or aliases for which it would like to accept requests. This contact information is made available to other SIP servers in the same administrative domain. For each invited SIP URL that had been registered before, these proxy and redirect servers will be able to forward the request correctly. The registration procedure is usually executed when a user becomes reachable (e.g., after start-up of a SIP client on a PC, or after the user changed his location).

The registrar function updates another SIP entity called the SIP Location Server. The SIP Location Server contains a mapping between any contact names (SIP ID, e.g. an E.164 telephone number) an endpoint might have and the endpoint’s IP address. In the end, the IP address is need to properly signal to an endpoint. However, the incoming call message rarely contains this IP address. Instead, it will contain some type of contact name (alias name) for the node being called. The SIP Location server can provide a translation of alias-to-IP-address and maintain a flag indicating the called endpoint’s availability. The Registrar function is the key in maintaining proper endpoint availability status on the SIP Location Server.

TIP hiQ 4200 / hiQ 8000 fulfills both functions, Registrar and Location Server.

SIP Registrar functionality:• Closely tied to with the SIP location server function

• updates SIP location server with current mappings of SIP URLs (Uniform Resource Locator) to IP addresses

• Proxy server then uses location service to process incoming SIP “invite”

• Typically, SIP phone registers with proxy server on power-up and re-registers periodically

• Once registered, SIP phone can be called, as well as make a call.

UAC

UAS

SIP Locat ion Server

REGISTRARRegister

OK

Provides translation of SIP address to IP address

SIP Proxy Server

Fig. 9 SIP Registrar


FN41028EN52GLA1


2.4 SIP Proxy Server

It receives SIP requests and responses from SIP user agents. On behalf of the user agent, it forwards or responds to it. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity “closer” to the targeted user. Typically, the SIP proxy has access to a database or a location service to aid in processing requests (determination of the next hop). A location service is used by a SIP proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record keys to zero or more contact addresses. The bindings can be created and removed in many ways; RFC 3261 defines a REGISTER method that updates the bindings.

Furthermore, proxy servers can support forking. This means, that the proxy can handle a number (i.e. more than one) of user registrations in parallel. An invitation message can be “forked” to different locations where the user is registered at the same time (e.g., ring several phones at different places at once until somebody takes the call at one of them).

Each proxy server can either be call/transaction stateful or stateless:

• a call stateful proxy holds information about the call during the entire time the call is up;

• a transaction stateful proxy maintains the state only during a SIP transaction;

• a stateless proxy processes a message and then forgets everything until the next message arrives.

A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true.

A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.



19

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standard SIP Proxy Server

SIP Proxy Server

• makes requests on behalf of other clients• can service requests internally or re-format a request before forwarding it• does normally not care about state of call (stateless)

UAC UASSIP Proxy Server

SIP Location Server

sip:[email protected]

192.168.81.102

INVITE sip:[email protected]

- finds location of called number- helps route call within IP network

INVITE sip:[email protected]


SIP - URI

Fig. 10 Standard SIP proxy server


FN41028EN52GLA1


2.5 Redirect Server

The redirection server, accepting SIP requests and mapping the address into zero or more recent, more accurate addresses for handling the SIP request. These addresses are returned to the client (Proxy or the User Agent), which sent the request, who then forwards the original request to the newly provided addresses. Unlike a proxy server, it does not initiate its own SIP request (forwarding step above), and unlike a user agent server, it does not accept calls.



21

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP Redirect Server• Possible load balancer to other servers

• Provides a simple redirection of the caller• Does not care about call state (stateless)

• Push of routing data back to the requesting client• Client upon receiving the redirection response is responsible for continuing the

call to the designated contact.

The hiQ does not operate as a Redirect Server.

UAC

UAS

SIP Proxy Server

SIP Location Server



10.17.5.80

IN VITE sip:[email protected]

Redirection 3xx(Contact:sip:[email protected])

INVITE (sip:[email protected])

Fig. 11 SIP redirect server


FN41028EN52GLA1


2.6 Back-to-Back User Agent (B2BUA)

A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as user agent server (UAS). In order to determine how the request should be answered, it acts as user agent client (UAC) and generates requests. Unlike a proxy server, it maintains call state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.

The hiQ 4200 Real-time Server / hiQ 8000 takes over typical Proxy functions, i.e., they are e.g. responsible for the routing of the INVITE message coming from the A-side to the B-side of the call. Concerning this the hiQ does act from the perspective of a SIP endpoint like a proxy server. However, the hiQ is not a pure proxy server:

• The hiQ is required to accommodate multiple signaling protocols, and not just SIP.

• Furthermore the hiQ has to be aware of the call status in order to be able to do e.g. charging of the call.

Therefore the hiQ works in calls between 2 SIP Endpoints as a Back-to-Back User Agent (B2BUA):

• The hiQ is a User Agent Client from point of view of the A-side of the call.

• The hiQ is a User Agent Server from point of view of the B- side of the call

• It forces the A and B side of the call to send all SIP message always to him and not to exchange SIP messages directly (in CONTACT or VIA field of the SIP messages sent to the B-side of the call you will always find the IP address of the hiQ (and not of the A-side subscriber).

The figure on the opposite page shows how the hiQ working as a back-to-back user agent participates in a call.

• The calling subscriber is configured to send all its SIP requests to the hiQ.

• The called subscriber views the hiQ as the user agent client and doesn’t really know that the hiQ is making a call on behalf of someone else:

• The “invite” sent from the hiQ to the called SIP phone is the result of a call route lookup by the hiQ. This lookup was done on a dialed number (E.164 number) that was passed to the hiQ in the invite message sent by the SIP terminal that initiated the exchange.

• The key parameters needed to put the RTP stream in place (UDP port, IP address, compression algorithm, etc transmitted as Session Description Protocol SDP) are passed transparently from the calling party to the called party in the “invite” message. The called party confirms this by passing these parameters back in the “OK” message.



23

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP User Agent on hiQ

• hiQ implements Back-to-Back (B2B) User Agent- SIP signaling manager, within one call, can be both UAS (server) and UAC

(client)

• Back-to-Back arrangement allows interworking with other signaling protocols- SIP-to-H.248, SIP-to-ISUP, ...

UAC UASUCEINVITE

INVITE

SIP SM

A3 Server(Authentication)

Call Routing Services

Back-to-Back User Agent

UAS UAC

Fig. 12 SIP User Agents


FN41028EN52GLA1


The most generic SIP operation involves a SIP user agent client (UAC) issuing a request, a SIP proxy server acting as end-user location discovery agent and a SIP user agent server (UAS) accepting the call. A successful SIP invitation consists of two requests: INVITE answered by a Response (200 OK) that is again acknowledged by ACK. The INVITE message contains session description that informs the called party what type of media the inviting party can accept and where it wishes the media data to be sent to. SIP addresses are referred to as SIP Uniform Resource Locator (SIP-URL's), which is of the form sip:[email protected]. SIP message format is based on the Hyper Text Transport Protocol (HTTP) message format, which uses a human-readable, text-based encoding.



25

3 SIP syntax


FN41028EN52GLA1


3.1 Request and response

Since SIP is a text-based protocol and borrows a lot of from HTTP, the SIP syntax looks very similar to HTTP’s and SIP uses email like address.

A SIP message is either a request from a client to a server, or a response from a server to a client. Both Request and Response messages use the basic format of RFC 2822. Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body. The header is a component of a SIP message that conveys information about the message. It is structured as a sequence of header fields.

SIP Requests have a Request start line containing a method name (see extra chapter), a Request-URI (indicates the user or service to which this request is being addressed), and the protocol version.

SIP message: Request

INVITE sip:[email protected]:5060 SIP/2.0

Max-Forwards: 70Content-Length: 242Via: SIP/2.0/UDP 192.168.9.161:5060;branch=z9hG4bK801769770Call-ID: 0c46073715d2d25From: Robert <sip:[email protected]:5060>;tag=553140ae026105dTo: sip:[email protected]:5060CSeq: 2 INVITESupported: timerMin-SE: 5Supported: 100relAllow-Events: talk, hold, conferenceAllow: INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,MESSAGE,UPDATEContent-Type: application/sdpAuthorization:Digest response="8c5e6d41b6da50df0608517cd73de1c3",nc=00000001,username="Siemens",realm="ti-munich.surpass.com",nonce="65709606-8e66cd12c2369afb0da40a2eb97631ba",algorithm=MD5,qop=auth,cnonce="3ffc5d474b285b947756ca757d66a5eaSupported: replacesContact: Robert <sip:[email protected]:5060;transport=udp>User-Agent: optiClient S 130 V3/3.0.0.23

(v): 0

(o): MxSIP 0 84121838 IN IP4 192.168.9.161

(s): SIP Call

(c): IN IP4 192.168.9.161

(t): 0 0

(m): audio 29102 RTP/AVP 0 8 18 101

(a): rtpmap:0 PCMU/8000(a): rtpmap:8 PCMA/8000(a): rtpmap:18 G729/8000(a): rtpmap:101 telephone-event/8000(a): fmtp:101 0-15

Start (request) line

Header fields

Empty line

Message body (SDP)

Fig. 13 SIP Request Message



27

SIP Responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code (see extra chapter) and its associated Reason phrase. The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code.

SIP message: Response

Start line (status code)

Header fields

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.9.161:5060;branch=z9hG4bK801769770

Call-ID: 0c46073715d2d25

From: Robert <sip:[email protected]:5060>;tag=553140ae026105d

To: sip:[email protected]:5060

CSeq: 2 INVITE

Content-Length: 0

Fig. 14 SIP Response Message


FN41028EN52GLA1




29

3.2 SIP methods

Following list shows the list of methods requested by RFC 3261 and other RFCs/drafts, which are supported by the SIP-Stack.

publication of event state from a user agent to an entity that is responsible for compositing this event state and distributing it to interested parties (draft-ietf-sip-publish-02)

PUBLISH

allows a client to update parameters of a session (such as the set of media streams and their codec) (RFC 3311)

UPDATE

see SUBSCRIBE (RFC 3265)UNSUBSCRIBE

used to request current state and state updates (RFC 3265)SUBSCRIBE

registers with location service (RFC 3261)REGISTER

indicates that the recipient (identified by Request-URI) should contact a third party using the contact information provided in the request (RFC 3515)

REFER

acknowledges reliable provisional responses (RFC 3262)PRACK

queries feature support by remote side (RFC 3261)OPTIONS

informs subscribers of changes in state (RFC 3265)NOTIFY

exchange of content between a set of participants in near real time (RFC 3428)MESSAGE

initiates call (RFC 3261)INVITE

carries session related control information (RFC 2976)INFO

cancels a pending request (RFC 3261)CANCEL

terminates a call (RFC 3261)BYE

confirms final response (RFC 3261)ACK

SIP Request Methods

Fig. 15 SIP methods


FN41028EN52GLA1


3.3 Status codes

The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a “1xx response”, any response with a status code between 200 and 299 as a “2xx response”, and so on. SIP/2.0 allows six values for the first digit:

Final is a response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final.

Provisional is a response used by the server to indicate progress, but that does not terminate a SIP transaction. 1xx responses are provisional, other responses are considered final.

1xx: Provisional – request received, continuing to process the request;

2xx: Success – the action was successfully received, understood, and accepted;

3xx: Redirection – further action needs to be taken in order to complete the request;

4xx: Client Error – the request contains bad syntax or cannot be fulfilled at this server;

5xx: Server Error – the server failed to fulfill an apparently valid request;

6xx: Global Failure – the request cannot be fulfilled at any server.

Status Codes

Fig. 16 Status codes



31

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP Responses

Request Failure

400 Bad Request 407 Proxy Authentication Required401 Unauthorized 408 Request Timeout402 Payment Required 410 Gone403 Forbidden 413 Request Entity Too Large404 Not Found 414 Request-URI Too Long405 Method Not Allowed 415 Unsupported Media Type406 Not Acceptable 416 Unsupported URI Scheme

420 Bad Extension 484 Address Incomplete421 Extension Required 485 Ambiguous422_Session Interval Too Small 486 Busy Here423 Interval Too Brief 487 Request Terminated480 Temporarily Unavailable 488 Not Acceptable Here481 Call/Transaction Does Not Exist 489 Bad Event482 Loop Detected 491 Request Pending483 Too Many Hops 493 Undecipherable

Provisional

100 Trying180 Ringing181 Call Is Being Forwarded182 Queued183 Session Progress

Successful

200 Ok202 Accepted

Redirection

300 Multiple Choices301 Moved Permanently302 Moved Temporarily305 Use Proxy380 Alternative Service

Server Failure

500 Server Internal Error501 Not Implemented502 Bad Gateway503 Service Unavailable504 Server Time-out505 Version Not Supported513 Message Too Large

Global Failure

600 Busy Everywhere603 Decline604 Does Not Exist Anywhere606 Not Acceptable

Fig. 17 SIP responses


FN41028EN52GLA1


3.4 Header fields

Header name Description

Accept An Accept header field should be included to indicate the type of message body.

Accept-Encoding The Accept-Encoding header field restricts the content-codings that are acceptable in the response.

Accept-Language The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response.

Alert-Info used for requests only

When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS.

Allow The Allow header field lists the set of methods supported by the UA generating the message.

Allow-Events The "Allow-Events" header from RFC 3265 includes a list of tokens which indicates the event packages supported by the client (if sent in a request) or server (if sent in a response).

Authentication-Info used for responses only

A UAS may include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field.

Authorization used for requests only

The Authorization header field contains authentication credentials of a UA.

Body the message body if present

Call-ID mandatory

The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client.



33


Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard or LDIF formats.

Contact A Contact header field value provides a URI whose meaning depends on the type of request or response it is in.

Content-Disposition The Content-Disposition header field describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS.

Content-Encoding The Content-Encoding header field is used as a modifier to the "media-type". When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field.

Content-Language entity-header

Content-Length The Content-Length header field indicates the size of the message-body, in decimal number of octets, sent to the recipient.

Content-Type The Content-Type header field indicates the media type of the message-body sent to the recipient

CSeq A CSeq header field in a request contains a single decimal sequence number and the request method.

Date The Date header field contains the date and time.

Diversion The Diversion header should be added when a SIP proxy server, SIP redirect server, or SIP user agent changes the ultimate endpoint which will receive the call.

Error-Info used for responses only

The Error-Info header field provides a pointer to additional information about the error status response.


FN41028EN52GLA1



Event Header from RFC 3265 for the purposes of matching responses and NOTIFY messages with SUBSCRIBE messages

Expires The Expires header field gives the relative time after which the message (or content) expires. The precise meaning of this is method dependent.

From The From header field indicates the initiator of the request. This may be different from the initiator of the dialog. Requests sent by the callee to the caller use the callee's address in the From header field.

In-Reply-To used for requests only

The In-Reply-To header field enumerates the Call-IDs that this call references or returns.

Max-Forwards used for requests only

The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server.

MIME-Version Version of Multipurpose Internet Mail Extensions (MIME)

Min-Expires used for responses only

The Min-Expires header field conveys the minimum refresh interval in seconds supported for soft-state elements managed by that server. This includes Contact header fields that are stored by a registrar.

Min-SE The Min-SE header field indicates the minimum value for the session interval, in units of delta-seconds.

Organization The Organization header field conveys the name of the organization to which the SIP element issuing the request or response belongs.

“Other header” list of all yet unknown headers

P-Asserted-Identity The P-Asserted-Identity header field from RFC 3325 is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication.

P-Charging-Vector The P-Charging-Vector contains identifier that are used for correlating charging records and events.



35


P-Preferred-Identity The P-Preferred-Identity header field from RFC 3325 is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert.

Priority used for requests only

The Priority header field indicates the urgency of the request as perceived by the client. The header field can have the values "non-urgent", "normal", "urgent", and "emergency" and other.

Privacy There are some headers that a user agent cannot conceal itself, because they are used in routing, that could be concealed by an intermediary that subsequently takes responsibility for directing messages to and from the anonymous user. The user agent must have some way to request such privacy services from the network. For that purpose, RFC 3323 defines a new SIP header, Privacy, that can be used to specify privacy handling for requests and responses.

Proxy-Authenticate used for responses only

A Proxy-Authenticate header field value contains an authentication challenge.

Proxy-Authorization used for requests only

The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication.

Proxy-Require used for requests only

The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the proxy.

RAck The RAck header from RFC 3262 is sent in a PRACK request to support reliability of provisional responses. It contains two numbers and a method tag. The first number is the value from the RSeq header in the provisional response that is being acknowledged. The next number, and the method, are copied from the CSeq in the response that is being acknowledged.

Record-Route The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy.


FN41028EN52GLA1



Refer-To Refer-To is a request header field from RFC 3515 and only appears in a REFER request. It provides a URL to reference.

Referred-By Referred-By is a request header field which carries a SIP URI representing the identity of the referrer and, optionally, the Content-ID of a body part (the Referred-By token) that provides a more secure statement of that identity.

Reply-To used for requests only

The Reply-To header field contains a logical return URI that may be different from the From header field. For example, the URI may be used to return missed calls or un-established sessions.

Require The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request.

Retry-After used for responses only

The Retry-After header field can be used with a response to indicate how long the service is expected to be unavailable to the requesting client and to indicate when the called party anticipates being available again.

Route used for requests only

The Route header field is used to force routing for a request through the listed set of proxies.

RSeq The RSeq header from RFC3262 is used in provisional responses in order to transmit them reliably.

Server used for responses only

The Server header field contains information about the software used by the UAS to handle the request.

Session-Expires The Session-Expires header field conveys the session interval in seconds for a SIP session.

Subject used for requests only

The Subject header field provides a summary or indicates the nature of the call, allowing call filtering without having to parse the session description.



37


Subscription-State NOTIFY requests must contain "Subscription-State" headers from RFC 3265 which indicate the status of the subscription. The "Subscription-State" header value can be "active", "pending" or "terminated"

Supported The Supported header field enumerates all the extensions supported by the UAC or UAS.

Timestamp The Timestamp header field describes when the UAC sent the request to the UAS.

To The "To" header field specifies the logical recipient of the request.

Unsupported used for responses only

The Unsupported header field lists the features not supported by the UAS.

User-Agent The User-Agent header field contains information about the UAC originating the request.

Via The "Via" header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses. Every SIP component that initiates or routes a message is listed in the Via header.

Warning used for responses only

The Warning header field is used to carry additional information about the status of a response.

WWW-Authenticate used for responses only

A WWW-Authenticate header field value contains an authentication challenge.


FN41028EN52GLA1




39

3.5 Transaction and Dialog

Transaction and branch ID parameter

In general, a transaction includes all the messages associated with one request and is terminated by a 2xx response (but there are exceptions). In the figure below the ACK is considered to be a transaction all by itself. Also, the server could return a 3xx or 5xx response to the INVITE. This response would define the boundary of a transaction.

The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of the old RFC 2543. The branch ID inserted in the "Via" header by an element compliant with RFC 3261 always begin with the characters "z9hG4bK". These 7 characters are used as a magic cookie (7 is deemed sufficient to ensure that an older RFC 2543 implementation would not pick such a value), so that servers receiving the request can determine that the branch ID was constructed in the fashion described by RFC 3261. Beyond this requirement, the precise format of the branch token is implementation-defined.

Branch parameter and loops

Looped is a request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors, and the procedures for detecting them and handling them are described by the protocol.

If a proxy wishes to detect loops, the "branch" parameter it supplies must depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing. This is necessary to distinguish looped requests from requests whose routing parameters have changed before returning to this server. The request method must not be included in the calculation of the branch parameter. In particular, CANCEL and ACK requests (for non-2xx responses) must have the same branch value as the corresponding request they cancel or acknowledge. The branch parameter is used in correlating those requests at the server handling them.

Spiral

Spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding.


FN41028EN52GLA1


Dialog and "tag" parameter

The "tag" parameter is used in the To and From header fields of SIP messages. It serves as a general mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from each participant in the dialog. When a UA sends a request outside of a dialog, it contains a From tag only, providing "half" of the dialog ID. The dialog is completed from the response(s), each of which contributes the second half in the To header field.

A Dialog represents a peer-to-peer SIP relationship between two UAs that persists for some time.

A Dialog facilitates sequencing of messages and proper routing of requests between the user agents.

A Dialog is created through the generation of non-failure responses to requests with specific methods.

The only way to establish a Dialog described in RFC3261 are: 2xx/101-199 responses to an INVITE request.

A Dialog established by a non-final INVITE response is called an early dialog. The Dialog state changes to confirmed if a 2xx response is received.

A Dialog is identified at each UA with a Dialog ID, which consists of:

• the Call-ID value

• a Local Tag

• a Remote Tag

The Dialog ID is not identical for both UA’s:

• UAC: Local Tag = Tag in FROM Header of INVITE message Remote tag = Tag in TO Header of INVITE message

• UAS: Local Tag = Tag in TO Header of INVITE message Remote Tag = Tag in FROM Header of INVITE message

A Dialog contains certain pieces of state needed for further message transmissions within the Dialog:

• Dialog ID

• Local/Remote sequence numbers

• Local/Remote URI,

• Remote target

• Route set



41

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dialog and Transactions

200 OK

[email protected]

[email protected]

INVITE

ACK

400 Bad Request

(Re-)INVITE

ACK

200 OK

BYE

Transaction 1(Request outside of a

Dialog)

Transaction 3(Request inside the Dialog!)

Dialog is established!

Re-INVITE transactionfails, but the Dialog isstill established!!

Dialog is terminated.



Fig. 18 Dialog and transaction


FN41028EN52GLA1


Via header and "rport" parameter

RFC 3263 tells us how to find SIP servers to which we can send messages. In particular, when sending responses we can use the top Via header to locate a target machine for our response. As part of this algorithm RFC 3263 says, that the server examines the value of the sent-by construction in the topmost Via header. If it contains a numeric IP address, the server attempts to send the response to that address, using the transport protocol from the Via header, and the port from sent-by, if present, else the default for that transport protocol.

The algorithm tells us that the response with topmost Via

"Via: SIP/2.0/UDP 127.0.0.1:15060"

should be sent to the machine at 127.0.0.1 on port 15060 using UDP.

The response with topmost Via:

"Via: SIP/2.0/UDP 127.0.0.1"

should be sent to the machine at 127.0.0.1 on the default UDP port (5060) using UDP.

So far so good. What happens with the Via header

"Via: SIP/2.0/UDP 127.0.0.1;rport=8000"?

Assuming the UAS implements RFC 3581, the UAS sends the response to the machine 127.0.0.1 on port 8000 using UDP, and not to port 5060.

OK, so what about

"Via: SIP/2.0/UDP 127.0.0.1:5060;rport=8000"?

Does the message go to port 5060 or 8000? Does rport have precedence over a specified port? The rport overrides the 5060, since rport is filled in by the proxy or UAS receiving the request, and '5060' is filled in by the UA (which did not know via which port the NAT would send its request). The rport can be seen as a 'patch' that replaces the port that would not work.



43

4 Call flows with SIP


FN41028EN52GLA1


4.1 Registration

4.1.1 Contact

A Registration Request will contain always the "contact" information consisting out of

• the logical SIP ID of the endpoint (normally the E.164 Directory Number)

• the IP address of the endpoint

4.1.2 Static versus Dynamic Registration

Two registration types have to be distinguished:

• Static Registration Here the contact information contained in the registration request is compared to that entered already into the database of the hiQ. I.e., the endpoint is created in the hiQ's database with SIP ID already linked with an IP address. Only if there is a match (SIP ID is created in the hiQ's database and is linked with the same IP address), the hiQ marks the node as “registered”, and returns an “OK” response to the endpoint. I.e., an endpoint can only register with this predefined IP address. If the registration is not successful then it sends e.g. 401 Unauthorized to the user.

• Dynamic Registration Here the endpoint is created in the hiQ's database only with a SIP ID but without an IP address. I.e., the endpoint can register with any IP address.

4.1.3 Reactions in Registrar

A registrar is a server that accepts REGISTER requests and generates responses. A registrar is typically co-located with a proxy server and makes its information available through the location service. A register request can create different reactions in a registrar:

• Register a physical location (IP-address of the terminal) of a user

• Add a physical location to an existing physical location of a user

• Delete one or all physical location of a user

• Read all physical locations of a user

When an “INVITE” is received and the call route lookup indicates that the dialed number (DN) points to a SIP endpoint, the contact information in the database is used to retrieve the IP address of the destination endpoint.



45

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

• SIP endpoints view hiQ as a registrar server, and attempt to register themselves on the hiQ.

• Registration will fail unless endpoint contact info (SIP ID) has been entered in hiQ database.

• After registration, session “invites” will be processed by hiQ, and phone can be called.

• Registration expires depending on „time to live“ value (expires=.....) insidethe Register message.

UCE

E.164 code table

192.168.20.102

hiQ

DB

UAS

RegistrarUAC

Register sip:192.168.20.102:5060 SIP/2.0Contac t: Thomas <s ip:[email protected]:5060;

transport=udp>expires=3605;

200 OK


SIP ID

SIP ID in databaseof hiQ = DN

Fig. 19 SIP user registration


FN41028EN52GLA1


4.1.4 Re-registration and De-registration

A user can only be reachable if he is registered at one physical location.

The content of this record together with the E.164 number of the user and the IP-address of the terminal is cached as long as the record is valid, i.e. the expiration time counter is not zero (this counter is 3600 seconds by default or is part of the register request).

If a user registers himself with a REGISTER request for a second time the new IP-address of the terminal is added in the cache.

If a user de-registers itself at the proxy using a REGISTER request, the proxy deletes the entry of the terminal in the user record from its cache. If it is the last entry of the location the user record will be deleted in the cache.

Since each entry offers an expiration time a location will also be deleted, if the expiration time of this entry decreases to zero. The record will be deleted, if the last expiration time counter of the user decreases to zero. So the terminal must send a REGISTER request before the expiration times expires.



47

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 20 Re-Registration timer


FN41028EN52GLA1


4.2 SIP digest authentication

There is a user authentication scheme supported in SIP called digest authentication. It is referred to as a “challenge-response” model in that the hiQ can request authentication information from a SIP endpoint that is trying to send a packet. An example of this challenge-response exchange is shown in the figure on the opposite page.

The SIP RFC 3261 defines digest authentication as the primary means of verifying a user’s identity. The authentication strategy defined in RFC 3261 is borrowed from RFC 3310 that outlines HTTP authentication. The digest authentication scheme is based on two core properties:

• A shared secret (key or password) between parties

• Embedding the key and user credentials within cryptographic hashes

The Authentication and Key Agreement (AKA) mechanism is based on a paradigm that uses symmetric cryptography: if both sides share the same authentication credentials, and use the same crypto algorithms, the authentication string received should match that one generated locally. Digest authentication primarily focuses on user authentication and does not provide encryption of the message content (RTP stream).

In the figure on the next page, the hiQ responds to the endpoint’s Register request with a “401 Unauthorized” packet. The endpoint responds by retrying the request, but with an added authorization header line. This new line of information contains the checksum result of the encryption algorithm and other plain text parameters (including the SIP phone’s username). Upon receiving the request, the hiQ checks its validity by looking up the password that corresponds to the submitted username. Then, the hiQ performs the same digest operation (typically MD5) as that on the SIP phone and compares the result to the given value just passed to it.

Within a SIP environment, any of the intermediary nodes can request digest authentication.



49

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP Digest Authentication

SIP phone hiQ 8000

(1) Register (no authentication info included)

(2) 401 Unauthorized

(3) Register (with authentication header)

(4) 200 OK

Status-Line: SIP/2.0 401 UnauthorizedMessage HeaderWWW-Authenticate: Digest realm="ti-munich.surpass.com", nonce="65765511-f79462e05b6d782321dd76da85515142", algorithm="MD5", qop="auth"

Authorization:Digestresponse="6ececc48b4a046679f8c8dcd2ac9d65c",nc=00000001,username="Siemens",realm="ti-munich.surpass.com",nonce="65765511-f79462e05b6d782321dd76da85515142",algorithm=MD5,qop=auth,cnonce="654843332446224992b3af64233ccdff

hiQ 4200

CSCF

Fig. 21 SIP Digest Authentication, e.g. registration scenario


FN41028EN52GLA1


4.2.1 Parameters of the digest challenge

If digest authentication is enabled, the hiQ will “challenge” the first packet received from the SIP endpoint. It does this by sending a “401 Unauthorized” message back to the endpoint. This challenge contains:

realm

The realm is a string that identifies the host performing the authentication. It is used to distinguish the different username/password combinations a user may have. A user will insert the username/password combination into the credentials fitting the realm received in the challenge. As the realm string should be globally unique among all realms which any single user is likely to use, a good choice of a realm should contain the domain name (of the domain the server is responsible for) and the server name.

nonce

Nonce is a hiQ- generated data string that is unique to each 401 response. It is the MD5 hash of some data that the hiQ generates. This string is used as “seed” input to the encryption scheme. The SIP phone uses the "nonce" to generate a digest response. It does not change this string, returning it as sent. The nonce is opaque to the client.

algorithm

The algorithm (defaulted to MD5) is used to produce the digest and checksum.

qop - Server Quality-of-Protection

Qop determines the quality of protection. A qop value may be included in the challenge of the hiQ to determine how the response in the credentials must be calculated.

Quality of Protection (qop) options – a list of qop value supported by the hiQ:

• Qop = auth (Auth – authentication) The directive qop = auth is included in the challenge. The user may choose between no qop or qop = auth for the credentials. If the user chooses qop = auth in the credentials the digest response is calculated using method, uri, nonce, nonce count, client nonce and qop of the SIP request to be authenticated.

• Qop = auth-int (Auth-int - authentication with message body integrity protection) The directive qop = auth-int is included in the challenge. The user may choose between no qop or qop = auth-int for the credentials. If the user chooses qop = auth-int in the credentials the digest response in the credentials is calculated using method, uri , nonce, nonce count, client nonce, qop and the entire body of the SIP request to be authenticated.

• Qop = auth-extd-int (Auth-extd-int - authentication with complete message integrity protection)

• Qop = auth-hdr-int (Auth-hdr-int - authentication and integrity protection of the message body and various message headers).



51

stale

A flag indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE, the client may wish to simply retry the request with a new encrypted response, without reprompting the user for a new username and password.

nextnonce

The WWW-Authenticate- Info header issued by the hiQ is used to pass information about the successful authentication in the response. One of the values that can be included by the hiQ is a nextnonce, which is the nonce that the hiQ wants the phone to use for future authentication responses.

Session Initiation ProtocolStatus-Line: SIP/2.0 401 Unauthorized

Status-Code: 401[Resent Packet: False]

Message HeaderContent-Length: 0Via: SIP/2.0/UDP 192.168.9.151:5060;branch=z9hG4bK5c9a522e6Call-ID: a1fc63a9597ce20From: Post1 <sip:[email protected]:5060>;tag=d8e65b4a2ebca05;epid=SC519df8

SIP Display info: Post1 SIP from address: sip:[email protected]:5060SIP tag: d8e65b4a2ebca05

To: Post1 <sip:[email protected]:5060>;tag=test_tag_0012704357SIP Display info: Post1 SIP to address: sip:[email protected]:5060SIP tag: test_tag_0012704357

CSeq: 1 REGISTERUser-Agent: optiClient S 130 V3/3.0.0.23WWW-Authenticate: Digest realm="training", nonce="3038955891-29eadfec9c131775a2ddd38790d24beb",

algorithm="MD5", qop="auth"Authentication Scheme: DigestRealm: "training"Nonce Value: "3038955891-29eadfec9c131775a2ddd38790d24beb"Algorithm: "MD5"QOP: "auth"

Fig. 22 Example of a digest challenge of the hiQ (after a REGISTER request by a SIP phone)


FN41028EN52GLA1


4.2.2 Parameters of the digest response

The digest response is very similar to the digest challenge. This response contains additionally to the "digest challenge" parameters:

response

A string of 32 hex digits computed by the user agent, which proves, that the user knows a password.

nc

The nc-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value is seen twice, then the request is a replay.

username

It is the user's name in the specified realm.

qop

Indicates what "quality of protection" the client has applied to the message.

cnonce

The cnonce-value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plaintext attacks, to provide mutual authentication, and to provide some message integrity protection.

uri

The URI that the client wants to access.

If a directive or its value is improper, or required directives are missing, the proper response is 400 Bad Request.

TIP For more information see RFC 2617 and RFC 3261.



53

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Session Initiation ProtocolRequest-Line: REGISTER sip:192.168.20.102:5060 SIP/2.0

Method: REGISTER[Resent Packet: False]

Message HeaderMax-Forwards: 70Content-Length: 0Via: SIP/2.0/UDP 192.168.9.151:5060;branch=z9hG4bK30945129bCall-ID: a1fc63a9597ce20From: Post1 <sip:[email protected]:5060>;tag=d8e65b4a2ebca05;epid=SC519df8

SIP Display info: Post1 SIP from address: sip:[email protected]:5060SIP tag: d8e65b4a2ebca05

To: Post1 <sip:[email protected]:5060>SIP Display info: Post1 SIP to address: sip:[email protected]:5060

CSeq: 2 REGISTERContact: Post1 <sip:[email protected]:5060;transport=udp>;expires=75;audio;video;text

Contact Binding: Post1 <sip:[email protected]:5060;transport=udp>;expires=75;audio;video;textURI: Post1 <sip:[email protected]:5060;transport=udp>

SIP Display info: Post1 SIP contact address: sip:[email protected]:5060

Authorization:Digestresponse="ed312056db9167a44892e4d9e71fc0c3",nc=00000001,username="siemens",realm="training",nonce="3038955891-29eadfec9c131775a2ddd38790d24beb",algorithm=MD5,qop=auth,cnonce="e72f2f677ba0f7ed93846471bf9d49a6",uri="sip:

Authentication Scheme: DigestDigest Authentication Response: "ed312056db9167a44892e4d9e71fc0c3"Nonce Count: 00000001Username: "siemens"Realm: "training"Nonce Value: "3038955891-29eadfec9c131775a2ddd38790d24beb"Algorithm: MD5QOP: authCNonce Value: "e72f2f677ba0f7ed93846471bf9d49a6"Authentication URI: "sip:192.168.20.102:5060"

User-Agent: optiClient S 130 V3/3.0.0.23

Fig. 23 Example of a digest response of a SIP phone


FN41028EN52GLA1


4.3 SIP user to SIP user call

1. INVITE: The User Agent Client initiates a call with a User Agent Server, via the Proxy Server by sending an INVITE message to the Proxy Server that is destined for the User Agent Server. 100 Trying (not shown): The Proxy Server responds immediately with a 100 response to confirm that it has received the message.

2. INVITE: The Proxy Server forwards the INVITE message to the User Agent Server, now that it has located that user. 100/Trying: The User Agent Server responds immediately with a 100 response to confirm that it has received the message. 180 /RINGING: After processing the INVITE, and notifying the end user that a call has arrived, the User Agent Server responds with a 180 response to indicate that the terminating side is ringing 180/RINGING: The Proxy Server forwards the 180 Response to the User Agent Client that originated the INVITE request

3. 200/OK: After the user accepts the connection, the User Agent Server sends a 200 response to the Proxy Server, indicating that the call has been accepted

4. 200/OK: The Proxy Server forwards the 200 Response to the User Agent Client that originated the INVITE request

5. ACK: The User Agent Client acknowledges that receipt of the final response to the INVITE message by sending an ACK: due to the Proxy Server choosing to use the record route/route headers the ACK is sent to the Proxy Server

6. ACK: The Proxy Server forwards the ACK message to the User Agent Server.

After the ACK, the media stream is set up and the session is in progress. When either side wants to end the session, it sends a BYE request. As with the ACK the BYE will traverse the Proxy Server due to the Proxy Servers request. The Proxy Server forwards the BYE message. The User Agent Server responds by sending a 200 Response to the Proxy Server. The Proxy Server forwards the 200 Response to the User Agent Client.



55

SIP User to SIP User Call via two Proxy Server

SIP Proxyss1.munich.de

SIP Proxyss2.berl in.de

INVITE Bob@berlin .de(c ontains SDP offer)

100 TryingINVITE Bob @berl in.d e

100 T ryingINVITE Bo b@d ev1.berl in.d e

100 Trying

180 Ringing180 R inging

180 Ringing 200 OK(c ontains SDP answer)

200 OK200 OK

ACK

Talk

BYE

200 OK

U ACAlice@ client3.munich.de

[email protected]

Fig. 24 SIP user to SIP user call via two proxy server

Routing of SIP Responses

SIP Proxyss1.munich.de

SIP Proxyss2.berlin.de

INVITE [email protected]: SIP/2.0/UDP client3.munich.de;

branch=z9hG4bK776asdhds

[email protected]

[email protected]

INVITE [email protected]: SIP/2.0/UDP ss1.munich.de;

branch=z9hG4bKSNCLLC11202356Via: SIP/2.0/UDP client3.munich.de;


INVITE [email protected]: SIP/2.0/UDP ss2.berlin.de;

branch=z9hG4bK4b43c2ff8.1Via: SIP/2.0/UDP ss1.munich.de;



200_OKVia: SIP/2.0/UDP ss2.berlin.de;

branch=z9hG4bK4b43c2ff8.1Via: SIP/2.0/UDP ss1.munich.de;



200_OKVia: SIP/2.0/UDP ss1.munich.de;


branch=z9hG4bK776asdhds200_OKVia: SIP/2.0/UDP client3.munich.de;


The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses.

The BranchID serves as transaction identifier. It must start with “z9hG4bK” if the element is compliant to RFC3261.

Fig. 25


FN41028EN52GLA1


4.3.1 SIP Session Timer

According to the 13th version of the SIP-session-timer-draft it is recommended that an UPDATE without any SDP is used for session refresh purposes. The SIPCA is enhanced in order to receive an UPDATE without SDP in alternative to the implemented mechanism of receiving RE-INVITE with an unmodified SDP origin field. On the sending side now an UPDATE without SDP is to be sent instead of RE-INVITE, in case the following two conditions are met:

• the remote peer has signaled that it supports the UPDATE method

• a config flag allows to send UPDATE instead of RE-INVITE for session timer

The new config flag is necessary because with high probability it is to be expected that some implementations will pretend to support UPDATE, while they mean to support bearer redirect with UPDATE (and NOT this new session timer procedure).



57

SIP Session Timer (RFC4028)– a keepalive mechanism for SIP

UAC UAS

INVITE . . . (SDP A)Supported: timerSession-Expires: 1800Min-SE: 1800

UAC proposes a maximumtime interval of 30 minutesbetween the sessionrefresh requests

200 OK (SDP B)Require: timerSupported: timerSession-Expires: 1800;refresher=uac

ACK

UAS accepts the time intervaland specifies that the UAC should send the sessionrefresh requests

ACK

(Re-)INVITE . . . (SDP A) or UPDATE (without SDP)Supported: timerSession-Expires: 1800; refresher=uac

UAC periodically sendssession refresh requests(UPDATE or Re-INVITE)approx. every 15 minutes(half of the maximum timeinterval)

200 OK (SDP B)Require: timerSession-Expires: 1800;refresher=uac

• If INVITE is used as sessionrefresh request, it must con-tain a SDP Session, which isidentical with the last sent SDP(same SDP session versionin „o=“ line, see RFC3264!).

• If UPDATE is used as sessionrefresh request, it containsno SDP.

Fig. 26 Session timer

No. Time Source Destination Protocol Info38 7.436600 192.168.10.81 192.168.20.102 SIP/SDP Request: INVITE sip:[email protected];user=phone, with session descr81 15.270169 192.168.10.81 192.168.20.102 SIP/SDP Request: INVITE sip:[email protected]:5060;maddr=192.168.20.102;tran

4769 918.834932 192.168.10.81 192.168.20.102 SIP/SDP Request: INVITE sip:[email protected]:5060;maddr=192.168.20.102;tran9454 1821.713832 192.168.10.81 192.168.20.102 SIP/SDP Request: INVITE sip:[email protected]:5060;maddr=192.168.20.102;tran

14127 2724.785859 192.168.10.81 192.168.20.102 SIP/SDP Request: INVITE sip:[email protected]:5060;maddr=192.168.20.102;tran18820 3627.667910 192.168.10.81 192.168.20.102 SIP/SDP Request: INVITE sip:[email protected]:5060;maddr=192.168.20.102;tran26913 4530.646800 192.168.10.81 192.168.20.102 SIP/SDP Request: INVITE sip:[email protected]:5060;maddr=192.168.20.102;tran

Fig. 27 Session timer example


FN41028EN52GLA1


4.3.2 SDP Offer/Answer

A SIP Session is established with a successful exchange of Session Descriptions.

SIP uses an Offer/Answer Model: One UA sends a Session Description, called the Offer.

The other UA responds with another Session Description, called the Answer.

The Session Description Protocol (SDP; RFC2327) is used for Session Descriptions.

Details of the SDP Offer/Answer cycle are described in RFC3264 ("An Offer/Answer Model with the Session Description Protocol").

There are several possibilities for a successful SDP Offer/Answer Cycle:

• SDP Offer in INVITE; SDP Answer in 18x(INVITE) and/or 200_OK(INVITE)

• Empty INVITE; SDP Offer in 200_OK(INVITE), SDP Answer in ACK

• SDP Offer in 18x(INVITE), SDP Answer in PRACK

• SDP Offer in PRACK, SDP Answer in 200_OK(PRACK)

• SDP Offer in UPDATE, SDP Answer in 200_OK(UPDATE)

SDP Offer/Answer for Basic Call

SIP A Party SIP B Party

INVITE . . . .v=0o=ksession-ac120346138cac12034613c4ac12034613c4 0 1632267388 IN IP4 172.18.28.36s=SIP Callc=IN IP4 172.18.28.36t=0 0m=audio 15212 RTP/AVP 0 8 9 4 18 101a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:9 G722/8000a=rtpmap:4 G723/8000a=rtpmap:18 G729/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=ptime:20

200_OK . . . .v=0o=hiQ9200/CN0/009/076/097 00003120050530125212 155975777 IN IP4 172.18.35.10s=Phone Call via hiQ9200 SIPCAc=IN IP4 172.18.67.178t=0 0m=audio 39016 RTP/AVP 0a=rtpmap:0 PCMU/8000a=sendrecv

The SDP Offer containsone media streamwith a list of codecs

• The SDP Answer must contain acorresponding media streamfor each media stream in the Offer.

• Each media stream in SDP Answermust contain at least one codec from thecorresponding stream in the offer.

Fig. 28 SDP Offer/Answer for Basic Call



59

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SDP Offer/Answer for Basic Video Call

SIP A Party(Utopia Client)

SIP B Party(Vizufon)

INVITE . . . .v=0o=0844200206 2146 5552 IN IP4 84.81.215.50s=UtoPIA sessionc=IN IP4 84.81.215.50t=3322995185 0m=audio 34409 RTP/AVP 96 0a=rtpmap:96 AMR/8000a=rtpmap:0 PCMU/8000a=fmtp:96 octet-alignm=video 33744 RTP/AVP 98 99 34b=AS:100a=rtpmap:98 H263-1998/90000a=rtpmap:99 H263-2000/90000a=rtpmap:34 H263/90000a=fmtp:98 CIF=2 QCIF=2a=fmtp:99 CIF=2 QCIF=2a=fmtp:34 CIF=2 QCIF=2

200_OK . . . .v=0o=0844200209 2147 5553 IN IP4 213.75.12.213s=SDP Session For C&S MoIPc=IN IP4 213.75.12.213b=AS:100t=3322995185 0m=audio 35004 RTP/AVP 0a=rtpmap:0 PCMU/8000a=ptime:20m=video 35006 RTP/AVP 34a=rtpmap:34 H263/90000a=fmtp:34 CIF=2 QCIF=2

• The SDP Offer containsan audio- and a video-media stream.

• Both media streams containa list of codecs.

• Video resolution and –framerateis signalled as specified in“draft-ietf-avt-rfc2429-bis-04”.

• The SDP Answer also containstwo media streams.

• Each media stream contains thecodec(s) supported by the B party.

Fig. 29


FN41028EN52GLA1


4.3.3 Forking

One of the main functions (besides authentication and registration) of a proxy with co-located registrar and location service is to provide the following functions on the egress side:

• Route to the physical location of a user

• If the user is registered at different terminals at the same time the proxy will perform a parallel search (=forking) of the user.

In this scenario the user is registered at two terminals at the same time. The proxy tries to search the user at these physical locations and routes the call to both user agents (SIP User Agent 1 and SIP User Agent 2). If the user hooks up at SIP User Agent 1 and answers with 200 OK the proxy finishes the call setup to this user agent and also finishes the call setup to SIP User Agent 2 by sending a Cancel Request.

Forking

Office PC withSIP UA SIP Enabled

Org an izer

SIP EnabledMobile phone

SIP Phone

If multiple locations found, fork INVITE. Process only firstresponse

1) INVITE

2) IN VITE

8) 200 OK

9) 200 OK

SURPASS hiQ 4200 SIP Proxy

SURPASS hiQ 4200 SIP Proxy

Fig. 30 Forking



61

SIP Forking

SIP Phone

hiQ 4200SIP Proxy A

hiQ 4200 SIP Proxy Bmultip le locatio n entries

1) IN

VITE

6) 2

00 O

K

SIP Phone

2) Invite

5) 200 OK

SIP C lient

SIP Clien t

SIP enab ledOrganizer

SIP enab ledmobile phone

3) INVITE3) IN

VITE3) INVITE

3) INVITE

4) 200 OK

8) ACK

7) A

CK

9) ACK

Fig. 31 Forking

The forking mechanism can speed up searching for particular in the network. Some possible examples of services are: traffic news to your handset, delivery tracking, stock-watch, sales-force tracking, and taxi services. Presence will revolutionize the whole voice services. Since SIP network is capable of dynamically updating information about a user's preferences and availability, it can perform more intelligent call routing than today's PSTN or existing find-me/follow-me services. Presence makes the telephone more effective both by adding dynamic information about the user to the static address of the device and by placing it in a broader context of devices.


FN41028EN52GLA1




63

5 SIP Service Examples


FN41028EN52GLA1


5.1 Call Hold related flows

5.1.1 Call Hold

Bob‘s UA takes the call on hold by issuing a Re-INVITE with a SDP offer, that does include theattribute „inactive“

Bob‘s UA takes the call off hold by issuing a Re-INVITEwith a SDP offer, that doesinclude the attribute „sendrec“

Fig. 32 Call Hold



65

5.1.2 Consultation Hold

Fig. 33 Consultation Hold


FN41028EN52GLA1


5.2 Transfer related flow

Fig. 34 Transfer - Attended (part1)



67

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 35 Transfer - Attended (part 2)


FN41028EN52GLA1


5.3 Call Forwarding Unconditional

SIP gateway

Fig. 36 Call Forwarding Unconditional



69

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4 3-Party Conference: Third Party is Add

Fig. 37 3-Party Conference: Third Party is Add


FN41028EN52GLA1




71

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.5 Click to Dial

While browsing theComManager on his PC, Bob clicks on Carol‘s link intending to establish a session with Carol. Bob‘sweb browser passes theinfo to the SIP-server (hiQ4200/4300).

Bob‘s PC Bob Carol

INVITE180 Ringing200 ok

ACK

INVITE

200 ok

ACK

INVITE (auto-answer)

180 Ringing

200 ok

ACK

RTP

http

Fig. 38 Click to dial with Com Manager


FN41028EN52GLA1


5.6 Presence with hiQ 4300 Com Manager

The presence service that is integrated in the hiQ 4300 for the business users is standard compliant with the relevant RFCs from the SIP SIMPLE workgroup, the overall presence model, as well as the overall SIP architecture.

The presence of a user is determined by their ability, willingness, desire and capability to communicate using different types of media (e.g. Voice, Video, IM, etc) and devices. Presence is normally described in terms of the presence of a human user but it not necessarily limited to this.

The presence system collects information relating to the presence of BG Users and distributes this information to interested parties (i.e. watchers).

The security of information held and distributed by a presence system and the privacy of users is a major issue for a presence based system.

Instant Messaging is often closely associated with presence and many of the associated RFCs (e.g. [RFC 2778] and [RFC 2779]) cover both, IM and Presence.

Another application which is closely associated to presence is that of Buddy/Contact Lists, which is typically an integral part of a presence watcher application. This type of enhanced directory application is also considered to be just another presence application and will only be mentioned briefly in this document. In the context of the project addressed by this document the Com Manager is in the role of the watcher maintaining a Contact List displaying presence of the presentities.

The presence states maintained by the presence server are:

1. The “User Identity Context” which describes the availability of a person. Possible values are: In Office, Working Remotely, Be Right Back, In Meeting, On Business Trip, Out Of Office, On Vacation.

2. The “Media Availability” which describes for each device the availability per media type. Possible values for media availability are Off Line, On-Line, and Busy.

3. The “Desired-Media Filter” which describes for each user the user's preference about its wish to be contacted per media. Possible values are for media - Audio: Available, Unavailable - IM: Available, Unavailable - Video: Available, Unavailable The Presence Server will aggregate this particular states in an appropriate manner (e.g. the desired state overrides the real media state), so build a logical AND from “Media Availability and “Desired-Media Filter”.

4. The “Attendant Identity Context” which describes the availability of a person in the role of an attendant. Possible values are: Attendant On Duty, Attendant Break, Attendant Off Duty.

These states are maintained per user, thus the presence document for a user contains the identity context and the media availability for all devices owned by that user.



73

A subscriber receives the complete presence document for a user and is free to aggregate the information for presentation purposes. Supported media types are Voice, Video, and Instant Message. Additionally the portal is also modeled as a device that has as media type of web and supports the states Off Line, and On Line.

The table below illustrates the presence model for user A. If a media is not available for a device it has no entry in the presence document.

Attendant Identity Context “Attendant On Duty”

Identity Context “Working Remotely”

Aggregation Device On Line Busy On Line

Aggregation Final Off Line Busy On Line

Media Type Device

Instant Message

Voice Video

Desired-Media Filter

Unavailable Available Available

Soft Phone 1 On Line On Line On Line

Hard Phone 1 Busy

The Presence Server will provide the aggregated Media Type state in addition to the particular Media Type states per devices for flexibility reasons.

The user will set his identity context with the web portal. The Com Manager will publish this value using the Simple interface to the presence server (with the publish method). The presence server will persistently store the user identity context. The Com Manager may also publish the media availability for the web portal to indicate if the user has signed in through the web interface. The Identity Context is completely independent of Media Type status. The Com Manager will not publish the Web media state in this first step (the respective information can be derived from Identity-Context (enhance-user-state) also.

The voice, video, and IM media availability is published by the hiQ 4200. Upon receiving a subscription from the Com Manger the presence server in turn subscribes to the hiQ 4200 to obtain voice, video, and media availability.

Each user can manage the privacy of his presence data by administrating a personal white list that contains the contacts with whom the user is willing to share presence.

Additionally the business group administrator can define a business group white list. The business group white list defines the contacts that are allowed to access the presence of all users in that business group. When the white list filter is applied a contact may obtain presence information for a user in a business group if he either is in the business group white list or in the personal white list. The Business Group White List is particularly useful for applications (e.g. Com Manager) that must know about the status of all users in the business group.


FN41028EN52GLA1


SUBSCRIBEwithResourcelist ID

SUBSCRIBE

SUBSCRIBE

SUBSCRIBE

SUBSCRIBEsfor users ofresource list withPresence serviceenabled

SUBSRIBEswill be send via Spooler to minimize the traffic load to hiQ4200 CS !

SUBSRIBEswill be send via Spooler to minimize the traffic load to hiQ4200 CS !

Resourcelist ID isthe Business Group ID

Resourcelist ID isthe Business Group ID

NOTIFY

200 OK

NOTIFY

SUBSCRIBE

200 OK

SUBSCRIBE

200 OK

SUBSCRIBEsfor users ofresource list withPresence serviceenabled

Accumulated NOTIFY

200 OK

Send response if Business Group found

One NOTIFY message contains aggregated presence info for many UAs to minimize the traffic load to Com Manager !

One NOTIFY message contains aggregated presence info for many UAs to minimize the traffic load to Com Manager !

200 OK

200 OK

200 OK

200 OK

Notifications can already be received while Subscriptions are still sent.

hiQ 4300 Com Manager hiQ 4200 Presence Server hiQ 4200 Communication Service

Fig. 39 Initial SUBSCRIBE handling for a Business Group (hiQ 4200/4300)



75

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

hiQ 4300 Com Manager

hiQ 4200 PresenceServer

hiQ 4200 CommunicationService

PUBLISHfor single user in case ofextended stats change

NOTIFY

NOTIFYfor subscribedusers !

NOTIFYswill be send via Spooler to minimize the traffic load to Com Manager !

NOTIFYswill be send via Spooler to minimize the traffic load to Com Manager !

Store extendedstatus persistentin common DB !

NOTIFY for other subscriptionsor watcherspotential 2nd. User (e.g.client)

Note: User is assumed to be already subscribed at PSA

200 OK

200 OK

200 OK

Fig. 40 PUBLISH handling hiQ 4200


FN41028EN52GLA1




77

6 SIP Gateway and ISUP/SIP Inter-working


FN41028EN52GLA1


The ITU-T Recommendation Q.1912.5 profile B defines the signaling inter-working between ISDN User Part (ISUP) protocols and Session Initiation Protocol (SIP) with its associated Session Description Protocol (SDP) at an ISUP exchange. ISUP is defined in accordance with ITU-T Q.761 to Q.764. SIP and SDP are defined by the IETF.

It is assumed that the initial service requests are forwarded and/or delivered via a trusted SIP Node within a SIP network domain and thus the interface between the ISUP exchange and the SIP Node is a Network to Network interface (NNI). Where Profile C (SIP I) is used, it is assumed that the remote SIP User Agent is able to process ISUP. This is explained in the next chapter.

The services that can be supported through the use of the signaling inter-working are limited to the services that are supported by ISUP and SIP-based network domains. Services that are common in SIP and ISUP network domains will inter-work by using the function of an Inter-working Unit (IWU). The IWU will also handle (through default origination or graceful termination) services or capabilities that do not inter-work across domains.

The following RFCs are supported on the signaling interface:

• RFC 3261 "SIP"

• RFC 3262 "Reliable provisional responses"

• RFC 3264 "Offer/Answer Model"

• RFC 3325 "Private Extensions to the SIP for Asserted Identity within Trusted Networks"

• RFC 3326 "The Reason Header Field for SIP"

• RFC 3311 "SIP UPDATE Method"



79

PSTN

Operator

hiQ 4200

IP Centrex Domain

hiE 9200

basic

SIP:

NNI

national

ISUP

SIP:NNI

to SIP:UNI

IW

SIP:UNI

B2B

UA

B2B

UAUCE

ISUP

LTGPCU

SIP

LTG

ISUP

LTG

User

LTG

H.248

Interworking :

ISUP to

to basic SIP IW

ISUP to

to analog or

ISDN

User IW

end to end feature interworking

hiG 1x00

Fig. 41 End to end feature inter working

Message flow for ISUP to SIP Call Setup

IAMCRCX (TDM-port MG)

200 OK (IP address MG)

MG MGC Proxy

PRACK180_Ringing

100_Trying

INVITE

MDCX (Ring_back_tone)ACM subscriber_free)

200_OK200_OK (prack)200_OK ACK

MDCX (IP address, port SIP UA)

200_OKANM

re-INVITE (session_timer)200_OK ACK

IP-BearerTDMIP-Bearer

Fig. 42 PSTN to SIP


FN41028EN52GLA1


6.1 SIP-T/SIP-I

ISUP is the protocol used in SS7 networks to set up and manage basic call connections.

In the Virtual Trunking application scenario, PSTN calls hop onto the IP network over a media gateway, like hiG, and then hop back off to the PSTN. While SIP is used to route calls over the IP networks, it is important to maintain feature transparency. The primary way is carrying the incoming ISUP through the IP network to the media gateway on the far end.

This can be accomplished with SIP-T (SIP for telephony), a simple extension of SIP that preserves needed ISUP information as the call is carried through the IP network. This is done by actually carrying the ISUP message, byte for byte, in the body of the SIP messages. Since SIP supports transfer of any type of content, ranging from image files to HTML web pages, it can easily carry ISUP messages.

In contradiction to the IETF SIP -T work, the ITU-T SIP-I took into account the latest ITU-T ISUP/BICC signaling versions. Furthermore not only the core SIP protocol but also some SIP extensions to support additional procedures and supplementary services (e.g. CLIP/CLIR) have been considered. There is no big difference between the SIP-T standard based on RFC 3398 and our implemented SIP-I standards based on Q1912.5 implementation when it comes to Profile C. The inter-working of all the features can be ensured with both standards because it involves only encapsulation. However Q.1912.5 - Profile C gives more details with respect to some ISUP mapping, details which are not covered in RFC 3398.

Telecordia delegates attending an ITU-T meeting in Geneva said, that the ANSI SIP spec is completely based on ITU-T and that all major U.S. operators will follow this specification. There is of course also SIP-T in commercial operation, mostly because at the time of start there was only the IETF spec available.



81

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Session Initiation Protocol for Telephones (SIP-T)

IETF Standard (RFC3372), specifies a set of mechanisms for interfacing traditional telephone signaling with the SIP protocol.

SIP-T components are:

All methods and procedures of Core SIP as defined in RFC 3261.

the encapsulation of PSTN signaling in SIP messages (by using new MIME media types for ISUP and QSIG Objects and multipart MIME bodies; see RFC3204).

the protocol translation between SIP and ISUP on message and parameter level (see RFC3398).

The transport of mid-call signalling information (such as the ISUP user-to-userinformation) by using the SIP INFO method (see RFC2976).

SIP-T messages are ASCII encoded with the exception of the encapsulated ISUP content, which is binary encoded.

ITU-T has an own recommendation for ISUP-SIP Interworking (Q.1912.5, “SIP-I”).

Fig. 43


FN41028EN52GLA1


Message Flow for SIP-I Bridging

IAM

100_Trying

MGC egressMGC ingress

ANM

183_Session_Progress

PRACKACM (no_indication) 200_OK (prack)

INVITE

Path established in both direc tions

IAM (cot_on_prev_circuit)

COT (successful)

ACM (no_indication)

CPG (alerting)180_Ringing

PRACK

200_OK (prack) CPG (alerting)

ANM200_OK

ACK

SBC

Fig. 44



83

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP-I Message Layout ExamplePart 1: SIP header fields

Session Initiation ProtocolStatus-Line: SIP/2.0 180 Ringing

Status-Code: 180Resent Packet: False

Message HeaderVia: SIP/2.0/TCP 192.168.10.81:5060;branch=z9hG4bK07259044920000826547.From: <sip:[email protected];user=phone>;tag=443cc990-1ee740-c0a80a51

SIP from address: sip:[email protected] tag: 443cc990-1ee740-c0a80a51

To: <sip:[email protected];user=phone>;tag=443cc990-12540c-c0a80c15SIP to address: sip:[email protected] tag: 443cc990-12540c-c0a80c15

Call-ID: 443CC990-000C9C92@pcueCSeq: 1 INVITEContact: <sip:192.168.12.21>

Contact Binding: <sip:192.168.12.21>URI: <sip:192.168.12.21>

SIP contact address: sip:192.168.12.21MIME-Version: 1.0Require: timerRequire: 100relRSeq: 1Allow: CANCELAllow: INFOAllow: OPTIONSAllow: BYEAllow: PRACKAllow: UPDATEContent-Type: multipart/mixed;boundary=sdp-isup-boundary-1Content-Length: 556

Fig. 45 SIP header fields


FN41028EN52GLA1


SIP-I Message Layout ExamplePart 2: SIP Message Body: SDP Content

Message bodyMIME Multipart Media Encapsulation, Type: multipart/mixed, Boundary: "sdp-isup-boundary-1"

Type: multipart/mixedFirst boundary: --sdp-isup-boundary-1\r\nEncapsulated multipart part

Content-Type: application/sdp\r\n\r\nSession Description Protocol

Session Description Protocol Version (v): 0Owner/Creator, Session Id (o): hiQ9200/CN0/070/012/083 3620060312113408 1175191635 IN IP4 192.168.12.21

Owner Username: hiQ9200/CN0/070/012/083Session ID: 3620060312113408Session Version: 1175191635Owner Network Type: INOwner Address Type: IP4Owner Address: 192.168.12.21

Session Name (s): Phone Call via hiQ9200 SIPCAConnection Information (c): IN IP4 192.168.12.130

Connection Network Type: INConnection Address Type: IP4Connection Address: 192.168.12.130

Time Description, active time (t): 0 0Session Start Time: 0Session Stop Time: 0

Media Description, name and address (m): audio 5268 RTP/AVP 4Media Type: audioMedia Port: 5268Media Proto: RTP/AVPMedia Format: ITU-T G.723

Media Attribute (a): rtpmap:4 G723/8000Media Attribute Fieldname: rtpmapMedia Attribute Value: 4 G723/8000

…Media Attribute (a): sendrecv

Fig. 46 SIP Message Body: SDP Content



85

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP-I Message Layout ExamplePart 3: SIP Message Body: ISUP Content

Boundary: \r\n--sdp-isup-boundary-1\r\nEncapsulated multipart part

Content-Type: application/isup;version=itu-t92+\r\nContent-Disposition: signal;handling=required\r\n\r\nISDN User Part

Message type: Address complete (6)Backward Call Indicators: 0x1604

Mandatory Parameter: 17 (Backward call indicators).... ..10 .... .... = Charge indicator: Charge (0x0002).... 01.. .... .... = Called party's status indicator: Subscriber free (0x0001)..01 .... .... .... = Called party's category indicator: Ordinary subscriber (0x0001)00.. .... .... .... = End-to-end method indicator: No End-to-end method available (only link-by-link method available) (0x0000).... .... .... ...0 = Interworking indicator: no interworking encountered (No.7 signalling all the way).... .... .... ..0. = End-to-end information indicator: no end-to-end information available.... .... .... .1.. = ISDN user part indicator: ISDN user part used all the way.... .... .... 0... = Holding indicator: holding not requested.... .... ...0 .... = ISDN access indicator: terminating access non-ISDN.... .... ..0. .... = Echo Control Device Indicator: Echo control device not included.... .... 00.. .... = SCCP method indicator: No indication (0x0000)

Pointer to start of optional part: 1Optional backward call indicators: 0x1

Optional Parameter: 41 (Backward call indicators)Parameter length: 1.... ...1 = In-band information indicator: in-band information or an appropirate pattern is now available.... ..0. = Call diversion may occur indicator: no indication.... .0.. = Simple segmentation indicator: no additional information will be sent.... 0... = MLPP user indicator: no indication

Parameter Type unknown/reserved (1 Byte)Optional Parameter: 122 (unknown)Parameter length: 1

Parameter compatibility information (2 bytes length)Optional Parameter: 57 (Parameter compatibility information)Parameter length: 2Upgraded parameter no: 1 = unknown (122)Instruction indicators: 0xc0 .... ...0 = Transit at intermediate exchange indicator: Transit interpretation.... ..0. = Release call indicator: do not release call.... .0.. = Send notification indicator: do not send notification.... 0... = Discard message indicator: Do not discard message (pass on)...0 .... = Discard parameter indicator: Do not discard parameter (pass on).10. .... = Pass on not possible indicator: Discard parameter (0x02)1... .... = Extension indicator: last octet

End of optional parameters (0)Last boundary: \r\n--sdp-isup-boundary-1--

Fig. 47 SIP Message Body: ISUP Content


FN41028EN52GLA1


6.2 ISUP overlap signaling to SIP/SIP-I overlap signaling

Overlap signaling consists of sending only some digits of the called party's number in the first signaling message. Further digits are sent in subsequent signaling messages. Although overlap signaling in the PSTN is the source of much additional complexity, it is still used in some countries. As the collection of the received digits in one network element (conversion of overlap to en-bloc) can result in unacceptable (multiple-second) call setup delays to subscribers, some form of overlap signaling has to be introduced in the SIP network to minimize this impact.

RFC3578 “Mapping of ISDN User Part (ISUP) overlap signaling to the SIP” and ITU-T rec. Q1912.5 are describing the mechanism of how Overlap signaling (as known from ISUP) can be applied to a SIP network.

With the introduction of overlap signaling in SIP networks, the SIP-LTG has to verify if "overlap" or "en-block" sending is used. This information will be extracted by the encapsulated IAM inside ISUP MIME content.

With the hiE 9200 V4 two realizations were implemented:

• Overlap signaling via multiple INVITE (basic solution)

• Overlap signaling via INFO messages (second approach)

NOTE:

Interworking between hiE S4 (Overlap functionality introduced) and older versions is not possible as the older versions of hiE do not support overlap.



87

6.2.1 Overlap signaling via multiple Invite messages (basic solution)

1. IAM (digits first part)

5. SAM (next digit)

10. SAM (last digit)

15. ACM

2. Invite

6. Invite (next digit)

11. Invite (last digit)

8. 484 Addr Incompl


7. SAM (next digit)


13.ACM

4. 100 TRYING

9. ACK

14. 180 Alerting

Overlap signaling via multiple Invite messages (basic solution)

Fig. 48 SIP Overlap signaling by multiple SIP Invite messages

If nothing special is configured the hiE 9200 forwards as long as there are digits via ISUP delivered to it, them via SIP/I INVITE to the adjacent softswitch.

If the hiE 9200 receives the digits via SIP/I INVITE, the standard behavior is to produce a SIP 484 (Address Incomplete) when an additional SIP/I INVITE (with the next digit) is present. This message exchange is repeated as long as the final B-destination doesn't indicate the end of digits via the ISUP Address Complete Message. The end of dialing is then indicated to the originating hiE by the SIP 180 Alerting message.


FN41028EN52GLA1


6.2.2 Overlap by using SIP/I INFO (second approach)


4. SAM (next digit)


2. INVITE

6. PRACK

8. INFO (next digit)

10. 200 (INFO)


9. SAM (next digit)


5. 183 Session Progress

7. 200 (PRACK)

12. INFO (last digit)

14. 200 (INFO)

p y g ( pp )

Fig. 49 Overlap sending via SIP/I INFO

In this scenario, the hiE 9200 receives an IAM (Initial Address Message) and possibly one or more SAMs (Subsequent Address Message) that provide more than the minimum amount of digits that can represent a phone number.

As soon as the minimum amount of digits is received, the hiE sends an INVITE to the adjacent softswitch. If a SAM arrives to the LTG, it is encapsulated into a SIP/I INFO instead of an SIP/I INVITE. The originating hiE MUST NOT send any SIP/I INFO request until it receives 183 Session Progress response.

In the case of an incoming SIP/I INVITE the hiE 9200 checks what behavior is configured (sending the SIP 484 Addr Incomplete or sending SIP 183 Session Progress), the corresponding response is sent to the other softswitch. The subsequent SAMs have to be delivered via SIP/I INFO messages.

To configure the behavior of the second approach (sending a SIP/I 183 Session Progress) the property value 17 has to be assigned to the SIP/I trunk group.

CR TGRP TGNO =

GCOS = SIPT & PROP17



89

7 Call flows for SIP-NNI and SIP-I


FN41028EN52GLA1


7.1 JMSIP: SIP interworking program

The Subsystem JMSIP is a GP User Program in between of TP1 Interface (Transfer Program 1) and ISUP. It belongs to ISUP, and its scope is to provide an efficiently mapping of ISUP orders to ISIP reports and vice versa. Moreover, when PCUs receive a SIP message, it translates it to an ISIP report and sends it to TP1. There, JMSIP is called to receive this report, translate it to a well-defined ISUP order and send it to ISUP via LTG OS task queue. These internal ISUP orders are visible in the Signaling Tracer.

On the opposite direction, whenever ISUP prepares an order, calls JMSIP to map this order to a well-defined ISIP report and sent it (through TP1) to PCUs.

This mapping functionality (among other) allows a SIP subscriber to perform and receive calls from PSTN through a Call Feature Server.

JMSIPJMSIPLTGOS

LTGOS

Order Interface

ISUPISUP

JMGTU

(TP1)

JMGTU

(TP1)

PCUsPCUs

Report Interface

JBIUS(ISUP)JBIUS(ISUP)

Dummy Order Interface(Procedure)

Fig. 50 Interface Diagram of JMSIP



91

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Message ID

Message

01h -

02h Release

82h Release Ack

03h Facility

04h Forward SAM

05h Forward Setup

06h Backward Setup

07h Forward Setup Reject

08h Suspend

09h Resume

0Ah Bearer Redirect Request

Messages Parameters

ISUP-SIP Interworking Protocol (ISIP)

Tag ID

Name

01h LTG Port

02h SIP Proxy

03h Calling SIP URL

04h ISUP MIME Content

05h MCA/BAT Transparent Data

06h ISUP Version

07h ISUP MIME Handling

09h CdPN

0Ah CgPN

0Dh Response Information

15h Calling Party Category

Fig. 51 ISIP Messages & Parameters


FN41028EN52GLA1


7.2 Call flows PSTN (ISUP) to SIP (Basic call)

IAM received

When an IAM is received the NI, OPC and CIC contained in the message is converted to the appropriate URL of that trunk and a MGCP:CRCX or MEGACO:Add is sent.

The MG seizes a RTP port and provides its IP address in the acknowledgement message to the MGC.

On receipt of 200 (OK) the SIP INVITE is sent to a SIP proxy server and SIP timer T1 is started. The INVITE contains the SDP parameters received from the MG. Furthermore a Supported header with the option tag "timer" and a Session-Expires header must be included. Thus the SIP agent in the MGC behaves like an UAC.

100 (Trying) received

Upon receipt of the 100 (Trying) the SIP timer T1 is stopped.

180 (Ringing) received

Upon receipt of the 180 (Ringing) the ACM indicating "subscriber free" is generated and the MG is instructed by sending an MGCP:MDCX or MEGACO:Modify to connect the ring back tone to the ISUP trunk. Therefore the Call Progress Tones Generator Package acc. H.248 RFC chapter E.7 is used.

200 (OK) received

The SIP 200 (OK) contains the remote SDP information, which is sent in a MGCP:MDCX or MEGACO:Modify to the MG.

The MG through-connects the transmission in both directions and sends 200 (OK) to the MGC.

The 200 (OK) from the MG causes sending of the ISUP ANM and the SIP ACK messages. Eventually the call has been successfully established.

REL received

Upon receipt of a ISUP REL message an MGCP:DLCX or MEGACO:Substract is sent to the MG and a SIP BYE is forwarded to the SIP proxy.

On receipt of the 250 response code from the MG the RLC is sent on the ISUP side.

Eventually all call resources are released when the SIP 200 (OK) arrives and the ISUP trunk is marked idle again.



93

MGC_IhiE 9200

MG_IhiG 1x00

T11(15 s)

T1

Session_Timer

ACM (subscriber_free)

ANM

100_Trying

180_Ringing

200_OK (INVITE)

INVITE

ACK

IAM

PRACK

200_OK (PRACK)

re-INVITE (SDP=single_codec)200_OK (INVITE)

ACK

MGCP:MDCX/MEGACO:Modify

200_OK/reply

R ing_back_tone

200_OK

MGCP:CRCX/MEGACO:Add

PSTNSIPserver

MGCP:MDCX/MEGACO:Modify

200_OK/reply

Fig. 52 A-side PSTN to B-side SIP call setup


FN41028EN52GLA1


MGChiE 9200

MGhiG 1x00

Session_Timer(if running)

RLC

200_OK

BYE

REL

250_Deleted/reply

MGCP:DLCX/MEGACO:Substract

PSTNSIPserver

Fig. 53 A-side PSTN to B-side SIP call release



95

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP/ISUP Mapping in hiE 9200, Basic PSTN->SIP Call

PCU (SIPCA) BSIPIWP LTG BSIP ISUP LTG BCPMG ISUP LTG APCU (VT CA) AhiG1200 A

O:IAMM:SEIZURE_CA

M:DIGIT_BLOCK_CC:SEIZURE_CBT

C:SETUP_CMCU:SETUP_I

MCU:SETUP_ACK(BAT)

CRCX

200 123 OK(SDP A)R:SETUP_COMPLETE(BAT) O:IAM(BAT ) ISIP:FwSetup(BAT) INVITE (SDP A)

180_RingingISIP:BwSetup(180)O:ACMR:ACMMCU:MODIFY(ToneOn)MDCX(RT on)

200 124 OK200_OK(SDP B)

ISIP:Facility(BAT)O:APM(BAT)R:APM(BAT)MCU:FACILITY(BAT)

MCU:MODIFY_ACK

ISIP:BwSetup(200)O:ANMR:ANMMCU:MODIFY(ToneOff)

ACK

MCU:FACILITY(BAT)R:APM(BAT) O:APM(BAT ) ISIP:Facility(BAT)

MDCX(RT off, SDP B)

200 124 OKMCU:MODIFY_ACK

O:ACM

O:ANM

Fig. 54 A-side PSTN to B-side SIP (internal flow)


FN41028EN52GLA1


Announcement before answer and Ring-back-tone

The hiQ 4200 may provide an announcement (IP Unity) before answer, e.g. if an unallocated SIP number was dialed. This means that the bearer has to be through connected in backward direction with the receipt of a SIP:183_Session_Progress response containing the announcement data in the SDP part. Therefore the hiQ 4200 has to be administered as Trustworthy ASN (Adjacent SIP node).

But the hiQ 4200 does not support the Bearer Through Connection procedures according Q.1912.5 and it will therefore not provide a Ring-back-tone. The SIP Clients will also not do this.

• The hiE 9200 (MG) has to apply the Ring-back-tone to the A-side although the ASN is trustworthy. If a SIP:180_Ringing response is received from the B-side, the MG-ISUP LTG will inform the A-side CA to apply the local Ring-back-tone in the MG and to set the connection to “inactive”.

• The MG-ISUP LTG will inform the A-side CA to disable the local Ring-back-tone in the MG and to set the connection to “sendrecv”, if the B-side answers and sends a SIP:200_OK response to the initial INVITE.

• If a 183_Session_Progress containing SDP (e.g. announcement data) is received from the B-side, the A-side CA passes the SDP data to the A-side and sets the connection to “sendrecv”, if no local Ring-back-tone is applied at that time. Otherwise the SDP data are stored until the Ring-back-tone is disabled.

• If a SIP:UPDATE request is received from the B-side, the Call is redirected, but it cannot be determined if the new B-party is an announcement or another SIP subscriber. Therefore the A-side CA will disable the Ring-back-tone and set the connection to “sendrecv” per default if it receives a BICC:Bearer Redirection request. The A-side CA will also inform the MG-ISUP LTG about the Ringacktone deactivation.



97

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

msc Rbk03

hiQ hiE9200 (SIPCA) MLHG_Member SIPIWP VT_CA MG ISUP

A Party hears Announcement

INVITE(SDP A)

183_Session_Progress(SDP Ann.)

BAT_ASE(AI = ConnFw,IP Data A)

CRCX

CRCX_ACK(SDP A)

INVITE(SDP A)

(*) BwSetup(183,TWTC=yes)

MDCX_ACK

180_Ringing

BAT_ASE(AI = ConnFw+No+SCod,IP Data Ann.,TWTC=yes) MDCX(SDP Ann.,sendrecv)

BAT_ASE(AI = Connected)

PRACK

200_Ok(PRACK)

UPDATE(SDP C) BAT_ASE(AI = Bearer Redirect,BRI = RdFwReq, RdBRComp, IP Data C)

MDCX(SDP C,RBK Off, sendrecv)

MDCX_ACK

200_Ok(INVITE) BwSetup(200,TWTC=yes)

BAT_ASE(AI = Bearer Redirect,BRI = RdBrConnected, IP Data A) 200_Ok(UPDATE,SDP A)

180_Ringing BwSetup(180,TWTC=yes) MDCX(RBK On,inactive)

MDCX_ACK

200_Ok(INVITE,SDP C)

ACK

ACK

ACM(Subscriber Free, InbandInfo=NoIndication) Modify(RingbackTone On)

Modify_Ack

ANM

Notification(RingbackTone Off)

Fig. 55 Example Ring-back-tone handling


FN41028EN52GLA1


7.3 Call flows SIP to PSTN (ISUP) (Basic call)

INVITE received

On receipt of a SIP INVITE message a routing task is performed using the E.164 number contained in the To header of the INVITE message. The routing result points to the proper ISUP access that is to be used for this call. The circuit selection procedure chooses an idle trunk within this ISUP access . Finally this trunk is marked busy in the MGC and a MGCP:CRCX OR MEGACO:ADD containing SDP information is sent to the MG.

The MG returns the 200 OK message containing SDP information.

Upon receipt of the INVITE the ISUP IAM is sent to the PSTN and timer T7 to await address complete is started.

ACM received

The subsequent ACM message with "no indication" is mapped to 183 (Session Progress). On receiving of ACM the timer T7 is stopped and T9 to await an answer indication is started. A Require header containing the option tag 100rel is included in the 183 (Session Progress), if this option is supported by the UAC.

ANM received

The ANM message is mapped to 200 (OK) and timer T9 is stopped. With regard to the SIP session timer the SIP agent behaves like an UAS.

ACK received

Upon receipt of the SIP ACK message the call is established.

BYE received

Upon receipt of a SIP BYE message a MGCP:DLCX or MEGACO:Substract is sent to the MG and a ISUP REL is forwarded to the PSTN.

With the 250 response code from the MG the SIP 200 Ok is sent.

Upon receipt of the ISUP RLC message all call resources are released and the ISUP trunk is marked idle again.



99

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MGC_EhiE 9200

MG_EhiG 1x00

T7(20-30 s)

T9(90-180 s)

ACK

100_Trying

183_Session_Progress

180_Ringing

200_OK

ACM(no_indication)

CPG(alerting)

ANM

IAM(cot_on_prev_circuit)

INVITE

PRACK

200_OK

PRACK

200_OK

COT(successful)

200(OK)

CRCX/Add

SIPserver PSTN

Fig. 56 A-side SIP to B-side PSTN call setup


FN41028EN52GLA1


MGChiE 9200

MGhiG 1x00

Session_Timer(if running)

T1(60 s)200_OK

RLC

REL

BYE

250_Deleted/reply

DLCX/Substract

PSTNSIPserver

Fig. 57 A-side SIP to B-side PSTN call release



101

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SIP/ISUP Mapping in hiE 9200 Basic SIP->PSTN Call

PCU (SIPCA) A SIPIWP LTG A SIP ISUP LTG A CP MG ISUP LTG B PCU (VT CA) B hiG1200 B

INVITE (SDP A)

M:INFO_REQUEST (hiE 9200 V1.1 only)

C:INFO_RETURN (hiE 9200 V1.1 only)

ISIP:FwSetup(BAT)

BAT=Bearer Association Transport(ITU Recommendation Q.765.5, BICC)

O:IAM(BAT)M:SEIZURE_CA

M:DIGIT_BLOCK_C

C:SETUP_CC:SEIZURE_CBT

R:SETUP_COMPLETE(BAT) O:IAM

MCU:SETUP_E(BAT) CRCX/Add (SDP A)

200 OK(SDP B)MCU:FACILITY(BAT)R:APM(BAT)

O:APM(BAT)ISIP:Facility(BAT)

ISIP:Facility(BAT)

O:APM(BAT )

R:APM(BAT) MCU:FACILITY(BAT)

MCU:SETUP_ACK

O:ACMR:ACM

O:ACMISIP:BwSetup(180 ) O:ANM

R:ANMO:ANMISIP:BwSetup(200

)

180_Ringing(SDP B)

200_OK(SDP B)

ACK

Fig. 58 A-side SIP to B-side PSTN (internal flow)


FN41028EN52GLA1


7.4 CLIP/CLIR and Support of Additional Calling Party Number

7.4.1 ISIP to SIP mapping for CLIP/CLIR

If an ISIP:FwSetup message is received by SIPCA, the setup of the SIP From, Privacy and P-Asserted-Identity header fields depends on the content of the Calling Party Number and the Additional Calling Party Number parameter. The following table shows the ISIP SIP mapping (ISIP:FwSetup SIP:INVITE) for CLIP/CLIR.

Q.1912.5 requires the support of the Additional Calling Party Number for CLIP/CLIR. The ISIP:FwSetup message was enhanced with the new parameter ISIP:GenericNumber. This parameter can carry several types of numbers, distinguished by the Number qualifier indicator. It may appear in an ISIP message even more than once.

Case ISIP Calling Party Number Format

ISIP Additional Calling Party Number Format

ISIP Parameter

SIP Parameter

1 Complete E.164 Number

Screening Indicator = Network provided or UPVP

APRI = Presentation allowed or restricted

Complete E.164 Number

Screening Indicator = UPNV (note 3)

APRI = Presentation allowed

Calling Party Number, Digits

Additional Calling Party Number, Digits

Calling Party Number, APRI

P-Asserted-Identity header, name-addr/addr-spec (hostname part is set to IP address of hiE9200).

From header: - Map Digits to name-addr/addr- spec (hostname part is set to IP address of hiE9200).

Privacy header: - Setup Privacy header with priv-value = “id”, if APRI = Presentation restricted. - Omit Privacy header if APRI = Presentation allowed.

2 Complete E.164 Number

Screening Indicator = Network provided or UPVP

APRI = Presentation allowed or restricted

ISIP Additional Calling Party Number does not fulfill the above mentioned conditions



Calling Party Number, APRI

P-Asserted-Identity header, name-addr/addr-spec (hostname part is set to IP address of hiE9200).

From header: - Map Digits to name-addr/addr- spec, if APRI = Presentation allowed (hostname part is set to IP address of hiE9200).. - Setup anonymous URI “<sip: [email protected]>”, if APRI = Presentation restricted.

Privacy header: - Setup Privacy Header with priv-value = “id”, if APRI = Presentation restricted. - Omit Privacy Header if APRI = Presentation allowed.

3 ISIP Calling Party Number does not fulfill the above mentioned conditions

Complete E.164 Number

Screening Indicator = UPNV (note 3)

APRI = Presentation allowed

Additional Calling Party Number, Digits

P-Asserted-Identity header is omitted.

From header: - Map Digits to name-addr/addr- spec (hostname part is set to IP address of hiE9200).

Privacy header is omitted.

4 ISIP Calling Party Number does not fulfill the above mentioned conditions

ISIP Additional Calling Party Number does not fulfill the above mentioned conditions

P-Asserted-Identity header is omitted.

From header is set to “<sip:Unavailable@ip_addr_hiE9200>”

Privacy header is omitted.



103

7.4.2 SIP to ISIP Mapping for CLIP/CLIR

If a SIP:INVITE message is received by the SIPCA, the mapping into the ISIP protocol depends on the received P-Asserted-Identity and From headers.

Due to non-support of the P-Asserted-Identity header by the hiQ 6200, it is still necessary to map the From header into the Calling Party Number respectively Calling SIP URL parameter, if the INVITE is received from a hiQ 6200. The hiQ 6200 guarantees that the number in the From header is a valid number. The knowledge about the source of the INVITE is deduced from the PCU SIP node table.

The following table shows the SIPISIP mapping (SIP:INVITE ISIP:FwSetup) for CLIP/CLIR:

Case SIP Precondition SIP Parameter ISIP Parameter

1 P-Asserted-Identity header contains an E.164 number

From header contains an E.164 number

P-Asserted-Identity header, name-addr/addr-spec

Privacy header, priv-value

From header, name-addr/addr-spec



Calling Party Number, APRI: - Presentation restricted, if priv-value = “id”, “header” or “user”. - otherwise Presentation allowed (this value is also set if Privacy header is not available)

Calling Party Number, SI: - network provided

Additional Calling Party Number, Digits:

Additional Calling Party Number, APRI: (use the same settings as for Calling Party Number, APRI).

Additional Calling Party Number, SI: - user provided, not verified

2 P-Asserted-Identity header contains an E.164 number

From header contains NO E.164 number

P-Asserted-Identity header, name-addr/addr-spec



Calling Party Number, APRI: - Presentation restricted, if priv-value = “id”, “header” or “user”. - otherwise Presentation allowed (this value is also set if Privacy header is not available)

Calling Party Number, SI: - network provided

Additional Calling Party Number is omitted.

3 P-Asserted-Identity header is available but contains NO E.164 number


P-Asserted-Identity Header, name-addr/addr-spec

From header, name-addr/addr-spec


Calling SIP URL (Calling Party Number is omitted!)


Additional Calling Party Number, APRI: - Presentation restricted, if priv-value = “id”, “header” or “user”. - otherwise Presentation allowed (this value is also set if Privacy header is not available).



FN41028EN52GLA1


Case SIP Precondition SIP Parameter ISIP Parameter 4 P-Asserted-Identity header is not available


From header, name-addr/ addr-spec


From header, name-addr/ addr-spec


Calling Party Number is omitted or Calling Party Number, Digits (note)

Calling Party Number is omitted or Calling Party Number, APRI (note): - Presentation restricted, if priv-value = “id”, “header” or “user”. - otherwise Presentation allowed (this value is also set if Privacy Header is not available)

Calling Party Number is omitted or Calling Party Number, SI: - network provided


Additional Calling Party Number, APRI: - Presentation restricted, if priv-value = “id”, “header” or “user”. - otherwise Presentation allowed (this value is also set if Privacy header is not available).


5 P-Asserted-Identity header is not available

From header contains NO E.164 number

From header, name-addr/ addr-spec Calling SIP URL (note) (Calling Party Number is omitted!).

Additional Calling Party Number is omitted.

Session Initiation ProtocolRequest-Line: INVITE sip:[email protected]:5060 SIP/2.0Message Header

From: PRIVATE <sip:[email protected]>;SIP Display info: PRIVATE SIP from address: sip:[email protected] tag: 1144829926-8395761145669502-11

To: <sip:[email protected];user=phone>SIP to address: sip:[email protected]

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

O: JC1=H'1A JC2=H'00 RECEIVED GP-A 1 HC/MT=H'01 IAM 00005C hiE internal01 Message Type: IAM01 Nature of Connection: no satellite,CTC not required,outg. EC incl.2000 Forward Call Indicator: call to be treated as a national call, …0A Calling Party Category00 Transmission medium requirement: speech02 Pointer0806 03900808 2042 Called Party Number: national significant number,

numbering plan (E.164), 808002240A05 0313982822 Calling Party Number:national significant number,

numbering plan (E.164), presentation allowed, network provided , 898222

3D011F reservedD3060584 BC01680E reserved

Fig. 59 SIP to PSTN without CLIR



105

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Session Initiation ProtocolRequest-Line: INVITE sip:[email protected]:5060 SIP/2.0Message Header

From: Anonymous <sip:[email protected]>;SIP Display info: Anonymous SIP from address: sip:[email protected] tag: 1144830136-9903191145820455-11

To: <sip:[email protected];user=phone>SIP to address: sip:[email protected]

Privacy: idP-Asserted-Identity: Unavailable <sip:[email protected]>

O: JC1=H'1A JC2=H'00 RECEIVED GP-A 1 HC/MT=H'01 IAM 00005C hiE internal01 Message Type: IAM01 Nature of Connection: no satellite,CTC not required,outg. EC incl.2000 Forward Call Indicator: call to be treated as a national call, …0A Calling Party Category00 Transmission medium requirement: speech02 Pointer0806 03900808 2042 Called Party Number: national significant number,

numbering plan (E.164), 80800224

0A06 01179498 2822 Calling Party Number: subscriber numbernumbering plan (E.164), presentation restricted, network provided , 49898222

3D011F reservedD30605 84BC0128 08 reserved

Fig. 60 SIP to PSTN with CLIR


FN41028EN52GLA1




107

7.5 Codec Mapping according to Q1912.6

In the hiE 9200 of the V3.x and lower the SIP-LTG entered a default value for the ISUP parameter TMR (Transmission Medium Requirement). The parameters USI (User Service Information) and HLC (High Layer Compatibility) were not supplied with any values.

The parameters TMR, USI and HLC are used to indicate the desired bearer characteristics of a call. More specifically, the TMR parameter contains information about the type of the transmission medium required for the connection. The USI parameter contains the Bearer Capability information element that specifies the requested bearer service to be provided by the network. Finally, the HLC parameter, part of the ATP specifies the layer-1, layer-2 and layer-3 protocols used.

According to Q1912.5 the above parameters are closely connected with the codec list in the SDP data of the initial INVITE message.

USI parameter (Note 1) HLC parameterTMR parameter

a=lineb=linem=line

Note 3G.711 A-law“3,1 KHz audio”

“3,1 KHz audio”

rtmap: <dynamic PT> PCMA/8000

N/A or up to 64 kbit/s

Dynamic PT

RTP/AVPaudio

“Facsimile Group 2/3”

“3,1 KHz audio”

“3,1 KHz audio”

Based on T.38N/A or up to 64 kbit/s

T38udptlImage

“unrestricted digital information”

“64 kbit/sunrestricted”

rtmap:<dynamic-PT> CLEARMODE/8000 (Note 2)

AS: 64 kbit/sDynamic PT

RTP/AVPaudio

Based on T.38

rtpmap: 9G722/8000

N/A

rtpmap:,dynamic-PT> <encoding name>/<clock rate>[/<encoding parameters>]


AS: 64 kbit/s


<modifier>:<bandwidth-value>

NOTE: <bandwidth value> for <modifier> of AS is evalueated to be B kbit/s

t38

9

8

fmt-list

udptl

RTP/AVP

RTP/AVP

transport

“Facsimile Group 2/3”

“3,1 KHz audio”

“3,1 KHz audio”

image

“unrestricted digital inf. w/tones/ann”

“64 kbit/sunrestricted”

audio

Note 3G.711 A-law“3,1 KHz audio”

“3,1 KHz audio”

audio

High Layer Characteristics Identification

User Information Layer 1 Protocol Indicator

Information Transport Capability

TMR codesmedia

Note 1- In this table the codec G.711 is used only as an example. Other codec is possible.

Note2 - CLEARMODE is specified in [29] RFC4040.

Note 3 - NOTE 3 -HLC normally absent in this case. It is possible for HLC to be present with the value "Telephony", although 6.3.1/Q.939 indicates that this

would normally be accompanied by a value of "Speech" for the Information Transfer Capability element.

NOTE 4 - If the b=line indicates a bandwidth greater than 64kbit/s then the call may use compression techniques or the reject the call with a 415

response being sent back indicating one media stream of 64kbit/s only supported.

Fig. 61 Coding of TMR/USI/HLC from SDP


FN41028EN52GLA1


In general, if <media> of the “m=” line is “audio”, then <transport>, <fmt-list> and the optional “b=” line should be evaluated to determine the TMR/USI value used in the outgoing signaling. The bandwidth proposed by the “b=” line should be rounded up to the nearest values of Nx64 kbit/s, where N is an integer starting from 1. If the round-up bandwidth is between 128 and 1920 kbit/s (i.e., 2 ≤ N ≤ 30), then the TMR should indicate the corresponding values (kbit/s) for unrestricted digital information. If the bandwidth proposed by the optional “b=” line is greater than 1920 kbit/s, then there is an inter-working failure.

If the round-up bandwidth for <media> equals to audio is 64 Kbps or “b=” line is absent, then the <transport> and <fmt-list> are evaluated to determine whether (a) TMR should be set to “speech” or “3.1 KHz”; and (b) User information layer 1 protocol indicator of USI parameter should be set to “G.711 μ–law” or “G.711 A-law”.

According to ETSI EN 383 001 V1.1.1, only “G.711 A-law” shall be supported therefore, if the round-up bandwidth for <media> equals to audio is 64 Kbps or “b=” line is absent the TMR value will be equal to “3.1 kHz Audio” whereas the User Information layer 1 protocol indicator of USI parameter will be set to “G.711 A-law” so as to support table 2.

The HLC parameter will only be present with the value “facsimile group 2/3” to support a facsimile group 2/3 equipment (case of image codecs), as referred in ITU-T Recommendation Q.939.

Extended tables of the values for TMR, USI and HLC derived from the respective codec value are shown below. These tables show also the codec values that are not currently supported. The implementation though will cover those cases as well, in order to support future requirements.



109

Mapping of ITU specific codec values to TMR, USI and HLC

USI PARAMETER CODEC NAME ORG. ID/ER

ITU

CODEC TYPE

TMR PARAMETER

INFORMATION TRANSPORT CAPABILITY

USER INFORMATION LAYER 1 PROTOCOL

HLC PARAMETER

No Indication 01 00 DEFAULT - - -

G.711 64 Kbit/s A-law

01 01 3.1 kHz Audio 3.1 kHz Audio G.711 A-law -

G.711 64 Kbit/s μ-law


G.711 56 Kbit/s A-law


G.711 56 Kbit/s μ-law


G.722 (SB-ADPCM)

01 05 64 Kbit/s unrestricted

Unrestricted Digital Information

- -

G.723.1 01 06 3.1 kHz Audio 3.1 kHz Audio G.711 A-law -

G.723.1 Annex A (Silence Suppression)


G.726 (ADPCM) 01 08 3.1 kHz Audio 3.1 kHz Audio G.711 A-law -

G.727 (Embedded ADPCM)


G.728 01 0A 3.1 kHz Audio 3.1 kHz Audio G.711 A-law -

G.729 (CS-ACELP)

01 0B 3.1 kHz Audio 3.1 kHz Audio G.711 A-law -

G.729 Annex B (Silence Suppression)

01 0C 3.1 kHz Audio 3.1 kHz Audio G.711 A-law -

Spare 01 0D DEFAULT - - -

Telephone Event

01 12 DEFAULT - - -

T38UDPTL 01 13 3.1 kHz Audio 3.1 kHz Audio - Facsimile Group 2/3

T38TCPTL 01 14 3.1 kHz Audio 3.1 kHz Audio - Facsimile Group 2/3


FN41028EN52GLA1


Mapping of hiE 9200 specific codec values to TMR, USI and HLC

USI PARAMETER CODEC NAME ORG. ID/ER

SIEMENS

CODEC TYPE

TMR PARAMETER

INFORMATION TRANSPORT CAPABILITY

USER INFORMATION LAYER 1 PROTOCOL

HLC PARAMETER

Spare F0 00 DEFAULT - - -

ITU-T Recommendation T.38 codec based on UDP

F0 01 3.1 kHz Audio 3.1 kHz Audio - Facsimile Group 2/3

G.711 64 Kbit/s A-law (Silence Suppression)

F0 02 3.1 kHz Audio 3.1 kHz Audio G.711 A-law -

G.711 64 Kbit/s A-law modem transparency


Unrestricted Mode CLEARMODE

F0 04 64 Kbit/s unrestricted

Unrestricted Digital Information

- -

G.711 56 Kbit/s μ -law (Silence Suppression)


G.711 56 Kbit/s A -law (Silence Suppression)


G.711 64 Kbit/s μ -law (Silence Suppression)


G.726 (Silence Suppression)


Table 1: Mapping of SIEMENS specific codec values to TMR, USI and HLC

NOTE Currently G.722, G.727 and G.728 are not supported by the PCU. G.722 is a speech codec operating at 32-64 kbit/s, G.723 at 5.3 or 6.3 kbit/s, G.727-G.726 at 16, 24, 32 and 40 kbit/s, G.728 at 16 kbit/s and G.729 at 8 kbit/s, therefore the round up value is at 64 kbit/s and the mapping is done as G.711.

The mapping of codec G.711 μ –law is performed like that of codec G.711 A-law because only A-law is supported.

The telephone event (RFC2833) represents a DTMF codec and not an audio codec, therefore no special mapping is needed this is why the default value is used.



111

7.6 Enhanced Codec Negotiation

According to RFC 3264 codec lists can be negotiated between the SDP endpoints. In the SIP scenario an intersection of the codec lists is made between UAC and UAS on A-side and B-side and in the H.248 scenario between MG and MGC on A-side and B-side. The hiE 9200 works as UAS in the SIP scenario and as MGC in the H.248 scenario. It can in principle either restrict to a list of allowed codecs (called DP) or allow arbitrary codecs.

Reasons for restriction of codecs in hiE 9200: The operator wants to restrict the use of codecs inside the hiE 9200 domain. For this purpose a codec list administrable via NetM is provided in the PCU. This list exists once per PCU and is not suitable for call individual codec selection without additional functionality.

With hiE 9200 V4.1 the support of dynamic Payload Types, handling of several asymmetrical situations due to media negotiation, new SDP parameters, handling of Voice-Band Data codecs as well as to ensure backward compatibility with older Surpass solutions and 3rd party vendors equipment is introduced.

Offers / answers are handled that may arrive either from the MG-ISUP-MCTASK or the SDP part of an incoming SIP request. This media offer/answer transport is now to be enhanced with the support of new codecs/parameters, enable "Switch on the Fly" (SOF) among the voice negotiated codecs for hiE9200 and provides support for V.152 voice-band data codecs used for fax/modem transmission. In addition hiE 9200 has to ensure backward compatibility on all interfaces (internal and external).


FN41028EN52GLA1


Comfort Noise

The Comfort Noise codec is a special type of codec. It is used by the IP endpoints to insert silence within an RTP stream by transmitting ‘Comfort Noise’ packets to indicate existence of silence. So, it’s not a voice codec and it must not be found alone within an SDP message. It always accompanies voice codecs, such as G.722, G.726 etc. For comparison, G.723 and G.729 use the ‘annexa’ and ‘annexb’ SDP codec parameters to indicate silence suppression. CN has a static Payload Type definition with value 13. Within our solution, it is going to be used for the PCMA, PCMU and G.726 codecs. So, whenever at least one of the previous-mentioned voice codecs is present within an SDP offer, the CN should be inserted by the IP endpoint and has to be fully negotiated between the IP endpoints. The PCU has to support the mapping of this codec from the internal structure to SDP and vice versa. In former times, the PCU was transmitting the proprietary ‘vad’ parameter for e.g. PCMA codec for the same reason. However, due to backward compatibility, this parameter will still be transmitted along with the CN codec.

m = audio 12344 RTP/AVP 8 18 100 13 (8) G.711 A-law, (13) Comfort Noise

a= rtpmap:8 PCMA/8000

a=fmtp:8 vad = yes

a=rtpmap:13 CN/8000

rtpmap: G.711 A-law (8000 Hz)

voice activity detection

rtpmap: Comfort Noise

V.152 support for G.711 a and μ-law (also for fax/modem)

The V.152 recommendation defines procedures for equipment that interconnect PSTN networks with IP networks to provide satisfactory, transparent delivery of modulated voice-band data (VBD) as encoded audio content over IP (data modems, facsimile terminals and text telephones). The V.152 mode has to be supported for both PCMA and PCMU with dynamic PT and be negotiated from the beginning of the call, i.e. at the initial offer/answer cycle.

When V.152 codecs have been negotiated, no modification to these codecs should be attempted. This is because, always according to V.152 specification, whenever the IP endpoints desire to switch into data mode using the V.152 codecs, this should be done autonomously by the gateways. Also after data mode ends, the IP endpoints should try autonomously to switch back to voice, if this is desired of course.

m = audio 12344 RTP/AVP 8 18 100 127 (127) dynamic payload type

a= rtpmap: 127 PCMA/8000

a=gpmd:127 vbd = yes

rtpmap: dynamic payload type

generic parameter for payload type 127 voice band data



113

G.726 AAL2 codecs

These G.726 variants are used within ATM networks by SIP clients. The difference between the G.726 AAL2 variants and the normal G.726 codecs, it is that they use different encoding of RTP packets. So, these codecs should be negotiated as the plain G.726 codecs. All other characteristics are same.

They are going to be transported as separate codecs over SIP, for all sampling frequencies 16, 24, 32 and 40 KHz. At the SDP protocol, these are transported with the addition of the ‘AAL2’ prefix at the respective G.726 codec variant..

m = audio 12344 RTP/AVP 8 127 125 13 (125) dynamic payload type

a= rtpmap: 125 AAL2-Q726-32/8000

a=fmtp:125 vad = yes

rtpmap: dynamic payload type Q.726 AAL2

fax modem traffic for payload type 125, voice activity detection

silenceSupp SDP attribute

Cisco gateways do not understand our ‘gpmd’ SDP parameter for signaling of voice-band data information for PCMA. Currently the ‘silenceSupp’ SDP attribute (defined within RFC3108), is used to interwork with Cisco gateways for the above reason. I.e. instead sending the ‘gpmd’ attribute with ‘vbd=yes’, the ‘silenceSupp:off - - - -’ parameter is sent. However this attribute is more close to standards and it will be used in baseline processing along with the ‘gpmd’ attribute to indicate that silence suppression should be set to ‘off’, when it comes to voice-band data.

m = audio 12344 RTP/AVP 8 (8) G.711 A-law,

a= SilenceSupp:off - - - - attribute Silence Suppression set to off

pmft SDP attribute

Since V.152 is going to be supported along with T.38 for fax calls, there should be a method to declare by an IP endpoint which one should be preferred for each particular call, as soon as both are finally negotiated. V.152 specification takes care of this issue by defining the pmft SDP attribute. Among the possible values of this parameter is the ‘T38’. According to V.152 specification, the default preference is set to V.152. If an IP endpoint wishes to override this and declares T.38 preference, it should include this within its SDP offer, together with the V.152 and T.38 codecs.

If this parameter does not exist within an SDP offer but it contains both V.152 and T.38 codecs, then this should be considered as a preference for V.152. If an outgoing SDP offer with V.152 and T.38 codecs contains no ‘pmft’ attribute and the SDP answer contains a ‘pmft’ set to T.38, then the T.38 preference is accepted.


FN41028EN52GLA1


Switch On the Fly

Switch On the Fly (SOF) is a procedure where the IP endpoints may switch autonomously to another voice codec contained within the negotiated codec list. However, since this functionality was not supported by hiE9200. If more than one voice codec was received within an SDP answer, the PCU reduced this codec list to one voice codec by selecting the first one received and send it within a re-INVITE. In this way, it was ensured that no SOF would be attempted by a 3rd pty gateway.

Since now hiG1200 and hiG1600 will support SOF, the PCU behavior needed also an adaptation. Whenever more than one voice codec is received within an SDP answer, the PCU transparently passes them within to the partner. The re-INVITE is not anymore.

Backward compatibility w/o SOF

All new parameters and codecs inserted, will be simply discarded, when received, by a hiE which does not support them. If however the SDP offer contains only new codecs, then the call will be released by the "old" hiE. Vice versa, no problem occurs, the call will be established using the old codecs and parameters.



115

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


FN41028EN52GLA1


7.7 Support of SIP Reason Header

Q.1912.5 requires the support of the Reason header, which is defined in RFC 3326. It provides means to transport additional (error) information in SIP messages. By rules of Q.1912.5 it is mapped to/from the ISUP Cause Indicators parameter. Therefore the ISIP:Release message was enhanced with the new parameter ISIP:Cause.

The Reason header is generated with a reason-text which contains the full definition phrase of a cause value according to Q.850. Therefore the SIPCA maps the received cause value into the corresponding text. Similar to the mapping of the calling party category, this is achieved with a new mapping class. The actual string values are read from a config-file during initialization. This allows easy project specific adaptations of the definition text. Of course the protocol-cause will also be set-up. However, that's only a number, hence the mapping is simple.

Example:

Reason: Q.850; cause=16; text=”Normal call clearing”

In order to improve debug capabilities, the Reason header, indicating the SIP status code, shall be inserted when a BYE or CANCEL is generated due to SIPCA internal reasons. The reason-text is not sent (it is optional). Additionally the Q.850 cause #127 will be generated hardcoded, as all the status codes, which are set-up by SIPCA, are mapped to #127.

Example:

Reason: SIP; cause=500

Reason: Q.850; cause=127; text="interworking, unspecified"

On receipt of the Reason header, the SIP status codes are always ignored. The Q.850 causes are mapped according Q.1912.5.

If an ISIP:Release message containing an ISIP:Cause parameter is received by the SIPCA, it is mapped into the Reason header in the corresponding message (BYE, CANCEL or negative final response).

If a BYE, CANCEL or final response >= 400 is received which is mapped into an ISIP:Release message and which contains a Reason header with Q.850 cause, then the Q.850 cause is mapped into the ISIP:Cause parameter. The location is always set to “network beyond interworking point”.

If a BYE or CANCEL is received which does not contain a Reason header with a Q.850 cause, then the ISIP:Cause parameter is generated with the default value 16 “Normal call clearing” (for BYE) respectively 31 “Normal, unspecified” (for CANCEL).



117

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Session Initiation ProtocolRequest-Line: BYE sip:[email protected]:5060;transport=udp SIP/2.0

Method: BYEResent Packet: False

Message HeaderVia: SIP/2.0/UDP

10.12.50.21:5090;branch=z9hG4bK1e78ad11ac95cb1dc7cd8fbbcc6961d001;lskpmc=S04Record-Route:

<sip:[email protected]:5090;routing_id=bd59d92aa74fd8355b3aa3b1213b385e;lskpmc=S04;lr;interface=bcc;tid=1e78ad11ac95cb1dc7cd8fbbcc6961d001>

Via: SIP/2.0/UDP 192.168.12.21:5060;branch=z9hG4bK01183580620000157347.From: <sip:[email protected];user=phone>;tag=44d6d3f6-63a21-c0a80c15

SIP from address: sip:[email protected] tag: 44d6d3f6-63a21-c0a80c15

To: <sip:[email protected]>;tag=1154929771-3227971155252568-11SIP to address: sip:[email protected] tag: 1154929771-3227971155252568-11

Call-ID: 1779294511-6952237632525511-11-2877511382CSeq: 1 BYEMax-Forwards: 69Reason: Q.850;cause=16;text="Normal call clearing"Content-Length: 0P-com.Siemens.Corr-ID: 1e78ad11ac95cb1dc7cd8fbbcc6961d001,1779294511-

6952237632525511-11-2877511382

Fig. 62 SIP:BYE message with reason header


FN41028EN52GLA1




119

7.8 Bearer Redirection Procedures

The bearer redirect procedures are used to support 3-party-conference-calls, call forwarding, announcement sequencing, IN call scenarios, etc. In hiE 9200 bearer redirect after answer using SIP re-INVITE has already been shown.

7.8.1 Bearer Redirection Procedures before Answer

In many Call Forwarding scenarios and Call Transfer scenarios the Bearer Data of a Call are changed before the call is answered. On SIP side this is done by using the UPDATE method according to RFC3311. On BICC side BICC:Bearer Redirect Requests (with or without IP data) are used.

If the SIPCA received a SIP:INVITE message and it already sent a provisional response with the SDP Answer, it has to send an UPDATE message to the SIP side if it received new IP data from the BICC side.

This SIP:UPDATE message can only be sent, if

• the SIP side supports the UPDATE method and

• the SIP side supports reliable provisional responses (PRACK)!

According to RFC3311, a new SDP offer may only be sent if the SDP answer in a provisional response is acknowledged with a PRACK message. If there was no PRACK received, it is not assured that the SDP answer reached the SIP side and so no new SDP offer can be sent.

If a new IP Offer is issued to one side, the IP Answer of that side may also contain new IP data. This IP data are transferred to the other side, which may again change it. This may lead to an endless loop and therefore the SIPCA has to be able to do a “cross check” of the received IP data to decide if a new Bearer Redirect Cycle has to be initiated or the Call has to be released.

The SIPCA supports the following Bearer Redirection cases:

1. The SIPCA is able to receive and process a BICC:BRR without IP data before the Call has been answered.

2. The SIPCA is able to receive and process a BICC:BRR with IP data before the Call has been answered.

3. The SIPCA is able to receive and process a SIP:UPDATE message with new IP data from the SIP side before the Call has been answered.


FN41028EN52GLA1


Bearer Redirect for Call Forwarding on No Reply (CFNR)

A call flow illustrating the SIP-NNI procedures is given hereafter. The CFNR is performed in MGC_B. Flows via the UNI interface, e.g. MGCP/H.248, are not shown in the figure.

The figure shows an incoming SIPCA receiving a BICC BRR (before answer) without IP data. The SIPCA replies the BICC:BRR with the stored IP data from the SIP side that were received in the SIP:INVITE message. The BICC side replies with the IP data of the new (redirected) C-party. This IP answer from the BICC side triggers an UPDATE message to the SIP side. The SIP side answers with 200_OK message to the UPDATE, which contains the SIP side IP data.

Normally this IP data of the SIP side should be the same IP data (Connection address, RTP Port and Codec(s)) for all Media Streams, which were received by the SIPCA in the SIP:INVITE message.

However, it may happen, that the SIP side sends different IP data in the 200_OK (Update).

The SIPCA has to do a “Crosscheck” on the SIP SDP answer. In this flow it detects that the SDP answer is different from the stored SDP (last received in the SIP:INVITE message). Therefore the SIPCA now sends itself a Bearer Redirection Request to the BICC side, which contains the changed IP data from the SIP side. The BICC side answers the BRR request with the IP data of the new (redirected) C-party.

Again, it may happen that the IP data received by the SIPCA (this time the BICC IP answer) are different from the BICC IP data received in the last Bearer Redirection answer. To prevent an endless loop, the SIPCA has to release the call.

The following has to be mentioned regarding the codec:

For all Media Streams, a SIP:UPDATE message triggered by an IP answer from the BICC side must always contain only one codec, namely the selected codec of the BICC side (to avoid a BRR to the BICC side if the SIP Connection Address and RTP-Port have not changed but the Codec changed). Therefore, also the 200_OK (UPDATE) from the SIP side must also contain that codec as first (preferred) payload type. According to RFC3264, section 6.1, the SDP answer may also contain other codecs not listed in the SDP offer. Therefore we must foresee a SIP:UPDATE for a single codec if a SIP:200_OK( UPDATE) message contains more than one codec for one of the Media Streams. If a BICC:BRR is triggered by this SIP:200_OK(UPDATE), it should only contain this single codec to make it impossible for the BICC side to send a different codec back!



121

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MGC_BMGC_A MGC_C

No reply

INVITE(sdp a)

180_Ringing(sdp b)

PRACK

200_OK(PRACK)

UPDATE(sdp c)

200_OK(UPDATE,sdp a')

INVITE(sdp a)

180_Ringing(sdp c)

PRACK

200_OK(PRACK)

UPDATE(sdp a')

200_OK(UPDATE,sdp c)

Fig. 63 CFNR using SIP UPDATE, new SDP received in UPDATE from MGC_A


FN41028EN52GLA1


7.8.2 Call Hold/Call Retrieve before Answer

In Q.1912.5, Annex B.10, it is mentioned, that the UPDATE method should be used for Call Hold/Call Retrieve before answer.

The SIPCA does the following:

• The SIPCA is able to receive a SIP:UPDATE message for Call Hold before answer, which contains a SDP session with either the Connection Address “0.0.0.0” (RFC2543 compatible) or the Stream Mode “sendonly” (RFC3264 compatible) for ALL Media Streams. If one ore more of the Media Streams are not on Hold, the call is NOT on Hold and the SIPCA recognizes the Bearer Redirect Feature for transparency reasons in case of SIP-SIP Inter-working! The SIP:UPDATE message is mapped into an ISIP:SUSPEND message (see figure) with BICC Action Indicator “Remote Hold”. The ISIP answer (ISIP:Facility with BICC Action Indicator “Remote Hold Ack”) is mapped into the SIP:200_OK( UPDATE) message (with stream-mode “recvonly” for ALL Media Streams).

• If a Call is on Hold, the SIPCA is able to receive a SIP:UPDATE message for Call Retrieve before answer, which contains a SDP Session with the Streammode “sendrecv” (or no Streammode; “sendrecv” is default) for ALL Media Streams. Otherwise the SIPCA will recognize the Bearer Redirect Feature (see above). The SIP:UPDATE message has to be mapped into an ISIP:RESUME message (see figure) with BICC Action Indicator “Remote Retrieve”. The ISIP answer (ISIP:Facility with BICC Action Indicator “Remote Retrieve Ack”) has to be mapped into a SIP: 200_OK(UPDATE) message (with Streammode “sendrecv” for ALL Media Streams).



123

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

msc HoRe01

SIPCA_I

180_Ringing(SDP B)

INVITE(SDP A)

UPDATE(SDP A,sendonly or ConnAddr 0.0.0.0)

200_Ok(SDP B,recvonly)


BAT_ASE(AI = ConnFw+No+SCod,IP Data B)

SUSPEND(AI = Remote Hold)

BAT_ASE(AI = Remote Hold Ack)

UPDATE(SDP A,sendrecv) RESUME(AI = Remote Retrieve)

BAT_ASE(AI = Remote Retrieve Ack) 200_Ok(SDP B,sendrecv)


PRACK

200_Ok(PRACK)

Fig. 64 Call Hold/Retrieve from SIP side before answer


FN41028EN52GLA1


• The next figure shows a SIPCA receiving an ISIP:SUSPEND message for Call Hold before answer. This message is mapped into a SIP:UPDATE message that contains a SDP Session with the Stream Mode “sendonly” AND the Connection Address “0.0.0.0” for ALL Media Streams. The Connection Address “0.0.0.0” is for compatibility with RFC2543, because unfortunately there are SIP Clients which support only the "old" SIP Standard. The "new" SIP Standard "RFC3261" references RFC3264, which uses the Stream Mode "sendonly" to put a call on Hold. The SDP answer in the SIP:200_OK(UPDATE) message must contain the Streammode “recvonly” (or "inactive”) for all Media Streams if the SIP side supports RFC3264. It is mapped into an ISIP:Facility message with BICC Action Indicator “Remote Hold Ack” if the ISIP:SUSPEND message contained a BICC part, or into an ISIP:Facility message with BICC Action Indicator “Remote Hold”, if the ISIP:SUSPEND message didn’t contain a BICC part (this message is here in fact used as “Local Hold” indication, because the BICC side CA was not informed about the SUSPEND, which came directly from the PSTN).

• If a Call is on Hold, the SIPCA is able to receive an ISIP:RESUME message for Call Retrieve before answer, which is mapped into a SIP:UPDATE message that contains a SDP Session with the Stream Mode “sendrecv” for ALL Media Streams (see figure). The SDP answer in the SIP:200_OK(UPDATE) message may contain any Streammode (or no Stream Mode; “sendrecv” is default) for the Media Streams. The SDP answer is mapped into an ISIP:Facility message with BICC Action Indicator “Remote Retrieve Ack” if the ISIP:RESUME message contained a BICC part or into an ISIP:Facility with BICC Action Indicator “Remote Retrieve” if the ISIP:RESUME message didn’t contain a BICC part (“Local Retrieve” indication; see above). The Streammode in the SDP answer is ignored by SIPCA. It's evaluation and mapping to BICC is an open point.



125

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

msc HoRe02

SIPCA_O

180_Ringing(SDP B)

INVITE(SDP A)

UPDATE(SDP A,sendonly and ConnAddr 0.0.0.0)

200_Ok(SDP B,recvonly)



SUSPEND

BAT_ASE(AI = Remote Hold Ack)

UPDATE(SDP A,sendrecv) RESUME

BAT_ASE(AI = Remote Retrieve Ack) 200_Ok(SDP B,sendrecv)


PRACK

200_Ok(PRACK)

Fig. 65 Call Hold/Retrieve from ISIP side before answer


FN41028EN52GLA1


7.8.3 SIP:PRACK with SDP offer

As described in RFC3262, the incoming SIP CA may receive a PRACK carrying a SDP offer. (This can only occur in case the reliable provisional response sent by the incoming SIPCA did carry a SDP answer). It is not the intention to send such SDP offer in a PRACK issued by hiE 9200 itself. As for the UPDATE with a SDP offer the SIPCA maps this to ISIP:Facility(BearerRedirect) with IP data (respectively ISIP:SUSPEND/RESUME) and does not issue a 200 OK to the PRACK immediately, but awaits the response from the B-side. Because the response from the BICC side may take a while, the SIPCA will send a provisional response 100_TRYING.

On receipt of the ISIP:Facility(BearerRedirect with BRI=connected) the SIPCA issues the 200 OK with the SDP answer as received on the BICC internal interface, and completes the BICC internal bearer redirection flows. There is no need to store and/or cross check the SDP contents for this received SDP offer/answer cycle as the origination side sending the SDP offer with the PRACK need to take over responsibility. The call flow of the described procedure is depicted in the next figure.

msc Prack01

SIPCA_I

180_Ringing(SDP B)

INVITE(SDP A)

PRACK(SDP A')

200_Ok(PRACK,SDP B)



BAT_ASE(AI = Bearer Redirect, BRI = RdFwReq, RdBRComp, IP Data A')

BAT_ASE(AI = Bearer Redirect, BRI = RdBrConnected,IP Data B)


Fig. 66 PRACK with SDP Offer



127

7.9 Call Completion Supplementary Services (CCSS)

Completion of Calls to Busy Subscribers (CCBS) enables a calling user A, upon encountering a busy destination B, to be notified when the busy destination B becomes free and to have the service provider reinitiate the call to the specified destination B if user A desires.

The CCNR supplementary service enables user A, encountering a destination B which does not answer the call (No Reply), to have the call completed without having to make a new call attempt when the destination becomes not busy after having initiated an activity.

These features are already available in PSTN networks, providing this functionality for ISDN and analog subscribers. With the new implementation the Call Completion Supplementary Services (CCSS) is also applied in inter-working scenarios between PSTN and SIP networks.

msc flow1-1

hiQ4200 hiQ9200 PSTNSIP LTGSub endpt A

Offhook+digits

SIP:INVITE

SIP:100 TRYING

SIP:INVITE

SIP:100 TRYING

ISIP:FwSetup

ISUP:IAM

ISIP:RELEASE (Cause=User Busy, CCBS Possible=Yes

ISUP:REL(Cause=User Busy,CCBS Possible=Yes)

SIP:486(Allow-Events:CCBS)

SIP:486(No Allow-Events Header)

SIP:ACK

SIP:ACK

SIP:100 TRYING

SIP:INVITE(CCBS Act VSC)

Offhook+CCBS Act VSC

offhook

Initial Condition:CCBS subscriber

is idle

Subscriber A attempsto call Sub B.

Sub B is busy andSub A activates CCBS feature.

Final Condition:CCBS activationrequest received

via a call

Detect thatthe user is

busy

User receiveslocal user

busy indication

Store called number in outgoing memory

slot. Insert timestampin otg mem slot

Fig. 67 Call flow NGN Sub CCBS activation Request


FN41028EN52GLA1


msc flow2-1

SIPIWP/BIG PSTNSUB endptA hiQ4200 SIPCA

SIP:NOTIFY(Event:CCBS,queue=request-queued,Subscription-State=Active,Service R

TSIP:NOTIFY(DialogID,Event:CCBS,queue=request-queuedSubscription-State=Active

TSIP:SUBSCRIBE(TSIP:ClgNo,TSIP:CldNo,Event:CCBS,DialogID,queue=true,Expire

SIP:SUBSCRIBE(Event:CCBS, queue=true,caller=calling DN, Expires=max duration,S

TC_CONT:CCBS request (result)

TC_BEGIN:CCBS Request (invoke)

SIP:202 ACCEPTED(Expires =max duration)

SIP:200OK

SIP:200OK

SIP:ACK

validation of request passes

Start CCBS T2 timer

Cancel CCBS T2Start CCBS T3

Media server plays CCBS activation confirmation.

User hears CCBS activation confirmation

Start CCBS T7

Final Condition:NGN CCBS

subscriber receives CCBS activation

confirmation

Initial Condition:CCBS activation

request via

Fig. 68 Call flow NGN Sub CCBS activation



129

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

msc flow3-1

PSTNSub endpt A hiQ4200 SIPCA SIPIWP/BIG

TSIP:NOTIFY(DialogID,Event:CCBS,queue=user-free,Subscription-State=Active,TCB

SIP:NOTIFY(Event:CCBS,queue=user-free,Subscription-State=Active)

TC_CONT:REMOTE USER FREE

SIP:200OK

SIP:100 TRYING

SIP:INVITE(no SDP)

CCBS T8 expires

Deny termination to this sub. Start CCBS T9 timer.

Final Condition:NGN CCBS subscriber

alerted

Initial Condition:NGN CCBS subscriber

is idle and monitoredsubscriber become

idle

Start CCBS T4 timer

Fig. 69 Call flow NGN Sub Recall: Alerting of NGN CCBS sub.


FN41028EN52GLA1


msc flow3-2

hiQ4200 SIPCA PSTNSIPIWP/BIGSub endpt A

offhook

SIP:200OK (SDP data of CCBS sub)

SIP:INVITE(SDP data of CCBS sub,Call-Info:<caller URI>;purpose=CCS Call)

SIP:100 TRYING

ISIP:FwSetup(CCS Call)

ISIP:Facility(AI=ConnFw+No+SCod)

ISIP:Facility(AI=Connected)

ISIP:BwSetup(180)

SIP:180 RINGING (with SDP)

SIP:ACK (with SDP)

TSIP:NOTIFY(DialogID,Event:CCBS,Result=End,TCBAddress<>0,Reason=CCS ComSIP:NOTIFY(Event:CCBS,Subscription-

State=Terminated,Reason=CCS Completed)

SIP:200OK

ISUP:IAM(CCS Call)

ISUP:ACM

TC_END

Cancel CCBS T4 timer

Release CCBS request/subscriptionRemove the CCBS requestfrom this subscriber's queue

Alert user

Cancel CCBS T9CCBS T7 timers.

Release the resourcesof this CCBS request.

Initial Condition:

NGN CCBS subscriber

alerted

Final Condition:NGN CCBS subscriber connected to monitored

Fig. 70 Call flow NGN Sub Recall: NGN CCBS subscriber connected to monitored



131

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


FN41028EN52GLA1


7.10 Fixed Mobile Convergence Call Flows

The FMC 2.0 solution provides the inter-working between IMS (IP multimedia subsystem) and PSTN/CS networks. In all scenarios, hiE 9200 as MGCF acts as SIP User Agent. SIP signaling is always routed via the CSCF, but not directly between the MGCF and the IMS Application Server (e.g. the hiQ 4200 – as done in Business Connection Solution). IMS bearer traffic (VoIP in this case) is exchanged directly between the MGW and the UE (e.g. the OptiClient or the OptiPoint SIP Phone) without traversing the CSCF. The standard SIP capability negotiation is performed during the session setup. In this procedure, SDP information is exchanged to negotiate/exchange the session details such as codec- and address information. In the following, both inter-working scenarios are described in more detail.

7.10.1 PSTN/CS domain originated call to the IMS

An example for this scenario is a PSTN user that makes a voice call to an IMS subscriber using an SIP Phone via a Fixed (xDSL) Network access. The next figure illustrates the corresponding session setup in the IMS.

When the hiE 9200 MGCF receives the ISUP IAM message, the MGCF communicates with the hiG 1200 MGW that is responsible for the trunk to reserve an IP address and port number. Afterwards, the I-CSCF of the IMS is selected. The MGCF initiates the IMS session setup by sending a SIP Invite message to the I-CSCF. The SDP includes the address information (IP address and port number).

When receiving the SIP Invite, the I-CSCF queries the HSS for the called party using the R-URI as key. This query is done via the Cx-interface. The serving S-CSCF address is returned by the HSS when the subscriber is registered. This is the case in the example show in the figure. Otherwise, the indication to route to a default S-CSCF or an error is returned. The I-CSCF converts the SIP-URI to a TEL-URI and forwards the SIP Invite request to a terminating S-CSCF and from there via the P-CSCF to the B-Party (UE-B). A SIP 180 Ringing message is sent afterwards by the IMS Client to signal that the phone is ringing. If the call is successful (the user picks up the handset of the phone), the IMS Client returns a SIP 200 OK message with an SDP that includes the address information (IP address and port number) of the client.

When the MGCF receives the 200 OK, it passes the address information of the client to the MGW to enable a direct IMS bearer connection between the MGW and the IMS Client of the called B-Party.

An IMS Application Server is invoked by the S-CSCF of the B-Party in order to execute Terminating Supplementary Services (e.g. Call-Forwarding) for the B-Party. In the case that the B-Party is not registered in the IMS, the terminating call is forwarded by the I-CSCF to a Default S-CSCF. The Default-S-CSCF could e.g. trigger an Application Server (assuming that the B-Party has the appropriate Filter Criteria in his IMS User Profile), which could forward the call to a Mailbox or perform another subscriber specific call handling.



133

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CS-Domain/PSTN Originated Call Setup to an IMS User

2. 180 Ringing

1a. Invite

IAM

4. ACK

1b. Invite

3. 200 OKACM

ANM

Cx

1c. Invite

1f. Invite

1d. Invite

1e. Invite

CS/PSTN I-CSCFMGCF UE-BAccessP-CSCFHSS Voice-ASS-CSCF

IMS Registration

Fig. 71 CS-Domain/PSTN Originated Call Setup to an IMS User


FN41028EN52GLA1


7.10.2 IMS originated call to the PSTN/CS domain

An example for this scenario is an IMS user that uses his OptiPoint SIP Phone to make a voice call to a CS-Domain/PSTN user. In the case that the B-Party is a CS-Domain user that also has an IMS subscription, the E.164 number used in the CS-Domain needs to be different to the E.164 number used in the IMS.

The message flow starts with a SIP invite request sent by the UE-A after the user entered the destination number on hisSIP Phone. This SIP Invite request is sent to the P-CSCF and is forwarded from there to the S-CSCF of the A-Party. In this example, the called user is identified by a SIP-URI including an E.164 number (e.g. a SIP-URI of the format sip:<E.164>@<domainname>). In the case that the S-CSCF is responsible for the domainname in the SIP-URI, the S-CSCF re-formats the E.164 number (e.g. when the number is not already in international format), and tries to resolve the number via DNS/ENUM into a SIP-URI (according to [RFC3761]). The same DNS/ENUM query is performed by the S-CSCF when a TEL-URI is used for the addressing of the B-Party. Since the called B-Party is a PSTN user, the E.164 number cannot be resolved into a SIP-URI (because PSTN users do not have the required entry in the DNS/ENUM server). The S-CSCF thus passes the SIP-Invite request to the BGCF (co-located in IMS 4.0) for the Breakout to the PSTN/CS-Domain. The BGCF selects an MGCF according an administrable database (Number Plan). Afterwards, the call is routed to the MGCF.

Upon receipt of the SIP Invite, the MGCF selects a MGW that reserves an IP address and port number for the voice bearer. It further sends an ISUP IAM message towards the PSTN. After receiving an ISUP ACM message from the PSTN, a SIP 180 Ringing is sent towards the UE-A. The ISUP ANM message from the PSTN triggers a SIP 200 OK.

It remains to remark that when the DNS/ENUM query from the S-CSCF to the I-CSCF is successful (the E.164 number is resolved into a SIP-URI), then the SIP Invite request is routed from the S-CSCF to the terminating IMS (I-CSCF) according to the standard procedures.

As shown in the figure, an IMS Application Server is invoked by the S-CSCF of the A-Party to execute for example Supplementary Services for the A-Party. The executed supplementary service may however also force the breakout to the PSTN/CS-Domain (e.g. a Call Forwarding to the PSTN).



135

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1a. Invite

2. Ringing

1b. Invite

IAM

3. 200 OK

4. ACK

ACM

ANM

ENUM

IMS Registration

UE-A Access P-CSCF ENUM MGCF CS/PSTNS-CSCF/

BGCF Voice-AS

1c. Invite

1d. Invite

IMS Session Setup for the IMS Originating Breakout to the CS-Domain/PSTN

Fig. 72 IMS Session Setup for the IMS Originating Breakout to the CS-Domain/PSTN (e.g., an IMS user makes a voice call to PSTN user)


FN41028EN52GLA1


7.11 Call flows SIP-I

MGC_I

Path established in both directions

IAM

INVITE

IAM(cot_on_prev_circuit)

100_Trying

ACM(no_indication)183_Session_Progress

ACM(no_indication)

CPG(alerting)

180_Ringing

CPG(alerting)

ANM

200_OK

ANM

ACK

PRACK

200_OK

PRACK

200_OK

COT(successful)

MGC_EPSTN_I PSTN_E

Fig. 73 SIP-I - Call setup



137

8 Exercises


FN41028EN52GLA1




139

Exercise 1

Title: BC/CV: SIP user registration at hiQ 4200

Objectives: The participant is able to analyze a SIP trace

Pre-requisite: Wireshark SW, File: FN4102_sip_ex1a.pcap and FN4102_sip_ex1b.pcap

Task

Try to answer the following questions with the help of the trace file:

1. Who tries to register? _______________________________________________

2. Is the first registration successful? _____________________________________

3. Which parameters are additional in the second Register message? ___________________________________________________________________

4. After which interval is the Registration repeated? __________________________

5. Why is the registration not successful in file 1b? __________________________


FN41028EN52GLA1


No. Time Source Destination Protocol Info 1 0.000000 192.168.9.151 192.168.20.102 SIP Request: REGISTER sip:192.168.20.102:5060 Frame 1 (476 bytes on wire, 476 bytes captured) Arrival Time: Apr 12, 2006 11:22:09.686737000 Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Frame Number: 1 Packet Length: 476 bytes Capture Length: 476 bytes Protocols in frame: eth:ip:udp:sip Ethernet II, Src: Vmware_51:9d:e4 (00:0c:29:51:9d:e4), Dst: Intel_0b:ac:8b (00:07:e9:0b:ac:8b) Internet Protocol, Src: 192.168.9.151 (192.168.9.151), Dst: 192.168.20.102 (192.168.20.102) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Session Initiation Protocol Request-Line: REGISTER sip:192.168.20.102:5060 SIP/2.0 Method: REGISTER Resent Packet: False Message Header Max-Forwards: 70 Content-Length: 0 Via: SIP/2.0/UDP 192.168.9.151:5060;branch=z9hG4bK9f9f3edfa Call-ID: 4207b4e7947a1b1 From: Mike <sip:[email protected]:5060>;tag=7b09c96dc68b53b;epid=SC519df8 SIP Display info: Mike SIP from address: sip:[email protected]:5060 SIP tag: 7b09c96dc68b53b To: Mike <sip:[email protected]:5060> SIP Display info: Mike SIP to address: sip:[email protected]:5060 CSeq: 1 REGISTER Contact: Mike <sip:[email protected]:5060;transport=udp>;audio;video;text Contact Binding: Mike <sip:[email protected]:5060;transport=udp>;audio;video;text URI: Mike <sip:[email protected]:5060;transport=udp> SIP Display info: Mike SIP contact address: sip:[email protected]:5060 User-Agent: optiClient S 130 V3/3.0.0.23



141

Exercise 2

Title: SIP-NNI (hiQ 4200) to PSTN Call Setup and Release (no CLIR)


Pre-requisite: Wireshark SW, File: FN4102_sip_ex2.pcap

Task


1. What is the A-Sub. # _________________________________________________

2. What is the B-Sub. # _________________________________________________

3. Is the INVITE sent over UDP? _________________________________________

4. Which codecs are offered to the B-side? _________________________________

5. Which codec is finally used? __________________________________________

6. Which E1 # is seized on the hiG? _______________________________________

7. Who releases the call? _______________________________________________

8. Use the Statistics/VoIP call option to see the call as graph! __________________


FN41028EN52GLA1


No. Time Source Destination Protocol Info 154 29.332200 192.168.20.102 192.168.10.81 SIP/SDP Request: INVITE sip:[email protected]:5060, with session description Frame 154 (965 bytes on wire, 965 bytes captured) Arrival Time: Apr 12, 2006 10:19:06.004063000 Time delta from previous packet: 1.758216000 seconds Time since reference or first frame: 29.332200000 seconds Frame Number: 154 Packet Length: 965 bytes Capture Length: 965 bytes Protocols in frame: eth:ip:udp:sip:sdp Ethernet II, Src: 192.168.10.253 (00:e0:18:38:bf:33), Dst: 192.168.10.81 (00:03:ba:dc:4d:0f) Internet Protocol, Src: 192.168.20.102 (192.168.20.102), Dst: 192.168.10.81 (192.168.10.81) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Session Initiation Protocol Request-Line: INVITE sip:[email protected]:5060 SIP/2.0 Method: INVITE Resent Packet: False Message Header From: PRIVATE <sip:[email protected]>;tag=1144829926-8395761145669502-11 SIP Display info: PRIVATE SIP from address: sip:[email protected] SIP tag: 1144829926-8395761145669502-11 To: <sip:[email protected];user=phone> SIP to address: sip:[email protected] Via: SIP/2.0/UDP 192.168.20.102:5060;branch=z9hG4bKSNCLLC1145669518 CSeq: 162 INVITE Contact: <sip:[email protected]:5060;transport=udp;maddr=192.168.20.102> Contact Binding: <sip:[email protected]:5060;transport=udp;maddr=192.168.20.102> URI: <sip:[email protected]:5060;transport=udp;maddr=192.168.20.102> SIP contact address: sip:[email protected]:5060 Call-ID: 6299284411-9029385319665411-11-0877511382 P-Asserted-Identity: PRIVATE <sip:[email protected]> Max-Forwards: 70 Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER Accept-Language: en; q=0.0 Content-Type: application/sdp Content-Length: 305



143

Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): MxSIP 0 190694538 IN IP4 192.168.9.151 Owner Username: MxSIP Session ID: 0 Session Version: 190694538 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.9.151 Session Name (s): SIP Call Connection Information (c): IN IP4 192.168.9.151 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.9.151 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 29116 RTP/AVP 0 8 18 101 Media Type: audio Media Port: 29116 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Media Format: ITU-T G.729 Media Format: 101 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 8 PCMA/8000 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 18 G729/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute Fieldname: fmtp Media Attribute Value: 101 0-15 Media Description, name and address (m): video 29118 RTP/AVP 34 Media Type: video Media Port: 29118 Media Proto: RTP/AVP Media Format: ITU-T H.263 Media Attribute (a): rtpmap:34 H263/90000 Media Attribute Fieldname: rtpmap Media Attribute Value: 34 H263/90000 Media Attribute (a): recvonly


FN41028EN52GLA1




145

Exercise 3

Title: SIP-NNI (hiQ 4200) to PSTN Call Setup and Release (CLIR)



Task


1. What is the A-Sub. # _________________________________________________

2. What is the B-Sub. # _________________________________________________

3. What is the function of the header " P-Asserted-Identity"?____________________


FN41028EN52GLA1


No. Time Source Destination Protocol Info 54 10.427867 192.168.20.102 192.168.10.81 SIP/SDP Request: INVITE sip:[email protected]:5060, with session description Frame 54 (983 bytes on wire, 983 bytes captured) Arrival Time: Apr 12, 2006 10:22:36.162770000 Ethernet II, Src: 192.168.10.253 (00:e0:18:38:bf:33), Dst: 192.168.10.81 (00:03:ba:dc:4d:0f) Internet Protocol, Src: 192.168.20.102 (192.168.20.102), Dst: 192.168.10.81 (192.168.10.81) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Session Initiation Protocol Request-Line: INVITE sip:[email protected]:5060 SIP/2.0 Method: INVITE Resent Packet: False Message Header From: Anonymous <sip:[email protected]>;tag=1144830136-9903191145820455-11 SIP Display info: Anonymous SIP from address: sip:[email protected] SIP tag: 1144830136-9903191145820455-11 To: <sip:[email protected];user=phone> SIP to address: sip:[email protected] Via: SIP/2.0/UDP 192.168.20.102:5060;branch=z9hG4bKSNCLLC1145820471 CSeq: 163 INVITE Privacy: id Contact: <sip:[email protected]:5060;transport=udp;maddr=192.168.20.102> Contact Binding: <sip:[email protected]:5060;transport=udp;maddr=192.168.20.102> URI: <sip:[email protected]:5060;transport=udp;maddr=192.168.20.102> SIP contact address: sip:[email protected]:5060 Call-ID: 6310384411-0299896500285411-11-0877511382 P-Asserted-Identity: Unavailable <sip:[email protected]> Max-Forwards: 70 Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER Accept-Language: en; q=0.0 Content-Type: application/sdp Content-Length: 305 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): MxSIP 0 744558676 IN IP4 192.168.9.151 Owner Username: MxSIP



147

Session ID: 0 Session Version: 744558676 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.9.151 Session Name (s): SIP Call Connection Information (c): IN IP4 192.168.9.151 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.9.151 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 29120 RTP/AVP 0 8 18 101 Media Type: audio Media Port: 29120 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Media Format: ITU-T G.729 Media Format: 101 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 8 PCMA/8000 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 18 G729/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute Fieldname: fmtp Media Attribute Value: 101 0-15 Media Description, name and address (m): video 29122 RTP/AVP 34 Media Type: video Media Port: 29122 Media Proto: RTP/AVP Media Format: ITU-T H.263 Media Attribute (a): rtpmap:34 H263/90000 Media Attribute Fieldname: rtpmap Media Attribute Value: 34 H263/90000 Media Attribute (a): recvonly


FN41028EN52GLA1




149

Exercise 4

Title: PSTN to SIP-NNI (hiQ 4200) Call Setup and Release



Task



2. What is the A-Sub. # _________________________________________________

3. What is the B-Sub. # _________________________________________________

4. Is the INVITE in frame 6 sent over UDP? _______________________________


6. Why is the Modify in frame 18 sent to the hiG? ____________________________

7. Why is a second INVITE sent in frame 38? _______________________________





FN41028EN52GLA1




151

Exercise 5

Title: FMC user registration at CSCF/hiQ 4200



Task


1. Which SIP-user tries to register? _______________________________________

2. Is the first REGISTER message successful? _____________________________

3. Why is an additional REGISTER sent in frame 9? _________________________

4. Why is an additional REGISTER sent in frame12? _________________________

5. Where does the additional information in frame 12 come from? _______________


FN41028EN52GLA1




153

Exercise 6

Title: FMC Breakout Call Setup

Objectives: The participant is able to analyze a SIP/DNS trace

Pre-requisite: Wireshark SW, File: FN4102_sip_ex6a.pcap

a) "PCU view"

b) "hiQ 4200 view"

c) "CSCF view"

Task



2. What is the A-Sub. # _________________________________________________

3. What is the B-Sub. # _________________________________________________

4. Which codecs are offered from the A-side? _______________________________



7. What is the payload IP# and port of the A-Sub.? ___________________________

8. What is the payload IP# and port of the B-side? __________________________



FN41028EN52GLA1




155

Exercise 7

Title: FMC Break-in Call Setup

Objectives: The participant is able to analyze a SIP/DNS trace


a) "PCU view"

b) "hiQ 4200 view"

c) "CSCF view"

Task



2. What is the A-Sub. # _________________________________________________

3. What is the B-Sub. # _________________________________________________


5. What is the payload IP# and port of the A-Sub.? ___________________________

6. What is the payload IP# and port of the B-side? __________________________





FN41028EN52GLA1




157

Exercise 8

Title: SIP-I Call Setup



Task


1. What is the A-Sub. # _________________________________________________

2. What is the B-Sub. # _________________________________________________

3. Fill out the following table:

Frame # SIP-msg contained ISUP msg

1

4

12

16

4. Can you find the CIC and DPC in the encapsulated ISUP? ___________________


FN41028EN52GLA1




159

Exercise 9

Title: SIP Forking



Task


1. How often is the subscriber "Kirk" registered? _____________________________

2. Under which IP#s of user agents is "Kirk" registered? _______________________

3. How many SIP:INVITE are sent from the SIP proxy?________________________

4. What tags are linked to which user agent?________________________________

5. What IP# has the user agent, which accepts the call?_______________________

6. How is ringing stopped on the other user agent? ___________________________

7. Frame 232 contains an SIP:INVITE. Which branch ID is used?________________

8. Which other frames belong to the transaction of frame 232? __________________


FN41028EN52GLA1




161

Exercise 10

Title: SIP Register and De-register with eyebeam client SW



Task


1. The first registrations of the user agent fail. Why? __________________________

2. After which time will the user agent register again? _________________________

3. How does the eyebeam SW handle de-registrations? _______________________


FN41028EN52GLA1




163

Exercise 11

Title: SIP Loop



Task


1. Why is the call failing? _______________________________________________

2. How can the SIP servers detect such problems? ___________________________


FN41028EN52GLA1




165

Exercise 12

Title: SIP Services



Task

Try to answer the following questions with the help of the trace files:

a) Call Hold

FN4102_sip_ex12a.pcap

1. With which frame puts the user agent the call on hold? ______________________

2. Which session attribute is used to do so? ________________________________

b) Consultation Hold

FN4102_sip_ex12b.pcap

1. Draw a schematic call flow based on the trace!

2. Compare your drawing with the example in the course folder!

c) Call Transfer

FN4102_sip_ex12c.pcap

1. Draw a schematic call flow based on the trace! Who is A, B and C subscriber?

___________________________________________________________________

2. Which SIP method is used to transfer the call ? ___________________________

3. Compare your drawing with the example in the course folder!

Which Messages are not implemented?

____________________________________________________


FN41028EN52GLA1


d) Call Forwarding

FN4102_sip_ex12d.pcap

1. Which user is invited by the first message? _______________________________

2. To whom is the second INVITE sent? ___________________________________

3. What number will be shown to the PSTN subscriber?______ _________________

e) 3-Party conference

FN4102_sip_ex12e.pcap

1. Draw a schematic call flow based on the trace! Who (IP# and Tel.#) are the user agents A, B and C?

___________________________________________________________________

2. Which RTP-port chooses the B user agent for the session with the A user agent?

___________________________________________________________________

3. With which frame puts the user agent B the call with A on hold? _______________

4. Which RTP-port chooses the B user agent for the session with the C user agent?

___________________________________________________________________

5. With which frame is the 3-party conference between A, B and C set up? ________

6. Where takes the media mixing place? ___________________________________



167

f) Click-to-dial

FN4102_sip_ex12f.pcap

1. Which SIP component sends the first INVITE message?

___________________________________________________________________

2. What is indicated by the FROM and Alert-Info header of this INVITE? ____________________________________________________________________

3. Why is a second INVITE sent to the same user agent? ______________________

g) Reject Call

FN4102_sip_ex12g.pcap

1. With which response does the B user agent reject the call?

___________________________________________________________________

h) Presence Watcher

FN4102_sip_ex12h.pcap

1. Which Business Groups (BG) subscribe for presence status?

___________________________________________________________________

2. To whom are the SUBSCRIBE messages sent?

____________________________________________________________________

3. What is contained in the NOTIFY messages?

____________________________________________________________________

e) Presence Buddy

FN4102_sip_ex12i.pcap

1. How does the buddy "K5" change its presence status?

___________________________________________________________________

2. What is its first and second status? ____________________________________


FN41028EN52GLA1




169

Exercise 13

Title: Signaling tracer for SIP-I

Objectives: The participant is able to follow the internal message flow with the help of a signaling tracer

Pre-requisite: Knowledge on tracer evaluation.

Message Catalog MCU,ISIP: P30309-A1224-A051-**-7622

Task TAC3/TAC3V17MPS/WSACBK1V7130/P63/013 06-04-12 14:19:53 5311 NetM IPAORCA1 3091/00006 DMPSIGNTRAC:DISPLAY=NORMAL; STARTED END TEXT 5311 TAC3/TAC3V17MPS/WSACBK1V7130/P63/013 06-04-12 14:19:55 5311 NetM IPAORCA1 3091/08190 DMPSIGNTRAC:DISPLAY=NORMAL; CALL UTILITIES : SIGNALING TRACE PROTOCOL TRACE REQUESTED FROM TERMINAL NetM AT 06-04-12 14:19:28 START OF CALL RELATED TRACE A-SIDE INFORMATION B-SIDE INFORMATION SELECTION: BY TRACER ACTIVATION ------------------+----------------------------+------------------------ LAC DN EQN/LTG LC TGNO/PA V522B SIP622 LNO 203 3 OPMODE CIC 13-18 CIRCUIT TYPE DIUSIG12 DIUSIG12 SIGNALING TYPE CCS7 ISUP SIGNALING VARIANT 0 0 CODE RECEIVER LIST-ID(S) 1 LTG 28-8 1 LTG 28-6


FN41028EN52GLA1


TAC3/TAC3V17MPS/WSACBK1V7130/P63/013 06-04-12 14:19:55 5311 NetM IPAORCA1 3091/08099 DMPSIGNTRAC:DISPLAY=NORMAL; TIME OF FIRST TRACED EVENT = 06-04-12 14:19:31 RELATIVE TIMESTAMP LIST M S MS TRACE EVENT TRACED IN EVENT DIRECTION ID ---------+------------------------------+----------+---------------+---- 00:00:000 O: JC1=H'1A JC2=H'85 RECEIVED GP-A 1 HC/MT=H'01 IAM H'14081201 0020010A 00020907 83902608 00340F0A 06031308 H'08204231 0200003D 011FFF04 0B080000 03041E02 80831D03 H'8090A339 0431C03D C0000000 0000 00:00:000 O: JC1=H'21 JC2=H'2A SENT GP-A 1 HC/MT=H'2F CFN H'6A100100 85080001 20B2012F 02000382 E3FF0000 0000 00:00:000 M:SEIZURE CA GP-A 1 H'00001200 77000002 02000000 00000000 E3FF00 00:00:000 M:DIGIT BLOCK C GP-A 1 H'77001001 13FB0A00 00000000 C1000000 00000000 00000900 H'02020000 05000000 01000000 00001000 00000000 00000000 H'00000000 00000000 00000700 00000000 89000000 00000009 H'00000008 08002240 06280004 30000000 00 00:00:068 C:SET UP C GP-A 1 H'7700006A 0C0E0000 4300000F 7F000024 09010400 000005C2 H'20000000 00000020 00061800 02000000 00000000 00000000 H'00000000 00FF0000 00000000 00000000 00000000 00000000 24 BYTES EQUAL H'00 H'00000000 00000000 00 NO MORE DATA ( REDUCED DATASIZE ) 00:00:068 R:PCU DATA FROM LTG GP-A OUTGOING 1 H'58000800 6A100302 0000 VOIP TRUNKING MCU SETUP_I H'05010112 02294453 2F535F31 372F5354 4D315F30 312F4531 H'5F34332F 3138404D 4731322E 545241 NO MORE DATA ( REDUCED DATASIZE ) 00:00:076 C:SEIZURE CBT GP-B 1 H'00004300 0E006A10 77F04408 00000000 00060400 00100000 H'00000000 F0010209 00000000 00000000 00000000 00000000 H'00802020 20202020 20202020 20200000 00000000 00000000 24 BYTES EQUAL H'00 H'00000000 00000000 00 NO MORE DATA ( REDUCED DATASIZE ) 00:00:100 R:PCU DATA TO LTG GP-A INCOMING 1 H'4C000800 6E280302 0000 VOIP TRUNKING MCU SETUP ACK H'80010112 05380182 83020283 83C80003 88833500 01C0A850 H'8D049B83 05839101 07058391 F00205 NO MORE DATA ( REDUCED DATASIZE ) 00:00:100 R:SET UP COMPLETE GP-A OUTGOING 1 H'0E6A1077 00000012 00090004 03020000 80002020 01000000 H'0000085F 00007700 00104000 010A0020 07809006 28000430 H'00033D00 04078090 06280004 300A0603 13808002 24A40F00



171

H'03020000 03000000 05085F00 00773D01 1F310200 0003041E H'0280831D 038090A3 39 NO MORE DATA ( REDUCED DATASIZE ) 00:00:100 O: JC1=H'21 JC2=H'2A SENT GP-B 1 HC/MT=H'01 IAM H'6A0C0000 85000000 00000001 1020010A 00020806 03902608 H'00340A06 03130808 20423102 00003D01 1E03041E 0280831D H'038090A3 390431C0 3DC000C0 000000 00:00:100 R:PCU DATA FROM LTG GP-B OUTGOING 1 H'9F000800 6A0C0B14 0000 SIP-NNI ISIP FORWARD SETUP H'05018143 04B20111 20010A00 02090704 90942608 00340A07 H'04139408 08204231 0200003D 011E03 NO MORE DATA ( REDUCED DATASIZE ) 00:00:456 R:PCU DATA TO LTG GP-B INCOMING 1 H'42000800 6E280B14 0000 SIP-NNI ISIP FACILITY H'03018143 05B20182 83060283 83149803 88833500 01C0A80C H'82058383 0107048B 83058391 010705 NO MORE DATA ( REDUCED DATASIZE ) 00:00:456 O: JC1=H'1A JC2=H'00 RECEIVED GP-B 1 HC/MT=H'41 APM H'00004341 00000000 00 00:00:456 R:APPLICATION REPORT GP-B OUTGOING 1 H'776A0C0E 00053B00 78370085 81C00000 01828306 02838314 H'98038883 350001C0 A80C8205 83830107 048B8305 83910107 H'058391F0 03E48391 0408E382 9104F182 91000000 00000000 00:00:456 R:PCU DATA FROM LTG GP-A OUTGOING 1 H'42000800 6A100302 0000 VOIP TRUNKING MCU FACILITY H'03010112 05320182 83060283 83149803 88833500 01C0A80C H'82058383 0107048B 83058391 010705 NO MORE DATA ( REDUCED DATASIZE ) 00:00:468 R:PCU DATA TO LTG GP-B INCOMING 1 H'26000800 6E280B14 0000 SIP-NNI ISIP BACKWARD SETUP H'06018143 048F0616 04012901 017A0101 39027AC0 00078102 H'0D82B400 FF800000 0000 00:00:468 O: JC1=H'1A JC2=H'00 RECEIVED GP-B 1 HC/MT=H'06 ACM H'00004306 16040129 01017A01 0139027A C0000000 0000 00:00:468 R:ADDRESS COMPLETE GP-B OUTGOING 1 H'776A0C0E 00041604 00000000 01150018 07000390 62800043 H'02060313 80800224 04010100 030B007A 01012901 0139027A H'C0000000 000000 00:00:468 O: JC1=H'21 JC2=H'2A SENT GP-A 1 HC/MT=H'06 ACM H'6A100100 85080001 20B20106 16040129 01017A01 0139027A H'C0000000 0000 00:00:480 R:PCU DATA TO LTG GP-A INCOMING 1 H'14000800 6E280302 0000 VOIP TRUNKING MCU FACILITY H'03010112 05040182 8308FF00 0000165D 00:00:480 R:APPLICATION REPORT GP-A OUTGOING 1 H'0E6A1077 00050D00 78090085 81C00000 01828308 00000000 H'0000 00:00:480 O: JC1=H'21 JC2=H'2A SENT GP-B 1 HC/MT=H'41 APM H'6A0C0000 85000000 00000041 01380190 00000000 00


FN41028EN52GLA1


00:00:480 R:PCU DATA FROM LTG GP-B OUTGOING 1 H'14000800 6A0C0B14 0000 SIP-NNI ISIP FACILITY H'03018143 05840182 8308FF80 00000000 00 00:09:376 O: JC1=H'1A JC2=H'85 RECEIVED GP-A 1 HC/MT=H'0C REL H'1408120C 02000280 90000000 00 00:09:376 R:PCU DATA FROM LTG GP-A OUTGOING 1 H'39000800 6A100302 0000 VOIP TRUNKING MCU RELEASE H'02010112 02294453 2F535F31 372F5354 4D315F30 312F4531 H'5F34332F 3138404D 4731322E 545241 NO MORE DATA ( REDUCED DATASIZE ) 00:09:376 R:CLEAR GP-A OUTGOING 1 CALL ABAND AFTER FIRST DIGIT H'0E6A1077 00B7000A 00000000 000F0305 00120280 90000000 H'000000 00:09:376 R:CLEAR ACKNOWLEDGEMENT GP-B OUTGOING 1 H'776A0C0E 000A0000 00000000 00:09:376 O: JC1=H'21 JC2=H'2A SENT GP-B 1 HC/MT=H'0C REL H'6A0C0000 85000000 0000000C 02000280 90000200 00 00:09:376 R:PCU DATA FROM LTG GP-B OUTGOING 1 H'19000800 6A0C0B14 0000 SIP-NNI ISIP RELEASE H'02018143 04860C02 00028090 128110FF 80000000 0000 00:09:396 R:PCU DATA TO LTG GP-A INCOMING 1 H'43000800 6E280302 0000 VOIP TRUNKING MCU RELEASE ACK H'82010112 0D020000 14217F00 00000000 00000000 00000000 H'00000000 00000000 00000000 000000 NO MORE DATA ( REDUCED DATASIZE ) 00:09:396 O: JC1=H'21 JC2=H'2A SENT GP-A 1 HC/MT=H'10 RLC H'6A100100 85080001 20B20110 00000000 00 00:09:396 M:RELEASE C GP-A 1 CALL ABAND AFTER FIRST DIGIT H'77000000 0A000000 0000000A B75E0000 10000000 02000000 H'00000000 00000000 09000000 06280004 30000000 00 00:09:436 R:PCU DATA TO LTG GP-B INCOMING 1 H'15000800 6E280B14 0000 SIP-NNI ISIP RELEASE ACK H'82018143 04821000 078102FF 80003650 7D 00:09:436 O: JC1=H'1A JC2=H'00 RECEIVED GP-B 1 HC/MT=H'10 RLC H'00004310 00000000 00 00:09:436 M:RELEASE C GP-B 1 CALL ABAND AFTER FIRST DIGIT H'0E000000 0A000000 0000000A B7000000 00000000 02000000 H'00000000 00000000 00000000 00000000 END TEXT 5311 TAC3/TAC3V17MPS/WSACBK1V7130/P63/013 06-04-12 14:19:57 5311 NetM IPAORCA1 3091/00007 DMPSIGNTRAC:DISPLAY=NORMAL; EXEC'D END JOB 5311



173

Exercise 14

Title: Signaling tracer for SIP-NNI (hiQ 4200) to PSTN (no CLIR)

Objectives: The participant is able to follow the internal message flow with the help of a signaling tracer

Pre-requisite: Knowledge on tracer evaluation

Task TAC3/TAC3V17MPS/WSACBK1V7130/P63/013 06-04-12 10:20:02 1547 NetM IPAORCA1 3091/00006 DMPSIGNTRAC:DISPLAY=NORMAL; STARTED END TEXT 1547 TAC3/TAC3V17MPS/WSACBK1V7130/P63/013 06-04-12 10:20:04 1547 NetM IPAORCA1 3091/08190 DMPSIGNTRAC:DISPLAY=NORMAL; CALL UTILITIES : SIGNALING TRACE PROTOCOL TRACE REQUESTED FROM TERMINAL NetM AT 06-04-12 10:17:00 START OF CALL RELATED TRACE A-SIDE INFORMATION B-SIDE INFORMATION SELECTION: BY TRACER ACTIVATION ------------------+----------------------------+------------------------ LAC DN EQN/LTG LC TGNO/PA SIP42B V522B LNO 28 188 OPMODE CIC 13- 3 CIRCUIT TYPE DIUSIG12 DIUSIG12 SIGNALING TYPE CCS7 ISUP SIGNALING VARIANT 0 0 CODE RECEIVER LIST-ID(S) 1 LTG 28-7 1 LTG 28-8 END TEXT 1547


FN41028EN52GLA1


TAC3/TAC3V17MPS/WSACBK1V7130/P63/013 06-04-12 10:20:04 1547 NetM IPAORCA1 3091/08099 DMPSIGNTRAC:DISPLAY=NORMAL; TIME OF FIRST TRACED EVENT = 06-04-12 10:17:41 RELATIVE TIMESTAMP LIST M S MS TRACE EVENT TRACED IN EVENT DIRECTION ID ---------+------------------------------+----------+---------------+---- 00:00:000 R:PCU DATA TO LTG GP-A INCOMING 1 H'8F000800 6E280B14 0000 SIP-NNI ISIP FORWARD SETUP H'0501815C 05E00182 83020283 8371BC03 88833500 01C0A809 H'97049C83 058391F0 07058391 F00205 NO MORE DATA ( REDUCED DATASIZE ) 00:00:000 O: JC1=H'1A JC2=H'00 RECEIVED GP-A 1 HC/MT=H'01 IAM H'00005C01 0120000A 00020806 03900808 20420A05 03139828 H'223D011F D3060584 BC01680E 00000000 00 00:00:000 M:SEIZURE CA GP-A 1 H'00005C00 7F000002 02000000 00000000 00F001 00:00:000 M:DIGIT BLOCK C GP-A 1 H'7F000001 13FB0A00 00000000 C1000000 00000000 00000900 H'02020000 05080000 01000000 00001000 00000000 00000000 H'00000000 00000000 00000700 00000000 07000000 00000009 H'00000008 98222008 08002240 00000000 00:00:040 C:SEIZURE CBT GP-B 1 H'00000300 03006A0E 7FF04408 00000000 00450400 00100000 H'00000000 F0000009 00000000 00000000 00000000 00000000 H'00802020 20202020 20202020 20200000 00000000 00000000 24 BYTES EQUAL H'00 H'00000000 00000000 00 NO MORE DATA ( REDUCED DATASIZE ) 00:00:044 C:SET UP C GP-A 1 H'7F00006A 10030000 0300000F 7F000004 09010400 000005C2 H'20000000 000000E0 00050F01 02000000 00000000 00000000 H'00000000 00FF0000 00000000 00000000 00000000 00000000 24 BYTES EQUAL H'00 H'00000000 00000000 00 NO MORE DATA ( REDUCED DATASIZE ) 00:00:072 R:SET UP COMPLETE GP-A OUTGOING 1 H'036A0E7F 0000005C 00090004 23020000 90014020 00000000 H'000007B7 03007F00 00104000 010A0020 07809008 08002240 H'00033100 04078090 08080022 400A0503 13898222 A40F0003 H'02000003 00000005 07B70300 7F3D011F 31020000 3906A4C0 H'3DC031C0 00056900 78 NO MORE DATA ( REDUCED DATASIZE ) 00:00:072 R:PCU DATA FROM LTG GP-B OUTGOING 1 H'B4000800 6A100302 0000 VOIP TRUNKING MCU SETUP_E H'06010103 02294453 2F535F31 372F5354 4D315F30 312F4531 H'5F34332F 3033404D 4731322E 545241



175

NO MORE DATA ( REDUCED DATASIZE ) 00:00:072 O: JC1=H'21 JC2=H'2A SENT GP-B 1 HC/MT=H'01 IAM H'6A100100 85080001 30A30101 1920000A 00020907 83900808 H'20420F0A 05031398 28223102 00003D01 1E39043D C031C000 H'C0000000 00:00:124 R:PCU DATA TO LTG GP-B INCOMING 1 H'44000800 6E280302 0000 VOIP TRUNKING MCU FACILITY H'03010103 05340182 83060283 83B00003 88833500 01C0A850 H'8D049083 058391F0 07058391 F00205 NO MORE DATA ( REDUCED DATASIZE ) 00:00:124 R:APPLICATION REPORT GP-B OUTGOING 1 H'7F6A1003 00053D00 78390085 81C00000 01828306 028383B0 H'00038883 350001C0 A8508D04 90830583 91F00705 8391F002 H'058391F0 03E48491 7E7F0805 8391F007 E3829104 00000000 H'0000 00:00:124 O: JC1=H'21 JC2=H'2A SENT GP-A 1 HC/MT=H'41 APM H'6A0E0000 85000000 00000041 01380190 00000000 00 00:00:124 R:PCU DATA FROM LTG GP-A OUTGOING 1 H'44000800 6A0E0B14 0000 SIP-NNI ISIP FACILITY H'0301815C 05B40182 83060283 83B00003 88833500 01C0A850 H'8D049083 058391F0 07058391 F00205 NO MORE DATA ( REDUCED DATASIZE ) 00:00:132 R:PCU DATA TO LTG GP-A INCOMING 1 H'14000800 6E280B14 0000 SIP-NNI ISIP FACILITY H'0301815C 05840182 8308FF80 0000F647 00:00:132 O: JC1=H'1A JC2=H'00 RECEIVED GP-A 1 HC/MT=H'41 APM H'00005C41 00000000 00 00:00:132 R:APPLICATION REPORT GP-A OUTGOING 1 H'036A0E7F 00050D00 78090085 81C00000 01828308 00000000 H'0000 00:00:132 R:PCU DATA FROM LTG GP-B OUTGOING 1 H'14000800 6A100302 0000 VOIP TRUNKING MCU FACILITY H'03010103 05040182 8308FF00 00B00003 88 00:00:156 R:PCU DATA TO LTG GP-B INCOMING 1 H'12000800 6E280302 0000 VOIP TRUNKING MCU SETUP ACK H'80010103 0D020000 FF000000 0000 00:00:156 O: JC1=H'21 JC2=H'2A SENT GP-B 1 HC/MT=H'05 COT H'6A100100 85080001 30A30105 01000000 00 00:00:600 O: JC1=H'1A JC2=H'85 RECEIVED GP-B 1 HC/MT=H'06 ACM H'14080306 16140129 0101F401 012E0100 3904F4C0 2EC00000 H'1645BD 00:00:600 R:ADDRESS COMPLETE GP-B OUTGOING 1 H'7F6A1003 00021634 00000000 01150018 08008390 80800224 H'F0020503 13898222 04010100 0310007A 01012901 012E0100 H'39047AC0 2EC00000 00000000 00:00:600 O: JC1=H'21 JC2=H'2A SENT GP-A 1 HC/MT=H'06 ACM H'6A0E0000 85000000 00000006 16340129 01012E01 0039022E H'C000C000 00C0


FN41028EN52GLA1


00:00:600 R:PCU DATA FROM LTG GP-A OUTGOING 1 H'12000800 6A0E0B14 0000 SIP-NNI ISIP BACKWARD SETUP H'0601815C 0D82B400 FF800039 022EC0 00:05:360 O: JC1=H'1A JC2=H'85 RECEIVED GP-B 1 HC/MT=H'09 ANM H'14080309 012D0200 0039022D C0000000 0000 00:05:360 R:PCU DATA FROM LTG GP-B OUTGOING 1 H'11000800 6A100302 0000 VOIP TRUNKING MCU MODIFY H'01010103 030104FF 00008080 0224 00:05:360 R:ANSWER GP-B OUTGOING 1 H'7F6A1003 00000000 00000001 15001808 00839080 800224F0 H'02050313 89822204 01010003 09002D02 00003902 2DC00000 H'00000000 00:05:364 O: JC1=H'21 JC2=H'2A SENT GP-A 1 HC/MT=H'09 ANM H'6A0E0000 85000000 00000009 012D0200 0039022D C0000000 H'0000 00:05:364 R:PCU DATA FROM LTG GP-A OUTGOING 1 H'12000800 6A0E0B14 0000 SIP-NNI ISIP BACKWARD SETUP H'0601815C 0D82C800 FF800000 000000 00:05:416 R:PCU DATA TO LTG GP-B INCOMING 1 H'12000800 6E280302 0000 VOIP TRUNKING MCU MODIFY ACK H'81010103 0D020000 FF000000 0000 00:17:956 O: JC1=H'1A JC2=H'85 RECEIVED GP-B 1 HC/MT=H'0C REL H'1408030C 02000280 90000000 00 00:17:956 R:PCU DATA FROM LTG GP-B OUTGOING 1 H'39000800 6A100302 0000 VOIP TRUNKING MCU RELEASE H'02010103 02294453 2F535F31 372F5354 4D315F30 312F4531 H'5F34332F 3033404D 4731322E 545241 NO MORE DATA ( REDUCED DATASIZE ) 00:17:956 R:CLEAR GP-B OUTGOING 1 NORMAL CALL CLEARING H'7F6A1003 00100001 00000000 000F0305 00120280 90000000 H'000000 00:17:956 R:CLEAR ACKNOWLEDGEMENT GP-A OUTGOING 1 H'036A0E7F 00010000 00000000 00:17:956 O: JC1=H'21 JC2=H'2A SENT GP-A 1 HC/MT=H'0C REL H'6A0E0000 85000000 0000000C 02000280 90000200 00 00:17:956 R:PCU DATA FROM LTG GP-A OUTGOING 1 H'11000800 6A0E0B14 0000 SIP-NNI ISIP RELEASE H'0201815C 128110FF 80000000 0000 00:17:980 R:PCU DATA TO LTG GP-B INCOMING 1 H'43000800 6E280302 0000 VOIP TRUNKING MCU RELEASE ACK H'82010103 0D020000 14217F00 00006F00 00412300 00032400 H'01F68000 00000000 00000000 000006 NO MORE DATA ( REDUCED DATASIZE ) 00:17:980 O: JC1=H'21 JC2=H'2A SENT GP-B 1 HC/MT=H'10 RLC H'6A100100 85080001 30A30110 00000000 00 00:17:980 M:RELEASE C GP-B 1



177

NORMAL CALL CLEARING H'03000000 0A0D007E 00000011 107E0000 10000000 02000000 H'00000000 00000000 00000000 00000000 00:17:996 R:PCU DATA TO LTG GP-A INCOMING 1 H'0E000800 6E280B14 0000 SIP-NNI ISIP RELEASE ACK H'8201815C FF800000 0000 00:17:996 O: JC1=H'1A JC2=H'00 RECEIVED GP-A 1 HC/MT=H'10 RLC H'00005C10 00000000 00 00:17:996 M:RELEASE C GP-A 1 NORMAL CALL CLEARING H'7F000000 0A0C007E 00000011 107E0000 00000000 02000000 H'00000000 00000000 09000000 08080022 40000000 00 END TEXT 1547 TAC3/TAC3V17MPS/WSACBK1V7130/P63/013 06-04-12 10:20:07 1547 NetM IPAORCA1 3091/00007 DMPSIGNTRAC:DISPLAY=NORMAL; EXEC'D END JOB 1547


FN41028EN52GLA1


Documents

08_FN41028EN52GLA1_sip