Scott Lawrence wrote: > > This is an instance of a general problem, and the difference > you see is that the return code provided by your ISDN gateway > informed the proxy that the failure was local (no channels at > the gateway) as opposed to end-to-end (the called party > returned 'busy'). > > If sipXbridge can be told about the call restriction, it > could then return an error that would support fallback. > > We struggle with this a lot - many gateways don't return a > good error and then fallback to an alternate gateway cannot work.
It appears that some ITSPs offer a SIP trunk (equivalent to ITSP SIP account) for a monthly per-trunk flat fee. They also limit the number of active calls per trunk. Some may allow customers to pay extra to increase the active call limit per trunk. In some cases it may be cheaper for the customer to buy extra SIP trunk to increase the number of active calls and use both accounts as pooled resources for outgoing calls. For incoming calls ITSP determines which SIP account to use and the decision is made based on the dialed DID number, or other ITSP policy. The situation described in Chris's email is an example of such a case where multiple ITSP SIP accounts are used to increase the limit on the number of active calls. I wonder how common this situation is and whether it makes sense to implement a specific solution for it. In the current sipXconfig/sipXbridge implementation Chris has to create two separate gateways of type "SIP trunk" and associate them with a single dial plan rule. Then when a call is sent to sipXbridge, sipXbridge relies on callerId match to determine which ITSP SIP account to use for the call. If ITSP rejects the call due to call limit we don't roll over to the second account. It might be a good idea to introduce a one-to-many relationship between a SIP trunk and ITSP SIP accounts to better address the problem described above. A single SIP trunk would be associated with multiple ITSP SIP accounts. We introduce a configurable limit on the number of active calls per ITSP SIP account and let sipXbridge track active calls per ITSP account (incoming and outgoing). Due to lack of standardization mentioned in this thread this is better then relying on ITSP to return a well-known error code, but it also requires the customer to know exactly what the per-trunk limit is and provision it manually into the system. In addition we introduce a policy based mechanism to choose ITSP accounts on a per-outgoing-call basis. Supported policies may include random, CallerId-based, round-robin, CallerId-based with no rollover, etc. Thanks, Mark. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
