With the new caller id regulations coming into play, starting to have FollowMe calls failing if the calling party has their number blocked, or anonymous. The call will ring on a local phone and end up in voicemail, but wont externally send the call out on a sip trunk.
Executing [s@macro-user-callerid:9] ExecIf(“SIP/SIP1-0000024d”, “0?Set(REALCALLERIDNUM=anonymous)”) in new stack
Got SIP response 603 “Declined” back from 184.75.215.114:5060
I have a Route CID set in the outbound route and override extension set to yes, but still fails the call
Have tried setting sendrpid to pai and yes but they didnt seem to make a difference.
Also tried setting a failover trunk, but not sure if thats the right way to go
I dont really want to fix the caller id, still want to pass on the correct caller id if its available. The issue is when the inbound caller doesnt have caller id and it fails when trying to forward out of the system.
Have it working, not sure if its the best way to do it or not, but seems to be working.
So I changed the FollowMe to prefix with a 9 so it will select a certain outbound route.
In the outbound route it uses a standard sip trunk and if there is caller id, the call completes with the callers number. If there is no caller id and it fails, it goes to a second sip trunk that has the Outbound CallerID and Force Trunk CID set and forces the trunk’s inbound callerid and pushes that caller id out with the call
Your provider said “No”. I’d guess that your provider will not let your send a call with a bad CID. You can write a custom outbound context that looks at the caller ID information and adjusts it if the CID is invalid. This might be a good place to start:
Something that worked a couple of weeks ago stopped working recently with the changes to CID requirements. I guess the new regulations are a good thing, just causing a little trouble.
I’ll maybe have to try a little hooking, just hope I dont get myself in trouble!
