> Tony and All - Thanks for the quick and thorough reply. I > read the Remote User config carefully and realize it might > work for us - I had some misunderstanding about the pinholes > before. It seems a good in-box option and easy to use. I will > try it out in NAT environ. At this point, I am eager to find > out how good the algorithm is - i.e. > discover reachable media path and only use Relay as the last > resort.... I hope it should handle it as good as ICE or > Skype. I had some experience on OCS and it did a good job > with ICE implementation.
The algorithm is trying to use the media relay as spraringly as possible but unlike ICE and Skype, it does not take into consideration the type of NATs that are in play. In some cases, if the right types of NATs are used, you can eliminate the media relay once the call has started but sipXecs does not make use of that trick for three reasons: 1- would be very difficult to implement in sipXecs architecture 2- More and more NATs are now of the type 'symmetric' which do not work with said 'trick' 3- NAT types are informal definitions rather than hard specs so it is not possible to guarantee that the NAT type can be determined 100% of the time. For more detailed info on the NAT traversal design, please consult the desgin spec at http://code.sipfoundry.org/browse/~raw,r=16215/sipXecs/main/sipXproxy/doc/NAT-traversal/NAT_Traversal_Design_Doc.doc . Secsion 4.2.4 and 4.3.5.3 will be of special interest to you. Cheers, bob > > Rich > > On Thu, Jun 17, 2010 at 6:52 PM, Tony Graziano > <[email protected]> wrote: > > (actually a 4th option is to use a vpn enabled phone. snom > is the only > > vendor I know of that has one, but quite frankly I never > had good luck > > with the very first model they shipped, as you cannot have > a 2 factor > > vpn credential like certificate and user/password). > > > > On Thu, Jun 17, 2010 at 6:11 AM, Tony Graziano > > <[email protected]> wrote: > >> Actually a third option for remote users is to VPN in. But > that goes > >> without saying. > >> > >> On Thu, Jun 17, 2010 at 6:09 AM, Tony Graziano > >> <[email protected]> wrote: > >>> There are two ways to handle this... > >>> > >>> 1. Setup sipx to be behind nat, enabling support for remote users > >>> and server behind nat, as well as enabling the role for > siptrunking > >>> and setup your firewall accordingly, which for whatever reason is > >>> "not acceptable in your environment". > >>> > >>> or > >>> > >>> 2. Do none of the above and use a separate SBC to handle > those roles. > >>> > >>> The most recent IETF draft: > >>> > >>> > http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-10#page- > >>> 10 > >>> > >>> (4.1.1. Symmetric Response) is what sipx does in method 1 above. > >>> The IETF draft considers it reliable adn does not > consider it to be > >>> a security issue. Nor do I. > >>> > >>> ICE is actually a layered protocol. It is reliable, but sipx does > >>> not implement it. Whether you want ICE, STUN or TURN, > these can be > >>> delivered from a firewall with "sip awareness" or from a SBC with > >>> these capabilities (i.e. Ingate, etc.). We do this all > the time for > >>> customers who need to make trunking or dial plan changes > during work > >>> hours without disruption to users. > >>> > >>> Good luck. > >>> > >>> On Wed, Jun 16, 2010 at 10:19 PM, Richard Zhao > <[email protected]> wrote: > >>>> Hi, > >>>> > >>>> We are trying out sipXecs for internal usage. An > important factor > >>>> for us is NAT traversal. We have some experience with > Microsoft OCS > >>>> and it uses ICE for NAT traversal. It seems a good way > to handle this. > >>>> > >>>> I checked sipXecs docs and it is not very clear about how to > >>>> configure STUN/TURN for ICE protocol. Does anyone have > experience > >>>> on this? How should we set up STUN/TRUN server and have ICE > >>>> available? I read that OpenSips has an internal STUN > server and it > >>>> works well. Can I have an internal STUN server in sipXecs? > >>>> > >>>> I know that sipXecs has some built-in NAT traversal > mechanism but > >>>> it needs pinholes on the firewall. That is not acceptable in our > >>>> environment. > >>>> > >>>> Thanks for your help, > >>>> Richard > >>>> _______________________________________________ > >>>> 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 > >>> sip: [email protected] > >>> Fax: 434.984.8431 > >>> > >>> Email: [email protected] > >>> > >>> LAN/Telephony/Security and Control Systems Helpdesk: > >>> Telephone: 434.984.8426 > >>> sip: [email protected] > >>> 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. > >>> > >> > >> > >> > >> -- > >> ====================== > >> Tony Graziano, Manager > >> Telephone: 434.984.8430 > >> sip: [email protected] > >> Fax: 434.984.8431 > >> > >> Email: [email protected] > >> > >> LAN/Telephony/Security and Control Systems Helpdesk: > >> Telephone: 434.984.8426 > >> sip: [email protected] > >> 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. > >> > > > > > > > > -- > > ====================== > > Tony Graziano, Manager > > Telephone: 434.984.8430 > > sip: [email protected] > > Fax: 434.984.8431 > > > > Email: [email protected] > > > > LAN/Telephony/Security and Control Systems Helpdesk: > > Telephone: 434.984.8426 > > sip: [email protected] > > 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/
