I have a provider that sends the main TN on all calls without a number (anonymous).
On Sun, Dec 13, 2009 at 12:55 PM, Todd Hodgen <[email protected]> wrote: > > > -----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/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ 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/
