+ sign in front of called party number

Dear All,
I've created SIP Trunk between CUCM 10.5 and Siemens HiPath 4000.
When I'm dialing from Siemens Ip Phone ( ext. 2200)  it shows 2305 .
But when I'm calling from Cisco Ip phone (ext. 2305)  it shows me +2200 
How can I strip this + sign CUCM?
Thanks in advance
Bahlul

Hi Bahlul,
Do you see the + prefix on any other calls made by Cisco Phones as well?
Can you share the screenshots of the Route pattern and RL that is pointing towards Siemens HiPath from CUCM?
Manish

Similar Messages

  • 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

  • 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

  • Prevent called party number changes on outgoing call to PSTN

    Hello Folks,
    we have CUCM 9.1 with SIP trunks to cisco 2951 connected to the PSTN either by BRI or PRI module.
    we have implemented internal full e.164 (including +) dialplan
    when    we do an outgoing call (via SIP trunk and 2951) the phones first  shows   the full e.164 number i.e. +4970366431002. As soon as the call  goes  out  to the PSTN, the display changes to the number format in  which the  2951  sends the call to the ISDN.
    Because in  ISDN  there  is no +, the gateway translates the called number to (in  this  example)  70366431002 TON national. and sends this back to CUCM in  the  Session  progress Remote-Party-ID value (see output from debug  on the 2951 below)
    how can we prevend that the phone is showing this number instead of the original number?
    thanks a lot - mat
    debug isdn q931
        Calling Party Number i = 0x1081, '497142500290'
            Plan:Unknown, Type:International
        Called Party Number i = 0xA1, '70346431002'
            Plan:ISDN, Type:National
    debug ccsip  messages:
    Sent:
    SIP/2.0 183 Session Progress
    Via: SIP/2.0/TCP 10.1.60.2:5060;branch=z9hG4bK3b5c02cb10b0d
    From: <sip:[email protected]>;tag=3018449~a209bda8-de62-43dc-9e6a-6ebfafc31bde-46236303
    To: <sip:[email protected]>;tag=ED03BF44-10BA
    Date: Mon, 02 Sep 2013 12:41:56 GMT
    Call-ID: [email protected]
    CSeq: 101 INVITE
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    Allow-Events: telephone-event
    Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
    Contact: <sip:[email protected]:5060;transport=tcp>

    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

  • 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

  • Called Party Number when Forwarded Issue

    We have upgraded to 7.1 and our users have alerted us to something interesting and annoying.
    It appears that the Called Number/Name is retained on the Calling Party phone even when the Called Number is;
    Picked Up within a Pickup Group
    Forwards on Busy/No Reply
    Is Transferred to another phone
    This is causing confusion for our users who are used to seeing the called number/name change when it is directed to another phone.
    I am thinking that this could be a bug in CUCM 7.1, I have had a search for any parameter that is new as this was the default behaviour with our previous versions 5.1, 6.0, 6.1 and 7.0.
    I have rebooted our Publisher and 2 x Subscribers as a basic measure to see if this restores the logic but the issue still persists.
    Has anyone else encountered this on their CUCM?
    Regards Kim

    I found the answer;
    Service Parameters => Publisher => Cisco CallManager
    Clusterwide Parameters (Device - General)
    Always Display Original Dialed Number Required Field*
    This was a parameter I have never had to alter in previous versions of CUCM and may be new, I am not sure, setting this to False solves the issue.
    Regards

  • How to dial the  plus sign in front of the phone number when dialing abroad

    iPhone 5:
    When dialling a phone number, the + sign is inactive, and I cannot phone abroad unless I write the number in Contacts, or know the number code of my operator.
    Is there another way ?

    Press and hold the "0" key on the dial pad.

  • 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

  • Help with Calling Party Transformation Patterns

    Hello,I am struggling to figure out how to apply Calling Party Transformation Patterns on CUCM for MGCP gateways.
    Basically, we use MGCP gateway everywhere so I need to apply CPTP on CUCM. However, I know how to do this using a gateway (CME) as an example.
    Below is what I am trying to figure out using CUCM...Here as you can see, if the calling party number is 000xxxx then the calling Party xformation is set to 353xxxx and then egress to PSTN.
    If the calling party number is 111xxxx, then the calling party xformation is set to 454xxxx and then gets sent to the PSTN;
    voice translation-rule 1
    rule 1 /^000\(...\)$/ /353\1/
    rule 2 /^111\(...\)$/ /454\1/
    voice translation-profile OutBound_CallerID
    translate calling 1
    dial-peer voice 101 pots
    destination-pattern 9T
    translation-profile outgoing OutBound_CallerID
    port 0/0/0:15
    The only way I know how to do this is by creating 2 sets of CSS and PTs. Then, create the same route pattern in both (example 9.!) but set the CPTM on each route pattern as 353xxxx on one and 454xxxx on the other. Then by putting some of the phones with one CSS and some with the other it will work. This is not ideal as I need to be able to do it before matching the Route Patterns and I need all phones to use the same CSS.
    Is there a better way?
    Thanks

    @Anas, thanks for the response, great answer.One question. When creating 'Calling Party Transformation Patterns' should the pattern be the original calling party number i.e 111XXXX.
    For example, in the below screenshot will CUCM match the pattern if extension 111XXXX tries to make an outbound call?
    So the call flow on CUCM goes:
    Ext 111XXXX makes call > Route Pattern>RouteList>ROuteGRoup> Gateway>CPT CSS Applied matching below rule which changes Calling PT to 454XXXX > PSTN
    Would that be correct?
    Thanks.

  • 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

  • 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

  • Where is   sign when you call international number, but first you call local number and after connect open keyboard and see that sign   doesn't exist only 0

    Where is   sign when you call international number, but first you call local number and after connect open keyboard and see that sign   doesn't exist only 0

    No that is not work. Try to call some number and when is connect click on keyboard and you can see that sign "+" doesn't exist.
    So I use local number, when I'm connect I have option to call international number but like "+3193675xxxx" how I can put?
    Before on iOS 6 I do it.

  • Lync 2013 not hear ring back in mobile when call by number

    Hi,
    I have setup a Lync server 2013 standard Front end on windows server 2012 R2 and also installed update for Mobility service and enabled it. It seems everything works perfect but...
    When I call by number in android phones and iphones, I do not hear ring back tone, although call is proceeded and if the calling person answer the call, everything will be fine. The strange thing is that if I call by name I hear ring back
    tone.
    This problem does not exist while using windows phone or desktop client.
    Thanks, Amir.

    Early media refers to media (e.g., audio and video) that is exchanged  before a particular session is accepted by the called user.
    If the remote party does not generate it, then you will not hear it. As stated by Holger, the logs will have this information. Without the logs it is not possible to identify where the problem is. Your app might have received it and not played it or it was
    never send.
    Regards Herbert Zimbizi

  • Minus Sign in front

    Hello all,
    I have a requirement where in I need to bring the minus sign in front for the amount field in ALV Grid Display.
    I used the FM CLOI_PUT_SIGN_IN_FRONT, but after I pass back the values, the sign gets set at the end. Moreover, I cannot create a character filed because the business might want to do sum on it.
    Please advice.
    Regards,
    Salil
    P.S. the below piece of code
    DATA : gv_bill_rev  TYPE string,
             gv_balance   TYPE string.
      LOOP AT gt_master INTO gs_master.
        gv_bill_rev = gs_master-bill_rev.
        gv_balance  = gs_master-balance.
        CLEAR : gs_master-bill_rev,gs_master-balance.
        CALL FUNCTION 'CLOI_PUT_SIGN_IN_FRONT'
          CHANGING
            value = gv_bill_rev.
        CALL FUNCTION 'CLOI_PUT_SIGN_IN_FRONT'
          CHANGING
            value = gv_balance.
        MOVE : gv_bill_rev TO gs_master-bill_rev,
               gv_balance  TO gs_master-balance.
        MODIFY gt_master FROM gs_master INDEX sy-tabix
                                        TRANSPORTING bill_rev balance.

    You can directly specify an edit mask for output.
    Field EDIT_MASK in the field catalog is a 60 character field in which you can specify an edit mask.
    fieldcat-edit_mask = 'V___.__'
    The V at the left indicates that you want the sign to appear at the left.  The _ will be replaced by the values of the number.  Put as many underscores as required.  You may also want to specify commas (,), if desired, for thousand's separators and a period (.) for the decimal point, if needed.
    Alterntively, if an appropriate conversion exit exists to put the sign in front, you can assign the conversion exit in the field catalog table.
    Field CONVEXIT in the field catalog can be used to specify the name of the conversion exit.
    Brian
    Edited by: Brian Sammond on Jan 27, 2009 8:08 PM
    Simplfy example edit mask because forum was displaying it funny

  • 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

Maybe you are looking for

  • Is there a way to make firefox open hyperlinks to local files?

    My company has a custom developed ticketing system and of course its developed for IE but none of the engineers like IE. We all use and want to continue using Firefox. One of the sections in the ticketing system has a spot for links to local files on

  • How can I get my iBook on the feature page?

    Is there a fee or way to be on the feature page of iBooks?

  • Date Presentation variable

    Hi, If Date presentation variable (with between operator) returning two values, how to call the first value specifically... thanks in advance. Siva Prasad

  • Camera raw on a 4K Monitor (CC 2014.1)

    I've downloaded the trial of Photoshop CC today with a view to taking out a subscription having bought a 4K Monitor (using with Windows 8) - my problem is that while Photoshop CC itself has the very helpful scale UI to 200% option in experimental fea

  • The choice of the programming language

    Hi everyone, The right programming language in the right place. What are according to you the criteria that can help you to decide which programming language you should use to program an application or a system? Why should you use for example Java in