No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Voice Feature Guide 01

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
SIP Services and Basic Service Flows

SIP Services and Basic Service Flows

This chapter describes the subscriber registration and authentication flow, subscription flow, and basic call flow.

User Registration and Authentication Flows

Before initiating a call, a SIP user must register with the home network to map the domain name to an IP address. The registration is of two types: the registration not requiring authentication and the registration requiring authentication. After the system is powered on or after the user is added, the user registration flow is started.

Registration Not Requiring Authentication

As shown in Figure 1-25, the SIP AG sends the REGISTER request message to the IMS for each user. The message contains information such as the user ID. After receiving the REGISTER request message, the IMS checks whether the user is already configured on the IMS. If the user is already configured, the IMS responds to the SIP AG with the RESPONSE 200 message.

Figure 1-25 Flowchart of the registration not requiring authentication

Registration Requiring Authentication

As shown in Figure 1-26, the SIP AG sends the REGISTER request message to the IMS for each user. The message contains information such as the user ID.

The IMS responds with the RESPONSE 401/407 message, the message containing information such as the key and the encryption mode. The SIP AG encrypts the corresponding user name and password, generates a new REGISTER request message, and sends the message to the IMS. The IMS decrypts the message and verifies the user name and password. If the user name and password are correct, the IMS responds to the SIP AG with the RESPONSE 200 message.

Figure 1-26 Flowchart of the registration requiring authentication

Registration Modes
Table 1-12 shows the registration modes supported by SIP AGs.
Table 1-12 Registration modes supported by SIP AGs

Registration Mode

Description

Separate account registration

A non-wildcard number is used for registration. Each account is registered separately.

Wildcard number registration

A wildcard number, such as 2878*, is used for registration. After the registration, all numbers with prefix "2878" are successfully registered on the IMS.

Proxy group registration

A batch of accounts are added to a group. Then, an account in the group or a separate group account is used for registration. After the registration, all accounts in the group are successfully registered on the IMS.

NOTE:
If a large number of accounts concurrently register with the IMS in separate account registration, mass registration messages degrade IMS performance. The wildcard registration and proxy group registration reduce the number of registration messages to be exchanged between AGs and the IMS.
Deregistration

When a SIP AG attempts to deregister from the IMS, the AG sends a REGISTER request with timeout duration set to 0s to the IMS. The deregistration request can also be initiated by the IMS.

Deregistration Initiated from the AG

Figure 1-27 Deregistration initiated from the AG

As shown in Figure 1-27, the SIP AG initiates deregistration by sending a new REGISTER request with Expires set to 0 to the IMS.

Deregistration Initiated from the IMS

Figure 1-28 Deregistration initiated from the IMS

As shown in Figure 1-28, when the IMS requires to clear the registration of a SIP AG, the IMS sends a NOTIFY message carrying the deregistration reason to the AG if the IMS has subscribed to the registration status of this AG. After receiving the NOTIFY message, the SIP AG responds to the IMS with a 200 OK message.

Subscription

Subscription indicates that a SIP access gateway (AG) requests the current status, information change, and service permission of a subscription user from the network side. The SIP AG supports the following subscriptions:
  • Registration status subscription
  • User agent (UA) profile subscription
  • Message waiting indication (MWI) subscription
As shown in Figure 1-29, after a user is successfully registered, registration status subscription and SIP UA profile subscription start. If the user has the MWI permission in the UA profile subscription, an MWI subscription starts.
Figure 1-29 Subscription flow
Registration Status Subscription
Registration status subscription is mainly used to obtain the user's registration status and registration status change. Figure 1-30 shows the flow of a registration status subscription:
  1. The SIP AG uses the Subscribe message to initiate a registration status subscription and uses the Event header to identify the subscription type.
  2. The IMS uses the Notify message to issue the user's registration status to the SIP AG.
Figure 1-30 Flow of a registration status subscription
UA Profile Subscription
UA profile subscription is used to obtain the user's service permission and dial tone scheme. For details about service permissions supported by a SIP user, see SIP Value-added Services. Figure 1-31 shows the flow of a UA profile subscription.
  1. The SIP AG uses the Subscribe message to initiate a registration status subscription and uses the Event header to identify the subscription type.
  2. The IMS uses the Notify message to issue the user's registration status to the SIP AG.
NOTE:
Users' service permissions can be subscribed to the IMS and can be configured at local through the SIP AG. If the SIP AG is not subscribed to the IMS, service permissions configured on the SIP AG take effect.
Figure 1-31 Flow of a UA profile subscription
MWI Subscription
MWI subscription is used to obtain the user's messages. Figure 1-32 shows the flow of an MWI subscription.
  1. The SIP AG uses the Subscribe message to initiate a registration status subscription and uses the Event header to identify the subscription type.
  2. The IMS uses the Notify message to issue the user's registration status to the SIP AG.
Figure 1-32 Flow of an MWI subscription

SIP-based VoIP

Figure 1-33 shows the networking for SIP-based voice over IP (VoIP) calls.

Figure 1-33 Networking for SIP-based VoIP calls

Figure 1-34 shows the SIP-based VoIP call flow. USER1 is the calling party, and USER2 is the called party.
Figure 1-34 SIP-based VoIP call flow

Call flow on the calling side

  • P1: AG1 receives the offhook message of USER1 and plays the dial tone to USER1.
  • P2: AG1 receives the first dialed digit, stops playing the dial tone, and then starts matching the digit with the digitmaps.
  • P3: After receiving N dialed digits and matching the digits with the digitmaps, AG1 finds that the dialed number matches a certain digitmap. Then, AG1 generates the INVITE message and sends the message to the IMS.
  • P4: AG1 receives RESPONSE 100 and knows that the peer end receives the INVITE message, so AG1 stops the INVITE message retransmitting flow.
  • P5: AG1 receives 180, which indicates that the phone of USER2 is ringing. Then, AG1 plays the ring back tone to USER1.
  • P6: AG1 receives 200, which indicates that USER2 answers the phone, so AG1 stops playing the ring back tone to USER1, and changes the stream mode to the bidirectional mode. Then, AG1 constructs an ACK message and sends the message to the IMS.
In the actual processing, when USER1 initiates a call, the IMS determines the situation as follows:
  • If USER1 has been configured but not registered with the IMS, the IMS rejects USER1 and responds with 403 to AG1.
  • If USER1 is not configured, the IMS rejects USER1 and responds with 404 to AG1.

Call flow on the called side

  • Q1: After receiving the INVITE message from the IMS, AG2 replies with a 100 response to the IMS, finds USER2 based on the P-Called-Party-ID, RequestURI, and TO fields (or TEL-URI) contained in the INVITE message, plays the ring tone to USER2, and sends 180 to the IMS, indicating that USER2 is being alerted.
  • Q2: After detecting that USER2 picks up the phone, AG2 stops playing the ring tone and sends 200 to the IMS, indicating that USER2 has picked up the phone.
  • Q3: After AG2 receives an ACK message, calling and called parties start a session.
In the actual processing, when USER1 initiates a call, AG2 determines the situation as follows:
  • If USER2 has been configured but is not registered with the IMS, AG2 replies with 403 to reject the call.
  • If USER2 is not configured, AG2 replies with 404 to reject the call.

Call release flow

  • D1: After detecting that USER1 hangs up, AG1 sends a BYE message to the IMS and releases DSP resources.
  • D2: After receiving the BYE message, AG2 notifies USER2 of the on-hook event. USER2 hangs up, and the call ends.

SIP-Based FoIP

In terms of transmission protocol, the fax service can be classified into transparent transmission and T.38; in terms of switching mode, the fax service can be classified into auto-switching and negotiated-switching. Hence, there are four combinations of the fax mode: auto-switching transparent transmission, auto-switching T.38, negotiated-switching transparent transmission, and negotiated-switching T.38.

The working principle of auto-switching is that the AG detects the fax tone, and then selects the transparent transmission or T.38 mode according to the configuration. In this case, the AG needs not send any signaling to the peer device.

The working principle of negotiated-switching is that the AG detects the fax tone, and according to the configuration sends the peer end the re-INVITE message that contains the negotiation parameters for negotiating the fax mode.

In actual application, fax can also be classified into low-speed fax and high-speed fax in terms of transmission speed. The high-speed fax cannot adopt the T.38 mode. A high-speed fax machine can actually be regarded as a modem. With the speed reduced, a high-speed fax machine can also adopt the T.38 mode.

Flow of the Negotiated-Switching Transparent Transmission Fax

Currently, this fax mode can be presented in three ways.

  • Presented as a=fax. This is a G.711 transparent transmission fax mode proposed by China Telecom.
  • Presented as a=silenceSupp:off. This is a G.711 transparent transmission fax mode defined in the draft-IETF-sipping-realtimefax-01.txt.
  • Presented as a=gpmd:99 vbd=yes. This is a VBD mode defined in the ITU-T V.152.

Which method to be applied depends on the parameters configured.

Figure 1-35 shows the fax flow.

Figure 1-35 Flow of the negotiated-switching transparent transmission fax

  • P1: AG-T first detects the fax tone, and then sends the re-INVITE message to the AG (AG-O) to which the calling party is connected.
  • L1: The SDP message contained in the re-INVITE message has three types. The specific fax mode must be configured on the AGs. The initiator of negotiation uses the a parameter of different values, and the recipient of negotiation needs to be compatible with the three parameter values. This means that when the recipient receives the re-INVITE message, the recipient should be able to complete the negotiation process with the initiator regardless of the a parameter value.
    • The G.711 transparent transmission fax/modem mode defined in the draft-IETF-sipping-realtimefax-01.txt.
    • The G.711 transparent transmission fax/modem mode proposed by China Telecom.
    • The VBD mode defined in the ITU-T V.152.
  • P2: AG-O receives the re-INVITE message. Then, AG-O generates the 200 OK message and sends the message to AG-T.
  • P3: AG-T receives the 200 OK message, and also enables the DSP channel in the fax mode.
  • P4: AG-T receives the fax end signal, and sends the re-INVITE message to AG-O.
  • L2: The SDP message contained in the re-INVITE message is for setting up a common voice channel.
  • P5: AG-O receives the re-INVITE message and switches the DSP channel to the voice mode.
  • P6: AG-T receives the 200 OK message, and also switches the DSP channel to the voice mode.
Flow of the Negotiated-Switching T.38 Fax

Figure 1-36 shows the flow of the negotiated-switching T.38 fax.

Figure 1-36 Flow of the negotiated-switching T.38 fax

  • P1: AG-T first detects the fax tone, and then sends the re-INVITE message to the AG (AG-O) to which the calling party is connected.
  • L1: The SDP message contained in the re-INVITE message carries the T.38 information.
  • P2: AG-O receives the re-INVITE message, learns that the peer device requires the T.38 mode, and enables the DSP channel in the T.38 mode. Then, AG-O generates the 200 message and sends the message to AG-T.
  • P3: AG-T receives the 200 OK message, and also enables the DSP channel in the T.38 mode.
  • P4: AG-T receives the fax end signal, and sends the re-INVITE message to AG-O.
  • L2: The SDP message contained in the re-INVITE message is for setting up a common voice channel.
  • P5: AG-O receives the re-INVITE message and switches the DSP channel to the voice mode.
  • P6: AG-T receives the 200 OK message, and also switches the DSP channel to the voice mode.
NOTE:

Figure 1-37 and Figure 1-38 shows the fax flows when the peer device does not support the T.38 mode.

Figure 1-37 Flow of the negotiated-switching T.38 fax when the peer device does not support the T.38 mode (scenario 1)

Figure 1-38 Flow of the negotiated-switching T.38 fax when the peer device does not support the T.38 mode (scenario 2)

In scenario 1, if AG-O does not support T.38, it may respond with 415 Unsupported Media Type. After AG-T receives the 415 response, AG-T sends the BYE message and releases the current call. In scenario 2, if AG-O does not support T.38, it responds with 488 Not Acceptable Here or 606 Not Acceptable. After AG-T receives the 488/606 response, AG-T generates another re-INVITE message. The SDP message in this message contains the VBD media type. Thus, the negotiation on the T.38 mode fails, and the transparent transmission mode is adopted.

The access device supports the T.38 mode, and therefore does not respond with the 415/488/606 message in the T.38 negotiation. The access device, however, can process such error codes sent by the peer device.

Flow of the Auto-Switching Transparent Transmission Fax

Generally, the called fax terminal detects the fax tone on the TDM side first, and the calling fax terminal detects the fax tone sent from the IP side. The fax terminal that detects the fax tone automatically switches to the transparent transmission mode without the SIP negotiation.

One problem currently exists in the auto-switching fax flow: If the DSP channel originally works in the G.729 mode for the voice service, and is now switched to the G.711 transparent transmission mode when the fax tone is detected, the G.711 voice packet may not be recognized. This is because the DSP channel of the calling party stills works in the G.729 mode. Therefore, the DSP chip is required to be able to receive G.711 packets when working in the G.729 or other coding modes. The prerequisite remains that the DSP chip should detect and report the fax tone sent from the IP side.

Flow of the Auto-Switching T.38 Fax

The working principle of this fax flow is the same as the working principle of the auto-switching transparent transmission fax. The difference is that, after the fax tone is detected, the DSP channel is enabled in the T.38 mode instead of the transparent transmission mode.

SIP-Based MoIP

In terms of service flow, the modem service is similar to the transparent transmission fax service, and can also be classified as auto-switching and negotiated-switching.

The modem service in the negotiated-switching transparent transmission mode can be presented in three ways.

  • Presented as a=modem. This is a G.711 transparent transmission modem mode proposed by China Telecom.
  • Presented as a=silenceSupp:off. This is a G.711 transparent transmission modem mode defined in the draft-IETF-sipping-realtimefax-01.txt.
  • Presented as a=gpmd:99 vbd=yes. This is a VBD mode defined in the ITU-T V.152.

The method actually applied depends on the parameters configured.

Flow of the Negotiated-Switching Modem Service

Figure 1-39 shows the flow of the negotiated-switching modem service.

Figure 1-39 Flow of the negotiated-switching modem service

  • P1: AG-T first detects the modem tone, and then sends the re-INVITE message to the AG (AG-O) to which the calling party is connected.
  • L1: The SDP message contained in the re-INVITE message has three types, corresponding to the three preceding presentations of the negotiated-switching transparent transmission mode. The specific transparent transmission modem mode must be configured on the AGs.
  • P2: AG-O receives the re-INVITE message. Then, AG-O generates the 200 message and sends the message to AG-T.
  • P3: AG-T receives the 200 OK message, and also enables the DSP channel in the fax or modem mode.
Auto-Switching Modem Mode

In this mode, after the AG detects the modem tone, the AG automatically switches the DSP channel to the VBD mode without notifying the IMS or the peer device.

Generally, the called modem detects the modem tone on the TDM side first, and the calling modem detects the modem tone sent from the IP side. The modem that detects the modem tone automatically switches to the VBD mode without the SIP negotiation.

SIP Trunking

This section describes the SIP trunking feature and its typical usage scenarios.

Background
The traditional private branch exchanges (PBXs) of government, enterprise, and business users connect to carrier networks using PSTN trunk lines (E1 lines). The All-IP network upgrade and reconstruction urgently demands an IP trunk technology to replace the traditional PSTN trunk technology. Then SIP trunking technology can meet such requirements, connecting government, enterprise, and business PBXs to carrier networks for voice and multimedia services. Figure 1-40 shows the network reconstruction for SIP trunking.
Figure 1-40 Network reconstruction for SIP trunking
Basic Concepts
  • Trunk: a physical communication line connecting two switching systems for carrying media stream signals, such as voice, data, and video signals.
  • The SIP trunking technology uses SIP to connect government, enterprise, and business PBXs to carrier networks over an IP network.
  • SIP trunking allows a PBX to register with the IMS in one of the following modes:
    • Separate number registration: In this mode, the PBX uses a separate number but not a wildcard number to register with the IMS.
    • Wildcard number registration: When the PBX successfully registers with the IMS using a wildcard number, such as 2878*, all numbers with prefix "2878" are successfully registered on the IMS.
    • Agent group registration: In this mode, multiple numbers are added to one group and the PBX uses one of the numbers in this group or a separate group number to register with the IMS. If the registration is successful, all numbers in this group are successfully registered on the IMS. This registration mode reduces registration message exchanging between the IMS and the AG connected to this PBX.
    • No registration: In this mode, the PBX supports call originating without registration. This mode is used if the access network is reliable.
  • SIP trunking supports call originating in one of the following modes:
    • Direct dialing in (DDI) calling: In this mode, the PBX requires multiple extension numbers and uses a separate number to register with the IMS; or the PBX uses a wildcard number to register with the IMS. The extension phones connected to the PBX can call each other using either long or short numbers. External users can call an extension phone by dialing its long number. User experience in DDI calling mode is the same as that in POTS access mode.
    • Global dialing number (GDN) calling: In this mode, the PBX requires only a switchboard number, also called "pilot number". The extension phones connected to the PBX call each other using short numbers. When an external user wants to call an extension phone, the user must dial the switchboard number up and the switchboard transfers to the call to the extension phone. In GDN calling mode, the number displayed for the external user is not the number of the extension phone where the call is initiated but the number of the switchboard number. The external user cannot call this extension phone in callback mode.
    • Line hunting: In this mode, multiple E1 lines connected to the PBX are added to one hunting group and one number is configured for this group. One hunting group can have one or multiple group numbers. When the PBX registers with the IMS, the AG adds these group numbers to one agent group for registration. For details about line hunting call process, see Line hunting.
    • Call routing identified by tgrp and trunk-context: This mode is used if call routing and charging cannot be implemented using only phone numbers. tgrp and trunk-context are defined in RFC 4904. They are only used in the Request URI and Contact URI, functioning as useinfo in the SIP URI or par in the TEL URI. The two parameters must be used in couple. Otherwise, AG considers that the URI does not carry this group of parameters. Huawei AG devices use these two parameters in hunting groups for call routing and charging.
Typical Usage Scenarios
Scenario 1: DDI calling

Usage scenario: As shown in Figure 1-41, the enterprise user uses one PBX to connect to 30 extension phones and the PBX connects to the AG using one PRA port. The 30 extension phones use different phone numbers, 28780001 through 28780030.

Configuration: Wildcard number 2878* is configured for the PRA port and the PBX uses this wildcard number to register with the IMS.
NOTE:
If the IMS does not support the registration using a wildcard number, configure 1 primary number and 29 extension numbers for the PBX. All the 30 numbers require a separate number registration.
Call description:
  • When user A dials number 28780001 up, phone 1 is called without requiring call transferring from the switchboard.
  • When phone 1 calls user A, the number displayed for user A is 28780001, the number of phone 1.
  • Phone 1 can call phone 30 using either long number 28780030 or short number 0030 of phone 30.
Figure 1-41 DDI calling
Scenario 2: GDN calling

Usage scenario: As shown in Figure 1-42, the enterprise user uses one PBX to connect to 30 extension phones and the PBX connects to the AG using one PRA port. The external number of the 30 extension phones is 28780020.

Configuration: Number 28780020 is configured for the PRA port and the PBX uses this number to register with the IMS in separate number registration mode.

Call description:
  • When user A calls number 28780020, the AG routes the call to the PBX. Then, the PBX uses the interactive voice response (IVR) function to automatically transfer the call to the desired extension phone, or uses the switchboard to manually transfer the call to the desired extension phone.
  • When an extension phone calls user A, the number displayed for user A is 28780020.
  • Phone 1 can call phone 30 only using short number 0030 of phone 30.
Figure 1-42 GDN calling
Scenario 3: line hunting calling

Usage scenario: As shown in Figure 1-43, the enterprise user uses one PBX to connect to 60 extension phones and the PBX connects to the AG using two PRA ports: PRA 1 and PRA 2. The external number of the 60 extension phones is 28780020.

Configuration: PRA 1 and PRA 2 are added to hunting group HG, number 28780020 is configured for this hunting group, and the PBX uses this number to register with the IMS.

Call description:
  • When user A calls 28780020, the AG routes the call to hunting group HG and this group selects an idle PRA port based on hunting policies for call incoming. Then, the PBX uses the IVR function to automatically transfer the call to the desired extension phone, or uses the switchboard to manually transfer the call to the desired extension phone.
  • When phone 1 calls user A, the PBX selects an idle PRA port for call outgoing. The number displayed for user A is 28780020.
  • Phones 1 through 60 can call each other using only short numbers.
Figure 1-43 Line hunting calling
Scenario 4: PBX dual-homing calling (call routing identified by tgrp and trunk-context)
  • Usage scenario: As shown in Figure 1-44, the enterprise user uses one PBX to connect to 80 extension phones. The external number of the 80 extension phones is 28780020. Because of high reliability requirements, the PBX uses two PRA ports to connect to two AGs, respectively, for redundancy backup on the access side; both AGs connect to I-BCF 1 and I-BCF 2, respectively, for dual homing on the core network side. This networking improves call reliability. However, the two AGs use the same number. Therefore, calls cannot be routed based on only the phone number. To resolve this issue, tgrp and trunk-context are added for differentiating between hunting groups for different AGs.
  • Configuration:
    • For AG 1:
      • PRA 1 and PRA 2 on AG 1 are added to hunting group HG1.
      • Number 28780020 is configured for this hunting group.
      • The values of tgrp and trunk-context are TG-1 and ims1@huawei.com, respectively.
    • For AG 2:
      • PRA 3 and PRA 4 on AG 2 are added to hunting group HG2.
      • Number 28780020 is configured for this hunting group.
      • The values of tgrp and trunk-context are TG-2 and ims2@huawei.com, respectively.
  • Call description:
    • When an external user calls number 28780020, the IMS routes the call to the desired AG based on the phone number, tgrp, and trunk-context. The AG selects an idle PRA port based on hunting policies for call incoming. Then, the PBX uses the IVR function to automatically transfer the call to the desired extension phone, or uses the switchboard to manually transfer the call to the desired extension phone.
    • When an extension phone calls an external user, the PBX selects an idle PRA port for call outgoing. The phone number of the calling party is mapped to contact header field URI and carries the tgrp and trunk-context parameters for the hunting group. Then, the IMS charges the call based on the tgrp and trunk-context parameters.
Figure 1-44 PBX dual-homing calling
Standards and Protocols Compliance
  • RFC 4904: representing trunk groups in tel/sip uniform resource identifiers (URIs)
  • RFC 3261: Session Initiation Protocol
  • RFC 3966: tel URI for phone numbers
  • ETSI TS 182 025: Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); business trunking; architecture and functional description

Line Hunting

Line hunting is a feature that allows a group of ports to share a group of called party numbers by specifying a hunting group and hunting policy. Only the Session Initiation Protocol (SIP) supports this feature.

Basic Concepts
Figure 1-45 shows a hunting group. The following provides the basic concepts about line hunting.
  • Hunting group: a group composed of multiple members that share a group of called party numbers, for example, the HG shown in Figure 1-45
  • Group member: a port in a hunting group. A group member can be a POTS port, a BRA port, a PRA port or a child hunting group. A child hunting group is a sub group of a parent hunting group. A child hunting group has the same structure as its parent hunting group. After a child hunting group is added into a parent hunting group, all the members of the child hunting group become the members of the parent hunting group.
  • Group number: a called party number shared by members of a hunting group. A group number can be a group numbering reduced (GNR) or a direct dial number (DDN). When the access gateway receives an incoming call and if the incoming call number is a group number of a hunting group, the AG hunts for a group member according to the hunting policy. A hunting group has one or more group numbers, but a group number belongs to only one hunting group.
    • GNR: a prefix of a wildcard number. For example, if the wildcard number is 024545*, the GNR is 024545. For simplicity, "024545*" is called a GNR. If the group number of a hunting group is a GNR, the AG determines that an incoming call number is the group number of the hunting group as long as the first several digits of the incoming call number are identical to the prefix of the GNR.
    • DDN: a specific number instead of a wildcard number
  • Hunting policy: a policy used to select a member of a hunting group as the called party for an incoming call. Hunting policies include sequential hunting, circular hunting, and circular hunting by weight. For details, see Hunting Policies.
  • Alternative line hunting: defines the call release mode for an ISDN port in a hunting group. Only ISDN ports support alternative line hunting. For details, see Alternative Line Hunting.
Figure 1-45 Hunting group
Hunting Policies
Available hunting policies include sequential hunting, circular hunting, and circular hunting by weight.

Item

Sequential Hunting

Circular Hunting

Circular Hunting by Weight

order

The order value determines the priority of a member port. When the AG receives an incoming call, the member port with the order value 1 takes precedence. If the member port with the order value 1 is busy or faulty, the member port with the order value 2 is selected. If the member port with the order value 1 is busy or faulty, the member port with the order value 2 is selected, and so on.

The order value determines the neighbor relationship between member ports. For example, the ports with the order values 1 and 2 are considered as neighbor ports. The neighbor port next to the previously selected port is the first choice when the AG is hunting for a group member. Specifically, when the AG receives the first incoming call, the member port with the order value 1 takes precedence. If the port is busy or faulty, the member port with the order value 2 is selected. If the member port with the order value 2 is successfully selected as the called party, the member port with the order value 3 is selected when the AG receives the second incoming call.

The meaning is the same as the order in circular hunting.

weight

The weight value determines the number of times that a member port is selected as the called party. When the weight value of each member port in a hunting group is the same, the circular hunting by weight functions the same as the circular hunting.

In circular hunting by weight, the weight value decreases by 1 each time after a member port is successfully selected as the called party. If there are still member ports whose weight values is not 0 after all member ports in a hunting group are selected once as the called parties, the AG preferentially selects the member ports with non-0 weight values as the called parties according to the circular hunting policy.

NOTE:
Members of a hunting group can have the same order value.
  • When a child group and a port have the same order value, the port takes precedence.
  • When two or more ports have the same order value, the ports are selected according their subrack IDs/slot IDs/ port IDs. Specifically, the port in the subrack with the smallest ID takes precedence. If these ports are in the same subrack, the port on the board with the smallest slot ID takes precedence. If these ports are on the same board, the port with the smallest ID takes precedence.
  • When two or more sub groups have the same order value, they are selected according to the numerical and alphabetical sequences of their names.
Alternative Line Hunting

Assume that the AG selects an ISDN port as the called party for an incoming call and issues a call request. If the AG receives a call failure message before receiving any response and the Q.850 cause code carried in the call failure message (specifically, Release message) cannot be found in the Q.850 cause code table configured for the hunting group, the AG does not release the call but continues to hunt for another available group member and issues the call request. On the contrary, if the Q.850 cause code is found in the Q.850 cause code table, or if the AG receives a response before receiving any call failure message, the AG releases the call. This procedure is called alternative line hunting. For the definition of the Q.850 cause code, see ITU-T Q.850.

Assume that:
  • The POTS port, BRA port, and PRA port (as shown in Figure 1-46) are members of the same hunting group.
  • The hunting policy of the hunting group is sequential hunting. The order value of the PRA port is set to 1. The order value of the BRA port is set to 2. The order value of the POTS port is set to 3.
  • The POTS port, BRA port, and PRA port are in the idle state.
  • The Q.850 cause code carried in the Release message cannot be found in the Q.850 cause code table configured for the hunting group.
Figure 1-46 Alternative line hunting
The called party number of an incoming call is a group number. When receiving an Invite message sent by the IP multimedia subsystem (IMS), the AG hunts for a member among multiple group members. The alternative line hunting procedure is as follows:
  1. The AG issues a Setup message to the PRA port.
  2. The PBX directly replies to the AG with a Release message. The AG cannot find the Q.850 cause code (carried in the Release message) in the Q.850 cause code table configured for the hunting group, and then continues to hunt for a member.
  3. The AG issues a Setup message to the BRA port.
  4. The BRA replies to the AG with a Release message. The AG cannot find the Q.850 cause code (carried in the Release message) in the Q.850 cause code table configured for the hunting group, and then continues to hunt for a member.
  5. The AG issues ringing signals to the POTS port, and replies to the IMS with a 180 Ringing signaling message. Then the POTS port is selected as the called party.
Translation
Download
Updated: 2019-02-22

Document ID: EDOC1100067358

Views: 13226

Downloads: 129

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next