Apologies for my ignorance but I have a problem that you may already have an answer to (that I have failed to find in threads on this and other forums).
We run CUCM 22.214.171.124900-4. We have an analogue phone that acts as a hotline phone (autodial done via CSS). We use SCCP on the ATA and run software version 3.02.03(051201A). When one picks up the receiver, a Hunt Pilot no is auto dialled and thus rings 1 phone in a Hunt Group. The phones are 7940s. In any case, I initiate an autodial, have a conversation and hang up. However, if the person in the Hunt Group hangs up before I do on the analogue phone, the next phone in the Hunt Group will ring once. If the phone is answered as it is ringing once, I can have a conversation with the person for perhaps a second before I hear an engaged tone and the person at the other end hears hold music.
Any ideas on what settings I should look at? I have gone through the ATA but cannot seem to find an answer. I can duplicate the issue with an ATA I have at the office using the autodial CSS that the local office has.
What are SigTimer bits 22-25 (reorder delay) set to on the ATA? Have you tried setting them to 1111 (e.g. 0x003c0064)?
Please rate helpful posts.
Thanks for your interest. The SigTimer on the ATA186 was set to 0x00000064. I have changed it to 0x003c0064 on the ATA on site and will test with clients. I shall let you know how it goes. Justa question: Is 0x003c0064 a 1 second delay in the re order tone as I have no idea about hex and bits! Sorry about that!
According to the doc, "a value of 15" (1111 in binary) "means that the Cisco ATA will not play a fast-busy tone" ;-)
Ummm I am mega confused. I thought the SigTimer was in hex. I suppose I need to know what the setting is if the default is 0x00000064 for reorder delay of 1 second. I don't know what is meant by 'Bits 0-7' or 'Bits 8-15' for eg.
The 3c = 0011 1100... where the 1's have been set for bits 22-25... but not for bits 20, 21, 26 or 27, of the two hexadecimal digits we're focused on.
If you look at the whole number in hex, 03c00064 = 0000 0011 1100 0000 0000 0000 0110 0100 in binary
The bits relate to each digit of the binary number... but you have to start from the right-most digit and work left.
bit 0 is off (or zero)
bit 1 is off (or zero)
bit 2 is on (or one)
bit 3 is off (or zero)
bit 4 is off (or zero)
bit 5 is on (or one)
bit 6 is on (or one)
bit 0 is off (or zero)
I've just realized I messed up, in my post above, and had a zero in the wrong place. The SigTimer should have read 0x03c00064 above, and not 0x003c0064. My error. Please accept my apologies.
No worries re the error. I shall correct it and try to test today. I was none the wiser anyway until your kindly post which has cleared things up a lot.
One thing still gets me though. I was taught to look at binary fours (i.e. 2 to the power of 0, 2 to the power of 1, 2 to the power of 2 and 2 to the power of 3). This translates into bits 0 though to 3 and then 4 to 7, 8 to 11 etc. However, when Cisco says bits 22 to 25, as you illustrated above the setting falls accross 2 sets of 4 (i.e 2 to the power of 2 and 2 to the power of 3, 2 to the power of 0 and 2 to the power of 1) which I can't see the logic.
How do I put into binary a number streched accross two sets of 4? In binary 9 is 1001. Nice and easy as they fit into bits 0 to 3 but how would I represent 9 in bits 6,7,8 & 9?
Thanks as ever
If you're only referring to those four particular bits, then you can still call it a 9 in decimal (for 1001) ...or 15 in decimal (for 1111) in our example where only bits 22-25 are being talked about for Reorder delay. It's when you have to put it all (call waiting, reorder delay, and hookflash times) into the single SigTimer Parameter that things look strange when converting it to hex.
I was able to maipulate in hex a reorder delay of 1 second with no dramas! Thanks for that! Sadly, it did not fix the problem. A reorder of 100ms would do it but alas 1 second is the minimum. Further testing reveals that there is no problem if I set up the phone to auto dial a single DN as opposed to a queue & Hunt Group.
I have a feeling that the cure is to set up a DN on all the phones concerned and have the translation pattern ring that DN as opposed to the q line that goes to the hunt group.
I really have not done much research on this.
But i do see that the firmware on the ATA is 3.02.03(051201A, but if you check in the device defaults in the call manager the ATA firmware would be 3.02.04
So the ATA is not taking the correct firmware, do you mind upgrading the firmware on the ATA, use the proceedure mentioned in the support thread below:
I believe upgrading the ATA firmware should help.