We have a Cisco gateway 2800 series with 4 FXO cards filled with POTs lines. Half of the lines are used for site A and the other half for site B. I'm researching a way to have the users from Site B go out their POTs lines and same with Site A (for correct outgoing caller ID assessment).
The only idea I have at this time is to assign a prefix (in Call Manager) on the users calling from site A to the PSTN and different prefix from site B users and then strip this at the gateway. This prefix would tell the gateway which trunk to use.
Would you agree this is probably the most practical way? Or can you suggest a way that the POTs lines can be shared instead of split and correctly assign the outgoing caller ID?
BTW, a large number of POTs lines are used instead of an E1/T1 because the local telecom doesn't offer T1/E1 capability at this time.
I guess prefixing a digit for site A, and a different digit for site B before CUCM sends the call to the gateway like you suggest should work. Then use your dial-peers to direct it out the correct trunk group and only forward the necessary digits to the PSTN.
Another option would be to do this on the gateway. Configure a separate translation rule on the gateway for site A, and one for site B, that translates the called number and prefixes a particular digit. Then configure a translation-profile on your inbound VoIP dial-peers from CUCM for each particular rule you created. Then specify which dial-peer would be used by site A and site B by matching the answer-address, so you have inbound VoIP dial-peers from CUCM for site A, and site B.
The translation-profile prefixes whatever digit for site A and whatever digit for site B in front of the called number. Then the destination-pattern on your pots dial-peers for each site would need to match that number you prefixed followed by whatever CUCM is sending to the gateway. Then point that to your POTS trunk group and use the forward-digits command to forward only the 7, 10 or whatever digits to the PSTN.
Not sure which you would consider to be the most practical. I guess I've probably done it both ways in the past depending on whether or not the two sites were already configured to use separate route patterns in CUCM or not.
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...