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

On 11.07.17 11:52, Marian Piater wrote:

...

Hello,

I have a problem with RTPProxy.

Scenario:

SS7 (PSTN) ---> ASTERISK BOX --> Kamailio --> UAC

In case of incoming call from PSTN, when called party answer the call after 60 seconds of ringing, then the call is without audio and in this case I see in the log this message:

Creating session

Jul 11 11:24:32 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_command: new session 766d0e006d8969d36c628e363ea7c3e1@upc.cz, tag as7a7c86ae;1 requested, type strong Jul 11 11:24:32 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_command: new session on a port 52902 created, tag as7a7c86ae;1 Jul 11 11:24:32 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_command: pre-filling caller's address with XXX.XXX.XXX.XXX:32740

Answer after approx 60 seconds

Jul 11 11:25:40 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_command: lookup request failed: session 766d0e006d8969d36c628e363ea7c3e1@upc.cz, tags as7a7c86ae;1/l0g9iusua2;1 not found Jul 11 11:25:40 b2b-voice-sipproxy-v3 rtpproxy[731]: INFO:handle_delete: forcefully deleting session 1 on ports 35196/36656

Kamailio log (answer)

Jul 11 11:25:40 b2b-voice-sipproxy-v3 kamailio[5268]: INFO:

<script>: UID:766d0e006d8969d36c628e363ea7c3e1@upc.cz -- ONREPLY_ROUTE: rtpproxy_manage(co) Jul 11 11:25:40 b2b-voice-sipproxy-v3 kamailio[5268]: ERROR: rtpproxy [rtpproxy.c:2536]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy It looks like there is somewhere 60 seconds session timeout. But I don't know where. When the call is answered during first 60 seconds, then everything is OK and we have both audio. Kamailio reply route configuration: onreply_route[REPLYROUTE] { # #-- On-replay block routing -- # xlog("L_INFO","UID:$ci -- ONREPLY_ROUTE1: $rm $si avp $avp(s:131) $avp(s:132)"); if(has_body("application/sdp")) { xlog("L_INFO","UID:$ci -- ONREPLY_ROUTE: rtpproxy_manage(co)"); rtpproxy_manage("co"); } if ((isflagset(FLT_NATS) || isbflagset(FLB_NATB)) && status=~"(183)|(2[0-9][0-9])"){ xlog("L_INFO","UID:$ci -- ONREPLY_ROUTE1: force_rtp_proxy"); append_hf("P-hint: onreply_route|force_rtp_proxy \r\n"); } if (isbflagset(FLB_NATB)) { xlog("L_INFO","UID:$ci -- ONREPLY_ROUTE1: P-hint: Onreply-route - fixcontact"); append_hf("P-hint: Onreply-route - fixcontact \r\n"); fix_nated_contact(); } exit; } Some parameters settings. modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") modparam("rtpproxy", "extra_id_pv", "$avp(extra_id)") modparam("rtpproxy", "rtpproxy_disable_tout", 20) modparam("rtpproxy", "rtpproxy_tout", 2) modparam("tm", "disable_6xx_block", 1) modparam("tm", "fr_timer", 5000) ## 5 seconds. modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "auto_inv_100_reason", "Trying") modparam("dialog", "dlg_flag", 4) modparam("dialog", "rr_param", "rtp") modparam("dialog", "default_timeout", 7230) modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "db_mode", 1) modparam("dialog", "enable_stats", 1) modparam("dialog", "send_bye", 1) modparam("dialog", "lreq_callee_headers", "TH: dlh\r\n") modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 1) modparam("rr", "enable_double_rr", 1) RTPproxy is installed from Debian package: /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 Any advice? Thanks _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

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

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 Mierla www.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 42 marian.piater@voipsun.cz www.voipsun.cz

Good to know about both -T and -W options. In many of my rtpproxy installations I migrated to 2.0, because the default packaged rtpproxy version from distros (mainly stable debian or centos -- which come with some 1.2.1+patches), seems to be a problem with re-INVITEs changing the RTP port. However, rtpproxy v2.0 doesn't seem to be packaged yet in the stable distros out there, hopefully they will update it soon, it will make the life easier to deploy.

Cheers, Daniel

On 12.07.17 15:14, Maxim Sobolev wrote:

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@gmail.com mailto:miconda@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
<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 Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
Kamailio World Conference - www.kamailioworld.com <http://www.kamailioworld.com>

-- 
Marian Piater

VoIPsun s.r.o.
+420 608 24 58 42
marian.piater@voipsun.cz <mailto:marian.piater@voipsun.cz>
www.voipsun.cz <http://www.voipsun.cz>

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
Kamailio World Conference - www.kamailioworld.com <http://www.kamailioworld.com>


_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>