Sep 30

Calling Party Number for Mobile Connect (SNR) on Internal Phones

Had a request from a customer to see about removing a prefix from the calling party number when a known Mobile (Remote Destination) calls an office extension phone. The prefix was interfering with call-back and visual display in Missed Calls. So the scenario was mobile 0420999xxx would call into the Office, this mobile is configured as a Remote Destination, therefore the system matches it with the internal extension (ext. 4000). The call proceeds to ring an internal extension, however the calling party display number is 04000. Zero is the access code for PSTN Calls.

I found the MGCP Gateway (this also relates to SIP and H323 gateways in CUCM) was directing the call to a translation pattern. This translation pattern was prefixing a ‘0’ to the calling party number. So even though the system matched the remote destination number to an extension the translation pattern still proceeded to prefix a ‘0’. This is because the transformation of the remote destination number to the associated extension is actioned at the gateway level when the call first arrives. But the Translation pattern prefixes a ‘0’ to all calls to extensions from the Gateway including calls from the transformed remote destination.

How to Resolve

There a few options to work around this issue. I was working with an MGCP Gateway, so I will opt to change add a prefix ‘0’ at the Gateway configuration page. There are four rows containing call types. International, National, Subscriber and Unknown. These types cover all possible calling party types. Under the Prefix Digit column, I will enter a ‘0’ into all the rows. I will also ensure the Use Device Pool checkbox is unchecked for each call type.

Then open the translation pattern and remove the Calling Party Prefix digit of ‘0’.

Make a test call and the calling number should only display the extension. Plus all other calls from the PSTN should maintain the ‘0’ prefix.

Sep 20

Faxing T.38 Relay MGCP to SIP

Not so commonly discussed area of the Voice Communication world is the T.38 Fax Relay between multiple signalling protocols. I was tasked to complete a Fax Server install into an existing Cisco UC environment. The Fax Server communicated to the CUCM via the SIP Protocol and the existing UC infrastructure inclusive of VG224 and a 2811 ISR was controlled via the MGCP protocol.

First thing first, gain connectivity between the CUCM and the Fax Server to ensure SIP is correctly working. Make a call to the fax server and you should receive the fax signalling sounds.. done.

Now lets work on the 2811 Voice Gateway. This is an ISDN Gateway controlled via the MGCP Protocol through CUCM. However we don’t need to log into CUCM to allow the T.38 Fax Relay protocol. Enable T.38 Fax Relay Globally under the Voice Services VOIP Menu.

(Config)# voice service voip
(Config-voip)# fax protocol t38 ls-redundancy 2 hs-redundanyc 0 fallback passthru g711alaw

In the above exampled I chose to fallback to Passthru method, as this is the existing method on the Voice Gateway.

Now lets enable the T.38 Fax Relay Protocol under MGCP.

(Config)# mgcp default-package fxr-package
(Config)# no fax t38 inhibit

Now lets restart the MGCP Application. *Depending your MGCP Configuration, this may disrupt existing calls.

(Config)# no mgcp
(Config)# mgcp

Faxing inbound/outbound the UC network should now be working as normal.

The VG224 configuration is exactly the same as the 2811 Voice Gateway. As organisations still have a need to fax internally, the VG224 needs the above configuration mended as well.

Below is the summary of configuration changes made.

(Config)# voice service voip
(Config-voip)# fax protocol t38 ls-redundancy 2 hs-redundanyc 0 fallback passthru g711alaw
(Config)# mgcp default-package fxr-package
(Config)# no fax t38 inhibit
(Config)# no mgcp
(Config)# mgcp