(Contents)
Embedded MGCF
MSOFTX3000V100R007C01
Issue1.00
Date2008-06-30
confidential
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Technologies Co., Ltd. provides customers with
comprehensive technical support and service. Please feel free to
contact our local office or company headquarters.
Huawei Technologies Co., Ltd.
Address:Administration Building, Huawei Technologies Co.,
Ltd.,
Bantian, Longgang District, Shenzhen, 518129, Peoples Republic
of China
Website:http://www.huawei.com
Email:[email protected]
Copyright Huawei Technologies Co., Ltd. 2008. All rights
reserved.No part of this document may be reproduced or transmitted
in any form or by any means without prior written consent of Huawei
Technologies Co., Ltd.
Trademarks and Permissions and other Huawei trademarks are
trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document
are the property of their respective holders.
Notice
The information in this document is subject to change without
notice. Every effort has been made in the preparation of this
document to ensure accuracy of the contents, but all statements,
information, and recommendations in this document do not constitute
the warranty of any kind, express or implied.
About This DocumentAuthorPrepared
byFeng.JidongDate2008-04-12
Reviewed byDate
Approved byDate
HistoryIssueDetailsDateAuthorApproved by
V1.00Creation2008-06-12Feng.Jidong
Contents11 Embedded MGCF
11.1 Service Description
11.1.1 Function Code
11.1.2 Definition
21.1.3 Standard Compliance
31.1.4 System Specifications
31.1.5 Benefits
31.1.6 Application Limitations
41.1.7 Influence
41.2 Availability
41.2.1 Requirements for NEs
41.2.2 Functions of the NEs
41.2.3 Requirements for License
41.2.4 Supporting Versions
51.3 Hardware Compatibility
51.4 Application Scenario
61.5 External Interfaces
61.6 Service Flow
61.6.1 Video Call Flow Originated by the IMS
81.6.2 Video Call Flow Terminated by the IMS
91.6.3 Fax Call Flow Originated from the IMS
101.6.4 Fax Call Flow Terminated to the IMS
111.6.5 IMS-associated Charging Flow
131.6.6 Standard/Non-Standard TEL URI Flow
131.6.7 AMR One Packet Multi-Frame
131.6.8 HISTORY-INFO
151.7 Initial Configuration
151.7.1 Typical Networking
151.7.2 Application Requirements
161.7.3 Data Configuration at the MSOFTX3000 Side
161.7.4 Data Configuration at the UMG8900 Side
161.7.5 Data Configuration at the HLR9820 Side
171.7.6 Data Configuration Example
181.7.7 Table Query
181.8 Maintenance
191.9 Service Management
191.10 Charging and CDR
191.10.1 Charging Principle
191.10.2 CDRs
191.11 Performance Measurement
201.12 Service Interaction
211.13 Reference
211.13.1 Glossary
211.13.2 Acronyms and Abbreviations
211.14 FAQ
Figures7Figure 1-1 Video call message flow
8Figure 1-2 Video call flow (slow start)
9Figure 1-3 Video call message flow terminated by the IMS
10Figure 1-4 Fax call flow originated from the IMS (fax
interworking between SIP and BICC)
11Figure 1-5 Fax flow terminated to the IMS
12Figure 1-6 Charging of a voice call originated from the
IMS
12Figure 1-7 Charging of a voice call terminated to the IMS
15Figure 1-8 Networking of video/fax interworking
Tables1Table 1-1 Function codes of the embedded MGCF service
2Table 1-2 Functions of the embedded MGCF service
3Table 1-3 Benefits of the embedded MGCF service
4Table 1-4 NEs required to implement the embedded MGCF
service
4Table 1-5 Versions of the Huawei UMTS CN products that support
the embedded MGCF service
16Table 1-6 Procedure of data configuration at the MSOFTX3000
side
20Table 1-7 Interaction between the fax service and other
services
1 Embedded MGCF
1.1 Service Description
Control call states: Control the parts related to media channel
connection in the IM-MGW.
Communicate with the call session control function (CSCF).
Select the CSCF for incoming calls from traditional networks
according to the route number.
Implement the conversion between Integrated Services Digital
Network User Part (ISUP) protocols and IP Multimedia Subsystem
(IMS) call control protocols.
Receive out-band information and forward it to the
CSCF/IM-MGW.
1.1.1 Function Code
Table 1-1 lists the function codes of the embedded MGCF
service.
Table 1-1 Function codes of the embedded MGCF
serviceNameCode
Video interworking service WMFD-168300
Fax interworking serviceWMFD-168301
IMS charging service WMFD-168302
Standard/non-standard TEL URI WMFD-168303
AMR one packet multi-frameWMFD-168304
HISTORY-INFOWMFD-168305
1.1.2 Definition
Table 1-2 lists the functions of the embedded MGCF service.Table
1-2 Functions of the embedded MGCF serviceNameDefinition
Video interworking service The video interworking between the
circuit switched (CS) domain and the IMS domain can be transferred
through a media gateway control function (MGCF). For an incoming
video call from the IMS domain, the MGCF can correctly route the
call to the video interworking gateway (VIG), and the VIG can
transfer the call to the CS domain; thus, video interworking
between the IMS domain and the CS domain is realized. For a video
call from the CS domain to the IMS domain, the VIG transfers the
call to the MGCF, and then the MGCF can correctly route the call to
the IMS domain; thus, video interworking between the CS domain and
the IMS domain is realized. For video interworking, the MGCF
supports the H.263, H.264 and MPEG-4 codecs.
Fax interworking serviceThis service supports the fax
interworking between an IMS network and a CS network. It enables
the switching between fax calls and voice calls.
IMS charging service When the IMS interworks with the CS, the
charging information of the IMS domain can be reflected in the CDRs
of the CS domain. Thus, the charging information of the IMS domain
can be associated with the charging information of the CS
domain.
Standard/non-standard TEL URI In an outgoing INVITE message, if
it is required that numbers in the REQUEST URI/TO/FROM header
fields be in the unified TEL URI format, "+" must be added in front
of a number in the international TEL URI format; "+" cannot be
added in front of a number in the non-international TEL URI
format.For an incoming INVITE message, the MGCF is able to process
the TEL URI format.
AMR one packet multi-frameWhen the MSOFTX3000 interworks with
the IMS, the AMR is often used as the audio codec. The AMR adopted
in the IMS domain may use one packet multi-frame. This requires the
MGCF to support one packet multi-frame. In this way, negotiation of
the AMR multi-frame parameter (maxptime) can be successful during
the O/A negotiation with the IMS domain. When the bearer is set up,
the UMG can be informed of maxptime.
HISTORY-INFOWith this function, the History-Info header can
carry the forwarding information.
1.1.3 Standard Compliance
3GPP TS 32.225, Charging data description for the IP Multimedia
Subsystem (IMS), V5.11.0.
IETF RFC 2190 RTP Payload Format for H.263 Video Streams
IETF RFC 3984 RTP Payload Format for H.264 Video.
IETF RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual
Streams
1.1.4 System Specifications
None
1.1.5 Benefits
Table 1-3 describes the benefits of the embedded MGCF
service.
Table 1-3 Benefits of the embedded MGCF
serviceBeneficiaryDescription
Carrier The service enables carriers to provide value-added
video and fax services to improve competitiveness. The service is
compatible with standard and non-standard TEL URI formats.
Mobile subscriber The service enables mobile subscribers to use
video and fax services.
1.1.6 Application Limitations
The video call supports only the H.263, H.264, and MPEG-4 codecs
and requires negotiation throughout the service flow.
For MPEG-4 and H.264, the maximum parameter length supported is
50 bytes (only the first 50 bytes are used if the length exceeds 50
bytes). For the Session Description Protocol (SDP), if multiple
H.264 codecs exist, only one is used.
The video call supports only the standalone VIG. The embedded
VIG scenario is not supported at present.
The video call does not support the intra-office inter-MGW
scenario. When a video call is active, the interaction between the
Ring Back Tone (RBT), announcement, and intelligent network (IN)
services is not supported.
In the case of fax interworking, G.711a, G.711u, and T38 are
supported when the MGCF interworks with the PSTN.
G.711a and G.711u codecs are supported when the MGCF interworks
with the CS BICC/CM.
When the IMS interworks with the IMS through the MGCF, G.711a,
G.711u, and T38 codecs are supported (T.38 requires negotiation
throughout the service flow).
Fax services are judged according to China Telecom SIP-Based Fax
Service Implementation Specification.
The re-negotiation of the fax codec is not supported. The
gateway does not support configuration of the maxptime. If the
maxptime used is not supported by the gateway, a message is
returned, indicating the termination application failure. 1.1.7
Influence
The embedded MGCF service does not support mutual switching
between video calls and fax calls.
1.2 Availability
1.2.1 Requirements for NEs
The embedded MGCF service requires the coordination of the UE,
NodeB, RNC, MSC Server, MGW, CSCF, PSTN, and VIG. For details about
the requirements of NEs, see Table 1-4.
Table 1-4 NEs required to implement the embedded MGCF
service
UENodeBRNCMSC ServerMGWCSCFPSTNVIG
The symbol "" indicates that the NE is required.
1.2.2 Functions of the NEs
The UE, NodeB, RNC, MSC Server, MGW, CSCF, and VIG are involved
in the video interworking between the IMS and CS networks.
The MSC Server, MGW, CSCF, and PSTN are involved in the fax
interworking between the IMS and CS networks, IMS charging service,
and standard/non-standard TEL URI.
1.2.3 Requirements for License
Among the embedded MGCF services, the T38 fax service and the
H263/H264/MPEG-4 video call service are provided through the
license of the MGCF function (LKWAMGCF01).1.2.4 Supporting
Versions
Table 1-5 lists the versions of the Huawei UMTS CN products that
support the embedded MGCF service.Table 1-5 Versions of the Huawei
UMTS CN products that support the embedded MGCF service
ProductSupporting Version
MSC ServerMSOFTX3000V100R007C01
MGWUMG8900V200R007C06
1.3 Hardware Compatibility
None
1.4 Application Scenario
This service is applicable to the GSM and UMTS R99/R4
networks.
The embedded MGCF service includes the video interworking, fax
interworking, IMS charging, and standard/non-standard TEL URI
functions.
Video interworking provides IMS and CS subscribers with the
inter-network video interworking service.
Fax interworking provides IMS and CS subscribers with the
inter-network fax interworking service.
The IMS charging feature enables carriers store the charging
information in the IMS domain into the charging information of the
CS domain. Therefore, it is convenient for carriers to associate
the charging information in the CS domain with the charging
information in the IMS domain. Standard/non-standard TEL URI can be
compatible with all formats of TEL URI in the IMS network. The
network compatibility increases.
The specific application scenarios are as follows:
Video interworking: When the MGCF receives a call from the IMS
network which carries video media information, the MGCF
transparently transfer the video media information to the VIG.
Through the VIG, a video call is originated to a CS subscriber.
When the MGCF receives a video call from the VIG, the video media
information is transparently transferred to the IMS to originate
the video call to a subscriber in the IMS domain. For video
interworking, the MGCF supports video fallback to audio.
Fax interworking: At present, the MGCF supports TS61 and TS62.
For TS61, when a voice connection is active between a CS subscriber
and an IMS subscriber, the MGCF sends the fax to the CS (IMS)
network to allow the fax interworking if the IMS (CS) subscriber
originates a fax call. For TS62, after the MGCF receives a fax call
from an IMS (CS) subscriber, the MGCF sends the fax to the CS (IMS)
subscriber. The MGCF supports the switching from voice to fax and
the switching from fax to voice.
IMS charging: After the MGCF receives a call request from the
IMS domain, the MGCF determines according to the data configuration
whether to extract the charging headers in the message, send the
local IMS charging information to the IMS network through relevant
header fields in the response, and reflect the charging information
in the CS CDR. For a call originated by the MGCF to the IMS domain,
the MGCF also determines according to the data configuration
whether to carry relevant charging headers in the request message,
extract the charging information in the IMS response, and reflect
the charging information in the CS CDR.
Standard/non-standard TEL URI: In the case of the Session
Initiation Protocol (SIP) trunk calls, the MGCF needs to support
SIP calls represented by the TEL URI. In outgoing INVITE messages,
if numbers of REQUEST URI/TO/FROM header fields are required to be
in a unified TEL URI format, the MGCF can packet the header fields
correctly: "+" is added in front of a number in the international
TEL URI format; "+" is not added in front of a number in the
non-international TEL URI format. AMR one packet multi-frame: When
the MSOFTX3000 interworks with the IMS, the AMR is often used as
the audio codec. The AMR adopted in the IMS domain may use one
packet multi-frame. This requires the MGCF to support one packet
multi-frame. In this way, negotiation of the AMR multi-frame
parameter (maxptime) can be successful during the O/A negotiation
with the IMS domain. When the bearer is set up, the UMG can be
informed of maxptime.
HISTORY-INFO: When the MSOFTX3000 interworks with the IMS, the
History-Info header in a message received or sent by the MSOFTX3000
carries the forwarding information. 1.5 External Interfaces
The fax interface between the MGCF and the IMS network complies
with China Telecom SIP-Based Fax Service Implementation
Specifications.pdf.
The video call interface between the MGCF and the IMS network
complies with IETF RFC 2190, IETF RFC 3984, and IETF RFC 3016.
1.6 Service Flow
1.6.1 Video Call Flow Originated by the IMS
Figure 1-1 shows the message flow for a video call originated by
the IMS.
Figure 1-2 Video call flow originated by the IMS
When an IMS subscriber calls a 3G subscriber, the MGCF
distinguishes between the video call and the voice call. For a
voice call from the IMS domain, the MGCF directly routes it to the
MSC server. For a video call, the MGCF performs special processing,
routes the call to the VIG, and establishes a video connection with
the MSC through the VIG.
Figure 1-2 shows the video call message flow originated from IMS
(slow startup).
Figure 1-3 Video call flow (slow start)
The slow start mode (200/ACK negotiation or 18x/PRACK
negotiation) is not differentiated in this flow. The MGCF
determines whether to send the video codec when the caller
termination is established in slow start mode. The MGCF uses a
codec supported by the MGW. The MGCF can set Selected VP Codec for
use in slow start mode.
1.6.2 Video Call Flow Terminated by the IMS
Figure 1-3 shows the service flow of a video call terminated by
the IMS.
Figure 1-4 Video call message flow terminated by the IMS
2. The MS originates a video call to the VMSC. The VMSC
determines it a video call and routes the call to the VIG according
to the configuration. The VIG routes the call to the MGCF.
3. The MGCF receives the INVITE message from the VIG. The
message carries video media information. The MGCF adds audio/video
media terminations to the MGW and then transparently transfers the
media codec and parameters to the IMS.
4. The MGCF receives the response from the IMS. The response
message carries video media information. The MGCF modifies the
audio/video media terminations according to the video media
information and then transparently transfers the media codec and
parameters to the VIG.
5. Upon the receipt of the response from the IMS, the MGCF
returns an ACK to the IMS. The video call is established.
1.6.3 Fax Call Flow Originated from the IMSFigure 1-4 shows the
fax call flow originated from the IMS.
Figure 1-5 Fax call flow originated from the IMS (fax
interworking between SIP and BICC)
The service flow is as follows:
6. The IMS sends a RE-INVITE message to notify the MGCF to
originate a fax call. The MGCF sends a MODIFY message to instruct
the MGW to modify bearers.
7. After receiving a MODIFY ACK message from the MGW, the MGCF
sends an APM(codec modify) message with G.711Red or G.711
parameters to instruct the peer MSC to modify codec parameters.
8. After receiving an APM(modify success) message from the peer
MSC, the MGCF sends a MODIFY message to instruct the MGW to modify
T1 termination.
9. After receiving a MODIFY ACK message from the MGW, the MGCF
returns a 200 OK response to notify the IMS that the MGCF has
completed all modifications.
10. The voice call is transformed into a fax call.1.6.4 Fax Call
Flow Terminated to the IMSFigure 1-5 shows the fax call flow
terminated to the IMS.
Figure 1-6 Fax flow terminated to the IMS
The service flow is as follows:
11. The MSC sends an APM(codec modify) message to notify the
MGCF to originate a fax call. The MGCF sends a MODIFY message to
instruct the MGW to modify codec parameters.
12. After receiving a MODIFY ACK message from the MGW, the MGCF
sends a RE-INVITE message to notify the IMS to renegotiate codec
parameters. The message carries G.711 parameters.
13. The IMS returns a 200 OK response to notify the MGCF that
codec parameters are successfully modified. The MGCF then sends an
APM(modify success) message to notify the MSC that codec parameter
modification is successful.
14. The voice call is transformed into a fax call.1.6.5
IMS-associated Charging FlowFigure 1-6 shows the charging of a
voice call originated from the IMS.
Figure 1-7 Charging of a voice call originated from the IMS
The service flow is as follows:
15. When an IMS subscriber calls a CS subscriber, the IMS sends
an INVITE message with the header P-Charging-Vector to the MGCF.
The header contains IMS charging information.
16. The MGCF extracts IMS charging information from
P-Charging-Vector and then inserts CS charging information to
P-Charging-Vector. Using the new P-Charging-Vector, the MGCF
constructs a response destined for the IMS.17. After the
conversation is completed, the MGCF generates a CS CDR, which
contains both IMS charging information and CS charging
information.Figure 1-7 shows the charging of a voice call
terminated to the IMS.
Figure 1-8 Charging of a voice call terminated to the IMS
The service flow is as follows:
18. When a CS subscriber calls an IMS subscriber, the MGCF sends
an INVITE message with the header P-Charging-Vector to the IMS. The
header contains CS charging information.
19. After receiving a response from the IMS, the MGCF extracts
IMS charging information from the received response.
20. After the conversation is completed, the MGCF generates a CS
CDR, which contains both IMS charging information and CS charging
information.1.6.6 Standard/Non-Standard TEL URI Flow
This feature is a supplement to RFC2806. It enables the MGCF to
add "+" in front of a number in the international TEL URI format
and to delete "+" from a number in a non-international TEL URI
format.
The service flow is as follows:
21. When the current call must be routed over an outgoing SIP
trunk, the MGCF converts the calling number and called number into
a standard format.22. Based on number conversion results, the MGCF
determines whether the number is in the international format or a
non-international format.
23. When an outgoing INVITE message is sent, the MGCF determines
whether to add "+" before the REQUEST URI/TO/FROM header fields
according to the obtained number format. Other header fields and
the message structure remain unchanged, and the outgoing call flow
does not change.1.6.7 AMR One Packet Multi-Frame
24. If the MGCF initiates the O/A negotiation and the AMR codec
is used, maxptime is set to 20ms (one packet one frame). After the
peer end returns the answer, the value of maxptime is subject to
the value in the answer. If the peer end initiates the O/A
negotiation, the value of maxptime on the MGCF is subject to the
value at the peer end. If the peer end does not send maxptime, the
value of maxptime contained in the answer sent by the local end is
20ms.
25. When the AMR codec is used to set up the bearer, the
parameter maxptime must be sent to the MGW. If maxptime is modified
during modification of the bearer attributes, the MOD message
containing the new value of maxptime must also be sent to the
MGW.
1.6.8 HISTORY-INFO
To realize interworking between the IMS and the CS in the case
of forwarding, the MGCF must convert the forwarding information in
History-Info into the trunk signaling (ISUP or BICC) or the trunk
signaling (ISUP or BICC) into the forwarding information in
History-Info, and ensure that the forwarding information is not
lost in the conversion and can be sent to the next hop. Thus, five
scenarios may arise.
Scenario 1
A subscriber in the IMS domain calls a subscriber in the CS
domain. The call is forwarded by the called subscriber for one or
more times in the CS domain.
In this case, the CS domain sends the ACM or CPG message to
inform the MGCF of the forwarding information (including the
redirection number and forward reason, but excluding the forwarding
times). The MGCF fills the converted forwarding information in the
History-Info header, and sends the header through the 181 response
to the IMS domain.
Scenario 2
A subscriber in the CS domain calls a subscriber in the IMS
domain. The call is forwarded by the called subscriber for one or
more times in the IMS domain.
In this case, the IMS domain sends a 181 message to inform the
MGCF that the called subscriber forwards the call in the IMS
domain. If the 181 message contains the History-Info header, the
MGCF converts the History-Info header into the forwarding
information, and sends the forwarding information through the ACM
or CPG message to the CS domain.
Scenario 3
After a call is forwarded in the IMS domain, the call is again
forwarded to a subscriber in the CS domain.
For example, UA 1, UA 2, and UA 3 are IMS subscribers, and UA 4
is a CS subscriber. UA 1 calls UA 2, UA 2 forwards the call to UA3
unconditionally, and UA 3 forwards the call to UA 4
unconditionally. For the MGCF, all the call forwarding flows are
the same except that the forwarding reasons are different.
Scenario 4
After a call is forwarded in the CS domain, the call is again
forwarded to a subscriber in the IMS domain.
For example, UA 1, UA 2, UA 3, and UA 4 are CS subscribers, and
UA 5 is an IMS subscriber. UA 1 calls UA 2, UA 2 forwards the call
to UA3 unconditionally, UA 3 forwards the call to UA 4
unconditionally, and UA 4 forwards the call to UA 5
unconditionally. For the MGCF, all the call forwarding flows are
the same except that the forwarding reasons are different.
Scenario 5
Both the incoming and outgoing trunks of the MGCF are SIP
trunks.
When an IMS/NGN interworks with another IMS/NGN through the MGCF
(that is, both the incoming and outgoing trunks of the MGCF are SIP
trunks), the description about the History-Info header is the same
in both the protocols rfc4244 and ETSI TS 183004. Therefore, after
the MGCF receives History info from a subscriber of one IMS/NGN, it
transparently sends History info to the subscriber of another
IMS/NGN and conversion of the forwarding information is not
required.
1.7 Initial Configuration
1.7.1 Typical Networking
Figure 1-8 shows the typical networking for fax/video
interworking between the IMS domain and the CS domain.
For video interworking, the IMS terminal interworks with the
MGCF through the CSCF. The MGCF routes a video call to the VIG and
then to the visited (VMSC). The VMSC originates the video call to a
3G UE.
A video call originated by a UE is routed to the MGCF through
the VIG and then to the IMS network.
For fax interworking, the fax machine accesses the IMS network
through an integrated access device (IAD) and then the fax call is
routed to the MGCF to originate a fax to the PSTN or mobile
network.Figure 1-8 shows the networking of video/fax
interworking.
Figure 1-9 Networking of video/fax interworking
1.7.2 Application Requirements
The following application requirements are implemented through
the data configuration at the MSOFTX3000 side:
One SIP trunk is activated between the MGCF and the VIG and
between the MGCF and the CSCF. One IP channel is activated to carry
video media between the UMG8900 and the VIG or CSCF.
One MTP link is activated between the MGCF and the visited
MSOFTX3000. One E1 circuit is activated between the UMG8900 and the
visited MSOFTX3000.
1.7.3 Data Configuration at the MSOFTX3000 Side
Video interworking and fax interworking are implemented
according to basic SIP data. This section describes only the data
difference between V100R007C01 and V100R006C02. The
standard/non-standard TEL URI and IMS charging features do not have
special requirements on the data configuration.
For video calls, configure data about the following office
directions: SIP-based MGCF-IMS office direction, SIP-based MGCF-VIG
office direction, and ISUP/BICC-based MGCF-VMSC office
direction.For fax calls, configure data about the following office
directions: SIP-based MGCF-IMS office direction and ISUP/BICC-based
MGCF-VMSC office direction (or ISUP-based MGCF-PSTN office
direction).Table 1-6 describes the procedure of data configuration
at the MSOFTX3000 side.
Table 1-6 Procedure of data configuration at the MSOFTX3000
side
StepDescription CommandKey Parameters
1Configure MGW data ADD MGWCodec list
2Configure route data ADD RTANA For video calls, set
Transmission capability to Unrestricted digital information
service. For audio calls, set Transmission capability to the
default value (All categories).
3Configure SIP trunk data ADD SIPTGSelected VP CodecPeer entity
type
For command explanations, see the online help.
1.7.4 Data Configuration at the UMG8900 Side
For fax interworking, configure data about the UMG8900-IWF
office direction.
1.7.5 Data Configuration at the HLR9820 Side
When a fax or video call is initiated in the IMS domain to a
called mobile subscriber and the MSOFTX3000 functions as a GMSC or
VMSC, the fax or video service must be subscribed on the HLR.
1.7.6 Data Configuration Example
Scenario
This section describes the data configuration for the video
interworking feature of the MGCF. For other features of the MGCF,
only basic SIP data requires to be configured.
1. When the system works as a trunk TMSC, configure SIP tandem
data (when the VMSC uses SIP signaling, the data configuration is
similar to that of the TMSC).
2. Set the IMS and VIG as peer offices. Configure the local and
peer offices to use SIP signaling for communication with each
other.
3. Set the IP address of the IMS to 1.1.1.1 and that of the VIG
to 2.2.2.2.
4. The number prefix destined for the VIG is 2222.
Configuration Scripts
Step 1 Configure the video codec capability of the MGW.
DescriptionConfigure the video codec H.263, H.264, and MPEG-4
capability of the MGW.
Script ADD MGW: MGWNAME="mgw", TRNST=SCTP, CTRLMN=132, BCUID=0,
ENCT=NSUP,
TC=GSMEFR-0&GSMHR-0&TDMAEFR-0&PDCEFR-0&HRAMR-0&UMTSAMR2-0&FRAMR-0&UMTSAMRWB-0&PCMA-1&PCMU-1&UMTSAMR-0&G7231-0&G729A-0&GSMFR-0&T38-0&MUME-0&H263-1&H264-1&MPEG4-1,
VQECTRL=NSUP;
Remark None
Step 2 Configure data about the route to the VIG.
DescriptionConfigure data about the route to the VIG.
Script ADD RTANA: RSN="to_vig", RSSN="ims", TP=UNLIMDATA,
RN="to_vig", ISUP=SIP_M;
Remark For video calls, set Transmission capability to
Unrestricted digital information service so that the calls can be
routed to the VIG.
For audio calls, set Transmission capability to the default
value.
Step 3 Configure SIP trunk data.
DescriptionConfigure the VIG trunk group.
Script ADD SIPTG: TGN="to_vig", CSCN="0", SRTN="to_vig",
IMN=134, OSU="2.2.2.2", ISST=YES, VPCODEC=H263, ENTYPE=VIG;
Remark When configuring a SIP trunk group to the VIG, set Peer
entity type to VIG. For video calls, Selected VP Codec is
settable.
Step 4 Configure the called number analysis information.
DescriptionConfigure the called number analysis information so
that the call is routed to the VIG.
Script ADD CNACLD: PFX=K'2222, RSNAME="to_vig", MINL=4, MAXL=13,
ISERVICECHECKNAME="INVALID", CHGNAME="INVALID";
Remark When the called number prefix is 2222, configure the data
to route the call to the VIG.
--End1.7.7 Table Query
The use of the embedded MGCF service does not change the table
query sequence.
1.8 Maintenance
To disable the IMS charging function, modify the following
software parameter:
DescriptionDisable the IMS charging function.
Script MOD MSFP: ID=P215, MODTYPE=P1, BIT=5, BITVAL=0;
Remark To disable IMS charging, set bit5 of P215 to 0. To enable
the IMS charging, set bit5 of P215 to 1.
To disable the outgoing TEL URI format, set the related software
parameter.
DescriptionDisable the TEL URI format.
Script MOD SIPTG: TGN="to_vig", SFPARA=SVR12-0;
Remark You can choose not to use the TEL URI format by setting
the software parameter 12 of the SIP trunk group. If the parameter
is set to 1, the TEL URI format is used. If the parameter is set to
0, the SIP URI format is used.
To use the HISTORY-INFO or DIVERSION header to carry the
outgoing forwarding information, set the related software
parameter. DescriptionUse the HISTORY-INFO header.
Script MOD SIPTG: TGN="to_vig", SFPARA=SVR10-0;
Remark When software parameter 10 of the SIP trunk group is set
to 1, the DIVERSION header is used.
When software parameter 10 of the SIP trunk group is set to 0,
the HISTORY-INFO header is used.
1.9 Service Management
None
1.10 Charging and CDR
1.10.1 Charging Principle
For the fax interworking feature, the MGCF generates and
transfers intermediate data/voice CDRs to the iGWB after the
established voice call is converted into a fax call.
1.10.2 CDRs
For the IMS charging feature, the MGCF generates GWI, GWO, and
TRANSIT CDRs and transfers the CDRs to the iGWB if the charging
function is enabled. The generated CDRs contain the IMS charging
information, among which icid-value, orig-ioi, and term-ioi are
inserted into fields of a variable length.1.11 Performance
Measurement
For fax interworking, the measurement unit SIP Office Direction
Data Service Traffic is added to the measurement task MSC Special
Service Measurement.
For the video interworking, the measurement units VP Trunk
Office Direction Outgoing Office Traffic and VP Trunk Office
Direction Incoming Office Traffic are added to the measurement task
Bearer Traffic.SIP Office Direction Data Service Traffic CODEC
MODIFY TIMES
CODEC MODIFY SUCCESSTIMES
VP Trunk Office Direction Outgoing Office Traffic
BID_TIMES
SEIZURE_TIMES
CALL_CONNECTED_TIMES
ANSWER_TIMES
CONNECTED_RATIO
ANSWER_RATIO
SEIZURE_TRAFFIC
CONNECTED_TRAFFIC
ANSWER_TRAFFIC
CALLED_BUSY_TIMES
ABANDON_AFTER_RING_TIMES
RINGED_NO_ANSWER_TIMES
VP Trunk Office Direction Incoming Office Traffic
SEIZURE_TIMES
CALL_CONNECTED_TIMES
ANSWER_TIMES
CONNECTED_RATIO
ANSWER_RATIO
SEIZURE_TRAFFIC
CONNECTED_TRAFFIC
ANSWER_TRAFFIC
CALLED_BUSY_TIMES
ABANDON_AFTER_RING_TIMES
CONGESTION_TIMES
1.12 Service Interaction
Table 1-7 describes the interaction between the fax service and
other services.
Table 1-7 Interaction between the fax service and other
services
Service Interaction
Fax and video A fax call cannot co-exist with a video call. This
means a subscriber cannot switch a fax call to a video call or
originate a fax call when being active in a video call.
1.13 Reference
1.13.1 Glossary
None
1.13.2 Acronyms and Abbreviations
Acronym/AbbreviationFull Name
3GThe Third Generation
3GPP23rd Generation Partnership Project 2
BOSSBusiness and Operation Support System
VIGVoice Interworking Gateway
ETSIEuropean Telecommunications Standards Institute
1.14 FAQ
None
_1276007476.vsd
