On Thu, Jan 27, 2011 at 3:23 PM, Matthew Kitchin (public/usenet) < [email protected]> wrote:
> On 1/27/2011 2:20 PM, Matt White wrote: > > > Do you have any traces with the firmware at 3.2.4? > > The traces you list have names of 3.2.1 and 3.2.4 but all the traces show > the phones still running 3.2.1 > > Will do. I'm not sure how that could have happened. > > I say this because this issue looks much like this bug. > http://track.sipfoundry.org/browse/XTRN-942 > > where the phone ignores the route and send right to the bridge. But this > should be fixed in 3.2.2 and above. > > can you get a trace of a phone running 3.2.4? > > -M > > > _______________________________________________ > sipx-users mailing [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/ > I think there is some confusion here on the general understanding of port or address translation. I think Matt and Mike undertsand it well enough, but sometime its how you explain it that helps someone who "has been through it" understands it in the correct context. When an invite comes from the provider and says the address and port "123.456.789.10:5080" and it needs to say instead "123.456.789.10:5060", its not the PACKET that needs to be translated or the address, its what is INSIDE the header, not the actual packet destination. This means something has to actually take the header message and rewrite it with the correct information. A simple PAT or NAT in a firewall is not going to be able to do this in any event. The fact that your system has been working thus far is probably either due to one or several bugs that are being fixed in either polycom or sipxbridge code, so this is something that should be addressed or understood now. Yes, I am working with folks on a piece of software (appliance'ish) to place behind a firewall and do smart thing like this for both trunking and remote user traversal without having to adjust remote firewalls too. It is not totally finished but it is working at several sites thus far. There are several goals we have for it, but there is not much I can say until we've done some more work on making it easier to configure and test it more thoroughly. So while people are saying "put an sbc software on this firewall, etc.", it's just not that simple. If it was easy, everyone would be ding it and we wouldn't be talking about it.
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
