H323 between UCM and RightFax

[gonatienza]

Hi There,

Im implementing a cluster of 2 RightFax servers with a UCM 7.

My idea was to send and receive rightfax calls through the UCM, instead of pointing it to the PSTN GW directly.

Outgoing calls (RightFax -> UCM -> H323 PSTN GW) havent been an issue, but Im having a little problem with calls from the UCM to the RightFax server.

When a call is sent to the RightFax, it prompts with an IVR asking the caller to insert an extension, and those DTMFs are being sent OOB (as H245).

The RightFax guy told me they require in-band DTMF for this solution.

I could be sending the call directly from the PSTN GW to the RightFax configuring dial-peers sending digits in-band, or I could use a CUBE with transcoding resources to insert DTMF embedded in the audio stream payload.

Is there any other way of doing this with the UCM alone without involving another GW or resource?

Ideas?

Thanks!

[Steven Holl · Accepted solution]

If they actually need the DTMF in the audio payload, then you need to invoke a DSP to get the OOB DTMF in the audio stream.  Which means you need to invoke a transcoder and configure a DTMF mismatch on the node where the transcoder is registered (which you can do with SIP on CM, but can't with H323 since CM only supports h245-signal/alpha on an h323 gateway instance).

If you invoke a transcoder, be sure to configure 'codec pass-through' on the transcoder capability list so that it supports T.38 through it.

I'm suprised that RF needs to see DTMF in the actual audio stream, since they would then require a DSP to detect the DTMF, and it's much easier to look in the OOB signaling for DTMF.  You're doing VoIP straight to RF, not integrating to RF with a T1 card, right?

And it is RF that is playing the IVR prompting for the extension, and not an external IVR like Unity, right?

Is it possible that you disable the IVR function on the RF and use ANI or DNIS manipulation to get the calls into the correct RF inbox?  That's the cleaner solution, in my opinion.

[gonatienza]

Thanks for replying Steven.

you need to invoke a transcoder and configure a DTMF mismatch on the node where the transcoder is registered (which you can do with SIP on CM, but can't with H323 since CM only supports h245-signal/alpha on an h323 gateway instance).

That was the big question.  I knew that on-band DTMF with H323 wasnt supported on CUCM, but I was hoping for a magic solution...

Regarding using SIP, I know I have the option that way, but the customer bought an H323 card to use with RF for this integration (I didnt engineered this, Im just deploying, but someone from the partner did, and Im not going to tell the customer "you needed to buy a SIP card for this implementation".  I dont even dare to ask if this card supports SIP too).

RF works unlike anything Ive seen...  It has two interfaces, one of them used for signaling, and the other (the supposed H323 card) used for RTP (doesnt make too much sense, does it?).

If you invoke a transcoder, be sure to configure 'codec pass-through' on the transcoder capability list so that it supports T.38 through it.

Didnt know that one.  Thanks.

I'm suprised that RF needs to see DTMF in the actual audio stream, since they would then require a DSP to detect the DTMF, and it's much easier to look in the OOB signaling for DTMF.  You're doing VoIP straight to RF, not integrating to RF with a T1 card, right?

I was surprised too...  I had the same thing with an Avaya implementation (the Avaya guys had to do some weird tweak to make DTMF work OOB.  There were a LOT of calls between the two solutions, and using transcoder resources for each call wasnt an option).  Like you said, its much easier to work OOB.  I captured packets on the H323 card from the RF and the DTMF are getting there OOB, RF is just waiting for them in-band.  It is VoIP straight to RF, no T1/E1 in the middle.

And it is RF that is playing the IVR prompting for the extension, and not an external IVR like Unity, right?

The RF has an embedded IVR prompting for extension, there is no external IVR involved.

Is it possible that you disable the IVR function on the RF and use ANI or DNIS manipulation to get the calls into the correct RF inbox?  That's the cleaner solution, in my opinion.

To use DNIS I would need either one DID line for each user (no way...) or use another IVR to prompt for extension and then send it to RF (Ill think about it, if RF actually supports that).

Ill keep working on this next week, this one was a nightmare.  Ill let you know how I solved it.

Thanks for you help Steven.

[gonatienza]

Hey Steven,

I worked on this today and it wasnt so hard after all.

As said before this is the call flow: PSTN -E1-> GW -H323-> UCM -H323-> RightFax.

The only thing needed to be done was to configure a dial-peer on the GW matching the number of the RightFax and sending the call to UCM with DTMFs in-band (dtmf-relay rtp-nte).  The UCM does the signaling with the RightFax, and the RTP goes between the GW and the RightFax with DTMFs in-band.  In this case MTP wasnt required in the UCM GW config.  I think that the UCMs MTPs doesnt support T.38, only IOS software/hardware MTPs or Transcoders.  I could have also configured the dial-peer to send the call directly to the RightFax server, but I dont know if the server accepts signaling from unconfigured IPs (the RF is configured to send the call only to one of the UCMs), furthermore I rather mange redundancy from UCM instead of dial peers with different preference (its a cluster of 2 RF).

Thanks for your help Steven!