HI Saul, The ports in use are 16384-32768. That provides for ~8000 session, yes? We were nowhere near that many calls. So, it's much more likely that ports were not being released for some reason.
There is a limited amount of T.38 traffic through these relays. The majority of the T.38-speaking devices are Adtran TA900-series, which, in general, behave quite well. That's on our side. On the partner side, usually Sonus GSX 9000-series. I bet it's the unusual client that is the problem. A SIP capture isn't practical here. :( I'll try to correlate the exceptions with CDR records to determine if there is a particular trunk group on my network that needs its attitude adjusted. Until we can update the entire call flow (Opensips, Mediaproxy, all deps, ...), or find a definitive misbehaving client, I'll restart the relays on a schedule. If I am able to reproduce the exceptions I'll provide debug data. - Jeff On Wed, Jul 23, 2014 at 4:01 AM, Saúl Ibarra Corretgé <[email protected]> wrote: > Hi Jeff, > > On 21 Jul 2014, at 21:55, Jeff Pyle <[email protected]> wrote: > > > Hello, > > > > This is on Opensips 1.6 with Mediaproxy 2.4.4. Yeah, they're old. I > know. > > > > We see this from time to time: > > > > media-relay[10719]: Traceback (most recent call last): > > media-relay[10719]: File > "/usr/lib/python2.5/site-packages/twisted/internet/udp.py", line 126, in > doRead > > media-relay[10719]: self.protocol.datagramReceived(data, addr) > > media-relay[10719]: File > "/usr/lib/pymodules/python2.5/mediaproxy/mediacontrol.py", line 130, in > datagramReceived > > media-relay[10719]: self.cb_func(host, port, data) > > media-relay[10719]: File > "/usr/lib/pymodules/python2.5/mediaproxy/mediacontrol.py", line 226, in > got_data > > media-relay[10719]: self.substream.send_data(self, data, is_stun) > > media-relay[10719]: File > "/usr/lib/pymodules/python2.5/mediaproxy/mediacontrol.py", line 311, in > send_data > > media-relay[10719]: dest.listener.protocol.send(data, is_stun) > > media-relay[10719]: File > "/usr/lib/pymodules/python2.5/mediaproxy/mediacontrol.py", line 159, in send > > media-relay[10719]: self.transport.write(data, (ip, port)) > > media-relay[10719]: File > "/usr/lib/python2.5/site-packages/twisted/internet/udp.py", line 155, in > write > > media-relay[10719]: return self.socket.sendto(datagram, addr) > > media-relay[10719]: error: (1, 'Operation not permitted') > > > > There doesn't seem to be any pattern. Nor do there seem to be any > complaints. > > > > Today we had it happen about 10 times, far more than the logs indicate > is normal. Then we had many lines of this: > > > > media-relay[10719]: error: Could not reserve relay ports for session, > all allocated ports are being used > > > > What port range are you using? Any chance they were all exhausted? > > > Then a few instances of: > > > > media-relay[10719]: File > "/usr/lib/pymodules/python2.5/mediaproxy/relay.py", line 175, in > lineReceived > > media-relay[10719]: response = > self.factory.parent.got_command(self.factory.host, self.command, > self.headers) > > media-relay[10719]: File > "/usr/lib/pymodules/python2.5/mediaproxy/relay.py", line 387, in got_command > > media-relay[10719]: local_media = > self.session_manager.update_session(dispatcher, **headers) > > media-relay[10719]: File > "/usr/lib/pymodules/python2.5/mediaproxy/mediacontrol.py", line 754, in > update_session > > media-relay[10719]: session.update_media(cseq, to_tag, user_agent, > media, is_downstream, is_caller_cseq) > > media-relay[10719]: File > "/usr/lib/pymodules/python2.5/mediaproxy/mediacontrol.py", line 566, in > update_media > > media-relay[10719]: raise ValueError('Media types do not match: "%s" > and "%s"' % (stream.media_type, media_type)) > > media-relay[10719]: ValueError: Media types do not match: "audio" and > “image” > > > > Hum, this could be a bug. Maybe some weird fax device? A SIP trace of such > calls would be nice. > > > Followed by lots (and LOTS) of these with various port combinations: > > > > media-relay[10719]: warning: Cannot use port pair 28836/28837 > > > > It’s possible that due to the previous exception ports are not deallocated > so they kept piling up until the range was exhausted. > > > This happened on two relays at the same time. The dispatchers lost > connectivity with the relays, and I had to kill -9 the relays to shake them > loose. Upon a relay restart all seems normal. > > > > Even though old, this media relay configuration has been rock solid for > years. Today, not so much. I'm wondering if this is a known bug that > hasn't bitten us until today? Or, something else? > > > > They are scheduled for replacement with more current software, but until > then, I'd like to learn what I can. > > > > I browsed through the MediaProxy changelogs just in case memory was not > serving well, and I don’t see anything related to this problem. At a first > glance it looks like an issue potentially caused by a device that can do > a=image, usually a fax. We do have some workarounds inplace for misbehaving > fax devices, maybe there is one case we miss. > > > Regards, > > -- > Saúl Ibarra Corretgé > AG Projects > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
