Translation-pattern delay to outbound call
Hello,
I config one translation-pattern: 1234 tanslation to one mobile number (call ouside to PSTN via E1 link)
and also config T302 time value = 5000 (default 15000)
When I dial 1234, I will get a dial-tone, then waiting 5 second -> the call active.
Is it normally?
Or what could I do to resolve it?
Thanks.
What you are experiencing is expected, this is what is called Inter-digit time out. What is happening is that within your dial plan there is another pattern (could be another Translation Pattern, DN or Route Pattern) starting with "0".
The following Cisco document explains this behavior:
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/6171-interdigit-timeout.html
Now going back to your concern and moving forward with the explanation, the Unified Communications Manager Platform is designed to route calls based on the closest match. When you dial "0" since there is another pattern starting also with 0 in your dial plan then, CUCM will wait for more digits. It is not until the T302 timer (that the document above mentions) expires that CUCM routes the call based on the order of the partitions set or configure on the routing device (in your scenario it is going to be the CSS of the Translation Pattern)
You will be able to check there is an over-lapping pattern within your system by going (in the Administration page for Call Manager) to Call Routing > Route Plan Report and:
1) Type 0 on the search bar and hit search and all the results starting with 0 should display.
Or
2) Exporting your dial plan to a .csv file, open it with excel and apply filters to find the overlapping problem.
You can also reduce the T302 timer from the Call Manager service parameters from the default value (15 seconds) to a minimum of 3 seconds.
Hope this information helps
Similar Messages
-
Translation Pattern - X wildcard not working.
I am trying to translate any calls from a certain CSS to extension 4900-4999 to a single extension (8114). I tried using 49XX as the
Translation Pattern, 8114 as the Called Party Transform Mask, and the partiton for this is the first in the CSS list. This is not working...it just calls directly to the dialed extention (4950), but if I change the Translation Pattern to 4950 it works just fine (goes to 8114 like desired). The partition 4950 is located in is halfway down the list in the CSS. Is there a particular reason the X wildcard is not working in this instance?Everything is working as expected based on your configuration, CUCM uses best match routing.
I can already tell your CSS has access to both, 4950 and 49XX, thus,it's all working fine.
4950 is one match
49XX 100 matches
4950 is the best match.
CSS order only matters when there's 2 or more patterns with the same number of matches. Only THEN, which CSS is on top, will matter.
You need to remove access to the DNs directly and leave only the TP.
HTH
java
if this helps, please rate
www.cisco.com/go/pdihelpdesk -
Need help Creating a translation pattern that adds dial out digits to incoming calls
I came across an article yesterday and it showed the steps how to fix Missed Call/Received Call numbers so that you can dial them from the menu correctly (auto-add a 9, etc.)?
I tried it this morning and came up with this translation pattern:
voice translation-rule 6
rule 1 /^201\(.*\)/ /8\1/
rule 2 /\(..........\)/ /81\1/
voice translation-profile filter_Incoming
translate calling 6
This translation pattern rule 1 adds the dial out character 8 and strips 201 for local calls. Rule 2 adds dial out character 8 and adds 1 for long distance. The purpose of this translation rule is when the ephone receives the phone call the characters 8 and 1 are added so when you quickly need to redial you do not have to edit the number and add 8 for each call.
I tested the translation-rule:
ROUTER-2911#test voice translation-rule 6 9082121231
Matched with rule 2
Original number: 9082121231 Translated number: 819082121231
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none
ROUTER-2911#test voice translation-rule 6 2019121231
Matched with rule 1
Original number: 2019121231 Translated number: 89121231
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none
ROUTER-2911#
Issue is I am not sure with my inbound call leg if it can even work. We dial out through the SIP Trunk and the incoming is translated to the AutoAttendant on Cisco Unity Express.
voice translation-rule 1
rule 1 /2015552100/ /2003/
voice translation-profile CUE_Voicemail/AutoAttendant
translate called 1
dial-peer voice 9 voip
description **Incoming Call from SIP Trunk**
translation-profile incoming CUE_Voicemail/AutoAttendant
call-block translation-profile incoming BLOCKED-INCOMING
call-block disconnect-cause incoming call-reject
session protocol sipv2
session target dns:nd01-04.fs.SIPPROVIDER.net
incoming called-number .%
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
dtmf-relay rtp-nte
no vad
Can what I am trying to do be done with my current setup?Hi patldmart012,
The dial-peer 9 that you have attached will not be affected by following config
voice translation-rule 6
rule 1 /^201\(.*\)/ /8\1/
rule 2 /\(..........\)/ /81\1/
voice translation-profile filter_Incoming
translate calling 6
Because you have not applied the translation profile "filter_incoming" on the dial-peer.
Could you please provide the exact call flow?
Along with that, If you are facing issue with calls on SIP Trunk, please collect following debugs in a logging buffer and attach the file. I will analyse it and will get back to you.
debug voip ccapi inout
debug ccsip message
debug voice translation
Debug h225 asn1 (If H323 involved)
Debug h245 asn1 (If H323 involved)
Debug MGCP Packets (If MGCP involved)
Also provide the running config of the GW.
These are verbose debugs, so please collect them in the following manner:
Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 30000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router# Clear log
Router# term no mon
<Enable debugs, then wait for issue to occur.>
Router# term len 0
<Enable session capture to txt file in terminal program.>
Router# Undebug all
Router# sh log
Once i have the logs, i will analyse it and will get back to you.
Regards,
Mudit Mathur -
Call to translation pattern took longer to reach the translated DN
I translated 0 > 9000 which is pilot number for CUACE, noticed when press 0 to dial using particular CSS it's taking a few seconds before the call translated to 9000 and hear the ringing tone.
Which part to check on this?
ThanksWhat you are experiencing is expected, this is what is called Inter-digit time out. What is happening is that within your dial plan there is another pattern (could be another Translation Pattern, DN or Route Pattern) starting with "0".
The following Cisco document explains this behavior:
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/6171-interdigit-timeout.html
Now going back to your concern and moving forward with the explanation, the Unified Communications Manager Platform is designed to route calls based on the closest match. When you dial "0" since there is another pattern starting also with 0 in your dial plan then, CUCM will wait for more digits. It is not until the T302 timer (that the document above mentions) expires that CUCM routes the call based on the order of the partitions set or configure on the routing device (in your scenario it is going to be the CSS of the Translation Pattern)
You will be able to check there is an over-lapping pattern within your system by going (in the Administration page for Call Manager) to Call Routing > Route Plan Report and:
1) Type 0 on the search bar and hit search and all the results starting with 0 should display.
Or
2) Exporting your dial plan to a .csv file, open it with excel and apply filters to find the overlapping problem.
You can also reduce the T302 timer from the Call Manager service parameters from the default value (15 seconds) to a minimum of 3 seconds.
Hope this information helps -
Phone won't make outbound calls. can't call verizon support. this after being on hold for 17 minutes in an attempt to fix voicemail notification. this is a nightmare and Verizon is unreachable. Any way to get Verizon wireless to fix my service when they can't be called (because their phone service doesn't work)?
Well 1, I guess it's not that important to you, 2, customer support generally closes at 11pm in the time zone you are in, 3, toll free and local calls are free in hotels, 4 there is limited support after hours.
-
Outbound call failing with cause code 57
Hi,
our outbound calls to some numbers getting failed with cause code 57 and in ccsip messages i am getting 403 forbidden.
i tried to change the payload type to 97 which was 98 but no success.
the called number is 9-8955900
the calling number is 8062300
can any one help me..
the ccsip messages and ccapi inout debug is..
509022: *Jan 8 14:23:20.513: :FEATURE_VSA attributes are: feature_name:0,featur e_time:1255632752,feature_id:53127
509023: *Jan 8 14:23:20.513: //678454/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPr ivate:
SPI Call Setup Request Is Success; Interface Type=9, FlowMode=1
509024: *Jan 8 14:23:20.513: //678454/xxxxxxxxxxxx/CCAPI/ccCallSetContext:
Context=0x4AC5D304
509025: *Jan 8 14:23:20.517: //678454/xxxxxxxxxxxx/CCAPI/cc_api_call_connected:
Interface=0x48D4E620, Data Bitmask=0x0, Progress Indication=NULL(0),
Connection Handle=0
509026: *Jan 8 14:23:20.517: //678454/xxxxxxxxxxxx/CCAPI/cc_api_call_connected:
Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
509027: *Jan 8 14:23:20.537: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.12.190:5060;branch=z9hG4bK6aded64034252
From: "Asif CIPC" <sip:[email protected]>;tag=2524413~70e9433b-1d79-44ae-9a16- 09a52be377c5-22878662
To: <sip:[email protected]>
Date: Wed, 08 Jan 2014 14:02:15 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Cisco-Guid: 2031538944-0000065536-0000027607-3188500672
Session-Expires: 1800
P-Asserted-Identity: "Asif CIPC" <sip:[email protected]>
Remote-Party-ID: "Asif CIPC" <sip:[email protected]>;party=calling;screen=yes; privacy=off
Contact: <sip:[email protected]:5060;transport=tcp>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 240
v=0
o=CiscoSystemsCCM-SIP 2524413 1 IN IP4 192.168.12.190
s=SIP Call
c=IN IP4 192.168.33.5
t=0 0
m=audio 17706 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
509028: *Jan 8 14:23:20.553: //-1/7916D3000000/CCAPI/cc_api_display_ie_subfield s:
cc_api_call_setup_ind_common:
cisco-username=3064
----- ccCallInfo IE subfields -----
cisco-ani=3064
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=8955900
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
509029: *Jan 8 14:23:20.553: /
ASICO-DAM#/-1/7916D3000000/CCAPI/cc_api_call_setup_ind_common:
Interface=0x48667600, Call Info(
Calling Number=3064,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=8955900(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=T RUE,
Incoming Dial-peer=1, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALS E), Call Id=678455
509030: *Jan 8 14:23:20.553: //-1/7916D3000000/CCAPI/ccCheckClipClir:
In: Calling Number=3064(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pre sentation=Allowed)
509031: *Jan 8 14:23:20.553: //-1/7916D3000000/CCAPI/ccCheckClipClir:
Out: Calling Number=3064(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pr esentation=Allowed)
509032: *Jan 8 14:23:20.553: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509033: *Jan 8 14:23:20.553: :cc_get_feature_vsa malloc success
509034: *Jan 8 14:23:20.553: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509035: *Jan 8 14:23:20.553: cc_get_feature_vsa count is 13
509036: *Jan 8 14:23:20.553: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509037: *Jan 8 14:23:20.553: :FEATURE_VSA attributes are: feature_name:0,featur e_time:1255634768,feature_id:53128
509038: *Jan 8 14:23:20.553: //678455/7916D3000000/CCAPI/cc_api_call_setup_ind_ common:
Set Up Event Sent;
Call Info(Calling Number=3064(TON=Unknown, NPI=Unknown, Screening=User, Passe d, Presentation=Allowed),
Called Number=8955900(TON=Unknown, NPI=Unknown))
509039: *Jan 8 14:23:20.557: //678455/7916D3000000/CCAPI/cc_process_call_setup_ ind:
Event=0x48EE6200
509040: *Jan 8 14:23:20.557: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 8955900
509041: *Jan 8 14:23:20.561: //678455/7916D3000000/CCAPI/ccCallSetContext:
Context=0x476E35D0
509042: *Jan 8 14:23:20.561: //678455/7916D3000000/CCAPI/cc_process_call_setup_ ind:
>>>>CCAPI handed cid 678455 with tag 1 to app "_ManagedAppProcess_Default"
509043: *Jan 8 14:23:20.561: //678455/7916D3000000/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)
509044: *Jan 8 14:23:20.565: //678455/7916D3000000/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=20, Params=0x476E4AE0, Progress Indication=NULL(0)
509045: *Jan 8 14:23:20.565: //678455/7916D3000000/CCAPI/ccCheckClipClir:
In: Calling Number=8062301(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
509046: *Jan 8 14:23:20.565: //678455/7916D3000000/CCAPI/ccCheckClipClir:
Out: Calling Number=8062301(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
509047: *Jan 8 14:23:20.565: //678455/7916D3000000/CCAPI/ccCallSetupRequest:
Destination Pattern=.T, Called Number=8955900, Digit Strip=FALSE
509048: *Jan 8 14:23:20.565: //678455/7916D3000000/CCAPI/ccCallSetupRequest:
Calling Number=8062301(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pres entation=Allowed),
Called Number=8955900(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=Asif CIPC
Account Number=3064, Final Destination Flag=TRUE,
Guid=7916D300-0001-0000-0000-6BD7BE0CA8C0, Outgoing Dial-peer=20
509049: *Jan 8 14:23:20.565: //678455/7916D3000000/CCAPI/cc_api_display_ie_subf ields:
ccCallSetupRequest:
cisco-username=3064
----- ccCallInfo IE subfields -----
cisco-ani=8062301
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=8955900
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
509050: *Jan 8 14:23:20.569: //678455/7916D3000000/CCAPI/ccIFCallSetupRequestPr ivate:
Interface=0x48667600, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=8062301,(Calling Name=Asif CIPC)(TON=Unknown, NPI= Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=8955900(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=20 , Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Appl ication Call Id=)
509051: *Jan 8 14:23:20.569: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509052: *Jan 8 14:23:20.569: :cc_get_feature_vsa malloc success
509053: *Jan 8 14:23:20.569: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509054: *Jan 8 14:23:20.569: cc_get_feature_vsa count is 14
509055: *Jan 8 14:23:20.569: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509056: *Jan 8 14:23:20.569: :FEATURE_VSA attributes are: feature_name:0,featur e_time:1255629840,feature_id:53129
509057: *Jan 8 14:23:20.569: //678456/7916D3000000/CCAPI/ccIFCallSetupRequestPr ivate:
SPI Call Setup Request Is Success; Interface Type=3, FlowMode=1
509058: *Jan 8 14:23:20.573: //678456/7916D3000000/CCAPI/ccCallSetContext:
Context=0x476E4A90
509059: *Jan 8 14:23:20.573: //678455/7916D3000000/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=20
509060: *Jan 8 14:23:20.577: //678456/7916D3000000/CCAPI/cc_api_call_proceeding :
Interface=0x48667600, Progress Indication=NULL(0)
509061: *Jan 8 14:23:20.585: //678456/7916D3000000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 172..XX.XX.XX:5060;branch=z9hG4bK67CD11AE
Remote-Party-ID: "Asif CIPC" <sip:[email protected]>;party=calling;screen=ye s;privacy=off
From: "Asif CIPC" <sip:[email protected]>;tag=EA475228-24AE
To: <sip:[email protected]>
Date: Wed, 08 Jan 2014 14:23:20 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2031538944-0000065536-0000027607-3188500672
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIF Y, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1389191000
Contact: <sip:[email protected]:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 274
v=0
o=CiscoSystemsSIP-GW-UserAgent 5380 1731 IN IP4 172..XX.XX.XX
s=SIP Call
c=IN IP4 172..XX.XX.XX
t=0 0
m=audio 19502 RTP/AVP 18 101
c=IN IP4 172..XX.XX.XX
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
509062: *Jan 8 14:23:20.589: //678455/7916D3000000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.12.190:5060;branch=z9hG4bK6aded64034252
From: "Asif CIPC" <sip:[email protected]>;tag=2524413~70e9433b-1d79-44ae-9a16- 09a52be377c5-22878662
To: <sip:[email protected]>
Date: Wed, 08 Jan 2014 14:23:20 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow-Events: kpml, telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
509063: *Jan 8 14:23:20.605: //678456/7916D3000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172..XX.XX.XX:5060;branch=z9hG4bK67CD11AE
Call-ID: [email protected]
From: "Asif CIPC"<sip:[email protected]>;tag=EA475228-24AE
To: <sip:[email protected]>
CSeq: 101 INVITE
Content-Length: 0
509064: *Jan 8 14:23:20.677: //678456/7916D3000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 172..XX.XX.XX:5060;branch=z9hG4bK67CD11AE
Record-Route: <sip:10.205.20.50:5060;transport=udp;lr>
Call-ID: [email protected]
From: "Asif CIPC"<sip:[email protected]>;tag=EA475228-24AE
To: <sip:[email protected]>;tag=sbc0804k7h28358
CSeq: 101 INVITE
Reason: Q.850;cause=57;text="bearer capability not authorized"
Warning: 399 - "SoftX3000 R601-CCU Rel POS:[3103] Release from CR"
Content-Length: 0
509065: *Jan 8 14:23:20.677: //678456/7916D3000000/CCAPI/cc_api_call_disconnect ed:
Cause Value=57, Interface=0x48667600, Call Id=678456
509066: *Jan 8 14:23:20.677: //678456/7916D3000000/CCAPI/cc_api_call_disconnect ed:
Call Entry(Responsed=TRUE, Cause Value=57, Retry Count=0)
509067: *Jan 8 14:23:20.681: //678455/7916D3000000/CCAPI/ccCallReleaseResources :
release reserved xcoding resource.
509068: *Jan 8 14:23:20.681: //678456/7916D3000000/CCAPI/ccCallSetAAA_Accountin g:
Accounting=0, Call Id=678456
509069: *Jan 8 14:23:20.681: //678456/7916D3000000/CCAPI/ccCallDisconnect:
Cause Value=57, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect C ause=57)
509070: *Jan 8 14:23:20.681: //678456/7916D3000000/CCAPI/ccCallDisconnect:
Cause Value=57, Call Entry(Responsed=TRUE, Cause Value=57)
509071: *Jan 8 14:23:20.681: //678456/7916D3000000/CCAPI/cc_api_call_disconnect _done:
Disposition=0, Interface=0x48667600, Tag=0x0, Call Id=678456,
Call Entry(Disconnect Cause=57, Voice Class Cause Code=0, Retry Count=0)
509072: *Jan 8 14:23:20.685: //678456/7916D3000000/CCAPI/cc_api_call_disconnect _done:
Call Disconnect Event Sent
509073: *Jan 8 14:23:20.685: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
509074: *Jan 8 14:23:20.685: :cc_free_feature_vsa freeing 4AD76408
509075: *Jan 8 14:23:20.685: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
509076: *Jan 8 14:23:20.685: vsacount in free is 13
509077: *Jan 8 14:23:20.685: //678455/7916D3000000/CCAPI/ccCallDisconnect:
Cause Value=57, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect C ause=0)
509078: *Jan 8 14:23:20.689: //678455/7916D3000000/CCAPI/ccCallDisconnect:
Cause Value=57, Call Entry(Responsed=TRUE, Cause Value=57)
509079: *Jan 8 14:23:20.693: //678455/7916D3000000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 403 Forbidden
Via: SIP/2.0/TCP 192.168.12.190:5060;branch=z9hG4bK6aded64034252
From: "Asif CIPC" <sip:[email protected]>;tag=2524413~70e9433b-1d79-44ae-9a16- 09a52be377c5-22878662
To: <sip:[email protected]>;tag=EA475298-106E
Date: Wed, 08 Jan 2014 14:23:20 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow-Events: kpml, telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=57
Content-Length: 0
509080: *Jan 8 14:23:20.693: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 172..XX.XX.XX:5060;branch=z9hG4bK67CD11AE
From: "Asif CIPC" <sip:[email protected]>;tag=EA475228-24AE
To: <sip:[email protected]>;tag=sbc0804k7h28358
Date: Wed, 08 Jan 2014 14:23:20 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0
509081: *Jan 8 14:23:20.709: //678454/xxxxxxxxxxxx/CCAPI/ccCallDisconnect:
Cause Value=0, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Ca use=0)
509082: *Jan 8 14:23:20.709: //678454/xxxxxxxxxxxx/CCAPI/ccCallDisconnect:
Cause Value=0, Call Entry(Responsed=TRUE, Cause Value=0)
509083: *Jan 8 14:23:20.709: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.12.190:5060;branch=z9hG4bK6aded64034252
From: "Asif CIPC" <sip:[email protected]>;tag=2524413~70e9433b-1d79-44ae-9a16- 09a52be377c5-22878662
To: <sip:[email protected]>;tag=EA475298-106E
Date: Wed, 08 Jan 2014 14:02:15 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence
Content-Length: 0
509084: *Jan 8 14:23:20.713: //678455/7916D3000000/CCAPI/cc_api_call_disconnect _done:
Disposition=0, Interface=0x48667600, Tag=0x0, Call Id=678455,
Call Entry(Disconnect Cause=57, Voice Class Cause Code=0, Retry Count=0)
509085: *Jan 8 14:23:20.717: //678455/7916D3000000/CCAPI/cc_api_call_disconnect _done:
Call Disconnect Event Sent
509086: *Jan 8 14:23:20.717: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
509087: *Jan 8 14:23:20.717: :cc_free_feature_vsa freeing 4AD77748
509088: *Jan 8 14:23:20.717: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
509089: *Jan 8 14:23:20.717: vsacount in free is 12
509090: *Jan 8 14:23:20.721: //678454/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnect _done:
Disposition=0, Interface=0x48D4E620, Tag=0x0, Call Id=678454,
Call Entry(Disconnect Cause=0, Voice Class Cause Code=0, Retry Count=0)
509091: *Jan 8 14:23:20.721: //678454/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnect _done:
Call Disconnect Event Sent
509092: *Jan 8 14:23:20.721: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
509093: *Jan 8 14:23:20.721: :cc_free_feature_vsa freeing 4AD76F68
509094: *Jan 8 14:23:20.721: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
509095: *Jan 8 14:23:20.721: vsacount in free is 11
509096: *Jan 8 14:23:20.725: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivat e:
Interface=0x48D4E620, Interface Type=9, Destination=0.0.0.0, Mode=0x0,
Call Params(Calling Number=,(Calling Name=)(TON=Unknown, NPI=Unknown, Screeni ng=Not Screened, Presentation=Allowed),
Called Number=(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=, FinalDestinationFlag=FALSE, Outgoing Dial-peer=0, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Appl ication Call Id=)
509097: *Jan 8 14:23:20.725: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509098: *Jan 8 14:23:20.725: :cc_get_feature_vsa malloc success
509099: *Jan 8 14:23:20.725: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509100: *Jan 8 14:23:20.729: cc_get_feature_vsa count is 12
509101: *Jan 8 14:23:20.729: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509102: *Jan 8 14:23:20.729: :FEATURE_VSA attributes are: feature_name:0,featur e_time:1255632752,feature_id:53130
509103: *Jan 8 14:23:20.729: //678457/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPr ivate:
SPI Call Setup Request Is Success; Interface Type=9, FlowMode=1
509104: *Jan 8 14:23:20.729: //678457/xxxxxxxxxxxx/CCAPI/ccCallSetContext:
Context=0x4AC5D1C4
509105: *Jan 8 14:23:20.729: //678457/xxxxxxxxxxxx/CCAPI/cc_api_call_connected:
Interface=0x48D4E620, Data Bitmask=0x0, Progress Indication=NULL(0),
Connection Handle=0
509106: *Jan 8 14:23:20.729: //678457/xxxxxxxxxxxx/CCAPI/cc_api_call_connected:
Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
509107: *Jan 8 14:23:20.753: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.12.190:5060;branch=z9hG4bK6adee3e42a498
From: "Asif CIPC" <sip:[email protected]>;tag=2524415~70e9433b-1d79-44ae-9a16- 09a52be377c5-22878662
To: <sip:[email protected]>
Date: Wed, 08 Jan 2014 14:02:15 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Cisco-Guid: 2031538944-0000065536-0000027608-3188500672
Session-Expires: 1800
P-Asserted-Identity: "Asif CIPC" <sip:[email protected]>
Remote-Party-ID: "Asif CIPC" <sip:[email protected]>;party=calling;screen=yes; privacy=off
Contact: <sip:[email protected]:5060;transport=tcp>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 240
v=0
o=CiscoSystemsCCM-SIP 2524415 1 IN IP4 192.168.12.190
s=SIP Call
c=IN IP4 192.168.33.5
t=0 0
m=audio 17932 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
509108: *Jan 8 14:23:20.769: //-1/7916D3000000/CCAPI/cc_api_display_ie_subfield s:
cc_api_call_setup_ind_common:
cisco-username=3064
----- ccCallInfo IE subfields -----
cisco-ani=3064
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=8955900
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
509109: *Jan 8 14:23:20.769: //-1/7916D3000000/CCAPI/cc_api_call_setup_ind_comm on:
Interface=0x48667600, Call Info(
Calling Number=3064,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=8955900(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=T RUE,
Incoming Dial-peer=1, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALS E), Call Id=678458
509110: *Jan 8 14:23:20.769: //-1/7916D3000000/CCAPI/ccCheckClipClir:
In: Calling Number=3064(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pre sentation=Allowed)
509111: *Jan 8 14:23:20.773: //-1/7916D3000000/CCAPI/ccCheckClipClir:
Out: Calling Number=3064(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pr esentation=Allowed)
509112: *Jan 8 14:23:20.773: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509113: *Jan 8 14:23:20.773: :cc_get_feature_vsa malloc success
509114: *Jan 8 14:23:20.773: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509115: *Jan 8 14:23:20.773: cc_get_feature_vsa count is 13
509116: *Jan 8 14:23:20.773: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509117: *Jan 8 14:23:20.773: :FEATURE_VSA attributes are: feature_name:0,featur e_time:1255634768,feature_id:53131
509118: *Jan 8 14:23:20.773: //678458/7916D3000000/CCAPI/cc_api_call_setup_ind_ common:
Set Up Event Sent;
Call Info(Calling Number=3064(TON=Unknown, NPI=Unknown, Screening=User, Passe d, Presentation=Allowed),
Called Number=8955900(TON=Unknown, NPI=Unknown))
509119: *Jan 8 14:23:20.773: //678458/7916D3000000/CCAPI/cc_process_call_setup_ ind:
Event=0x48EE6200
509120: *Jan 8 14:23:20.777: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 8955900
509121: *Jan 8 14:23:20.777: //678458/7916D3000000/CCAPI/ccCallSetContext:
Context=0x476D5190
509122: *Jan 8 14:23:20.777: //678458/7916D3000000/CCAPI/cc_process_call_setup_ ind:
>>>>CCAPI handed cid 678458 with tag 1 to app "_ManagedAppProcess_Default"
509123: *Jan 8 14:23:20.777: //678458/7916D3000000/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)
509124: *Jan 8 14:23:20.781: //678458/7916D3000000/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=20, Params=0x476DCE60, Progress Indication=NULL(0)
509125: *Jan 8 14:23:20.781: //678458/7916D3000000/CCAPI/ccCheckClipClir:
In: Calling Number=8062301(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
509126: *Jan 8 14:23:20.781: //678458/7916D3000000/CCAPI/ccCheckClipClir:
Out: Calling Number=8062301(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
509127: *Jan 8 14:23:20.785: //678458/7916D3000000/CCAPI/ccCallSetupRequest:
Destination Pattern=.T, Called Number=8955900, Digit Strip=FALSE
509128: *Jan 8 14:23:20.785: //678458/7916D3000000/CCAPI/ccCallSetupRequest:
Calling Number=8062301(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pres entation=Allowed),
Called Number=8955900(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=Asif CIPC
Account Number=3064, Final Destination Flag=TRUE,
Guid=7916D300-0001-0000-0000-6BD8BE0CA8C0, Outgoing Dial-peer=20
509129: *Jan 8 14:23:20.785: //678458/7916D3000000/CCAPI/cc_api_display_ie_subf ields:
ccCallSetupRequest:
cisco-username=3064
----- ccCallInfo IE subfields -----
cisco-ani=8062301
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=8955900
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
509130: *Jan 8 14:23:20.785: //678458/7916D3000000/CCAPI/ccIFCallSetupRequestPr ivate:
Interface=0x48667600, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=8062301,(Calling Name=Asif CIPC)(TON=Unknown, NPI= Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=8955900(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=20 , Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Appl ication Call Id=)
509131: *Jan 8 14:23:20.785: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509132: *Jan 8 14:23:20.785: :cc_get_feature_vsa malloc success
509133: *Jan 8 14:23:20.785: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509134: *Jan 8 14:23:20.785: cc_get_feature_vsa count is 14
509135: *Jan 8 14:23:20.785: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
509136: *Jan 8 14:23:20.785: :FEATURE_VSA attributes are: feature_name:0,featur e_time:1255629840,feature_id:53132
509137: *Jan 8 14:23:20.789: //678459/7916D3000000/CCAPI/ccIFCallSetupRequestPr ivate:
SPI Call Setup Request Is Success; Interface Type=3, FlowMode=1
509138: *Jan 8 14:23:20.789: //678459/7916D3000000/CCAPI/ccCallSetContext:
Context=0x476DCE10
509139: *Jan 8 14:23:20.789: //678458/7916D3000000/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=20
509140: *Jan 8 14:23:20.793: //678459/7916D3000000/CCAPI/cc_api_call_proceeding :
Interface=0x48667600, Progress Indication=NULL(0)
509141: *Jan 8 14:23:20.801: //678459/7916D3000000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 172..XX.XX.XX:5060;branch=z9hG4bK67CE197B
Remote-Party-ID: "Asif CIPC" <sip:[email protected]>;party=calling;screen=ye s;privacy=off
From: "Asif CIPC" <sip:[email protected]>;tag=EA475304-26C5
To: <sip:[email protected]>
Date: Wed, 08 Jan 2014 14:23:20 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2031538944-0000065536-0000027608-3188500672
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIF Y, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1389191000
Contact: <sip:[email protected]:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 274
v=0
o=CiscoSystemsSIP-GW-UserAgent 9218 9584 IN IP4 172..XX.XX.XX
s=SIP Call
c=IN IP4 172..XX.XX.XX
t=0 0
m=audio 16868 RTP/AVP 18 101
c=IN IP4 172..XX.XX.XX
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
509142: *Jan 8 14:23:20.805: //678458/7916D3000000/SIP/Msg/ccsipDisplayMsg:
Sent:
509163: *Jan 8 14:23:20.945: //678458/7916D3000000/CCAPI/cc_api_call_disconnect _done:
Call Disconnect Event Sent
509164: *Jan 8 14:23:20.945: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
509165: *Jan 8 14:23:20.945: :cc_free_feature_vsa freeing 4AD77748
509166: *Jan 8 14:23:20.945: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
509167: *Jan 8 14:23:20.945: vsacount in free is 12
509168: *Jan 8 14:23:32.517: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:172..XX.XX.XX:5060 SIP/2.0
Via: SIP/2.0/UDP 10.205.20.50:5060;branch=z9hG4bKhs8ak5845ch42p7cff35k1ap3T02677
Call-ID: isbchh12748fcsk155w58p151kks36fww24s@SoftX3000
From: <sip:172..XX.XX.XX:5060>;tag=sbc0806pa8fp7w7
To: <sip:172..XX.XX.XX>
CSeq: 1 OPTIONS
Max-Forwards: 70
Content-Length: 0
509169: *Jan 8 14:23:32.525: //678460/495AB05FB187/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.205.20.50:5060;branch=z9hG4bKhs8ak5845ch42p7cff35k1ap3T02677
From: <sip:172..XX.XX.XX:5060>;tag=sbc0806pa8fp7w7
To: <sip:172..XX.XX.XX>;tag=EA4780CC-582
Date: Wed, 08 Jan 2014 14:23:32 GMT
Call-ID: isbchh12748fcsk155w58p151kks36fww24s@SoftX3000
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIF Y, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 170
v=0
o=CiscoSystemsSIP-GW-UserAgent 8937 2437 IN IP4 172..XX.XX.XX
s=SIP Call
c=IN IP4 192.168.33.5
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3
c=IN IP4 192.168.33.5
u all
and the config is
voice service voip
ip address trusted list
ipv4 172.XX.XX.XX 255.255.255.255
dtmf-interworking rtp-nte
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
no supplementary-service h225-notify cid-update
redirect ip2ip
h323
session transport udp
h245 tunnel disable
sip
session transport tcp
rel1xx disable
registrar server expires max 3600 min 3500
transport switch udp tcp
redirect contact order best-match
asymmetric payload full
g729 annexb-all
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
codec preference 4 g729br8
and the dial-peer through the calls will go out is
dial-peer voice 20 voip
description ***TO-OUT***
translation-profile outgoing OUT-SIP
destination-pattern .T
progress_ind progress enable 8
rtp payload-type cisco-codec-fax-ack 112
rtp payload-type nte 97
session protocol sipv2
session target ipv4:10.205.20.50:5060
session transport udp
voice-class codec 1
voice-class sip bind control source-interface FastEthernet0/0
voice-class sip bind media source-interface FastEthernet0/0
dtmf-relay rtp-nte
no vadHi Nadeem,
our setup is like
vpn link
call manager ------head office(router)----------------------------------brach router(gateway)------------------ip phone(branch)
The call flow is
sip
IP Phone---->brach GW-------------->call manager------------------>branch GW------------------->ITSP
there is no subscriber at branch side, so the outbound call should travel to call manager at head office and then get exit from branch gateway to ITSP through sip line. -
CME - Sending outbound calls to FXO port
Hi Guys,
Need your help for the below scenario.
Our customer has a CME where 4 FXO ports are already connected and working. Customer has added 2 more FXO port and few IP phones.
The requirement is when ever an outbound call is made from the newly configured IP phones, the call should go through the newly added FXO lines.
For eg ext 3001 , the outbound call should go through port 0/1/0
Already the prefix 9 is used for dialing the number and I guess only one prefix number can be used in CME.
I tried translation rule , cor list but none worked , the call is default going through the old fxo port and not to the new fxo port.
Can you guys help me with the configuration.
Regards
SathyaPrevious post on similar issue might be helpful -
https://supportforums.cisco.com/discussion/11431746/h323-choose-outbound-fxo-port-based-calling-number
Thnx -
Translation patterns - best practice
We have 300 DIDs from our telco. Currently, only 150 are in use. If a call comes thru for a non-asigned number, I would like to set-up a call handler that states the number is a non-working number that belongs to the company and then give options for contacting the correct person. Also, when a person leaves the company I am currenly forawarding the number to the operator but I would also like to make these numbers part of the call handler.
My question is this - what is the best way to set this up? I currently am removing the number from the directory numbers and setting up a translation pattern to point the number to an end point such as the operator. Is this the best thing to do? I would like to know what is considered to be "best practice" in keeping the phone system as clean as possible.
I appreciate any input.
PatI would setup a catch-all scenario with a translation to a CTIRP that would forward to VM and hit the Call handler you desire. For example if you had the DIDs 212-555-1000 thru 212-555-1299 i would first setup a non-DID CTI RP that matches your call handler dtmf (e.g. 7999 if you use 4 digit extensions). the CTI RP for 7999 would forward to VM and then the Call Handler with DTMF of 7999 would play your message that number is not in use.
Then setup a translation for 212-555-1[012]xx that translates to 7999.
This wildcard match would not route the call if there was a more specific match present within the Calling Search Space for the Gateway. So if extension 1050 was present it would route to that phone, but if extension 1051 was a terminated or unused number it would not be present and therefore the call would hit the translation and be routed to the "number not in use" call handler.
I think this is what you are after, a way to minimize the translations and not have to keep track of individual numbers. Of course modify the length of the translations if you are not routing based on 10 digits. -
Good afternoon - I had an urgent request to forward a number out of our DID pool to a satellite phone, which I was attempting to do with a translation pattern. When that didn't work, I tried setting that DID up as a regular DN, but not assigning it to a phone, and configuring the CFWALL to forward to the international number, making sure the cfw partition is set to all international calls.... Is there an easy way to do this? Other than configuring that number on a phone of course and doing a good old-fashioned CFWall.
Yes, I ensured that I had the correct CSS and number mask. As a quick fix, I put an extension on the employees phone, and created a temporary cfw CSS with international calling capabilities and forwarded all calls to the satellite phone number.
Thanks!
Joel -
Query About translation pattern
HI ,
we have call manager 8.6 version.
we are planning to implement incoming call blocking based on calling number as we are using MGCP gateway.
we have already implemented +dialing in incoming calls in calling party number.
Query:
will translation pattern pass alphanumeric charactors?
if the matching number starts with alphanumeric charactors (+ ) in translation pattern will translation pattern pass the number or will reject?
Thnaks,Try this
SELECT ffv.flex_value, maptl.parval
FROM apps.fnd_flex_values ffv,
(SELECT ffvc.flex_value chval, ffvh.parent_flex_value parval
FROM apps.fnd_flex_values ffvr1,
apps.fnd_flex_values ffvr2,
apps.fnd_flex_values ffvc,
apps.fnd_flex_value_hier_all ffvh
WHERE ffvh.child_flex_value_low = ffvr1.flex_value
AND ffvh.child_flex_value_high = ffvr2.flex_value
AND ffvc.flex_value_id BETWEEN ffvr1.flex_value_id
AND ffvr2.flex_value_id
AND ffvr1.flex_value_set_id = :val_set_id
AND ffvr2.flex_value_set_id = :val_set_id
AND ffvc.flex_value_set_id = :val_set_id
AND ffvh.flex_value_set_id = :val_set_id) maptl
WHERE ffv.flex_value = maptl.chval(+)
AND ffv.flex_value_set_id = :val_set_id
ORDER BY ffv.flex_valueThis takes value set id as an input parameter.
HTH -
Translation pattern not matching
Hello All
I am configuring a cucm 4.2 (yes i know its obsolete) integration with Lync 2010 and am having issues with a translation pattern.
The Lync server is sending me 86xxxxxxxxxx for calls within china and will send 61xxxxxxxx for australia (strips the +)
I have configured a [^86]! which should match any international numbers (other than China) and be prefixed and sent to the gateway. Here is the wiered thing I can dial +44xxxxxxxxxx using my lync client which proves that this is matching (when i delete the translation the call will fail).
But when i dial a number like +61xxxxxxxx it doesnt get through and i get
Cisco CallManagerDigit analysis: match(pi="1",fqcn="", cn="removedbymyself", plv="5", pss="LYNC:PT_Reception", TodFilteredPss="LYNC:PT_Reception", dd="61xxxxxxxx ",dac="0")
Cisco CallManagerDigit analysis: potentialMatches=NoPotentialMatchesExist" on the traces.
The LYNC partition has the translation rules. and the CSS assigned to the sip trunk has access to it. the CSS configured in the translation rules is the also the one assigned to the sip trunk.
Anyone see this sort of thing before? how can i check if there is another transformation taking place?
Only way i get round is to put a translation patter for " ! " and it works for all international calls.
Thanks,Hi,
Have you tried testing the call with Dialed Number Analyzer? I find that's a fantastic and often-overlooked tool for this kind of issue. If DNA shows the call will not route, it's probably a CSS issue for the Stafford gateway. If DNA shows the call will route, then it's probably a dial-peer issue on the Stafford gateway.
-Jameson -
Translation Pattern digit problem
We have created a translation pattern (6925) which allows our users to call an internal number in order for them to get routed out to their external helpdesk via the PSTN (908456016925). Initially this didnt work as the translation patter number of 6925 did not have the correct Calling Search Space to get routed out of the voice gateway.
That is now fixed however every time you dial 6925 you get a dead tone when dialling the number 2. If you press 5 immediately the call routes to the translation pattern and out to the helpdesk. This is not ideal as many users are putting the phone down when they get the dead tone as they think the number is incorrect.
I have checked our dial plan route plan report and can confirm that no other device etc has been allocated a number beginning with 692.
I've also created another translation patter (6935) to the same PSTN number and this works fine ie no dead tone when I dial the digit '3'. In fact I have tested 3,4,5 etc and they are fine its just 692.
Any help would be appreciated.......
BSOCMy first step would be to remove the 6925 translation from CM. Once removed, I would try dialing 6925 to see what happens, knowing full well that it should not work. If there are any other patterns or devices beginning with 69 it should fail after pressing the 2 since there is nothing that matches. I would then add the 6925 translation back in and test again. Let us know!
Tony -
Translation Pattern Usage Report
I am trying to determine if a translation pattern is still needed. Is there a report that can be run? Call Manager Release 6.1. Thank you.
Hi,
You can try to check in CDR for the Called Party number (Original and Final) if they match the Translation pattern or the Called Party Transformed number (using Mask or Prefix).
HTH,
Jagpreet Singh Barmi -
Blocking Outbound Calls by Area Code and Time Zone
I am looking to block agents from making outbound calls to certain time zones by area code. Can't quite get my head around how I can use route filters with time schedules. Any help would be appreciated.
Create the route patterns for those area codes and then configure one which allows the calls, and another one that blocks the calls, use TOD to enable/disable them as required.
HTH
java
if this helps, please rate
www.cisco.com/go/pdihelpdesk -
Hello guys,
Our new branch in NY has the DIDs in the range 40XX. The extensions in Our HQ in Boston are in the range 79XX. I asked telco to route those NY DIDs(40XX) to the Boston PRI but they say it wouldn't be possible before 30 days. I am in a big trouble and need to make this happen today. We have some extra DIDs in the range 75XX that we are not using them for now. My idea is to ask telco to map those 40XX DIDs to 75XX DIDs in Boston and use Translation Pattern in CCM to route the incoming calls to NY.
Long story short,
The caller will dial 21279840XX. The Telco will map the 40XX to 75XX and will send it to our Gateway in Boston. I configure a dial-peer with destination-pattern 75.. and the session target <<CCM IP Address>>. The digits represented to CCM will be in the ragne 75XX. By creating some Translation Pattern, I will remap the 75XX to 40XX and send it to NY (On Net). The 40XX extensions are already configured in the CCM. Could you please let me know if this is possible and how can I make this happen in the CCM. Do I need to creat any new dialpeer in the gateway for 75XX extensions?
Thanks,Just like you said all you need to do is create a TP that translates 75XX to 40XX, so here is what you do:
Create a new TP 75XX, under transform called number enter 40XX, make sure that the parition assigned to this TP is included in the GW CSS, also make sure that the CSS assigned to this TP has access to the phone's partition. That's it!
There are other options, such as creating translation rule or num-exp on the GW, but the TP is the easiest.
HTH,
Chris
Maybe you are looking for
-
I would like to know which Sun Cert JAVA Course should I take ???
I am a very good C programmer that is trying to learn Java programming. I know my way around all the various programming statements such as if-then-else, switch etc etc ... I know the basics of an Applet and a Stand Alone application ... I feel that
-
Hello, recently there hasnt been any audio when I send and playback a video message. I tried adjusting the mic on my pc and on skype, so far, nothing. I have the latest skype, this just happened out of the blue. I thank you for helping me.
-
Transaction Variant for SHD0 in CAT2
Hi, We have a requirement to default the wage type in CAT2 screen. Is it possible to accomplish this using the SHD0 transaction variant. The wage type appears in the table control in the CAT2 screen .Kindly advice. Regards, Prabaharan.G
-
JDBC receiver MS SQL Server encryptation
Hi all, I have to configure a communication channel from a PI 7.0 to MS SQL Server 2005 database to execute updates. I have already deployed the com.microsoft.sqlserver.jdbc.SQLServerDriver driver. I have been asked whether SSL encryptation can be us
-
Firewall between Nexus 1000V VSM and vCenter
Hi, Customer has multiple security zones in environment, and VMware vCenter is located in a Management Security Zone. VSMs in security zones have dedicated management interface facing Management Security Zone with firewall in between. What ports do w