I would think that you absolutely could solve the problem with an Ingate...
Mike From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Thursday, February 18, 2010 3:12 PM To: Andrew Cotter Cc: Sipx-users list Subject: Re: [sipx-users] Up a creek.... On Thu, Feb 18, 2010 at 3:00 PM, Andrew Cotter <[email protected]> wrote: Anyone have a paddle? Thank you everyone for the suggestions of the past few weeks. My saga with AT&T may be coming to an end, unfortunately in a negative way. AT&T is starting to pull at straws since they have basically denied my requests for both a port change for signaling (5080 for sipXbridge) and enabling the B2BUA feature in their managed router. Both of which I understand may have fixed my issue. The main issue is that don't support REFER (like a lot of ITSP it sounds) which screws up transfers. This messes with incoming calls to a handset or the AA which we need when it comes to transfers. This basically renders the AA useless. Transfers, MOH, etc. too. I have a couple of people on their end pulling for me and looking to iron this out. Getting AT&T labs involved, etc. Couple of options I wanted to run by everyone. Looking for a sanity check if it is possible and how difficult if it could even work. Some may be crazy I know.... Lack of sleep and head is throbbing after banging it against the wall repeatedly. 1) Have AT&T configure their router to do a port mapping (incoming 5060 --> 5080) No. If you support remote workers you need to understand that this will require a lot more on your end. 2) Have AT&T hand this off to us not via SIP, but a PRI Don't forget to get a PRI SIP gateway to go with that. 3) Add something in between the SIP trunk and SipX. InGate? (stab in the dark) Might work, but if they initiate the signalling on port 5080, it also means the call further breaks because they are not routing to your SBC after that, so adding an Ingate in will likely see the same result. 4) Ditch the great system called SipX in which I was really looking forward to the 4.2 release, for some other open source or commercial product (boooooo!) Anything else? Thanks! Andrew Ranga swears it is working well with AT&T. Maybe the standard sip trunking works, but their FLEX IP product does not, which sits INSIDE your network. I'd swing a Louisville slugger around and tell them to change the port to 5080 or else, but then I would have been through my checklist before signing off on anything. 1. Get a different ITSP, we sell bandwidth.com and never have these issues. 2. Move from their FLEX (which must be an integrated T1 or something?) product. 3. Have them change the signalling port. 4. Use a PRI (assuming you need a lot of call paths). Truth be told, if they ARE NOT willing to setup signalling on another port, it makes me want to run away too. Ranga - Do you know what the official AT&T product is called that sipXbridge was tested against? Tony
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
