PSTN Ringback for non-existing DN

[s.angelmahr]

Hi,

customer has a CUCM, version 8.5

Connected to PTSN via H323 gateway.

If you call a not existing DN via PSTN you just get a ringback instead of an error.

No internal phone rings (at least SOMETHING that works as expected ).

I guess it's something about the gateway, but not sure right now. Any ideas where to start?

Regards,

Sven

[Chris Deren]

What is the PSTN connection?  PRI, FXO, etc?

Chris

[s.angelmahr]

Its a PRI connection.

Sven

[Chris Deren]

Can you post "debug isdn q931" for one of these calls?

Chris

[s.angelmahr]

Sure, just did a test. After getting the ringback i just hang up. Looks very normal to me...

14379324: Sep 12 16:34:40.477 MEST: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x3A21

        Sending Complete

        Bearer Capability i = 0x9090A3

                Standard = CCITT

                Transfer Capability = 3.1kHz Audio

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA9838C

                Exclusive, Channel 12

        Progress Ind i = 0x8083 - Origination address is non-ISDN

        Calling Party Number i = 0x2180, '71179763732'

                Plan:ISDN, Type:National

        Calling Party Number i = 0x2183, '711797630'

                Plan:ISDN, Type:National

        Called Party Number i = 0xC1, '97074000'

                Plan:ISDN, Type:Subscriber(local)

14379325: Sep 12 16:34:40.481 MEST: ISDN Se0/0/0:15 Q931: Received SETUP  callref = 0xBA21 callID = 0x1E14 switch = primary-net5 interface = User

14379326: Sep 12 16:34:40.497 MEST: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0xBA21

        Channel ID i = 0xA9838C

                Exclusive, Channel 12

14379327: Sep 12 16:34:40.561 MEST: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xBA21

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

14379328: Sep 12 16:34:40.577 MEST: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8  callref = 0xBA21

        Progress Ind i = 0x8188 - In-band info or appropriate now available

14379333: Sep 12 16:34:50.973 MEST: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x3A21

        Cause i = 0x8090 - Normal call clearing

14379334: Sep 12 16:34:50.973 MEST: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8  callref = 0xBA21

14379335: Sep 12 16:34:50.989 MEST: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x3A21

[s.angelmahr]

I even see the call at CAR. Just looks like a normal call, besides "finalCalledPartyNumberPartition" is "null", and the "destIpAddr" is "0.0.0.0"

[Risat]

Do u remember how u resolved this issue, am facing the same issue

[Risat]

I fixed the issue using the command voice call send-alert :-)

[Chris Deren]

Interestingly I do not see expected "unallocated number" message, is there some kinf of wild card pattern in CUCM that matches these calls? Or old DN not assigned to a device?

Chris

[s.angelmahr]

Don't think there is some wildcard pattern matching, as DNA tells me "Block this pattern / unallocated number".

I can tell for sure that THIS test DN never existed in the whole cluster.

So thats why i have absolutly no idea even where to start searching...

[Ayodeji Okanlawon]

Out of curiosity, do you have dial-peers on the gateway  beginning with 9...I can see the called number = 0xC1, '97074000' starts with a 9. .Im just thinking out of the box here..

From the trace it look as if the call was routed out back to the PSTN and then disconnected from the PSTN. The disconnect is coming from outside rather than inside.

14379333: Sep 12 16:34:50.973 MEST: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x3A21

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[paolo bevilacqua]

From the trace it look as if the call was routed out back to the PSTN and then disconnected from the PSTN. The disconnect is coming from outside rather than inside.
14379333: Sep 12 16:34:50.973 MEST: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x3A21

That can be just because the OP doing the test call, heard the ringback to phantom destination, and hung-up.

If the call was looped back to PSTN, it would show in trace , and would have another effect.

[Ayodeji Okanlawon]

Totally correct Paolo. Infact the call couldnt have been re routed because there is no new setup information in the log..

S.angelmahr,

can you please provie the output of "debug voip ccapi inout" This will help us to see if any dial-peer is matched for this call

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[s.angelmahr]

Thanks for your input. Sorry, i should have given some more information:

- Number is totaly ok. As this is in germany the 9 is just the first number of the phone number. If i call 97074206 (thats our testphone in there) the phone rings.

- I can tell for sure a dial-peer matches. The number gets translated to the e164 pattern 4971197074000 and is sent to the CUCM. As mentioned i even can see the call in the CAR file on the CUCM.

We don't have fixed number length in germany. Some phone numbers are longer, some are shorter, but of course none are overlapping. So we've always have to keep our route pattern flexible.

Big question is why the CUCM answers with a ringback, instead of the unallocated number message. Ad told: DNA clearly tells me that this should get an unallocated number message.

Any other ideas?

[paolo bevilacqua]

I know that one can take CM traces, may be these would reveal something.