Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

CUCM v8.6.2 Call Forward Issue with HiPath 4000 v4

I have a CUCM cluster integrated to five Siemens HiPath 4000 v4.1 PBX's using QSiG under this configuration

PRI Protocol Type:                   PRI ISO QSIG E1

QSIG Variant:                          ISO

ASN.1 ROSE OID Encoding:     Use Local Value

Protocol Side:                          User

Channel Selection Order:          Top Down

Channel IE Type:                      Continuous Number

Framing:                                  Non-CRC4

Calls from CUCM SCCP (7962) phone direct to Siemens extension work as expected.

If the IP Phone calls Siemens extension (85112) which is on call forward universal to say Voicemail or an external mobile the call will fail.

The calling DN is 603355469700. The dial plan allows the IP Phone to dial 485112, this is uplifted to 603355485112. There is a Route Pattern

6033554.8[56]XXX (strip predot) to the HiPath. Also at the HiPath E1 gateway on CUCM there is a Calling Party Transform Pattern 6033554.XXXXX so calling party sent to HiPath is 69700 (to provide direct redial from HiPath back to CUCM).

A Q931 trace for a failed call is attached. Also attached is HiPath trace for call failure on CUCM 8.6.2 and also HiPath trace for call success on CUCM v6.1.2 (we are migrating from 6.1.2 to 8.6.2 which is why their are two integrations).

In the HiPath working trace the invoked facility is:

Facility  INV: divertingLegInformation1

In the HiPath fail trace the invoked facility is:

Facility  INV: callRerouteing

In the fail trace the callRerouteing number is 19 (to HiPath voicemail system). This then makes the unknownPartyNumber 603355419. This seems to be the 6033554.8[56]XXX Route Pattern (before the .) + the callRerouteing number.

Operation: callRerouteing (19)

                Service: QSIG-CF (13873) - Call-Diversion-Operations


                    rerouteingReason: cfu (1)


                        partyNumber: unknownPartyNumber (0)

                            unknownPartyNumber: 603355419

                            unknownPartyNumber: 603355419

I cannot work out how to get the CUCM v8.6 to invoke the same divertingLegInformation1 as the CUCM v6.1.2. I think on CUCM v6.1.2 the HiPath is doing the call divert but on CUCM v8.6.2 the QSiG message tells CUCM to do the divert but it does not have those digits in its dial plan to complete the call. I have proved this by configuring a route pattern 6033554.19 to the same HiPath and the call can then complete. This workaround isn't ideal and also would not cater for diverts to a mobile number.

I have compared the Service Parameters of the two clusters 'Feature - Path Replacement' and 'Feature - Forward' and there are some slight differences. Can someone tell me which of the service parameters would have an influence on the above whether the HiPath does the divert or whether CUCM does it? The CUCM v8.6.2 doesn't have a PINX ID configured at the moment, I did try doing that but it didn't seem to make a difference although if that should be in place for this to work I'm happy to try again (for reference the CUCM v6.1.2 doesn't have a PINX ID either).

Thanks in advance for your help

New Member



I have same problem with  following call flow.

QSIG - Cisco GW -- sip - CUCM 9.1 -- CUBE- ISP

I could not see history-info on my cisco voice gateway.

 How can I solve this issue

PRI Protocol Type:  isdn switch-type primary-net5         


CreatePlease to create content