IOS Toll Fraud Prevention

I was recently configuring a VG202 (yeah that little cutie) for a customer and when making inbound test calls they were failing:-

I checked the configuration and there was no reason for the call to fail, did a debug voip ccapi inout and saw the following error:-

>>>>CCAPI handed cid 19 with tag 2000 to app “_ManagedAppProcess_TOLLFRAUD_AP
*Mar  9 02:41:02.915: //19/0050FCDF0800/CCAPI/ccCallDisconnect:
Cause Value=21, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect C
ause=0)

Hmm.. i thought this was only applicable to IOS 15.X and above but seems like i was wrong, looks like this 12.4(20r)YA1 has Toll Fraud mechanism

The following command <voice iec syslog>will also help you get toll fraud debugs;

*Mar  9 02:36:17.163: %VOICE_IEC-3-GW: Application Framework Core: Internal Erro
r (Toll fraud call rejected): IEC=1.1.228.3.31.0 on callID 13
*Mar  9 02:36:17.283: %VOICE_IEC-3-GW: Application Framework Core: Internal Erro
r (Toll fraud call rejected): IEC=1.1.228.3.31.0 on callID 14

you can either create a trusted ip access or disable it totally; see Toll-Fraud Prevention Feature in IOS Release 15.1(2)T for more information

Advertisements

ISDN Disconnect “Cause i = 0x829F”

Caller is able to recieve calls but unable to make calls, when making a call they get a  flat dial tone.

Traces show the following:

Dec 20 10:51:51.676: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x
95B8
Cause i = 0x829F – Normal, unspecified

The Cause code 82 is related to the receiving equipment (telco switch) requesting to use a channel that is not activated on the interface for calls.

This looks like an issue with BT who have deactivated the line (in this case, due to not paying bills)

Continue reading

MWI Light in SRST

Setup
Remote site connected to CUCM, using CUE via jtapi

Issue
MWI Light not working in SRST mode

Solution
i did a MWI refresh all and saw the MWI Messgae come through from  162.62.3.253

NOTIFY sip:4002@162.62.3.254:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 162.62.3.253:5060;branch=z9hG4bK1WUTp9FrIozXMZEzjWQ0Iw~~4
Max-Forwards: 70
To: <sip:4002@162.62.3.254:5060>
From: <sip:4002@162.62.3.253:5060>;tag=dsad213b8f
Call-ID: 38932540-1103@sip:4002@162.62.3.253:5060
CSeq: 1 NOTIFY
Content-Length: 113
Contact: <sip:4002@162.62.3.253:5060>
Content-Type: application/simple-message-summary
Event: message-summary

Messages-Waiting: yes
Message-Account: sip:4002@162.62.3.253
Voice-Message: 1/0 (0/0)
Fax-Message: 0/0 (0/0)

When i had a look through the configuration, i saw that the sip-ua was incorrectly configured as 162.62.3.254 (the gateway address)

sip-ua
mwi-server ipv4:162.62.3.253 expires 3600 port 5060 transport udp unsolicited

Translation profile on a voice-port or dial-peer

if you apply a translation-profile on the voice-port for an incoming call, it will have an effect “calling number” and “Peer address”

Example :-

voice translation-rule 2
rule 1 /(.+)/ /901/ type unknown unknown
rule 2 /(.+)/ /901/ type national national
rule 3 /(.+)/ /9001/ type international international

voice translation-profile 20
translate calling 2

Example of Translation profile on voice-port

voice-port 0/0/0
translation-profile incoming 20

1025806: Jun 13 11:44:14.731, PeerAddress 90123456789, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing
1025806: Jun 13 11:44:14.731: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Calling Number=90123456789, Called Number=104839, Voice-Interface=0x4764ADC4,
Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH

Example of translation-profile on Dial-peer

dial-peer voice 1 pots
translation-profile incoming 20
incoming called-number .

1025859: Jun 13 11:50:14.445, PeerAddress 123456789, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing

1025859: Jun 13 11:50:14.445: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Calling Number=123456789, Called Number=104839, Voice-Interface=0x4764ADC4,
Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH

this information is pretty useful when the billing software is looking at the calling party number or peer address it mask to a Name

CM to CUE Voicemail problem

scenario #
CM -> Gatekeeper -> CME -> CUE

Problem
When CUCM user calls CME User and reaches voicemail, the call fails. they get a fast busy tone.

I had a look to see whether it was transcoding, but it wasnt

CME#sh scc connections

Total number of active session(s) 0, and connection(s) 0
CME#

i came to the realisation that the incoming dial-peer was negotiating a codec,

!
dial-peer voice 2300 voip
translation-profile incoming in
voice-class codec 2
incoming called-number .

voice class codec 2
codec preference 1 g729r8
codec preference 2 g711ulaw

in this case it negotiated inbound to g.729.

Since CUE is g711, here it is supposed to invoke a transcoder, but it wasnt

when i removed the voice-class codec call was successful

dial-peer voice 2300 voip
no voice-class codec 2

In summary, i dont know if this is a bug or something, but once the codec has been “negotiated” the CME fails to invoke the transcoder. By removing the codec negotiation, the transcoder was invoked and call was successful

CME#sh scc conn
sess_id    conn_id      stype mode     codec   sport rport ripaddr

1          2            xcode sendrecv g711u   17806 2000  10.10.1.254
1          1            xcode sendrecv g729    18138 2000  10.10.1.254

Total number of active session(s) 1, and connection(s) 2