Manual FWD to 800 number on PRI

[dwayneg]

I need to fwd to an answering service after hours.  Pretty simple, create phantom and manually forward it.  Problem is, you can't fwd to an 800 number if the trunk group is set to propagate original caller ID.  I guess this is because they need true caller ID to bill the 800 call correctly.
I'm not propagating caller ID on this particular phantom, but doesn't seem to matter...if trunk group flag is yes, it won't work, call fails (local and LD work fine).  I hate to lose that caller ID on extensions using cell twinning, so really want to keep propagating on.
My current solution is that I've forwarded that phantom to a LS port looped to a SL port, so 800 call leaves on a LS line, no problem, then re-enters on SL and leaves again as a call dialed by the SL port, so again no problem.  Works, but not an elegant solution.
Anyone have a better idea? 

[Tech Electronics]

Dwayneg,

Couldn't you just change the phantom to not propagate and then set its Calling Party Number to be the BTN of the PRI; which should be a valid number?

Thanks,

TE

[dwayneg]

Really looking for a way to get the best of both worlds: propagate CLID on twinned calls to cells, but allow FWD to 800 number.  I thought maybe just turning off propagation on the forwarded phantom might work, but that's not the case...if its on for the trunk group no more fwd to 800, regardless of individual station setting.

[Tech Electronics]

Dwanyneg,

Huh, I never had that issue before. I can have Propagate Caller ID on the Trunk Group turned on, with nothing in the Calling Party Number or Name Fields, and have it turned off on a phantom and it doesn't pass anything but what I put in the Calling Party Number field.

What if you put something in the Calling Party Number field of the Trunk Group; does it work then?

Thanks,

TE

[dwayneg]

Yes, I've tried plugging numbers in to the TG and also tried in the ext, no help.  My gut feeling is that we might be sending something to the carrier warning that CLID might be spoofed...but I can't prove it.  I wonder how 5000 knows its an 800 call...maybe the route group patterns?  If there were somewhere I could convince the 5000 its not a toll free that might do it.

[Tech Electronics]

Dwayneg,

Have you looked at the setup message and verified what was being sent and the cause codes for it?

Thanks,

TE

[dwayneg]

Logged a ticket with Mitel, they agree issue is as described, no way to change setup info.  So I'm asking client to try for a "regular" number from answering service.  Thanks for the suggestions.