Right, that too. ============================ 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/ ----- Original Message ----- From: Matthew Kitchin (Public) <[email protected]> To: Tony Graziano <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]> Sent: Fri Aug 20 07:44:25 2010 Subject: Re: [sipx-users] Remote office (was: port 5060/ port 5080, proxy why? I thought the SBCs did some other things as well with refer and such. -----Original Message----- From: Tony Graziano <[email protected]> Date: Fri, 20 Aug 2010 07:37:17 To: <[email protected]>; <[email protected]>; <[email protected]> Cc: <[email protected]> Subject: Re: [sipx-users] Remote office (was: port 5060/ port 5080, proxy why? Example: when I install a patton gateway it is just a local ip address in sipx. Users dial a number and sipx sends the call to the patton. When the user is connected I demonstrate UNPLUGGING the ethernet cable from sipx while on that call because the media is peer to peer, in this case with the gateway. The same worked on an internal call. It is different when the call has to traverse NAT, which is why media is typically anchored. That's why sbc's are used. ============================ 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/ ----- Original Message ----- From: Matthew Kitchin (Public) <[email protected]> To: Tony Graziano <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]> Sent: Fri Aug 20 07:32:07 2010 Subject: Re: [sipx-users] Remote office (was: port 5060/ port 5080, proxy why? No. I didn't know anything about that option at the time. I'm still a little fuzzy on how that works. -----Original Message----- From: Tony Graziano <[email protected]> Date: Fri, 20 Aug 2010 07:30:26 To: <[email protected]>; <[email protected]>; <[email protected]> Cc: <[email protected]> Subject: Re: [sipx-users] Remote office (was: port 5060/ port 5080, proxy why? Did you try making the itsp an unmanaged gateway? If the phones don't traverse nat, but simply can route to the gateway (carrier) address, this would be feasible otherwise if they traverse nat, its an entirely different discussion, which I think we went through a while back. ============================ 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/ ----- Original Message ----- From: [email protected] <[email protected]> To: Todd Hodgen <[email protected]>; 'Martin Steinmann' <[email protected]> Cc: [email protected] <[email protected]> Sent: Fri Aug 20 07:24:18 2010 Subject: Re: [sipx-users] Remote office (was: port 5060/ port 5080, proxy why? Sorry. On a BBerry, and can't respond inline. Normally, all calls go in and out Verizon SIP trunk that uses al local MPLS connection. Corp office is in Nashville, TN and we have facilities all over the country. we can't have the RTP traffic coming back through Nashville. So, normal calls go in/out local SIP trunk. If the MPLS connection goes down, outbound calls go out a local Audiocodes FXO using a backup POTS line. We don't worry about inbound in this scenario. It is critical that outbound calls seamlessly transition to the backup method. With media anchor/media release, I'm not talking about internal handset to handset calls. I'm talking about calls to the PSTN through our carrier. My understanding is that some platforms can set the call up where the RTP traffic flows directly from the handset to the ITSP. I don't believe Sipx can do this. Does that make sense? -----Original Message----- From: "Todd Hodgen" <[email protected]> Date: Fri, 20 Aug 2010 00:01:45 To: 'Matthew Kitchin \(public/usenet\)'<[email protected]>; 'Martin Steinmann'<[email protected]> Cc: <[email protected]> Subject: RE: [sipx-users] Remote office (was: port 5060/ port 5080, proxy why? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Kitchin (public/usenet) Sent: Thursday, August 19, 2010 8:11 PM To: Martin Steinmann Cc: [email protected] 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/[email protected]/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"<[email protected]> >> Date: Thu, 19 Aug 2010 21:49:43 >> To:<[email protected]>; 'Michael >> Scheidell'<[email protected]>;<sipx- >> [email protected]> >> 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:[email protected]] >>> Sent: Thursday, August 19, 2010 9:43 PM >>> To: Martin Steinmann; 'Michael Scheidell'; sipx- >>> [email protected] >>> 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"<[email protected]> >>> Sender: [email protected] >>> Date: Thu, 19 Aug 2010 21:30:34 >>> To: 'Michael Scheidell'<[email protected]>;<sipx- >>> [email protected]> >>> Subject: Re: [sipx-users] port 5060/ port 5080, proxy why? >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
