I also thought and forgot to add, that some users may have a presence in more than one geographical area, and may want to provide local calling to customers or vendors within that area. Some ITSP's do not provide local numbers in all areas, so it sometimes would become necessary to switch providers or have multiple to get adequate coverage.
On Sat, Dec 12, 2009 at 10:30 AM, M. Ranganathan <[email protected]> wrote: > On Fri, Dec 11, 2009 at 5:47 PM, Scott Lawrence > <[email protected]> wrote: > > 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? > > One use case that has been brought up earlier : > > The same ITSP may offer different pricing schemes for different parts > of the world. So you would want all US calls to use one account and > all calls to France to use another account. Both have the same ITSP > domain but you have purchased different accounts for different > domains. > > Another case that came up was a mobile operator (I believe it was > onrelay) that wanted to distribute calls to different servers. Here > the domain is the same but the call distribution would be achieved > through picking the appropriate ITSP account to send the call to. I am > fuzzy about the details here but if anybody from onrelay is reading, > they are welcome to elaborate. > > > > Ranga > > > > > (more on some of the details above later - there are some good questions > > there, but I've got to go off line now) > > > > _______________________________________________ > > 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/ > > > > > > -- > M. Ranganathan > _______________________________________________ > 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/
