[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