On 02/02/2012 12:24 PM, Danny Nicholas wrote:
Agreed - I think the "solution" is a patch to udptl.c to reset the counter instead of dying with this message (just my opinion).
Asterisk was recently changed to only allocate UDPTL port numbers to channels that actually need them; prior to this change, if a SIP peer had "t38pt_udptl=yes", then any channels for that peer would have a UDPTL session allocated for them. This wasted resources, both memory and port numbers.
If the original poster had a lot of SIP channels at once, but most of them not using UDPTL, this could have caused his problem. For now, increasing the port range is the best method to resolve it, and is not harmful. Once a new release of Asterisk is made available with these UDPTL allocation changes made, then the port range could be reduced to only those necessary for the number of simultaneous channels using UDPTL.
-- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
