Calling Party Presentation

Hello,
I have CM4.1(3)Sr3c connecet to a cisco 1760 h323 gateway, when i make a call from a ipphone to a phone beyind the gateway I dont want to send the calling number, I have tryed in the gateway configuration on the callmanager to put restrict in Calling Party Presentation but with no sucess. Is there any other way to block this, all the other setting's are default.
Thanks

Try setting the Calling Party Number Presentation to Restricted at the Route Pattern or Route List level and see if that helps.
Regards,
Anup

Similar Messages

  • Presenting Called Party with IVR?

    We're building out a prepaid calling card system using IVR instances on Voice Gateways with a modified version of the Debit Card script. The Voice Gateways communicate back to billing software via radius, and so far everything has been going great! Last week we met with the customer and were thrown a bit of a curveball. They are requesting that when the called party picks up the line they are presented with a recorded message and an option to accept or deny the call. Something like: "This is a Prepaid Call from <name>. To accept press 1. To deny press 2, or hang up." To add a bit more complexity, they do not want the calling party to be able to speak with the called party until they have accepted the call. I've been looking around at a few different ways to do this but so far I'm drawing a blank. Any help would be greatly appreciated. Thanks!

    Rolando,
    Thanks so much for your help! I just reached out to the Cisco Partner Helpline about this exact feature in UCCX. If you don't mind me asking a quick question while I wait to hear back from them. The Voice Gateway running the IVR Debit Card scripts keeps the Billing System updated with call duration info via RADIUS. The Billing System uses this information to determine the call duration and the amount to deduct from the calling account. Once the outbound call has been authorized from the on-site Voice Gateway, would you then have the call forwarded to a UCCX instance that matches on inbound and then creates it's own outbound dial? Forgive my ignorance of UCCX. Would it be something like: match on inbound ANI & park call, place outbound dial to DNIS and run IVR script when called party picks up, after they press 1 connect the 2 calls together? Thanks!

  • Calling Party translation internal and external

    Hello all!
    I have a problem regarding the external phone number mask and some special requests.
    Basically is the feature "external phone number mask" enabled and in use.
    Now we have the following request:
    Several phones are member of a hunt list, with the extension 555. They want now two groups, one should show internal and external the 555. And the other one should show internal the 555 and external the "normal" extension of the user.
    Overview, showing the numbers:
    Phone group 1:
    external: 555
    internal: 555
    Phone group 2:
    external: line extension
    internal: 555
    Used is CUCM 8.6 and MGCP-Gateways to the PSTN.
    Has anyone an idea to configure that?
    Thanks a lot!
    Kind regards,
    DrMxxxxx

    Ah, got it. Well here's how you do it then:
    Create a Partition for e.g. PT-CallingParty and put it in CSS-CallingParty.
    Create a Calling Party Transformation Mask as following:
    4912345XXX with PT-CallingParty
    Check Mark "Use Calling Party's External Phone Number Mask"
    Under Calling Party Transformation Mask put "4912345555"
    Now, for phones:
    Go under each phone and under Number Presentation Transformation Uncheck "Use Device pool Calling Party Transformation CSS" and from dropdown just above it Select " CSS-CallingParty" (Apply config, I will suggest BAT for this if you have multiple phones)
    Once done that, For User A put External Mask as 4912345555 
    Whereas for User B put 4912345456
    Let me know how that works out for you.
    Regards,
    Vishal

  • Calling name presentation cucm

    Hi
    I have a problem with calling name presentation when a call is transfered from one of my secretaries to another internal user, the original Called Party details are shown on the recieving phone.
    This is the secretaries query :- "If I picked up an external call that has bounced from my Manager cathy's phone and the caller requests to speak to someone else (i.e. Jim) as Cathy is unavailable, when I call Jim's extension (without ending my external call) it tells Jim that it is Cathy calling him and not me calling".
    So the wrong calling party name is shown (the original called party, rather than the transferor) ?
    Thanks
    Paul

    Hi Paul,
    Can you give a try for below settings:
    When a call routes through a translation or route pattern, routes to a Call Forward All or Call Forward Busy destination, or gets redirected through a call transfer or CTI application, the connected number display updates to show the modified number or redirected number.
    To turn off phone display updates so that the phone displays only the dialed digits, set the Cisco CallManager service parameter "Always Display Original Dialed Number" to true. When this service parameter specifies true, the originating phone displays only the dialed digits for the duration of the call.
    You can choose if the name for the original dialed number or the number after translation is displayed using the Cisco CallManager service parameter called "Name Display for Original Dialed Number When Translated". The default setting displays the name for the original dialed number before translation. This parameter is not applicable if the "Always Display Original Dialed Number" service parameter is set to false.
    Regards,
    Nishant Savalia

  • Calls going out displaying extra digits to called party

    I have calls going out of one of our offices that have extra digits appended to the end. Instead of caller id showing the 10 digits of the calling party, it shows 15 repeating the last 5 digits again. If my number was 1234567890, it goes out 123456789067890. Obviously that looks strange and the called party often times doesn't answer. I've been comparing with some of our other sites but I don't see anything obvious. I'm new to voice, I've looked at the dial peer and translation rule on our gateway for that site. Where else should I be looking for this problem. AT&T says they aren't sending the extra digits.
    Thanks

    Here is the log from a test call after enabling the debugs. Sequence# 095713 includes the extra digits. Thanks for the help.
    095693: Sep 30 09:48:53.467 CST: //-1/00E60F465903/CCAPI/cc_api_display_ie_subfields:
       cc_api_call_setup_ind_common:
       cisco-username=Dallas Main Number
       ----- ccCallInfo IE subfields -----
       cisco-ani=2147651234
       cisco-anitype=0
       cisco-aniplan=0
       cisco-anipi=0
       cisco-anisi=1
       dest=917139074321
       cisco-desttype=0
       cisco-destplan=0
       cisco-rdie=FFFFFFFF
       cisco-rdn=
       cisco-rdntype=-1
       cisco-rdnplan=-1
       cisco-rdnpi=-1
       cisco-rdnsi=-1
       cisco-redirectreason=-1   fwd_final_type =0
       final_redirectNumber =
       hunt_group_timeout =0
    095694: Sep 30 09:48:53.467 CST: //-1/00E60F465903/CCAPI/cc_api_call_setup_ind_common:
       Interface=0x4A04DDA4, Call Info(
       Calling Number=2147651234,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
       Called Number=917139074321(TON=Unknown, NPI=Unknown),
       Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
       Incoming Dial-peer=101, Progress Indication=NULL(0), Calling IE Present=TRUE,
       Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=27508
    095695: Sep 30 09:48:53.467 CST: //-1/00E60F465903/CCAPI/ccCheckClipClir:
       In: Calling Number=2147651234(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
    095696: Sep 30 09:48:53.467 CST: //-1/00E60F465903/CCAPI/ccCheckClipClir:
       Out: Calling Number=2147651234(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
    095697: Sep 30 09:48:53.467 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
    095698: Sep 30 09:48:53.467 CST: :cc_get_feature_vsa malloc success
    095699: Sep 30 09:48:53.467 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
    095700: Sep 30 09:48:53.467 CST:  cc_get_feature_vsa count is 3
    095701: Sep 30 09:48:53.467 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
    095702: Sep 30 09:48:53.467 CST: :FEATURE_VSA attributes are: feature_name:0,feature_time:1309707448,feature_id:27508
    095703: Sep 30 09:48:53.467 CST: //27508/00E60F465903/CCAPI/cc_api_call_setup_ind_common:
       Set Up Event Sent;
       Call Info(Calling Number=2147651234(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
       Called Number=917139074321(TON=Unknown, NPI=Unknown))
    095704: Sep 30 09:48:53.471 CST: //27508/00E60F465903/CCAPI/cc_process_call_setup_ind:
       Event=0x4B77BFD0
    095705: Sep 30 09:48:53.471 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
       Try with the demoted called number 917139074321
    095706: Sep 30 09:48:53.471 CST: //27508/00E60F465903/CCAPI/ccCallSetContext:
       Context=0x4E138418
    095707: Sep 30 09:48:53.471 CST: //27508/00E60F465903/CCAPI/cc_process_call_setup_ind:
       >>>>CCAPI handed cid 27508 with tag 101 to app "_ManagedAppProcess_Default"
    095708: Sep 30 09:48:53.471 CST: //27508/00E60F465903/CCAPI/ccCallProceeding:
       Progress Indication=NULL(0)
    095709: Sep 30 09:48:53.475 CST: //27508/00E60F465903/CCAPI/ccCallSetupRequest:
       Destination=, Calling IE Present=TRUE, Mode=0,
       Outgoing Dial-peer=91, Params=0x4E1276A8, Progress Indication=NULL(0)
    095710: Sep 30 09:48:53.475 CST: //27508/00E60F465903/CCAPI/ccCheckClipClir:
       In: Calling Number=214765123451234(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
    095711: Sep 30 09:48:53.475 CST: //27508/00E60F465903/CCAPI/ccCheckClipClir:
       Out: Calling Number=214765123451234(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
    095712: Sep 30 09:48:53.475 CST: //27508/00E60F465903/CCAPI/ccCallSetupRequest:
       Destination Pattern=91[2-9].........$, Called Number=917139074321, Digit Strip=TRUE
    095713: Sep 30 09:48:53.475 CST: //27508/00E60F465903/CCAPI/ccCallSetupRequest:
       Calling Number=214765123451234(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
       Called Number=917139074321(TON=Unknown, NPI=Unknown),
       Redirect Number=, Display Info=Dallas Main Number
       Account Number=Dallas Main Number, Final Destination Flag=TRUE,
       Guid=00E60F46-E5D0-A142-5903-1B030A0A023F, Outgoing Dial-peer=91
    095714: Sep 30 09:48:53.475 CST: //27508/00E60F465903/CCAPI/cc_api_display_ie_subfields:
       ccCallSetupRequest:
       cisco-username=Dallas Main Number
       ----- ccCallInfo IE subfields -----
       cisco-ani=214765123451234
       cisco-anitype=0
       cisco-aniplan=0
       cisco-anipi=0
       cisco-anisi=1
       dest=917139074321
       cisco-desttype=0
       cisco-destplan=0
       cisco-rdie=FFFFFFFF
       cisco-rdn=
       cisco-rdntype=-1
       cisco-rdnplan=-1
       cisco-rdnpi=-1
       cisco-rdnsi=-1
       cisco-redirectreason=-1   fwd_final_type =0
       final_redirectNumber =
       hunt_group_timeout =0
    095715: Sep 30 09:48:53.475 CST: //27508/00E60F465903/CCAPI/ccIFCallSetupRequestPrivate:
       Interface=0x4B7C2F08, Interface Type=6, Destination=, Mode=0x0,
       Call Params(Calling Number=214765123451234,(Calling Name=Dallas Main Number)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
       Called Number=917139074321(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
       Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=91, Call Count On=FALSE,
       Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
    095716: Sep 30 09:48:53.475 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
    095717: Sep 30 09:48:53.479 CST: :cc_get_feature_vsa malloc success
    095718: Sep 30 09:48:53.479 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
    095719: Sep 30 09:48:53.479 CST:  cc_get_feature_vsa count is 4
    095720: Sep 30 09:48:53.479 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
    095721: Sep 30 09:48:53.479 CST: :FEATURE_VSA attributes are: feature_name:0,feature_time:1309709240,feature_id:27509
    095722: Sep 30 09:48:53.479 CST: //27509/00E60F465903/CCAPI/ccIFCallSetupRequestPrivate:
       SPI Call Setup Request Is Success; Interface Type=6, FlowMode=1
    095723: Sep 30 09:48:53.479 CST: //27509/00E60F465903/CCAPI/ccCallSetContext:
       Context=0x4E127658
    095724: Sep 30 09:48:53.479 CST: //27508/00E60F465903/CCAPI/ccSaveDialpeerTag:
       Outgoing Dial-peer=91
    095725: Sep 30 09:48:53.483 CST: ISDN Se0/0/0:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 13
    095726: Sep 30 09:48:53.483 CST: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x1 0x1, Calling num 214765123451234
    095727: Sep 30 09:48:53.487 CST: ISDN Se0/0/0:23 Q931: Sending SETUP  callref = 0x13D3 callID = 0x9354 switch = primary-ni interface = User
    095728: Sep 30 09:48:53.487 CST: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x13D3
            Bearer Capability i = 0x8090A2
                    Standard = CCITT
                    Transfer Capability = Speech  
                    Transfer Mode = Circuit
                    Transfer Rate = 64 kbit/s
            Channel ID i = 0xA98397
                    Exclusive, Channel 23
            Display i = 'Dallas Main Number'
            Calling Party Number i = 0x1181, '214765123451234'
                    Plan:ISDN, Type:International
            Called Party Number i = 0x80, '17139074321'
                    Plan:Unknown, Type:Unknown
    095729: Sep 30 09:48:53.551 CST: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x93D3
            Channel ID i = 0xA98397
                    Exclusive, Channel 23
    095730: Sep 30 09:48:53.579 CST: //27509/00E60F465903/CCAPI/cc_api_call_proceeding:
       Interface=0x4B7C2F08, Progress Indication=NULL(0)
    095731: Sep 30 09:48:55.295 CST: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x93D3
            Progress Ind i = 0x8488 - In-band info or appropriate now available
    095732: Sep 30 09:48:55.295 CST: //27509/00E60F465903/CCAPI/cc_api_call_alert:
       Interface=0x4B7C2F08, Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)
    095733: Sep 30 09:48:55.295 CST: //27509/00E60F465903/CCAPI/cc_api_call_alert:
       Call Entry(Retry Count=0, Responsed=TRUE)
    095734: Sep 30 09:48:55.299 CST: //27508/00E60F465903/CCAPI/ccCallAlert:
       Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)
    095735: Sep 30 09:48:55.299 CST: //27508/00E60F465903/CCAPI/ccCallAlert:
       Call Entry(Responsed=TRUE, Alert Sent=TRUE)
    095736: Sep 30 09:48:55.299 CST: //27509/00E60F465903/CCAPI/cc_api_get_called_ccm_detected:
       CallInfo(ccm detected=0)
    095737: Sep 30 09:48:55.299 CST: //27508/00E60F465903/CCAPI/ccConferenceCreate:
       (confID=0x4E1EE068, callID1=0x6B74, gcid=0-0-0-0, tag=0x0)
    095738: Sep 30 09:48:55.299 CST: //27509/00E60F465903/CCAPI/ccConferenceCreate:
       (confID=0x4E1EE068, callID2=0x6B75, gcid=0-0-0-0, tag=0x0)
    095739: Sep 30 09:48:55.299 CST: //27508/00E60F465903/CCAPI/ccConferenceCreate:
       Conference Id=0x4E1EE068, Call Id1=27508, Call Id2=27509, Tag=0x0
    095740: Sep 30 09:48:55.299 CST: //27508/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
    095741: Sep 30 09:48:55.299 CST: cc_api_get_xcode_stream : 4702
    095742: Sep 30 09:48:55.299 CST: //27508/00E60F465903/CCAPI/cc_api_bridge_done:
       Conference Id=0x2A56, Source Interface=0x4A04DDA4, Source Call Id=27508,
       Destination Call Id=27509, Disposition=0x0, Tag=0x0
    095743: Sep 30 09:48:55.299 CST: //27509/00E60F465903/CCAPI/cc_api_bridge_done:
       Conference Id=0x2A56, Source Interface=0x4B7C2F08, Source Call Id=27509,
       Destination Call Id=27508, Disposition=0x0, Tag=0xFFFFFFFF
    095744: Sep 30 09:48:55.299 CST: //27508/00E60F465903/CCAPI/cc_generic_bridge_done:
       Conference Id=0x2A56, Source Interface=0x4B7C2F08, Source Call Id=27509,
       Destination Call Id=27508, Disposition=0x0, Tag=0xFFFFFFFF
    095745: Sep 30 09:48:55.299 CST: //27508/00E60F465903/CCAPI/ccConferenceCreate:
       Call Entry(Conference Id=0x2A56, Destination Call Id=27509)
    095746: Sep 30 09:48:55.299 CST: //27509/00E60F465903/CCAPI/ccConferenceCreate:
       Call Entry(Conference Id=0x2A56, Destination Call Id=27508)
    095747: Sep 30 09:48:55.299 CST: //27509/00E60F465903/CCAPI/cc_api_caps_ind:
       Destination Interface=0x4A04DDA4, Destination Call Id=27508, Source Call Id=27509,
       Caps(Codec=0x1, Fax Rate=0x1, Vad=0x1,
       Modem=0x2, Codec Bytes=20, Signal Type=3)
    095748: Sep 30 09:48:55.303 CST: //27509/00E60F465903/CCAPI/cc_api_caps_ind:
       Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
       Playout Max=1000(ms), Fax Nom=300(ms))
    095749: Sep 30 09:48:55.303 CST: //27508/00E60F465903/CCAPI/ccCallNotify:
       Data Bitmask=0x7, Call Id=27508
    095750: Sep 30 09:48:55.303 CST: //27509/00E60F465903/CCAPI/cc_api_get_called_ccm_detected:
       CallInfo(ccm detected=0)
    095751: Sep 30 09:48:55.303 CST: //27508/00E60F465903/CCAPI/cc_api_get_delay_xport:
       CallInfo(delay xport=FALSE)
    095752: Sep 30 09:48:55.311 CST: //27508/00E60F465903/CCAPI/cc_process_notify_bridge_done:
       Conference Id=0x2A56, Call Id1=27508, Call Id2=27509
    095753: Sep 30 09:48:55.811 CST: //27508/00E60F465903/CCAPI/cc_api_caps_ind:
       Destination Interface=0x4B7C2F08, Destination Call Id=27509, Source Call Id=27508,
       Caps(Codec=0x1, Fax Rate=0x80, Vad=0x1,
       Modem=0x0, Codec Bytes=160, Signal Type=2)
    095754: Sep 30 09:48:55.811 CST: //27508/00E60F465903/CCAPI/cc_api_caps_ind:
       Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
       Playout Max=1000(ms), Fax Nom=300(ms))
    095755: Sep 30 09:48:55.811 CST: //27508/00E60F465903/CCAPI/cc_api_caps_ack:
       Destination Interface=0x4B7C2F08, Destination Call Id=27509, Source Call Id=27508,
       Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_14400(0x80), Vad=OFF(0x1),
       Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=8122)
    095756: Sep 30 09:48:55.815 CST: //27509/00E60F465903/CCAPI/cc_api_caps_ack:
       Destination Interface=0x4A04DDA4, Destination Call Id=27508, Source Call Id=27509,
       Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_14400(0x80), Vad=OFF(0x1),
       Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=8122)
    095757: Sep 30 09:48:55.819 CST: //27509/00E60F465903/CCAPI/cc_api_voice_mode_event:
       Call Id=27509
    095758: Sep 30 09:48:55.819 CST: //27509/00E60F465903/CCAPI/cc_api_voice_mode_event:
       Call Entry(Context=0x4E127658)
    095759: Sep 30 09:49:03.691 CST: //27507/E25C9BF99854/CCAPI/cc_api_call_disconnected:
       Cause Value=16, Interface=0x4A04DDA4, Call Id=27507
    095760: Sep 30 09:49:03.695 CST: //27507/E25C9BF99854/CCAPI/cc_api_call_disconnected:
       Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
    095761: Sep 30 09:49:03.695 CST: //27506/E25C9BF99854/CCAPI/ccConferenceDestroy:
       Conference Id=0x2A55, Tag=0x0
    095762: Sep 30 09:49:03.695 CST: //27506/E25C9BF99854/CCAPI/cc_api_bridge_drop_done:
       Conference Id=0x2A55, Source Interface=0x4B7C2F08, Source Call Id=27506,
       Destination Call Id=27507, Disposition=0x0, Tag=0x0
    095763: Sep 30 09:49:03.695 CST: //27507/E25C9BF99854/CCAPI/cc_api_bridge_drop_done:
       Conference Id=0x2A55, Source Interface=0x4A04DDA4, Source Call Id=27507,
       Destination Call Id=27506, Disposition=0x0, Tag=0x0
    095764: Sep 30 09:49:03.695 CST: //27506/E25C9BF99854/CCAPI/cc_generic_bridge_done:
       Conference Id=0x2A55, Source Interface=0x4A04DDA4, Source Call Id=27507,
       Destination Call Id=27506, Disposition=0x0, Tag=0x0
    095765: Sep 30 09:49:03.695 CST: //27506/E25C9BF99854/CCAPI/ccCallDisconnect:
       Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
    095766: Sep 30 09:49:03.695 CST: //27506/E25C9BF99854/CCAPI/ccCallDisconnect:
       Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
    095767: Sep 30 09:49:03.695 CST: //27506/E25C9BF99854/CCAPI/cc_api_get_transfer_info:
       Transfer Number Is Null
    095768: Sep 30 09:49:03.695 CST: //27507/E25C9BF99854/CCAPI/ccCallDisconnect:
       Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)
    095769: Sep 30 09:49:03.695 CST: //27507/E25C9BF99854/CCAPI/ccCallDisconnect:
       Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
    095770: Sep 30 09:49:03.699 CST: //27507/E25C9BF99854/CCAPI/cc_api_get_transfer_info:
       Transfer Number Is Null
    095771: Sep 30 09:49:03.719 CST: //27507/E25C9BF99854/CCAPI/cc_api_get_transfer_info:
       Transfer Number Is Null
    095772: Sep 30 09:49:03.723 CST: //27507/E25C9BF99854/CCAPI/cc_api_call_disconnect_done:
       Disposition=0, Interface=0x4A04DDA4, Tag=0x0, Call Id=27507,
       Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
    095773: Sep 30 09:49:03.723 CST: //27507/E25C9BF99854/CCAPI/cc_api_call_disconnect_done:
       Call Disconnect Event Sent
    095774: Sep 30 09:49:03.723 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
    095775: Sep 30 09:49:03.723 CST: :cc_free_feature_vsa freeing 4E108850
    095776: Sep 30 09:49:03.723 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
    095777: Sep 30 09:49:03.723 CST:  vsacount in free is 3
    095778: Sep 30 09:49:03.727 CST: %ISDN-6-DISCONNECT: Interface Serial0/0/0:0  disconnected from 2147662349 , call lasted 105 seconds
    095779: Sep 30 09:49:03.731 CST: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x833F
            Cause i = 0x8090 - Normal call clearing
    095780: Sep 30 09:49:03.759 CST: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8  callref = 0x033F
    095781: Sep 30 09:49:03.759 CST: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x833F
    095782: Sep 30 09:49:03.767 CST: //27506/E25C9BF99854/CCAPI/cc_api_call_disconnect_done:
       Disposition=0, Interface=0x4B7C2F08, Tag=0x0, Call Id=27506,
       Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
    095783: Sep 30 09:49:03.767 CST: //27506/E25C9BF99854/CCAPI/cc_api_call_disconnect_done:
       Call Disconnect Event Sent
    095784: Sep 30 09:49:03.767 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
    095785: Sep 30 09:49:03.767 CST: :cc_free_feature_vsa freeing 4E109570
    095786: Sep 30 09:49:03.767 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
    095787: Sep 30 09:49:03.767 CST:  vsacount in free is 2
    095788: Sep 30 09:49:13.991 CST: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x93D3
            Progress Ind i = 0x8482 - Destination address is non-ISDN
    095789: Sep 30 09:49:13.995 CST: %ISDN-6-CONNECT: Interface Serial0/0/0:22 is now connected to 17139074321 N/A
    095790: Sep 30 09:49:13.995 CST: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x13D3
    095791: Sep 30 09:49:13.995 CST: //27509/00E60F465903/CCAPI/cc_api_call_connected:
       Interface=0x4B7C2F08, Data Bitmask=0x1, Progress Indication=DESTINATION IS NON ISDN(2),
       Connection Handle=0
    095792: Sep 30 09:49:13.999 CST: //27509/00E60F465903/CCAPI/cc_api_call_connected:
       Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
    095793: Sep 30 09:49:13.999 CST: //27508/00E60F465903/CCAPI/ccCallConnect:
       Progress Indication=DESTINATION IS NON ISDN(2), Data Bitmask=0x1
    095794: Sep 30 09:49:13.999 CST: //27509/00E60F465903/CCAPI/cc_api_get_called_ccm_detected:
       CallInfo(ccm detected=0)
    095795: Sep 30 09:49:13.999 CST: //27508/00E60F465903/CCAPI/ccCallConnect:
       Call Entry(Connected=TRUE, Responsed=TRUE)
    095796: Sep 30 09:49:13.999 CST: //27508/00E60F465903/CCAPI/ccCallNotify:
       Data Bitmask=0x7, Call Id=27508
    095797: Sep 30 09:49:13.999 CST: //27509/00E60F465903/CCAPI/cc_api_get_called_ccm_detected:
       CallInfo(ccm detected=0)
    095798: Sep 30 09:49:33.319 CST: //27508/00E60F465903/CCAPI/cc_api_call_disconnected:
       Cause Value=16, Interface=0x4A04DDA4, Call Id=27508
    095799: Sep 30 09:49:33.323 CST: //27508/00E60F465903/CCAPI/cc_api_call_disconnected:
       Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
    095800: Sep 30 09:49:33.323 CST: //27508/00E60F465903/CCAPI/ccConferenceDestroy:
       Conference Id=0x2A56, Tag=0x0
    095801: Sep 30 09:49:33.323 CST: //27508/00E60F465903/CCAPI/cc_api_bridge_drop_done:
       Conference Id=0x2A56, Source Interface=0x4A04DDA4, Source Call Id=27508,
       Destination Call Id=27509, Disposition=0x0, Tag=0x0
    095802: Sep 30 09:49:33.323 CST: //27509/00E60F465903/CCAPI/cc_api_bridge_drop_done:
       Conference Id=0x2A56, Source Interface=0x4B7C2F08, Source Call Id=27509,
       Destination Call Id=27508, Disposition=0x0, Tag=0x0
    095803: Sep 30 09:49:33.323 CST: //27508/00E60F465903/CCAPI/cc_generic_bridge_done:
       Conference Id=0x2A56, Source Interface=0x4B7C2F08, Source Call Id=27509,
       Destination Call Id=27508, Disposition=0x0, Tag=0x0
    095804: Sep 30 09:49:33.327 CST: //27508/00E60F465903/CCAPI/ccCallDisconnect:
       Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)
    095805: Sep 30 09:49:33.327 CST: //27508/00E60F465903/CCAPI/ccCallDisconnect:
       Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
    095806: Sep 30 09:49:33.327 CST: //27508/00E60F465903/CCAPI/cc_api_get_transfer_info:
       Transfer Number Is Null
    095807: Sep 30 09:49:33.327 CST: //27509/00E60F465903/CCAPI/ccCallDisconnect:
       Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
    095808: Sep 30 09:49:33.327 CST: //27509/00E60F465903/CCAPI/ccCallDisconnect:
       Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
    095809: Sep 30 09:49:33.327 CST: //27509/00E60F465903/CCAPI/cc_api_get_transfer_info:
       Transfer Number Is Null
    095810: Sep 30 09:49:33.351 CST: //27508/00E60F465903/CCAPI/cc_api_get_transfer_info:
       Transfer Number Is Null
    095811: Sep 30 09:49:33.355 CST: //27508/00E60F465903/CCAPI/cc_api_call_disconnect_done:
       Disposition=0, Interface=0x4A04DDA4, Tag=0x0, Call Id=27508,
       Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
    095812: Sep 30 09:49:33.355 CST: //27508/00E60F465903/CCAPI/cc_api_call_disconnect_done:
       Call Disconnect Event Sent
    095813: Sep 30 09:49:33.355 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
    095814: Sep 30 09:49:33.355 CST: :cc_free_feature_vsa freeing 4E108CB0
    095815: Sep 30 09:49:33.355 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
    095816: Sep 30 09:49:33.355 CST:  vsacount in free is 1
    095817: Sep 30 09:49:33.363 CST: %ISDN-6-DISCONNECT: Interface Serial0/0/0:22  disconnected from 17139074321 , call lasted 19 seconds
    095818: Sep 30 09:49:33.363 CST: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x13D3
            Cause i = 0x8090 - Normal call clearing
    095819: Sep 30 09:49:33.399 CST: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8  callref = 0x93D3
    095820: Sep 30 09:49:33.399 CST: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x13D3
    095821: Sep 30 09:49:33.403 CST: //27509/00E60F465903/CCAPI/cc_api_call_disconnect_done:
       Disposition=0, Interface=0x4B7C2F08, Tag=0x0, Call Id=27509,
       Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
    095822: Sep 30 09:49:33.403 CST: //27509/00E60F465903/CCAPI/cc_api_call_disconnect_done:
       Call Disconnect Event Sent
    095823: Sep 30 09:49:33.403 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
    095824: Sep 30 09:49:33.403 CST: :cc_free_feature_vsa freeing 4E1093B0
    095825: Sep 30 09:49:33.403 CST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
    095826: Sep 30 09:49:33.403 CST:  vsacount in free is 0

  • Route Pattern CSV File Removes "0" from Called Party Prefix Digits Field

    I want to upload over 350 route patterns using BAT Tool in CUCM 9.1. All patterns must have their Called Party Prefix Digits (Outgoing Calls) Field containing 10 numbers with the number "0" at the begining. The Problem is the CSV file removes the leading "0" form the digits. I tried to make the cell type in Excel as "Text" and it worked and the "0" is kept normally, but when I save and close the file then open it again, the cell is defaulted to "General" type and the "0" is disappeared again! Changing the CSV file format to any other one and uploading it to CUCM system generates an error stating that the file format is not supported.
    Attached is a sample entry of the CSV file. I want to preserve the whole number "0541234567" in "PREFIX_DIGITS_CALLED_PARTY" Field.
    Anyone can help me how to upload this big number of route patterns while preserving the number "0" at the begining?

    Make sure you change the csv file when using Excel to "Text" on the cell where the string starts with 0, otherwise Excel assumes this is a number and strips it.
    HTH, please rate all useful posts!
    Chris

  • Calling Party Number empty when the call gets to Route List

    Caller id is not showing up on 911 calls.  Using Dialed Number Analyser I can see the calling Party Number fine through the route pattern.  Then in the Route List it comes up empty.  Nothing in the config of the Route List is restricting or manipulating the calling number.  Use calling party's external phone number mask is set to on.  We are using Standard Local Route Groups.
    Thanks in advance for your help.

    Do you see the caller ID on the GW in debugs?
    What type of circuit is used for this call? If PRI can you provide "debug isdn q931"?
    Chris

  • Called party number on phone display - updating with results of translation on GW, not wanted

    Call Manager 9.x, IOS 15.1, H.323 gateways
    Hi, I've got 2 questions regarding the called number display on handsets. Essentially, when a user dials an external number it's obviously shown on their phone handset screen - when that number is manipulated to add prefix for certain PSTN gateways etc. the updated number is shown on the phone display, which the users identify as "not the number I dialled" - can this be changed?
    It a cosmetic issue essentially, but one I am being asked about and can't find an answer to:
    1) I add a prefix on the gateway to the outbound dialled number (to add a carrier code / network function to all calls) - ie, \^9!\ \1666\ - Process looks like this:
    user dials -> 912345
    shows as dialled number on handset -> 912345
    translation-rule on gateway (in IOS) converts number to -> 166612345
    call connected
    user handsets now updated to show dialled number as -> 166612345  (but still wanted it to show 912345)
    2) Another seperate scenario is that I am doing called party transformation on a route pattern - here the modified number is shown instantly on the callers display. Presumably this in unavoidable? Or, can the original number dialled by the user be displayed on their phone, not the modified one?

    Hi,
    any calling or called transformation in the route pattern appears in the screen.
    you can discard the 9 in the route pattern and add prefix 9 in the route list level.
    for the 2nd point there is a service parameter in the call manager to keep the original dialed number
    HTH
    Anas
    don't forget to rate the helpful posts

  • Use External phone Number mask * Calling party Transform Mask @ Route patt

    Having an issue with CLID at RP level. Lets say I have two phones. One phone is configured with an External phone number mask of 1112223333 and the other one does not have an external number mask set. When a call is placed to the PSTN, Phone one needs to display its external phone number mask. Phone two since nothing has been added under external phone mask needs to be 1112224444.
    I configured the RP to "Use External Phone Number mask" and set the Calling Party Transform mask to 1112224444. I figured that if an external phone number mask was specified under the DN that it will route it to the PSTN and if nothing specified under the DN it will default to 1112224444 according to the setting in the RP.
    When I configured this, no matter what I do the calling party transform mask takes priority and the external phone number mask is never used. Is there a way around this? I tried it at the RL level and it does the same thing.
    Does anyone have any other ideas other than adding an external phone number mask for every phone.

    Thats what I thought. Why can't they add that as a feature in the next release of CM? It seems like it could be simple to do. Check for External Phone number mask, if nothing is specified, then check for calling party transform mask. If true set Calling Party transform Mask as CLID and route to RL or something like that..
    thanks

  • Called Party Answer (CPA) / Line Reversal

    Hi - is there any reason why the Called Party Answer (CPA) service can only be applied to Business and not Residential lines. SPM/MPF used to be available on Residential sub's lines - seems weird that its replacement (CPA) can only be activated on Business Lines ?

    monolog99 wrote:
    Hi - is there any reason why the Called Party Answer (CPA) service can only be applied to Business and not Residential lines. SPM/MPF used to be available on Residential sub's lines - seems weird that its replacement (CPA) can only be activated on Business Lines ?
    This is a Customer to Customer forum, so messages do not go to BT.
    I may be able to give you some idea why.
    CPA was a hangover from the days of Strowger mechanical exchanges and was implemented on subsequent exchange designs to maintain compatibility with some legacy products that relied on a physical line reversal to detect when a call was answered.
    Modern equipment, like answering machines, can simply detect the network tones to determine when a call has been answered, so this facility was not implemented on residential lines.
    Some business lines still have legacy equipment connected to them, like older switchboards(PABX), that require line reversal. Also they may have payphones which need this facility.
    So this facility has been retained for business lines until such time as all the legacy equipment has been replaced. From what I remember, this has to happen before full implementation of the 21CN network, whenever that may be.
    I hope that is of some help. Was there any reason why you were asking?
    There are some useful help pages here, for BT Broadband customers only, on my personal website.
    BT Broadband customers - help with broadband, WiFi, networking, e-mail and phones.

  • Route pattern with called party transformations

    HI All,
    i wanto to add route pattern with transformation
    i want to add RP with 9.001! predot
    and want to convert to 9.01017! with called party transformations.
    How we replace ! ? i've tried and it's error with message
    Called Party Transform Mask - allowed characters are numeric (0-9),plus (+),asterisk (*),pound (#),X.
    I've give screen shot for the configuration
    Please anybody help.
    Thanks in advance
    Regards,
    ATommy

    You can create the RP with 9001.! and in the called party, discard predot and prefix 901017.
    see below screenshot:

  • Should calling party name showed up in case it had been previously stored in PAB?

    Hi,
    I have a question related to Personal Address Book
    Cluster version CUCM8.6
    - End users have PAB confiugred
    - can save entries in PAB
    - can dial out from PAB
    In case call comes in - from a caller number had already been stored in user's PAB - should the name also showed up on the LCD screen of the calling party as it is stored in his/her PAB?
    Thanks,
    Tibor

    No, there's no number to name resolution feature in CUCM in any version.

  • CVP call server logs - Hi All, I am trying to figure out whether caller party(End User) hangup the call first or UCCE Agent

    CVP call server logs
     Hi All,
    I am trying to figure out whether caller party(End User) hangup the call first or UCCE Agent.
    Attaching CVP call server Logs& UCCE TCD& Route Call Details for your reference.

    From the CVP logs, it can be determined which side disconnected the call first. For each call, CVP keeps track each call leg. From Inbound Gateway to CVP is INBOUND leg, rest are OUTBOUND leg. You can then look at which leg the SIP BYE message is received first.
    Since you have very basic log enabled, you will not see the exact SIP message. But it can be determined by the outcome of the message. Here is the snippet of the log during the disconnect:
    Line 3766: 3083689: 10.180.245.43: Sep 12 2014 12:21:11.293 -0700: %CVP_8_5_SIP-7-CALL:  {Thrd=DIALOG_CALLBACK.6} CALLGUID = CBCCDD8539E811E4A3E2CCEF48565980 LEGID = CC65CE04-39E811E4-87DFD7D1-64B198F2 - [INBOUND] DURATION (msecs) = 25610 - DIALOG TERMINATED. Reason: Q.850;cause=16
    Line 3768: 3083690: 10.180.245.43: Sep 12 2014 12:21:11.293 -0700: %CVP_8_5_SIP-7-CALL:  {Thrd=DIALOG_CALLBACK.6} Sending BUS MSG:>>HEADERS: (JMSType)=MsgBus:CALL_STATE_EVENT (JMSDestination)=Topic(CVP.SIP.CC.EVENT) (JMSTimestamp)=1410549671293 >>BODY: callguid=CBCCDD8539E811E4A3E2CCEF48565980 RouterCallKey=6472 RouterCallKeySent=true causecode=1 timezone=America/Los_Angeles RouterCallKeySequenceNumber=0 version=CVP_8_5 labeltype=1 RouterCallKeyDay=151099 calldate=Fri Sep 12 12:21:11 PDT 2014 label=190376 localOffset=-420 eventid=6 calllegid=CC65CE04-39E811E4-87DFD7D1-64B198F2  >>STATE: isTabular=false isWriteable=true cursor=-1  
    The first Termination message came on the INBOUND leg which is the PSTN. That means, PSTN side disconnected the call first.
    Hope this helps.
    Abu

  • Caller ID Manipulation based on called party Area Code

                I have a new Sales department and they want to be able to call 6 different areas, in which we have a local presence, and have a local number show up for Caller ID and return calls. I have setup a separate Partition and CSS for these users, which will send calls out our SIP trunk. I need all other calls to show the External Phone Number Mask, as normal
    I have tried using the Calling Party Transformation in the route pattern to achieve this. I've added it to the Sales partition. I also tried using translation patterns. The "
    Use Calling Party's External Phone Number Mask" box is unchecked in both scenarios. I need to get this completed before I brief them on it tomorrow. The External Phone Number Mask field is empty on my test extension. The far end sees the extension of that phone, and not the intended local number.
    Any help?
    Thanks in advance
    - Jonathan Beardsley

    The problem, for me, was that the "Use External Phone  Number Mask" box was checked on teh Route Group, overriding other  changes.
    So, I built separate RG, RL, and Route  Patterns to achieve my goals, applying the Calling Party Transformation  on the Route Pattern, thus applying different CallerID per area code of  called party.
    Thanks!
    - Jonathan Beardsley

  • Redirect Calls Based on Calling Party Number

    Hi All,
    I am looking for a method to redirect inbound PSTN calls based on the calling party number.  I can do this in CUCM 9 or IOS.  I find plenty of documentation out there on blocking calls by calling party number but nothing on redirecting.     
    My situation is this.  We are a large company and often get request from users to block calls from annoying or harassing numbers.  Rather than block them I would like to drive them into a mailbox where the caller can attempt to find a resolution if they feel the calls was blocked in error.
    Has anyone else attempted something like this? 
    Thanks

    Hi Jerold,
    If you are using CUCM 8.x and above, you can re-direct the call on the basis of the calling party number.
    The configuration is very similar to block a call that uses the new feature added in CUCM 8.x and above (
    Route Next Hop By Calling Party Number). The step 8 in the following document explains how to handle the call when the call has be routed by the calling party number. The translation pattern is configure with Route Option as "Block this pattern".
    https://supportforums.cisco.com/docs/DOC-18367
    In order to re-direct the call, you can configure the Route Option with "Route this pattern" and specify the desired destination pattern under "Called party Transformation Mask". Also, make sure to add the appropriate CSS to be able to route the call.
    HTH,
    Jagpreet Singh Barmi

Maybe you are looking for