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


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


The Call-Waiting Service Fails Because of Incorrect MAXPARACALL Parameter in MOD SBR

Publication Date:  2012-08-06 Views:  216 Downloads:  0

Issue Description

[Version] ATS V100R003C00SPC100

[Problem Description]
It is a Call Waiting service test on a site .it involves there users, two of them are IMS subscribers (IMS_A\IMS_B), the third one is a PSTN subscriber (PSTN_C). IMS_A has the CW service right.
The test procedure is following this:
1) IMS_A makes call to IMS_B and the call is established successfully;
2) PSTN_C makes call to IMS_A;
3) PSTN_C didn’t hear the call-waiting tone, the CW service failed.

[Network Topology]

See the attachment: CW fails case.rar

Alarm Information


Handling Process

1. According to the message trace result, the IMS_A sends 180 to PSTN_C after it received the invite message. When the ATS receives the 180, it does not process it and pass it through to the PSTN_C side. We can see that the Call Waiting service is not triggered compare to the CW service flow.

2. Owing to the CW service not triggered, and analyzing the inter traces of ATS, it can be seen that the parameter of ucMAXMutiCallNum is 2. That means a single subscriber can support 2 concurrent calls. This will cause the CW service not triggered. The ucMAXMutiCallNum parameter can be seen by the following capture:

3. According to the incorrect parameter, MAXPARACALL can be re-configured on ATS by MOD SBR and set it to 1: Then the CW service will be triggered successfully。

Root Cause

If the CW service is not successful, it mainly involves these following reasons [1]:
1) The license function of the CW service is disabled;
2) No CW service authority is configured;
3) The CW service is not registered;
4) The service flow designated by the carrier is not configured.
5) A service conflict occurs.
For this case,it is that the MAXPARACALL parameter in MOD SBR on ATS is incorrect, so that the Call Waiting service is not trigged.


[Related information]
1. For the Call Waiting service in detail, can refer to the following path:
IMS GTS Product Information (GPI) Operation and Maintenance (V200R008C03- GPI_02)-Descriptions->Features description->Telecommunications services ->Telephony services->Call Waiting.
2. The Call Waiting service is different from Call Holding service for example; the Call Holding service just needs the subscriber to own the service right. But for the Call Waiting service, the subscriber needs to register the service besides the service right (REG COMSS).
3. For the service flow the UE_C returns 180 or 182, the terminal can be set to it and both of them are right for the CW service. If one needs to add the Call-Waiting indication in alert-info head in 180 or 182, there is a command that MOD CWCFG can make it. The parameter of "IND 180" in MOD CWCFG can specify whether to send a 180 message that contains a CW indication to the caller when the service is triggered.
[On-Site Operation Suggestion]
On the ATS of SPG web portal, configure the parameter of MAXPARACALL to 1 in MOD SBR.
[1] “Troubleshooting Procedure for the CW Service Failure”. IMS GTS Product Information (GPI) Operation and Maintenance (V200R008C03-GPI_02).Page 4697