Using one ITSP for domestic calls and another for International. On Sat, Dec 12, 2009 at 2:20 AM, Todd Hodgen <[email protected]> wrote:
> > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Scott Lawrence > Sent: Friday, December 11, 2009 2:48 PM > To: Mark Gertsvolf > Cc: sipX-dev > Subject: Re: [sipX-dev] SIP trunk gateway selection by sipXbridge > > On Fri, 2009-12-11 at 17:11 -0500, Mark Gertsvolf wrote: > > This post is in reference to http://track.sipfoundry.org/browse/XX-7235 > > > > sipXecs dial plan logic is implemented in sipXproxy. sipXbridge > > maintains ITSP accounts (SIP trunk gateways) and it is in charge of the > > ITSP account selection when handling outgoing calls. > > Even though sipXproxy dial plan logic knows the ITSP account (SIP trunk > > gateway) chosen for a particular call it does not tell sipXbridge > > explicitly what the account is. Instead it sets the domain name in R-URI > > and also sets the CallerID ("from" header) before sending the request to > > sipXbridge. > > > > In order to find the right ITSP account sipXbridge looks at the target > > domain in R-URI and finds the ITSP account with matching domain. If > > there are multiple ITSP accounts with the same domain the "from" header > > is used for disambiguation. > > > > This mechanism to signal the choice of ITSP account from sipXproxy to > > sipXbidge is not sufficiently reliable. It breaks when multiple accounts > > exist with the same target domain name and when an external caller is > > making a call, which is routed to sipXbridge. In case where the caller > > is external sipXproxy CallerAlias plugin refuses to manipulate the > > CallerID and the disambiguation of the ITSP accounts does not work. > > > > It is not totally clear to me why CallerAlias does not manipulate > > CallerID for external callers, but regardless, it seems that the current > > communication mechanism between the dial plan logic and sipXbridge is > > not good enough. > > > > I think a better mechanism is required to communicate the ITSP account > > information to sipXbridge rather then letting it guess which account to > > use. > > In the past similar communication details have been sent between sipXecs > > components via proprietary headers. Is there a room for another such > > header (something like: X-Sipx-itsp-account) to communicate the ITSP > > account name to sipXbridge. > > > > Comments? > > I'd like to start with a question... > > What is the point of having multiple ITSP 'accounts' to the same domain? > What is different about them and why do they exist? > > (more on some of the details above later - there are some good questions > there, but I've got to go off line now) > > > > An example of multiple ITSP "Accounts" to the same domain. > > System installed for one company that sublets some of their empty office > space, however, the sublets need trunks for their own set of billing > requirements. One way to handle is separate domain names if the ITSP > supports this, but if they don't, then you need a method of identifying > calls from one group of users to use one specific group of trunks for > billing purposes. > > _______________________________________________ > 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/ > > _______________________________________________ > 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/
