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. If so, you can try pruning the list of allowed codecs to reduce the invite. The other option is to see if patton has a compact sip header format. -M >>> On 3/1/2010 at 07:43 PM, in message >>> <[email protected]>, Pizza Napoletana >>> <[email protected]> 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. How can I prevent sipx from using TCP as the initial transport for INVITEs before it tries UDP for this device? I thought this was based on the device's registration. But the device's registration doesn't say transport=tcp. I don't know if the DNS NAPTR record has any relevance here. But I have also set it to give priority to UDP over TCP. I don't know what else to do to force sipx to not try TCP transport so we can prove / disprove our theory. How can I force sipx to send out only UDP INVITEs? Thanks btw, the device registers fine and can make outgoing calls too. The problem is only with the ignoring of INVITEs. _______________________________________________ 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/
_______________________________________________ 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/
