> > Over the past few weeks I've been considering SipX as a > replacement for our existing phone system. My greatest > interest is in the remote worker configuration to help > support "virtual office" functionality. I don't really have > any questions, but thought I'd share my experience in case > it's helpful to someone else. >
Thanks for taking the time to document your experiences with the project. > > I initially had difficulty getting the remote worker feature > to operate for two reasons. The first problem had to do with > my firewall due to my confusion when reading some SipX > documentation regarding symmetric NAT. Here is a quote from > "SIP Trunking with sipXecs". "SipXbridge assumes symmetric > NAT port mapping. That means an internal port must be mapped > to an identical external port and vice versa. Without such a > mapping some sipx components will not work. Not all NATs will > lend themselves to such mapping." The use of the term does > not match the definition of "Symmetric NAT". I didn't > realize what the problem was until I looked in a log file and > found a warning entry that suggested that the internal and > external port mapping were different and that there may be > problems (I can't remember the exact message). I replaced my > SonicWall TZ190 with a simple WRTG54GS2 Linksys wireless > router and that problem cleared up. There is one element that needs to be emphasized and what you describe confirms that the wiki is confusing in that area. The sipXbridge is the feature that allows you to connect sipXecs with ITSPs and one of the tasks it needs to perform to do so is to compensate for NATs between it and the ITSP *BUT* sipXbridge is not the feature to use to allow remote workers. sipXbridge -> designed for connecting with ITSPs sipXbridge -> not designed for allowing remote workers. In order to allow remote workers, you do not need to create SIP trunks and the sipXbridge is not required to be running. http://sipx-wiki.calivia.com/index.php/Configuring_remote_workers_cheats heet captures the steps required to have remote workers working and symmetric NATs are supported. > The second problem ended up being with my Snom 320 phones. > One of the Snoms was at another location on the other side of > a 3Com OfficeConnect firewall. Right. As long as all SIP-aware features (e.g. SIP ALGs) are disabled, not additional config is required at the remote firewall. > I made no configuration > changes to that firewall. I noticed in the Snom log that > SipX was adding the proper information to traverse NAT. The > Snom would register and I could place and receive calls, but > there was no audio. I noticed that the Snom was trying to > open a connection directly to the PRIVATE IP address the SipX > server even though SipX had provided the proper IP in the SDP > payload of the SIP INVITE message. I reported the problem to > Snom and they opened a bug ticket number of SCPP-1007 on August 6th. > > > > To continue testing I used the X-Lite softphone from > CounterPath. Remote worker functionality seems to be working now. > > > > My next experience was setting up the Grandstream GXW4104 FXO > gateway. The setup was fairly simple. The biggest issue I > had was that it kept trying to dial the "9" prefix. I'm > still not certain if the issue is with the gateway or with > SipX. SipX claims that it's not sending the prefix in the > rule, but I see it in the SIP message. I ended up > configuring the Grandstream to "eat" the 9 to work around the > problem. > > > > The final issue I had was trying to get call forking to work. > I wanted my extension and cell phone to ring together. The > Grandstream gateway was treating the call as answered > immediately after dialing even though I hadn't answered the > phone. Someone on a Grandstream forum suggested I could > enable Polarity Reversal to get the desired behavior. That > also requires that feature from the phone company. I haven't > tried that yet. > > > > My biggest observation is that SipX does not work when it is > behind a firewall that has symmetric NAT. What the docs are > calling symmetric is more of a one-to-one mapping. Someone > please correct me if I am wrong. The remote worker can be > behind symmetric NAT and that worked just fine. The remote worker feature is known to work behind a symmetric NAT as long as the remote worker phones use the same port for sending and receiving SIP messages (i.e. they do symmetric signaling) and use the same port for sending and receiving media (i.e. they do symmetric media). All the phones I have tried meet this but I haven't tested with Snomn and grandstream. > > > > I hope some of my experiences are helpful to someone. > > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org 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/
