[]

Huawei Training

en
m/
co
Huawei eSpace IPT

i.
we
ua
System Troubleshooting

.h
ng
ni
ar
le
://
tp
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo
Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht
tp
://
le
Huawei Technologies Co., Ltd

ar
ni
ng
.h
ua
we
i.
co
[]

m/
en
 []

Copyright Huawei Technologies Co., Ltd. 2015 All rights reserved.

en
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.

m/
Trademarks and Permissions

co
i.
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other

we
trademarks and trade names mentioned in this document are the property of their respective
holders.

ua
Notice

.h
ng
The information in this document is subject to change without notice. Every effort has been

ni
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,

ar
express or implied.
le
: //
tp
ht

Huawei Training
s:
ce

Huawei eSpace IPT System Troubleshooting

ur

Edition v1.0
so
Re
ng
ni
ar
Le
re
Mo
 []

Preface

en
Introduction

m/
Huawei eSpace IPT System Troubleshooting is designed to assist those who would like to
have an in-depth understanding on Huawei UC system, especially on Huawei IPT system so

co
as to have a quick fault locating and handling ablitity.

i.
Prerequisites

we
In order to learn the content more effectively, readers should have the basic knowledge

ua
listed below

.h
Learn the basic principle of voice communication

ng
Learn the basic knowledge of IP network.

ni
Referenced document

ar
eSpace U1900 unified gateway product documentation
le
eSpace 7910&7950 product documentation
//

eSpace 7910&7950 IP Phone V200R002C00SPC300 Administrator Guide 04

:
tp
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo
 []

en
eSpace IPT Referenced Icon

m/
co
i.
Router

we
PBX IP PBX SBC SVN

ua
.h
CDR Server Console Access IAD Lanswitch

ng
gateway

ni
ar
Analog phone IP phone Fax Video phone Email Server
le
: //

Database EGW eServer EMS PC

tp
ht

eSpace IPT Software Version

s:
ce

Device or software Version

ur

U1980 V200R003C00SPC100
U1960 V200R003C00SPC100
so

U1911 V200R003C00SPC100
Re

IAD132E(T) V300R002
ng
ni
ar
Le
re
Mo
 []

en
m/
Contents

co
i.
we
1 UC Signaling and Protocols1

ua
1.1 Analog Voice Knowledge4

.h
1.2 Digital Voice Knowledge8

ng
1.3 VoIP Knowledge17

ni
2 UC Maintenance Tools58

ar
2.1 Collect Fault Information through CLI61
le
2.2 Collect Fault Information Using the LMT70
//

2.3 Whats Wireshark and How to Use it90

:
tp

3 U1900 System Architecture111

ht

3.1 U1900 Hareware Architecture114

3.2 U1900 Software Architecture133

s:

4 Terminal Registration Faults155

ce

4.1 IP Phone Registration Diagram158

ur

4.2 IP Phone Registration Process Analysis164

so

4.3 Common Registration Fault Rectification177

Re

5 U1900Call Faults190
5.1 U1900Call Troubleshooting Methods193
ng

5.2 Intra-office Call Troubleshooting195

ni

5.3 Inter-office Call Troubleshooting225

ar

5.4 Number Display Fault Rectification249

Le

Glossary259
re
Mo
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

1
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

2
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

3
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

4
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

5
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Before DTMF is introduced, a telephone system uses a series of intermittent pulses to

transmit a called number, which is called the pulse signal.
ht

DTMF was invented in Bell Lab. The dual-tone mode is used because it can reliably
s:

distinguish dial information from voice. Generally, voice signals will not trigger the DTMF
receiver.
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

6
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

7
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

8
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

PCM: pulse code modulation

ht

Traditionally, voice encoding uses an 8 kHz sampling rate and an 8-bit depth to encode
quantized values, and uses the A law or law in the encoding process to finally obtain 64
s:

kbit/s voice code.

ce
ur
so
Re
ng
ni
ar
Le
re
Mo

9
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

ISDN is short for integrated services digital network. The ISDN can provide integrated
services such as voice, data, and video through a common telephone cable.
ht

TDM is short for time division multiplexing. It refers to the technology for transmitting
s:

multiple digital data, voice, and video signals simultaneously on the same transmission
media through cross pulses in different channels or timeslots.
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

10
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Except service information, a large amount of information is transmitted over a

communication network. Such information does not contain signals related to specific
ht

services such as voice, images, or text transmitted to users. Instead, it contains control
signals transmitted between communication devices, such as the information about
s:

occupation, release, device busy and idle status, and called numbers. Therefore, signaling
ce

can be considered as control signals except user information transmitted between

communication devices (including user terminals and switching devices).
ur
so
Re
ng
ni
ar
Le
re
Mo

11
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Channel associated signaling (CAS)

ht

Signaling and voice are transmitted through the same call channel. Inter-office signaling
of the CAS type is also classified into line signaling with the monitoring function and
s:

register signaling with the control function. Common CAS includes China No.1 and
standard R2.
ce

Common channel signaling (CCS)

ur

Voice and signaling are transmitted separately. All trunk line and communication service
so

signaling is transmitted over public data links. Common CCS includes SS7 and PRA.
Re
ng
ni
ar
Le
re
Mo

12
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Two physical ports:

ht

S/T port: four lines; transmission distance: 1.2 km. Currently, BRA trunk ports provided
in some countries are of this type.
s:

U port: two lines; transmission distance: 5 km. U ports are converted into S/T ports
through NT1 devices.
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

13
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Physical layer
ht

The physical layer provides means for establishing, maintaining, and releasing physical
connections and ensures information transmission over physical circuits. Physical layer
s:

specifications are those for electrical and physical characteristics of ports, including
mechanical characteristics of connectors.
ce

Data link layer

ur

The data link layer provides measures for establishing, maintaining, and releasing data
so

links based on the physical layer. The data link layer completes the link multiplexing,
Re

error check and restoration, traffic control, and information transmission functions. The
standard protocol for PRA at the data link layer is Q.921.
ng

Network layer
ni

The network layer completes call control functions based on services provided by Layer
ar

2, including control of circuit switched calls and packet switched calls. The standard
protocol for PRA at the network layer is Q.931.
Le
re
Mo

14
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

15
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Description of common messages:

ht

SETUP: sent by the calling user to the network, which forwards the message to the
called user, for initiating a call.
s:

ALERTING: sent by the called user to the network, which forwards the message to the
calling user, indicating that the called user's phone starts ringing.
ce

CONNECT: sent by the called user to the network, which forwards the message to the
ur

calling user, indicating that the called user has picked up the phone.
so

CONNECT ACKNOWLEDGE: sent by the calling user to the network, which then
Re

forwards the messages to the called user, indicating that the calling user obtains the
call.
ng

DISCONNECT: sent by a user to the network for requesting disconnection of the end-
ni

to-end connection, or sent by the network to a user, indicating disconnection of the

ar

end-to-end connection.
Le

INFORMATION: sent by a user or the network for providing additional information.

re
Mo

16
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

17
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Signaling protocols
ht

Registration, user locating, and routing

Session setup, modification, and release
s:

Session description protocol

ce

Session management (SIP) and session description (SDP) are separated from each other.
ur

Media transmission protocol

so

RTP/RTCP protocol for transmitting voice/video data

Re
ng
ni
ar
Le
re
Mo

18
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

19
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Session
ht

A multimedia session includes a group of multimedia senders and recipients and data
streams transmitted between senders and recipients. For example, a multimedia
s:

conference is a typical multimedia session.

Dialog
ce

A dialog is a P2P SIP relationship between two user agents in a continuous time period.
ur

A dialog can include multiple transactions.

so

Transaction
Re

A SIP transaction is an event between the client and server, including the first request
ng

sent by the client to server, the final response sent by the server to client (non-1xx
response), and all messages transmitted between the client and server. If the request is
ni

an INVITE request, and the final response is a non-2xx response, the transaction also
ar

includes an ACK message to the response.

Le
re
Mo

20
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

Simplicity
tp

The Keep It Simple Stupid (KISS) design rule is adapted, which is also the design rule for
ht

IETF protocols.
Six requests and six responses
s:

Request messages: INVITE, ACK, BYE, CANCEL, REGISTER, and OPTIONS

ce

Response messages: 1xx to 6xx

ur

Text-based encoding and many available tools such as XML

Easy to implement and debug
so

Focusing on session setup, modification, and termination, and facilitating the user of
Re

other protocols such as SDP and RTP

Expandability
ng

Session-irrelevant: SIP-URL indicates the resource or user to access, and the message
ni

body can carry any contents.

Flexible expansion mechanism: adding header fields and messages types
ar

Powerful capability negotiation mechanism: Supported, Unsupported, Require, Proxy

Le

Require, Allow, and Accept

Network transparency to services: Middle devices Proxy and Redirector transparently
re

process message contents without understanding them.

Mo

21
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The SIP protocol uses the client/server (C/S) model.

Each request triggers an operation on the server.
ht

An operation is called a method.

In addition to the specific method, each request carries a series of header fields that
s:

carry service information.

ce

Beside header fields, a message carries a message body of any type.

The basic composition of a SIP message includes the start line, SIP message header, empty
ur

line, and SIP message body.

so

General syntax of a SIP message

Re

Start-Line (Request-Line/Response-Line), Message Header, CRLF and [Message-Body]

Common SDP information in a call is transmitted between the client and server in
message bodies. From the point when the server receives a request to the point when
ng

the request is processed, the server needs to return multiple temporary responses and a
ni

final response. There is only one final response.

ar

A request and all its responses form a transaction. A complete call process includes
multiple transactions. For example, call setup and call release are two independent
Le

transactions.
A user agent is a logical entity that initiates or receives a call.
re

UAC: used for initiating a request.

Mo

UAS: used for receiving a request.

The definition of UAC/UAS is transaction-specific. In multiple transactions of a call, the
roles of UAC and UAS can be exchanged.

22
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Single-valued and multi-valued header fields

ht

Single-valued header field: A single-valued header can appear only once in a message,
such as From and To.
s:

Multi-valued header field: A multi-valued header field can appear multiple times in a
message, such as Via and Route.
ce

The Max-Forwards field indicates the maximum number of SIP entities that a request can
ur

pass through. It is a counter used for preventing an infinite loop.

so
Re
ng
ni
ar
Le
re
Mo

23
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

24
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

Understand the six basic request messages. You only need to know extension
tp

messages.
ht

Extension messages:
s:

MESSAGE: used for requesting an instant message.

ce

SUBSCRIBE: used for subscribing to a notification event.

ur

NOTIFY: used for sending a notification event.

so

UPDATE: used for modifying session properties in the call setup stage.
Re

PUBLISH: used for sending event status to the status server.

PRACK: used for identifying the reliability of a temporary response.

ng

ni
ar
Le
re
Mo

25
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

26
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The request requires user authentication. This response is issued by UASs

ht

401 Unauthorized and registrars, while 407 (Proxy Authentication Required) is used by proxy
servers.
s:

The server understands the request, but is refusing to fulfill it. Authorization
403 Forbidden
will not help, and the request should not be repeated.
ce

The server has definitive information that the user does not exist at the
domain specified in the Request-URI. This response is also returned if the
ur

404 Not Found

domain in the Request-URI does not match any of the domains handled by
so

the recipient of the request.

The request cannot be completed due to a conflict with the current state of
Re

409 Conflict the resource. This response is returned if the action parameter in a REGISTER
request conflicts with existing registrations.
ng

The requested resource is no longer available at the server and no

forwarding address is known. This condition is expected to be considered
ni

410 Gone permanent. If the server does not know, or has no facility to determine,
whether or not the condition is permanent, the status code 404 (Not Found)
ar

should be used instead.

Le

The server refuses to accept the request without a defined Content- Length.
411 Length
The client may repeat the request if it adds a valid Content-Length header
Required
field containing the length of the message-body in the request message.
re

The server is refusing to process a request because the request entity is

Mo

413 Request larger than the server is willing or able to process. If the condition is
Entity Too Large temporary, the server should include a Retry-After header field to indicate
that it is temporary and after what time the client may try again.

27
 414 Request-URI The server is refusing to service the request because the Request-URI is
Too Long longer than the server is willing to interpret.
The server is refusing to service the request because the message body of

en
415 Unsupported the request is in a format not supported by the server for the requested
Media Type method. The server must return a list of acceptable formats using the

m/
Accept, Accept-Encoding, or Accept-Language header field.
420 Bad The server does not understand the protocol extension specified in a Require

co
Extension (Section 20.32) header field.

i.
The callee's end system is contacted successfully but the callee is currently
480 Temporarily unavailable (for example, is not logged in, or logged in but has activated the

we
Unavailable "do not disturb" feature). The response may indicate a better time to call in
the Retry-After header field.

ua
This response is returned under the following conditions: The server receives

.h
481 Call a BYE request that does not match any existing call leg, the server receives a
leg/Transaction CANCEL request that does not match any existing transaction, or the server

ng
Does Not Exist receives an INVITE request that does not match any existing TAG. (The server
simply discards an ACK referring to an unknown transaction.)

ni
482 Loop
The server receives a request with a Via path containing itself.
Detected

ar
483 Too Many The server receives a request that contains a more Via entries (hops) than
le
Hop that allowed by the Max-Forwards header field.
484 Address The server receives a request with a To address or Request-URI that is
//
Incomplete incomplete.
:

The callee address provided in the request is ambiguous. The response may
tp

485 Ambiguous
contain a list of possible unambiguous addresses in the Contact header field.
ht

The callee's end system is contacted successfully but the callee is currently
not willing or able to take additional calls. The response may indicate a
486 Busy Here better time to call in the Retry-After header field. The user can also be
s:

available elsewhere, such as through a voice mail service. Therefore, this

response does not terminate any searches.
ce

487 Rquest
The request is terminated by a CANCEL request.
ur

Cancelled
so
Re
ng
ni
ar
Le
re
Mo

28
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

29
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

SIP provides a mechanism allowing UAs to create precise binding relationships. This
mechanism is called the Register service.
ht

The Register service needs to send a REGISTER request to a special UAS (that is, registrar).
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

30
 Mo
re

Le
ar
ni
ng
Re
so
ur

B2BUA: back-to-back user agent.

ce
s:

31
ht
tp
: //
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

SDP is a format for describing streaming media initialization parameters, and is published
tp

as an IETF Proposed Standard as RFC 4566. The streaming media is the content saw or
ht

heard during data transmission. An SDP packet includes the following information:
Session information
s:

Session name and objective

ce

Time when the session is active

The following additional information is useful when session resources are limited:
ur

Bandwidth used by the session

so

Contact information about the session originator

Re

Media information
Media type, such as video and audio
ng

Transmission protocol, such as RTP/UDP/IP and H.320

ni

Media format, such as H.261 video and MPEG video

ar

Multicast address and media transmission port (IP multicast session)

Le

Remote address for media and transport port for the contact address (IP unicast
session)
re
Mo

32
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

33
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The o line includes parameters related to the session originator.

The first parameter indicates the session originator name, which is optional. The value
ht

must be consistent with the From header field in the SIP message.
s:

The second parameter indicates the session identifier of the calling party.
ce

The third parameter indicates the session version of the calling party. When the session
data changes, the version number increases.
ur

The fourth parameter indicates the network type. The IN value indicates the Internet
so

network type, which is the only network type defined currently.

Re

The fifth parameter indicates the address type. Currently, IPv4 and IPv6 address types
are supported.
ng

The sixth parameter indicates the IP address of the session originator, which is a
ni

control-plane IP address.
ar
Le
re
Mo

34
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The c line defines information about the connection established for a multimedia session,
which includes the real IP address used by media streams.
ht

The first parameter indicates the network type. Currently, only the Internet network
type is defined, which is indicated by IN.
s:

The second parameter indicates the IP address type. Currently, IPv4 and IPv6 address
ce

types are supported.

ur

The third parameter indicates the IP address used by multimedia streams.

so

If the secondary PDP context is established for transmitting media streams on the basis
Re

of the signaling PDP context established, the two PDP contexts must use the same IP
address. If a new PDP context is separately established for transmitting media streams,
ng

that is, the media PDP context, a different IP address must be used.
ni
ar
Le
re
Mo

35
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The m line is called the media line that describes media information such as the media
type supported by the originator.
ht

The first parameter indicates the media name. In this example, the audio type is
supported.
s:

The second parameter indicates the port number. In this example, the UE sends audio
ce

streams on local port 3458.

The third parameter indicates the transmission protocol, which is generally the RTP or
ur

AVP protocol.
so

The fourth to seventh parameters indicate four payload type numbers.

Re

RFC 3551 includes 35 payload formats and allocates payload type numbers ranging from 0
to 34 to RTP/AVP.
ng

The new coding scheme can dynamically allocate payload type numbers ranging from 96
to 127.
ni

The a line indicates the media attribute, which is in the format of Attribute name:
ar

Attribute value. The format is a=rtpmap:<Payload type><Number name>.

a=rtpmap:0 PCMU
Le

a=rtpmap:96 G726-32/8000
a=rtpmap:97 AMR-WB
re

Payload type 0 is fixedly allocated to PCMU.

Mo

Payload type 96 matches the G.726 coding scheme, which is dynamically allocated.
The coding scheme for payload type 97 is adaptive multirate wideband (AMR-WB),
which is dynamically allocated.

36
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The m line is called the media line that describes media information such as the media
ht

type supported by the originator.

The first parameter indicates the media name. In this example, the video type is
s:

supported.
ce

The second parameter indicates the port number. In this example, the UE sends video
streams on local port 3400.
ur

The third parameter indicates the transmission protocol, which is generally the RTP or
so

AVP protocol.
Re

The fourth and fifth parameters indicate two payload type numbers.
The format is a=rtpmap:<Payload type><Number name>.
ng

a=rtpmap:98 MPV
ni

a=rtpmap:99 H.261
ar

Payload type 98 matches the MPV coding scheme, which is dynamically allocated.
Le

Payload type 97 matches the H.261 coding scheme, which is dynamically allocated.
re
Mo

37
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The following negotiation modes are rarely used:

ht

1. The INVITE message does not carry SDP information, the 180 (ringing) message carries
SDP information about the called party as the offer, and the calling party sends the
s:

negotiation result to the called party using the PRACK message.

ce

2. The INVITE message does not carry SDP information, the 200 message carries SDP
ur

information about the called party as the offer, and the calling party sends the
so

negotiation result to the called party using the ACK message.

Re

Huawei devices currently support the first, second, and fourth SDP negotiation modes.
ng
ni
ar
Le
re
Mo

38
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The INVITE message carries SDP information, and the 2xx response message also carries
ht

SDP information.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

39
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The INVITE message carries SDP information, the reliable 1xx response message carries
ht

SDP information, and the final 2xx response does not carry SDP information.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

40
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The INVITE message carries SDP information, the reliable 1xx response message and
ht

UPDATE message also carry SDP information, and the final 2xx response does not carry
SDP information.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

41
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The INVITE/REINVITE and final 2xx response messages carry SDP information.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

42
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

RTP data transmission characteristics:

ht

RTP itself does not provide any mechanism to ensure timely data transmission or
provide other quality of service guarantees, but relies on lower-layer services to do so.
s:

RTP does not ensure transmission of data packets in sequence.

ce

RTP is mainly designed to meet the requirements of multimedia conferences with

multiple participants. It is not limited to specific applications.
ur

RTP can also be used for continuous data storage, interactive distributed simulation,
so

active badge, and control and measurement applications.

Re
ng
ni
ar
Le
re
Mo

43
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

An application layer protocol defines how application processes in different end systems
exchange packets.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

44
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

In VoIP, RTP is used for real-time transmission of media data. Due to characteristics of
tp

packet switched circuits, the delay, jitter, out-of-order, and packet loss of the voice
packets may occur when the voice packets are transmitted over an IP network. These
ht

problems greatly lower voice quality.

RTP provides the following functions in VoIP:
s:

1. Transmits media information in real time. To ensure real-time transmission, RTP packets
ce

are transmitted through UDP.

2. Eliminates the jitter. The jitter refers to the variation in time for each packet to reach
ur

the destination caused by a forwarded data burst upon network congestion. A jitter
buffer is required to ensure that packets can be evenly forwarded to the decoder.
so

3. Sequences packets. If packets may reach the destination by passing through different
Re

routes, out-of-order packets may exist and packets sent first may reach later. In this
case, the Sequence Number field in the RTP header is used to sequence RTP packets
so that the decoder can correctly decode the voice packets.
ng

4. Prevents packet loss. Redundant RTP packets can be used to prevent packet loss.
However, this method occupies high bandwidth, and will occupy more bandwidth
ni

when the number of redundant packets increases. As a result, the network

ar

environment where packet loss occurs gets worse. Currently, RTP uses the Bad Frame
Indication (BFI) to notify the decoder. The decoder uses the mathematical internal
Le

difference method to generate approximate data to mitigate the packet loss impact.
5. Transmits DTMF signals, signal tones, and signaling messages in specific scenarios.
re
Mo

45
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

An RTP data packet includes the media transmission type, format, sequence number,
timestamp, and additional data, which provide a basis for real-time transmission of
ht

streaming media.
The CSRC identifier is at the end of the RTP fixed header, and used to indicate the source
s:

of an RTP data packet. RTP allows multiple data sources in a session. An RTP mixer can
merge these data sources into one. For example, a CSRC list can be generated to indicate
ce

a voice conference, and an RTP mixer can merge all voice data sources in the conference
ur

into one RTP data source.

The fields are described as follows:
so

Version (V): 2 bits. This field defines the RTP packet version. The current version is 2
Re

(Version 1 is used in the RTP draft).

Padding (p): 1 bit. If the padding bit is set to 1, a packet contains more additional
padding octets at the end of the packet, which are not part of the RTP payload. The
ng

last octet of the padding indicates the number of total padding octets. Padding may be
ni

required by some encryption algorithms with fixed block sizes or for carrying several
RTP packets in a lower-layer protocol data unit.
ar

Extension (X): 1 bit. If the extension bit is set to 1, the fixed header is followed by only
Le

one header extension. The header extension field is mainly used to implement new
payload-format-independent functions. Information relevant with specific formats
re

should be carried in the payload of RTP packet.

CSRC Count (CC, contributing source): 4 bits. This field indicates the number of CSRC
Mo

identifiers that follow the fixed header. One to fifteen CSRC identifiers can be specified.

46
 Marker (M): 1 bit. The interpretation of the marker is defined by a profile. Different
applications define the packetization modes for specific PT values, payload data, and

en
rules for using the marker. An application can define one or more markers (in the
payload).

m/
Payload Type (PT): 7 bits. This field identifies the format of the RTP payload and

co
determines its interpretation by the application. PT values in the range of [96, 127] are
used as dynamic PT values. That is, the PT values are not statically mapped to the

i.
payload formats. Other protocols other than RTP, such as SDP, are required to

we
negotiate the interpretation mode of the payload format for two communicating

ua
parties. RFC 3551 defines a set of static PT values used by audio and video media
formats.

.h
Sequence Number: 16 bits. The sequence number increments by one for each RTP data

ng
packet sent. The RTP packet receiver can use this field to detect packet loss and restore
the packet sequence. The initial value of the sequence number should be random to

ni
increase the deciphering difficulty (The source itself may not encrypt data, but data

ar
needs to be encrypted at the lower layer or during transmission). The sequence number
starts from 0 when it reaches the upper limit. le
Timestamp: 32 bits. The timestamp indicates the sampling instant of the first octet in
//
the RTP data packet. The sampling instant must be derived from a clock that increments
:

monotonically and linearly in time to allow synchronization and jitter calculations. If RTP
tp

packets are generated periodically, the nominal sampling instant as determined from
ht

the sampling clock is to be used. For example, the sampling frequency of audio is 8000
Hz, that is, 8000 points are sampled in 1 second or 8 points are sampled in 1
s:

millisecond; if the packetization duration is 10 milliseconds, 80 points are sampled and

the timestamp difference between RTP packets is 80. That is, the timestamp unit is a
ce

sampling cycle (that is, duration for sampling a point), and the clock used is the
ur

sampling clock. Similar to the sequence number, the initial value of the timestamp is
random and starts from 0 when it reaches the upper limit.
so

SSRC: 32 bits. The SSRC field identifies the synchronization source. The identifier is
Re

chosen randomly, but different synchronization sources within the same RTP session
must use different identifiers. If a synchronization source changes its source transport
ng

address, it must also use a new SSRC identifier to avoid being interpreted as a looped
ni

source.
CSRC list: The CSRC list identifies the contributing sources. The number of contributing
ar

sources ranges from 0 to 15 and depends on the CC field value. CSRC identifiers are
Le

inserted by mixers, using the SSRC identifiers of contributing sources. In addition,

mixers use SSRC identifiers in RTP packets as their own SSRC identifiers.
re
Mo

47
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

RTCP provides the following functions:

ht

1. The most important function of RTCP is to provide feedback on data transmission

quality, equivalent to the traffic and congestion control function of other transport
s:

protocols. The feedback is useful for control of adaptive encodings, but experiments
with IP multicasting have shown that it is also critical to get feedback from the receivers
ce

to diagnose faults in the distribution. Sending reception feedback reports to all

ur

participants allows one who is observing problems to evaluate whether those problems
are local or global.
so

2. RTCP carries a persistent transport-level identifier for an RTP source, which is called the
Re

canonical name or CNAME. Since the SSRC identifier may change if a conflict is
discovered or a process is restarted, receivers require the CNAME to trace each
ng

participant. Receivers may also require the CNAME to associate multiple data streams
ni

from a given participant in a set of related RTP sessions, for example to synchronize
audio and video.
ar

3. Each participant sends RTCP packets to all the others so that each participant can know
Le

the number of participants in an RTP session. This number is used to calculate the rate
at which packets are sent.
re

4. An optional function is to convey minimal session control information, for example

Mo

participant identifier to be displayed on the user interface.

48
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

SR (sender report) packet: transmission and reception statistics from participants that are
active senders
ht

RR (receiver report) packet: reception statistics from participants that are not senders
s:

SDES (source description) packet: description of RTCP packet sources, including CNAME
ce

BYE (goodbye) packet: end of voice transmission

ur

APP (application-defined) packet: application-oriented expansions

so
Re
ng
ni
ar
Le
re
Mo

49
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

50
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Consider the following when choosing a codec: device capability, bandwidth, and voice
quality requirements. If the bandwidth is limited, you shall choose a codec that provides
ht

the voice compression function. If digital trunks have sufficient bandwidth and high voice
quality is required, you can choose a codec without the voice compression function. Voice
s:

quality is a factor that must be considered. If voice is encoded and compressed, more time
ce

will be spent on voice sampling; therefore, a delay occurs.

ur

You can choose a codec based on the site requirements. Higher bandwidth is required for
a higher encoding rate and better voice quality.
so
Re
ng
ni
ar
Le
re
Mo

51
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The interval for sending voice packets is configurable using an interface at the application
layer. The packetization time must be an integral multiple of the processed frame length,
ht

such as 10 ms, 20 ms, or 30 ms for G.729.

s:

When NetATE is enabled, the packetization time and bit rate are automatically adjusted
based on the network condition. This applies only to Opus.
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

52
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

53
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

54
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

55
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

56
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

57
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

58
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

UC: Unified Communications

ht

LMT: Local Maintenance Terminal

s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

59
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The U1900 is the generic term for eSpace U1900 series unified gateways. It includes
the U1981, U1980, U1960, U1911, and other models of IP PBX.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

60
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

61
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

62
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

63
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

64
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

65
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

66
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re

Le

ar

IDLE
ni

BUSY

FAULT
Three states:
ng
Re
so
ur
ce
s:

67
ht
tp
: //
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

68
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

69
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

70
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

71
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The LMT tool enables users to log in to equipment for a variety of operations. The
operations include viewing and configuring commands using the command tree,
ht

managing alarms, managing configurations, tracing signaling, upgrading versions,

collecting logs, and performing offline operations.
s:

Before using the LMT tool, use the file signature verification tool to verify the integrity of
ce

the software package.

ur

Enter the IP address, user name (default: admin), and password (default: huawei123) of
so

the LMT server.

Re

Note: The server-side and client-side versions must be consistent.

ng
ni
ar
Le
re
Mo

72
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

In the device tree area on the left, right-click and choose Add Device.
ht

In the Add Device dialog box, enter the name and IP address and click OK.

If the IP address of the U1900 unified gateway you selected is an IPv6 address, select ipv6
s:

from the IP drop-down list box and then enter the IP address.
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

73
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

In the device tree area on the left, right-click the desired device and choose Connect.
ht

Set Username (default: admin), View mode password (default: huawei123), and
Config mode password (default: huawei123). If you only need to log in to the View
mode, you do not need to set Config mode password.
s:

You can log in to the U1900 using Telnet or SSH. By default, only the SSH mode (SSH
ce

authentication) can be selected. The Telnet protocol is insecure and is disabled by

ur

default.
so

Change the password at your first login. It is recommended that you change the user
Re

name and password once a month to ensure system security.

ng
ni
ar
Le
re
Mo

74
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Command navigation tree area: This area is bi-directionally linked to the complete
command input area.
ht

Command configuration area: Based on the command keywords, enter relevant parameter
values to obtain the complete command.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

75
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Users can use the LMT tool to view alarm information online.
ht

Procedure

1. Log in to the LMT tool. In the menu bar, choose Alarm Management > Alarm.
s:

The system displays all alarms on the current equipment.

ce

2. Double-click an alarm record. The system displays a dialog box that provides alarm
details.
ur

3. Click the Alarm Suggestions tab. Clear the alarm based on the alarm handling
so

suggestions that are displayed here.

Re

4. After an alarm is cleared, the system displays an alarm clearance message.

ng
ni
ar
Le
re
Mo

76
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

5. Double-click an alarm record. The system displays a dialog box that provides alarm
details.
ht

6. Click the Alarm Suggestions tab. Clear the alarm based on the alarm handling
suggestions that are displayed here.
s:

7. After an alarm is cleared, the system displays an alarm clearance message.

ce
ur
so
Re
ng
ni
ar
Le
re
Mo

77
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

78
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Log types and descriptions

Type Description
ht

Run Log Run logs record key events and faults that occur in system operating, and can
be used to locate system faults.
s:

Operate Log Operation logs record commands executed by maintenance personnel and
ce

scheduled tasks, and all the operations (add, delete, modify, and query)
performed on configurations.
ur

Call Log Call logs record detailed running information of programs in a module, key
so

service processes, and the function executing process.

Re

Call Analysis Call analysis logs can be used to analyze the processes of SIP/PRA/R2/SS7/QSIG
trunk-based calls.
Control Block Control block logs record the in-call control block information.
ng
ni
ar
Le
re
Mo

79
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

80
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

81
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

82
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

SIP: Session Initiation Protocol

ht

SIP is an Internet Engineering Task Force (IETF) standard protocol. SIP is used to initiate
multimedia-enabled, interactive user sessions, covering video, audio, chat, gaming, and
virtual reality.
s:

QSIG: Q Signaling
ce

QSIG is a type of Integrated Services Digital Network (ISDN) protocol. QSIG is a global
ur

standard for the networking of Stored Program Control (SPC) exchanges, and is used for
so

directly connecting SPC exchanges through leased lines. I

PRA: Primary Rate Access

Re

Through PRA interfaces, ISDN provides one 64 kbit/s D channel and twenty-three (T1) 64
ng

kbit/s or thirty (E1) 64 kbit/s B channels. B channels are used for carrying services, while D
channels are used for carrying call control signaling and maintenance management signaling.
ni

SS7: Signaling System No.7

ar

SS7 is a protocol for controlling calls and services on the telecommunications network. SS7
Le

often uses dedicated 64 kbit data circuit to carry packetized messages and provides
connection control services for calls between two or more machines in the same network.
re

R2: R2 signaling
Mo

R2 is a standard Channel Associated Signaling (CAS).

83
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

SIP: Session Initiation Protocol

ht

SIP is an Internet Engineering Task Force (IETF) standard protocol. SIP is used to
initiate multimedia-enabled, interactive user sessions, covering video, audio, chat,
gaming, and virtual reality.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

84
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

85
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

86
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

PRA: Primary Rate Access

ht

Through PRA interfaces, ISDN provides one 64 kbit/s D channel and twenty-three
(T1) 64 kbit/s or thirty (E1) 64 kbit/s B channels. B channels are used for carrying
services, while D channels are used for carrying call control signaling and
s:

maintenance management signaling.

ce
ur
so
Re
ng
ni
ar
Le
re
Mo

87
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

88
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

89
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

90
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Wireshark captures packets over various ports, including WLAN ports.

ht

Wireshark supports packet decoding for various protocols, including IP, TCP, RTP, and
H.264.
s:

Wireshark can detect network security risks, troubleshoot the network, learn network
ce

protocols, and test the protocol running performance.

ur

Wireshark is not intrusion detection software (IDS), so it will not generate alarms or display
so

messages when the network traffic becomes abnormal.

Re

However, a thorough analysis of the packets captured by Wireshark enables a deeper

ng

understanding of network behavior. Wireshark does not change the information about
packets, but only displays the information about packets.
ni
ar

Wireshark itself does not send packets to the network.

Le
re
Mo

91
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Settings vary with switches from different vendors. The following steps use the Quidway
S3000 as an example:
ht

1. Use the serial port cable to connect the monitoring PC to the switch.
s:

2. Run the system-view command to enter the system view.

ce

3. Run the monitor-port ethernet 0/2 command to configure port 2 as the

monitoring port. Connect the PC to port 2.
ur

4. Run the mirroring-port ethernet 0/21 to ethernet 0/23 both command to

so

configure port mirroring. (This indicates that all the ports within the start and end
Re

port range will be monitored.)

5. Run the display mirror command to view the port mirroring setting results.
ng

6. Run the undo mirroring-port Ethernet 0/21 to Ethernet 0/23 both command
ni

to cannel monitoring on ports 21 through 23.

ar

Note: There is only one monitoring port on a switch. Local ports cannot be monitored.
Le
re
Mo

92
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Procedure
ht

1. Connect the LAN port on the IP phone to the switch.

2. Connect the PC port on the IP phone to the monitoring PC.

s:

3. Log in to the IP phone configuration page.

ce

4. Choose Advanced > Others. In the fault locating area, enable the port mirroring
ur

function.
so
Re
ng
ni
ar
Le
re
Mo

93
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

94
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

95
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

96
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

97
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

98
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:

99
ht
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Packets to be captured are generally massive and non-organized. Specify filter criteria such
as protocols and IP addresses to filter packets.
ht

Procedure
s:

1. Click Expression.
ce

2. Select filter criteria (e.g. TCP). Here, you can fully utilize a large number of protocols
in OSI Layer 2 through Layer 7, including IP, TCP, DNS, SIP, and H225.
ur

3. Click OK.
so
Re
ng
ni
ar
Le
re
Mo

100
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

101
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Other filter criteria include the source address and destination address.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

102
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

103
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

104
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

105
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re

2. B.
Le

1. ABD;
ar
ni
ng
Re
so
ur
ce
s:
ht

106
tp
: //
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

107
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

108
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

109
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

110
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

111
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

112
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

113
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

114
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The SM bus is used in communication between the fan module and SCU board.
tp

The PM bus is used by the power module to provide power for boards.
ht

The RS232 bus is used in communication between the ASI/OSU and SCU boards.
s:

The IP bus is used in broadband communication among internal boards.

ce

The TDM bus is used in narrowband communication among internal boards.

ur
so
Re
ng
ni
ar
Le
re
Mo

115
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

116
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

117
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

118
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The SCU board (main control module) integrates functional modules such as the main
tp

control module, narrowband switching module, security logic module and two broadband
ht

switching modules.

The MTU board (media resource module + digital trunk module) contains the media
s:

processing module (DSP + CPU), E1/T1 trunk module, and SD card storage module.
ce

The ASI board (analog user module) provides analog user access.
ur

The OSU board (analog user module + analog trunk module) provides analog user access
so

and analog trunk access.

Re

The BTU board (digital trunk module) provides BRI trunk access.
ng
ni
ar
Le
re
Mo

119
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

A module refers to a functional component, which is not necessarily a board. For example,
tp

the media resource module is only a functional module on the MTU module. In addition to
ht

the media resource module, the MTU board also includes the digital trunk module.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

120
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The main control module is on the SCU board and is the brain of the U1900. The main
tp

control module processes all broadband protocols, stores user and trunk information,
ht

controls call routing, and controls media and user permissions.

s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

121
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The media resource module of the U1900 is on the MTU board. The media resource
tp

module provides DSP resources for voice playback, voice conference sites, fax protocol
ht

conversion, IP packetization, analog signaling monitoring, and DTMF digit collection.

s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

122
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

Trunk modules include the digital trunk module and analog trunk module.
tp

The digital trunk module is on the MTU board.

ht

The analog trunk module is on the OSU board.

s:

Analog voice received by analog trunks is converted into digital signals through AD
ce

conversion on the OSU board.

ur
so
Re
ng
ni
ar
Le
re
Mo

123
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The user module is on the ASI or OSU board. Analog voice is directly converted into digital
tp

signals through AD conversion on the ASI or OSU board.

ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

124
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

As shown in the preceding figure, call processes in U1900 internal hardware modules
tp

include intra-office and outgoing call processes.

ht

Intra-office call
s:

IP phone B makes a call to IP phone C.

ce

Analog phone 1 makes a call to IP phone B.

ur

Outgoing call
so

Analog phone 1 makes an outgoing call through an analog trunk.

Re

Analog phone 1 makes an outgoing call through a digital trunk.

Analog phone 1 makes an outgoing call through a SIP trunk.
ng
ni
ar
Le
re
Mo

125
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The preceding process is not a complete call process between intra-office IP phones. It is a
tp

partial process starting from the point when the calling party initiates the call to the point
ht

when the called party answers the call. The key purpose is to introduce how the U1900
processes a call internally.
s:

Generally, signal tones played by IP phone B locally include the ringing tone, dial tone,
ce

ringback tone, and hang-up tone.

ur

This call process assumes that IP phone C is idle when IP phone B initiates the call, and the
so

RBT function is enabled on IP phone C. The process changes if IP phone C is in other

states:
Re

IP phone C is disconnected or the called number does not exist.

ng

Steps 4 through 10 will be unavailable. When detecting that the called phone is
disconnected or the called number does not exist in step 3, the SCU board directly
ni

sends an instruction for playing the exception tone or number unobtainable tone to
ar

the MTU board.

Le

IP phone C is idle but the RBT function is disabled.

Steps 7 through 9 will be unavailable. When receiving status information about the
re

called phone, the SCU board sends ringback tone signaling to IP phone B, and IP
Mo

phone B plays the ringback tone locally.

IP phone C is busy. Step 10 will be unavailable.
After IP phone C answers the call, the media stream process between IP phones B and C is
as follows: IP phone B<--->IP phone C 126
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The preceding process is not a complete call process between an intra-office IP phone and
tp

an intra-office analog phone. It is a partial process starting from the point when the analog
ht

phone initiates the call to the point when the IP phone answers the call. The key purpose is
to introduce how the U1900 processes a call internally.
s:

This call process assumes that IP phone C is idle when analog phone 1 initiates the call. The
ce

process changes if IP phone C is in other states:

ur

IP phone C is disconnected or the called number does not exist.

so

Steps 10 through 17 will be unavailable. When detecting that the called phone is
Re

disconnected or the called number does not exist in step 9, the SCU board directly
sends an instruction for playing the exception tone or number unobtainable tone to
the MTU board.
ng

IP phone C is busy.
ni

Step 17 will be unavailable.

ar

After IP phone C answers the call, the media stream process between analog phone 1 and
Le

IP phone C is as follows:
re

IP phone C<--->SCU<-(IP bus)->MTU (encoding and decoding, IP packetization and

unpacketization)<-(TDM bus)->ASI (AD conversion)<--->Analog phone 1
Mo

127
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The preceding process is not a complete process for making an outgoing call through an
tp

analog trunk. It is a partial process starting from the point when analog phone 1 initiates
ht

the call to the point when analog phone 1 hears the ringback tone. The key purpose is to
introduce how the U1900 processes a call internally.
s:

In step 9, when detecting that the analog trunk where the called number is located does
ce

not have an idle line or the analog trunk is faulty, the U1900 directly sends the line
ur

disconnection tone to analog phone 1. Subsequent steps will be unavailable.

so

In step 15, the SCU board sends different instructions based on the status of the called
phone.
Re

If the called phone is idle, the SCU board sends an instruction for playing the
ringback tone or RBT.
ng

If the called phone is busy, the SCU board sends an instruction for playing the busy
ni

tone.
ar

If the called number does not exist or is not registered, the SCU sends an instruction
Le

for playing an announcement indicating that the called number does not exist or the
called user line is faulty.
re

After sending the off-hook signaling in step 10, the SCU waits for a moment and sends
Mo

called number information to the MTU board for processing.

After analog phone 2 answers the call, the media stream process is as follows:

Analog phone 1<--->ASI (AD conversion)<-(TDM bus)->OSU (AD conversion)<--->Analog

trunk<--->Analog phone 2 128
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The preceding process is not a complete process for making an outgoing call through a
tp

digital trunk. It is a partial process starting from the point when analog phone 1 initiates
ht

the call to the point when analog phone 1 hears the ringback tone. The key purpose is to
introduce how the U1900 processes a call internally.
s:

In step 9, when detecting that the digital trunk where the called number is located does
ce

not have an idle line or the digital trunk is faulty, the U1900 directly sends the line
ur

disconnection tone to analog phone 1. Subsequent steps will be unavailable.

so

In step 13, the SCU board sends different instructions based on the status of the called
phone.
Re

If the called phone is idle, the SCU board sends an instruction for playing the
ringback tone or RBT.
ng

If the called phone is busy, the SCU board sends an instruction for playing the busy
ni

tone.
ar

If the called number does not exist or is not registered, the SCU sends an instruction
Le

for playing an announcement indicating that the called number does not exist or the
called user line is faulty.
re

After analog phone 3 answers the call, the media stream process is as follows:
Mo

Analog phone 1<--->ASI (AD conversion)<-(TDM bus)->MTU<-->Digital trunk<--->Analog

phone 3

129
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The preceding process is not a complete process for making an outgoing call through a SIP
ht

trunk. It is a partial process starting from the point when analog phone 1 initiates the call
to the point when analog phone 1 hears the ringback tone. The key purpose is to
introduce how the U1900 processes a call internally.
s:

In step 9, when detecting that the SIP trunk where the called number is located does not
ce

have an idle line or the SIP trunk is faulty, the U1900 directly sends the line disconnection
ur

tone to analog phone 1. Subsequent steps will be unavailable.

so

In step 15, the SCU board sends different instructions based on the status of the called
Re

phone.
If the called phone is idle, the SCU board sends an instruction for playing the
ng

ringback tone or RBT.

ni

If the called phone is busy, the SCU board sends an instruction for playing the busy
tone.
ar

If the called number does not exist or is not registered, the SCU sends an instruction
Le

for playing an announcement indicating that the called number does not exist or the
called user line is faulty.
re

After IP phone A answers the call, the media stream process is as follows:
Mo

Analog phone 1<--->ASI (AD conversion)<-(TDM bus)->MTU (encoding and decoding, IP

packetization and unpacketization)<-(IP bus)->SCU<--->SIP trunk<--->IP phone A

130
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The DSP provided by the media unit (that is, the MTU board) includes the general DSP and
tp

codec DSP.
ht

General DSP: implements the voice playback, digital collection (number detection),
and signal tone detection functions.
s:

Codec DSP: converts the voice codec among TDM, G.711, G.723, and G.729.
ce

Acronyms and abbreviations on this slide

ur

FE: fast Ethernet (10/100 Mbit/s)

so

HDLC: High-Level Data Link Control

Re

HW: high way (high-speed TDM bus)

ng

HPI: Host Port Interface (parallel interface for communicating with a host; this
ni

interface is mainly used by the DSP to communicate with other buses or CPUs)

PCI: Peripheral Component Interconnect

ar

PHY: physical layer

Le

UART: universal asynchronous receiver/transmitter

re
Mo

131
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The DSP provided by the media unit (that is, the MTU board) includes the general DSP and
codec DSP.
ht

General DSP: implements the voice playback, digital collection (number detection), and
s:

signal tone detection functions.

Codec DSP: converts the voice codec among TDM, G.711, G.723, and G.729.
ce

ur
so
Re
ng
ni
ar
Le
re
Mo

132
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

133
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

The system is divided into the following planes based on the function:
tp

System plane: includes the operating system, database, timer, memory management,
ht

task management, and interface commissioning functions.

s:

Driver plane: includes the RS232 serial port communication, network chip, hardware
chip, and FPGA logical drivers.
ce

Protocol plane: processes data for SIP, AT0, POTS, PRI, R2, QSIG, and Q.921.
ur

Transfer plane: includes the board and card management, inter-board communication,
so

and message forwarding functions.

Re

Service control plane: includes the call control, connection management, resource
management, user management, SoftConsole management, registration management,
ng

and CDR generation functions.

ni

Maintenance and management (M&M) plane: includes the CLI, web management,
ar

LMT, log/alarm processing, tracing, and license management functions.

Le

Messages transmitted among planes are scheduled and encapsulated in a unified manner,
effectively reducing system complexity and further improving reliability.
re
Mo

134
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

135
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

CCM: call control module

tp

USAM: user abstract module

ht

RM: resource module

s:

USAM IE: user abstract signaling module

ce
ur
so
Re
ng
ni
ar
Le
re
Mo

136
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

CCM: call control module

tp

USAM: user abstract module

ht

s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

137
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

138
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

CCM: call control module

ht

USAM: user abstract module

DB: database
s:

SIPUSM: SIP unified session management

ce

SIPTK: SIP trunk

ur
so
Re
ng
ni
ar
Le
re
Mo

139
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

140
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

141
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

142
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

143
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

144
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

145
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

146
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

147
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

For details about ucCause, see section "Reference > Log Reference > Analyzing Logs > Call
Log" in the unified gateway product documentation.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

148
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

149
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

150
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

151
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

152
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

153
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

154
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

155
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

156
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

157
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

158
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Normally, an IP phone registers with the active U1900.

ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

159
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

When the active U1900 is faulty, an IP phone registers with the standby U1900.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

160
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

When both the active and standby U1900s are faulty, an IP phone registers with the local
U1900.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

161
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

162
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

163
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

164
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

SIP Registration Cycle: Value half of which used by the IP phone as the interval for
tp

sending registration messages to a server.

ht

Re-registration Interval: Interval for initiating registration again upon a registration

failure.
Local SIP Port: Local SIP port number on which the capture software listens and through
s:

which the IP phone transmits data.

SIP T1(ms): Evaluation of the round trip time (RTT) between the server and client by
ce

default. If the network waiting time is high, specify a larger value to ensure stable use.
ur

SIP T2(ms): SIP T2 timer by default. The unit is milliseconds. Timer T2 defines the interval
between the INVITE response and non-INVITE request.
so

Call Re-initiation Interval: Interval for initiating a call again upon a call initiation failure.
Subscription Interval: Interval for updating voicemail, dialog, and call-info subscriptions.
Re

SIP Session Timer: Indicates whether to enable the timer that allows a terminal to
periodically send UPDATE messages (session update requests) during a session to ensure
ng

that the session is in the activated state.

Registration Status Subscription: Indicates whether to subscribe to the registration
ni

status. When the account logs in to the SIP server in another place, the IP phone receives a
notification from the server.
ar

PAI Header Field: Indicates whether to enable the IP phone to parse user information
from the PAI or From header field.
Le

Signaling Returned Upon Call Rejection:: Signaling for rejecting an incoming call. The
options include 486, 603, 404, and 480.
re

Support Header Field: 100rel that ensures reliable transmission of non-100 temporary
responses.
Mo

ALLOW Header Field: Parameters supported by the Allow header field of SIP signaling.

165
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

After successfully registering with the SIP server, an IP phone updates registration at an
interval of a half of the registration cycle.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

166
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

167
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

168
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

169
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

170
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

1. An IP phone registers with the U1900 for the first time. The registration request does not
carry authentication information.
ht

2. The U1900 returns the 401 message, indicating that the authentication fails.
s:

3. The IP phone sends a registration request carrying authentication information.

ce

4. The U1900 returns the 200 OK message, indicating that the registration succeeds.
ur
so
Re
ng
ni
ar
Le
re
Mo

171
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The terminal (IP phone) sends the first REGISTER message (registration request).
ht

The registration request contains the following information:

User number for registration
s:

IP address of the registration server

ce

IP address and port number of the terminal

ur

Model and version of the terminal

so

Message types supported by the terminal (contained in the Allow header field)
Re

The key part of the REGISTER message also contains the Contact and Expires header
fields.
ng

Contact header field: contains the number, IP address, and port number of the
ni

terminal that initiates registration and forms a binding relationship between the
ar

number and IP address of the terminal on the U1900.

Le

Expires header field: validity period of the binding period. The registration is updated
at the interval of a half of the registration cycle to instruct the U1900 to continue to
re

use the binding relationship.

Mo

172
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The U1900 checks whether the number in the To field exists in the user information stored
on the main control board. If the number exists, the U1900 establishes a number binding
ht

relationship.
s:

The U1900 then determines whether authentication is required.

If authentication is not required, the U1900 directly returns the 200 OK message.
ce

If authentication is required, the U1900 determines the authentication type. If the

ur

authentication type is password-based authentication, the U1900 returns the 401

so

message, indicating that authentication is required.

Re

If the authentication type is IP address-based authentication, the U1900 checks

whether the IP address in the Contact header field is configured on the U1900. If the
ng

IP address is configured, the U1900 returns the 200 OK message. If the IP address is
ni

not configured, the U1900 returns a message indicating that authentication fails.
ar
Le
re
Mo

173
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The IP phone sends the second registration request packet that carries authentication
information.
ht

The registration request contains the following information:

s:

User number for registration

ce

IP address of the registration server

ur

IP address and port number of the terminal

so

Model and version of the terminal

Re

Authentication information
Message types supported by the terminal (contained in the Allow header field)
ng
ni
ar
Le
re
Mo

174
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The U1900 verifies that the authentication information is correct and returns the 200 OK
message, indicating that registration succeeds.
ht

The IP phone updates registration based on the 600s interval specified by the Expires
s:

header field in the message returned by the U1900. Updating registration to prevent the
U1900 from removing the binding relationship when the connection times out. If the
ce

U1900 removes the binding relationship, the IP phone enters the Fault state.
ur

SIP number authentication modes:

so

Password-based authentication: The registration message carries the ciphertext of the

Re

password. The U1900 converts the password stored internally into the ciphertext and
compares it with that sent by the IP phone.
ng

The ciphertext carried in the registration message is generated from the user name,
ni

password, realm, and nonce using the MD5 algorithm, stored in the response field,
and sent to the U1900. The U1900 uses the MD5 algorithm to generate a string
ar

from the user name, password, realm, and nonce, and compares the string with the
Le

ciphertext sent by the IP phone. The encryption algorithms used on both sides are
irreversible.
re

IP address-based authentication: The registration message carries the IP address of the

Mo

IP phone. The U1900 compares the IP address stored internally with that sent by the IP
phone.

175
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

176
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

177
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

178
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Verify that the network cable is connected to the LAN port instead of the PC port.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

179
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

180
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

181
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

182
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

183
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

184
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re

2. B.
1. B;
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

185
tp
: //
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

186
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

187
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

188
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

189
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

190
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

191
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

192
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

193
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

194
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

195
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

196
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

197
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

198
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Check the system blacklist and whitelist of the calling party:

ht

show blackandwhite calltype caller

Check the system blacklist and whitelist of the called party:
s:

show blackandwhite calltype callee

ce
ur
so
Re

Note:
ng

Users in the blacklist can make calls only to users in the whitelist.
ni

Users in the common call restriction group can make calls to users in the same group
ar

or in the whitelist, but cannot make calls to users in the blacklist.

Le

Users in the whitelist can make calls to any users.

re
Mo

199
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

View the personal blacklist:

ht

show blacksubscriber
Add a personal blacklist:
s:

config add blacksubscriber userdn userdn blackdn blackdn

ce

Delete a personal blacklist:

ur

config delete blacksubscriber userdn userdn blackdn blackdn

so
Re
ng
ni
ar
Le
re
Mo

200
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

201
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

202
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

203
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Check the phone status.

ht

IDLE: Registration is normal.

FAULT: Registration fails.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

204
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

205
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Key parameters
ht

Parameter Description Fault Analysis

If a phone is in the
s:

Phone status. The value can be FAULT state, check

State
FAULT, IDEL, or BUSY. whether the phone is
ce

registered successfully.
ur

Outgoing call permission. The value Users having

OutgoingRight can be INTER, LOCAL, DDD, IDD, or corresponding service
so

any combinations of them. rights can make

Re

outgoing calls of certain

Incoming call permission. The value types or answer
IncomingRight can be INTER, LOCAL, DDD, IDD, or incoming calls of certain
ng

any combinations of them. types.

ni
ar
Le
re
Mo

206
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

If the calling number and called prefix have different 32-level right call restriction, modify
the configuration.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

207
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

208
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Use the LMT toll to trace signaling. If the call signaling is incomplete or other exceptions
occur, locate the fault based on the signaling content.
ht
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

209
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

210
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

211
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

212
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

213
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

If the DND service is registered for a user's phone, other users who call the user hear the
DND announcement, and no call is put through to the user. After registering this service,
ht

the user cannot receive any calls but can still make calls.
s:

Run the show subscriber dn dn type newservice command to view the user's service
configuration and check whether DDS is enabled.
ce

How to use the DND service

ur

Registering the service: User A who has the DND service permission picks up the phone
so

and dials *56#. An announcement is played, indicating that the DND service is
Re

registered successfully.
Using the service: Another user makes a call to user A, and hears the DND
ng

announcement or busy tone. User A can make outgoing calls.

ni

Deregistering the service: User A picks up the phone and dials #56#. An announcement
ar

is played, indicating that the service is deregistered successfully.

Le
re
Mo

214
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Call Forwarding Unconditional (CFU): This service allows calls to a user to be automatically
forwarded to a preset number regardless of the user's status.
ht

Run the show subscriber dn dn type newservice command to view the user's service
s:

configuration and check whether CFU is enabled.

Parameter Description Fault Analysis
ce

If the CFU service is enabled for a

ur

Call forwarding
CFU user but the forward-to number is
unconditional.
invalid, the call fails.
so

Calling line When the CLIP service is enabled for

Re

CLIP identification an intra-office user, the calling

presentation service. numbers are displayed to this user.
ng
ni
ar
Le
re
Mo

215
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

216
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

217
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

218
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Work Mode CallMode Value

ht

PBX NORMAL

IMS IMS
s:
ce

The U1900 unified gateway can work in IMS and PBX modes.
ur

The IMS stands for IP multimedia subsystem. It is a brand-new multimedia service system
so

that can meet the new and diverse multimedia service requirements of users. If the U1960
is connected to an IMS network, configure it to work in IMS mode; otherwise, configure it
Re

to PBX mode.

To configure the U1900 work mode, run the following command: config system
ng

workmode callmode callmode [switchmode switchmode]

ni
ar
Le
re
Mo

219
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Key license parameters

Parameter Description
ht

State Indicates whether the license is valid.

s:

License SN License serial number.

Equipment SN Device serial number.
ce

Term Validity period of the license.

ur

Trial Days Remaining validity period of the license.

so

Run LeftDays Duration that the license has been used.

Re
ng
ni
ar
Le
re
Mo

220
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

The prefix attributes include inter, local, ddd, and idd. Check whether the prefix attribute is
inter.
ht

If the 32-level right call restriction is configured for the prefix, the same 32-level right call
s:

restriction must be also configured for numbers using this prefix.

View the index referenced for called number change, and check whether the length of the
ce

called number after number change meets the prefix requirements.

ur

The minimum and maximum number lengths match the called numbers after number
so

conversion.
Re
ng
ni
ar
Le
re
Mo

221
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //

Field Description
tp

CallCategory Call type.

ht

CallAttribute Call attribute.

CustomAttribute Custom call attribute.
s:

MinLen Minimum number length.

ce

MaxLen Maximum number length.

ur

Indicates whether the long number of the calling party is

UseLongCLI
so

displayed to the called party.

CLDPredeal Flag for called number change.
Re

CLDIndex Index for called number change.

ng

ChangeType Number change type.

ChangePos Position from which the number change starts.
ni

ChangeLen Number change length.

ar

NewDn New number inserted or replaced during number change.

Le
re
Mo

222
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Impacts of a full bill pool:

ht

All outgoing calls fail.

Only incoming calls can be answered.
s:

If no CDRServer exists, clear the alarm using either of the following methods:
ce

Run the following command in the debug mode to delete CDRs from the bill pool (Note
ur

that the deleted CDRs cannot be restored): cmd 45 p1 <0-4294967295> p2 <0-

4294967295>
so

Run the following command to disable the CDR generation function: config createbill
Re

switch off
ng
ni
ar
Le
re
Mo

223
 Mo
re
Le

1. ABD.
ar
ni
ng
Re
so
ur
ce
s:
ht

224
tp
: //
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

225
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

226
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

227
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

228
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

229
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

230
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

231
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

232
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

233
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

234
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

235
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Note
ht

For detailed check operations, see called party's phone fault in an intra-office call.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

236
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

237
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

238
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

239
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Parameters
ht

Field Description
DomainName Domain name of the peer device.
s:

IPAddress IP address of the peer device.

ce

PeerTKCNum Number of trunk circuits in the peer office.

ur

SIPTKCNum Maximum number of circuits for the SIP trunk.

so

SIPOffice Number of the office route to which the SIP trunk belongs.
Re

SIP service status, which can be service state, non-service state,

SIPServiceStatus
and not configured.

Indicates whether the U1900 sends heartbeat signals to the

ng

HeartBeat
peer device periodically.
ni

Internal at which the U1900 sends heartbeat signals to the

HeartBeatPeriod
peer device.
ar

Communication status of the component, including not

Le

CommState
configured, normal, interrupted, and unknown.

VoipDomain ID of the VoIP domain.

re
Mo

240
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

241
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

242
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

243
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

show board: View all boards.

ht

OK indicates that a board is working properly.

--- indicates that no card is inserted into a slot.
s:

Fault indicates that the board is faulty or not configured.

ce

show board slot slot number: View the working status of a specified board.
ur

If State is LOS, check whether the Tx and Rx ports are reversely connected, whether the
so

trunk line is connected properly, and whether the trunk line is too long.
Re
ng
ni
ar
Le
re
Mo

244
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Note
ht

Two ends of a PRA trunk must be in network and user positions respectively, and
have the same TS value.
s:
ce
ur
so
Re
ng
ni
ar
Le
re
Mo

245
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Run the show tkc office no officeno command to check the trunk circuit status (that is,
value of the State field).
ht

If State is ISOLATE, run the config cancelisolate board slot slotno command to
s:

cancel the board isolation configuration.

If State is Fault, check whether the PRA trunk is correctly configured.

ce

If State is IDLE, go to the next step.

ur

so
Re
ng
ni
ar
Le
re
Mo

246
 en
m/
co
i.
we
ua
.h
ng
ni
ar
le
: //
tp

Run the show pralink command to check the trunk link status (value of the State field).
ht

If State is FAULT, verify the following link configurations:

The local and peer network positions (value of the Position field) must be correct.
s:

That is, one end is the network side, and the other end is the user side. Generally,
the U1981 unified gateway is configured as the user side.
ce

The timeslot of the link (value of the TS field) is 16 on both the local and peer ends.
ur

If the preceding configurations are incorrect, run the config

so

modify pralink linkno linkno slot slot trunkport trunkport position <user |
Re

network> ts ts command to correct them.

ng
ni
ar
Le
re
Mo

247
 Mo
re
Le
ar

1. ABCD.
ni
ng
Re
so
ur
ce
s:
ht

248
tp
: //
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

249
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

250
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

251
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

252
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

253
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le

1. AC.
ar
ni
ng
Re
so
ur
ce
s:
ht

254
tp
: //
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

255
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

256
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

257
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Mo
re
Le
ar
ni
ng
Re
so
ur
ce
s:
ht

258
tp
://
le
ar
ni
ng
.h
ua
we
i.
co
m/
en
 Glossary

Number

en
3WC: Three-Way Calling

m/
A

co
AC: Alternative Current

i.
ACD: Automatic Call Distributor

we
AG: Access Gateway

ua
AN: Access Network

.h
ARP: Address Resolution Protocol

ng
B

ni
BHCA: Busy Hour Call Attempts

ar
BHCC: Busy Hour Completed Call

BLF: Busy Lamp Field

le
//
BMU: Business Management Unit
:

BS: Billing System

tp

C
ht

CAS: Channel Associated Signaling

s:

CC: Conference Call

ce

CDMA: Code Division Multiple Access

ur

CDR: Call Details Records

so

CFB: Call Forwading Busy

Re

CFNR: Call Forwarding No Reply

CFO: Call Forwarding Offline

ng

CFU: Call Forwarding Unconditional

ni

CTVMNR: Call Transfer to Voice Mailbox on No Reply

ar

CTVMU: Call Transfer to Voice Mailbox Unconditional

Le

CTVMB: Call Transfer to Voice Message on Busy

CH: Call Hold

re

CLI: Command Line Interface

Mo

CLIP: Calling Line Identification Presentation

CLIR: Calling Line Identification Restriction

259
 CLIRO: Calling Line Identification Restriction Override

CNIP: Calling Name Identification Presentation

en
CNIR: Calling/Connected Name Identification Restriction

m/
CODEC: Code And Decode

co
COLP: Connected Line Identification Presentation

i.
CONP: Connected Name Identification Presentation

we
CRC: Cyclic Redundancy Check

ua
CT: Call Transfer

.h
D

ng
DC: Direct Currect

ni
DID: Direct-Inward-Dialing

ar
DDI: Direct-Dialing-In

DND: Do-Not-Disturb
le
//
DSP: Digital Signal Processor
:

DSS1: Digital Subscriber Signaling No.1

tp

DTMF: Dual Tone Multiple Frequency

ht

E
s:

EMC: Electromagnetic Compatibility

ce

EMS: Element Management System

ur

ESD: ElectroStatic Discharge

so

F
Re

FXS: Foreign eXchange Station

FXO: Foreign eXchange Office

ng

G
ni

GUI: Graphical User Interface

ar

I
Le

IAD: Integrated Access Device

IPCC: IP Contact Center

re

IPT: IP Telephony
Mo

ISDN: Integrated Services Digital Network

IVR: Interactive Voice Response

260
 L

LAN: Local Area Network

en
LDAP: Lightweight Directroy Access Protocol

m/
LE: Local Exchange

co
LMT: Local Maintenance Terminal

i.
M

we
MAS: Mobil Agent Server

ua
MGC: Media Gateway Controller

.h
MGW/MG: Media Gateway

ng
MoH: Music on Hold

ni
N

ar
NGN: Next Generation Network

O
le
//
OMU: Operation Maintenance Unit
:

ONLY: One Number Link You

tp

P
ht

PBX: Private Branch Exchange

s:

PGND: Protection Ground

ce

POTS: Plain Old Telephone Service

ur

PRA: Primary Rate Adaptation

so

PRI: Primary Rate Interface

Re

PSTN: Public Switched Telephone Network

R
ng

RBT: Ring Back Tone

ni

RTCP: Real-time Transport Control Protocol

ar

RTP: Real-time Transport Protocol

Le

RX: Receive
re
Mo

261
 S

SCE: Service Creation Enviroment

en
SG: Signaling Gateway

m/
SNMP: Simple Network Management Protocol

co
SNTP: Simple Network Time Protocol

i.
SIP: Session Initiation Protocol

we
SMTP: Simple Mail Transfer Protocol

ua
SS: Supplementary Service

.h
T

ng
TDM: Time Division Multiplex

ni
TFTP: Trivial File Transfer Protocol

ar
TMG: Trunk Media Gateway

TX: Transmit
le
//
U
:

UA: User Agent

tp

UC: Unified Communications

ht

UMS: Unified Message System

s:

USB: Universal Serial Bus

ce

V
ur

VLAN: Virtual Local Area Network

so

VoIP: Voice over IP

Re

VU: Virtual User

ng
ni
ar
Le
re
Mo

262