[OpenSIPS-Users] Mediaproxy relay oddness

Wed Jul 23 14:38:55 CEST 2014

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é <saul at ag-projects.com>
wrote:

> Hi Jeff,
>
> On 21 Jul 2014, at 21:55, Jeff Pyle <jpyle at fidelityvoice.com> 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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140723/9c55abe6/attachment.htm>