-----Original Message----- From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Matthew Kitchin (public/usenet) Sent: Thursday, August 19, 2010 8:11 PM To: Martin Steinmann Cc: sipx-users@list.sipfoundry.org Subject: [sipx-users] Remote office (was: port 5060/ port 5080, proxy why?
On 8/19/2010 9:26 PM, Martin Steinmann wrote: >> I went through the requirements in detail on this list, and I never >> could find a plan that would work. >> There were 2 huge issues. >> 1)I never understood a way I could have a seamless transition to an fxo >> for outbound calls if the connection to the central office went down. > Audiocodes GWs can do this. It became stable starting firmware release 5.8 > and it is supported in sipXecs 4.2. > http://wiki.sipfoundry.org/display/xecsuserV4r2/AudioCodes+6.00+Stand-Alone+ > Survivability > >I started with 4.0.2, so perhaps this is something that may have worked, >but wasn't available at the time. I am using Audiocodes MP 114s for the >backup gateway. >My outbound traffic at the remote location needs to be SIP. It seems I >have to have an SBC of some sort at the remote office (discussed more below) Questions here - Are you saying that you need to have calls access FXO trunks if your SIP trunks fail - when they are connected to the sipxbridge? Or, do you want calls to access calls via a diverse route located at a different location. Unless I'm really missing something here, it seems you should be able to do either scenario. > A second option would be to configure the local gateway as an emergency > gateway in the phones. For Polycom phones you can do this through the UI on > the phone screen adding a line, then go to tab Dial Plan. If the main route > to sipXecs cannot be found, the phone uses the 2nd one, which points at the > local GW. You can configure this on the phone group level as well. > >Is it possible for the user to dial any call exactly the same on the >handset with no knowledge of whether or not their primary SIP connection >is down? Yes, this should be transparent to the caller. >> 2)I never understood a way I could make the call traffic go in and out >> the local mpls connection at the remote office without putting a local >> sipx device of some sort at the remote site. My understanding was if >> sipx supported media release, this would have been possible. > Explain 'media release'. sipXecs separates media from signaling and local > media stays local. > >Maybe that isn't the correct term. That is what Verizon called it. In >this case, it is the ability for the Sipx server to drop out of the >picture for RTP traffic. Asterisk can do this. I was under the >impression Sipx couldn't do this by design since it was a proxy. I need >the sip RTP traffic for a remote site to go in/out their local MPLS >connection. I can't have it coming back through our corporate office. >Here is a description: >http://www.voip-info.org/wiki/view/Asterisk+sip+directrtpsetup >All my endpoints can access each other. There is no IP NAT involved. >Verizon sends calls to our servers by their actual IP and could >communicate directly with the handsets if needed. >This is what my VoIP carrier wanted to do. Sip signaling would go >through the corporate office, but RTP traffic would go directly to and >from the remote site. I think the issue is that if your calls are anchored to the sipxbridge, then you have to have your calls continue to go through that bridge. Calls that are routed from phone to phone would not be using the bridge, and would be UA to UA calls, operating like you describe. I think that Martin's team should be able to come up with a solution for this, using current release of software, and current products. >> I wanted to do what you describe, but I was unable to find a way to >> make it work for us. I'll be glad to keep discussing if you think there >> is a way. >This was my initial conversation on the topic: >http://www.mail-archive.com/sipx-users@list.sipfoundry.org/msg10781.html >I would love to find a way to make it work. I hit a roadblock with every >scenario I worked on. Regardless of the outcome, this is a great conversation to have, and if it can't be done now, a healthy discussion will help understand what is required to make it work, and if it can be done, a healthy conversation will help to understand what is required to make it work. > --martin > >> -----Original Message----- >> From: "Martin Steinmann"<mstei...@gmail.com> >> Date: Thu, 19 Aug 2010 21:49:43 >> To:<mkitchin.pub...@gmail.com>; 'Michael >> Scheidell'<michael.scheid...@secnap.com>;<sipx- >> us...@list.sipfoundry.org> >> Subject: RE: [sipx-users] port 5060/ port 5080, proxy why? >> >> Why not a centralized deployment with only phones and optional gateways >> in >> the remote office? Having to manage 110 small ITX boxes does not >> sound >> pretty. >> --martin >> >>> -----Original Message----- >>> From: Matthew Kitchin (Public) [mailto:mkitchin.pub...@gmail.com] >>> Sent: Thursday, August 19, 2010 9:43 PM >>> To: Martin Steinmann; 'Michael Scheidell'; sipx- >>> us...@list.sipfoundry.org >>> Subject: Re: [sipx-users] port 5060/ port 5080, proxy why? >>> >>> Using 2 hosts (sipxbridge on a dedicated one) was the other option we >>> looked at. I didn't do it for 2 reasons. I was a total novice and >>> wanted to keep things simple. And, our corporate office was the model >>> we would follow at our 110 small remote locations. We wanted to do >>> small mini itx (on a bberry, I think that is what they are called) >>> boxes at the small sites, and adding a second box wasn't practical. >>> -----Original Message----- >>> From: "Martin Steinmann"<mstei...@gmail.com> >>> Sender: sipx-users-boun...@list.sipfoundry.org >>> Date: Thu, 19 Aug 2010 21:30:34 >>> To: 'Michael Scheidell'<michael.scheid...@secnap.com>;<sipx- >>> us...@list.sipfoundry.org> >>> Subject: Re: [sipx-users] port 5060/ port 5080, proxy why? >>> >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
