I know I am not going to provide a whole lot of info since there is so much to post so I thought I would lay out what works and what doesn't in hopes someone can guide me to solution.
We have a current physical RF (RightFax) with a tech line coming straight into it avoiding CUCM.
I have (with help) virtualized the RF and have it going thought the CUCM 8.6 through a 2901 voice router
I can dial out through an existing PRI. I have added a new PRI to accept incoming calls and this is where I am stuck. Internally I can set up a four-digit extension...say 2901...and get to the RF virtual server. I pointed the DID to the new PRI and get the below results but the call rings not allocated:
001078: Jul 8 12:10:21.663 EDT: ISDN Se0/2/0:23 Q931: RX <- SETUP pd = 8 callref = 0x00BA Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98381 Exclusive, Channel 1 Facility i = 0x9F8B0100A10F02010106072A8648CE1500040A0100 vgmducgvg01# Protocol Profile = Networking Extensions 0xA10F02010106072A8648CE1500040A0100 Component = Invoke component Invoke Id = 1 Operation = InformationFollowing (calling_name) Name information in subsequent FACILITY message Calling Party Number i = 0x0081, 'FULL NUMBER' Plan:Unknown, Type:Unknown Called Party Number i = 0xC1, '2901' Plan:ISDN, Type:Subscriber(local) 001079: Jul 8 12:10:21.667 EDT: ISDN Se0/2/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x80BA Cause i = 0x8081 - Unallocated/unassigned number
When the DID was pointed (mistakenly by the Telcom) to our local PRI, it actually worked but not to our new PRI. The settings mirror each other on the two PRIs to boot. Same Telcom and everything.
That's what you need - an incoming call on the PRI that is controlled by CUCM needs some sort of pattern associated with it so you can route it (else you'll get unallocated/unassigned and busy on the line when calling that number from outside). You need to configure the fax DID(s) as route pattern(s) in CUCM and then route them via SIP or H323 trunk(s) (whichever integration you are using between CUCM and RightFax) to the RightFax server.
Well, the number is either a DID or it's not...DID just means that it is a direct inward dial number that is routed via the PSTN into your network. When you call the number from outside, does it hit the PRI or no? If not, that's the first problem (assuming it is a DID) and would be a carrier issue. If it does, how many digits are presented from the Telco vs. what you are expecting to route (you note 4-digits)? Are you routing the call from the PSTN gateway to CUCM and then to RightFax or expecting to route directly from the PSTN gateway to RightFax via H323 dial peers?
Ok - so the call is routed into the network and then when you assign it to a route pattern, which is used to route the call to the RightFax server, the call fails. In that case, you will need to look at the H323 integration between RightFax and CUCM. First, you'll need to make sure that the versions are compatible. There are some gotchas when using H323 between CUCM and RightFax just as there are gotchas if you use SIP between CUCM and RightFax. Personally, I'd try the SIP integration over H.323 but it's not that one is inherently better than the other. You need to make sure that you configure the CUCM side based on the latest RightFax integration guide. You also have to make sure that the RightFax is configured appropriately as well. It needs to 1) be configured to accept calls from the CUCM via either SIP or H323 and 2) have the fax DIDs (or abbreviated extensions - whatever you use) configured so it can process the call as well.
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...