Issue with Overwritten Caller ID Prefix for *some* incoming numbers

General Help
1

Strange one for you all. Here’s the call flow:

Inbound call coming across T1, hits inbound route. Inbound route does Set(Callerid(Name)=“Campaign Code”), which is set via FreePBX 2.6 gui. Route sends call to IVR, user pushs zero and is sent to a queue. By the time the call hits the queue, the caller id name (including prefix) has been overwritten. This ONLY happens for some DIDs. The Data appears to be coming from the carrier, as it is typically all uppercase “CITY STATE” data.

I have manually added several NoOp checkpoints in the code (Add exten => s,n,NoOp(Callerid name: ${CALLERID(name)})) and everything is fine UNTIL the call enters the queue. In the full dialplan debugging, we don’t see the

Example call hitting the IVR:

-- Accepting call from '478972XXXX' to '8775551212' on channel 0/9, span 2
-- Executing [[email protected]:1] Set("DAHDI/33-1", "__FROM_DID=8775551212") in new stack
-- Executing [[email protected]:2] Gosub("DAHDI/33-1", "app-blacklist-check,s,1") in new stack
-- Executing [[email protected]:1] GotoIf("DAHDI/33-1", "0?blacklisted") in new stack
-- Executing [[email protected]:2] Set("DAHDI/33-1", "CALLED_BLACKLIST=1") in new stack
-- Executing [[email protected]:3] Return("DAHDI/33-1", "") in new stack
-- Executing [[email protected]:3] ExecIf("DAHDI/33-1", "1 ?Set(CALLERID(name)=478972XXXX)") in new stack
-- Executing [[email protected]:4] SetMusicOnHold("DAHDI/33-1", "default2") in new stack
-- Executing [[email protected]:5] Set("DAHDI/33-1", "__MOHCLASS=default2") in new stack
-- Executing [[email protected]:6] Set("DAHDI/33-1", "__CALLINGPRES_SV=allowed") in new stack
-- Executing [[email protected]:7] Set("DAHDI/33-1", "CALLERPRES()=allowed_not_screened") in new stack
-- Executing [[email protected]:8] Set("DAHDI/33-1", "[email protected] CAMPAIGN ") in new stack
-- Executing [[email protected]:9] Set("DAHDI/33-1", "CALLERID(name)[email protected] CAMPAIGN 478972XXXX") in new stack
-- Executing [[email protected]:10] Goto("DAHDI/33-1", "ivr-19,s,1") in new stack
-- Goto (ivr-19,s,1)

{ snip to reduce post length, but code is just handling IVR “0” key press }

-- Goto (ext-queues,6900,1)
-- Executing [[email protected]:1] Macro("DAHDI/15-1", "user-callerid,") in new stack
-- Executing [[email protected]:1] Set("DAHDI/15-1", "AMPUSER=478972XXXX") in new stack
-- Executing [[email protected]:2] GotoIf("DAHDI/15-1", "0?report") in new stack
-- Executing [[email protected]:3] ExecIf("DAHDI/15-1", "1?Set(REALCALLERIDNUM=478972XXXX)") in new stack
-- Executing [[email protected]:4] Set("DAHDI/15-1", "AMPUSER=") in new stack
-- Executing [[email protected]:5] Set("DAHDI/15-1", "AMPUSERCIDNAME=") in new stack
-- Executing [[email protected]:6] GotoIf("DAHDI/15-1", "1?report") in new stack
-- Goto (macro-user-callerid,s,10)
-- Executing [[email protected]:10] GotoIf("DAHDI/15-1", "0?continue") in new stack
-- Executing [[email protected]:11] Set("DAHDI/15-1", "__TTL=64") in new stack
-- Executing [[email protected]:12] GotoIf("DAHDI/15-1", "1?continue") in new stack
-- Goto (macro-user-callerid,s,19)
-- Executing [[email protected]:19] NoOp("DAHDI/15-1", "Using CallerID "MACON       GA" <478972XXXX>") in new stack
-- Executing [[email protected]:2] Answer("DAHDI/15-1", "") in new stack

The problem is that this ONLY happens for certain inbound callers. I am NOT using any caller id lookup sources. The data appears to be coming from carrier CNAM data (as in “MACON GA”) across the trunk. [Note, the caller ID inserted always appears to be 14 characters, with spaces (forum removes them) between the city and the state, all uppercase] I am assuming that this is being set/overwritten at a lower level than in the dialplan itself, as there is no debug data that indicates a Set operation is being performed between the inbound route and the Queue.

Before I dig into this a little bit further, has anyone ran into this before? Or found a good way to block the CNAM data from coming across the trunk?

Thanks in advance…

2

After doing some extensive PRI debugging, we found that the sequence of events was causing a race condition for the caller ID information from the ISDN line (within the facility message) and the inbound route that sets the Caller ID Prefix.

It turns out that for some lookups, the CNAM data from the carrier was taking a few seconds to come across - and these CNAM transactions can occur in the ISDN specification in an “out of band” manner. In this time, inbound route had already set the caller ID prefix. When the facility message is processed after the inbound route has already been hit, the caller ID prefix is overwritten.

Not necessarily a bug, but an issue with some carriers and the speed at which they deliver CNAM info. This can be solved by modifying chan_dahdi.c and removing the processing of that facility message, or by requesting your carrier to turn off sending CNAM information to you.

Hope this helps,

Josh

3

Thanks for the follow-up.

The other option would be to put an explicit delay in the inbound route (Pause Before Answer) which occurs before the pre-pending of the CNAM field, though this may not be the most desired because of the delay and the DAHDI configuration change seems like the best solution.

4