CFwdALL not working for QSIG on H323 gateway

[gohlex8848]

Hi All,

Hope i can seek a little helps here.

I have a router which act as a h323 gateway for CUCM and the gateway have two trunk, 1 is PRI to PSTN and the other one is QSIG

to BT System.

The issue now is when a BT Phone did a CFwdALL to external PSTN no or DN in CUCM, the PSTN call to BT Phone will not get forwarded.

the same goes for an IP Phone calling BT Phone. However, call from another BT Phone will have the call routed to forwarded number succesfully.

I've done a debug isdn q931, look like the h323 gateway doesn't process the Facility IE send by the BT system (which rerouting the call to

forwarded number), hence the call failed.

Anyway I can get the call forward/call divert work in this case? or h323 doesn't support call forward for QSIG? does this related to hairpinning?

do i need allow-connections h323-h323?

Note: call between CUCM, PSTN, BT system is working fine, except the call forward, I guess the dial-peer is setting up correctly.

Anyone is very much appreciated. Thanks

Alex

e.g 97777(IP Phone) is calling 96666(BT Phone), which is CFwdALL to 97778(IP Phone), call from PSTN is having the same

issue too.

13928743: .Dec 16 06:40:12.894 UTC: ISDN Se0/2/0:15 Q931: TX -> SETUP pd = 8  callref = 0x2265
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech 
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98382
                Exclusive, Channel 2
        Calling Party Number i = 0x0081
HOSTNAME#, '97777'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0x80, '96666'
                Plan:Unknown, Type:Unknown
13928744: .Dec 16 06:40:12.910 UTC: ISDN Se0/2/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0xA265
        Channel ID i = 0xA98382
                Exclusive, Channel 2
13928745: .Dec 16 06:40:13.002 UTC: ISDN Se0/2/0:15 Q931: RX <- FACILITY pd = 8  callref = 0xA265
        Facility i = 0x9FAA06800100820100A14002023E5502011330370A0101300CA50A0A010412053936313735020101400504038090A3A109A00780053936333138820102A40CA00A800539363137370A0103

Facility IE to Decode:
9FAA06800100820100A14002023E5502011330370A0101300CA50A0A010412053936313735020101400504038090A3A109A00780053936333138820102A40CA00A800539363137370A0103

<**************************** mt decode start ************************>

Facility Ie Data:
    Network Facility Extension: Len: 06
        sourceEntity: endPINX
        destinationEntity: endPINX

    RoseAPDU InvokePDU: Len: 40
        invokeId: 15957

        callRerouting:
            reroutingReason: cfu(1)
            calledAddress:
                partyNumber:
                    privatePartyNumber:
                        privateTypeOfNumber: localNumber(4)
                        privateNumberDigits: 12, Len: 05
                            "97778"

            diversionCounter: 1

            pSS1InfoElement: 40, Len: 05
                04 03 80 90 A3

            lastRetroutingNr:
                presentationAllowedAddress:
                    unknownPartyNumber: 80, Len: 05
                        "96666"

            SubscriptionOption: notificationWithDivertedToNr(2)

            callingNumber:
                presentationAllowedAddress:
                    unknownPartyNumber: 80, Len: 05
                        "97777"

                screeningIndicator: networkProvided(3)

<**************************** mt decode end **************************>

13928780: .Dec 16 06:40:37.424 UTC: ISDN Se0/2/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x2265
        Cause i = 0x8290 - Normal call clearing
13928781: .Dec 16 06:40:37.432 UTC: ISDN Se0/2/0:15 Q931: RX <- RELEASE pd = 8  callref = 0xA265
        Cause i = 0x8290 - Normal call clearing
13928782: .Dec 16 06:40:37.432 UTC: ISDN Se0/2/0:15 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x2265

[gohlex8848]

Any luck that someone can help?

[mhafbnet]

any recent upgrades, how many servers involved?

[gohlex8848]

Hi mhafbnet,

Not sure why is this related, but to answer you, there isn't any recent upgrade on cucm or server.

the issue surface when BT user trying to do call forward/divert.

Alex

[gohlex8848]

Any kind soul out there can help on this？

[Abu Hadee]

Hi Alex,

When call is made from IP Phone or PSTN, PBX sends the facility msg with diversion info. CUCM/GW should decode it and redirect call accordingly.If decoding is failed, it will not be able to send call to forwarded destination

But when you make call from BT phone, in that case, is made to diverted number. So, even if CUCM/GW fails to decode the facility, call will go to destination, may not have the orignally called number.

I am assuming that CUCM/GW is having issue decoding the facility msg. Can you collect the following

debug isdn q931

debug voip ccapi inout

debug cch323 all

If you can attach the GW config, that will be great.

Thank you

- abu

[gohlex8848]

Hi Abu,

I've added a command "qsig-decode" and apparently that it solved the forwarding issue. However, new issue surface : )

Now when the IP Phone called a BT Phone which forwarded to another IP Phone,

The calling party will not hear any ring back.

I've tried the tone ringback & progress_ind alert command but no avail.

I'm thinking that since the inbound and outbound call on the GW to BT system is on the same VOIP dial-peer (hairpin), should I add the command "delay transport-address" to generate the ringback?

Would you able to comment on this?

Thanks

Regards,

Alex

[James Hawkins]

Alex,

I am having a similar issue linking from CUCM 8.0 to an Avaya system using a QSIG link on a H.323 gateway.

I do not think that the facility message is being processed by the Cisco gateway as I am not getting name or number information displayed on Cisco phones when called from an Avaya phone. Also when I call from a Cisco phone to an Avaya phone and the call is unanswered an forwarded to voicemail the call fails because I guess the rerouting information from the Avaya is not decoded properly.

If you did manage to resolve this would it please be possible to see a copy of your gateway configuration?

thanks

James

[acampbell]

James,

This seems like an issue with QSIG path replacement.

Look on the interoperability  portal and find a set up similar to yours

You may need to look under older version of CUCM for QSIG over E1/T1 etc

http://www.cisco.com/en/US/netsol/ns728/networking_solutions_program_category_home.html

When you find a similar set up look for the CUCM set up

for PINX, The pickup group required and the service parameters for

path replacement

HTH

Alex