Coming from an SBC standpoint, if the ALG is performing its function correctly, then there shouldn't be any issue if it mangles the contact-uri or not. However, if it only mangles SIP request transport headers and not the SDP, then you will be encountering exactly what you have described since sipx needs to know a-priori that a remote worker is behind NAT for it to load the necessary logic to traverse it. I would be interested in seeing an actual 200 OK packet coming from the ALG to see how it responds to the INVITE coming from sipx. Comparing sipx to other ipbx might indeed produce a different result. It is highly probable that other implementations default to proxying the rtp stream making it more NAT friendly. The trade off to this is scalability.
On Thursday, 02 September, 2010 08:25 PM, Smith wrote: > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: 8bit > Organization: SipXecs Forum > In-Reply-To:<[email protected]> > X-FUDforum: 08063afcdd00a6e76393c5b9527381e8<51461> > Message-ID:<[email protected]> > > > > Yes I'll investigate it with the provider, and VPN is always > a solution. > > But I ask myself why this is working with other PBX > software. I'll try with askozia (asterisk) this friday. > _______________________________________________ > 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/
