A fixed port would probably work best from a firewall perspective. On May 23, 2011 11:58 AM, "Mircea Carasel" <[email protected]> wrote: > On Mon, May 23, 2011 at 2:37 PM, George Niculae <[email protected]> wrote: > >> Hi All, >> >> I'm investigating http://track.sipfoundry.org/browse/XX-9189 so I'm >> resurrecting >> http://thread.gmane.org/gmane.comp.telephony.pbx.sipfoundry.general/30441 >> discussion... >> >> I managed to recreate the issue on my machine by specifying the UDP >> range 31000 - 44000 and restarting prompted services. Basically Joe's >> statement >> "sipxrls is binding to a udp port that is on the range of our RTP >> (UDP) ports; which then prevents Media Relay from starting" >> can be explained as: sipxrls starts before Media Relay and binds to >> port 38428 (which is in the range of ephemeral ports for linux: >> http://en.wikipedia.org/wiki/Ephemeral_port), then Media Relay is >> started and tries to account ports in range 31000 - 44000 (including >> 38428) but since 38428 is already taken it fails to start (as a test I >> also started sipxrls and registrar after Media Relay and problem went >> away). >> As Joegen suggested we could ignore port if not available at Media >> Relay startup and go check next port in range, however the symmitron >> code works mostly with range of ports not with specific ports (meaning >> that if a bad port at startup it won't know further that the port is >> bad and will try to use it again later). While I agree this should be >> the correct fix I feel that radically changing the symmitron code is >> not what we want at the moment (or at least for 4.6). >> Therefore I would suggest only to improve help text on config page and >> to make admin aware about possible side effects when specifying RTP >> ports in ephemeral range. >> > +1. > Maybe, in addition, a global warning to be shown when a port from ephemeral > range is picked. > Similar, for instance, with the error message that globally appears when a > file replication failed > Mircea > >> >> Looking for some feedback, >> >> Thanks, >> George >> _______________________________________________ >> sipx-users mailing list >> [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/
