Some might argue it "should" work this way too (as in how it works now), since the first user does not have the security to send the call where the second user does...
You might be sure to test attended transfers and directed call pickups. That's where they failed before. They have gotten better since they finally added REFER support, but you might also want to test park retrieve and park call return too. Post back on what they choke on if you would be so kind. On Thu, Sep 20, 2012 at 11:30 AM, Jeff Pyle <jp...@fidelityvoice.com> wrote: > Michael, > > I have a number of TA900-series Adtrans on my network, and I'm familiar > with most of the ins and outs of their configuration. You're right, > they're not perfect, but I've become quite satisfied with them. I'm > curious what issues you've encountered. > > In this particular sipX test scenario, I have a single Adtran gateway > configured in sipX as an "Unmanaged gateway". All the signaling everywhere > in the system is private; no NAT or public traffic exists. This is not a > "SIP Trunking" issue as sipX defines it because I don't have a "SIP Trunk" > defined with sipXbridge. > > Regardless, the signaling for the outbound leg of the call doesn't make it > out of sipXproxy towards the Adtran in the failing scenarios. Captures > have shown sipXproxy denies it with a "403 Requires" rejection. Joegen has > said this is because of a long-standing 302 bug where permissions are not > inherited correctly. The provider/gateway is irrelevant because the call > is dropped within sipX before it even tries to contact the > provider/gateway. Even if I were to light up a trunk with voip.ms as > Todd suggests and configure it with sipXbridge, in this scenario sipXproxy > would reject the call before it got to sipXbridge (tested), and certainly > before it got to voip.ms. > > Summarizing Joegen's explanation, the call is denied because of a > permissions problem. What if I were to edit the Local dial plan to change > the permission requirement from the default "Local Dialing" to "None"? > That way an unauthenticated user (with no permissions), including an > external gateway, should be able to send a call through the matching dial > plan. > > And it worked! I could call the user with the call forward from a user > without the Local permission, and the forward executed correctly. Same > thing from an external call routing in through the PRI. Good stuff. > > Clearly there's a security issue leaving it like this. I look forward to > the day when the 302/permissions problem is resolved. Thanks to everyone > for your thoughts and suggestions. And if anyone has other thoughts about > how to work around the 302 problem in a more secure way, I'd love to hear > it. > > > - Jeff > > > > > On Thu, Sep 20, 2012 at 9:12 AM, Michael Picher <mpic...@ezuce.com> wrote: > >> Well, those adtrans are known to have some SIP issues in working with our >> platform... >> >> Josh can speak up but we've tested them every so often and from what I >> know from about 4 months ago they still hadn't ironed out all of the >> signalling issues they have. >> >> Mike >> >> >> On Thu, Sep 20, 2012 at 9:06 AM, Todd Hodgen <thod...@frontier.com>wrote: >> >>> That feature works today, as AFAIK, has worked for years. Incoming >>> calls to an extension, can have forwarding set to ring at the same time, or >>> at the end of a timed period. There is no magic to that, the feature just >>> works.**** >>> >>> ** ** >>> >>> Something in your particular setup is keeping that from working. **** >>> >>> ** ** >>> >>> Don’t want to sound like a broken record, but try using another group of >>> trunks – for example, order some VOIP.ms trunks, which are very low cost, >>> and get them working. It will give you a known working scenario to test >>> from, and give you some call details to do stare and compare with to see >>> what might be your issue.**** >>> >>> ** ** >>> >>> *From:* sipx-users-boun...@list.sipfoundry.org [mailto: >>> sipx-users-boun...@list.sipfoundry.org] *On Behalf Of *Jeff Pyle >>> *Sent:* Thursday, September 20, 2012 5:50 AM >>> *To:* Joegen Baclor >>> *Cc:* Discussion list for users of sipXecs software >>> >>> *Subject:* Re: [sipx-users] Call forward fails to external number**** >>> >>> ** ** >>> >>> Is there a workaround to allow a user to forward externally sourced >>> calls to external numbers? Perhaps by disabling a permission requirement >>> somehow?**** >>> >>> ** ** >>> >>> ** ** >>> >>> - Jeff**** >>> >>> ** ** >>> >>> ** ** >>> >>> On Wed, Sep 19, 2012 at 11:53 PM, Joegen Baclor <jbac...@ezuce.com> >>> wrote:**** >>> >>> This is a long standing issue and is all about 302 redirects not able to >>> grant permissions of the called number to the caller. On top of this, >>> branches will also be enforced if you have set one. The caller will not >>> inherent the branch where the callee is located.**** >>> >>> >>> >>> On 09/20/2012 10:04 AM, Jeff Pyle wrote:**** >>> >>> On Wed, Sep 19, 2012 at 5:56 PM, George Niculae <geo...@ezuce.com> >>> wrote: **** >>> >>> ** ** >>> >>> It's not about tailing logs only but it also captures other config >>> from your system. However in your case tailing proxy and reg logsand >>> post them back here would suffice.**** >>> >>> ** ** >>> >>> ** ** >>> >>> The proxy and registrar logs are attached.**** >>> >>> ** ** >>> >>> User 1821 is set to ring for 4 seconds, then forward to 2169311212. >>> User 1821 can call 2169311212 with no problem (has Local permission).** >>> ** >>> >>> ** ** >>> >>> In this test, User 4821 called user 1821, but since User 4821 does not >>> have the Local permission, the call went to 1821's VM box instead of to >>> 2169311212. If I re-enable Local permission for 4821, the call forward >>> on 1821 succeeds.**** >>> >>> ** ** >>> >>> ** ** >>> >>> - Jeff**** >>> >>> ** ** >>> >>> ** ** >>> >>> _______________________________________________**** >>> >>> sipx-users mailing list**** >>> >>> sipx-users@list.sipfoundry.org**** >>> >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/**** >>> >>> ** ** >>> >>> ** ** >>> >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> >> -- >> Michael Picher, Director of Technical Services >> eZuce, Inc. >> >> 300 Brickstone Square**** >> >> Suite 201**** >> >> Andover, MA. 01810 >> O.978-296-1005 X2015 >> M.207-956-0262 >> @mpicher <http://twitter.com/mpicher> >> linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro> >> www.ezuce.com >> >> >> ------------------------------------------------------------------------------------------------------------ >> There are 10 kinds of people in the world, those who understand binary >> and those who don't. >> >> >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: tgrazi...@voice.myitdepartment.net 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! <http://sipxcolab2013.eventbrite.com/?discount=tony2013> -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
