100% found this document useful (3 votes)
677 views257 pages

Slides SIP SIP-I Advanced in MSS15

Uploaded by

Abdaraof Hemmes
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (3 votes)
677 views257 pages

Slides SIP SIP-I Advanced in MSS15

Uploaded by

Abdaraof Hemmes
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 257

SIP/SIP-I Advanced in MSS15

Introduction
Objectives

Introduction – What is SIP?


› List the SIP and SIP-I features
› Explain SIP functionality
› Present MSS and SIP/SIP-I Scenarios
› Explore the interfacing networks for SIP/SIP-I
› Name the main logical nodes in the IMS (IP Multimedia Subsystem)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-1


SIP/SIP-I signaling in MSC-S 15A
› Interworking with SIP networks based on the 3GPP IMS standards,
including interworking with MMTEL

› Interworking with SIP networks based on the TTC standards, including


interworking with MMTEL

› SIP-I interworking with wireline or wireless soft-switches using the


standards specified by ITU-T, ANSI, and ETSI (V3 and V4) ISUP version
in SIP-I

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-2


SIP and SIP-I features in MSC-S 15A

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-3


What is SIP anyway?
“Session Initiation Protocol (SIP),
an application-layer control (signaling) protocol for creating,
modifying, and terminating sessions with one or more
participants” - source: RFC 3261 http://tools.ietf.org/html/rfc3261

What IETF says themselves about SIP…

http://tools.ietf.org/html/rfc5727 Change Process for the Session Initiation


Protocol (SIP) and the Real-time Applications and Infrastructure Area

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-4


SIP reuses email and HTTP Concepts
› SIP is like email between machines, using extended
HTTP syntax. In this way SIP is like AJAX*.

› In the same way there are email servers and web servers,
there are also SIP servers.

SIP Base Protocols

RFC3261 RFC3262 RFC3263 RFC3264 RFC3265

SIP PRACK Locating SDP Specific


SIP Event
Servers Notification

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-5


SIP Base is updated by many standards
› There are also many updates to standards referred
and reused by SIP Base Protocols (not shown here).
RFC3853 RFC4320 RFC4916 RFC5393
RFC5621 RFC5626 RFC5630 RFC5922 RFC5954
RFC6026 RFC6141 RFC6157 RFC6665 RFC6878
Obsoletes
Updates

RFC3261 RFC3262 RFC3263 RFC3264 RFC3265

SIP PRACK Locating SDP Specific


SIP Usage Event
Servers Notification

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-6


SIP has soft real-time with long timeouts
› The complexity
with SIP
compared with
email and HTTP
is that SIP has
special soft real-
time
requirements.

› Example: A
Non-INVITE
sender can
“give up” before
the protocol
times out = 32 !
seconds

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-7


Example of inconsistence using SIP timers
› The answer is returned in time (64*T1), but arrived too late.

› Timers are not


synchronized.

› Call states can


be different in
different nodes:
Inconsistence.

Non-INVITE Transaction Problems


http://tools.ietf.org/html/rfc4321

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-8


Security vs. Interoperability
› S/MIME is secure all way, but HTTPS (TLS) is per hop.

TLS is optional
per hop

SIPS URI Scheme


http://tools.ietf.org/html/rfc5630

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-9


SIP is more than 100 internet standards
› IANA summarizes the SIP protocol, but does not mention all standards
http://www.iana.org/assignments/sip-parameters/sip-parameters.xml
Example is RFC5751 – S/MIME v3.2 used by SIP, but not shown below.

RFC2616, RFC2617, RFC3204, RFC3261, RFC3262, RFC3263, RFC3264,


RFC3265, RFC3310, RFC3311, RFC3312, RFC3313, RFC3323, RFC3325,
RFC3326, RFC3327, RFC3329, RFC3427, RFC3428, RFC3455, RFC3459,
RFC3486, RFC3515, RFC3581, RFC3603, RFC3608, RFC3840, RFC3841,
RFC3891, RFC3892, RFC3903, RFC3911, RFC3959, RFC3968, RFC3969,
RFC4028, RFC4091, RFC4092, RFC4235, RFC4240, RFC4244, RFC4411,
RFC4412, RFC4457, RFC4458, RFC4474, RFC4488, RFC4538, RFC4575,
RFC4660, RFC4662, RFC4916, RFC4964, RFC4967, RFC5002, RFC5009,
RFC5049, RFC5079, RFC5318, RFC5360, RFC5365, RFC5366, RFC5367,
RFC5368, RFC5373, RFC5393, RFC5478, RFC5502, RFC5503, RFC5552,
RFC5626, RFC5627, RFC5630, RFC5727, RFC5768, RFC5839, RFC5923,
RFC5989, RFC6011, RFC6026, RFC6050, RFC6072, RFC6080, RFC6086,
RFC6140, RFC6223, RFC6228, RFC6401, RFC6442, RFC6446, RFC6665,
RFC6794, RFC6809, RFC6873, RFC6910 (and more is coming…)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-10


SIP has several Methods
› SIP is like a “framework” where new methods can be added
as needed.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-11


An Empty Line separates Header and
Body
› SIP reuses HTTP/HTTPS syntax, except… overall layout

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-12


Example of a SIP request
Request INVITE sip:[email protected] SIP/2.0
Line Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net;lr>, <sip:scscf1.home1.net;lr>
From: <sip:[email protected]>;tag=171828
Header

To: <sip:[email protected]>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Contact: <sip:[5555::aaa:bbb:ccc:ddd]>
Content-Type: application/sdp
Content-Length: 248
Body

SDP

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-13


Example of an SDP session description

v= 0
o= mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s= SDP Seminar
i= A Seminar on the session description protocol
u= http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e= [email protected] (Mark Handley)
c= IN IP4 224.2.17.12/127
t= 2873397496 2873404696
a= recvonly
m=audio 49170 RTP/AVP 0
m= video 51372 RTP/AVP 31
m= application 32416 udp wb
a= orient:portrait

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-14


SIP Components
› SIP User Agents
– User Agent Clients (UAC)
– User Agent Servers (UAS)

› SIP Servers
– Proxy server
– Location server
– Redirect server
– Registrar server

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-15


User Agents (1)
Consists of UAC part and a UAS part
› UAC - An entity that initiates a call
› UAS – An entity that receives a call
› UAC is the only SIP component that can create an original request
› Phones – acts as UAC or UAS
› Implemented in Hardware or Software Components
› Includes softphones, SIP ip phones, gateways

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-16


User Agents (2)
› Gateways – provide call control, mainly translation function between SIP
conferencing end points and other terminal types
› Includes a translation between translation formats
› Translation between codecs

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-17


User Agents (3)
Examples of user SIP user agents:

Cisco 7960 SIP IP Phone

PC with softphone application

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-18


Proxy Server
› Acts Both as a Server and a Client
› Receives SIP messages, forwards to next SIP server
› Can perform functions such as Authentication, Autherisation, network access
control, routing
› Requests are serviced internally or by passing them on, possibly after
translation, to other servers.
› Interprets, rewrites or translates a request message before forwarding it.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-19


Redirect server
› Provides information about next hop to the users
› Maps address to zero or more real addresses
› Does not accept or terminate calls
› Does not initiate its own SIP request
› Generates SIP responses to locate other entities

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-20


Registrar server
› Accept registration requests from users
› Maintains user’s whereabouts at a Location Server
› Typically co-located with a proxy server or a redirect server and may offer
location services
› May also support authentication

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-21


Location Server

› Used by a SIP redirect or proxy server to obtain information about a called


party’s possible location (s)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-22


Simplified SIP Call Setup and Teardown
Alice Bob

User Agent Proxy Server Location/Redirect Server Proxy Server User Agent
INVITE INVITE
100 Trying 302
(Moved Temporarily)
ACK
INVITE
Call 100 Trying
Setup INVITE

180 (Ringing) 180 (Ringing) 180 (Ringing)

200 (OK) 200 (OK) 200 (OK)


ACK ACK ACK
Media
RTP MEDIA PATH
Path
Call BYE BYE BYE
Teardown 200 (OK) 200 (OK) 200 (OK)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-23


Protocol Interworking

SIP/SIP-I
TCP/UDP
IP
Data Link
Phys
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-24
Supported Interworking Scenarios

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-25


Signaling Plane and User Plane
Interworking
SIP
UDP,
TCP
IP
LL
SBC, I-CSCF BGCF
SBG
MRFP CSCF S-CSCF
CSCF CSCF

RTP/ SIP SIP


RTCP
UDP, UDP,
UDP TCP TCP
IP Mg Mj IP
IP
LL LL LL

SIP,SIP-I
RANAP, SIP,SIP-I
ISUP, ISUP, RANAP ISUP, BSSAP UDP,TCP
BSSAP
BICC BICC BICC IP UDP,TCP
SCCP SCCP SCCP
LL IP
M3UA MTP3b MTP3
MSC-S LL
SCTP SAAL MTP2
IP ATM GCP external
LL wireless,
LL LL M3UA
wireline, or
SCTP IMS network
Iu, A, BICC,ISUP Mn SBG
SBC
Mc IP RTP/
RNC LL RTCP
Q.AAL2 Mb UDP
BSC SCTP SAAL Mb IP
RTP/
Radio IP ATM LL
RTCP
Access, LL LL
CS network UDP
IP
Iu, A,Nb,ISUP
MGW MSC-S
MGW
M-MGw LL
NbUP,IuUP
PCM
RTP AAL2
TDM
UDP ATM
IP
LL
LL

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-26


IMS Interworking
RFC 3261, RFC 3264, RFC
3262, RFC 3263, RFC 3311,
CS RFC 3323, RFC 3325, RFC
Domain 3326, RFC 3455, RFC 3556,
RFC 3966

TeS SIP/SDP

MSC-S
Mg/Mj
MGCF (TS 24.229)
IMS
Mc+Mn Domain
H.248

(TS 29.232)
(TS 29.332)

Mb
Proprietary GCP
profile combining
open-Mc and Mn RTP/RTCP
interface.

VoIP-GW

RFC 3550, RFC 3551, RFC


3555, RFC 3556, RFC 4867,
RFC 4733

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-27


IMT Architecture Overview
IP-Centrex Servers Presence Server

Network &
Service SIP SIP
Mgmt
CS-MS CS-AS CS-CS PGM

Interworking
SIP
SIP
OSS-RC
SIP External IMS

Diameter N-SBG
EMA HSS S-CSCF CSCF
SIP
SIP

Diameter SIP ISUP


MM PLMN
SLF I-CSCF MGC MSC-S
SIP H248

IPWorks
SIP

P-CSCF
MGW
SIP

SIP or H323 External VoIP


Network
Media A-SBG N-SBG
SIP
SIP
H323 SIP-PBX

H323 PBX
SIP Phone SIP-ALG POTS/IAD SIP Client

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-28


IMS Access
User Equipment
› PC-Client
› (Call Manager Client – Web Access)
› SIP Phone
› POTS with SIP IAD
› SIP ALG
› 2G/3G Mobile phone with SIP Client

User Access
› BroadBand
› Cable
› GGSN

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-29


Proxy Call Session Control Function
(P-CSCF)
The P-CSCF is the first contact point for the UE in the IMS
network.

Behaves as a stateful proxy and performs the following main


tasks:
› Keeps track of registrations and active call sessions.
– Stores the UE Contact info (IP address and port).
– Enforce min/max registration times.
› Forwards SIP messages from the access network to the SIP
server in the home network (and vice versa).

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-30


Interrogating Call Session Control Function
(I-CSCF)
The I-CSCF is the entry point for all connections terminating
in the subscriber home IMS network.

It performs the following main tasks:

› Assigns an S-CSCF during initial registration, in cooperation


with the HSS.
› Routes SIP requests received from another network towards
the S-CSCF.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-31


Serving Call Session Control Function
(S-CSCF)
The S-CSCF performs session control services including:
› Subscriber registration – SIP Registrar.
› User Authentication (together with HSS).
› Downloading the user profile with service trigger data from HSS.
› Triggering of the Application Servers in order to provide multimedia
services.
› SIP Message Routing.
› Number Normalization from local numbers to global E.164 numbers.
› Querying the ENUM DNS for translation of E.164 numbers to routable
SIP URIs.
› Breakout.
› Supervision of ongoing sessions using the session timer.
› Accounting data output.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-32


Home Subscriber Server (HSS)
It is the master database containing all user and subscriber
information.
The HSS provides the following capabilities:
› Identification of users.
› Authentication and authorization of user access.
› Keeps track of which S-CSCF the user is registered to.
› Service information support – triggers, application server identities in the
user profiles.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-33


ENUM Domain Name Server
› DNS for resolving of Fully Qualified Domain Names into IP-addresses.
› ENUM for resolving phone numbers into routable SIP-addresses.
› DHCP support to IPv4 and IPv6 networks.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-34


Centrex Servers
CENTREX SERVICES
CS-Application Server
•Main access point for control signaling.
CS-DS CS-WS CS-CDS •Manages the sessions.
•User & group profiles, service & subscription data.
SIP
CS-Media Server
SIP

CS-MS CS-AS
•Terminates the RTP media streams for detecting
CS-CS
digits, recording & playing media, video greetings
and video attendant etc.
CS-Conference Server
•Audio and Web Conferencing.
CS-WS (CS Web Server Farm)
•Portals for service administration.
CS-DS (CS Distribution Server)
•Directs end-user requests towards the appropriate
Application Server.
CS-CSD (CS Call Detail Server)
•Stores call log data.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-35


Presence Service

PRESENCE SERVICES • Presence status – available, busy, idle, offline.


• Subscribers – the online subscribers to the
PGM
user’s Presence Information.
• Authorization policies – rules set by the user
available
to determine who may subscribe to their
presence information or not.
CSCF • User accesses these services through the
CSCF by using the PC-client Active Contacts.
• PUBLISH
• SUBSCRIBE
• NOTIFY

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-36


Session Border Gateway
› Funnels sessions - signaling together with associated
media streams of real time IP voice, video, and other
data to/from other IP networks.

› Ensures Security, Quality of Service, Service Level Agreements &


Network Address Translation.

› The SBG has two roles in the network;


– As Access Session Boarder Gateway (A-SBG) in the
crossing between an access network and the IMT system,
to funnel sessions from User Agent Clients (UAC) to the CSCF.
– As Network Session Boarder Gateway (N-SBG)
in the crossing between an external network and the IMT system.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-37


PSTN / PLMN Gateway
Media Gateway Controller
› Master to the MGWs.
› Responsible for the call control signaling.
› Multimedia session establishment, modification, and
termination.
› Addressing and routing of multimedia sessions to and
from CSCF.

Media Gateway
› Handles the media payload.
› Adapts the payload into IP packets.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-38


Support Systems
Network & EMA (Ericsson Multi Activation)
Service
Mgmt • Provides one uniform interface, through which all databases can be
accessed from the Customer Administration System (CAS).

MM (Multi Mediation)
OSS-RC • All charging records are sent to, or collected by the MM system for
refinement and distribution to the external BSS as CDRs.

OSS-RC (Operation Support System)


EMA • Used for fault, configuration, and performance management of the
system.

MM
IPWorks (ENUM/DNS)
• DNS SRV and other standard DNS queries
• ENUM translates E164 to SIP URI.

IPWorks

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-39


Reference Architecture of the IMS
IP Multimedia Networks Legacy mobile
CS Network Mm Signalling Networks

Mb Mb CS
BGCF I-CSCF AS
Mm
CS
Mk Mk
ISC Sh
Cx C, D,
Mj BGCF Mw Mw
Gc, Gr
Mi
Cx
IMS - MGCF HSS
MGW Mn Mg S-CSCF
Dx

Mr Mw
SLF
Mb

MRFP MRFC P-CSCF


UE
Mp Gm Ut

Mb Mb Mb IMS Subsystem

Media These nodes are used for mobile access


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-40
Interwork with IMS before SIP
implementation in MSC-S
IP-Centrex Servers Presence Server

Network &
Service SIP SIP
Mgmt PLMN
CS-MS CS-AS CS-CS PGM

Interworking
SIP
SIP
OSS-RC

Diameter N-SBG RAN


EMA HSS S-CSCF SIP
SIP

Diameter SIP ISUP


MM
SLF I-CSCF MGC MSC-S BSC
SIP
H248
H248
IPWorks
SIP

P-CSCF
MGW
MGW
SIP

Media A-SBG N-SBG

SIP or H323

External VoIP
SIP Phone Network
SIP Client
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-41
Interwork with IMS after SIP implementation
in MSC-S
IP-Centrex Servers Presence Server

Network &
Service SIP SIP
Mgmt PLMN
CS-MS CS-AS CS-CS PGM

Interworking
SIP
SIP
OSS-RC

Diameter N-SBG RAN


EMA HSS S-CSCF SIP
SIP
SIP

Diameter SIP SIP


MM
SLF I-CSCF MSC-S BSC
SIP
SIP
H248
IPWorks

P-CSCF
MGW
SIP
Alternative
Way to media
Media
A-SBG N-SBG

SIP or H323
SIP

External VoIP
SIP Phone Network
SIP Client
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-42
MSC-S SIP/SIP-I Interfaces

BICC
MSC-S MSC-S
SIP SIP-I
MSS
CSCF PLMN1 MGC

BGCF MGW MGW Softswitch


(PSTN=TSS) /PLMN2
IMS
MGW

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-43


MSC-S Blade Cluster and IS Blades

IS Infrastructure
M S I M M M I S I E M M M E M
X I P S S S S I P X S S S X X
B S L C C C L S L B C C C B B
Application Blades
B B

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-44


SIP and SIGTRAN signalling in the
MSC-S Blade Cluster (IS based)

Blades:
MSC IS
SIP signalling
MSC
IPLB
MXBMXB
MSC
IPLB
SIGTRAN signalling

EXB EXB

SPX x 2
SCB- APZ SCB-
RP 212 60 RP (only one
shown)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-45


SIP and SIGTRAN signaling in the
MSC-S Dual Blade (IS based)

SIP signaling

APZ GESB

GARP
RPB-E

SIGTRAN signaling

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-46


Traffic handled by IPLB
MSC-blade SPX

4
Unbalanced UDP or TCP traffic:
5 Balanced UDP or TCP traffic: SIP/UDP or TCP APG
SIP/UDP or TCP DNS/UDP or TCP
DNS/UDP or TCP 1
SRVCC/UDP Unbalanced SCTP traffic:
M3UA/SCTP
Balanced SCTP traffic: M2PA/SCTP
2
GCP/SCTP IUA/SCTP
SGsAP/SCTP GCP/M3UA/SCTP
SIP/SCTP

IPLB CMXB

CMXB as a VR
(Router Mode)

3
Unbalanced UDP or TCP traffic:
OAM/UDP or TCP

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-47


SIP/SIP-I Advanced in MSS15

SIP Protocol
Objectives

Explain the functions and capabilities of SIP protocol:

› Explain generic architecture and terminology


› Name the IETF protocols related to SIP
› Understand the most important SIP protocol header fields
› Relate the steps in a basic session establishment between MSS and
external networks

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-50


SIP Background and Functionality
› Background:
– Developed by IETF MMUSIC (Multi-Party Multimedia Session Control)
Work Group
– The Current protocol standard is RFC 3261 (current basic spec) and
replaces the original RFC 2543 of 1999
– Signaling protocol for exchange of media information
– Can run on top of TCP and UDP and in the future over SCTP

› The basic functions of SIP:


– Location of an end point (Subscriber)
– Signal of a desire to communicate
– Negotiation of session (call), parameters to establish the session
– Teardown after the end of the session (call)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-51


SIP Concept

SIP SIP SIP


Proxy Proxy

SIP SIP

UA UA
Session

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-52


SIP Components
SIP Server
Proxy
Redirect
Registrar
B2BUA

SIP Request

IP

UAC RTP Stream ( Media) UAS

UAC – User Agent Client


UAS – User agent Server
B2BUA – Back to Back User Agent
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-53
SIP Requests and Responses
SIP MESSAGES

REQUESTS/METHODS RESPONSES

REGISTER
INVITE PROVISIONAL FINAL
ACK
Basic (RFC 3261)
BYE
Methods
CANCEL 100-199 >199
OPTIONS 100 Trying, 2xx Success
180 Ringing, and 3xx Redirect
MESSAGE (RFC 3428) 183 Session progress 4xx Client Mistake
Extension SUBSCRIBE (RFC 3265)
5xx Server Failure
Protocol PUBLISH (RFC 3903)
6xx Global Failure
methods NOTIFY (RFC 3265)
INFO (RFC 2976)
UPDATE (RFC 3311)
REFER (RFC 3515)
PRACK (RFC 3262)
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-54
Detailed Numbering Methods
1xx Informational – 100 Trying
– 180 Ringing
– 181 Call is Being Forwarded
– 182 Queued
– 183 Session Progress
2xx Success – 200 OK

3xx Redirection – 301 Moved Permanently


– 302 Moved Temporarily

4xx Client Error – 401 Unauthorized


– 404 Not found
– 482 Loop Detected
– 486 Busy Here
5xx Server Failure – 500 Server Internal Error (Retry-after:5)

6xx Global Failure – 600 Busy Everywhere


– 604 Does not Exist Anywhere
– 606 Not acceptable

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-55


Function of SIP Methods

Request Method Description

INVITE Used to establish session between user agents

REGISTER Used by a user agent to notify a SIP network of its current IP


address and URL for calls

BYE Used to terminate an established media session

ACK Used to acknowledge final response to INVITE requests

CANCEL Used to terminate pending searches or call attempts

OPTION Used to query a user agent or server about its capability and its
current availability

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-56


Function of SIP Methods (2)
Request Method Description
INFO Used by user agent to send call signaling information to other
user agent with which it has an established session
PRACK (Provisional Used to acknowledge receipt of reliably transported provisional
Response Ack) responses (1xx)

SUBSCRIBE: installs a subscription for a resource


NOTIFY: informs about changes in the state of the resource
MESSAGE: delivers an Instant Message
REFER: used for call transfer, call diversion, etc.
PRACK: acknowledges a provisional response for an INVITE request

UPDATE: changes the media description (e.g. SDP) in an existing session

INFO: used to transport mid-session information


PUBLISH: publication of presence information
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-57
SIP General Message Format
Start Line: REQUEST: Method, URI, version or STATUS: Response
Header fields . . .
•Addresses for routing
•Dialog & Transaction Ids
•UA capabilities
•Security/privacy settings

Empty line
Body (optional)
SDP
XML
MIME . . .

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-58


Example of a SIP request
Request Method
INVITE sip:[email protected] SIP/2.0
Line Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7 Version
Max-Forwards: 70 Request-URI
Route: <sip:pcscf1.visited1.net;lr>, <sip:scscf1.home1.net;lr>
From: <sip:[email protected]>;tag=171828
Header

To: <sip:[email protected]>
Call-ID: cb03a0s09a2sdfglkj490333 Header Field
Cseq: 127 INVITE
Contact: <sip:[5555::aaa:bbb:ccc:ddd]>
Content-Type: application/sdp Header Field Name
Content-Length: 248
Header Field Value
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
Body

t=907165275 0
m=audio 3458 RTP/AVP 97 96 0 15
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 G726-32/8000

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-59


SIP Headers for SIP part

 Request line Extendibility:


 Status line  Accept
Routing
 Allow
 Via
 Route  Require
 Record-Route  Supported
 Contact  Unsupported
Common Authentication:
 To
 WWW-Authenticate
 From
 Call-Id  Authorization
 Max-Forwards
 Cseq
 RSeq
 RAck

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-60


The Use of RSeq, CSeq & RAck
Request-Line: INVITE sip:[email protected] SIP/2.0
CSeq: 39 INVITE

Status-Line: SIP/2.0 183 Session Progress

CSeq: 39 INVITE

Require: 100rel

RSeq: 17

Request-Line: PRACK sip:csas.edu.imt.se:5060 SIP/2.0

CSeq: 40 PRACK

RAck: 17 39 INVITE

Status-Line: SIP/2.0 200 OK

CSeq: 40 PRACK

Status-Line: SIP/2.0 200 OK

CSeq: 39 INVITE

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-61


Body Part and Other SIP headers

Body Part
 Accept-Encoding
 Content-Type
 Content-Length
 Content-Encoding
 Content-Disposition
 MIME-Version

Other SIP Headers


 P-Asserted-Identity
 P-Charging-Vector
 Privacy
 Retry-After
 Reason
 Timestamp
 Warning
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-62
Call Release and Call Setup
UAC Proxy UAS
INVITE
INVITE
100 Trying
100 Trying

180 Ringing
180 Ringing

PRACK
PRACK

200 OK
200 OK
200 OK
200 OK

ACK

Session active
BYE
BYE

200 OK
200 OK

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-63


Basic Concept - Transactions
INVITE

› All signaling messages are composed of 180 Ringing


independent transactions
› Fundamental unit of messaging exchange 200 OK CSeq: 1
– Request
– Zero or more provisional responses ACK
– One final response
– Maybe ACK
Media Session
› Identified by CSeq (Command Sequence)
– Sequence number
– Method tag BYE
CSeq: 2
200 OK

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-64


Basic Concept - Dialog

A dialog represents a peer-to-peer INVITE INVITE


SIP relationship between two user
agents. A dialog persists for some 100 trying
100 trying
time and it is very important
200 OK 200 OK
concept for user agents. Dialogs
facilitate proper sequencing and ACK ACK
routing of messages between SIP
endpoints. Dialogs are identified Bye
using Call-ID, From tag, and To
tag. 200 OK

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-65


Proxy Servers
› Forwards requests and responses only
– Does not issue a request; only responds to requests from user agent (except CANCEL)
– Has no media capabilities
› Proxy server can be stateless or stateful
› Stateless proxy server process each
request based solely on the message
content
– Never retransmits
– No memory
› Stateful proxy server keeps track of
requests received and use that info for
future response
– Uses a timer and retransmits after the
timer expires
User Agent Proxy Server User Agent
– Can require user agent authentication
– Usually sends a 100 Trying
Client Server
response
Server Server – Proxy handling TCP must be stateful
Server Client

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-66


Forking Proxy Servers
› Stateful proxy
› Forking proxy server can receive an INVITE
INVITE request, then forward to a Branch = 1
SIP
number of locations at the same Phone
time if the database lookup returns
multiple possible locations for the INVITE
Branch = 2
called party that need to be tried
INVITE
› Two variations SIP Mobile
INVITE Phone
– Sequential search: Try first Forking Branch = 3
address, only if that fails try Proxy Server
Calling
second User
– Parallel search: Try all at once Agent
SIP
› First response (200 OK) received is Enabled
PC
forwarded upstream
› All other unanswered requests
cancelled

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-67


Loop Detection
Via: C
› With all this forking and forwarding, Via: B
request may fall into a loop and come Via: A
back to the same proxy! Via: U

› SIP provides two mechanisms to prevent


messages from looping forever Proxy Server Proxy Server 
D
– Max-Forwards Via: D
C

› Max-Hops counter decremented Via: C Via: B


by 1 on each hop Via: B Via: A


Via: A
› Discard request when Max-Hops Via: U
Via: U
is zero
– Via based loop detection and
prevention
Via: A
› Every proxy inserts its address in Proxy Server  Via: U Proxy Server 
the Via header A B
Via: U
› Check for its own address and
branch in the list of Via header
› Drop the request if loops are Calling
detected User
Agent

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-68


SDP – Session Description Protocol
Background:
Developed by IETF
The Current protocol standard is RFC 2327 (current
basic spec)
Can be used besides SIP for other protocols like SAP,
MGCP, RTSP, Email, HTTP, IPBCP, etc

Basic functions
Describes the details of the session, such as IP address, Codecs and IP
ports

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-69


SDP General Format
v= (protocol version)
o= (owner/creator and session identifier) Time description:
s= (session name)
i=* (session information) t= (time the session is active)
u=* (URI of description) r=* (zero or more repeat times)
e=* (email address) Media description:
p=* (phone number)
c=* (connection information) m= (media name and transport address)
b=* (bandwidth information) i=* (media title)
c=* (connection information)
One or more time descriptions (see right) b=* (bandwidth information)
z=* (time zone adjustments) k=* (encryption key)
k=* (encryption key) a=* (zero or more media attribute lines)
a=* (zero or more session attribute lines)
Zero or more media descriptions (see
right)
* Optional information
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-70
Offer / Answer Model for SDP

Session level attribute foo


Session level attribute bar
A B
m = audio 20000 RTP/AVP 8 3
m = audio 21000 RTP/AVP 97
m = video 40000 RTP/AVP 98

Session level attribute foo


Session level attribute bar
m = audio 30000 RTP/AVP 8
m = audio 0 RTP/AVP 97
m = video 21000 RTP/AVP 98

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-71


SDP Example

Version ---> v=0


Origin ---> o=gonzalo 2987933615 2987933615 IN IP4 10.0.0.8
Session Name --> s=training course
Session URI --> u=http://standards.ericsson.net/sip
level E-mail address --> [email protected]
Phone number --> p=+358-9-299-3553 IP address where
Connection Data --> c=IN IP4 10.0.0.8
Times --> t=907165275 0
media is received
Media --> m=audio 3458 RTP/AVP 97 0
Attributes --> a=rtpmap:97 AMR
Media Attributes --> a=fmtp:97 mode-set=0,2,5,7; maxframes=2
level Media --> m=video 3459 RTP/AVP 98
Attributes --> a=rtpmap:98 H263 Codecs
Media --> m=application 32416 udp wb

Type of media Port number where


streams media is received

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-72


RTP/AVP codecs (RFC 1890) negotiated by SDP (RFC
2327)
PT Encoding Name Audio/Video PT Encoding Name Audio/Video

0 PCMU (u-law) A 16-23 unassigned A

1 1016 A 24 unassigned V

2 G721 A 25 CelB V

3 GSM A 26 JPEG V

4 unassigned A 27 unassigned V

5 DVI4 A 28 nv V

6 DVI4 A 29 unassigned V

7 LPC A 30 unassigned V

8 PCMA (a-law) A 31 H261 V

9 G722 A 32 MPV V

10 L16 A 33 MP2T AV

11 L16 A 34-71 unassigned ?

12, 13 unassigned A 72-76 reserved N/A

14 MPA A 77-95 unassigned ?

15 G728 A 96-127 dynamic ?

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-73


Supported Codecs for each Network

G.722

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-74


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-75
SIP/SIP-I Advanced in MSS15

DNS Routing
Objectives

Clarify DNS routing

› Explain the routing principles for SIP messages


› Demonstrate cases where DNS is invoked
› Practice to configure DNS resolver routing in MSS

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-77


Basic Routing in SIP
DNS
DNS DNS DNS DNS DNS Location
DNS DNS Query
Query Server Query Server Server Server
Query Server

Proxy A Proxy C
UAC aside Proxy B bside UAS
alice@aside bob@bside
INVITE Bob@bside INVITE Bob@bside INVITE Bob@bside INVITE Bob@current
Via: <UAC> Via: <ProxyA> Via: <ProxyB> Via: <ProxyC>
Contact: alice@current Via: <UAC> Via: <ProxyA> Via: <ProxyB>
Contact: alice@current Via: <UAC> Via: <ProxyA>
Contact: alice@current Via: <UAC>
Contact: alice@current

200 OK 200 OK 200 OK 200 OK


Via: <UAC> Via: <ProxyA> Via: <ProxyB> Via: <ProxyC>
Contact: bob@current Via: <UAC> Via: <ProxyA> Via: <ProxyB>
Contact: bob@current Via: <UAC> Via: <ProxyA>
Contact: bob@current Via: <UAC>
Contact: bob@current

ACK bob@current
Via: <UAC>
Contact: alice@current

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-78


VIA Operation

Via: C
Via: B Via: B
Via: A Via: A Via: A
Proxy Proxy
UAC UAS
Via: A Via: B Via: C
Addr: A Addr: B Addr: C Addr: D
Via: A Via: B
Via: A

Request
Response

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-79


Loose Routing in SIP
DNS DNS DNS DNS
DNS DNS DNS
Query Server Query DNS Location
Query Server Server Query
Server Server

UAC Proxy A Proxy B Proxy C UAS


alice@aside bob@bside
INVITE Bob@bside INVITE Bob@bside INVITE Bob@bside INVITE Bob@current
Via: <UAC> Record-Route: <SIP:A; lr> Record-Route: <SIP:A; lr> Record-Route: <SIP:C; lr>
Contact: alice@current Via: <ProxyB> Record-Route: <SIP:A; lr>
Via: <ProxyA>
Via: <ProxyA> Via: <ProxyC>
Via: <UAC>
Via: <UAC> Via: <ProxyB>
Contact: alice@current
Contact: alice@current Via: <ProxyA>
Via: <UAC>
Contact: alice@current

200 OK 200 OK 200 OK 200 OK


Record-Route: <SIP:C; lr> Record-Route: <SIP:C; lr> Record-Route: <SIP:C; lr> Record-Route: <SIP:C; lr>
Record-Route: <SIP:A; lr> Record-Route: <SIP:A; lr> Record-Route: <SIP:A; lr> Record-Route: <SIP:A; lr>

ACK bob@current ACK bob@current ACK bob@current


Route: <SIP:A; lr> Route: <SIP:C; lr>
Route: <SIP:C; lr>

BYE alice@current BYE alice@current BYE alice@current


Route: <SIP:A; lr> Route: <SIP:C; lr>
Route: <SIP:A; lr>

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-80


Routing of SIP Messages
• Routed using the Route header
REQUESTS ACK bob@current
Route: <SIP:A; lr>
Route: <SIP:C; lr>

• Routed using configured/stored data


Like MSC-S Static Configuration.

• Routed using the Request URI


and DNS look-up
Request URI: sip:user@domain
Ex: INVITE sip:[email protected]

Request URI: sip:telephone number@home domain, user=phone


Ex: INVITE sip:[email protected], user=phone

RESPONSES Routed using the VIA header


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-81
Dialling a phone number

Request URI: sip:telephone number@home domain, user=phone


Ex: INVITE sip:[email protected], user=phone

Tel URL: tel: telephone number


Ex: INVITE tel:4684045813

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-82


DNS Basics
› DNS: Domain Name System – is a distributed database system used to
store resource information specified as resource records (RR).
› To look up information in a “Name Server”, a user must have a DNS
Client (Resolver).
› MSS R5.0 forward implements the DNS client and provides the
standardized interface to external DNS Servers (Name Servers).

MSC Server

DNS Query
DNS
DNS
DNS RR Name
Server
Server
Resolver Server

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-83


DNS Resolver
› Any application can ask the DNS resolver to provide resource
information (e.g. IP address) that belongs to a host name (1).
› The resolver translates internal user requests into DNS queries (2).
› The resolver stores query results (RRs) into a cache (3).
› The cached info can be used in later user requests to speed-up the
name resolution (4).
MSC Server
Application
(user program)

(1) Host (4) IP


Name Address

(2)-DNS Query
DNS Resolver
DNS
DNS
(3) RR Name
Server
Local Server
Server
Cache

DNS Client DNS Server


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-84
DNS Queries
Three queries type are used to support SIP/SIP-I application:

– A-query: get the IP address of the particular server.

– NAPTR: determine the preferred transport protocol (UDP or TCP) in the


domain.

– SRV: get server(s) names that can be contacted for the particular domain
and particular transport protocol.

DNS Queries are mostly used to send initial INVITE message and if the
inspected header of a received message contains an FQDN that must
be resolved.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-85


Example of DNS queries

DNS

2
SIP Proxy/ 4
MSC Server

5
DNS
Resolver
1
INVITE sip:[email protected]

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-86


Use of DNS in MSS
 MSS provides three ways to configure the adjacent
SIP(-I) nodes:
– Static configuration
– Semi-dynamic configuration
– Dynamic configuration

 Depending on the preferred configuration mode, one or


more DNS queries may be triggered to resolve
information like remote host’s name, transport protocol,
server port number, and IP address.

 For this purpose, MSS supports DNS query types


‘NAPTR’, ‘SRV’, and ‘A’, as specified by RFC 3263.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-87


Static configuration
 In fully static configuration it is assumed that the operator has not
deployed a DNS infrastructure. RSI Type 1, Type 2 and Type 5 are
applicable.
 For RSI Type 1 and Type 5 NHOP remote host must be fully defined
(host name, transport protocol, server port number and one up to 16
IPv4 addresses), while for the DEST the host name is sufficient.
 For RSI Type 2 the DEST remote host must be fully defined
(host name, transport protocol, server port number and one up to 16
IPv4 addresses).
 Additionally the operator has to administer the SRC for IMS interworking

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-88


Semi-dynamic configuration
 In semi-dynamic configuration it is assumed that the operator wishes to
use only DNS A type of queries. RSI Type 1, Type 2 and Type 5 are
applicable.
 For RSI Type 1 and Type 5 NHOP remote host’s host name, transport
protocol and server port number must be fully defined, while IP address
is resolved via A query, where the input is NHOP (remote host’s host
name). For the DEST the host name is sufficient.
 For RSI Type 2 DEST remote host’s host name, transport protocol and
server port number must be fully defined, while IP address is resolved
via A query, where the input is DEST (remote host’s host name).

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-89


Dynamic configuration
 In dynamic configuration the operator wishes to use SRV and possibly
NAPTR DNS queries in addition to A query. RSI Type 6 is applicable.
 If the operator configures only the remote domain name, NAPTR (for
determining the preferred transport protocol in the domain) and SRV (for
determining the names of the servers in the domain which support the
preferred transport protocol obtained by NAPTR) are both executed in
addition to A query (for determining the IP address).
 If the operator configures the remote domain name and the preferred
transport protocol in the domain, NAPTR query is not executed and
SRV (for determining the names of the servers in the domain which
support the preferred transport protocol obtained by NAPTR) is
executed in addition to A query (for determining the IP address).

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-90


DNS Query Resolving

1. Local Table
 only A RR
 optional
 Up to 255 host name definitions
2. Local Cache
 Fixed size 255kB
 All types of RR are cached according to TTL of RR
 When cache is full oldest entry will be dropped
3. Name Server Query
 Up to 16 name servers (round robin)
 Organized in resolver groups per domains (1 to many)
 Selection via best match of suffix list
 Various parameters for performance tuning
 Wait limit, supervision timer, …

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-91


Operator Benefits
Using domain names makes the
configuration of remote entities
more comfortable and less error prone.

Example
SIP based interworking towards IMS requires
the configuration of routes towards the next
hop SIP Node (I-CSCF) in the IMS network.
To send the first SIP message (INVITE), the MSC-S has to know the IP
address, the port, and the transport protocol for the I-CSCF.
Instead of configuring all this information statically, it is sufficient that a
route has a domain name (e.g. @operator.com).
The rest can be derived dynamically with DNS queries:
– “NAPTR query”  transport protocol(s)
– “SRV query”  SIP Proxy’s (CSCF) host name and port
– “A query”  IPv4 address
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-92
All Dynamic Configuration :NAPTR,SRV
and A queries
Domain = ipnet.voip.org

NAPTR RR = udp_ server1.ipnet.voip.org


SRV RR = 5060 server1.ipnet.voip.org
A RR = IP1
A RR = IP2
SRV RR = 5231 server2.ipnet.voip.org
A RR = IP3
A RR = IP4

DNS

Destination
=“ipnet.voip.org”

TeS server1.ipnet.voip.org
MSC-S port=5060
MGCF
IP1
Route A IP2

Route A:
Domain: ipnet.voip.org
server2.ipnet.voip.org
port=5231
IP3
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-93 IP4
Dynamic Configuration : SRV and A
queries
Transport = udp
SRV RR = 5060 server1.ipnet.voip.org
A RR = IP1
A RR = IP2
SRV RR = 5231 server2.ipnet.voip.org
A RR = IP3
A RR = IP4

DNS

Destination
=“ipnet.voip.org”

server1.ipnet.voip.org
port=5060
TeS
IP1
MSC-S Route A IP2
MGCF

Route A:
Domain: ipnet.voip.org server2.ipnet.voip.org
Preferred Transport :UDP port=5231
IP3
IP4
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-94
Dynamic Configuration : A query
Server = server1.ipnet.voip.org
A RR = IP1
A RR = IP2
Server = server2.ipnet.voip.org
A RR = IP3
A RR = IP4

DNS

Destination
=“ipnet.voip.org”
Route 1
server1.ipnet.voip.org
Route 1:
port=5060
Domain: ipnet.voip.org TeS IP1
Preferred Transport :UDP MSC-S IP2
server1.ipnet.voip.org MGCF
(port=5060) Route 2
Route 2: server2.ipnet.voip.org
Domain: ipnet.voip.org port=5231
Preferred Transport :TCP
IP3
server2.ipnet.voip.org
port=5231 IP4

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-95


Static configuration (Non DNS) - Example

Destination
Route 1 =“ipnet.voip.org”

server1.ipnet.voip.org
TeS port=5060
IP1
MSC-S IP2
MGCF Route 2
Route 1:
Domain: ipnet.voip.org
Preferred Transport :UDP
server1.ipnet.voip.org
(port=5060) server2.ipnet.voip.org
IP1 port=5231
IP2 IP3
IP4
Route 2:
Domain: ipnet.voip.org
Preferred Transport :TCP
server2.ipnet.voip.org Note : In this example ,DNS is NOT used
port=5231 because the operator make static configuration
IP3
IP4 with all information necessary to routing the SIP protocol

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-96


Load sharing
› In case of static and semi-dynamic configuration, MSC-S
load shares among available routes/RSI within a SCI,
relying on existing NMS functions, similar to BICC and ISUP
protocols.
› In case of dynamic configuration, load sharing is based on
SRV procedures specified in RFC 2782:
if DNS returns SRV RRs with a list of servers with the same
priority and different weights, then for each new outgoing
call, MSC-S will select a server based on the randomized
weights.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-97


Failover Procedures (No DNS)

Route re-selection

IP 1

INVITE
500

TeS
INVITE
MSC-S
IP 2
MGCF

200 OK

IP3

Alternate IP address

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-98


Failover procedures (DNS)

Server re-selection
DNS

IP 1

INVITE
500

TeS
INVITE
MSC-S
IP 2
MGCF

200 OK

IP3

Alternate IP address

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-99


DNS Configuration (I)

› The VIF interface ETHA-433 and ETHB -433 must be defined previously. Will
be explained further.

DNS 1
TeS IP: 10.138.10.168
MSC-S
MGCF
› Define first routing towards DNS1.

› IHRHC:VIF=ETHA-433, ADD, DEST=10.138.10.168,


NETMASK=255.255.255.255, GW=172.34.22.65, PREF=255;

› Define second routing towards DNS1.

› IHRHC:VIF=ETHB-433, ADD, DEST=172.34.7.212,


NETMASK=255.255.255.255, GW=172.34.22.66, PREF=255;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-100


DNS Configuration (II)
DNS Group 1
› Define DNS groups. ! DNS Group 1 !
› IHRGI: NSGID=DNSG01;
DNS 1
› IHRPC: NSGID=DNSG01, PRIOR=1; TeS
MSC-S
MGCF
› ! DNS Group 2 !

› IHRGI: NSGID=DNSG02; DNS Group 1


› IHRPC: NSGID=DNSG02, PRIOR=2;
DNS 1
TeS
MSC-S
› IHRHP:VIF=ETHA-433; MGCF

› IHRHP:VIF=ETHB-433;
DNS 2

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-101


DNS Group 2
DNS Configuration (III)
› Define/Modify a DNS Server in the DNS Group. DNS Group 1

› IHRGC:NSGID=DNSG01, NSIP=10.138.10.168; DNS 1


› IHRGC:NSGID=DNSG01, SUFFIX="COM"; TeS
MSC-S
MGCF

DNS Group 1

DNS 1
› IHRGC:NSGID=DNSG02, NSIP=172.34.7.212; TeS

› IHRGC:NSGID=DNSG02, SUFFIX="COM"; MSC-S


MGCF

DNS 2

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-102


DNS Group 2
DNS Configuration (IV)
› Configure DNS Server properties.

› IHRPC: OTIM= 6;
› IHRPC: NSGID=DNSG01, NSID=NS01,SUPTM=20; DNS Group 1
› IHRPC: NSGID=DNSG01, MAXTM=1000;
› IHRPC: NSGID=DNSG01, MINTM= 500; DNS 1
› IHRPC: NSGID=DNSG01, REATG= 2; TeS
› IHRPC: NSGID=DNSG01, REATNS= 5; MSC-S
MGCF
› IHRPC: NSGID=DNSG01, NDOTS= 1;

› ! Check the states of the Name Servers. They should be ALIVE.


› IHRPP:NSGID=ALL;

› The Same Configuration apllies to DNS Group2

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-103


DNS Resolver, Setup
<IHRTP:HOST=ALL;
DNS RESOLVER LOCAL TABLE DATA

LTID HOST NAME IPADDRESS


0 NS01.NIV 172.23.47.126
1 SIP.MSC300.NIV 172.23.47.70
2 SIP.MSC600.NIV 172.23.47.6

END

<IHRGP:NSGID=ALL;
DNS RESOLVER NAME SERVER GROUP DATA

SERVER GROUP NAME: DNSG01

NAME SERVER LIST:


NS01 172.23.47.126

SUFFIX LIST:
.
.NIV

END
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-104
DNS Resolver, Parameters
<IHRPP:NSGID=ALL;
DNS RESOLVER PARAMETER DATA

RESOLVER PARAMETERS:
STATE OTIM
ENABLE 6

NAME SERVER GROUP PARAMETERS:


NSGID PRIOR MAXTM MINTM REATG REATS NDOTS
DNSG01 3 1000 500 2 5 1

NAME SERVER PARAMETERS:


NSGID NSID NSIP SUPTM NS STATE
DNSG01 NS01 172.23.47.126 20 DEAD

END

<IHRUP;
DNS RESOLVER SEARCH SUFFIX DATA

DEFAULT SUFFIX: NIV

END

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-105


Commands for DNS Resolver

IHRCI: IP Transport, Resolver Cache, Initiate


IHRCC: IP Transport, Resolver Cache Configuration, Change
IHRCE: IP Transport, Resolver Cache, End
IHRCP: IP Transport, Resolver Cache Configuration, Print
IHRGI: IP Transport, Resolver Name Server Group, Initiate
IHRGC: IP Transport, Resolver Name Server Group, Change
IHRGE: IP Transport, Resolver Name Server Group, End
IHRGP: IP Transport, Resolver Name Server Group, Print
IHRLI: IP Transport, Resolver Local Table Lookup, Initiate
IHRLE: IP Transport, Resolver Local Table Lookup, End
IHRLP: IP Transport, Resolver Local Table Lookup, Print
IHRPC: IP Transport, Resolver Parameter, Change
IHRPP: IP Transport, Resolver Parameter, Print
IHRTI: IP Transport, Resolver Local Table Identity, Initiate
IHRTE: IP Transport, Resolver Local Table Identity, End
IHRTP: IP Transport, Resolver Local Table Identity, Print
IHRUI: IP Transport, Resolver Search Suffix, Initiate
IHRUE: IP Transport, Resolver Search Suffix, End
IHRUP: IP Transport, Resolver Search Suffix, Print

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-106


ENUM Look up for Number Portability
FEATURE IN SHORT
› Fetching of Number Portability (NP) data from an ENUM (E.164
Number Mapping) Data Base with a DNS query
– The MSC interacts with an ENUM node using the DNS/ENUM
protocol.
– The NP data is received as Tel-URI and SIP-URI (with
User=Phone) as E.164 number.
– The feature can co-exist with the design base Number
Portability functions and is applicable for all control plane
signaling protocols ISUP, BICC, SIP and SIP-I

Customer Benefits:
ENUM is the the GSMA recommended Unified Solution that
› Operators can modernize the NP-solution wich requires the support for ENUM-
queries
› Unified solution - a common Number Portability solution for different services
› Provides a structured and hierarchical way of handling Number Portability with
flexibility to use for other purposes e.g. routing optimization
› A common and future proof Number Portability solution: Used by IMS/VoLTE
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-107
ENUM Look up for Number Portability
1(2)
or "E2U+pstn:sip“
ENUM "!^.*$!sip:+46-70-8123;npdi;

DB [email protected];
NAPTR RR user=phone!"
2 3
"E2U+pstn:tel“
NAPTR query "!^.*$!tel:+46-70-8123;npdi;
Ported
(3.2.1.8.0.7.6.4.e164.arpa) rn=+46-98!"
subscriber

1 call set-up request 5 INVITE tel:+46708123


Recipient
CdPN: 46708123 npdi;rn=+4698
(SIP or SIP-I) /subscription
MSC-S
or network
Routing based on telephone number
4
(or network prefix) information INVITE sip:+46708123 - Encoding of NP parameters
received from ENUM in “rn” parameter
npdi;[email protected]; - Prefixed number, or just prefix,
of the URI + transfer of URI data
transparently to the o/g trunk user=phone is carried in “rn”
- sip URI host data transparency

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-108


ENUM Look up for Number Portability
2(2)

ENUM
DB NAPTR RR:
" E2U+pstn:tel“
A) "!^.*$!tel:+ 46708123;npdi;rn =+46 98708123!"
2 3
NAPTR query:
" E2U+pstn:tel“
B) "!^.*$!tel:+ 46708123;npdi!" Ported
3.2.1.8.0.7.6.4.e164.arpa
subscriber

SIP: INVITE Recipient


A) tel:+46708123;npdi;rn=+ 4698708123
call set- up request /subscription
1 or
CdPN: 46708123 ISUP: IAM (CdPN = 98708123) network
MSC-S

INVITE tel=708123;npdi
B) SIP:
or
ISUP: IAM (CdPN = 708123)
Not ported
subscriber

(G)MSC
/VLR

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-109


UG: Managing ENUM Look up for Number
Portability
› The managed objects used to configure the ENUM Look up for Number
Portability function and the relations between them are :

triggers DNS/ENUM indicates the query


interrogation type RN or NRN

locate the DNS/ENUM


database determines MSC-S
query behavior

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-110


Commands
DQENI DATABASE QUERY, ENUM TRIGGER, INITIATE
- The command initiates an ISK value to trigger ENUM query and its associated
data. The ISK value is tied to the B-number analysis

DQENE DATABASE QUERY, ENUM TRIGGER, END


- The command removes the defined ISK value and its associated Data

DQENC DATABASE QUERY, ENUM TRIGGER, CHANGE


- The command changes the ISK data once defined with command DQMNI

DQENP DATABASE QUERY, ENUM TRIGGER, PRINT


- The command prints the ISK data once defined with command DQMNI

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-111


DQENI command parameters
PARAMETER DEFINED: USED:
NAME:

ENUMT DQENI In B-number analysis as ISK.

SERVT DQENI It is the service filter. Defines for


which ENUM resolution services
to look in ENUM response.

BO DQENI In B-number pre-analysis for


deriving OBA. Ported and not
ported cases will be analysed
there after the query.

DNAME DQENI To form the domain name to be


resolved in DNS.

REPN DQENI to handle rn from ENUM


response either as a prefix or as
a complete number

RO DQENI In Route Analysis as branching


condition.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-112


Originating Query on Digit Analysis

› OQoD
ENUM HLR
DB Ported
subscriber

2. ENUM query 4. MAP 5. MAP

A B

1. call set-up 3. call set-up 6. call set-up


request (ISUP/ (ISUP/ MSC-S
MSC-S GMSC-S /VLR
SIP-I) BICC/
Originating SIP-I) Serving
& Interrogating switch
switch
Originating network Recipient network

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-113


OQoD configuration example
› 1- Before introducing of ENUM Look up › 4- The numbers which are received from
for Number Portability function the the DNS/ENUM database as rn parameter
existing routing case 6 was defined as must be administered in B-nr.Analysis
follows (the SP=MM1 means that the after the querying of DNS/ENUM database.
complete B-number must be received For ported numbers the B-number Analysis
before routing): leads to the routing alternative towards
ANRSI:RC=6,R=GRI03,SP=MM1; the recipient network. For not ported
numbers the B-number Analysis leads
towards an HLR interrogation route.
› 2- With the introduction of ENUM Look
› 5-The BO in DQENI command for ENUMT-1
up for Number Portability function
was set to value 2, and OBA in pre-
Route Analysis before DNS/ENUM
analysis is set to value 15 for the
database query is defined as follows:
national numbers (B-Number Type = 4).
ANRPI:RC=7; National numbers are provisioned in the
ANRSI:P01=1,R=DBQENP1,SP=MM1; DNS/ENUM.ISUP or BICC is as outgoing
ANRSI:P01=2,NRC=6; trunk.

ANRPE; PNBSI:BO=2,BNT=4,OBA=15;
ANBSI:B=15-708,RC=6;
› 3- The analysis of DN 708123 which ANBSI:B=15-#1495708,RC=9;
is regarded as portable results in › RC 9 is a routing case toward the
RC=7. The ISK=ENUMT-1 is an recipient network and it is expected to
additional analysis result. be already defined in the node as
ANBSI:B=0-708,ISK=ENUMT-1,RC=7,BNT=4; follows:
ANRSI:RC=9,R=ROUTG2,SP=MM1;
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-114
Terminating Query on Digit Analysis

› TQoD

ENUM HLR
DB Ported
subscriber

2. ENUM query 4. MAP 5. MAP

1. call set-up 3. call set-up 6. call set-up


(ISUP/ (ISUP/ (ISUP/ MSC-S
MSC-S GMSC-S GMSC-S /VLR
SIP-I) SIP-I) BICC/
Originating Interrogating SIP-I) Serving
switch switch switch

Originating network Donor network Recipient network

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-115


Query on HLR Release

› QoHR
HLR ENUM HLR
DB Ported
(3) ENUM query is done subscriber
only if HLR returns
“unknown subscriber”. 2. MAP 3. ENUM query 5. MAP 6. MAP

1. call set-up 4. call set-up 7. call set-up


(ISUP/ (ISUP/ (ISUP/ MSC-S
MSC-S GMSC-S GMSC-S
BICC/ /VLR
SIP-I) SIP-I)
Originating Interrogating SIP-I) Serving
switch switch switch

Originating network Donor network Recipient network

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-116


Transit Query on Digit Analysis

› TrQoD ENUM

HSS
ENUM
DB I-CSCF
/IBCF ( IMS )
2.
ENUM query (SIP)

HLR

3. call set-up
Originating (ISUP/ GMSC-S
1. call set-up
Network (ISUP/ TSC-S SIP-I) (mobile)
(fixed, mobile or IMS) /CTC
BICC/
SIP-I/ Interrogating Operator 1
SIP) switch
(SIP) ENUM

Interconnect HSS

(ISUP/
operator I-CSCF
SIP-I) /IBCF ( IMS )

HLR

GMSC-S
(mobile)

Operator 2

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-117


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-118
SIP/SIP-I Advanced in MSS15

SIP with ISUP encapsulation (SIP-I)


Objectives

Explore SIP with ISUP encapsulation (SIP-I)

› Compare SIP-I, SIP-T and BICC protocols in MSS


› Present SIP-I and ISUP Interworking
› Explain how SIP-I can fallback to BICC using ASNEE
› Use the ISUP MIME encapsulation body
› Recognize some Interworking traffic cases

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-120


VoLTE uses both Gm and I1 interfaces
› Gm is end-to-end, while I1 is between UE and Server.
App Servers
Client – Server
I1 SIP Communication
[SIP] via VoLTE Platform SCC-AS MTAS

VoLTE Platform

App Client
MME PCRF IMS
Gm Payload
[SIP] [IP]

S-GW P-GW Payload M-MGw


eNodeB [IP]

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-121


VoLTE lacks Mobility between operators
› MAP, BICC and SIP-I provide Mobility for 2G, 3G & 4G.

E & Nc
A, Iu & SGs A, Iu & SGs
[NAS] [MAP, BICC [NAS]
MSC-S MSC-S
& SIP-I ]

I1 Lacking I1
[SIP] Mobility [SIP]
App Client App Client

Ici (Gm)
Gm Gm
[SIP]
[SIP] [SIP]
Izi
[RTP]

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-122


SIP-I is defined by ITU in Q.1912.5
› The SIP-I protocol is called “Encapsulated ISUP”, but has
nothing to do with the correct protocol name:
Interworking between SIP and BICC protocol or ISUP
http://www.itu.int/rec/T-REC-Q.1912.5-200403-I/en

Mail load over SIP - This is the reason why it is called “encapsulated”

MIME ISUP
SIP-I BICC
MSC-S SDP APM MSC-S

MGw Negotiation GCP GCP


as BICC does in APM M-MGw SIP-I = BICC
adding DNS
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-123
SIP-T is defined by ISOC in RFC 3372
› The problem with SIP-T is that it was limited to SIP-ISUP
interworking, and did not consider the APM messages in
BICC. http://tools.ietf.org/html/rfc3372 (& http://tools.ietf.org/html/rfc3398)

SIP-T will not be explored further in this course

Mapping
MIME ISUP
SIP-T
MSC-S SDP MSC-S

› SIP-T is an early SIP-I, that could translate basic ISUP to SIP (same as SIP-I).
But SIP-T replaced ISUP, while SIP-I also tunnels original ISUP messages.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-124


ISUP without TDM is used in BICC & SIP-I
› ISUP without TDM: Both the Routing Label and Circuit ID
Code from ISUP are skipped in both BICC and in SIP-I.
http://www.itu.int/rec/T-REC-Q.1901/en http://tools.ietf.org/html/rfc3204

RFC3204 - MIME media types for ISUP and QSIG Objects

ISUP without TDM


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-125
SIP-I is “BICC over SIP”
› The “ISUP without TDM” messages in BICC, are transported
transparent in MIME or Secure MIME (S/MIME) using SIP-I.
› This is the benefit with SIP-I compared with SIP-T, since
ISUP is so different between many countries and regions.
BICC
SDP APM

BICC
Transparent
SIP-I

Tunneling*
S/MIME MIME “ISUP without TDM”

SIP M3UA

Optional TLS Optional TLS

TCP or SCTP SCTP

IP

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-126


SIP-I Signaling Profiles

To be 100%
strict, it is only
Profile C, that
is defined as
SIP-I.

Profile A & B are


like SIP-T
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-127
SIP-I – Recommended Payload Protocols

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-128


SIP-I Roaming is guided by GSMA
› IR.83 guides operators how to use SIP-I between them
› http://www.gsma.com/newsroom/ir-83-v1-2-sip-i-interworking-description

› Purpose of the document is to illustrate a generic SIP-I profile to be used for the
Packet Voice Interworking over the IPX between different mobile and fixed
Service Providers, aiming to limit the number of interoperability issues caused by
different implementation and deployment solutions used. Thus the features
needed for a successful interoperability of SIP-I Node & MGW (Media Gateway)
network elements being used in multi-operator, multi-vendor end-to-end
environment. (GSMA IR.83 v1.2 2009)

› GSMA clarifies some 3GPP and RFC references, but not all.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-129


SIP-I is not clarified for latest SIP RFCs

Original SIP-I Profile C/00 Profile C/1.2


References ITU 2004 IR.83 2009
RFC 2046 (MIME Media Types) Supported Supported
RFC 2327 (SDP) ‐ Obsoleted by RFC 4566 Supported See 4566
RFC 2806 (tel URI) ‐ Obsoleted by RFC 3966 Supported See 3966
RFC 2976 (INFO) Supported Required
RFC 3204 (MIME media types for ISUP) Supported Supported
RFC 3261 (SIP) Supported Supported
RFC 3262 (PRACK) Optional Required
RFC 3264 (Offer/Answer Model with SDP) Supported Supported
RFC 3311 (UPDATE) Supported Required
RFC 3323 (Privacy mechanism) ‐ Required
RFC 3325 (Private Extensions) Supported (Not mentioned)?
RFC 3326 (Reason Header Field for SIP) Supported Supported
RFC 3966 (tel URI).  See 2806 Supported
Until 3326
RFC 4028 (Session Timers) ‐ (New) Optional
Today exist
RFC 4566 (SDP) See 2327 Supported
double more
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-130
IANA has a good overview about SIP
› But no one has a good overview about SIP-I (as of today)
› http://www.iana.org/assignments/dnskey-flags
› http://www.iana.org/assignments/dns-key-rr
› http://www.iana.org/assignments/dns-parameters
› http://www.iana.org/assignments/dns-sec-alg-numbers
› http://www.iana.org/assignments/dnssec-nsec3-parameters
› http://www.iana.org/assignments/dns-sshfp-rr-parameters
› http://www.iana.org/assignments/media-control-channel
› http://www.iana.org/assignments/media-feature-tags
› http://www.iana.org/assignments/media-types/index.html
› http://www.iana.org/assignments/media-types-parameters
› http://www.iana.org/assignments/media-type-structured-suffix
› http://www.iana.org/assignments/media-type-sub-parameters
› http://www.iana.org/assignments/sdp-parameters
› http://www.iana.org/assignments/sdp-security-descriptions
› http://www.iana.org/assignments/sip-clf-parameters
› http://www.iana.org/assignments/sip-events
› http://www.iana.org/assignments/sip-parameters
› http://www.iana.org/assignments/sip-precond-types
› http://www.iana.org/assignments/sip-priv-values
› http://www.iana.org/assignments/sip-table
› The list can be made longer

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-131


GSMA needs to update the SIP-I Profile
› Since each new/updated/obsoleted RFCs can impact on the
Operator’s business, there is a need to decide when
the SIP-I profile needs to be updated to reflect new RFCs.

Missing Trigger IR.83


IANA GSMA
SIP-I

New or
Updated
or Obsoleted 3GPP
RFC

$ Operators Vendors

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-132


SIP Route Options using RGPAR
› There are many SIP parameter to handle all options:
Example: (As of MSS 13A)
› BCIND, BYEED, CGPNPRN, CHINFO, CI, DEEX, DNSEF,
FCIND, FEC, FLBL, FSUSRES, G729ABO, GCR, HCP,
HEADFNF, HNPCN, HOPFACT, HRTCP, ICP, IDA,
INCLRLC, INFU, MAXCALA, MAXCALL, MAXSIM,
MAXSIMA, MLPPUI, NF, NFAILA, NOGN, NPAPRI,
OCTALGN, PCMLAW, PRECOND, PREFURI, PROPDLS,
PROPDLY, PTAMRS7, PTAMRWB, PTCLRMD, PTEFR,
PTFRS1, PTG729, PTHRS1, PTPCM, PTSDP, REQURI,
RSIID, RSNTY, SCI, SIPPREF, SPCMLAW, T38FAX,
T38REIN, TEXIT, TIA, TRUSTPL, UPDCD, URITYPE,
VERFORM, WIBE (There are also other parameters)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-133


Example with DEEX & TEXIT
› SIP-I can fallback to BICC, if there is an alternative route.
› The fallback is measured if the response to INVITE delays
more than TEXIT seconds. DEEX can disable the fallback.

BICC Fallback Also called Early Exit

SIP Network BICC Network

IP Network

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-134


MGCF in MSC-S enables an interconnect
based on IP transport technology

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-135


ISUP parameters translated to SIP
headers according to Q.1912.5

› Called party number


› Calling party number
› Generic number (“additional calling party number”)
› TMR
› USI and HLC information element within Access Transport
Parameter
› Hop counter
› Cause indicators

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-136


ISUP to SIP mapped to SIP information
according to Q.1912.5

› Request-URI user info


› To
› From
› P-asserted ID
› Privacy
› SDP body
› Max-Forwards
› Reason header

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-137


Softswitch Interworking

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-138


SIP-I: the INVITE message body
Message body
MIME Multipart Media Encapsulation,
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): -
Session Name (s): -
Connection Information (c): IN IP4 192.168.162.213
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 4110 RTP/AVP 8
Media Type: audio
Media Port: 4110
Media Proto: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Attribute (a): rtpmap:8 PCMA/8000
Encapsulated multipart part
ISDN User Part
Message type: Initial address (1)
Nature of Connection Indicators: 0x11
Forward Call Indicators: 0x6000
Calling Party's category: 0xa (ordinary calling subscriber)
Transmission medium requirement: 3 (3.1 kHz audio)
Called Party Number: 9440000
Propagation delay counter = 47 ms
Calling Party Number: 9450001
Parameter compatibility information (2 bytes length)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-139


SIP-I to ISUP Interworking
MSC-S/ MSC/PSTN
PSTN / MSC
# SIP -I MGCF
INVITE (SDP , IAM) # ISUP
100 Trying

IAM

I83 Session Ringing


(SDP)

ACM ( Subscriber free)


I80 Ringing (ACM)

ANM
200 OK INVITE (SDP,ANM)

ACK

Note : Since reliable provisional responses are not supported, 200 OK INVITE includes , the same
SDP answer as already sent in 183 Session Progress

Successful Call Set-up Procedure, CC ( Continuity Check ) Not Performed,


183 Session Progress with SDP Answer, No Reliable Provisional Response
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-140
ISUP to SIP-I Interworking
MSC / # ISUP
MSC-S/ I-CSCF
# SIP-I
SIP
PSTN MGCF
IAM
INVITE (SDP,IAM)

100 Trying

I80 Ringing (SDP,ACM)

ACM ( Subscriber free)

200 OK INVITE (SDP,ANM) note

ANM

ACK

Note:The SDP answer in 200 OK INVITE must be the same as already sent in 180 provisional response,
Otherwise call is released with BYE message

Successful Call Set-up Procedure, CC not Performed, 180 Ringing with or without SDP,
No Reliable Provisional Response
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-141
BICC to SIP-I Interworking
# BICC
MSC-S/ PSTN/MSC-S
MSC-S MGCF # SIP-I

IAM (fw, no COT inc)

APM ( no Notif Req)

APM ( Request)
APM ( Accepted)
INVITE (IAM, SDP offer)

100 Trying

I80 Ringing (ACM)


ACM ( Subscriber free)
200 OK INVITE (ANM,SDP answer)

ANM
ACK

Successful Call Setup Procedure, Delayed Forward Bearer Setup, No COT


Indication, 180 Ringing with or without SDP, No Reliable Provisional Response
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-142
SIP-I to BICC Interworking 1(2)
MSC-S/ # SIP-I MSC-S/ MSC-S
MGCF # BICC
PSTN INVITE (IAM,SDP offer)
100 Trying
I83 Session Progress
(SDP) IAM (bw , COT ind)
APM (Request)

PRACK APM (Accepted)

200 OK PRACK Successful Call Setup


COT Procedure,
ACM ( No indication) Delayed Backward Bearer
I83 Session Progress (ACM) Setup,
INVITE with SDP Offer,
PRACK Reliable Provisional Response,
200 OK PRACK Early ACM
CPG (alerting)
180 RINGING (CPG)
PRACK
200 OK PRACK ANM
200 OK INVITE (ANM)

ACK

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-143


SIP-I to BICC Interworking 2(2)
MSC-S/ # SIP-I MSC-S/ MSC-S
MGCF # BICC
PSTN
INVITE (IAM,)

100 Trying
IAM (fw , no COT ind)

APM (fw)
APM (fw , Request)
APM ( Accepted)
APM (Connected)
ACM
180 RINGING (ACM) Successful Call Setup
Procedure,
ANM Delayed Forward
200 OK INVITE (ANM,SDP ofter) Bearer Setup,
INVITE without SDP
ACK (SDP answer) offer,
No Reliable
Provisional Response

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-144


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-145
SIP/SIP-I Advanced in MSS15

IP Connectivity support in MSC-S for SIP


Objectives

Clarify IP Connectivity support in MSC-S for SIP/SIP-I/DNS

› Introduce SIP/SIP-I Single Node View feature


› Clarify the IP connectivity for MSC-S DB and MSC-S BC
› List the main steps in setting up L2 infrastructure for SIP
› Describe the IP stack on CP implementation
› Explain the supervision and IP Layer failover mechanisms
› Configure IP stack on CP

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-147


CP types

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-148


Single node view for SIP(-I) in
MSC-S BC Benefits
– OPEX Reduction
– MSC-S BC seen as one SIP(-I)
node in the network
Description
– Increasing MSC-S BC capacity by
 The feature’s scope is to adding MSC blades will not
introduce a SIP level require reconfiguration on network
level
distribution for incoming
SIP/SIP-I traffic. – ISP Improvement
– Higher volumes of SIP(-I) traffic
– MSC-S Blade Cluster supports will be supported in MSC-S BC
one-IP-node view for incoming – The MSC-S BC will react more
SIP(-I) traffic robust on changes of the traffic
– An MCS-S BC internal profile in the network.
distributor distributes incoming – MSC-S BC failures are not visible
towards external interfaces
SIP(-I) traffic between the
– Remote nodes do not have to
blades
support fail over functionality
– Minimum SIP(-I) Traffic
Disturbance during MSC-S BC
Upgrade
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-149
SIP/SIP-I Configuration sequence
› Configuration in MSC-S
– Ethernet Layer Configuration
– IP stack Configuration
– Configuration of DNS resolver
– Configuration of SIP/SIP-I
– Number conversion in SIP or SIP-I
– B-number and Routing analysis

› Configuration in M-MGW
– M-MGw signaling configuration
– Media Stream Processing configuration in M-MGw, and
– M-MGw IP transport configuration

› Configuration in DNS Server


– Zones, master and slave DBS servers (is out of the course scope)

› Configuration issues affecting multiple network elements


– To align certain capabilities and configuration aspects between MSS, DNS Server,
IP backbone, remote SIP peer respectively SIP-I peer and RTP peer.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-150


Pre-requisites, Requirements and
Preparations
› HW installation is completed and checked

› Required functions, features, and accompanying licenses have been ordered


and activated in the relevant nodes

› Software package required for SIP/SIP-I Interworking up and running


.
› Network Design completed reviewed and approved by customer.

› MPBN network architecture, dimension and QoS auditing

› Check SIP/SIP-I protocol conformance Ericsson and non-Ericsson equipment in


order to avoid potential interworking problems. The protocol conformance
should be verified during migration with appropriate test calls towards the
peering nodes or networks

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-151


IP-stack support on MSC-S

› Integration of MSC-S Blade Cluster into IS or BSP platforms


– Based on blades, without RPs
– Providing full scalability by adding common blades
instead of dedicated signaling boards

› IS and BSP based cluster systems only differ regarding the infrastructure used
– Configurations of IS or BSP VLAN database must be performed

› Share IP/site infrastructure equipment

› CP-capacity is not the limiting factor anymore

› RPs (GARPs) can be avoided

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-152


MSC-S IP-stack on CP Delivery and Plans
› Traditionally the IP-stack for signaling in the MSC-S was located on the
SIGTRAN Link Interface cards (SLI) – GARP board

› In MSC-S Dual Blade the IP-stack for SIP and SIP-I is placed on the CP. The
IP-stack for SIGTRAN remains on the SLI – GARP board.
– A pair of GESB boards with ESS function is put between CP and the outside IP network.
The main function of the ESS is to perform shielding and VLAN separation.

› Also SIGTRAN makes use of the IP-stack on the CP for the MSC-S Blade
Cluster Solution

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-153


IP-stack on CP & IP-stack on RP (MSC-S
Dual Blade)

CP RP

SIP(-I) DNS GCP M3UA IUA


TCP/UDP SCTP
IP IP

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-154


IP-stack on CP (MSC-S Blade Cluster )

CP

SIP(-I) DNS GCP M3UA IUA

TCP/UDP/SCTP
IP

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-155


Physical Interfaces - APZ 212 60 (MSC-S
DB)

SIP
SIP

SIGTRAN

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-156


Preparation for IP Stack on CP
Configuration
› 1) Preparation of the site LAN switches
Prepare the LAN switches that the MSC node is to be connected to for ensuring the
MSC system integrity

› 2) Configuring the Ethernet Switching Planes


The MSC internal switching planes are configured such that the application signaling
traffic can properly be traversed through the system

› 3) Ethernet Interface Configuration


The Ethernet interfaces of the MSC to be used for the IP signaling application are
configured

› 4) Route Configuration
IP routes are configured such that the MSC node can properly utilize the fault resilient
LAN configuration

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-157


Example of ESSB Configuration with APZ
21250
SCB-RP GESB - I GESB-- E
GESB telnet APG43
host
-A
+ESSB + L3X ESSB + L3X
+- A
( default configuration) ( site configuration)

Port Port
0 1 2 6 7 7 6 2 0

CPSB-B
CPSB-A SIP O&M
1. O&M connection to APG43
2. telnet to host on GESB-E / ESSB or Define GESB-E as RP (Connect via
command TERDI)
3. Configuration of ESSB
• VLAN #1 (Default) – Untagged, legacy traffic; port 2 excluded
• E.g. VLAN 304 tagged traffic; aligned with ETHA-/ETHB-304
4. After legacy traffic is blocked on port 2, external network may be connected
(CP crash if legacy traffic of plane-A and plane-B is short cut)
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-158
ESSB – 802.1Q VLAN Settings (Example
of Printout to show VLAN configuration in
ESSB)
! 802.1Q VLAN table
switchdrv read qvlan -a

OSmon> switchdrv read qvlan -a

VTABLE_entry : 0
VLAN_TAG : 0
Port Members : -
Out Untag Ports : -

VTABLE_entry : 1
VLAN_TAG : 304
Port Members : 2 7
Out Untag Ports : -

VTABLE_entry : 2
VLAN_TAG : 4095
Port Members : -
Out Untag Ports : -

...
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-159
ESSB – Port Based VLAN Settings
! Port based VLAN table
switchdrv read pvlan -a

OSmon> switchdrv read pvlan -a

PORT : 0
VLAN_TAG : 1
Port Members : 0 1 3 4 5 6 7
Out Untag Ports : 0 1 3 4 5 6 7
RJ flag unset

PORT : 1
VLAN_TAG : 1
Port Members : 0 1 3 4 5 6 7
Out Untag Ports : 0 1 3 4 5 6 7
RJ flag unset

PORT : 2
VLAN_TAG : 304
Port Members : 2 7
Out Untag Ports : -
RJ flag set

...
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-160
Separate VLANs for SIP and DNS

› Example:

› SIP and DNS


use separate
VLANs.

› Different VLANs
for Signaling
and Payload.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-161


Security for IP on CP

MSC-S

CP-A ESSB
Switch Router
IP/MPLS Backbone

CP-B ESSB
Switch Router

Site Equipment
• Packet filters on L2,3,4
IP stack on CP • VLAN separation
• UDP, TCP, DNS Ethernet Switch & Shielding Board • Rate limiting
• Possibility to join VLANs • VLAN separation for protection
• Ethernet port setting

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-162


IP-stack services

Transport Service
Autonomous
System Number

DNS Service

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-163


IP on CP in MSC-S with APZ 212 50/60

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-164


IP addresses & L2 Interfaces
CP = APZ 212 40/50/60
PingA PingB

ETHA-304 ETHB-304

ETHA ETHB

MSC-S
Monitoring Address

Application Address

Site Site
Router Router

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-165


IHIFP, Virtual Ethernet Interface Data
<IHIFP:VIF=all;
VIRTUAL ETHERNET INTERFACE DATA

VIF DID STATE MTU HWADDRESS


ETHA-304 2 UP 1436 00-13-5E-E9-3F-92

IP NETMASK ARP
10.87.64.200 255.255.255.192 YES

VIF DID STATE MTU HWADDRESS


ETHB-304 3 UP 1436 00-13-5E-E9-3F-93

END

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-166


Router Supervision
› In case that Router Supervision detects that none of the
defined gateways is reachable, the IP address will be
migrated from ETH-A to ETH-B.

IP IP
Ping A Prim. GW
ETH-A

IP
1

CP
ETH-B

IP IP
Ping B Sec. GW

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-167


IHRSC, Route Supervision Settings

› Add, Change and Delete Router Paths for Supervision

Format 1
IHRSC: [SVRATE=svrate] [,SVTO=svto]
[,SVMAXTX=svmaxtx] [,SVMINRX=svminrx]
[,SVI=svi] [,SVR=svr];

Format 2
/ \
|,ADD, GW=gw |
IHRSC:VIFP=vifp +,DEL, GW=gw +;
|,IPMIGR=ipmigr |
|,HOFF=hoff |
\ /
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-168
IHRSP, Router Supervision Data
WO 6UCDE6CD2CI06ADTE108 AD-376 TIME 110824 1634 PAGE 1
<IHRSP;
ROUTER SUPERVISION DATA

SVRATE SVTO SVMAXTX SVMINRX


10 3 2 2

SVI SVR
65 82

VIFP IPMIGR HOFF TTL


ETH-304 YES 5 1

IP NETMASK HOME NOW


10.87.64.200 255.255.255.192 ETHA-304 HOME

PINGA PINGB
10.87.64.201 10.87.64.202

GW STATE
10.87.64.194 WO
10.87.64.195 WO

END
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-169
IHRHP, Routing Table
<IHRHP:vif=etha-304;
ROUTE HANDLING

VIF IP SUBNET
ETHA-304 10.87.64.200 10.87.64.192

DEFGW PREF
10.87.64.194 255
10.87.64.195 125

DEST NETMASK
10.101.251.0 255.255.255.0
GW PREF SOURCE
10.87.64.194 255

END

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-170


MSC-S BC Physical Connectivity

Resilient L2 Switch (back plane)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-171


VLAN Overview

TSC
APUB TSC
APUB AS (SPX+APG) IS Site
MSC
MSC
MSC
GARP CPUB SIS
SIS
GARP CPUB

OPTIONAL
External O&M
bypassing IS SCB IPLB
EXB IPLB
MXB not shown

Externally Inaccessible VLANs Externally Accessible VLANs


INT-IS-CTRL AXE-DEF SIG OAM (ISNB)
ISBS, ISOB, ISOS, MSC Application Cluster External Signalling through External O&M Traffic to
ISLCS, ISNB Control Between Blades SCTP OSS etc..
INT-SIG APZ-A + APZ-B SIP OAM (OPTIONAL)
Internal Signaling Internal Boot+ O&M External SIP Traffic External O&M Traffic to
through SCTP APUB ? CPUB OSS etc... If chosen,
CPUB ? TSC /MSC APUB ? TSC /MSC DNS replacing AS part of OAM
External DNS Traffic (ISNB).
APZ-CH APZ-C2C
Cluster Handler Protocol BSOM Mastership Coord.
Group Communcation CPT Trouble Shooting Untagged or otherwise limited VLAN
or P-Bit support (see Appendix B)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-172


MSC Blades to or from External Network
(SIP)

Ethernet
Ethernet
Link
Aggregation
Group(LAG)
Static Route

BFD Session

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-173


IS Network Configuration VLANs
VLANs manually defined
in the MSC blades:
› SIP
› DNS 1

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-174


› In blade cluster system it is possible to use Base IP addresses:
– The actual Application IP address assigned to the CP blade is called an Automatic IP
address.
– It is calculated as such: Automatic IP address = Base IP address + CP ID.
› It is however possible to define specific Application IP addresses directly
on a certain virtual interface of a CP blade without using Base IP
address.
– In this way the user can configure all CP blades with wanted Application IP addresses,
e.g. for use with a load balancer.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-175


Configuration example of SIP

MSC-S BC Site

MMSS
CC
193.180.16.1...10/26 193.180.16.61/24 (Front port IP A)
MSC-S
193.180.16.1...10/26 (MSC Blades, SIP)
193.180.16.61/26
MSC-S
AS (SPX1) IS (Backplane IP A)

SCB EXB MXB IPLBA


SE1
L2 Switch 1
CPUB
CPUB
#0
Backbone

SCB EXB MXB IPLBB L SE2


L2 Switch 2
193.180.16.62/26
1A
APUB (Backplane IP B) 193.180.16.62/24 (Front port IP B)
1B
APUB
C
MS

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-176


Interface and Address Configuration
IHIFI: NVIF=BC-SIP;

IHIFC: NVIF=BC-SIP, ADD, BASEIP=193.180.16.1


NETMASK=255.255.255.192, ARP=YES;

IHIFC: NVIF=BC-SIP, STATE=DOWN;


IHIFC: NVIF=BC-SIP, MTU=1416;
IHIFC: NVIF=BC-SIP, STATE=UP;

IHRHC: ADD, NVIF=BC-SIP, DEST=193.180.0.0,


NETMASK=255.255.0.0, GW=193.180.16.61,
PREF=0;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-177


MSC-S BC on BSP

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-178


IPLB-AETH-B
Base LAN
LNETH-A
ETH-B
ETH-A

IPLB-B
ETH-B
ETH-A
ETH-B
ETH-A
BSP Right Side

Data LAN

blade
MSC LN
ETH-B

ETH-A

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-179


Internal Connectivity

AP1 ETH-4
Base LAN
ETH-3
ETH-6
ETH-5

AP2 ETH-4
ETH-3
ETH-6
ETH-5
BSP Left Side

Data LAN

SPX1 ETH-B

ETH-A

BSP

SPX2
ETH-B

ETH-A
Example of Connectivity to VRs

Each BSP Tenant External VLAN is connected to the VR that has


been created for that Traffic Type.

MSC‐S BC
Tenant
SIG_SP1 SIG_SP2 SIG_SP3 SIG_SP4 OM_CN_SP CDR_CN_SP1 LI_CN_SP1

VRs

BSP  SIG_CN OM_CN CDR_CN LI_CN

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-180


IP Addresses for SIP

BSP
IPLB-A
ETH-B
LN IPLBA address VR-R
ETH-A VR-R address

IPLB-B
ETH-B
IPLBB address
ETH-A

MSC LN
blade VR-L address
ETH-B BPINGB address VR-R

ETH-A BPINGA address

VIP addresses

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-181


Router Path Supervision from MSC Blades

VR-R_Address
VR-R

LN VR-L_Address
MSC blades
VR-L
ETH-B BPINGB_Address

ETH-A BPINGA_Address

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-182


Default crossover routes

VR-R_Address
VR-R

LN VR-L_Address
MSC blades
VR-L
ETH-B VIPB_Address

ETH-A VIPA_Address

Preferred

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-183


Switching & Routing in BSP
L2 switch for system SCXA SCXB
communication 1 n
1G

Application
Blades (GEP)
10G

L2/L3 switch CMXA CMXB


CMX

10G

Site router Or APP


as node i/f

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-184


IP stack on CP configuration commands
› Format 1, Dual CP VIFs : IHIFI:VIF=vif;
› Format 3, CP in BSP environment : IHIFI:NVIFP=nvifp [,STACK=stack];

› Format 1, Dual CP VIFs : IHIFC:VIF=vif;


› Format 3, CP in BSP environment : IHIFC:NVIFP=ethnvif, ...

› Format 1, Dual CP: IHRSI:VIFP=nvifp,..PINGA=pinga, PINGB=pingb;


› Format 2a, Dual CP in BSP : IHRSI:NVIFP=nvifp,..PINGA=pinga, PINGB=pingb;

› Format 1, Dual CP VIFS : IHRHC:VIF=vif,..PINGA=pinga, PINGB=pingb;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-185


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-186
SIP/SIP-I Advanced in MSS15

Configuration of SIP
Objectives
Configuration of SIP/SIP-I routes in MSC-S:

› Describe the SIP/SIP-I routing concept as implemented in MSC-S


› Clarify the three main steps in the MGCF configuration for SIP/SIP-I
routes
› Practice to configure SIP/SIP-I routes
› Explain how to configure number conversion
› List and explain the DT for SIP-I Screening

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-188


MGCF Architecture

Charging applications
PSTN
MGCF IMS core
ISUP Traffic SIP
Control
SIP
I-/S-CSCF
ISUP BICC, BICC (Mg
ISUP and
Mj i/f) BGCF
Connection & Bearer control
PLMN, other CN
GCP (H.248)

RAN, UTRAN Sigtran (SCTP/IP) IMS Access


MSC-S

H.248
(Mc+Mn i/f)
MS
(IMSI, MSISDN) SGW

TDM /ATM /IP MGW RTP/IP stream

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-189


SIP functional distribution
SIP Trunk User Agent (SIPTA)

Transaction User: Trunk and Signaling


UAC and UAS Subsystem (TSS)

SIP Support Functions (SIPSF)


Common Signaling
Protocols RM
SIP Dialogs SIP Transactions SIP Transport
(CSPRM)
layer layer

Sockets in PLEX adaptation layer


Operating System Syntax & Encoding
and Hardware UDP TCP SCTP DNS Client
IP
ACSIP
Ethernet

APZ Eth-A Eth-B

LAN

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-190


Routing in SIP
Proxy-1 Proxy-2 INVITE request
Proxy-1 does not INVITE request
record route Contact (MSC-S)
(I-CSCF) Contact (MSC-S) (S-CSCF) Via (Proxy-2)
Via (Proxy-1)
Via (Proxy-1)
Via (MSC-S)
Via (MSC-S)
1st transaction 3 Record-Route (Proxy-2)
(INVITE) request 2
Contact (MSC-S)
VIA (MSC-S)
5
6 180 RING
Contact (UA)
180 RING Via (Proxy-1)
Contact (UA) Via (MSC-S)
Via (MSC-S) Record-Route (Proxy-
Record-Route (Proxy- 2)
2)
(1st transaction INVITE
response) 180 RING
1 Contact (UA)
Via (Proxy-2)
Via (Proxy-1)
Via (MSC-S)
2nd transaction Record-Route (Proxy-2)
(like PRACK)

… 4

Subsequent
TeS transactions will
MSC-S not traverse
Proxy-1, as it has

MGCF n:th transaction not recorded route
(like 200 OK)
UA
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-191
Initialization of SIP or SIP-I signaling
› IP stack configuration

› defining a local node to be visible as a resource in the SIP network and


connecting local SIP application to the IP stack

› definition of SIP signaling network (remote SIP hosts and domains definition, SIP
or SIP-I traffic routes definition)

› SIP or SIP-I Routes definition

› configuration of Route Analysis

› configuration of Number Handling for SIP and SIP-I

› defining of payload types to be used for media negotiation

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-192


Operational Procedure to Initiate SIP/SIP-I

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-193


Local VLAN and IP Definition in DB & BC
› VLAN and IP Configuration in DB
› ! DEFINE THE VIRTUAL INTERFACES!
› IHIFI:VIF=ETHA-10;
› IHIFI:VIF=ETHB-10;

! ADD IP TO VIF , ONLY ETHA NEEDS TO BE CONFIGURED !
› IHIFC:VIF=ETHA-10,ADD,IP=172.23.47.70,NETMASK=255.255.0.0,ARP=YES;

› VLAN and IP Configuration in BC


› ! DEFINE THE VIRTUAL INTERFACE !
› IHIFI: NVIF=BC-SIP;

! ADD IP TO NVIF ,
› IHIFC: NVIF=BC-SIP, ADD, BASEIP=193.180.16.1, NETMASK=255.255.255.192,
ARP=YES;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-194


Local Host Configuration in MSC-S DB
Used to populate the
P-Charging-Vector
SIP Local Host
Network Identity name

Local Host Name


Unique address (FQDN)
which identifies MSC-S in
the network
TCP listening socket: UDP socket:

local TCP port local UDP port

local IP address

APZ (CP) Eth-A Eth-B

L2 switch L2 switch
Note: Network Identity name is the domain name of the network in which the local host (node) resides.
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-195
Local Host Configuration in MSC-S BC
› Each Blade has a unique IP Address in MSC-S BC.

MSC Blade #n
MSC Blade #1
MSC Blade #0 Network Identity Name

SIP / SIP-I Note the point

Local Host Name = Blade ID . Base Host Name

Test Port Port Test


UDP TCP

Local / Blade IP Address = Blade ID + Base IP Address

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-196


Local Host Configuration in DB & BC
› Gateway Configuration in DB
› !ROUTE SUPERVISION & IP ADD MIGRATION !
› IHRHC:ADD,VIF=ETHA-10,DEFGW=<IPaddrGW1>,PREF=0;
› IHRHC:ADD,VIF=ETHA-10,DEFGW=<IPaddrGW2>,PREF=1;
› IHRSI:VIFP=ETH-10,GW=<IPaddrGW1>&<IPaddrGW2>,
› PINGA=172.23.47.72,PINGB=172.23.47.73,IPMIGR=YES;

› Gateway Configuration in BC (BC uses a different supervision)


› IHRHC:ADD, SOURCE=10.158.2.81, DEST=121.35.72.0, NETMASK=255.255.0.0,
GW=10.158.2.94, PREF=10;

› Local Host Configuration (from this point – all commands are similar)
› IBLNC:NAME1=“SIP.MSC300.NIV",NETID1=“MSC300.NIV";

› !CREATING LOCAL HOST SOCKETS!
› IBLSI:SID=TCP-0,IPADD="172.23.47.70",LPN=5060;
› IBLSI:SID=UDP-0,IPADD=“172.23.47.70"; !Port Nr 5060 default!
› IBLSP:SID=all;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-197


Printout SIP Local Host
<IBLSP:SID=ALL;
SIP SIGNALLING LOCAL HOST SOCKETS DATA

SID IPADD LPN SIDSTATE


UDP-1 172.23.47.70 5060 OPEN
TCP-1 172.23.47.70 5060 LISTENING

END

<IBLNP;
SIP SIGNALLING LOCAL HOST NAME

NAME
SIP.MSC300.NIV

NETID
MSC300.NIV

END

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-198


Remote Host Configuration
› Remote host name
– either FQDN (A RR)
– or IPv4 address
– or retrieved using DNS (DOMID; A RR)
› Transport protocol
– “UDP/TCP”, “UDP only” or “TCP only”
– or retrieved using DNS (NAPTR RR)
› Remote server port number
– default=5060 or in the range of IANA unassigned ports
– or retrieved using DNS (SRV RR)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-199


SIP Remote Host & Domain Configuration
Example
!Defining Remote Hosts!
IBHOI:HOST=M6PSPU,NAME1=“SIP.MSC600.NIV",TRN=1,RPN=5060;
IBHAI:HOST=M6PSPU,IPADD="172.23.47.6"; !Optional specification!

IBHOI:HOST=M6NSIU,NAME1=“SIP.M6NSIU.NIV”,TRN=0,RPN=5060;

IBHOI:HOST=RIHTSU,NAME1=“ICSCF.IMT2.RIMS.TN.BETE.ERICSSON.SE",T
RN=0,RPN=5060;
IBHOP:HOST=ALL;

!Defining Destination Domain!


DNDNI:DOMID=RIHDSU,NAME1=“IMT2.RIMS.TN.BETE.ERICSSON.SE";
DNDNI:DOMID=M6NDIU,NAME1=“SIP.M6NDIU.NIV”;
DNDNP:DOMID=all;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-200


Printout SIP Remote Host / Domain
<IBHOP:HOST=ALL;
SIP SIGNALLING REMOTE HOST DATA
HOST IPADD TRN RPN
M6PSPU 172.23.47.6 1 5060
NAME
SIP.MSC600.NIV
HOST IPADD TRN RPN
M6NSIU 1 5060
NAME
SIP.M6NSIU.NIV
HOST IPADD TRN RPN
RIHTSU 0 5060
NAME
ICSCF.IMT2.RIMS.TN.BETE.ERICSSON.SE

END

<DNDNP:DOMID=ALL;
DNS RESOLVING DOMAIN DATA

DOMID NAME
RIHDSU IMT2.RIMS.TN.BETE.ERICSSON.SE
M6NDIU SIP.M6NDIU.NIV

END
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-201
Route, RSI, SCI and EIVP 1(2)
SCI-B
Wireline
Wireline
Network
Network
TSS

R3 RSI3
SCI-A
R1 RSI1
Wireless
Wireles
R4 RSI2 MSS s Network
s Network
SBC 1
SIP R2
(Route owner)

R5 SBC 2
MSC-S RSI5 RSI4
SCI-C
RSI6
R6 IMS
IMS
SIP-I routes: R1, R2, R3 CSCF/
SIP routes: R4, R5, R6 BGCF

AXE Route concept applied to SIP/SIP-I networks:


Route Set Information (RSI), SIP trunk Configuration Information (SCI) ,
Encapsulated ISUP Version Profile (EIVP)
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-202
SIP Managed Objects

Route
1 n

1
SCI
m

EIVP
1
1

RSI
n

Remote Host
and/or
1
Domain

SIP Local Host

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-203


Route, RSI, SCI and EIVP 2(2)

Route-1 RSI 1
SCI-A
Route-2 RSI 2
EIVP-1
SCI-B Route-3 RSI 3

Route-4 RSI 4

SCI-C Route-5 RSI 5

Route-6 RSI 6

EIVP and SCI relations SCI, route and RSI relations


for SIP-I routes for SIP & SIP-I routes
EIVP SCI SCI Route RSI
1 : m 1 : n : n

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-204


RSI Configuration
Pre-configured SIP route set = NHOP host.
Next-hop host Destination host SIP invitation: Name of NHOP host is put in
RSI = NHOP + DEST (SBG) (MSS/TSS/I-CSCF) Route header. Name of DEST host
composes a SIP dialog target, i.e. name is
RSI Type 1 put into Request URI and To header URI.

Pre-configured SIP route set = empty.


Destination host SIP invitation: No Route header. Name of
RSI = DEST (MSS/TSS/I-CSCF) DEST host composes a SIP dialog target,
i.e. name is put into RequestURI and To
RSI Type 2 header URI.

Pre-configured SIP route set = NHOP host.


Next-hop host Destination SIP invitation: Name of NHOP host is put in
RSI = NHOP + DOMID (SBG/I-CSCF) DOMAIN Route header. Domain name composes a
SIP dialog target (AOR), i.e. name is put into
RSI Type 5 Request URI and To header URI.

Pre-configured SIP route set = empty.


Destination SIP invitation: No Route header. Domain
RSI = DOMID DOMAIN name composes a SIP dialog target
(AOR), i.e. name is put into Request URI
RSI type 6 and To header URI.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-205


Additional managed objects for IMS traffic
MSC-S

DEST = I-CSCF remote node


SRC1 = BGCF remote node
MGCF
MGCF
IMS

NHOP
NHOP DEST
RSI: (optional) DEST
(optional)

SIP traffic direction SRC1


INVITE for new session SRC1
(optional)
and subsequent messages (optional)

1 bothway ROUTE

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-206


RSI,EIVP,SCI & Route Configuration
Example
! Route Set Information (RSI) Configuration !
IBROI:RSI=M6PSPU ,DEST=M6PSPU,RSINUM=1;
IBROI:RSI=M6NSIU,DEST=M6NSIU,RSINUM=11;
IBROI:RSI=RIHTSU,DEST=RIHTSU,RSINUM=18;
IBROP:DEST=ALL;

!Encapsulated ISUP Version Profile (EIVP) Configuration!


SGVPI:EIVP=1,BASEID=2,VERNAME=ITUT92;
SGPVP:EIVP=ALL;

!SIP trunk Configuration Information (SCI) Configuration !


SGTCI:SCI=1, SIPTYPE=SIP,SIPIMPL=6;
SGTCI:SCI=2,SIPTYPE=SIPI,EIVP=1,SIPIMPL=4;

!SIP Route Configuration!


EXROI:R=PSPU330&PSPU33I,DETY=SIPCO,FNC=3;
EXRBC:R=PSPU33O,RGPAR=SCI-1;
EXRBC:R=PSPU33O,RGPAR=RSIID-1;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-207


Printout Route Set Information (RSI)
<IBROP:DEST=ALL;
SIP SIGNALLING ROUTE SET INFORMATION DATA
RSI NHOP DEST IPG TRN DOMID RSINUM
M6PSPU M6PSPU 1 1
SRC1 SRC2

RSI NHOP DEST IPG TRN DOMID RSINUM


M6NSIU M6NSIU 1 11
SRC1 SRC2

RSI NHOP DEST IPG TRN DOMID RSINUM


RIHTSU RIHTSU 18
SRC1 SRC2

END

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-208


Printout SIP Trunk Configuration (SCI) &
Encapsulated ISUP Version Profile (EIVP)
<SGTCP:SCI=ALL;
SIP TRUNK CONFIGURATION INFORMATION DATA
SCI ADMSTATE SIPTYPE SIPIMPL
1 CONFIGURED SIP SIP-3GPP

ROUTE RTEADMSTATE RTEGLSTATE RTEBLSTATE


PSPU33O ACTIVATED WORKING
RIHD36O DEFINED BLOCKED DBL

SCI ADMSTATE SIPTYPE SIPIMPL EIVP


2 CONFIGURED SIPI SIPI-ITUT-C 1

ROUTE RTEADMSTATE RTEGLSTATE RTEBLSTATE


PSIU33O ACTIVATED WORKING
END
<SGVPP:EIVP=ALL;
ENCAPSULATED ISUP VERSION PROFILE DATA
EIVP EIVPSTATE BASEID BASENAME VERSIONNAME PID
1 ASSIGNED 2 ITU-T92+ ITU-T92+ 0
SCI
2
END

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-209


Complete Pre-configuration of ASNs,
Example

SRC

DOMID

Remote Host3: MSS01


BGCF2 Route1:
DEST (RSI=IMS1) Route2: NHOP
SRC (RSI=MSS1)

MSC-S
Remote Host1: Remote Host 4:
Remote Host2: ICSCF1 Local host PX1
Remote Domain 1
BGCF1 191.110.12.13 191.110.45.22
191.110.45.23

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-210


Configuration Steps for SIP/SIP-I routes
› Definition of routes: EXROI command
EXROI:R=BCO&BCI,DETY=SIPCO,FNC=3; ! Traffic Route!
EXROI:R=MAINO&MAINI,DETY=SIPCO,FNC=7; ! Main Route!

› Assignment of SCI to route: EXRBC command


EXRBC:R=BCO,RGPAR=SCI-2;

› Configuring additional route data: EXRBC command

› Assignment of the main route to a traffic route EXRBC command


EXRBC:R=BCI, R2=MAINI;

› Assignment of RSI to Route EXRBC command


EXRBC:R=BCO, RGPAR=RSIID-5;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-211


Configuration of Route Analysis example

TMR TMR Type


supported/unsupported
0 supported Speech
1 supported* 64 kbit/s unrestricted digital
information
2 unsupported 56 kbit/s
3 supported 3.1 kHz audio
4 unsupported 7 kHz audio
5-255 Spare

ANRPI:RC=11;
ANRSI:BR=TMR-0&-1&-3,P01=1,R=SIPI1O,SP=661;
ANRSI:BR=TMR-2&-4,P02=1,R=ISUP10,SP=661;
ANRPE;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-212


Example of SIP connectivity

SIP DNS
DNS
DNS
DNS (ims.com)
(cscore.de) Mg
MSC-S
I-CSCF
I-CSCF CSI-1
Proxy1
Proxy1 IMS:
“ims.com”
BGCF
BGCF
Proxy2
Proxy2
MGCF Mj
MGCF

“cscore.de ” TSS:
“wireline.com” CSI-2
MSC: “ mscserver.cscore.de” Telephony
Telephony
PX1: “ proxy1.cscore.de” Server
Server
PX2: “ proxy2.cscore.de”
H1: “ icscf.ims.com ” DNS
“ bgcf.ims.com” DNS
H2: SIP-I (wireline.com)
WLN: “ tes40.wireline.com”

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-213


Data Transcript 1(2)
Making the feature available and activating the feature
DBTRI;
DBTSC:TAB=AXEPARS,SETNAME=SIPSUPPORTF,NAME=SIPAVAIL,VALUE=1;
DBTSC:TAB=AXEPARS,SETNAME=SIPSUPPORTF,NAME=SIPTAVAIL,VALUE=1;
DBTSC:TAB=AXEPARS,SETNAME=SIPSUPPORTC,NAME=SIPACT,VALUE=1;
DBTSC:TAB=AXEPARS,SETNAME=SIPSUPPORTC,NAME=SIPTACT,VALUE=1;
DBTRE:COM;
IP configuration
!Defining Virtual Interface and Setting IP address on IP port!
IHIFI:VIF=ETHA-10;
IHIFI:VIF=ETHB-10;
IHIFC:VIF=ETHA-10,ADD,IP=10.0.0.5,NETMASK=255.192.0.0,ARP=YES;
IHRHC:ADD,VIF=ETHA-10,DEFGW=<IPaddrGW1>,PREF=0;
IHRHC:ADD,VIF=ETHA-10,DEFGW=<IPaddrGW2>,PREF=1;
IHRHC:ADD,VIF=ETHB-10,DEFGW=<IPaddrGW1>,PREF=1;
IHRHC:ADD,VIF=ETHB-10,DEFGW=<IPaddrGW2>,PREF=0;
IHRSI:VIFP=ETH-10,GW=<IPaddrGW1>&<IPaddrGW2>,
PINGA=10.0.0.11,PINGB=10.0.0.12,IPMIGR=YES;
Local Host
!Defining Local Host Name!
IBLNC:NAME1="mscserver.",NAME2="cscore.de",NETID1="cscore.de";
!Creating Local Host Sockets!
IBLSI:SID=TCP-0,IPADD="10.0.0.5",LPN=5060;
IBLSI:SID=UDP-0,IPADD="10.0.0.5"; !Port Nr. 5060 default!
IBLSP:SID=all;
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-214
Data Transcript 2(3)
Remote Hosts & Domains
!Defining Remote Hosts!
IBHOI:HOST=PX1,NAME1="proxy1.cscore.de",TRN=1,RPN=5060;
IBHAI:HOST=PX1,IPADD="10.0.0.6"; !Optional specification!
IBHOI:HOST=PX2,NAME1="proxy2.cscore.de",TRN=1,RPN=5060;
IBHAI:HOST=PX2,IPADD="10.0.0.7"; !Optional specification!
IBHOI:HOST=H1,NAME1="icscf.ims.com";
IBHOI:HOST=H2,NAME1="bgcf.ims.com";
IBHOI:HOST=WLN,NAME1="tes40.wireline.com";
IBHOP:HOST=all;

!Defining Destination Domain!


DNDNI:DOMID=D1,NAME1="wireline.com";
DNDNP:DOMID=all;

!Defining RSI´s Next hop is PX1, final Dest is H1!


IBROI:RSI=IMSroute1,NHOP=PX1,DEST=H1,SRC1=H2,RSINUM=4;

!Next hop is PX2, final Dest is H1!


IBROI:RSI=IMSroute2,NHOP=PX2,DEST=H1,SRC1=H2,RSINUM=5;

!Route to Domain D1!


IBROI:RSI=TSSroute,DOMID=D1,RSINUM=6;
IBROP:RSI=all;
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-215
Data Transcript 3(4)
!Defining SCI-s!
SGTCI:SCI=1,SIPTYPE=SIP,SIPIMPL=6; !SIPIMPL=6 means SIP-3GPP!
!SIP-I type of route!
SGVPI:EIVP=1,BASEID=2,VERNAME=ITUT92;
SGPVP:EIVP=all;
SGTCI:SCI=2,SIPTYPE=SIPI,EIVP=1,SIPIMPL=4; !SIPIMPL=4 means SIPI-ITC!

MGWs and Routes


!Defining MGW and MGG!
...
NRGWI:MG="IM-MGW",BCUID=234,SIGTR=sctp,SIGADDR=assocID;
NRGGI:MGG="group1",MG="IM-MGW";
...
!Defining SIP routes!
EXROI:R=maino&maini,DETY=SIPCO,FNC=7; !Main Route!

EXROI:R=trunk1o&trunk1i,DETY=SIPCO,FNC=3; !Traffic route1!


!SIP type in SCI number 1!
EXRBC:R=trunk1o,RGPAR=SCI-1;
!Associating RSI number 4!
EXRBC:R=trunk1o,RGPAR=RSIID-4;
!Mapping to MGG and Main Route!
EXRBC:R=trunk1o,R2=maino,RGSPAR=mgg-group1;
!Mapping to Main Route!
EXRBC:R=trunk1i,R2=maini;
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-216
Data Transcript 4(4)
EXROI:R=trunk2o&trunk2i,DETY=SIPCO,FNC=3; !Traffic route2!
!SIP type in SCI number 1!
EXRBC:R=trunk2o,RGPAR=SCI-1;
!Associating RSI number 5!
EXRBC:R=trunk2o,RGPAR=RSIID-5;
!Mapping to MGG and Main Route!
EXRBC:R=trunk2o,R2=maino,RGSPAR=mgg-group1;
!Mapping to Main Route!
EXRBC:R=trunk2i,R2=maini;

EXROI:R=trunk3o&trunk3i,DETY=SIPCO,FNC=3; !Traffic route3!


!SIP type in SCI number 2!
EXRBC:R=trunk3o,RGPAR=SCI-2;
!Associating RSI number 6!
EXRBC:R=trunk3o,RGPAR=RSIID-6;
!Mapping to MGG and Main Route!
EXRBC:R=trunk3o,R2=maino,RGSPAR=mgg-group1;
!Mapping to Main Route!
EXRBC:R=trunk3i,R2=maini;

!Deblocking routes!
BLORE:R=trunk1o;
BLORE:R=trunk2o;
BLORE:R=trunk3o;
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-217
SIP Single Node View Background

bc00.msc.ericsson.com

bc00.msc.ericsson.com

bc01.msc.ericsson.com

bc01.msc.ericsson.com

bc02.msc.ericsson.com
bc02.msc.ericsson.com

bcN.msc.ericsson.com
bcN.msc.ericsson.com

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-218


SIP SNV improvements
› Single Node View improvements
– Virtual IP address is used on Cluster level (also named Cluster IP address). In order
to introduce Single Node View concept existing IP load balancing function in IPLB is
improved. New handling allows load balancing of incoming TCP connections or UDP
packets terminated on Cluster IP address. Number of SIP contact IP addresses in
MSC-S BC node can be reduced to only one.
– Cluster IP address is used for outgoing SIP traffic. Only one FQDN is used on cluster
level.
› Scalability improvements
– SIP distribution function is introduced in the blade that evenly distributes incoming
SIP calls taking into account blade capacity and load parameters in order to provide
a scalable and robust solution.
– In order to prevent bottleneck or single point of failure, SIP distribution and IP load
balancing functions are decoupled and completely independent of each other.
› ISP improvements availability
– Cluster IP address is not dependent of internal availability of specific blade.
– Call success rate and Call setup time are improved

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-219


SIP Distribution FUNCTION
Blade 1 Blade 2 Blade n

Distribution function Outgoing SIP session Incoming SIP session

IPLB

ASN1 ASN2

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-220


Migration and Configuration aspects

› Impacts on network configuration and migration


– SNV improvements require using Virtual IP address on Cluster level (also named Cluster IP
address) and one Fully Qualified Domain Name (FQDN) per cluster for SIP/SIP-I
communication towards external nodes.

– It is possible to execute upgrade and migration without reconfiguration of already deployed


ASNs. All existing blade specific IP addresses must be configured as Cluster IP addresses
equally defined in all blades.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-221


Before Migration

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-222


The Migration Procedure
› The migration procedure consists of two parts, as follows:

1) The mandatory part of the migration, which is executed in the MSC-S BC:
– Setting as Local Host Name the existing Blade Local Host Name of the blade with
the lowest Blade ID, and
– Configuring as Cluster IP addresses in the MSC-S BC all Blade IP addresses. The
MSC-S BC uses for all outgoing SIP and SIP-I signaling the Cluster IP address
with the lowest value.

2) The optional part of the migration, which is performed in all DNS servers,
remote peers, and in the MSC-S BC.
- The optional procedure comprises removing all Local Host Names and Cluster
IP addresses from the DNS servers and remote peers, except the IP address with
the lowest numerical value and the corresponding Local Host Name.
- The optional migration is highly recommended to simplify the network
administration.
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-223
After Mandatory Part of the Migration

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-224


After Mandatory and Optional Parts of
the Migration

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-225


LOAD BALANCER CONTROLLER DATA

MSC-S Blade Cluster Cluster VIP addresses for SIP/SIP-I


GCP over SCTP (dual -homed)
10.42.219.1
MSC 193.180.15.1
Blade 0 193.180.15.9
192.168.3.1
192.168.1.3
IPLBA
MSC 193.180.15.1
Blade 1 INT-DCP
193.180.15.9
192.168.3.2
192.168.1.4 IPLBB

MSC 193.180.15.1
Blade 5
10 193.180.15.9
10.42.219.1
192.168.3.11
192.168.3.8

IHIFC: NVIF=INT-SIG, ADD,


BASEIP=192.168.1.3,NETMASK=255.255.255.128, ARP=YES;
LBIDC: BASEIP=192.168.1.3, ILB=<ilb>;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-226


Mandatory Migration Part
› Defined Base IP address is 10.42.219.1

› The MSC-S BC node has 6 blades and the derived IP addresses are:
– Blade IP address / Prefix
– 10.42.219.1/27
– 10.42.219.2/27
– 10.42.219.3/27
– 10.42.219.4/27
– 10.42.219.5/27
– 10.42.219.6/27
› Defined Base Local Host Name is MSC.ERICSSON.COM

› The Default Gateway IP addresses are 10.42.219.29 and 10.42.219.30

› The destination network address for interface route is 10.42.221.192


© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-227
Single Node View Configuration Example 1(3)

› SYBUE;
› SAAEP:SAE=500,BLOCK=TPC;
› SAAII:SAE=500,BLOCK=TPIBH,NI=48;
› SAAII:SAE=502,BLOCK=TPIBH,NI=30240;
› IBLSE:SID=TCP-1;
› IBLSE:SID=TCP-0;
› IBLSE:SID=UDP-1;
› IBLSE:SID=UDP-0;
› IHRHC:DEL, NVIF=SIP, DEFGW=10.42.219.29;
› IHRHC:DEL, NVIF=SIP, DEFGW=10.42.219.30;
› IHRHC:DEL, NVIF=SIP, DEST=10.42.221.192, GW=10.42.219.29;
› IHRHC:DEL, NVIF=SIP, DEST=10.42.221.192, GW=10.42.219.30;
› IHIFC:NVIF=SIP, STATE=DOWN;
› IHIFC:NVIF=SIP, DEL, BASEIP=10.42.219.1;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-228


Single Node View Configuration Example 2(3)

› IHIFC:NVIF=SIP,ADD,IP=10.42.219.1,NETMASK=255.255.255.224,ARP=NO;
› IHIFC:NVIF=SIP,ADD,IP=10.42.219.2,NETMASK=255.255.255.224,ARP=NO;
› IHIFC:NVIF=SIP,ADD,IP=10.42.219.3,NETMASK=255.255.255.224,ARP=NO;
› IHIFC:NVIF=SIP,ADD,IP=10.42.219.4,NETMASK=255.255.255.224,ARP=NO;
› IHIFC:NVIF=SIP,ADD,IP=10.42.219.5,NETMASK=255.255.255.224,ARP=NO;
› IHIFC:NVIF=SIP,ADD,IP=10.42.219.6,NETMASK=255.255.255.224,ARP=NO;
› IHIFC:NVIF=SIP,STATE=UP;
› IHRHC:ADD, NVIF=SIP, DEFGW=10.42.219.29, PREF=255;
› IHRHC:ADD, NVIF=SIP, DEFGW=10.42.219.30, PREF=125;
› IHRHC:ADD, NVIF=SIP, DEST=10.42.221.192,
NETMASK=255.255.255.224, GW=10.42.219.29, PREF=255;
› IHRHC:ADD, NVIF=SIP, DEST=10.42.221.192,
NETMASK=255.255.255.224, GW=10.42.219.30, PREF=125;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-229


Single Node View Configuration Example 3(3)

› IBLNC:NAME1="BC00.MSC.ERICSSON.COM",
NETID1="ERICSSON.COM";
› IBLSI:SID=UDP-0,IPADD="10.42.219.1", LPN=5060;
› IBLSI:SID=UDP-1,IPADD="10.42.219.1", LPN=50600, PTI=TP;
› IBLSI:SID=TCP-0,IPADD="10.42.219.1", LPN=5060;
› IBLSI:SID=TCP-1,IPADD="10.42.219.1", LPN=50600, PTI=TP;
› IBLSI:SID=UDP-2,IPADD="10.42.219.2", LPN=5060;
› IBLSI:SID=UDP-3,IPADD="10.42.219.2", LPN=50600, PTI=TP;
› IBLSI:SID=TCP-2,IPADD="10.42.219.2", LPN=5060;
› IBLSI:SID=TCP-3,IPADD="10.42.219.2", LPN=50600, PTI=TP;
› (cut)
› IBLSI:SID=UDP-10,IPADD="10.42.219.6", LPN=5060;
› IBLSI:SID=UDP-11,IPADD="10.42.219.6", LPN=50600, PTI=TP;
› IBLSI:SID=TCP-10,IPADD="10.42.219.6", LPN=5060;
› IBLSI:SID=TCP-11,IPADD="10.42.219.6", LPN=50600, PTI=TP;
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-230

› SYBUI;
Configuration Before Migration

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-231


Configuration After MSC-S BC Mandatory
Migration for Incoming Messages

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-232


Optional Migration

› IBLSE: SID=UDP-2;
› Wait up to two minutes for all managed sockets
› IBLSE: SID=UDP-3; to be removed. When all managed sockets are
› IBLSE: SID=TCP-2; removed continue with the rest of the commands
› IBLSE: SID=TCP-3; as follows:
› IBLSE: SID=UDP-4;
› IHIFC:NVIF=SIP, DEL, IP=10.42.219.2;
› IBLSE: SID=UDP-5;
› IHIFC:NVIF=SIP, DEL, IP=10.42.219.3;
› IBLSE: SID=TCP-4;
› IHIFC:NVIF=SIP, DEL, IP=10.42.219.4;
› IBLSE: SID=TCP-5;
› IHIFC:NVIF=SIP, DEL, IP=10.42.219.5;
› (cut)
› IHIFC:NVIF=SIP, DEL, IP=10.42.219.6;
› IBLSE: SID=UDP-10;
› IBLSE: SID=UDP-11;
› IBLSE: SID=TCP-10;
› IBLSE: SID=TCP-11;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-233


Configuration After Both Mandatory and
Optional Migration

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-234


International Gateway for SIP-I
› Number modification between national and international format e.g. for
ISUP calling party number
› Interworking between national and international signalling protocols
› Supplementary service interworking

PLMN-1 MSC-S MSC-S PLMN-2


Country A Country B
SIP-I SIP-I
Mc Mn Mn Mc
RAN IP Transit Network RAN

Mb
Mb
M-MGW M-MGW

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-235


Example for Incoming SIP-I Call Number
Conversion

Call Set-up Direction

Country A Country B
CC: 31 CC: 49

SIP:INVITE(IAM) IAM
MAPPING NC

P-Asserted-Identity: Calling Party Number (CPN): CPN: 173 123456


+49 173 123456 49 173 123456 TON: national significant
From: +49 173 123456 TON: international number number
NAPI: E.164 NAPI: E.164
International Gateway

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-236


URI Conversion to Called Party Number
and vice versa

SIP SIP i/c BICC’ Traffic Control BICC’ BICC’ Traffic Control BICC’ SIP o/g SIP
Mapping Mapping
NumbCon NumbCon
1 . 2
2 1

Request-URI CdPN CdPN CdPN CdPN Request-URI

+39067258666 39067258666 39067258666 39067258666 39067258666 +39067258666


International International International International

067258666 067258666 39067258666 39067258666 067258666 067258666


phone-context National International International National phone-context
+39067258666 +39067258666 067258666 067258666 39067258666 +39067258666
International National National International
067258666 067258666 067258666 067258666 067258666 067258666
phone-context National National National National phone-context
666 666 067258666 067258666 666 666
phone-context Network Specific National National Network Specific phone-context

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-237


Calling/Connected Number Conversion
GPNA GPNA
2 NumbCon NumbCon 1

SIP SIP i/c BICC’ Traffic Control BICC’ BICC’ Traffic Control BICC’ SIP o/g SIP
Mapping Mapping
1 2

P-Asserted <-> CgPN/ACgPN -> CgPN/ACgPN-> CgPN/ACgPN -> CgPN/ACgPN-> P-Asserted <->
From -> ConnNumb<- ConnNumb <- ConnNumb<- ConnNumb <- From ->
+492407575444 492407575444 492407575444 492407575444 492407575444 +492407575444
International International International International
+492407575444 2407575444 2407575444 492407575444 492407575444 2407575444
National National International International phone-context

2407575444 492407575444 492407575444 2407575444 2407575444 +492407575444


phone-context International International National National
2407575444 2407575444 2407575444 2407575444 2407575444 2407575444
phone-context National National National National phone-context
444 444 444 444 444 444
phone-context Subscriber Subscriber Subscriber Subscriber phone-context
number number Number Number
444 444 444 444 444 -
- National National unknown unknown

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-238


NAT – Number Relation
NAT Number

2 Calling Party Number

3 Original called number

4 Redirecting number

5 Connected Number

7 Redirection Number

8 Additional Calling Party Number

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-239


GPNA Input/Output for Number
Conversions
NAT NO TON NAPI

GPNA Pre-Analysis

Digit Series NAT ODA NAPI

GPNA Digit Analysis

TON Number Converted digit series NAPI


discarded - Unmodified or
indication - CC added or
- CC removed

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-240


GPNA Input/Output During Call Handling
From the AXE parameter Derived from
(e.g. GPNANOCPNIC for the calling party the number
number and incoming number conversion) (e.g. national format)

NAT NO TON

Derived from the number


(e.g. Calling Party Number: NAT = 2)

GPNA Pre-Analysis

NAT ODA
Digit series of the
Calling Party Number

GPNA Digit Analysis

TON Number Converted digit series


discarded - Unmodified or
indication - CC added or
- CC removed
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-241
GPNA Pre-Analysis

! Zeroize Non-Operating Area !


GPPZI:NAT=2;

! Define the ODA for the Incoming Number Conversion (Removal of CC) !
GPPSI:NAT=2,NO=0,TON=1,ODA=10, STATUS=ZERO;

! Define the ODA for the special handling of received national numbers !
GPPSI:NAT=2,NO=0,TON=4,ODA=99;

! Define the ODA for the Outgoing Number Conversion (Addition of CC)!
GPPSI:NAT=2,NO=1,TON=4,ODA=11;

! Activate Non-Operating Area !


GPPAI:NAT=2;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-242


GPNA Analysis

! Zeroize Non-Operating Area !


GPAZI:NAT=2;
! Define the removal of the country code !
!For each number starting with the own CC, the first two digits !
! are removed and the TON is changed to national !
GPASI:NAT=2, NUM=10-49 ,M=2, TON=4, SUC, STATUS=ZERO;

! Define the addition of the country code !


! For all numbers the own CC is added and the TON is changed to
international !
GPASI:NAT=2, NUM=11-1, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-2, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-3, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-4, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-5, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-6, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-7, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-8, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-9, M=0-49, TON=1, SUC;
GPASI:NAT=2, NUM=11-0, M=0-49, TON=1, SUC;

Activate Non-Operating Area:


GPAAI:NAT=2;
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-243
SIP-I Screening
› The feature FAJ 121 0732/1 Support of SIP-I screening is used when
interconnecting the MSC Server with wireline or wireless softswitch networks

› It allows modification of messages, parameters and parameter fields from the


encapsulated ISUP content.

› This feature enables the operator to provide a SIP-I interconnect using the
national variant of ISUP by producing/configuring/defining the screening masks
needed for the interconnection.

› This simplifies the migration from a TDM based interconnect towards an IP


based interconnect.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-244


Support of SIP-I screening
› Modification of the encapsulated ISUP (messages & parameters)
› In MSS R5.1 only ITU-T and ANSI ISUP can be encapsulated
› SIP-I can use the screening mechanism

Benefit:
› Flexible mechanism
(e.g. bilateral agreements) SIP-I
MSC-S
› Better interoperability
(Int. Gateways are ETSI
IP
based ISUP and BICC)

M-
MGW

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-245


DT for SIP-I screening

SGSMI:SM=ETSI356V3,BASEID=6,PID=0,SMID=LZY2010531A;
SGSMC:SM=ETSI356V3,DIR=S,ACT=D-P,MI=IAM,PI=1;
SGRMC:SM=ETSI356V3,R=SUPETAR&LOZISCE;

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-246


Commands for SIP/SIP-I 1(2)
IBHAC: SIP Signaling, Remote Host IP Address, Change
IBHAE: SIP Signaling, Remote Host IP Address, End
IBHAI: SIP Signaling, Remote Host IP Address, Initiate
IBHOC: SIP Signaling, Remote Host, Change
IBHOE: SIP Signaling, Remote Host, End
IBHOI: SIP Signaling, Remote Host, Initiate
IBHOP: SIP Signaling, Remote Host Data, Print
IBLNC: SIP Signaling, Local Host Name, Change
IBLNP: SIP Signaling, Local Host Name, Print
IBLSE: SIP Signaling, Local Host Sockets, End
Terminates SIP UDP or TCP listening port
IBLSI: SIP Signaling, Local Host Sockets, Initiate
Creates SIP UDP or TPC listening port
IBLSP: SIP Signaling, Local Host Sockets, Print

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-247


Commands for SIP/SIP-I 2(2)

IBROE: SIP Signaling, Route Set Information, End


IBROI: SIP Signaling, Route Set Information, Initiate
IBROP: SIP Signaling, Route Set Information Data, Print
IBRDC: SIP Signaling Route Set Data Change
SGTCE: SIP Group Control Functions, Trunk Configuration, End
SGTCI: SIP Group Control Functions, Trunk Configuration,
Initiate
SGTCP: SIP Group Control Functions, Trunk Configuration, Print
SGVPE: SIP Group Control Functions, Version Profile, End
SGVPI: SIP Group Control Functions, Version Profile, Initiate
SGVPP: SIP Group Control Functions, Version Profile, Print
DNDNC: DNS, Resolving Domain Name, Change
DNDNE: DNS, Resolving Domain Name, End
DNDNI: DNS, Resolving Domain Name, Initiate
DNDNP: DNS, Resolving Domain Name, Print

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-248


Parameters for SIP/SIP-I
Parameter set: AXEMGCFCODECC
Parameter: ACTIVATION1/2/3/4/5 [ PCM / GSM-EFR / AMR(1) / AMR-HR(1) / AMR(7) ]
Parameter: PRIORITYSIP(I)1/2/3/4/5 (see above)

Parameter set: AXENODECODECC


Parameter: PROPERTY11/12/13/14/19/20
[ FR_AMR(1) / GSM_EFR / HR_AMR(1) / UMTS_AMR2(1) / FR_AMR-WB(0) / UMTS_AMR-WB(0) ]

Parameter set: SIPSUPPORTC


Parameter: PHCONTEXTP1 Sets 4 first digits of phone-context
Parameter: PHCONTEXTP2 Sets 4 last digits of phone-context
Parameter: PHONCONTLENG Sets length of phone-context par.
Parameter: SIPHOLDTONE Sets the generation of the “Hold” tone
Parameter: SIPACT/SIPTACT Feature activation SIP/SIP-I
Parameter: SIPTIMER1/2 SIP T1/T2
Parameter: SIPSATIND/SIPTSATIND Satellite indicator SIP/SIP-I

Parameter set: SIPBASUPC


Parameter: DIFFCLSIP Sets DSCP value for SIP/SIP-I (QoS)
Parameter: INACTIME Sets inactivity time interval after which
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-249 TCP connection is closed.
Supported and Prioritized Codecs
<DBTSP:TAB=AXEPARS,SETNAME=AXEMGCFCODECC;
DATABASE TABLE
Supported for SIP and SIP-I
BLOCK TAB TABLE WRAPPED
PARA AXEPARS YES

NAME SETNAME PARID VALUE UNIT CLASS DISTRIB


ACTIVATION1 AXEMGCFCODECC 10996 3 CUSTOM IMMED
STATUS FCVSET FCVALUE DCINFO FCODE
UPDATED FALSE 2 UNDEF Priority
0

NAME SETNAME PARID VALUE UNIT CLASS DISTRIB


PRIORITYSIPI1 AXEMGCFCODECC 10984 5 CUSTOM IMMED
STATUS FCVSET FCVALUE DCINFO FCODE
UPDATED FALSE 5 UNDEF 0

NAME SETNAME PARID VALUE UNIT CLASS DISTRIB


PRIORITYSIP1 AXEMGCFCODECC 10983 5 CUSTOM IMMED
STATUS FCVSET FCVALUE DCINFO FCODE
UPDATED FALSE 5 UNDEF 0
Payload Type: PCM

END
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-250
Counters for SIP/SIP-I 1(5)

Object Type SIPCODSTAT


INBCCALL Number of calls where 3GPP Narrow Band Compressed payload type is
applied on SIP/SIP-I route.
IPCMCALL Number of calls where PCM payload type is applied on SIP/SIP-I route.
ONBCCALL Number of calls where 3GPP Narrow Band Compressed payload type is
applied on SIP/SIP-I route
OPCMCALL Number of calls where PCM payload type is applied on SIP/SIP-I route.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-251


Counters for SIP/SIP-I 2(5)

Object Type SIPNODE


INSIPREQ Number of received SIP request messages
INSIPRES Number of received SIP response messages.
NASIPTRA Number of active SIP transactions.
NNFRESP Number of sent SIP requests without final response
NRINVITE Number of received INVITE requests.
NSFIADDR Number of session establishment request failures due to invalid address.
NSFSCAP Number of session establishment request failures due to server capability
mismatches.
NSIPQDNS Number of DNS queries invoked by SIP protocol.
NSIPSYERR Number of received SIP messages with syntax or size errors.
NSTCPCON Number of TCP connections used by SIP application.
NTOUTDNS Number of DNS look-up attempts due to time-out.
NUNRDNS Number of unresolved addresses due to failed DNS look-up attempts
NUSINVITE Number of unsuccessful INVITE attempts received.
ONSIPREQ Number of sent SIP request messages.
ONSIPRES Number of received SIP response messages.

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-252


Counters for SIP/SIP-I 3(5)
Object Type SIPROUT
IBUSYBN Number of rejected initial INVITE requests due to busy user. (I)
OBUSYBN Number of rejected initial INVITE requests due to busy user. (O)
IERISUP Number of rejected initial INVITE requests due to incorrect encapsulated
ISUP information. (I)
OERISUP Number of rejected initial INVITE requests due to incorrect encapsulated
ISUP information. (O)
IERRSDP Number of rejected requests due to unacceptable SDP offer. (I)
OERRSDP Number of rejected requests due to unacceptable SDP offer. (O)
INTERR Number of rejected initial INVITE requests due to server internal error.
INVNOFR Number of sent initial INVITE requests without received final response.
ISIPSES Number of initial INVITE requests. (I)
OSIPSES Number of initial INVITE requests. (O)
ISUCSES Number of successfully created initial INVITE requests. (I)
OSUCSES Number of successfully created initial INVITE requests. (O)
ITRMINV Number of cancelled initial INVITE requests. (I)
OTRMINV Number of cancelled initial INVITE requests. (O)
URI416 Number of rejected initial INVITE requests due to unsupported URI
scheme in Request-URI
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-253
Counters for SIP/SIP-I 4(5)

Object Type SIPROUT


INV3XX Number of initial INVITE requests rejected with 3xx final response.
IINV480 Number of rejected initial INVITE requests due to user unavailability. (I)
OINV480 Number of rejected initial INVITE requests due to user unavailability. (O)
IINV484 Number of rejected initial INVITE requests due to address incomplete. (I)
OINV484 Number of rejected initial INVITE requests due to address incomplete. (O)
IINV4XX Number of initial INVITE requests rejected with 4xx final response. (I)
OINV4XX Number of initial INVITE requests rejected with 4xx final response. (O)
IINV5XX Number of initial INVITE requests rejected with 5xx final response. (I)
OINV5XX Number of initial INVITE requests rejected with 5xx final response. (O)
IINV6XX Number of initial INVITE requests rejected with 6xx final response. (I)
OINV6XX Number of initial INVITE requests rejected with 6xx final response. (O)

© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-254


Counters for SIP/SIP-I 5(5)
Object Type VOIPROUT
IANSWER Number of B-answers.
IATPISUP Number of ATP received on ISUP routes.
IOVERFL Number of calls with congestion.
ITHROUGH Number of successful end of selections.
ITRALAC Accumulated number of occupied
LASTCONGCNT Number of congestions on the last available route.
NCALLSI Number of detected seizures, (inc. route). The counter is stepped up
when an accepted seizure is received.
NCALLSO Number of seizure attempts (bids), outgoing route.
NCONGNOIND Number of cong. due to route sw. individuals not available.
NCONGTRANS Number of congestions due no transmission resource available in BEACC.
NOSEIZ Number of outgoing seizures.
NSCAN Accumulated
NTRAFIND Number of (traffic) individuals in service.
OANSWER Number of B-answers.
OATPISUP Number of ATP received on ISUP routes.
OOVERFL Number of calls with congestion.
OTHROUGH Number of successful end of selections.
OTRALAC Accumulated number of occupied
TRALI Number of occupied devices in the route (inco. traffic level).
TRALO Number of occupied devices in the route (outg. traffic level).
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-255
© Ericsson AB 2015 | Introduction | LZU1089846 R1A | Figure 1-256

You might also like