Quick update for those who might consider using Patton Smartlink M-ATA, one-port FXS device.
Summary of the problem: M-ATA device ignores TCP INVITEs from sipx proxy if they are bigger than 1400 (or so) bytes. Summary of tests: When making calls from another M-ATA or X-lite to the M-ATA, via sipx, the INVITEs are smaller than 1400 bytes, and the calls succeed. When making calls from ITSP side (including an outside M-ATA) or from an internal Snom, the INVITEs are bigger than 1500 bytes, and the M-ATA ignores INVITEs. There are also some other issues with this unit. For example, once in a while, accessing the HTTP server can make the device inoperable until a reboot. There are also some minor annoyances, like not picking up time-server setting from DHCP, and not being able to provision via tftp/http. btw, a couple of people in this mailing list have said that they use this device and they don't have issues. So your mileage may vary. Patton support: They are very prompt and professional. Really nice people. But they weren't able to figure out what is wrong. The M-ATA is a nice little, pack-of-gum sized device, but as a compromise they had to strip a lot of things out of it, especially the ability to debug. So Patton is recommending that I dump this device and move up to a 2-port 4112 model, which I think Tony has used and likes. Conclusion: I am returning these devices. The 2-port Patton 4112 is $300+. Little too steep for connecting analog conference room phones scattered around the building to sipx. I just noticed that sipX can auto-provision Grandstream HandyTone 286. It costs $30. I am going to give it a shot. On Mar 2, 2010, at 5:59 AM, Scott Lawrence wrote: > Pizza Napoletana wrote: > >> In working with Patton support on debugging an issue with their M-ATA >> device (1 port FXS) where it ignores INVITEs from sipx, we have a >> theory. We think that the device is getting confused by sipx's TCP >> based iNVITEs which precede the UDP based INVITEs. > > >>> On Mon, Mar 1, 2010 at 8:50 PM, Matt White >>> <[email protected]> wrote: > >>> The default is to send UDP invites. I would suspect your >>> getting TCP invites because your packet is too big. >>> >>> Check and see if the invite is close to the MTU size. I bet >>> it is. > > Matt got it on the first try. The INVITE was 1762 bytes coming out of > the proxy, so absent any addressing constraints, the proxy will always > try TCP first (this is required by RFC 3261). > > I don't quite understand why Patton would think this is a problem - if > they support TCP, they should answer it (which it did not in your > trace), and if they don't support TCP they they should not be affected > by it. From the timing, it looks like they did receive the TCP INVITE, > but did not send any response soon enough to suppress the retry with > UDP. > >> How can I prevent sipx from using TCP as the initial transport for >> INVITEs before it tries UDP for this device? > > You can't, but Patton can. If the REGISTER specifies a Contact address > that has a 'transport=UDP' url parameter, then the proxy will never > attempt UDP. It would be better (given the message sizes, especially) > to just use TCP. > > _______________________________________________ sipx-users mailing list [email protected] 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/
