[cisco-voip] H323 call rejection using Translation Profile not working
Sreekanth
sknth.n at gmail.com
Fri Apr 8 07:57:34 EDT 2016
It looks like the original call is being disconnected, and there is a new
call.
The original GUID and call leg were:4/5BEF8EB8800B and the call was
disconnected at 11:10:44
Apr 8 11:10:44.662: //4/5BEF8EB8800B/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
11 seconds later, the second call comes in.
Apr 8 11:10:55.558: //-1/6602DE26800F/CCAPI/cc_api_display_ie_subfields:
You might want to check if the Telco is sending the call back to us as a
redundant mechanism after we reject it.
debug vpm signal, debug voip vtsp default will provide more input on what
happens on the FXO side.
Sreekanth
On 8 April 2016 at 17:15, Jeffrey Girard <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
> *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>
> 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
> 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/5cc916d7/attachment.html>
More information about the cisco-voip
mailing list