On Mon, Sep 22, 2008 at 12:33 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > 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. > >
Maybe we are rushing a bit on filing issue so perhaps we should discuss this a bit. Would there be any problem with the following scheme: 1. sipxbridge keeps count of number of calls for a given itsp account. 2. When that limit is reached, if a new call bound for that provider is seen by sipxbridge, then sipbridge cycles ( round robin ) to the next account of that provider. In doing so, of course, it has to re-write From header. But thats OK because it is a back to back ua. 3. If sipxbridge has cycled through all the accounts of a given provider, it can return error code. Note that in this case, the call is not even placed if the limit is reached ( we do not rely upon consistent error code being returned). Would the scheme above do the trick for what we want to achieve without relying upon ITSP behavior? Ranga > > > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- 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
