Hi Maxim, Thanks for your reply. We could start with the statistics available but we need to know the meaning of the fields. Duration does not seem hard to include, other information depends on the decoding of the RTP header and I'm not sure if the impact on RTP Proxy performance pays off. Another possibility would be to send some of this information from the SIP server during the call of rtpproxy_offer() and rtpproxy_answer() such as caller_id, callee_id, negotiated codec, user agent client, user agent server. With this information it would be possible to create a simple web monitoring interface listing the current sessions and maybe a nice graph using RRD plotting the number of simultaneous sessions. Using the information sent would be also possible to create a better naming standard for the recordings based on caller/callee/callid/datetime that would be simpler to retrieve. Using only callid requires a query to the acc database to grab these information for each call.
Best regards, Flavio E. Goncalves CEO - V.Office 2011/1/6 Maxim Sobolev <sobo...@sippysoft.com> > On 1/5/2011 6:25 AM, Alexandre Abreu wrote: > > I wonder if these statistics is clear to anyone.. Right now, the only way > to > > know is looking at the source code and I think you are right. “C” stands > for > > RTCP. > > The lack of understandable RTP information is the only thing that keeps > me > > still using the mediaproxy 2.X. I really have several reasons to switch > to > > the RTPProxy. The media-relay component in MP2 lists the sessions and > > attributes in a way that we can easily understand and parse [1 example]. > > > > The RTP Proxy Protocol is indeed a very powerful tool, but IMHO the > today's > > RTP Session Information really needs some improvements -- mainly to make > > the information clearer. > > > > [1 example] > > 1...@sipproxy (source) 02233334...@sipproxy (destination) PBX (source > > user-agent) Sippy (destination user-agent) 33'42" (duration) G729 (codec > > being used) Áudio (media type) 5.82M (in) 5.83M (out) > > Alexandre, Flavio, > > Yes, indeed, current statistics reporting is not very informative. > > If you guys can work list of things that the RTPproxy should be > reporting instead, we can look into implementing that and making > specification available on the rtpproxy.org. > > Thanks! > > Regards, > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > T/F: +1-646-651-1110 > Web: http://www.sippysoft.com > MSN: sa...@sippysoft.com > Skype: SippySoft > > _______________________________________________ > Users mailing list > Users@rtpproxy.org > http://lists.rtpproxy.org/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/users
