[SR-Users] RTPProxy - lookup request failed

[Maxim Sobolev]

Yes, Daniel is correct you can bump overall timeout with the -T option.
There is also another option -W now since 3 years ago (2.0+) to set timeout
specifically on early sessions, so that you can have bigger timeout during
call setup phase which might be relevant in this case. Hope it helps.

-Max

On Jul 12, 2017 4:42 PM, "Daniel-Constantin Mierla" <miconda at gmail.com>
wrote:

Hello,

knowing that rtpproxy v2.0 has -T is very useful. v1.2 is very old, so I
think its time to migrate to v2.0.

With this occasion I checked rtpengine -- it has a bunch of options related
to timeouts, so it's a good alternative to go for it as well.

Cheers,
Daniel

On 12.07.17 09:24, Marian Piater wrote:

Hi,
works fine, after recompile RTPProxy with newer version
(2.2.alpha.20160822) and using option -T 150. There was no necessary to
modify the source code.

/usr/bin/rtpproxy -s udp:127.0.0.1 7722 -u rtpproxy rtpproxy -p
/var/run/rtpproxy/rtpproxy.pid -F -l XXX.XXX.XXX.XXX -d DBUG LOG_LOCAL0 -T
150

Thank you again,
Marian


Dňa 12.7.2017 o 09:18 Daniel-Constantin Mierla napísal(a):

Hello,

ok -- it would be good to know if that solved the problem, so others can
find the answer in the archive when facing a similar situation.

Cheers,
Daniel

On 11.07.17 15:55, Marian Piater wrote:

Hello,

thank you for quick reply, I tried to find some options in the man pages,
but I didn't read HOWITWORKS section.

I will try to compile RTPProxy from source.

Regards Marian

Dňa 11.7.2017 o 15:36 Daniel-Constantin Mierla napísal(a):

Hello,

doing 'man rtpproxy' on debian jessie reveals:

"The proxy tracks idle time for each of existing sessions (i.e. the time
within which there were no packets relayed), and automatically cleans up a
sessions whose idle times exceed the value specified at compile time (60
seconds by default)."
Which seems to explain exactly what happens in your case.

I knew there was an inactivity cleanup routine, but I expected to be higher
than 60sec. Interesting that it didn't hit me badly so far. I haven't
checked the source code to see if it still matches the docs, though, but I
see that master branch of rtpproxy still has this remark in the manual:

  - https://github.com/sippy/rtpproxy/blob/master/rtpproxy.8#L335

An issue should be created for rtpproxy to at least increase this value, or
better make it an option for command line.

Cheers,
Daniel

On 11.07.17 15:21, Marian Piater wrote:

Hi Daniel,

we are using 1.2.1-2.1 version from Debian Jessie repository.

rtpproxy                        1.2.1-2.1
amd64        Relay for Real-time Transport Protocol (RTP) media streams

Regards,

Marian

Dňa 11.7.2017 o 13:09 Daniel-Constantin Mierla napísal(a):

Hello,

what is the version for rtpproxy?

Cheers,
Daniel



-- 
Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


-- 
Marian Piater

VoIPsun s.r.o.
+420 608 24 58 42marian.piater at voipsun.czwww.voipsun.cz


-- 
Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170712/2d2989b7/attachment.html>