[cisco-voip] H323 call rejection using Translation Profile not working

Ryan Huff ryanhuff at outlook.com
Fri Apr 8 07:59:46 EDT 2016


Hi Jeff,

While I certainly would not want to usurp Sreekanth, since you stated you are using CUCME, there may be a much easier way for you to do this;

telephony-service
!
after-hours block pattern 1000 7-24
!

Thanks,

Ryan

On Apr 8, 2016, at 7:46 AM, Jeffrey Girard <jeffrey.girard at girardinc.com<mailto:jeffrey.girard at girardinc.com>> wrote:

Results of debug voice ccpai inout are below.  I moved the test bed onto an actual PSTN line and used my cell phone as the call to be blocked.  Thus I have sanitized the number

Snipped output

Apr  8 11:10:38.654: //-1/5BEF8EB8800B/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x4AC94CCC, Call Info(
   Calling Number=TEST CALLING NUMBER,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=TEST CALLED NUMBER(TON=Unknown, NPI=Unknown),
   Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=100, Progress Indication=ORIGINATING SIDE IS NON ISDN(3), Calling IE Present=TRUE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=-1


Apr  8 11:10:38.662: //4/5BEF8EB8800B/CCAPI/cc_process_call_setup_ind:
   >>>>CCAPI handed cid 4 with tag 100 to app "_ManagedAppProcess_Default"  <<<<<<<<<<<<<<<<<<<<<<<<<< correct dial peer 100
Apr  8 11:10:38.666: //4/5BEF8EB8800B/CCAPI/ccCallDisconnect:
   Cause Value=21, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)  <<<<<<<<<<<<<<<<<<correct disconnect code
Apr  8 11:10:38.666: //4/5BEF8EB8800B/CCAPI/ccCallDisconnect:
   Cause Value=21, Call Entry(Responsed=TRUE, Cause Value=21)
Apr  8 11:10:38.666: //4/5BEF8EB8800B/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Apr  8 11:10:44.658: //4/5BEF8EB8800B/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x4AC94CCC, Tag=0x0, Call Id=4,
   Call Entry(Disconnect Cause=21, Voice Class Cause Code=0, Retry Count=0)
Apr  8 11:10:44.662: //4/5BEF8EB8800B/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent             <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<call should be disconnected
Apr  8 11:10:44.662: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Apr  8 11:10:44.662: :cc_free_feature_vsa freeing 4B8F1520
Apr  8 11:10:44.662: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Apr  8 11:10:44.662:  vsacount in free is 0
Apr  8 11:10:55.558: //-1/6602DE26800F/CCAPI/cc_api_display_ie_subfields:
   cc_api_call_setup_ind_common:
   cisco-username=
   ----- ccCallInfo IE subfields -----
   cisco-ani=
   cisco-anitype=0
   cisco-aniplan=0
   cisco-anipi=0
   cisco-anisi=0
   dest=6078350406
   cisco-desttype=0
   cisco-destplan=0
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=0
   cisco-rdnplan=0
   cisco-rdnpi=0
   cisco-rdnsi=0
   cisco-redirectreason=0   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

Apr  8 11:10:55.558: //-1/6602DE26800F/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x4AC94CCC, Call Info(
   Calling Number=,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),  <<<<<<<<<<<<<<<<call is being reprocessed with no calling number
   Called Number=TEST CALLED NUMBER(TON=Unknown, NPI=Unknown),
   Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=0, Progress Indication=ORIGINATING SIDE IS NON ISDN(3), Calling IE Present=FALSE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=-1
Apr  8 11:10:55.558: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr  8 11:10:55.558: :cc_get_feature_vsa malloc success
Apr  8 11:10:55.558: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr  8 11:10:55.558:  cc_get_feature_vsa count is 1
Apr  8 11:10:55.558: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr  8 11:10:55.558: :FEATURE_VSA attributes are: feature_name:0,feature_time:1267668264,feature_id:5
Apr  8 11:10:55.562: //5/6602DE26800F/CCAPI/cc_api_call_setup_ind_common:
   Set Up Event Sent;
   Call Info(Calling Number=(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=6078350406(TON=Unknown, NPI=Unknown))
Apr  8 11:10:55.566: //5/6602DE26800F/CCAPI/cc_process_call_setup_ind:
   Event=0x4AC4A460
Apr  8 11:10:55.566: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
   Try with the demoted called number 6078350406
Apr  8 11:10:55.566: //5/6602DE26800F/CCAPI/ccCallSetContext:
   Context=0x4BDFE058
Apr  8 11:10:55.566: //5/6602DE26800F/CCAPI/cc_process_call_setup_ind:
   >>>>CCAPI handed cid 5 with tag 0 to app "_ManagedAppProcess_Default"  <<<<<<<<<<<<<<<<<<<<<matches default dial peer
Based upon the reprocessed call, the lack of a calling number matches the default dial peer and the call eventually gets sent to CUCM and comes in as an unknown number.

Output of debug voice translation

Apr  8 11:23:29.192: //-1/xxxxxxxxxxxx/RXRULE/regxrule_get_profile_from_trunkgroup_internal:
   Voice port 0x4AC94CCC dsl=-1 timeslot=0 does not belong to any trunk group
Apr  8 11:23:29.196: //-1/2736DBF38014/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x4B7B0570; count=1
Apr  8 11:23:29.196: //-1/2736DBF38014/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x4C7C8250
Apr  8 11:23:29.204: //-1/2736DBF38014/RXRULE/regxrule_match: Matched a call block rule; number=TEST CALLING NUMBER rule precedence=1  <<<<<<<<<<matched on the block rule
Apr  8 11:23:29.204: //-1/2736DBF38014/RXRULE/regxrule_profile_block_internal: Matched with rule 1 in ruleset 1
Apr  8 11:23:35.199: //-1/2736DBF38014/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x4B7B0570; count=0
Apr  8 11:23:35.199: //-1/2736DBF38014/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x0
Apr  8 11:23:46.079: //-1/xxxxxxxxxxxx/RXRULE/regxrule_get_profile_from_trunkgroup_internal:
   Voice port 0x4AC94CCC dsl=-1 timeslot=0 does not belong to any trunk group
Apr  8 11:23:46.083: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x4B7B00F8; count=1
Apr  8 11:23:46.083: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x4C7C8250
Apr  8 11:23:46.087: //-1/3147BAC18018/RXRULE/regxrule_get_profile_from_dialpeer_internal: Error: Invalid input peer_tag=0 direction=incoming    <<<<<<default dial peer again
Apr  8 11:23:46.087: //-1/3147BAC18018/RXRULE/regxrule_stack_push_RegXruleNumInfo_internal: stack=0x4B7B00F8; count=1
Apr  8 11:23:46.095: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x4B7B00F8; count=1
Apr  8 11:23:46.095: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x4C7C8250
Apr  8 11:23:46.095: //-1/3147BAC18018/RXRULE/regxrule_stack_push_RegXruleNumInfo_internal: stack=0x4B7B00F8; count=1
Apr  8 11:23:46.099: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x4B7B00F8; count=1
Apr  8 11:23:46.099: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x4C7C8250
Apr  8 11:23:46.099: //-1/3147BAC18018/RXRULE/regxrule_stack_push_RegXruleNumInfo_internal: stack=0x4B7B00F8; count=1
Apr  8 11:23:50.327: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x0
Apr  8 11:23:50.335: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_RegXruleNumInfo: stack=0x4B7B00F8; count=1
Apr  8 11:23:50.335: //-1/3147BAC18018/RXRULE/regxrule_stack_pop_callinfo_internal: numinfo=0x4C7C8250


Output of debug voip dialpeer

Apr  8 11:35:45.834: %SYS-5-CONFIG_I: Configured from console by jeffrey.girard on vty0 (192.168.1.30)
Apr  8 11:35:54.669: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number=TEST CALLING NUMBER, Called Number=, Voice-Interface=0x4AC94CCC,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
Apr  8 11:35:54.669: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_ANSWER; Incoming Dial-peer=100  <<<<<<<<<<<<<<<correct inbound dial peer
Apr  8 11:35:54.669: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:
   dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0
Apr  8 11:35:54.677: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=TEST CALLED NUMBER, Peer Info Type=DIALPEER_INFO_SPEECH
Apr  8 11:35:54.677: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=TEST CALLED NUMBER  <<<<<<<<<<<<<<<<<continues to try to match.  Matched on outbound dial peer with destination pattern set to TEST CALLED NUMBER to send to CUCM
Apr  8 11:35:54.677: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
Apr  8 11:35:54.677: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:
   dialstring=6078350406, saf_enabled=0, saf_dndb_lookup=1, dp_result=0
Apr  8 11:35:54.677: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
   Result=SUCCESS(0)
   List of Matched Outgoing Dial-peer(s):
     1: Dial-peer Tag=8350406

So, the question becomes - why does CUCME continue to try to find a matching dial peer after the incoming dial peer has already rejected the call?

Jeff

From: Sreekanth [mailto:sknth.n at gmail.com]
Sent: Friday, April 8, 2016 5:25 AM
To: Jeffrey Girard
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] H323 call rejection using Translation Profile not working

Can you share these debugs for a test call?
debug voip ccapi inout
debug voip translation
debug voip dialpeer


On 8 April 2016 at 07:05, Jeffrey Girard <jeffrey.girard at girardinc.com<mailto:jeffrey.girard at girardinc.com>> wrote:
All -
                Playing around with call blocking using an H.323 gateway.

                Gateway has an FXO port and it is configured as an H323 GW to a CUCM.

                Here is the code

                voice translation-rule 1
rule 1 reject /1000/
exit

voice translation-profile call_block
translate calling 1
exit

                dial-peer voice 100 pots
                answer-address 1000
                translation-profile incoming call_block
call-block translation-profile incoming call_block
                call-block disconnect-cause call-reject

If I do a test of the translation profile using
Test voice translation-rule 1 /1000/
I get
/1000/ blocked on rule 1

However, when I have debug voice dialpeer enabled, I see that the incoming call matches on the correct dial peer (dial peer 100) and then continues to process and searches for an outbound dial peer.

I have tried several variations.  I have taken out the "translation-profile incoming call_block" command from the dial peer.  I have tried adding the command "translation-profile incoming call_block" directly to the voice port.

In all instances, the correct incoming dial peer matches, but then it seems like the translation profile does not get called.

Any thoughts?

Jeff

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160408/ab8afc96/attachment.html>


More information about the cisco-voip mailing list