SNR from DDI not working

[james.g.reed]

Hi

We have a UC540 with SNR configured on an extension. If the extension is called from an internal extension then the SNR works exactly as it should. However, if the extension is called either from the DDI number associated with the extension or via the main autoattendant and then dialing the extension it does not. The internal extension rings but never diverts out to the mobile to which SNR is configured to.

The DDI, incoming and outgoing lines are all SIP trunks as no PSTN lines are used for normal operation on this unit.

It would appear that there is some kind of anti-relay setting preventing the outgoine call but all other SIP based calling is working correctly.

Can  anyone offer any advice?

Thanks

James.

[greenturtlesteak · Accepted solution]

This is most likely happening because the SNR call is going out with the original caller's CLID, which your carrier is dropping.

Try adding the following to the ephone-dn to see if this helps.

snr calling-number local

Cole

[james.g.reed]

Hi Cole

Exactly right. Adding that command to the ePhone for the extension with SNR sorted this problem out perfectly.

That's what happens when you let the GUI do the work for you!

Thanks

James.

[Steven DiStefano]

Which GUI :-) ?

I would like to share what I know about this.

For Single Number Reach (SNR) numbers going over SIP trunks, the Caller ID should not reflect the Caller ID of the

original caller when set up using CCA.

Typically the Caller ID will be the main PSTN number (DID) configured for SIP trunk or the override to a specific DID using the CallerID TAB of the Outgoing Dial Plan GUI window.

All the designated SIP Trunk SPs require Caller IDs (FROM Headers) to be valid account numbers or they reject the call (prevent fraud)

As an example of how we do it for one such SP in the US the following resulting CCA CLI:

The UC500 is setup for translating calling, called and redirect numbers when call hits dialpeer 1027,

As per this config, every calls that goes out of dial-peer 1027 (in my case) will have calling-number as 6783979422 (my main SIP trun DID)

dial-peer voice 1027 voip

corlist outgoing call-national

description **CCA*North American*Long Distance**

translation-profile outgoing PSTN_Outgoing

preference 1

destination-pattern 91[2-9]..[2-9]......

session protocol sipv2

session target sip-server

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

dtmf-relay rtp-nte

ip qos dscp cs5 media

ip qos dscp cs4 signaling

no vad

voice translation-profile PSTN_Outgoing

translate calling 1111

translate called 1112

translate redirect-target 410

translate redirect-called 410

voice translation-rule 1111

rule 15 /.*/ /6783979422/

I realize the CME 8.0 introduced command you refer to, and in my experience using it with the CCA configured system has no impact on egress calls.

So I would guess that the system is modified and perhaps its a SIP trunk SP that is not a designated one?

SIP Trunk --> 201 w/ SNR to Mobile Phone (10 digit)
·        snr calling-line local

·        mobile displays the CLID of the UC500 (not the original CLID)


·        no snr calling-line local

·        mobile displays the CLID of the UC500 (not the original CLID)

[james.g.reed]

Hi Steve

All config has up to now been done through CCA 3.0 however the SIP provide we use is VOIP Unlimited in the UK and there is no XML template for that provider.

Using the CLI command sorted the issue so it has been added to the list for 'things that CCA does not do' for us in the future.

James.