On Sun, 2008-09-21 at 12:04 -0400, Gertsvolf, Mark (CAR:9D30) wrote: > 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.
There is nothing ITSP-specific about this problem. We have exactly the same set of issues with any multiple-trunk or multiple-gateway configuration regardless of the technology at the gateway. The proxy behavior is already what we need it to be (modulo any bugs in response handling, which we already have issues for and are working on for 4.0), and it will fail over just fine if the gateway (and an ITSP is just a gateway for this purpose) makes the right distinction between "unable to make a call due to some local or network resource restriction" and "call reached the target and the target returned busy". If there is anything to be done in sipXbridge, I think it is only to make sure that it communicates that distinction correctly when the ITSP sends something, and does the right thing when it has some local resource limit of its own. If the gateway does not make that distinction then there is little we can do about it. Retrying another gateway when you get a real "end-to-end" busy indication is a lose in another way that is also irritating - the "ring-twice problem": Suppose that I have two gateways that return "busy" when they run out of trunks (instead of a 5xx error), but I want fallback to work, so I change sipXecs to fallback on busy (no, you can't change this with configuration - I'm talking about hacking the code). Now I forward my line to my cell phone and go on the road. Someone calls and I'm either on another call or decide not to answer (based on seeing who it is), causing the PSTN to return 'busy' - the 'busy' gets back to sipXecs, which tries again on the other gateway. My phone rings again (the PSTN can't tell this is the same call); very annoying. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
