interface Serial0/3/0:15 no ip address encapsulation hdlc no logging event link-status no snmp trap link-status isdn switch-type primary-net5 isdn overlap-receiving isdn incoming-voice voice isdn bchan-number-order ascending round-robin trunk-group 1 no cdp enable
my problem is this:-
At the moment calls are leaving on the first available channel of my h323 voice gateway PRI, I can apply this command to the interface fine but it makes no difference the b cannels are always being picked on a first come first served basis . I have also tried combination "isdn bchan-number-order decending" and "isdn bchan-number-order descending round-robin" but it makes no difference , the first b channel is always selected .
Any ideas , if you think its a bug can u identify the bug id as I cannot find it .
I can see that you use ascending , that why you hit 1st channel.You have to choose one of these commands ascending or descending
I have a question here , for your incoming calls which channel hits ?.FYI isdn bchan-number-order descending is enable by default , so if you need to change you have to type ascending. Can you just share incoming calls which channel hits?.This is because before you define your outgoing calls , you have to check your service provider channel used, and this to avoid error channel is not available.
thanks for the reply but without this command it selects the order 1-31 , with the order in any combination it still selects ch1 if free every time ie ascending/ descending , not applied or round robin
the i/c calls from the telco come in in the order 31-1
my aim is really to apply bchan-number-order ascending round-robin so in theory if all channels are free it picks up ch1 first , then ch2 etc .. it is not doing this either ..
so in answer to your reply , it does not matter if i apply ascending or decending it is always using the order ascending ( first free channel)
no , i did not mention that. I said as above the default behaviour is descending , but before you are going to change it to ascending you have to check incoming calls to avoid a famous isdn error "channel is not available". So as per your answer you incoming calls from ITSP uses descending , so if you use ascending , no issues for change and everything should be ok .Now , if you are going to isdn ascending from your VG , if you have CUCM , you have to change the configuration of your controller timesolts from up to down . Your outgoing calls will hit starting from Channel 1 -31.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...