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? -----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
