On Mon, Sep 22, 2008 at 11:46 AM, Christopher Parfitt <[EMAIL PROTECTED]> wrote: > No there is no issue, do you want an issue raised? > > Chris
I would prefer for an issue to be raised so it can be scheduled. Can you write one up? There will also be some impacts on sipxconfig screens so we will need an issue to modify the sipxconfig screen for sipxbridge as well. Thanks Ranga > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steinmann, > Martin (BL60:2500) > Sent: 20 September 2008 00:57 > To: M. Ranganathan; Chris Parfitt > Cc: sipx-dev > Subject: Re: [sipX-dev] ITSP trunks - Dial Plan Rule - Gateway fallback > > 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 > -- 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
