http://www.acmepacket.com/default.asp I know several large providers use them. I believe Verizon does.
On 4/13/2010 6:45 PM, Tony Graziano wrote: > What the heck is an > ACME. Was it installed by a long nosed tech name Wile E. Coyote? > > > On Tue, Apr 13, 2010 at 7:25 PM, Josh Patten<[email protected]> wrote: > >> sipXbridge, the SBC built into sipX, should be handling this for you. Your >> ITSP must be able to send the SIP traffic to port 5080 on your server. >> >> Shawn Westerhoff wrote: >> >> Thanks Tony, >> >> The SIP provider is O1 Communications in Sacramento, CA and they say they >> can not support REFER method with the ACME (1000 I think) they are using. >> We connect to O1 via private MPLS so no NAT is involved, no Internet. >> >> We are on 4.04. Are you saying we can change the method used to use INVITE >> rather than REFER during a transfer? That would be fantastic. >> >> On Apr 13, 2010, at 3:56 PM, Tony Graziano wrote: >> >> >> >> What version are you using? Who is the ITSP and what SBC are you using >> to separate sipx from the Internet? >> >> sipXbridge is capable of doing that in 4.0.4 (current stable version), >> with a properly configured firewall. 4.1.7 offers only minor >> improvements to sipXbridge. >> >> >> >> On Tue, Apr 13, 2010 at 6:52 PM, Shawn Westerhoff<[email protected]> wrote: >> >> >> We use a SIP provider that can not handle REFER during a call >> transfer. We are seeking a way around this short of moving to 4.1.7 >> development release where we understand the issue has been fixed by >> using a RE-INVITE (or INVITE again, not sure if RE-INVITE is even a >> term we should be using). >> >> Our problem is with calls that originate on the PSTN, they get through >> to the extension just fine (Polycom 650) but if that call is >> transferred to any other extension, the upstream SBC drops the call. >> This is a total showstopper as the Auto Attendant can't even direct to >> extensions. Our SIP provider says they have no solution. >> >> One solution we thought of was to use another SBC rather than the one >> in SipXecs, OpenSBC. Any thoughts on this would be appreciated. >> Looks like we will try the developer release to confirm it fixes the >> issue. >> >> -- >> Shawn Westerhoff >> Turn 11 Networks, Inc. >> [email protected] >> direct: 415-300-4224 >> Professional IT Services / Cloud Computing / VOIP >> www.turn11.com >> _______________________________________________ >> 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/ >> >> >> >> -- >> ====================== >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> Fax: 434.984.8431 >> >> Email: [email protected] >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> Fax: 434.984.8427 >> >> Helpdesk Contract Customers: >> http://www.myitdepartment.net/gethelp/ >> >> Why do mathematicians always confuse Halloween and Christmas? >> Because 31 Oct = 25 Dec. >> >> >> _______________________________________________ >> 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/ >> >> >> _______________________________________________ >> 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/ >> >> > > > _______________________________________________ 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/
