[OpenSIPS-Users] Mediaproxy relay oddness

[Saúl Ibarra Corretgé]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opensips.org/pipermail/users/attachments/20140723/ae5f4ed0/attachment-0001.pgp>