Tony, Yikes, seems like you've had a rough go. Thanks for the tips. I'll test through those over the coming days and report back.
- Jeff On Thu, Sep 20, 2012 at 5:03 PM, Tony Graziano <[email protected] > wrote: > 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 <[email protected]>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 <[email protected]>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 <[email protected]>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:* [email protected] [mailto: >>>> [email protected]] *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 <[email protected]> >>>> 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 <[email protected]> >>>> 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**** >>>> >>>> [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/ >>>> >>> >>> >>> >>> -- >>> 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 >>> [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! > <http://sipxcolab2013.eventbrite.com/?discount=tony2013> > > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<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/
