Will check the askozia article if I can find something in there to help me out :) But it can be easily reproduced bij anyone, no asterisk is needed to encounter this behavior. Just add a custom dial rule to your dial plan, which matches 666 and 10 digits, and then try to dial a mobile number while you are not allowed to. It will work anyway. Perhaps this bug is fixed in 4.6 or will be fixed in 4.6, in that case some info might come in handy and perhaps we can backport this fix in 4.4....
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: donderdag 10 januari 2013 15:30 To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] Strange behavior in dial plan regarding permissions Since the Asterisk box is setup as a user also "I think" it creates a circular logic which might actually defeat dial plan permissions. You might consider a different way to connect to the Asterisk box. (hint: the askozia article shows a method that might be compatible using an SBC, which is why I suggested it.) I would consider posting to the sipx-dev list. I am not sure it would be "fixed" if considered a bug in 4.4 (instead maybe just for 4.6 though). On Thu, Jan 10, 2013 at 9:20 AM, Henry Dogger <[email protected]> wrote: > I have seen this interesting setup, but since we are also developing on > asterisk as we do on sipXecs, we would lose this option. > But it really shouldn't behave like this in my opion, since I can also > imagine using such a dial rule when using just sipXecs.... > Any thoughts on the bug/problem? > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Tony > Graziano > Sent: donderdag 10 januari 2013 14:06 > To: Discussion list for users of sipXecs software > Subject: Re: [sipx-users] Strange behavior in dial plan regarding > permissions > > I think this would behave differently using asterisk as a gateway. > > Have you considered this? > http://wiki.sipfoundry.org/display/sipXecs/ACD+solution+based+on+Askoz > ia > > Since it passes through a SBC it should not be required to make the dialplan > adjustments you are using. > > On Thu, Jan 10, 2013 at 7:59 AM, Henry Dogger <[email protected]> wrote: >> Hi all, >> >> >> >> We stumbled some time ago on a strange behavior in the dial plan >> regarding the dial permissions. >> >> The situation is as follows: >> >> >> >> We have a few dial plan rules e.g. >> >> - Mobile phones (required is the mobile call permission) >> >> - Local numbers (required is the local call permission) >> >> - International (required is the international call permission) >> >> >> >> This all works as aspected, a user without the mobile call permission >> is not allowed to call mobile phones. >> >> But part of our normal setup is a SIP connection between a sipXecs >> and a Asterisk, calls are being routed from asterisk to sipXecs and >> the other way around. (the reason why we use an Asterisk is because >> of the queue functionality, ACD in sipXecs is not satisfying and also >> openACD is still not good enough for us.) >> >> Since registering the asterisk as a user on sipXecs is a problem we >> decided to create a dial rule in the dial plan with a (to all users >> on the system) unknown prefix (e.g. 666). >> >> So the custom dial rule we created is 666 and 10 digits will result >> in a dial of the last 10 digits on the gateways configured for outbound >> calls. >> >> The problems we get with this dial rule are: >> >> - The rule has to be on top of the other outbound dial rules >> (Mobile, Local and International in this example) to work, otherwise >> sipXecs responds with a unauthorized to Asterisk. >> >> - When this rule is active, all other outbound dial rules (Mobile, >> Local and International in this example) can be called by all users, >> even the users without the desired call permissions, so somehow this >> rule breaks the entire permissions system.... >> >> >> >> I am curious if this is normal behavior, or did we stumble upon a bug? >> >> We are currently running on 4.4 updated till patch 16. >> >> >> >> Kind regards, >> >> >> >> Henry Dogger >> >> Telecats BV >> >> >> >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > -- > ~~~~~~~~~~~~~~~~~~ > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.465.6833 > ~~~~~~~~~~~~~~~~~~ > Linked-In Profile: > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > Ask about our Internet Fax services! > ~~~~~~~~~~~~~~~~~~ > > Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013! > > -- > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > > Helpdesk Customers: http://myhelp.myitdepartment.net > Blog: http://blog.myitdepartment.net > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013! -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
