5. 5
Feature 1331: Session Initiation Protocol in the MSC
Server
Feature description
Id:0900d80580651393
1 Feature description
1.1 Introduction
Tele and data communications enable users to access multiple services regardless of
where they are or what time it is. The Internet Protocol (IP) is seen as the dominant
network level protocol, and applications are written on top of it. In the evolution toward
an all-IP network, Feature 1331: Session Initiation Protocol in the MSC Server helps the
interworking of legacy circuit-switched networks with Third Generation Universal Mobile
Telecommunications System (3G UMTS) IP multimedia networks.
The Session Initiation Protocol (SIP) is implemented to create and manage multimedia
sessions between two or more participants over the Internet in 3G networks. The
general aim of SIP is to support Voice over IP (VoIP) and to ensure that future VoIP
services be fully Internet-based.
This feature works with other MSC Server (MSS) features and implements the Media
Gateway Control Function (MGCF) in the MSS. Between MSSs both SIP-T (Internet
Engineering Task Force (IETF)) and SIP-I (International Telecommunications Union
(ITU-T)) can be used.
Note that the SIP-T interface in the MSS implementation corresponds to a special SIP-
I configuration. Due to this the SIP-T interface definition dates back earlier than many of
the SIP extensions (such as the UPDATE method), and also lacks the discussion of
many issues that are important from an interoperability point of view. Nokia Siemens
Networks recommends using the SIP-I interface whenever the interconnection of differ-
ent vendor's ISUP tunneling SIP interfaces is necessary.
Only SIP without ISUP tunneling is used toward the IMS. Session refreshment
messages are supported on all interfaces.
A major benefit of this feature is that it connects Circuit-Switched (CS) and IP Multimedia
Subsystem (IMS) domains, and provides an open ISUP tunneling SIP trunk (soft switch)
interface (SIP-I) that can be used between MSSs or toward other equipment that
possess SIP-I interfaces such as VMSs (Voice Mail Systems), ATA (Analog Telefone
Adapters), SIP-I gateways and so on.
SIP-I is preferred between MSSs since it supports GSM or ISDN services more effec-
tively. Both European Telecommunications Standardisation Institute (ETSI) and
American National Standards Institute (ANSI) ISUP tunneling are supported.
6. 6
Feature 1331: Session Initiation Protocol in the MSC
Server
Id:0900d80580651393
Feature description
Figure 1 MSC Server interfaces
This feature complies with 3GPP IMS standards and with the relevant IETF standards.
It also aims to be compliant with the SIP-I interface defined in 3GPP for the Nc interface
in 3GPP TS 23.231 when standardization is complete. Both the User Datagram Protocol
(UDP) and the Transmission Control Protocol (TCP) are supported as signaling trans-
port for 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 also be used.
Semi-permanent SCTP associations are not created dynamically, but exist long before
the SIP calls are placed, thus enabling quick re-routing should the associations fail.
This feature has been improved to interwork with Bearer Independent Call Control
(BICC).
The BICC interworking enhancements of Feature 1451: IMS-CS Interworking include:
• service interworking
• interworking with non-3GPP SIP profiles (ITU-T Recommendation Q1912.5 Inter-
working between Session Initiation Protocol (SIP) and Bearer Independent Call
Control protocol or ISDN User Part, Profile B)
• Media Gateway (MGW) usage optimization
Extra support for business solutions in VoIP telephony on all SIP interfaces has been
provided through Support for SDP-less INVITE functionality.
7. 7
Feature 1331: Session Initiation Protocol in the MSC
Server
Feature description
Id:0900d80580651393
More standardized routing capabilities have been added through the use of Trunk group
(RFC4904) support for IP peering functionality.
1.2 Benefits for the operator
SIP is designed to support VoIP, and is the selected protocol for 3GPP IMS networks to
establish, modify, and terminate multimedia sessions or calls.
SIP is text-based, which makes it relatively easy to implement and maintain .It is also
extensible and modular. Modularity allows the implemenattion of SIP clients in different
device categories from small devices with limited capabilities to desktop computers with
full features. SIP has its own reliability system, and runs over any protocol that provides
byte stream or datagramservices.
Feature 1331: Session Initiation Protocol in the MSC Server is part of the signaling
services in the Network-Network Interface (NNI) and has been designed to improve the
interworking between legacy networks and 3G UMTS networks in the evolution toward
an all-IP network. This feature works with other MSS features and implements the
MGCF of the 3GPP reference architecture.
Session Initiation Protocol in the MSC Server is needed for MGCF toward the IMS
(3GPP IMS). It provides a clear evolutionary path toward an all-IP MGCF, and can be
used as a signaling protocol between MSSs (3GPP CS networks).
Between MSSs, both SIP-T (IETF) and SIP-I (ITU-T) can be used as an alternative to
BICC.
This feature allows the flexible building of 3GPP CS networks when IP is used as the
bearer and flexible connection of the IMS (3GPP IMS) and the bearer independent CS.
Session refreshment messages are supported on all interfaces.
Both UDP and TCP are supported as transport protocols for SIP, the dynamic selection
of the transport being based on the size of the SIP message. Fallback to UDP is also
supported if the peer network element does not support TCP. In addition, semi-perma-
nent SCTP associations can be used optionally to transport SIP messages. With SCTP
transport, multi-homing can be used as well, thus further enhancing resilience. The
semi-pemanent SCTP associations are not created dynamically, but precede any SIP
call, thus enabling quick re-routing should the associations fail. If SCTP is configured for
use, it is always used independently of the message size.
Furthermore, this feature allows mid-call modification in speech phase; however, as this
functionality does not interwork between the IMS and CS sides, Transcoder-free Oper-
ation (TrFO) functionality is adversely impacted by such a codec modification.
In addition, support for controlling the most important SIP parameters (for example, the
remote port, number portability mapping, carrier selection mapping) at SIP CGR level
has been introduced. Transport selection, for example, SCTP, can also be controlled in
the same way as FQDN.
Due to CMN mode enhancements based on NVS functionality, MSS and NVS SIP-
based features use a more coherent and consistent configuration.
The OPTIONS message can be used to check the reachability of the SIP application. It
is sent to all IP addresses that are targetable for SIP requests as a means to closely
monitor each IP address for reachability. If these IP addresses are not available for SIP
requests, traffic to them is prevented so that the calls can be re-routed without delay,
enabling a quicker response time than session-based refreshment.
8. 8
Feature 1331: Session Initiation Protocol in the MSC
Server
Id:0900d80580651393
Feature description
Under normal conditions there is no need to use virtual circuits with SIP; however, using
them can be beneficial in the following cases:
• When priority services rely on the queuing of some resources, and one such
common resource is a virtual circuit.
• When a number of parallel calls to a particular peer need to be limited.
• When only a particular signaling unit (that is, an IP address) needs to be used toward
a particular peer.
The cases described above show that the use of virtual circuits is most beneficial when
SIPis used in place of a circuit switched network.
The use of virtual circuit groups with SIP is an optional subfeature and is, thus, licensed.
For more information on its activation, see Feature 1331: Session Initiation Protocol in
the MSC Server, Feature Activation Manual.
Further enhancements including Support for SPD-less INVITE and Trunk group
(RFC4904) support for IP peering have been made which together enhance the MSS’s
IP to IP interconnection capabilities and offer a standards compliant solution for opera-
tors desirous to address the business VoIP sector.
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 Nokia Siemens NetworksDX MSC and MSC Server (MSS).
1.4 Functionality
1.4.1 General
The MSS can offer all circuit-switched call control functionalities and services of the
MSC and the 3G MSC, and provides a clear evolutionary path from the current 2G
circuit-switched networks (GSM) to 3G. This feature implements the SIP signaling inter-
face of the MGCF toward the IMS, and implements protocol conversion between the SIP
and call control protocols used with the MSS:
• SIP/Bearer Independent Call Control (BICC)
• SIP/Interconnect User Part (IUP)
• SIP/trunk/SS7 signaling
• SIP/Radio Access Network Application Part (RANAP)
This feature handles both control plane (related to call setup) and user plane (related to
bearer setup) information but does not directly control the bearer.
9. 9
Feature 1331: Session Initiation Protocol in the MSC
Server
Feature description
Id:0900d80580651393
Support for mid-call modification in the speech phase has been introduced; however, as
this modification does not provide interworking between IMS and CS, TrFO functionality
is adversely impacted by such codec modifications.
Support for SDP-less INVITE
The lack of Session Description Protocol (SDP) is important when a call is initiated by a
device which does not want to participate in the user plane of that call. It acts as a con-
trolling party only. As such, it can offer additional services, for example, customization,
call forwarding, blocking and waiting rules, voice mailbox handling, click-to-dial and
other related GUI services.
This subfeature allows such a device to directly control an MSS, thus enabling mobile
operators to offer the most modern call features to both residential and enterprise mobile
customers alike.
Trunk group (RFC4904) support for IP peering
In the case of IP-IP interconnections there are additional SIP-proxies, session board
controllers (SBCs) between the actual endpoints of trunk connections. MSSs have a rich
set of routing capabilities, whereas SBC routing is often based on only one routing
parameter.
In order to improve the interoperability between an MSS and an SBC, support for Trunk
group functionality has been implemented in MSSs (based on the RFC 4904 standard).
This functionality enhances the MSS’s IP-IP interconnection capability by introducing
standardized routing. It also provides more flexibility for routing through SBCs.
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 signaling-specific clear codes are reported to determine the signaling-specific
reason of the call release. For more information on mapping between the external SIP-
specific and the internal cause codes, see Mapping of External Data.
Signaling-specific clear code reports provide detailed information on the SIP-specific
reasons for call releases. SIP uses the response codes specified in IETF RFC 3261:
SIP: Session Initiation Protocol.
Until recently only the circuit groups could be set as an object of measurement. Due to
feature enhancement, however, you can set a Fully Qualified Domain Name (FQDN) for
SIP.
In the case of SIP signaling response codes, extra BYE and CANCEL requests are
counted as release causes when the call is released. When the ISUP is tunneled in SIP
messages, the signaling-specific reasons of call releases can be found in the ISUP-
specific measurement data.
Protocol measurement is not supported.
For more information on changes in statistics-related protocols, see Feature 543: Sig-
naling Specific Clear Code Reports, Feature Description.
10. 10
Feature 1331: Session Initiation Protocol in the MSC
Server
Id:0900d80580651393
Feature description
1.4.4 Parameters
• SIP_INVITE_RETRANS (052:0000)
This parameter determines the number of times the INVITE, 100 TRYING, and 18x
SIP messages have to be retransmitted over an unreliable transport system, that is,
a User Datagram Protocol (UDP).
• SIP_TIMER_T1 (052:0001)
This parameter determines the SIP timer T1 for the retransmission of exponential
back-off expressed in milliseconds. For more information, see IETF RFC 3261 - SIP:
Session Initiation Protocol.
• SIP_TIMER_T2 (052:0002)
This parameter determines SIP timer T2 for the retransmission of requests other
than INVITE, 100 TRYING, and 18x expressed in milliseconds when an unreliable
form of transport is used. For more information, see IETF RFC 3261 - SIP: Session
Initiation Protocol.
• SIP_NON_INVITE_RETR (052:0004)
This parameter determines the number of times that SIP messages other than
INVITE, 100 TRYING, and 18x must be retransmitted over unreliable transport pro-
tocols (that is, UDP).
• DSCP_FOR_SIGNALLING (053:0009)
SIP and other signaling applications use this parameter to set the Differentiated
Services Code Point (DSCP), carried in the Type of Service or Traffic Class field in
IPv4 and IPv6 headers, respectively. This parameter can be set to any value
between 0H and 03FH.
• 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) which a request can
transfer. 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 that the User Agent must wait before
resending any SIP requests to the MGCF.
• SIP_REFRESH_INT (052:0029)
This parameter defines the value of the initial session refreshment interval used in
SIP requests. If the actual value used in the session is not acceptable to some
servers; note, the interval value can be higher, but not lower. This 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 displaying the 422
Session Interval Too Small response code. This parameter is measured in seconds.
The minimum value is 90 seconds, which is also the default value.
• SIP_REFRESH_MIN (052:0030)
Do not set this parameter higher than the SIP_REFRESH_INT parameter (if it is
nevertheless set higher, the SIP_REFRESH_INT parameter is used instead).
• SIP_CONN_TIMEOUT (052:0025)
This parameter determines the maximum amount of inactivity time during which the
TCP connection is kept open. If no message is sent or received during the inactivity
period, the connection is closed. The timeout is determined in seconds. The possible
values are:
10 seconds Minimum value.
11. 11
Feature 1331: Session Initiation Protocol in the MSC
Server
Feature description
Id:0900d80580651393
28800 seconds Maximum value.
1800 seconds Default value.
Special value 0 The connection is never closed.
Special value 1 The connection can only be closed once all call handling hands
have terminated.
• SIP_CONN_SETUP (052:0031)
This parameter determines 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 UDP can already happen earlier if the trans-
port indicates some error, for example, the remote end does not listen to the con-
nection.
The timeout is determined in tens of milliseconds. The possible values are:
20 (200 ms) Minimum value.
2000 (20 seconds) Maximum value.
500 (5 seconds) Default value.
Special value 0 the SIP waits until the transport gives up the connection setup
• SIP_USE_DISPLAY_NAME (052:0059)
This parameter controls whether the 'Display Name' defined in IETF RFC 3261: SIP:
Session Initiation Protocol, June 2002 is included in the From and P-Asserted-
Identity SIP headers in outgoing initial INVITE requests.
If the parameter is set to zero, the display-name is not added to the headers.
Parameter values 1, 2 and 3 Control whether the display-name is added to From
only, to the P-Asserted-Identity only, or to both respectively.
• MSC_SIP_TUNNELING_SUPPORT (002:1320)
This FIFILE parameter activates the SIP ISUP tunneling (SIP-I and SIP-T) function-
ality in MSS. In addition to this parameter, appropriate CNTROL file records
(SI4MX:SIP-T, SI6MX:SIP-I) need to be taken into use.
• 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 at the route/FQDN level, it is taken into use
instead of this parameter.
• SIP_TIMER_T4 (052:0035)
This parameter defines the SIP timer T4 which, in the case of Non-INVITE Client
Transactions, represents the amount of time the network needs to clear messages
between the client and the server as described in IETF RFC 3261: SIP: Session Ini-
tiation Protocol, June 2002.
• 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, UDP is used). This parameter controls the use of
TCP on all SIP interfaces. The possible values are:
ON/'TRUE' TCP is allowed to be used.
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 TCP
should the local policy (for example, transport protocol of registered contact) allows
it. The possible values are:
'TRUE' The outgoing SIP requests are sent out using TCP regardless of the
message size. However, if the local policy defines UDP (for
example, transport protocol of registered contact), UDP is used.
12. 12
Feature 1331: Session Initiation Protocol in the MSC
Server
Id:0900d80580651393
Feature description
'FALSE' The SIP request is sent out with 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 TCP can be used for SIP requests and
responses. This parameter controls TCP usage on trunk SIP interfaces.
• SIP_OPTIONS_PING_SUPP (002:1399)
This FIFILE parameter activates the reachability checking functionality on SIP trunk
interfaces using the SIP OPTIONS method. The possible values are:
TRUE The feature is active. The configured neighboring elements are peri-
odically checked for availability.
FALSE The feature is inactive; no reachability check is done.
• SIP_OPTIONS_DNS_TIMER (052:0072)
This PRFILE parameter sets the DNS query timer for the OPTIONS reachability
check. When the reachability check with the SIP OPTIONS message is activated,
the DNS is queried periodically to check whether or not the DNS configuration of an
FQND has been changed. The PRFILE controls the periodicity.
The timer value is determined in minutes.
20 Minimum value.
360 (6 hours) Maximum value.
60 (1 hour) Default value.
• SIP_NOSDPINVITE_SUPP (002:1538)
This FIFILE parameter defines whether or not the operator is able to allow Support
for SDP-less INVITE in the MSC Server. The INVITE without SDP is used in 3rd
party call control scenarios. The possible values are:
TRUE The feature is active.
FALSE The feature is inactive. (Default value)
• SIP_TRUNK_GROUP_SUPP (002:1559)
Trunk group (RFC4904) support for IP peering can be activated using this FIFILE
parameter. this means that the operator can use the SIP trunk group ID feature on
incoming and outgoing SIP interfaces.
TRUE The feature is active. Trung Group IDs are used for incoming CGR
selection and included in outgoing SIP messages.
FALSE The feature is inactive. The incoming CGR selection is performed
based on the top most Via header. As a result Trunk Group IDs are
not included in outgoing SIP messages. (Default value)
• SIP_TRUNK_CONTEXT_USED (052:0086)
The use of the trunk-context parameter in outgoing SIP messages can be activated
using this PRFILE parameter, but only if the subfeature Trunk group (RFC4904)
support for IP peering is active. The default value for this parameter is FALSE, indi-
cating that the trunk-context parameter is not used.
• SIP_TGRP_NORM_ACC_ALLOW (052:0087)
Trunk Group ID parameter usage on the SIP normal access interface is controlled
by this PRFILE parameter, but again, only if the subfeature Trunk group (RFC4904)
support for IP peering is active.
1.4.5 Charging
This feature has no effects on charging.
13. 13
Feature 1331: Session Initiation Protocol in the MSC
Server
Feature description
Id:0900d80580651393
1.5 Capacity
12 CCSU/SIGU units can be used for resource calculations with a target of 1million Busy
Hour Call Attempts (BHCA) during 25 000 simultaneous calls. The BHCA values are the
following:
• for integrated MSS: 600 K BHCA
• for standalone MSS: 1 million BHCA
• for the Gateway Control Server (GCS): 2 million BHCA
This feature adds increases the load on the CCSU and SIGU units, more so than other
legacy signaling protocols.
1.6 Restrictions
• ANSI and ETSI ISUP tunneling cannot be used simultaneously.
• Round-trip Time (RTT) estimation is not used. The value of the T1 timer is defined
by SIP, based on a PRFILE parameter.
• The OPTIONS message returns the supported codes in the message body only. No
indication of supported tones, announcement packages or conferencing options is
returned.
• The ISUP version used to tunnel in the SIP is tied to the FQDN of the peer node.
1.7 Related and interworking features
This feature interworks with the following features:
Feature 543: Signaling Specific Clear Code Reports
Signaling specific clear code reports are created for all available signaling protocols.
Feature 1267: ISUP Hop Counter
The ISUP Hop Counter procedure is used to detect call setup looping caused by incor-
rect routing data for routing ISUP messages.
Feature 1330: Bearer Independent Call Control (BICC)
This feature implements one of three protocols (BICC, RANAP, or SIP) for the MSS.
BICC enables interworking between legacy networks and 3G UMTS networks in the
evolution toward an all-IP network.
Feature 1335: Speech Transmission Optimization in the MSC Server
This feature describes the implementation of TrFO and Tandem Free Operation (TFO)
in the MSS network element. TrFO completely removes unnecessary transcoding from
the speech path. In TFO, with the help of a mechanism performed by the transcoders
using inband signaling, peer transcoders are able to communicate using bit-robbing sig-
naling inside a 64 kbit/s established channel.
Feature 1451: IMS-CS Interworking
The BICC protocol and SIP are the types of signaling used in the ISN, where there is
interworking between the IMS and the CS network. The aim of this feature is to extend
the interworking between BICC and SIP, and to implement it according to current
3GPP/ITU-T standards.
14. 14
Feature 1331: Session Initiation Protocol in the MSC
Server
Id:0900d80580651393
Feature description
1.8 Compliance
This feature is supported in 3G.
The SIP-I interface is compliant with ITU-T Q.1912.5 (Interworking between Session Ini-
tiation Protocol (SIP) and Bearer Independent Call Control protocol or ISDN User Part)
specification.
The feature also aims to be compliant with the SIP-I interface defined in 3GPP in TS
23.231 (SIP-I based circuit-switched core network) once standardization is completed.
The interface toward IMS (Mg/Mj) complies with the relevant 3GPP recommendation
specifications:
• 3GPP TS 24.229 IP Multimedia Call Control Protocol based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 7), v7.7.0,
March 2007
• 3GPP TS 29.163 Interworking between the IP Multimedia (IM) Core Network (CN)
subsystem and Circuit Switched (CS) networks (Release 7), v7.6.0, March 2007.
For outgoing messages the use of the Trunk Group ID parameter in the Contact header
is optional.
For outgoing messages the use of the trunk-context parameter controlled by the PRFILE
parameter SIP_TRUNK_CONTEXT_USED (052:0086) is optional. For incoming mes-
sages, however, the trunk-context parameter is ignored, thus even if the parameter does
not exist, the Trunk Group ID parameter is still used for MFQDN and CGR lookups.
Both trunk group parameters Trunk Group ID and trunk-context are included in the URI’s
domain part instead of the user part.
On the ISC interface the local trunk group parameters are read from the top-most route
header.
1.9 Operator Interfaces
1.9.1 MMLs
Circuit Group Handling (RC Command Group)
Using the commands of the RC command group, it is possible to:
• 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 following commands are relevant to this feature:
RCA ADD CIRCUITS TO CIRCUIT GROUP
Use this command to add virtual circuit(s) to a circuit group.
RCC CREATE CIRCUIT GROUP
Use this command to create different types of circuit groups: CCS, CAS,
DCS, SIP, IPT, and special circuit groups.
RCI INTERROGATE CIRCUIT GROUP
15. 15
Feature 1331: Session Initiation Protocol in the MSC
Server
Feature description
Id:0900d80580651393
This command shows the virtual circuit groups.
RCR REMOVE CIRCUITS FROM CIRCUIT GROUP
This command is used to remove virtual circuits from circuit groups.
Note that BUSY virtual circuits cannot be removed.
RCD DELETE CIRCUIT GROUP
This command is used to delete circuit groups. Note that if there are
circuits connected in the circuit group, they cannot be deleted.
For further information, see Circuit Group Handling, RC Command Group.
Route Handling (RR Command Group)
Using the commands of the RR command group, it is possible to:
• create a route with circuit groups
• add circuit groups to a route
• modify external route characteristics
• delete a route or circuit groups from a route and carry out an interrogation of the
characteristics of a route
Before the operator uses the commands of the RR command group, the circuit groups
must be created by using the commands of the RC command group.
The following command is relevant to this feature:
RRM MODIFY ROUTE
Use this command to modify the characteristics of an external route. It
can also be used to modify the characteristics of the internal route of the
Group Switch (GSW) and modify the Adjacent Network Element Func-
tionality (NEFUNC).
For further information, see Route Handling, RR Command Group.
Extra FQDN Configuration Commands (JN Command Group)
Using the commands of the JN command group, it is possible to:
• add additional hosts to the given FQDN
• remove additional hosts
• inquire additional hosts
• delete all added hosts and parameters
• list all FQDNs that have additional hosts
• modify route (FQDN) level parameters
• create and copy route (FQDN) parameters
• query the status of OPTIONS-based reachability
The additional hosts are used as an alternative to selecting the SIP CGR in incoming
requests. Normally the FQDN given during SIP CGR creation is used to identify the SIP
CGR for use. The additional hosts can be either IPv4 or IPv6 based. The FQDN level
parameters can be used to influence the handling of SIP messages.
The following commands are related to Trunk group (RFC4904) support for IP peering
functionality:
JNA ADD HOST NAME
Use this command to create a new MFQDN record if the given root
FQDN does not exist.
16. 16
Feature 1331: Session Initiation Protocol in the MSC
Server
Id:0900d80580651393
Feature description
JNC CREATE AND COPY SIP MESSAGE PARAMETERS
Use this command to create and copy SIP message parameters.
JNM INTERROGATE / MODIFY SIP MESSAGE PARAMETERS
Use this command to interrogate or modify SIP message parameters.
JNT INTERROGATE FQDN RECORD WITH TRUNK GROUP ID/IDs
Use this command to interrogate an FQDN record using the remote or
local Trunk Group ID or both local and remote Trunk Group IDs.
Using the commands listed above it is possible to configure local and remote Trunk
Group IDs. It is also possible to configure the address of an outbound proxy server and
set the handling of Route headers in the outgoing initial INVITE.
For further information, see Extra FQDN Configuration Commands, JN Command
Group.
SIP Parameters Configuration Handling (JH Command Group)
With the help of the JH command group, it is possible to configure switch level domain
names for use with SIP in CCSU/SIGU.
For further information, see SIP Parameters Configuration Handling, JH Command
Group.
SIP Address Configuration Handling (JI Command Group)
With the help of the JI command group, it is possible to configure those IP addresses to
be used with CCSU/SIGU units and unit level domain names.
For further information, see SIP Address Configuration Handling, JI Command Group.
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 after the INVITE requests (call setups)
have been sent. There is no response either because the remote FQDN has not
been found in the DNS, or because the DNS query has resulted in an IP address,
which has no response from the remote side, indicating an incorrect IP address in
the DNS, or a broken SIP signaling connection between two signaling processes.
The alarm output contains the IP address of the remote end as an array of 16 bytes,
and can contain both IPv4 and IPv6 addresses.
• 1233 IP entity is not reachable
This alarm is set when the packet sent to the IP address coming from 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 alarms) reaches a limit. After alarm3220 is set,
notices 0121 are not set anymore until alarm 3220 is cleared.
17. 17
Feature 1331: Session Initiation Protocol in the MSC
Server
Feature description
Id:0900d80580651393
1.10 Subscriber interfaces
This feature has no subscriber interfaces.
1.11 External interfaces
The feature complies with 3GPP specifications in the Mg/Mj interface toward the IMS,
and is compatible with the other interfaces of the interworking features. This feature
implements the SIP signaling interface of the MGCF controlling the MGW.
SIP between MSSs
SIP is mostly used to transfer ISUP messages and to handle the IP resources with the
use of the SDP between MSSs. The MSSs do not act as a SIP proxy even if the call
originates from the SIP domain, thus the message is entirely constructed from internal
Call Control (CC) messages. Between MSSs SIP-T is followed as defined by IETF RFC
3261 SIP: Session Initiation Protocol and IETF RFC 3372: SIP for Telephones (SIP-T):
Context and Architectures.
Tunneling is not necessary in the MSS as the call can arrive from a non-ISUP domain,
for example, the IMS. The MSS constructs the corresponding ISUP message from the
provided data structure if ISUP tunneling is used.
The following figure describes the SIP protocol stack for the feature:
Figure 2 SIP protocol stack for this feature
3GPP IMS
The roles defined by 3GPP IMS include MGCF and Proxy, and Interrogating and
Serving Call State Control Functions (P/I/S-CSCF). The MGCF and I-CSCF are con-
nected by the Mg interface while the MGCF and the BGCF are connected by the Mj
interface. SIP is used to implement the IMS-CS interworking in this interface. The inter-
working includes support for voice calls between the IP Multimedia (IM) Core Networks
(CN) subsystem and CS networks, and support for supplementary services, such as
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 such as 3GPP defined 'P-' headers,
offer/answer models, and support for DTMF in RTP format in order to comply with 3GPP
TS 29.163 Interworking between the IP Multimedia (IM) Core Network (CN) subsystem
and Circuit Switched (CS) networks (Release 6).
SIP-I interface (interface according to Q.1912.5 standard)
This interface implements Profile C from ITU-T Q.1912.5 Interworking between Session
Initiation Protocol (SIP) and Bearer Independent Call Control protocol or ISDN User Part
standard. The interface is similar to the SIP-T interface but the Nb-UP framing protocol
is not used in the user plane stack of this interface. The aim of the enhancements made
on the control plane level is to follow the afore-mentioned standard to the utmost.
18. 18
Feature 1331: Session Initiation Protocol in the MSC
Server
Id:0900d80580651393
Feature description
IETF proxy
This interface implements Profile B from ITU-T Q.1912.5 Interworking between Session
Initiation Protocol (SIP) and Bearer Independent Call Control protocol or ISDN User Part
standard, and 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 proxies
toward the user agent. In a similar way to the 3GPP IMS interface, the Nb User Plane
(Nb UP) framing protocol is not used in the user plane stack of this interface.
19. 19
Feature 1331: Session Initiation Protocol in the MSC
Server
Main changes in Feature 1331: Session Initiation Pro-
tocol in the MSC Server
Id:0900d80580651395
2 Main changes in Feature 1331: Session Initi-
ation Protocol in the MSC Server
2.1 Changes in the feature
2.2 Changes in the document
Change description Release
No changes M14.5
Support for SPD-less INVITE and Trunk group (RFC4904)
support for IP peering have been added.
M14.4
The use of virtual circuits support with SIP is supported. M14.2
Using the OPTIONS message, the operator can check the
reachability of the SIP application.
M14.1
Issue Changes Release
7-0 Feature 1451: BICC-SIP Interworking has
been renamed to Feature 1451: IMS-CS
Interworking.
M14.5
6-0 The following sections have been updated:
• Introduction
• Benefits for the operator
• Functionality - general
• Parameters
• Compliance
• Operator interfaces - MMLs
Editorial changes have also been applied.
M14.4
5-1 References to IMS network elements have
been corrected according to the approved
portfolio naming convention.
M14.3
5-0 The company and product names have
been changed according to the official
Nokia Siemens Networks portfolio.
M14.3
4-0 The following sections have been updated:
• Benefits for the operator
• MMLs
M14.2
3-1 Information concerning the OPTIONS
message has been added.
M14.1
