Hi Apologies if I was not clear earlier. You dont need to create dial-peers for phones with extensions because there dial-peers will be automatically created. But you need dial-peers for any other number that is not registered automatically. Your hunt pilot number will not be registered automatically in SRST. You will need to define it for it to be available in SRST and hence you need to create dial-peers to route to it.   ... View more

In your configuration, I don't see the second dial peer to be used during SRST.. ... View more

Please provide the full call flow. Where does the gateway send the call to? CUCM? or is this a CCME deployment.. What is the protocol used in the call flow. You need to see the full picture to accurately diagnose what the issue is. When we need the full flow and protocols used we can request additional logs to help point us in the right direction ... View more

Typically when a REGISTER message is sent with Expires = 0, this is usually indicative of a keep-alive message sent to the backup registrar. It is possible that when the gateway performed DNS lookup on your registrar more than one hosts were returned and its trying to register to primary and send keep-alive to the secondary. To confirm this, I will need the following:   1. Turn on debug ccsip info, debug ccsip message, debug ccsip feature registration 2. initiate a new register request ( you can do this by doing the following: sip-ua no  registrar dns:XXX.XXX.XXX expires 60 registrar dns:XXX.XXX.XXX expires 60   Collect the logs and attach here   ... View more

Is the hunt pilot number registered in SRST? I doubt it, hence why you will need the dial-peer. In SRST the gateway will automatically create dial-peers for your phones with extension on them but for any other number like a hunt pilot you have to tell the gateway where to send the calls to. ... View more

Cofi, Based on your logs here is what I see:   leg 1: PSTN------>CUBE: isbco4ktp4wd9drsqtko4tpd4vwsqitvtotv@SoftX3000 leg 2: CUBE--------->.CUCM: 801BB756-764211E9-93549002-D9FECD1@10.151.1.5 This leg advertises G711Alaw only leg 3: CUCM-------->.CUBE ( forwardall):a9425980-cdc103c8-713397-43640c0a@10.12.100.67 This leg advertises only G711ulaw leg 4: CUBE------->PSTN ( for forwarded call):8037A35A-764211E9-935C9002-D9FECD1@10.151.10.240   As you can see leg 2 and leg 3 advertises different codecs and this is likely because of the following: 1. Dial-peer to CUCM has only G711alaw configured 2. The codec preference list for the SIP trunk to the gateway is not setup properly   To address this, try and enable G711ulaw on the dial-peer to CUCM. Ie add multiple codec to the dial-peer doing the following: voice class codec 20 codec preference 1 G711ulaw codec preference 2 G711alaw   2. ensure that the audio bit rate for the region assigned to the SIP trunk is set to 64Kbs   If the call still fails collect another set of logs and then attach the CUCM SDL traces ... View more

Since this is a h323 dial-peer, you will need to configure the following, so that when CUCM is down, calls will route to SRST gateway and when CUCM is up, calls will always go to CUCM first.   voice class h323 1 h225 timeout tcp establish 2 h225 timeout setup 2   ++ dial-peer to CUCM ++ dial-peer voice 2 voip preference 1 voice-class h323 1 destination-pattern 5000 session target ipv4:192.168.1.100 dtmf-relay h245-alphanumeric codec g711ulaw   ++ dial-peer to SRST gateway IP ++ dial-peer voice 2 voip preference 2 voice-class h323 1 destination-pattern 5000 session target ipv4:X.X.X.X ( where X.X.X.X is your SRST gateway ip ( you can use loopback address if you have one on the gateway) dtmf-relay h245-alphanumeric codec g711ulaw ... View more

It does not work like that. What you need to do is to configure two translation rules and then apply one for normal call routing and apply the second one during SRST. For SRST configure and  apply the translation profile as follows:   voice translation-rule 10 rule 1 /^0944994433$/ /5000/   voice translation-profile abbr-dial  translate called 10   ++ SCCP phones +++ call-manager-fallback  translation-profile incoming abbr-dial ! ++ SIP Phones +++ voice register pool  2  translation-profile incoming abbr-dial ... View more

Can you attach your debug ccsip messages? Include the call details please. Calling number, called and forwarded number, ... View more

On the face of it, this does not look like what you should be doing and may not work. A 6XX is a global failure, a 4XX is a user/client failure/ response. I dont see how this will work. A SIP profile does not rewrite the Method but headers within the SIP method. Secondly, You should be able to tel easily who is not handling the 603 from your SIP traces.  Please post snapshot of your traces here. Lastly what issue is this causing? ... View more

The answer depends on other things such as local route groups. If you are using local route groups in your deployment ( and running CUCM version that does not support multiple LRG in device pool) then your only option is to group your gateways into a single route group. A route list allows you to group multiple route groups. If you have more than one route group, you can assign them to a RL and then assign the route list to your route pattern. ... View more

Phone A---Speaks only G729 Phone B -- Speaks only G729 Region between phone A and B is set to 64kbps.   Yes they can talk to each other and they wont need a xcoder. You need to remember that the region setting is looking at the audio bit rate (  not the codec) So if you have a higher audio bit rate: in this case 64kbps, then G729 ( which is 8kbps) will be allowed. ... View more

Hi Muk, Question 1: 1. Phone A supports only Codec G711U and Phone B supports supports only G729 Region relation is set to G729. Do we need to invoke Xcoder if yes, who will invoke the Xcoder. Answer:  Both phones cant talk to each other, the region relationship between them is irrelevant. Yes we will need a xcoder. For the xcoder to be successfully invoked, here is what you need to know The side with the high bit rate codec will invoke the xcoder ( Phone A) in this case The device cap of the xcoder will affect what the region relationship between the devices and xcoder needs to be. Eg If the xcoder is configured for G711, then the region between Phone A and B and xcoder needs to be 64K 2.   Phone A supports only Codec G711U and Phone B supports supports only G729 Region relation is set to G711. Do we need to invoke Xcoder if yes, who will invoke the Xcoder. Answer: Again the region relationship is irrelevant. The two phones cannot talk to each other directly. The region relationship comes into play only when both devices can talk to each other. Here is the rule of thumb:   Can both devices talk to each other based on their device capabilities--If yes, then evaluate the region Does the region allow the device caps (codec) that the devices are trying to use to talk to each other--if no The side with the high bit rate codec invokes the xcoder Evaluate the device caps of xcoder Evaluate the region relationship between xcoder and devices   For example consider this scenario: Phone A---Speaks only G711 Phone B -- Speaks only G711 Region between phone A and B is set to 8kbps. Can this device talk to each other? No. Even though they can speak the same codec, yet the region does not allow it, hence a xcoder will need to be invoked, ... View more

There are many things to consider when doing CFA? You really cant use DNA to check for CFA. For example what is your dial plan like? Do you use device/line based CSS model. If you do, have you defined a secondary CSS for the CFA destination? If it is not a CSS issue, then we are going to need your CUCM logs to see what is going on. Can you use RTMT to pull CUCM logs for the affected call? ... View more