In Germany they use overlap sending & receiving on ISDN circuits, meaning that call setup messages don't contain the entire dialled number (i.e. en bloc dialling), instead the dialled digits will be split across several call setup messages. This is complicated by the fact that this isn't done for all calls - calls from international numbers & mobiles use en bloc dialling.
The Cisco configuration guide for overlap receiving says to enable it on the ISDN interface, disable direct-inward-dial & use T in your dial-peers to force a T302 timeout. However all the documentation I've seen covers a voice gateway with inbound & outbound dial-peers with timeout, not CME. This causes a problem as having just an inbound dial-peer with timeout doesn't result in digits after the first call setup message being captured, as the virtual dial-peers for the phones registered with CME don't have a timeout. The solution is to use a voip dial-peer pointing to the CME router to loop back the call, then translate the dialled number so that the phone's virtual dial-peer is matched.
Below is example configuration using a BRI interface, where the direct dial range is 8693920X & internal numbers are 920X. After experimentation I found the 6000ms value for the overlap receiving T302 timeout to work the best (the default is 10000ms).
interface BRI0/1/0
no ip address
isdn switch-type basic-net3
isdn overlap-receiving T302 6000
isdn point-to-point-setup
isdn incoming-voice voice
isdn send-alerting
isdn sending-complete
isdn static-tei 0
!
voice translation-rule 1
rule 1 /^8693\(920.\)/ /\1/
voice translation-profile BRI_Called
translate called 1
!
dial-peer voice 3000 pots
description BRI0 inbound
incoming called-number 869392T
port 0/1/0
dial-peer voice 3001 voip
description Loopback for overlap receive T302 timeout
translation-profile outgoing BRI_Called
destination-pattern 869392T
session target ipv4:172.23.12.130
incoming called-number 92..
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
Looking at the debug isdn q931 output, we can see the first call setup message arrive, followed by the 2nd containing the last digit & then the call connects correctly:
001218: May 3 11:49:04.136: ISDN BR0/1/1 Q931: TX -> RELEASE pd = 8 callref = 0x2B
001219: May 3 11:49:04.188: ISDN BR0/1/1 Q931: RX <- RELEASE pd = 8 callref = 0xAB
001220: May 3 11:49:20.569: ISDN BR0/1/0 Q931: RX <- SETUP pd = 8 callref = 0x01
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0x89
Exclusive, B1
Progress Ind i = 0x8283 - Origination address is non-ISDN
Calling Party Number i = 0x00A3, N/A
Plan:Unknown, Type:Unknown
Called Party Number i = 0xC1, '8693920'
Plan:ISDN, Type:Subscriber(local)
001221: May 3 11:49:20.573: ISDN BR0/1/0 Q931: TX -> SETUP_ACK pd = 8 callref = 0x81
Channel ID i = 0x89
Exclusive, B1
001222: May 3 11:49:21.125: ISDN BR0/1/0 Q931: RX <- INFORMATION pd = 8 callref = 0x01
Called Party Number i = 0xC1, '0'
Plan:ISDN, Type:Subscriber(local)
001223: May 3 11:49:27.149: ISDN BR0/1/0 Q931: TX -> CALL_PROC pd = 8 callref = 0x81
001224: May 3 11:49:27.193: ISDN BR0/1/0 Q931: TX -> ALERTING pd = 8 callref = 0x81
Progress Ind i = 0x8188 - In-band info or appropriate now available
001225: May 3 11:49:29.297: ISDN BR0/1/0 Q931: TX -> CONNECT pd = 8 callref = 0x81
Channel ID i = 0x89
Exclusive, B1
001226: May 3 11:49:29.377: ISDN BR0/1/0 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x01
001227: May 3 11:49:29.381: %ISDN-6-CONNECT: Interface BRI0/1/0:1 is now connected
Thursday, 9 May 2013
Monday, 18 February 2013
Communications Manager Tools Part 2
Troubleshooting using SDI/SDL traces from CUCM is a pain, in part because the tool within RTMT for doing this is pretty lame. Cisco do make the Voice Log Translator, which tidies up the presentation of traces & provides explanations of many of the fields, very useful! Unfortunately it's not been updated since 2010 & when I tried using it with CUCM 9.1 recently it didn't seem to understand many of the traces. Fortunately there are a couple of alternative tools for wrangling with traces, both made by Cisco employees: TranslatorX & Triple Combo.
Also, don't forget to give the tools from Communications Manager Tools Part 1 a go.
Also, don't forget to give the tools from Communications Manager Tools Part 1 a go.
Labels:
Communications Manager,
RTMT,
SDI,
SDL,
Tool,
Trace,
TranslatorX,
Triple Combo,
VLT
Friday, 15 February 2013
ATA 186 & 187 2nd FXS Port
On the now discontinued ATA 186 & the current ATA 187, to use the 2nd FXS port you have to create another device, take the MAC address & tack 01 on the end & remove the first 2 digits. For example 54781A1D7D43 becomes 781A1D7D4301.
Friday, 1 February 2013
Jabber Video for Telepresence & AnyConnect VPNs
I recently spent some time troubleshooting a customer's video call quality issues when their staff working from home on an AnyConnect VPN make video calls using Jabber Video for Telepresence. The symptoms include low resolution being used & frequent periods of high packet loss (upto 70%) reported by Jabber Video, despite fast Internet connections in use at both ends. After much head scratching it turns out Jabber Video doesn't get on with SSL VPNs, there's an official notice from Cisco on the matter here. My testing shows that both IPsec & L2TP/IPsec VPNs don't suffer from this problem.
Monday, 28 January 2013
Unhelpful Error Messages
This error message appeared after trying to restart a CUCM server via the OS Administration GUI. Where is the Save button that it refers to?!
Tuesday, 4 December 2012
United Arab Emirates PSTN Route Patterns
I recently had to configure a UC540 for use in the Dubai, unfortunately CCA doesn't have any dial plan templates for the UAE. Below is the route patterns for a simplified UAE dial plan:
| Route Pattern | Description |
|---|---|
| 00! | International calls |
| 971 | Water or electrical emergencies |
| 997 | Fire |
| 999 | Police and emergencies |
| [2-8]XXXXXX | Local calls |
| 0200XXXXX | Shared cost services |
| 0300XXXXX | Reserved for future use |
| 0400XXXXX | Free access services |
| 0500XXXXX | Shared revenue services |
| 0600XXXXX | Fixed cost services |
| 0700XXXXX | Shared cost services |
| 0800XXXXX | Freephone services |
| 0900XXXXX | Premium services |
| 0[234679]XXXXXXX | National area codes |
| 05[0256]XXXXXXX | Mobiles |
Friday, 2 November 2012
QuesCom GSM Gateways
I've just completed my 2nd deployment of a QuesCom GSM gateway & they're painful to use, so here's a couple of tips for those of you with the misfortune to also have to deal with one these.
Firmware Updates
To update the firmware you'll need:
Caller ID
The QuesCom GSM gateways default to restricting the caller ID on all outbound calls, regardless of what caller ID you present via H323 or SIP. This is undesirable as many people won't answer the phone to withheld numbers. Unfortunately you can't disable this behaviour from the web based GUI, you have to Telnet to the QuesCom and enter the following commands:
Firmware Updates
To update the firmware you'll need:
- A USB to serial adapter
- An Ethernet cable
- TFTPD
- PuTTY
- QuesCom firmware (getting this requires a support contract with QuesCom)
- Connect your PC's NIC to the QuesCom using the Ethernet cable, then using the serial cable that came with the QuesCom, connect to the console port on the QuesCom (this is the bottom serial port).
- Run TFTPD, configure the DHCP server function on it & also enable PXE compatibility (otherwise you'll get errors), now restart TFTPD for the changes to take effect.
- Run PuTTY & connect to the serial port using 19200bps, 8 data bits, no parity, 1 stop bit & no flow control.
- Power on the QuesCom & interrupt booting by pressing CTRL + E, then type OK when it says to.
- Select 1, wait for it to get a DHCP lease. Alternatively you can manually configure an IP address if DHCP fails.
- Input the IP address of your PC running TFTPD, default gateway & file name of the firmware (this is case sensitive).
- Wait for the firmware to finish downloading, then select 0 to boot with the new firmware.
Caller ID
The QuesCom GSM gateways default to restricting the caller ID on all outbound calls, regardless of what caller ID you present via H323 or SIP. This is undesirable as many people won't answer the phone to withheld numbers. Unfortunately you can't disable this behaviour from the web based GUI, you have to Telnet to the QuesCom and enter the following commands:
- config
- root gateway
- cd isdn
- cd Adapter.x (x=0,1 or 2; if you only have GSM cards in the slots, use 0)
- set HideIdentification=0;0;0;0; (this assumes you have 4 SIM card model)
- exit
Subscribe to:
Posts (Atom)