Been having some issues recently with phones dropping off the call manager and then refusing to re-register. The phone logs are showing TFTP NOT AUTHORIZED, a reboot of the phone brings it back online. I am wondering why this has started happening seemingly out of the blue and if it is a sign of something about to go wrong. We are not using security on your phone system and none of the phones have a CTL file installed. It's happened on two different 9.1 clusters both within a day or two of each other, both using different TFTP servers. Can you get this error message for non CTL related issues? ... View more

Hi Folks, I have an issue in a new Voip deployment whereby when a user call forwards their internal phone to an external mobile, the site prefix is being added to the Originating caller ID on the destination mobile phone and trailing digits are stripped. For example.. the site prefix is +43166105 A user outside the company with mobile phone number 06991968XXXX calls an internal extension that is call forwarded to 0664545XXXX, when the call rings on 06664545XXX, the caller ID is shown as +431661056991968, with last 4 digits missing The site has two voice gateways, GW2 for specific mobile phone calls, and GW1 for regular calls and all other mobile calls, when a user call forwards to a mobile phone that is reachable via GW2, the caller ID is showing correctly (both g/w are connected to different providers) I have a translation pattern on both g/w that strips the leading zero's of the calling number and also makes sure call type is presented properly to the provider. Generally, i would be calling the provider, however the site are telling me that this worked OK on the previous PBX based setup. Here are some relevant pieces of configuration information, and the ISDN debug of an affected call, as you can see, we are providing the correct digits to the provider, yet we always see the prefix regardless I have tried changing the numbering type in the translation pattern from any to unknown and it has the effect of then showing no digits of the Caller ID, it will just show the prefix number.   508090: Mar 28 10:42:47.084 CET+1: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8  callref = 0x07CC Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98382 Exclusive, Channel 2 Calling Party Number i = 0x0181, '6991968XXXX'  Plan:ISDN, Type:Unknown Called Party Number i = 0x81, '0664545XXXX' Plan:ISDN, Type:Unknown   GW1   trunk group A1_Telekom  carrier-id Vienna_A1_Telekom  description Vienna_PSTN_Trunks  hunt-scheme round-robin both  isdn supp-service tbct notify-on-clear  translation-profile outgoing OUTBOUND   voice translation-rule 4  rule 1 /^01\(.*\)/ /01\1/  rule 2 /^0/ //  rule 3 /^8912$/ /0017275788912/ ! voice translation-rule 5  rule 1 /\+43166105/ /166105/ type any national  rule 2 /^000\(.*\)/ /\1/ type any international  rule 3 /^00\(.*\)/ /\1/ type any national   voice translation-profile OUTBOUND  translate calling 5  translate called 4   dial-peer voice 99 pots  trunkgroup A1_Telekom  service session  destination-pattern 0T  fax rate disable  direct-inward-dial  forward-digits all   ... View more

Hi folks, I have an issue in a site in Austria that is related to isdn overlap. I recently migrated this site from a PBX to CUCM v9.1. Just recently i found out that some callers to the facility were not getting through, which was related to isdn overlap-receiving. That issue is now resolved, however there is one number (the site prefix) that should be redirected to reception when it is called. Site prefix - +43166105  followed by 4 digits When i call the +43166105 number it shows up on my gateway with no DNIS information and is waiting for extra digits as per the ISDN overlap requirement. The requirement is that if no digits are entered it should redirect to reception but i cannot get it to work without breaking the overlap receiving config. Presently if digits are entered they are expanded to e.164 and sent to CUCM. What i have tried aleady is add the following incoming DP on the expectation that the DP would be matched on ANI as Destination pattern, and null DNIS would be translated to the reception number, this piece of configuration worked but had the unexpected side effect of breaking the overlap recieving configuration dial-peer voice 98 pots trunkgroup A1_Telekom translation-profile incoming INBOUND service session destination-pattern . fax rate disable forward-digits all voice translation-rule 1 rule 3 /^$/ /+431661050/   Here is my configuration as it stands, everything works except +43166105 , presently to reach reception a caller can enter '0' after dialing the +43166105 prefix ......................................................................................................................... trunk group A1_Telekom  carrier-id Vienna_A1_Telekom  description Vienna_PSTN_Trunks  hunt-scheme round-robin both  translation-profile outgoing OUTBOUND   voice translation-rule 1  rule 1 /\(^3...$\)/ /+43166105\1/  rule 2 /^0$/ /+431661050\1/ voice translation-rule 3  rule 1 /^/ /00/ type national national  rule 2 /^/ /000/ type international international   voice translation-profile INBOUND  translate calling 3  translate called 1 interface Serial0/0/0:15  description PSTN  no ip address  encapsulation hdlc  no logging event link-status  isdn switch-type primary-net5  isdn overlap-receiving T302 5000  isdn incoming-voice voice  isdn send-alerting  isdn bchan-number-order ascending  trunk-group A1_Telekom  no keepalive  no cdp enable   dial-peer voice 99 pots  trunkgroup A1_Telekom  service session  destination-pattern 0T  fax rate disable  direct-inward-dial  forward-digits all dial-peer voice 100 pots  trunkgroup A1_Telekom  translation-profile incoming INBOUND  service session  incoming called-number .T  fax rate disable  forward-digits all ! ! dial-peer voice 1000 voip  description #### INCOMING CALLED NUMBER PEER ####  translation-profile incoming GX-ready-access  modem passthrough nse codec g711ulaw  incoming called-number .  voice-class codec 1  dtmf-relay rtp-nte  fax rate 14400  no vad ! dial-peer voice 1001 voip  preference 1  service session  destination-pattern +43166105....  progress_ind setup enable 3  progress_ind progress enable 8  modem passthrough nse codec g711ulaw  session protocol sipv2  session target ipv4:10.64.24.159  voice-class codec 1  dtmf-relay rtp-nte  fax rate 14400  ip qos dscp cs3 signaling  no vad ! dial-peer voice 1002 voip  preference 2  service session  destination-pattern +43166105....  progress_ind setup enable 3  progress_ind progress enable 8  modem passthrough nse codec g711ulaw  session protocol sipv2  session target ipv4:10.65.28.30  voice-class codec 1  dtmf-relay rtp-nte  fax rate 14400  ip qos dscp cs3 signaling  no vad ! dial-peer voice 1003 voip  preference 1  service session  destination-pattern +431661050  progress_ind setup enable 3  progress_ind progress enable 8  modem passthrough nse codec g711ulaw  session protocol sipv2  session target ipv4:10.64.24.159  voice-class codec 1  dtmf-relay rtp-nte  fax rate 14400  ip qos dscp cs3 signaling  no vad ! dial-peer voice 1004 voip  preference 2  service session  destination-pattern +431661050  progress_ind setup enable 3  progress_ind progress enable 8  modem passthrough nse codec g711ulaw  session protocol sipv2  session target ipv4:10.65.28.30  voice-class codec 1  dtmf-relay rtp-nte  fax rate 14400  ip qos dscp cs3 signaling  no vad !         ... View more

Is it possible to monitor which calls were made via standard local route group?    For example we have an on-net conferencing service that in times of congestion will re-direct to local pstn g/w via the standard local route group. we dont have any way to see how often it is happening at present.      ... View more