[cisco-voip] H323 call rejection using Translation Profile not working
Jeffrey Girard
jeffrey.girard at girardinc.com
Fri Apr 8 08:02:37 EDT 2016
Ryan -
Yes, I agree, and thanks for the input.
However, the intent here was not to "meet a customer requirement"
I was trying to learn a new skill that I had not previously used
But I certainly appreciate your willingness to help ?
Jeff
From: Ryan Huff [mailto:ryanhuff at outlook.com]
Sent: Friday, April 8, 2016 8:00 AM
To: Jeffrey Girard
Cc: Sreekanth; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] H323 call rejection using Translation Profile not working
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/03a3b799/attachment.html>
More information about the cisco-voip
mailing list