That pretty much hit the nail on the head. The SIP provider started out in the residential market and is growing.
We're providing them with help in getting their services up to standards, including (at the moment) helping them make a case to the switch vendor that the switch is not handling the re-INVITE correctly. Hopefully after we've helped them get past their growing pains they'll be a very good SIP provider. They have been extremely responsive to our suggestions, and they are currently looking to hire additional persons with strong SIP experience. My experience with SIP providers so far (including "big name" providers like Voxitas) is that none of them have everything working completely smoothly yet, so hopefully our provider has time to get some issues worked out and start providing quality business class service before the market is completely dominated by a few large providers. Anyone in the Grand Rapids, MI metro area with a good resume looking for an opportunity with a small company with growth potential? :) Mike Burden [cid:image002.gif@01CB4903.5BDD4B30] Lynk Systems, Inc e-mail: m...@lynk.com<mailto:m...@lynk.com> Phone: 616-532-4985 From: Tony Graziano [mailto:tgrazi...@myitdepartment.net] Sent: Tuesday, August 31, 2010 11:37 AM To: Burden, Mike Cc: sipx-users Subject: Re: [sipx-users] REFER vs INVITE for transfers I don't know of a way to do that unless you use an independent SBC instead of sipxbridge and tell it to allow REFER for that dialplan/trunk (provider). At the same time I don't see how it would be desirable to introduce that into sipxbridge (enable/disable refer). I am assuming your ITSP is a residential provider and not a real business class provider (or their switch vendor is in the residential market)... On Tue, Aug 31, 2010 at 11:30 AM, Burden, Mike <m...@lynk.com<mailto:m...@lynk.com>> wrote: Good morning, I have an ITSP that is currently battling with a switch vendor on my behalf, because when we transfer a call from extension to extension, we lose audio. The switch vendor is pointing out that they are not getting a REFER from us. This, of course, is because sipXbridge translates the REFER into an INVITE. So... seems you can't win either way. Many ITSPs apparently don't handle REFER correctly. Ours apparently doesn't handle a re-INVITE correctly. Obviously the correct long term solution is for the switch vendor to fix their switch. In the meantime, is it possible to disable this behavior in the sipXbridge? I've poked around the sipXbridge page on the sipXecs SBC page, but don't see anything that looks like it would do this. Mike Burden [cid:image002.gif@01CB4903.5BDD4B30] Lynk Systems, Inc e-mail: m...@lynk.com<mailto:m...@lynk.com> Phone: 616-532-4985 _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org<mailto: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<mailto:tgrazi...@voice.myitdepartment.net> Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net<mailto:tgrazi...@myitdepartment.net> LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net<mailto:helpd...@voice.myitdepartment.net> 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.
<<inline: image001.jpg>>
<<inline: image002.gif>>
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
