Hi Maxim,
Thank you for fixing the thread initialisation. It works fine now.
Related to the other issue, I was not refering to accounting, but to the
fact that different timeout values should be considered for early and
established state of the call. And this is the reason I made a patch to have
two timeout parameters - one for each state. I noticed this problem by
setting the -T parameter to a small value (10 seconds because of wanting to
catch the rtp timeout of an established session very quickly), but then many
calls didn't get to be actually established, because after 10 seconds of
ringing rtpproxy sent a timeout notification event and opensips then closed
the call.
Related to the problem you raised, accurate accounting is not our main goal,
but finishing the dialog as soon as possible.
OpenSIPS, once it receives from RTPProxy the timeout notification, sends BYE
messages to both ends and close the dialog. One of this party could be a
PSTN entity that also has it's own accounting mechanism. If we are having an
accurate accounting, and they (probably) don't, there will be some
inconsistencies.
The other problem is that the whole OpenSIPS accounting mechanism will be
messed up, because it is done when SIP messages are triggered.
Regards,
Razvan
On 02/27/2011 05:43 AM, Maxim Sobolev wrote:
On 2/23/2011 7:53 AM, Razvan Crainea wrote:
Thank you for commiting that patch.
I would like to open another issue regarding rtpproxy timeout
notification mechanism.
On december we made a release of OpenSIPS with this new feature. Because
of some problems found in RTPProxy, I had to add a patch for it. You can
find it in public svn at
"modules/patches/rtpproxy_timeout_notification.fix_patch". It was made
against RTPProxy branch 600c80493793bafd2d69427bc22fcb43faad98c5 and
fixes the following problem:
I noticed that the timeout notification thread is started in the
main(parent) process. If used in foreground, RTPProxy runs perfectly.
But when submitted in background, as daemon, that thread stops running
properly, and doesn't send any notification. After I moved the thread
initialization in the child process (after forking), I noticed
evreything works fine, without any problems.
I've adjusted the code to do initialization of thread after rtpp_daemon(),
please check and let me know if it still doesn't work.
There is also a new feature in that patch: I added a parameter
(called w), that adds a new timeout, for session establishment. In the
official code a single timeout parameter controls both session
establishment and rtp media timeout. The problem is that when setting a
small timeout (media timeout should be detected fast) timeout
notifications are sent before the session can even establish. So we
needed a longer period for session establishment, but a smaller period
for media timeout.
As I told you, that patch was done against an older version of
RTPProxy. If you are willing to commit this behaviour to the official
RTPProxy, I can create a patch against the latest GIT version and send
it to you.
Please let me know your decision.
Do you need this in order to get accurate accounting? I am not sure if it's
the best approach if so. Perhaps the correct one would be to send RTP
session duration and/or timestamp of the last seen RTP packet along with the
disconnect notification, so that the accounting can be adjusted accordingly.
Please let me know what do you think.
Regards,
_______________________________________________
Devel mailing list
[email protected]
http://lists.rtpproxy.org/mailman/listinfo/devel
