cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1043
Views
5
Helpful
6
Replies

RightFax VM not taking inbound calls

David Coelho
Level 1
Level 1

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. 

The internal ext works but not the full number. 

 

Anyone have any thoughts on where I should look?

 

THANKS!!!

 

 

6 Replies 6

David Coelho
Level 1
Level 1

OK...I can set a DID in CUCM and the call comes through. The example above, I have as a route pattern for 2901 to point to the RF virtual server. 

 

Can a DID on a PRI be associated to a route and not a DID? How can I push that DID through CUCM to the RF server?

 

Thanks again all!

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.

Hailey

Rate helpful posts!

Right now it is as a Route Pattern to the RF gateway via H323. 

 

Internally, I can use that route pattern to get to where it needs to go. Does not seem like the four-digit from the PRI is not hitting that route pattern though. It did hit when it was a DID.

 

Thank you for your help

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?

I might be mixing terms...

 

When the four digit DID is assigned to a Directory Number in CUCM...the call goes through. When the four digit DID is only assigned a Route Pattern, the call does not go through. 

Both ways it hits the PRI just when it is only a route pattern, the gateway does not seem to recognize it. 

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.