> Thanks for the clarification on the bridge. I'll put the > Sonic Wall TZ190 back in place tonight and test again. Upon > futher reflection... I think the warning I saw regarding > symmetric NAT was in the media relay log. The Sonic Wall has > a SIP ALG and I do have it disabled to allow SipX to do all > the travesal work. I'll post what I find.
I have yet to come across a very good SIP ALG implementation, as such, I would strongly recommend that you disable it. You do not need a SIP ALG for remote workers with sipXecs. If you leave it on, you may find that basic call works but to convince yourself that it is not breaking interoperability, you would have though all the test cases and that a lot of work (all possible ways to do transfers, call park, call pickup, BLF, auto-attendant, conference and many many more). > > -----Original Message----- > From: sipx-users-boun...@list.sipfoundry.org > [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of > Robert Joly > Sent: Monday, August 24, 2009 9:43 AM > To: Dennis Wallen; sipx-users@list.sipfoundry.org > Subject: Re: [sipx-users] Experiences with SipX,Grandstream > GXW4104 FXO gateway, Snom 320 phones,a couple of firewalls, > and remote worker setup. > > > > > 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_work ers_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/ > _______________________________________________ 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/
