BICC SIP Interworking

7/27/2019 BICC SIP Interworking

http://slidepdf.com/reader/full/bicc-sip-interworking 1/21



The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This document is not an officialcustomer document and Nokia Siemens Networks does not take responsibility for any errors or omissions in this document. This document is intended for the use of Nokia Siemens Networkscustomers only for the purposes of the agreement under which the document is submitted. Nopart of this documentation may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation hasbeen prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of thedocumentation.

The information or statements given in this documentation concerning the suitability, capacity or performance of the mentioned hardware or software products are given “as is” and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer.

IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, that might arise from the use of this document or the information in it.

THE CONTENTS OF THIS DOCUMENT ARE PROVIDED "AS IS". EXCEPT AS REQUIREDBY APPLICABLE MANDATORY LAW, NO WARRANTIES OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE MADE IN RELATION TO THE ACCURACY, RELIABILITY OR CONTENTS OF THISDOCUMENT. NOKIA SIEMENS NETWORKS RESERVES THE RIGHT TO REVISE THISDOCUMENT OR WITHDRAW IT AT ANY TIME WITHOUT PRIOR NOTICE.

This document and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners,and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2008. All rights reserved.

2 (21) # Nokia Siemens Networks DN0584997Issue 4-1 en draft

Feature 1451: BICC-SIP Interworking



Contents

Contents 3

List of figures 4

1 Feature description 51.1 Introduction 51.2 Benefits for the operator 61.3 Requirements for using the feature 81.3.1 Software 81.3.2 Hardware 81.3.3 Products 8

1.4 Functionality 91.4.1 General 91.4.2 Files 91.4.3 Statistics 91.4.4 Parameters 101.4.5 Charging 151.5 Capacity 151.6 Restrictions 161.7 Related and interworking features 161.8 Compliance 161.9 Operator interfaces 171.9.1 MMLs 17

1.9.2 Alarms 191.10 Subscriber interfaces 201.11 External interfaces 20

2 Changes in Feature 1451: BICC-SIP Interworking 212.1 Changes in the feature 212.2 Changes in the document 21

DN0584997Issue 4-1 en draft

# Nokia Siemens Networks 3 (21)

Contents



List of figures

Figure 1. MSC Server network environment 5





A basic interworking between the SIP and the BICC/ISUP has already

been implemented as part of Feature 1331: Session Initiation Protocol inthe MSC Server. The aim of this feature is to extend the interworking and

do it according to the current 3GPP/ITU-T standards. There are three

different profiles of SIP interworking defined by ITU-T:

. Profile A: 3GPP IMS IW

. Profile B: IETF SIP IW

. Profile C: SIP-T/I (interworking when ISUP tunnelling is used)

In the case of Profile C, the call control and the user plane handling hide

most of the interworking, and the tunnelled ISUP content provides theISUP feature transparency. Due to the ISUP feature transparency, the SIP-I does not require, for example, mapping of services, since Feature 1331:

Session Initiation Protocol in the MSC Server covers it already.

This feature handles the case when tunnelling is not used, and the BICC/

SIP functionalities and services have to be mapped to SIP. Both the User

Datagram Protocol (UDP) and the Transmission Control Protocol (TCP)

are supported as signalling transport for the SIP. In addition, semi-

permanent Stream Control Transmission Protocol (SCTP) associations

can be used optionally to transport SIP messages. With SCTP transport,

multi-homing can be used as well. The semi-permanent SCTP

associations are not dynamically created, but they are created before anySIP call, thus enabling quick re-routing if the association fails.

The feature is compliant with ETSI EN 383 001 standard, which provides

better interworking of FCI (Forward Call Indicator) and BCI (Backward Call

Indicator) ISUP parameters in case of UDI (CLEARMODE) calls and

mapping between ISUP cause code 24 and 433 (Anonymity Disallowed)

SIP response message.

1.2 Benefits for the operator SIP is designed to support Voice over IP (VoIP) and is the selected

protocol for 3GPP IM Subsystem (IMS) networks to establish, modify, and

terminate multimedia sessions or calls.

It is a text-based protocol which makes it flexible to accommodate services

and easy to implement service ideas. The SIP has excellent support for

multimedia, presence, messaging, and group services as a result of the

Internet Engineering Task Force (IETF) framework of protocols of which

the SIP can take advantage.





Interworking between the legacy call control protocols and the SIP is still

important to help with providing basic call services for those subscriberswho cannot use the SIP, as they have not migrated to the IMS domain, or

their equipment has no support for the IMS domain yet. The interworking is

necessary on message, parameter, and capability levels.

Due to the easily extensible nature of SIP, interworking must be provided

ranging from the basic SIP user agents with minimal or no support for SIP

extensions to the fully-fledged SIP user agents supporting all the SIP

extensions required by 3GPP or even some extensions that are not yet

widely accepted.

3GPP and ITU-T constantly improve the mapping between the BICC/ISUP

and the SIP service in order to improve subscriber satisfaction due to the

insufficient interworking between these protocols. The most important

benefit of this feature is to make this mapping available as soon as they

become known.

This feature also supports mid-call modification in speech phase.

However, as this functionality does not interwork between the IMS and the

CS side, the Transcoder-free Operation (TrFO) functionality is adversely

impacted by such codec modification.

To request URI tags, support for mapping number portability and carrier

selection (equal access) ISUP parameters have been added in order toprovide these features even when tunneling is not in use, as in case of

IMS.

The Extra FQDN Configuration, JN Command Group has been created toallow the defining of additional hosts to the Fully Qualified Domain Names

(FQDN) used in Session Initiation Protocol Circiut Group (SIP CGR)

creation. Route FQDN level parameters can also be configured in this way.

The additional hosts allow more flexible network topology as the incoming

request can be handled by the same SIP CGR as the outgoing request,

even if they come from a different network element (for example, outgoingrequests are sent to the Interrogating Call State Control Function (I-CSCF)

and incoming requests come from the Breakout Gateway Control Function

(BGCF) or directly from Serving Call State Control Function (S-CSCF)).

The route FQDN level parameters allow that different configuration is used

for each route, for example, the remote port can be different, or number

portability or carrier selection can be enabled/disabled per route.



Feature description



A useful enhancement is that Media Gateway Control Function (MGCF)

can work now in Call Mediation Node (CMN) mode. In this way, if incomingand outgoing user planes are similar, the usage of Media Gateway (MGW)

can be avoided. This enhancement is based on the merging of the

connected functionality with Nokia Siemens Networks Mobile Voice over

IP Server (NVS) and thus much configuration flexibility is taken from the

NVS. This, for example, allows that no Domain Name Server (DNS) is

used for own FQDN configuration.

A related enhancement is that MGCF can now also route multimedia

(video) calls to the interworking point, even if the MGW cannot support

Real-time Transport Protocol (RTP) video calls as the MGW is optimised

out of the user plane path. In this case, based on the Session Description

Protocol (SDP), the content correct call type (audio/multimedia) isindicated towards the call control and the user plane, and the call control

can route the calls differently.

The optional SCTP (with multi-homing support) has also been added to the

supported transport protocols for enhanced resilience.

MGCF also supports call transfer (Feature 1844, Call Transfer Support on

SIP) using the SIP REFER method.

1.3 Requirements for using the feature

1.3.1 Software

This feature has no special requirements for software.

1.3.2 Hardware

This feature has no special requirements for hardware.

1.3.3 Products

This feature functions in the DX MSC and in the server network products.

The functionality is the same.





1.4 Functionality

1.4.1 General

The MSC Server (MSS) offers all the circuit-switched call control

functionalities and services of the MSC and the 3G MSC, and provides a

clear evolution path from the current 2G circuit-switched networks (GSM)

to the 3G. This feature helps the evolution towards the IP Multimedia

Subsystem (IMS) architecture by implementing the Media Gateway

Control Function (MGCF) interface towards the IMS and the protocol

conversion between Session Initiation Protocol (SIP) and the call control

protocols used with the Mobile Services Switching Centre Server (MSS):

. SIP/Bearer Independent Call Control (BICC)

. SIP/Interconnect User Part (IUP)

. SIP/trunk/SS7 signalling

. SIP/Radio Access Network Application Part (RANAP)

This feature supports mid-call modification in speech phase. However, as

this functionality does not interwork between the IMS and CS side, TrFO

functionality is adversely impacted by such codec modification.

As the number portability and carrier selection (equal access) ISUP

parameters are also mapped to request URI tags, these features can be

used even when tunneling is not in use.

1.4.2 Files

There are no files directly visible to the operator.

1.4.3 Statistics

Not only the internal clear code reports generated by the call control, but

also the external signalling-specific clear codes are also reported to

determine the signalling-specific reason of the call release. For more

information on mapping between the external SIP-specific codes and the

internal cause codes, see Mapping of External Data, Mapping Document .

Signalling-specific clear code reports provide the operator with detailed

information on the SIP-specific reasons of call releases. SIP uses the

response codes specified in IETF RFC 3261.



Feature description



You can set both circuit groups and FQDNs as an object of the

measurement.

1.4.4 Parameters

. SIP_INVITE_RETRANS (052:0000)

This parameter determines the number of times the SIP messages

INVITE, 100 TRYING, and 18x must be retransmitted over an

unreliable transport system, that is, the User Datagram Protocol

(UDP).

. SIP_TIMER_T1 (052:0001)

This parameter determines the SIP timer T1 for the retransmission of

the exponential back-off expressed in milliseconds. For more

information, see IETF RFC 3261: SIP: Session Initiation Protocol,

June 2002.

. SIP_TIMER_T2 (052:0002)

This parameter determines the SIP timer T2 for the retransmission of

the requests other than INVITE, 100 TRYING, and 18x expressed in

milliseconds when the unreliable transport is used. For more

information, see IETF RFC 3261: SIP: Session Initiation Protocol,

June 2002.

. SIP_NON_INVITE_RETR (052:0004)

This parameter determines the number of times when the SIP

messages other than INVITE, 100 TRYING, and 18x must be

retransmitted over the unreliable transport protocol (that is, UDP).

. DSCP_FOR_SIGNALLING (053:0009)

SIP and other signalling applications use this parameter to set the

Differentiated Services code-point, carried in the Type of Service or

Traffic Class field in IPv4 and IPv6 headers, respectively. Theparameter can be set to any value between 0H and 03FH. For

definitions of the diffServ code-points and respective values, see

IETF RFC 2474: Definition of the Differentiated Services Field (DS

Field) in the IPv4 and IPv6 Headers, IETF RFC 2597: Assured

Forwarding PHB Group, and IETF RFC 2598: An Expedited

Forwarding PHB. For more information, see Quality of Service (QoS)

in DSCP mapping instructions of site routers .

. SIP_MAX_FORWARDS (052:0011)





This parameter determines the value of the Max-Forwards request

header field used to limit the number of Call State Control Functions(CSCF) through which a request can go. This parameter is used if no

Hop counter is received from the CS network.

. RETRY_AFTER_INTERVAL (052:0018)

This parameter determines the time in seconds the User Agent must

wait before resending any SIP requests to the MGCF.

. SIP_REFRESH_INT (052:0029)

This parameter defines the initial session refreshment interval value

used in SIP requests. If the actual value used in the session is not

acceptable to some servers, it can be bigger, but it cannot besmaller. The parameter is measured in seconds.

. SIP_REFRESH_MIN (052:0030)

This parameter defines the minimal session refreshment interval

value that can be accepted. If the SIP request contains a lower

value, it is rejected with the 422 (Session Interval Too Small)

response code. The parameter is measured in seconds. The

minimum value is 90 seconds, which is also the default value. Do not

set this parameter higher than the SIP_REFRESH_INT parameter (if it

is still set higher, the SIP_REFRESH_INT parameter is used instead).

. SIP_CONN_TIMEOUT (052:0025)

This parameter defines the maximum amount of inactivity time until

the TCP connection is open. If no message is sent or received

during the inactivity timeout, the connection is closed. The timeout is

measured in seconds.

. SIP_CONN_SETUP (0052:0031)

This parameter defines the maximum amount of time allowed to be

used for the TCP connection setup. If the connection cannot be

established during this time, the SIP falls back to the UDP. A fallback

to the UDP can happen earlier if the transport indicates some error,for example, the remote end does not listen to the connection. The

timeout is measured in tens of milliseconds.

. SIP_CIC_USAGE (052:0061)

This parameter controls whether to send and accept the Carrier

Identification Code (CIC) parameter in the Request URI of initial

INVITE requests. It has no effect on tunneling and access interfaces.

The possible values are:



Feature description



If this parameter is set to 'TRUE' when initial 'INVITE' is sent out, the

CIC is mapped to CIC parameter of the Request URI. When theinitial 'INVITE' is received, the CIC parameter of the Request URI is

mapped to the CIC.

If this parameter is set to 'FALSE', the CIC parameter is ignored

when 'INVITE' is received, and the CIC parameter is not added when

'INVITE' is sent.

. SIP_NPDI_USAGE (052:0062)

This parameter controls whether to send and accept the Number

Portability Indicator (NPDI) and the Routing Number (RN) parameter

in the Request URI of the initial 'INVITE' requests. It has no effect on

tunneling and access interfaces.

If this parameter is set to 'TRUE' when initial 'INVITE' is sent out, the

NPDI and RN are mapped to the NPDI and RN parameters of the

Request URI. When the initial 'INVITE' is received, the RN and NPDI

parameters of the Request URI are mapped to NPDI and RN.

If this parameter is set to 'FALSE', the NPDI and RN parameters are

ignored when 'INVITE' is received. NPDI and RN parameters are not

added when 'INVITE' is sent.

. PCS1900_EQUAL_ACCESS (002:0360)

For SIP, this parameter is used to determine whether PCS1900Equal Access is in use. Equal Access allows subscribers to pre-

subscribe or dial the long distance network.

. SIP_USE_DISPLAY_NAME (052:0059)

This parameter controls whether the 'Display Name' defined in IETF

RFC 3261 is included in the From and P-Asserted-Identity SIP

headers in outgoing initial 'INVITE' requests.

If the parameter is set to zero, 'Display Name' is not added to any of

the headers. Parameter values 1, 2, and 3 control if 'Display Name'

is added only to From, only to P-Asserted-Identity, or bothrespectively.

. USE_DIVERSION_HEADER (052:0060)

This parameter is used to control whether to send and accept SIP

Diversion Header in the initial 'INVITE' requests.





If this parameter is set to 'TRUE', when the initial 'INVITE' is sent out,

the Original Called Party Number, Redirecting Number, CallForwarding Counter and Call Forwarding Reason are mapped to the

Diversion Header. When the initial 'INVITE' is received, the Diversion

Header is mapped to the Original Called Party Number, Redirecting

Number, Call Forwarding Counter and Call Forwarding Reason.

If this parameter is set to 'FALSE', Diversion Header is ignored when

'INVITE' is received, and Diversion Header is not added when

'INVITE' is sent.

. SIP_CCBS_MAPPED (052:0063)

This FIFILE parameter is used to control if the Completion of Calls to

Busy Subscribers (CCBS) related call and release indications aremapped to the SIP.

If this parameter is ON/'TRUE', CCBS related parameters in Allow-

Events and Call-Info are mapped between SIP and other MSS

signallings.

If this parameter is OFF/'FALSE', CCBS related parameters are not

generated in outgoing SIP messages/ignored when received in

incoming SIP messages.

. SIP_CPC_MAPPED (052:0064)

This FIFILE parameter is used to control if Calling Party Category(CPC) related parameters are mapped between the ISUP/BICC and

the SIP.

If this parameter is ON/'TRUE', the CPC related parameters' cpc tag

in the P-Asserted-Identity SIP header, and the language tag in the

Accept-Contact SIP header are mapped between SIP and other

MSS signallings.

If this parameter is OFF/'FALSE', CPC related parameters are not

generated in outgoing SIP messages/ignored when received in

incoming SIP messages.

. MSC_MGCF_SUPPORT (002:1321)

This FIFILE parameter can be used to activate the MGCF

functionality in MSC Server. In addition to this parameter,

appropriate CNTROL file records (SI3MX:3GPP, SI7MX:IETF/IP

Centrex) need to be taken into use.

. SIP_IP_CENTREX_SUPP (052:0045)

This FIFILE parameter can be used to activate the SIP IP Centrex

interface. In addition to this parameter, the appropriate MGCF

CNTROL file record needs to be taken into use.



Feature description



. SIP_MGCF_CMN_SUPP (052:0066)

This FIFILE parameter can be used to activate the support of CMNmode in the MGCF interface. Even if the MGCF interface is active,

the CMN mode requires separate activation.

. VOIP_MM_SUPPORT (052:0040)

This FIFILE parameter is used to control if SIP based multimedia

(video) calls are allowed.

If this parameter is ON/'TRUE', the subscribers can initiate SIP

multimedia calls.

If this parameter is OFF/'FALSE', the subscribers cannot initiate SIP

multimedia calls. The SIP multimedia calls are downgraded to

speech calls.

. VOIP_REMOTE_PORT (052:0041)

This parameter determines the default SIP remote port number that

is used to send the request out.

If the port is defined on route/FQDN level, then it is taken into use

instead of this parameter.

. ALLOW_CALL_DIVERSION (052:0034)

This PRFILE parameter indicates whether the SIP call diversion isallowed.

If this parameter is set to 'TRUE', SIP call diversion is allowed. When

outgoing signalling receives 302 'Moved Temporarily' or 301 'Moved

Permanently' responses and it contains a new number or FQDN, the

call diversion is started to the received address.

If this paramter is set to 'FALSE', SIP call diversion is not allowed.

When outgoing signalling receives 302 'Moved Temporarily' or 301

'Moved Permanently' responses, the Contact address is not used

and the call is cleared.

. SIP_TIMER_T4 (052:0035)

This parameter defines the SIP timer T4 which, in case of Non-

INVITE Client Transaction, represents the amount of time the

network needs to clear the messages between client and server

transactions as described in IETF RFC 3261.

. MSC_VOIP_TCP_SUPP (002:1219)

This FIFILE parameter defines whether the TCP can be used for the

outgoing SIP requests and responses (if not, the UDP is used). This

parameter controls TCP use on all SIP interfaces.





If this parameter is ON/'TRUE', TCP is allowed to be used.

If this parameter is OFF/'FALSE', TCP is not allowed to be used.

. SIP_CONN_TCP_USED (052:0043)

This parameter defines whether the outgoing requests are sent out

using the TCP if the local policy (for example, transport protocol of

registered contact) allows it.

If this parameter is set to 'TRUE', the outgoing SIP requests are sent

out using TCP regardless of the message size. However, if the local

policy defines UDP (for example, the transport protocol of registered

contact), the UDP is used.

If this parameter is set to 'FALSE', a SIP request is sent out with the

TCP if the message size exceeds 1300 Byte or the local policy

requires it.

. TCP_ACTIVATED_ON_NET_IF (052:0049)

This PRFILE parameter controls whether the TCP can be used for SIP requests and responses. This parameter controls TCP use on

the trunk SIP interfaces.

1.4.5 Charging

P-Charging-Vector SIP header is supported. Other headers specified in

the 3GPP IMS related to charging are planned to be supported in later

releases.

1.5 Capacity

12 CCSU/SIGU units can be used for resource calculation with the target 1

M Number of Busy Hour Call Attempts (BHCA), that is, with 25 000

simultaneous calls. The BHCA values are the following:

. for the integrated MSS: 600 K BHCA

. for the standalone MSS: 1 million BHCA

. for the Gateway Control Server (GCS): 2 million BHCA

Mapping between the BICC/ISUP and the SIP adds more to the load of the

CCSU/SIGU units than other legacy signalling protocols due to the text-

based nature of the SIP and flexibility in protocol operation.



Feature description



1.6 Restrictions

There are no restrictions relevant to the functionality of this feature.

1.7 Related and interworking features

. Feature 543: Signalling Specific Clear Code Reports

Signalling specific clear code reports are created for all the available

signalling protocols.

. Feature 1267: ISUP Hop Counter

The ISUP Hop Counter procedure is used to detect call setup

looping that can be caused by incorrect routing data for routing ISUP

messages.

. Feature 1330: Bearer Independent Call Control (BICC)

This feature implements one of the three protocols (BICC, RANAP,

and SIP) for the MSS. The BICC enables interworking between

legacy networks and 3G UMTS networks in the evolution towards an

all-IP network.

. Feature 1331: Session Initiation Protocol in the MSC Server

This feature implements SIP framework and SIP profiles where due

to the support of ISUP tunneling only a limited protocol mapping is

required.

. Feature 1335: Speech Transmission Optimisation in MSC Server

This feature describes the implementation of TrFO and Tandem Free

Operation (TFO) in the MSS network element. The TrFO completely

removes the unnecessary transcoding from the speech path. In

TFO, with the help of a mechanism performed by the transcoders

using inband signalling, peer transcoders are able to communicateusing bit-robbing signalling inside a 64 kbit/s established channel.

. Feature 1844: Call Transfer Support on SIP

MGCF also supports call transfer using the SIP REFER method.

1.8 Compliance

This feature is supported in 3G.





The feature is compliant with the following 3GPP and ITU-T specifications:

. 3GPP TS 24.229 Internet protocol (IP) multimedia call Control

protocol based on Session Initiation Protocol (SIP) and Session

Description Protocol (SDP); Stage 3, v6.7-0, June 2005

. 3GPP TS 29.163 Interworking between the IP Multimedia (IM) Core

Network (CN) subsystem and Circuit Switched (CS) networks, v6.7-

0, June 2005

. ITU-T Q.1912.5 Interworking between Session Initiation Protocol

(SIP) and Bearer Independent Call Control or ISDN User Part

. ETSI EN 383 001 Interworking between Session Initiation Protocol

(SIP) and Bearer Independent Call Control (BICC) Protocol or ISDN User Part (ISUP), Ver. 1.1.1

1.9 Operator interfaces

1.9.1 MMLs

Circuit Group Handling, RC Command Group

With the help of the RC command group, you can

. create a circuit group

. add circuits to a circuit group

. modify the features of circuits or circuit groups

. delete circuit groups or circuits from a circuit group

. interrogate the features of circuit groups or circuits

The relevant commands are:

RCA ADD CIRCUITS TO CIRCUIT GROUP

This command is used to add circuit(s) to a circuit

group.

RCC CREATE CIRCUIT GROUP

This command is used to create different types of

circuit groups: CCS, CAS, DCS, SIP, IPT, and special

circuit groups.



Feature description



The parameters used in this feature are the following:

. FQDN of the adjacent Network Element (NE)

. CNTROL index (Line Signalling Index (LSI))

. Auxiliary Signalling Index (ASI)

. Circuit Group (CGR) type (SIP)

For more information on the commands and their parameters, see Circuit

Group Handling, RC Command Group.

Route Handling, RR Command Group

With the help of the commands of the RR command group, you can

. create a route with circuit groups

. add circuit groups to a route

. modify the external route characteristics

. delete a route or circuit groups from a route

. carry out an interrogation of the characteristics of a route

Before you use the commands of this command group, the circuit groups

must be created by using the commands of the RC command group.

For more information on the commands and their parameters, see Route

Handling, RR Command Group .

Route (FQDN) level SIP Parameter Handling, JN Command Group

With the help of the JN command group, you can

. add additional hosts to the given Fully Qualified Domain Name

(FQDN)

. remove additional hosts

. inquire additional hosts

. delete all added hosts and parameters

. list all FQDNs that have additional host

. modify the route of FQDN level parameters

. create and copy the route of FQDN parameters





The additional hosts are used as an alternative to select the SIP Circuit

Group (CGR) in incoming requests. Normally, with the help of FQDN givenin SIP CGR creation you can identify which SIP CGR you can use. The

additional hosts can be either IPv4 or IPv6 based. You can apply FQDN

level parameters to influence the handling of SIP messages.

SIP Parameter Configuration Handling, JH Command Group

With the help of the JH command group, you can configure switch level

domain name to be used with the SIP in CCSU/SIGU.

SIP Addres Configuration Handling, JI Command Group

With the help of the JI command group, you can configure IP addresses tobe used with CCSU/SIGU units and unit level domain names.

1.9.2 Alarms

The following alarms are used to indicate malfunctional cases in this

feature:

. 0121 IP CONTROL PLANE UNAVAILABLE

This notice is set when there is no response at all after INVITErequests (call setups) have been sent. There is no response either

because the remote FQDN was not found in the DNS, or because

the DNS query resulted in an IP address, but there is no response

from the remote side which indicates that the DNS contains an

incorrect IP address, or because the SIP signalling connection

between the two signalling processes is broken. The alarm output

contains the IP address of the remote end as an array of 16 bytes

and can hold both IPv4 and IPv6 addresses.

. 1233 IP ENTITY IS NOT REACHABLE

This alarm is set when the packet sent to the IP address comingfrom the DNS query does not reach its destination.

. 1235 FQDN NOT PRESENT IN IEIFIL

This alarm is set when the network is not configured properly. The

ZSC process writes the FQDN that caused the error to the log.

. 3220 IP CONTROL PLANE REPEATEDLY UNREACHABLE

This alarm is an error ratio counter alarm, set when the number of

unsuccessful call attempts indicated by several 0121 notices

reaches a limit. After alarm 3220 is set, notice 0121 is not set

anymore until alarm 3220 is cleared.



Feature description



1.10 Subscriber interfaces

This feature has no subscriber interfaces.

1.11 External interfaces

The feature complies with 3GPP/ITU-T specifications and is used to

implement the SIP signalling interface of the MGCF controlling the MGW.

External interfaces:

1. 3GPP IMS

Roles defined by the 3GPP IMS are MGCF and Proxy, and

Interrogating and Serving Call State Control Functions (P/I/S-

CSCF). The MGCF and I-CSCF are connected by the Mg interface

while the MGCF and the Breakout Gateway Control Function

(BGCF) are connected by the Mj interface. SIP is used to implement

the IMS-CS interworking in this interface. The interworking includes

support for voice calls between the IP Multimedia (IM) Core

Networks (CN) subsystem and CS networks, and support for

supplementary services like Calling Line Identification Presentation(CLIP)/Calling Line Identification Restriction (CLIR), and Connected

Line Presentation (COLP)/Connected Line Restriction (COLR). This

interface offers a wide range of functionalities like 3GPP defined 'P-'

headers and the offer/answer model. Number portability and carrier

selection related URI tags are also supported, even though currently

not required by the 3GPP.

2. IETF Proxy

This interface implements Profile B from the ITU-T Q.1912.5 Interworking between Session Initiation Protocol (SIP) and Bearer

Independent Call Control or ISDN protocols, March 2004 standard. It

is similar to the 3GPP IMS interface, but, by default, no 3GPP-

specific extensions are required. For example, it is assumed that

preconditions cannot typically be used by the user agents, and

privacy-related headers are not supported by all the proxies to the

user agent. Similarly to the 3GPP IMS interface, the Nb-UP framing

protocol is not used in the user plane stack of this interface.





2 Changes in Feature 1451: BICC-SIP

Interworking

2.1 Changes in the feature

Changes in the feature between releases M14.2 and M14.1

Support for Feature 1844: Call Transfer Support on SIP has been added.

Changes in the feature between releases M14.1 and M14.0

Support for ETSI EN 383 001 compliance has been added.

2.2 Changes in the document

Changes made between issues 4-1 and 4-0

Editorial changes have been made.

Changes made between issues 4-0 and 3-0

The company and product names have been changed according to the

official Nokia Siemens Networks portfolio naming.

DN0584997 # Nokia Siemens Networks 21 (21)

Changes in Feature 1451: BICC-SIP Interworking

BICC SIP Interworking

Documents

Transcript of BICC SIP Interworking