Do we have an issue on this? I thik it is reasonable to assume that the ITSP has to kind of do the right thing, although I do like Ranga's pragmatic approach. Gateway fallback is a very useful feature especially if you use different ITSPs or a mix between ITSPs and PSTN lines. --martin
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M. Ranganathan Sent: Friday, September 19, 2008 10:24 AM To: Chris Parfitt Cc: sipx-dev Subject: Re: [sipX-dev] ITSP trunks - Dial Plan Rule - Gateway fallback On Fri, Sep 19, 2008 at 9:08 AM, Chris Parfitt <[EMAIL PROTECTED]> wrote: > I think this is a different issue that the general one you explained below. > This is why: > When I setup a Dial Plan Rule with a SIP Trunk ITSP Gateway as first > choice and an ISDN Gateway as second choice the fallback works fine > when the ITSP has Max number of calls. > So the return error from the Gateway ITSP must be ok as the call > successfully falls back to the ISDN Gateway. > > Ranga can you explain why the fallback does not work from different > SIP Trunk gateways but on using the same ITSP supplier? I did not claim it will not work -- only that the provider must be consistent and respectful of the SIP protocol. If the provider consistently returns an error code 5xx for example, I can cycle to the next trunk for that provider. However if the provider returns 4xx error (busy for example ) instead of 5xx, I cannot do much other than return that error to the caller. Providers work in mysterious ways so I can experiment and find out and document which are the more consistent ones if you would post a requirement that we need to support this and if that requirement is approved for a sprint as a deliverable. Regards Ranga > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Scott > Lawrence > Sent: 19 September 2008 13:54 > To: Christopher Parfitt > Cc: sipx-dev > Subject: Re: [sipX-dev] ITSP trunks - Dial Plan Rule - Gateway > fallback > > > On Fri, 2008-09-19 at 12:02 +0100, Christopher Parfitt wrote: >> Hi All, >> I would like to get advice on this scenario that fails with >> 3.11.6: >> I have 2 ITSP SIP Trunk Gateway accounts each ITSP account will allow >> a Maximum of 3 simultaneous calls I have set up my Dial Plan rule so >> that both the above SIP trunks have been added to the rule. >> I then "fill" the first SIP Trunk with 3 outgoing calls I then make a >> 4th outgoing call it fails with busy tone The customer expected >> result is: the 4th call uses the next SIP Trunk ITSP Gateway defined >> in the Dial Plan Rule >> >> If we are not going to support this configuration then we will have >> to clearly state this in customer Docs i.e. that a dial plan rule >> with fallback configured from ITSP trunks to other ITSP trunks is not >> supported. >> >> Note I have tested this same dial plan rule scenario using a mix of >> ITSP and an ISDN Gateways and that works as expected, i.e. if the >> ITSP gateway was full the call fell back to ISDN. Or if the ISDN >> Gateway was full the call fell back to the ITSP Gateway > > 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. > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > > _______________________________________________ > 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 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
