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/
