There are two restrictions to keep in mind. First, if you're using analog lines, then it can only pass the caller ID of the analog line outward to the cell phone. Secondly, we ran into an issue with EC500 on our Definity (similar feature to follow me) using a PRI where when we would have the system call our cell phones, it would show our main outbound caller ID instead of the caller ID of the person calling. We found the problem was the LEC was not allowing us to send any caller ID, but only the caller ID of a valid DID on our PRI circuit.
Aside from those two issues, I'm not sure if there's something on the IP Office side, but just thought I'd give you a heads up on what I've run into in the past.
Thanks for the reply. What you say absolutely makes sense, but I don't think our LEC is blocking outbound CallerID outside our DID ranges; we accidentally had 4-digit outbound callerid when we made a mistake in the programming. And we are on PRI, obviously.
Anything in the programming, anyone? It seems that the CallerID would be blocked, rather than the DID (*not* the main number) coming through for forwarded calls.
If you would like to send me a copy of your configuration I would be happy to look at it and see what you need to change. I am assuming that the 912135551212 is the phone number of the party calling the cell phone. You may email the configuration to bstewart at ccitelecom dot net if you want. I'll be happy to look at it when I get a chance.
NOTE:
This only works if the PRI provider allows an open ANI path(ability to send caller id). Most providers use the source caller id for billing purposes so that appending ss to the end of a dial shortcode will fail or tell you something like your service is disconnected or in the case of fowarding to a long distance number you will hear your service providers long distance error.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.