-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mark Gertsvolf Sent: Sunday, December 13, 2009 9:37 AM To: Scott Lawrence Cc: sipX-dev Subject: Re: [sipX-dev] Caller Id rewriting (or not) for non-local callers
Scott Lawrence wrote: > Hmmm... I suspect you'll disagree with me, but I think the > right way to resolve that inconsistency is to not rewrite the > caller whose gateway used the proxy domain in its From > header. The intent of the caller-id rewriting was to only > rewrite the addresses of local users; at the time, the best > approximation of that we had was to base the choice on the > From header domain. Since we now have authentication for all > local callers, we could change that part of the decision from > 'if the From header domain is our domain' to 'if the caller > is authenticated as a local user'. > The problem with not rewriting CLID for calls arriving from gateways is that it will break call forward and transfer call flows for a number of SIP trunking providers. Whether we agree with them or not, some SIP trunking providers require the PBX to use its provider-assigned CallerID in all outgoing calls. For instance Skype and 3 large carriers requires that. Any call made with incorrect CallerID is rejected. Clearly with these providers you loose the ability to see the real callerID on your cell phone, when your office phone is forwarded to your cell phone. However without the CallerID rewrite you can not forward the call at all. Some carriers who have the same CallerID requirement offer an optional solution for the delivery of the real CallerID: If the call is forwarded by the PBX, CallerID in the "from" header is allowed to be the real callerID, but the INVITE has to include a diversion header with the PBX CallerID. Again, we can argue whether this solution makes sense, but that is the solution they offer. Mark. I have seen at least on carrier that will put in a spurious caller ID if you don't provide one to them. The local ITSP only forwards what is provided, and the larger carrier fills in the blanks with their own number of their choice, and it is unrelated to anything. It created quite a head scratcher when it happened, because they use a number that doesn't exist, causing lots of confusion. Providing a method to cover these instances as a default might make great sense. Todd _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
