On Tue, Sep 7, 2010 at 9:31 PM, Joegen Baclor <jbac...@ezuce.com> wrote: > Hmmmmn, the ALG seems to be sending the correct public info. This begs > two questions. > > 1. Did sipX offer (I mean the INVITE SDP this time) 94.227.135.32 > instead of 10.10.10.249? > 2. Do you get the same result if the caller is not behind NAT? > > If the answer to any of the two questions is NO, I am going to be > interested in digging further since there might be something in sipX > that we can improve on to be more NAT friendly. > > If the answer to the above items is both YES, it simply confirms the > limitation of sipX that it must have a prior knowledge of the phone > being inside a NAT for it to process the call correctly.
sipXconfig tells system what the IP address of the public facing IP address and so it can tell if messages are coming thru firewall and therefore need NAT capabilities. here are some pages if you haven't read them already http://wiki.sipfoundry.org/display/xecsuserV4r2/Remote+User+NAT+Traversal http://wiki.sipfoundry.org/display/xecsuserV4r2/Firewall+and+NAT+Configuration > I am aware > that another opensource ipbx has a flag to mark remote workers as NATted > via the configuration regardless of whether the UA is mangling the > transport addresses or not. I am not sure of the repercussions of this > if it gets supported in sipXconfig (if it's not already there). A user can register multiple clients or can register at home in the evening and in the office during the day. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
