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/
