From miconda@gmail.com Tue Jul 11 15:36:41 2017 From: Daniel-Constantin Mierla To: sr-users@lists.kamailio.org Subject: Re: [SR-Users] RTPProxy - lookup request failed Date: Tue, 11 Jul 2017 15:36:31 +0200 Message-ID: <1305237d-eb64-652c-a888-1440abaa1265@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0564900772==" --===============0564900772== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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(a)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(a)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: >>>