The H3C XE 200/2000 IP PBX (hereinafter referred to as XE IP PBX) supports both session initiation protocol (SIP) and H.323 protocol, and thus is suitable for complex networks deployed with both SIP and H.323 devices.

An XE IP PBX can serve as a location server (LS), a process server (PS) and/or a media server. This module mainly describes how to configure an XE IP PBX functioning as a PS.

A PS provides the function of an H.323 gatekeeper and/or a SIP Server, depending on your configuration. Figure 1-1 shows the architecture of the XE IP PBX.

Figure 1-1 Architecture of the XE IP PBXs

Configure an XE IP PBX as follows depending on the network where the IP PBX is deployed:

l In a SIP network, enable SIP Server on the PS, and set gateway device type to SIP user agent (UA) on the LS.

l In an H.323 network, enable gatekeeper on the PS, and set gateway device type to H.323 on the LS.

l In a complex network deployed with both SIP and H.323 devices, enable SIP server and gatekeeper on the PS, and set the proper gateway device type on the LS.

For the configuration of LS, refer to the “LS Configuration” part of this manual.

1.2 PS Capacities

The following table describes the capacities of XE 200/2000 IP PBXs.

Table 1-1 Capacities of the XE 200/2000 IP PBXs

Item	XE 200	XE 2000
Max. concurrent online gateway devices	400	4000
Max. subscriber numbers	400	4000
Max. maintained calls	400	4000
Min. call ability per second (CAPS)	1	5

Chapter 2 H.323 Overview

2.1 Introduction to H.323 Protocol

H.323, packet-based multimedia communications system, is a standard that specifies the components, protocols, and procedures that provide multimedia communication services over packet networks. It has long been used by traditional carriers and network device manufacturers in their VoIP solutions. Now, it is one of the standards for VoIP.

The H.323 protocol suite is specified for LANs that provide non-guaranteed quality of service (QoS) and is implemented at the application layer. It includes protocols such as H.225.0, H.245, G.729, G.723.1, G.711, H.261, H.263, and T.120 series. Among them, G.723.1, G.729, and G.711 are audio codec protocols; H.263 and H.261 are video codec protocols; H.225.0 and H.245 are system control protocols; and T.120 series are multimedia data transmission protocols.

The real-time transport protocol (RTP) provides end-to-end real-time audio and video delivery services. Its functionality is enhanced through its control protocol, the RTP control protocol (RTCP). The primary function of RTCP is to provide feedback on the quality of data distribution, which allows the application system to accommodate to different network conditions and helps with fault isolation as well. These two protocols work together to ensure real-time voice transmission.

H.323 applies to initiate sessions. It sets up and terminates a multimedia session involving a group of participants, and dynamically adjusts and modifies session characteristics such as required media type (voice or video), media encoding/decoding format, and multicast/unicast.

H.323 adopts the Client/Server model and sets up user calls through communication between gateway and gatekeeper.

2.1.1 Terms

I. H.323 terminal

The H.323 terminals are communication devices of terminal users. They must support at least one audio coding format in the H.323 protocol suite. They can also optionally support video coding formats.

II. H.323 gateway

H.323 gateways are responsible for the signaling conversions between different signaling protocols and the information conversions between different media formats. They allow PSTN terminals and H.323 terminals to communicate with each other transparently.

III. H.323 gatekeeper

H.323 gatekeepers are optional to an H.323 network. They function to manage H.323 network by providing endpoints services such as network access control, call routing control, and address translation.

IV. H.323 signaling

H.323 protocol suite contains the following three types of signaling:

l RAS signaling. This type of signaling is used between H.323 gateways and H.323 gatekeepers for operations such as gatekeeper discovery, gateway registration/unregistration, call access permission, and call release. In a voice network that contains gatekeepers, RAS signaling channels exist between voice gateways and gatekeepers. They are established prior to other channels and are independent of the call control channels and the media control channels. RAS signaling exchange is necessary for both direct and gatekeeper routed call modes. A RAS channel is an unreliable channel.

l H.225.0 call control signaling. This type of signaling is used to set up call connections between H.323 gateways or between H.323 gateways and gatekeepers. In a voice network that contains no gatekeepers, a call control signaling channel is established between the calling gateway and the called gateway. In a voice network that contains gatekeepers, if the call is set up in direct call mode, the calling gateway obtains the call address of the called gateway through RAS signaling exchange, and the call control signaling channel is established between the calling gateway and the called gateway. Whereas if the call is setup in routed call mode, the call control signaling channel is established between the gateway and the gatekeeper. A call control signaling channel is independent of the RAS channel and H.245 media control channel. It is a reliable channel.

l H.245 media channel control signaling. This type of signaling is used to establish multimedia channels (RTP [real time protocol]/RTCP [RTP control protocol] channels) between calling gateways and called gateways. The procedure to establish a multimedia channel contains sub-procedures such as master-slave determination, capability exchange, and opening logical channels. In this procedure, the calling and called gateways exchange multimedia information such as the information about the channel ports and the coding/decoding methods of them.

In a voice network that contains no gatekeepers, the H.245 media channel control signaling channel is established between the calling gateway and the called gateway. The calling gateway obtains the H.245 signaling address of the called gateway through H.225.0 call control signaling. In a voice network that contains gatekeepers, if the call is set up in direct call mode, the H.245 media channel control signaling channel is established between the calling gateway and the called gateway. Whereas if the call is set up in routed call mode, the H.245 media channel control signaling channel is established between the gateway and the gatekeeper.

An H.245 media control signaling channel is independent of the RAS channel and the H.225.0 call control signaling channel. It is a reliable channel.

V. H.323 call modes

For networks containing gatekeepers, the H.323 call mode refers to the way to transmit call control signaling and H.245 media channel control signaling. H.323 protocol suite defines two call modes: direct call and routed call.

l Direct call

Figure 2-1 H.323 direct call

The process of a direct call is as follows.

1) The calling gateway gets authenticated at the gatekeeper through RAS signaling exchange. It then obtains the call signaling address of the called gateway from the gatekeeper if it passes the authentication.

2) The calling gateway establishes a call control channel between itself and the called gateway using the call signaling address. Through this channel, the calling gateway communicates with the called gateway with call control signaling to exchange H.245 address information.

3) The calling gateway and the called gateway establish media control channel using the H.245 address information they obtain to exchange multimedia channel information.

In direct call mode, call control signaling and media channel control signaling are exchanged between the calling gateway and the called gateway directly rather than through the gatekeeper.

l Routed call

Figure 2-2 Routed call

The process of a routed call is as follows.

1) The calling gateway gets authenticated at the gatekeeper through RAS signaling. It then obtains the call signaling address of the gatekeeper if it passes the authentication.

2) The calling gateway establishes a call control channel between itself and the gatekeeper using the call signaling address.

3) The gatekeeper establishes a call control channel between itself and the called gateway. The calling gateway then sends a call setup request to the called gateway through the gatekeeper.

4) The called gateway gets authenticated at the gatekeeper through RAS signaling.

5) The calling gateway and the called gateway exchange call control signaling through the gatekeeper. This procedure varies in the following ways:

If the gatekeeper gets the H.245 address of the calling gateway during the exchange of call control signaling:

l The gatekeeper opens a H.245 port and notifies the called gateway.

l The called gateway actively establishes a media channel control signaling channel between itself and the gatekeeper.

l The gatekeeper establishes a media channel control signaling channel between itself and the calling gateway.

l The calling gateway and the called gateway exchange media channel control signaling and multimedia information through the gatekeeper.

If the gatekeeper gets the H.245 address of the called gateway during the exchange of call control signaling:

l The gatekeeper opens a H.245 port and notifies the calling gateway.

l The calling gateway establishes a media channel control signaling channel between itself and the gatekeeper.

l The gatekeeper establishes a media channel control signaling channel between itself and the called gateway.

l The calling gateway and the called gateway exchange media channel control signaling and multimedia information through the gatekeeper.

In this mode, the calling gateway and the called gateway exchange the call control signaling and the media channel control signaling through the gatekeeper.

VI. H.323 call setup modes

Based on the exchange method of multimedia information, such as the RTP/RTCP transmission address), H.323 calls can be set up in common mode or faststart mode.

l Common: Multimedia channel information is transferred through the multimedia control signaling channel. In this mode, H.245 processes including master/slave gateway decision, capability negotiation and logical channel opening are involved.

l Faststart: Multimedia channel information is transferred through the call control signaling channel by the fastStart parameter in the call control signaling. In this mode, H.245 processes including master/slave gateway, capability negotiation and logical channel opening are not involved.

2.1.2 H.323 Architecture

The architecture of H.323 includes terminals, gateways, gatekeepers and multipoint control units (MCUs). Gatekeepers are optional in an H.323 network; but if a gatekeeper is present, the terminals, gateways, and MCUs registered with the gatekeeper form a zone (see Figure 2-3). These devices can overlay networks or subnets through routers.

A zone is independent of network topology. It may comprise multiple network segments connected using routing devices. Multiple zones form an H.323 system.

MCUs are applied mainly in VoIP networks that provides voice conferencing functions. A MCU consists of a multipoint controller (MC) and a multipoint processor (MP). In multipoint conferencing, the MC is in responsible for capability exchange with endpoints, and the MP processes media streams (including audio/video/data streams from terminals) and then forwarded them to the destination.

Figure 2-3 H.323 zone

2.1.3 H.323 Operating Fundamentals

I. Gatekeeper discovery

Gatekeeper discovery refers to the process that an endpoint looks for a gateway ready to serve and control it. RAS signaling is used between endpoints and gatekeepers. The endpoint unicasts or multicasts a Gatekeeper Request (GRQ) message and the gatekeeper or gatekeepers respond with a Gatekeeper Confirm (GCF) or Gatekeeper Reject (GRJ).

II. Registration

If an endpoint sends a registration request (RRQ) message to a discovered or static gatekeeper for joining the zone the gatekeeper governs, it may receive a registration confirm (RCF) or registration reject (RRJ) message to accept or reject the registration request.

After registration, either side can ask for canceling registration by sending an Unregistration Request (URQ) message. However, whether to cancel registration is up to the gatekeeper: the endpoint can only respond with an Unregistration Confirm (UCF) message to cancel registration.

III. Address translation

If the calling endpoint knows the alias of the called endpoint but not the call signaling address, it sends a Location Request (LRQ) message to the gatekeeper.

IV. Access control

If the address of the called endpoint is available, the calling endpoint sends an Admissions Request (ARQ) message, based on which the gatekeeper decides whether to allow this endpoint to join a call process. This is how the gatekeeper controls admission. In the ARQ message sent to the gatekeeper, the calling endpoint may ask for direct call signaling (see Figure 2-4) or gatekeeper-routed call signaling (see Figure 2-5). Which method is used however, is decided by the gatekeeper in the Admissions Confirm (ACF) message.

Figure 2-4 Direct call signaling between endpoints

Figure 2-5 Gatekeeper-routed call signaling

V. Call setup

When the calling endpoint receives the ACF message from the gatekeeper, it sends call signaling to request a call. In a direct call signaling, for example, the calling endpoint first sends a call setup signaling message (setup) to the called endpoint, requesting for a connection.

VI. Call proceeding

When the called endpoint receives the setup message, it responds with a call proceeding message, indicating the request is being processed. It may choose not to send this message however.

VII. Alerting

Then the called endpoints may send an alerting message to the calling endpoint indicating its status, for example, ringing. This is optional too.

VIII. Connecting

If the called endpoint accepts the call, it sends a connect message. This is mandatory.

IX. Capability negotiation

After the calling endpoint receives the connect message, the H.245 control signaling channel is established to control the media session between the endpoints. First, the communicating parties exchange information on their capabilities, such as media format.

X. Opening/closing logical channel(s)

The communicating parties open one or more logical channels between them for transporting media streams. (The logical channels are specified by IP address plus port number.)

These channels are closed when the communication is over.

XI. Release completing

Finally, either party in communication can release resources by sending a release complete call signaling message.

XII. Disengaging

The endpoints send a Disengage Request (DRQ) to their own gatekeepers, who will confirm or reject the request. The gatekeepers however, may send DRQs to the endpoints. In this case, the endpoints can only confirm the request.

Figure 2-6 shows the flow of call setup and disconnection involving gatekeepers, or gatekeeper-routed call signaling.

Figure 2-6 Gatekeeper-routed call signaling

2.2 Functionality and Features of H.323 Gatekeeper

2.2.1 Registration Management

An endpoint, after discovering a gatekeeper providing service for it, must register with the gatekeeper before it can access the zone of this gatekeeper.

When the gatekeeper receives the RRQ message from the endpoint on its default RAS port 1719 (you can change the RAS port to another one), it makes registration decision based on the information contained in the message.

In the RRQ, the endpoint provides two IP addresses: one for transmitting/receiving RAS signaling, and the other for call signaling.

Chapter 3 Gatekeeper Configuration

3.1 Introduction to Gatekeeper Configuration

Given the XE 200 or the XE 2000, the H.323 gatekeeper must cooperate with the LS. The gatekeeper provides call control and registration service, and retrieve/report user information from/to the LS. This chapter describes how to configure the H.323 gatekeeper.

To know how to configure the LS, refer to the chapter discussing configuration examples in the “LS Configuration” part of this manual.

3.2 Basic Gatekeeper Configuration

I. Entering PS view

Execute the following command in system view.

Table 3-1 Enter PS view

Operation	Command
Enter PS view	process-server

II. Assigning an LS to a PS

The LS assigned to a PS can be co-located with the PS or not. If they are not co-located, you must configure the IP address, port number and priority of the device where the LS is located.

Caution:

When configuring a remote LS, make sure that its IP address and port number are the same as the ones configured on the LS.

Perform the following configuration in PS view.

Table 3-2 Assign an LS to the PS

Operation	Command
Configure an LS entry for the PS by specifying the local LS	ls-mode id-priority local
Configure an LS entry for the PS by specifying the IP address of a remote LS	ls-mode id-priority remote ip-address ip-address
Configure an LS entry for the PS by specifying the IP address and port number of a remote LS	ls-mode id-priority remote ip-address ip-address port port-number
Delete a specified LS entry or all LS entries	undo ls-mode { id-priority \| all }

III. Configuring heartbeat password

The LS learns about whether a PS is alive by listening to the keepalive messages sent regularly by the PS. They use heartbeat password to identify each other. Therefore, the heartbeat password configured for the PS must be the same as the one retained by the LS. Any inconsistency will result in disconnection.

Perform the following configuration in LS view.

Table 3-3 Configure a heartbeat password

Operation	Command
Configure a heartbeat password for the PS	heartbeat password password
Restore the default	undo heartbeat password

By default, the heartbeat password for the PS is XEngine.

IV. Configuring the identifier and interface of a PS

An LS uses PS identifier to distinguish between PSs. When configuring an identifier for a PS, make sure that the same one is configured on the LS and the PS.

The interface specified using the ps-config command is a network interface on the device where the PS is located.

Perform the following configuration in PS view.

Table 3-4 Configure the identifier and interface of a PS

Operation	Command
Configure the identifier of the PS and specify its interface	ps-config identifier interface interface-type interface-number
Remove the basic configuration of the PS	undo ps-config

V. Enabling/disabling a PS

Disabling/enabling a PS with the stop or start command is a software reset operation. It will interrupt ongoing calls, disconnecting the PS from the LS and preventing it from receiving messages from gateways. Then the PS reconnects with the LS for receiving messages from gateways. (The gateway in this manual refers to H.323 gateway and SIP user agent client, unless otherwise noted.)

Perform the following configuration in PS view.

Table 3-5 Enable/disable the PS

Operation	Command
Enable the PS	start
Disable the PS	stop

& Note:

Enabling (disabling) the PS enables (disables) the gatekeeper and SIP Server.

VI. Enabling/disabling long-time call interruption

This command is used to enable/disable long-time call interruption function. Each time you use the function, a timer is enabled on the server which will break the conversation when timeout interval expires on the timer.

Perform the following configuration in PS view.

Table 3-6 Enable/disable long-time call interruption

Operation	Command
Enable long-time call interruption	policy call-interrupt-by-long-time enable
Disable long-time call interruption	policy call-interrupt-by-long-time disable

VII. Configuring timeout interval for call interruption function

This command is used to configure the timeout interval for the call interruption function. If the timeout interval expires, the server will break the conversation.

Perform the following configuration in PS view.

Table 3-7 Configure the timeout interval for call interruption

Operation	Command
Configure the timeout interval for the call interruption	policy call-interrupt-time call-interrupt-time
Restore the default timeout interval	undo policy call-interrupt-time

VIII. Entering PS-GK view

This command is used to enter PS-GK view.

Perform the following configuration in PS view.

Table 3-8 Enter PS-GK view

Operation	Command
Enter PS-GK view	gatekeeper

IX. Enabling/disabling the gatekeeper

The gatekeeper is disabled by default. When you use an XE IP PBX as a gatekeeper, you must enable the gatekeeper function on it.

Perform the following configuration in PS-GK view.

Table 3-9 Enable/disable the gatekeeper

Operation	Command
Enable the gatekeeper	start
Disable the gatekeeper	stop

& Note:

When the PS is disabled, enabling the gatekeeper function will also enable the PS.

3.3 Advanced Gatekeeper Configuration

I. Configuring the RAS signaling port of the gatekeeper and the endpoint TCPCall signaling port

H.323 gateways and gatekeepers use RAS signaling to exchange messages. A gatekeeper receives/transmits RAS signaling on its RAS port. The backup RAS port is used to assist the RAS port in RAS signaling transmission and receiving.

When the gatekeeper function is enabled on an XE IP PBX, the RAS port and backup RAS port (if configured) on the XE IP PBX are enabled for RAS transmitting and receiving.

In H.323 basic routed call mode, the calling and called gateways exchange call control signaling through an XE IP PBX that serves as a gatekeeper. The gatekeeper listens the TCP connection requests transmitted when gateways attempt to establish call control signaling channel through the endpoint TCPCall signaling port (that is, the Q931 port).

& Note:

Usually a backup RAS signaling port is not required. It applies when two ports are needed for RAS signaling transmitting and receiving. For example, some devices send RRQ messages to port 1719 and GRQ messages to port 1718. In this case, configure rasport as 1719 and 2nd-port as 1718.

Perform the following configuration in PS-GK view.

Table 3-10 Configure the RAS port of the gatekeeper and the Q931 port

Operation	Command
Configure the RAS port of the gatekeeper	gk-config rasport port-number
Configure the Q931 port of the gatekeeper	gk-config q931port port-number
Configure the backup RAS port of the gatekeeper	gk-config 2nd-port port-number
Restore the default RAS port	undo gk-config rasport
Restore the default Q931 port	undo gk-config q931port
Delete the backup RAS port of the gatekeeper	undo gk-config 2nd-port

The default RAS port of a gatekeeper is 1719.

The default Q931 port of a gatekeeper is 1720.

II. Configuring the IRR response switch of the gatekeeper

H.323 gateways use Information Request Response (IRR) messages to provide status information to their gatekeepers. You can enable or disable the gatekeeper to respond to the IRR messages.

Perform the following configuration in PS-GK view.

Table 3-11 Configure the IRR response switch of the gatekeeper

Operation	Command
Configure the IRR response switch of the gatekeeper	response-irr { off \| on }

By default, the IRR response switch is turned on.

III. Configuring IRR report interval

You can configure the interval in seconds at which gateways report status information to their gatekeepers. If it is set to 0, no regular IRR report is required.

Perform the following configuration in PS-GK view.

Table 3-12 Configure the interval for IRR report

Operation	Command
Configure the interval for IRR report	irr-frequency irr-frequency-value
Restore the default interval at which gateways report their state information to the gatekeeper regularly.	undo irr-frequency

IRR report interval defaults to 60 seconds.

IV. Configuring the LRQ signaling processing method of the gatekeeper

The gatekeeper processes LRQ signaling by two methods:

l LRQ terminated: The gatekeeper responds the LRQ signaling with an LCF signaling, whose destination call signaling address is the call signaling address of this gatekeeper.

l LRQ forward: After receiving an LRQ signaling all of whose highest-priority called gateways are office devices of the gatekeeper type, the gateway forwards it to one of these devices.

Perform the following configuration in PS-GK view.

Table 3-13 Configure the LRQ signaling process method of the gatekeeper

Operation	Command
Configure the LRQ signaling process method of the gatekeeper	lrq-mode { forward \| terminated }
Restore the default LRQ signaling process method of the gatekeeper	undo lrq-mode

By default, the terminated mode is used.

In a network with multiple gatekeepers, usually the gatekeeper uses the forward mode and other gatekeepers use the terminated mode.

Chapter 4 SIP Overview

4.1 Introduction to SIP

Session initiation protocol (SIP) is an application layer control protocol that establishes, modifies, and terminates multimedia sessions such as IP phone calls, multimedia distribution, and multimedia conferences. It is the core component in the multimedia data and control architecture of IETF and the RFC for it is RFC3261.

SIP involves issues such as signaling control in IP networks and communication with soft switch platforms, intending to build a next generation value-added service platform to deliver better value-added services to telecom carriers, banks, and financial organizations.

SIP is used for initiating sessions. It sets up and terminates a multimedia session involving a group of participants and dynamically adjusts and modifies session characteristics such as media type (voice, video, or data), media encoding/decoding format, and multicast/unicast. SIP is based on text encoding and constructed taking HTTP, a quite mature protocol, as a model. Easy to extend and implement, it is suitable for implementing Internet-based multimedia conference systems.

SIP adopts the Client/Server model and sets up user calls through communication between user agents and proxy servers.

A SIP endpoint can directly send an INVITE carrying its description to another endpoint to set up a session. Upon receipt of the message, the destination endpoint accepts or rejects it considering its own capabilities and the information in the message. The sender can also send the INVITE to the destination endpoint through one or more entities called proxy servers. A proxy server works on behalf of a requestor, locating its destination endpoint, routing, authenticating and authorizing as required, and even providing a call routing policy.

SIP records description information of each endpoint on registrars, such as address, route, and number. SIP endpoints can register or update their descriptions by sending REGISTER messages to their registrars.

As an application layer protocol, SIP uses either TCP or UDP for transport and can work with both IPv4 and IPv6.

4.1.1 Terms

I. Multimedia session

According to RFC2327, "A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session." A session is identified by a set of username, session ID, network type, address type, and address elements in the origin field.

II. User agent

A user agent (UA), or SIP endpoint, is a SIP-supported multimedia session endpoint, which can be a phone, a gateway, or a router.

III. User agent client

A user agent client (UAC) is a device that creates a new session request. It can be a calling SIP endpoint or a proxy server forwarding a request to a called endpoint for example.

IV. User agent server

A user agent server (UAS) is a device that generates response to a SIP request. It can be a called SIP endpoint or a proxy server receiving a request from a calling endpoint for example.

V. Proxy server

A proxy server is a device that forwards session requests to a called UA on behalf of a calling UA (SIP endpoint) and responds to the calling UA on behalf of the called UA.

When the proxy server receives a request from a calling UA, it first requests its registrar for information on callee location and call policies of caller and callee. If the location information of the callee is available and the caller is allowed to make the call, the proxy server then forwards the request to the callee.

VI. Redirect server

A redirect server is a device that directs a calling UA to contact an alternate location for calling the called UA.

When receiving a request from a calling UA, the redirect server searches for the location information of the called UA and returns information on a location. This location can be that of the called UA or another proxy server, to which the UA can initiate the session request again. The subsequent procedure is the same as that for calling a called UA directly or for calling a proxy server.

VII. LS

A LS is a device that provides UA information to proxy and redirect servers; it retains UA information received by a registrar. Normally, LS and registrar are co-located.

VIII. Registrar

A registrar records location information of UAs for proxy servers to retrieve. In some simple applications, the registrar and the associated proxy server are usually co-located.

4.1.2 Functionality and Features of SIP

SIP supports five facets of establishing and terminating multimedia communications:

l Locating users or called SIP endpoints, the most powerful function of SIP. SIP has registration function itself. In addition, it can enhance its user location service by using the LS provided by domain name server (DNS) or lightweight directory access protocol (LDAP).

l Determining user availability, making sure whether a calling/called endpoint can participate in a session. SIP supports multiple address description and addressing styles, including username@hostname and called number@PSTN gateway address and telephone number (such as Tel: 01012345678). Thus, a SIP caller can identify whether a callee is attached to a PSTN network by callee's address, and then initiate and set up the call to the callee through the gateway connected to the PSTN.

l Determining user capabilities, or the media and media parameters to be used by a called endpoint. In a message exchange process, each SIP endpoint carries such information in transmitted messages so that all other participants can learn about its capabilities.

l Setting up a session, or session parameters, at both callee and caller sides. Two parties can select the appropriate capabilities for session setup through negotiation about media and media parameters to be used.

l Managing sessions by modifying session parameters or terminating sessions.

The following are the features delivered by SIP:

l Open standards. It can accommodate new functions, products, and services introduced by different service providers.

l Flexible configurations. It accommodates a wide range of dialup, wire, and wireless devices, allows highly flexible configurations, and can work with other systems.

l Scalable system. The system allows expansion as enterprises grow.

l Support to remote users. With SIP, an enterprise network can extend to all its users, wherever they are.

l Competitive advantage potentials. More SIP-based services are emerging.

l Consistent communication method. Management becomes easier as the result of consistency in dialup mode and system access method used by branches, SOHOs, and traveling personnel.

l Quick launch. The system can be updated quickly to accommodate new branches and personnel, as well as changes resulted from job rotation or relocation.

l Easy to install and maintain. Even unprofessional individuals can install and maintain SIP system configurations.

4.1.3 SIP Fundamentals

I. Registration

In a complete SIP system, all SIP endpoints working as UAs should register with SIP registrars through proxy servers, providing information such as location, session capabilities, and call policy.

Normally, a SIP UA sends its registrar a REGISTER request at startup or in response to an administratively registration operation, carrying all the information that must be recorded. Upon receipt of the request, the registrar sends back a response notifying receipt of the request and if the registration is accepted an OK (SUCCESS) message as well. See the following figure.

Figure 4-1 Message exchange for a UA to register with a Registrar via a proxy server

II. Call setup

SIP operates in Client/Server model and sets up calls through UA-proxy server communication.

Figure 4-2 Connect UAs through proxy servers

In the above figure, Phone1 wants to call Phone 2; and two voice gateways, VG 1 and VG 2, work as SIP endpoints (UAs).

The following are the procedures for connecting a call from Phone 1 to Phone 2:

1) Phone 1 dials the number of Phone 2.

2) Upon receipt of the call, VG 1 sends a session request (INVITE) to SIP Server.

3) SIP Server consults its database for information corresponding to the number of Phone 2. If such information is available, it forwards the request to VG 2.

4) VG 2, after receiving the request, responds to SIP Server and has Phone 2 ring if Phone 2 is available.

5) SIP Server forwards a response to VG 1. The response discussed here includes two messages: provisional (180 Ringing) and success (200 OK). When informing Phone 2 about invitation, VG 2 returns a 180 Ringing message to SIP Server; when Phone 2 is picked up, VG 2 returns a 200 OK message to SIP Server indicating the call is connected.

6) VG 1 sends an acknowledgement to VG 2, indicating it is ready for the conversation.

This completes the INVITE –– Final response (200) –– ACK three-way handshake. See Figure 4-3 for the message interactions throughout the call setup process.

Figure 4-3 Call setup procedures through a proxy server

This is a simple scenario where only one proxy server is involved and no registrar is present. A complex scenario, however, may involve multiple proxy servers and registrars.

III. Call redirect

When a SIP redirect server receives a session request, it sends back a response indicating address of the called SIP endpoint instead of forwarding the request. The calling and called endpoints thus can send request and response to each other bypassing the SIP proxy server. See the following figure.

Figure 4-4 Call redirect procedures for UAs

This is a common application. Fundamentally, a redirect server can respond with the address of a proxy server as well. The subsequent call procedures are the same as the call procedures involving proxy servers.

4.1.4 SIP Messages

SIP messages are text-coded and fall into two categories: request and response.

SIP requests include INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER and so on. Their functions are described in the following table.

Table 4-1 Functions of SIP request messages

Message	Function
INVITE	Invites a user to join a call
ACK request	Confirms a response
OPTIONS	Requests capability negotiation
BYE	Releases a call that has been established
CANCEL	Releases a call that has not been established
REGISTER	Registers user information such as location with a SIP registrar

A SIP response is sent indicating whether a call or registration request is accepted or fails. Each SIP response contains a three-digit status-code, where the first digit defines the class of response and the last two digits provide more information. The following table lists the classes of response.

Table 4-2 Status codes of response

Status code	Means…	Falls into class	Message type
100 to 199	A request is received and being processed	Provisional	Proceeding
200 to 299	The request is successfully received, understood, and accepted	Success	Completed
300 to 399	Further action needs to be taken to complete the request	Redirection	Completed
400 to 499	The request contains bad syntax and the SIP Server cannot process it	Client error	Completed
500 to 599	The SIP Server fails and cannot process the valid request	Server error	Completed
600 to 699	The request cannot be fulfilled at any server	Global failure	Completed

As required by SIP, the application may ignore the last two digits of status code, but it must understand the first digit.

4.2 Functionality and Features of SIP Server

4.2.1 SIP Proxy Server

When an XE IP PBX operates in call-routing model, it is a SIP proxy server which provides these functions:

l User-to-user call, in call-routing mode

In call-routing mode, the caller’s SIP proxy server can directly route a call to the called UA, provided the LS knows about the routing information of the called UA. This information can be gained either through report from another proxy server or through interaction with another LS. In this case, the called UA needs not to register with the caller’s SIP proxy server.

l Caller identification display

The proxy server extracts the address of calling UA and sends it in the session request to the called UA.

l Simultaneous ringing of multiple callees

You can have one number associated with multiple telephones (terminals) and have these telephones rung simultaneously when the number is called. (You need to configure the same priority for all the terminals and disable the random selection function at the same time. Refer to 1.4.1 “Enabling/Disabling Random Selection” in Location Server Configuration Operation” for details about random selection function.)

l Ringing of multiple callees in turn

You can have one number associated with multiple telephones (terminals). When the number is called, these telephones ring in turn according to their preferences; these telephones will ring simultaneously if they share the same preference. (You need to configure different priority values for the terminals, or configure the same priority for all the terminals and enable the random selection function at the same time. Refer to 1.4.1 “Enabling/Disabling Random Selection” in Location Server Configuration Operation” for details about the random selection function.)

& Note:

Only in the call-routed mode can the XE voice server support “simultaneous ringing of multiple callees” and “ringing of multiple callees in turn”. While in the call-redirect mode, the XE voice server will direct a call involving multiple callees to one phone.

l Authentication, handling 401 (unauthorized) that contains challenges

After the SIP proxy server forwards the INVITE to the callee’s UA, it may receive a 401 if the callee’s UA requires authentication. It then forwards the 401 to the originating UA.

If the originating UA provides authentication information in the resubmitted INVITE, the proxy server then forwards it to the callee’s UA for authentication.

l Periodic connectivity check between SIP proxy server and LS

A SIP proxy server and an LS need to maintain the connection between them for communication. To check connectivity, they periodically exchange messages.

l Transport protocol selection

In communicating with other devices, the SIP proxy server uses two transport protocols: TCP and UDP. Automatic selection between the two protocols is available.

l Multiplexing over TCP connections

When multiple calls that use TCP are present to a next hop, the SIP proxy server can multiplex them onto one TCP connection and will never request for closing the connection.

l Repairing TCP connection

If the TCP connection between the SIP proxy server and the next hop becomes unavailable for some reasons, the proxy server may originate a new TCP connection for transmission.

l Call tracing

On the proxy server, you may configure numbers that require call tracing. The SIP proxy server then tracks the state of calls related to these numbers during sessions.

l Statistics query

The SIP proxy server can provide statistics such as messages sent/received by the internal and external modules and errors generated.

l Proxy server debugging

Depending on your setting, enabling proxy server debugging can output related debugging information for problem analysis.

The following are features of the proxy server:

l Networking with H3C’s LSs.

l Networking with H3C’s SIP clients.

l RFC3261 compliant and backward compatible. It accommodates SIP terminals compliant with RFC2543. It supports RFCs 3262 (PRACK), 2976 (INFO), 2327 (SDP) and SDP transparent transmission in Offer-Answer model.

l Interoperation with SIP gateways and terminals of other vendors.

4.2.2 LS

When functioning as a LS, the XE IP PBX can manage H.323 devices and SIP devices at the same time. For more information about that, refer to the section discussing functionality and features of the LS in the “LS Configuration” part of this manual.

4.2.3 SIP Registrar

The SIP registrar supports:

l Registering UAs with or without authentication

l Periodic registration and always-on feature of devices

l In-service device information update

l Dynamic IP users

If the IP address of a UA changes dynamically, the UA sends its new IP address when sending a REGISTER request to the registrar, which, in turn, reports it to the LS. Accordingly, the LS updates the address information of the UA.

l Supporting two transport protocols: TCP and UDP

l Statistics query

The SIP registrar can provide statistics such as messages sent/received by the internal and external modules and errors generated.

4.2.4 SIP Redirect Server

When an XE IP PBX operates in call-redirect model, it is a redirect server which has the following features:

l User-to-user call involving redirection

This is only a simplified redirection-involved call flow.

If the mode of a received call is redirect, the SIP proxy server, after resolving the address, responds to the caller’s UA with a 3xx response containing the address information of the callee’s UA.

Based on the returned address information, the caller’s UA directly calls the callee’s UA. In this case, neither the SIP redirect server nor the SIP LS maintains any call state information or provides any service.

This approach is widely adopted in actual applications.

l Two transport protocols: TCP and UDP.

l Statistics query

The redirect server can provide statistics such as messages sent/received by the internal and external modules and errors generated.

Chapter 5 SIP Server Configuration

5.1 SIP Proxy Server Configuration

5.1.1 Introduction to SIP Proxy Server

A SIP proxy server can provides these functions:

1) As the media between calling and called parties, forwarding messages to a remote gateway or another SIP proxy server to complete and control calls

2) Exchanging messages with the LS to manage users

5.1.2 Basic SIP Proxy Server Configuration

The basic SIP proxy server configuration tasks are described in the following sections:

l Entering PS view

l Assigning a LS to a proxy server

l Configuring heartbeat password

l Configuring the identifier and interface of a PS

l Enabling/disabling a PS

l Enabling/disabling long-time call interruption function

l Configuring timeout interval for call interruption function

l Entering PS-SIP view

l Enabling/disabling the SIP Server

I. Entering PS view

Execute the following command in system view.

Table 5-1 Enter PS view

Operation	Command
Enter PS view	process-server

II. Assigning a LS to a proxy server

The LS assigned to a PS can be co-located with the PS or not. If they are not co-located, you must configure the IP address, port number and priority of the device where the LS is located.

Caution:

When configuring a remote LS, make sure that its IP address and port number are the same as the ones configured on the LS.

Perform the following configuration in PS view.

Table 5-2 Assign an LS to the PS

Operation	Command
Configure an LS table entry for the PS by specifying the local LS	ls-mode id-priority local
Configure an LS table entry for the PS by specifying the IP address of a remote LS	ls-mode id-priority remote ip-address ip-address
Configure an LS table entry for the PS by specifying the IP address and port number of a remote LS	ls-mode id-priority remote ip-address ip-address port port-number
Delete a specified entry or all entries from the LS table	undo ls-mode { id-priority \| all }

III. Configuring heartbeat password

Perform the following configuration in PS view.

Table 5-3 Configure a heartbeat password

Operation	Command
Configure a heartbeat password for the PS	heartbeat password password
Restore the default	undo heartbeat password

IV. Configuring the identifier and interface of a PS

A LS uses PS identifier to distinguish between PSs. When configuring an identifier for a PS, make sure that the same one is configured on the LS and the PS.

The interface specified using the ps-config command is a network interface on the device where the PS is located.

Perform the following configuration in PS view.

Table 5-4 Configure information on the PS

Operation	Command
Configure the identifier of the PS and specify its interface	ps-config identifier interface interface-type interface-identifier
Remove the basic configuration of the PS	undo ps-config

V. Enabling/disabling a PS

Enabling/disabling a PS with the start or stop command is a software reset operation. The operation will interrupt ongoing calls, disconnecting the PS from the LS and preventing it from receiving messages from gateways. Then the PS reconnects with the LS for receiving messages from gateways.

Perform the following configuration in PS view.

Table 5-5 Enable/disable the PS

Operation	Command
Enable the PS	start
Disable the PS	stop

& Note:

Disabling the PS will disable the gatekeeper and SIP Server.

VI. Enabling/disabling long-time call interruption function

Perform the following configuration in PS view.

Table 5-6 Enable/disable long-time call interruption

Operation	Command
Enable long-time call interruption	policy call-interrupt-by-long-time enable
Disable long-time call interruption	policy call-interrupt-by-long-time disable

VII. Configuring timeout interval for call interruption function

This command is used to configure the timeout interval for the call interruption function. If the timeout interval expires, the server will break the conversation.

Perform the following configuration in PS view.

Table 5-7 Configure the timeout interval for the call interruption

Operation	Command
Configure the timeout interval for the call interruption	policy call-interrupt-time call-interrupt-time
Restore the default timeout interval	undo policy call-interrupt-time

VIII. Entering PS-SIP view

Execute the following command in PS view.

Table 5-8 Enter PS-SIP view

Operation	Command
Enter PS-SIP view	sip

IX. Enabling/disabling the SIP Server

SIP Server is disabled by default. Before you can use SIP functions, you must enable the SIP Server.

Perform the following configuration in PS-SIP view.

Table 5-9 Enable/disable the SIP Server

Operation	Command
Enable the SIP Server	start
Disable the SIP Server	stop

5.1.3 Advanced SIP Proxy Server Configuration

I. Configuring the SIP signaling port of the SIP Proxy Server

SIP UAs and SIP proxy server uses SIP signaling to exchange messages. A SIP proxy server receives/transmits SIP signaling on its SIP signaling port.

Perform the following configuration in PS-SIP view.

Table 5-10 Configure the SIP signaling port of the SIP proxy server

Operation	Command
Configure the SIP signaling port of the SIP proxy server	ip-config port sip-port-number
Restore the default SIP signaling port of the SIP proxy server	undo sip-config

The default SIP signaling port of the SIP proxy server is 5060.

II. Configuring the wait-connect timer and the ringing-time timer

The wait-connect timer specifies the maximum duration that the calling party waits for the called party to pick up the phone. If no answer is received upon expiration of the timer, XE IP PBX disconnects the call.

The ringing-time timer specifies the maximum duration that the called party rings. If the called user does not pick up the phone upon expiration of the timer, XE IP PBX disconnects the call. This feature is available routed calls.

Perform the following configuration in PS view.

Table 5-11 Configure the wait-connect and ringing-time timers

Operation	Command
Configure the maximum duration that the calling party waits for the called party to pick up the phone	timeout caller wait-connect time
Restore the default maximum duration that the calling party waits for the called party to pick up the phone	undo timeout caller wait-connect
Configure the timeout interval for each called party	timeout callee ringing-time time
Restore the default timeout interval for each called party	undo timeout callee ringing-time

By default, the maximum duration that the calling party waits for the called party to pick up the phone is 90 seconds and the timeout interval for each called party is 40 seconds.

& Note:

The maximum duration configured through the timeout caller command does not take effect on a subscriber number bound with multiple phone sets.

III. Tracing calls

Call trace is used to print the debugging information on the caller and callee related to a number. The displayed debugging information spans levels 1 through 7. Before you can use this function, you must enable debugging.

Perform the following configuration in PS view.

Table 5-12 Trace calls related to a number

Operation	Command
Trace calls related to the specified number	tracecall number
Cancel call tracing	undo tracecall

& Note:

To start another call tracing, you must first use the undo tracecall command to cancel the call tracing related to the existing number.

Before using the tracecall command, turn on the debugging information output display switch with the terminal debugging command and the terminal monitor command.

IV. Automatically repairing TCP connection

Automatic TCP connection repair increases system robustness. It allows the system to automatically attempt to repair a TCP connection that is disconnected for some reasons.

Perform the following configuration in PS-SIP view.

Table 5-13 Automatically repair TCP connection

Operation	Command
Enable/disable automatic TCP connection repair	repair-tcp { enable \| disable }

By default, TCP connection repair is enabled.

5.2 LS Configuration

5.2.1 Introduction to LS

A LS stores device information (about SIP devices, H.323 devices and office devices) and numbers, and provides information when queried by the PS.

5.2.2 Configuring the LS

For LS configuration, refer to the chapter discussing LS configuration in the “LS Configuration Operation” part of this manual.

5.3 SIP Registrar Configuration

5.3.1 Introduction to SIP Registrar

A SIP registrar retains information on UA locations for SIP proxy servers to query. UAs, including SIP gateways, register with their SIP registrars at their power-on, reboot or configuration. In a simple application, a SIP registrar may be co-located with the SIP proxy server.

5.3.2 Configuring the SIP Registrar

SIP registrar is one of the LS functions provided by XE IP PBXs. For its configurations, refer to the section discussing how to configure a gateway registered with a LS in the “LS Configuration” part of this manual.

5.4 SIP Redirect Server Configuration

5.4.1 Introduction to SIP Redirect Server

The purpose of a SIP redirect server is to redirect a calling UAC to an alternate location for calling the called UAS.

When receiving a request from a calling UAC, the redirect server searches for the location information of the called UAS and returns information on a location. This location can be that of the called UAS or a proxy server, to which the UA can send the session request. The subsequent procedure is the same as that for calling a called UAS directly or calling a proxy server.

5.4.2 Configuring SIP Redirect Server

SIP redirect server is one of the LS functions provided by XE IP PBXs. For its configuration, refer to the sections discussing call mode configuration in the “Location Server Configuration” module of this manual.

Chapter 6 Displaying and Debugging the PS

6.1 Displaying Information for the PS

I. Displaying statistics for the PS

Execute the following command in any view.

Table 6-1 Display statistics for the PS

Operation	Command
Display statistics for the PS	reset process-server statistics { adapter \| all \| bkm \| cdp \| cm \| csm \| hadpt \| hrm \| hsm \| hstack \| rm \| sm \| stack \| tucl }

II. Clearing statistics for the PS

Execute the following command in user view.

Table 6-2 Clear statistics for the PS

Operation	Command
Clear statistics for the PS	reset process-server statistics { adapter \| all \| cdp \| cm \| hadpt \| hrm \| hsm \| hstack \| rm \| sm \| stack \| tucl }

III. Displaying information about calls being processed on the PS

Execute the following command in any view.

Table 6-3 Display information about calls being processed on the PS

Operation	Command
Display information about calls being processed on the PS	display process-server call-information

IV. Displaying status information of the LS managing the PS

Execute the following command in any view.

Table 6-4 Display status information about the LS managing the PS

Operation	Command
Display status information of the LS managing the PS	display process-server location-server status

6.2 Debugging the PS

I. Configuring the debugging level of the PS

Perform the following configuration in user view.

Table 6-5 Configure the debugging level of the PS

Operation	Command
Configure the debugging level of the PS	debugging process-server { adapter \| all \| bkm \| cdp \| cm \| csm \| hadpt \| hrm \| hsm \| hstack \| om \| rm \| sm \| stack \| tucl } level level

II. Displaying the debugging level of the PS

Execute the following command in any view.

Table 6-6 Display the debugging level of the PS

Operation	Command
Display the debugging level of the PS	display debugging process-server

TOP

H3C reserves the right to modify its collaterals without any prior notice. For the latest information of the collaterals, please consult H3C sales or call 400 hotline.