[sr-dev] rtpproxy-ng

[Daniel-Constantin Mierla]

On 7/10/13 9:50 PM, Richard Fuchs wrote:
> On 07/10/13 14:28, Daniel-Constantin Mierla wrote:
>
>> It was not about 'do it yourself', but commodity for average users to
>> deal with it ...
>
>> It's again about existing tools/storage systems -- they have built-in to
>> access json as an object/variable, no need to parse yourself and build a
>> custom/own query language. Just for example, iirc, at some point I saw a
>> patch/presentation that MariaDB can do optimized searching withing json
>> object by matching with dedicated functions (as well as capability of
>> setting just a value inside json docs).
>
>> That will required development in all these systems, both can be seen as
>> serialization mechanisms, but their structure is different, so existing
>> json functions in one system cannot be reused.
>
>> You implemented and it was your decision, so I don't have anything
>> against using bencode in this case -- in the light of requests for
>> comments you asked for, I tried to figure out if parsing faster bencoded
>> strings pays off when balancing with the need to interact with/from
>> different components in a complete operational platform.
>
> I think all those cases that you mention are outside of the scope of a 
> control protocol between a SIP proxy and an RTP proxy. I don't see an 
> average user having much interest in the details of the protocol and 
> they probably wouldn't find the contents any more interesting if they 
> were in JSON format.

My focus in the discussion was related to the query -- getting 
statistics of the sessions, which can be very useful to humans. But also 
I meant post-processing -- polling those statistics, save them to a 
backend and then generate reports when needed.

Similar is the way we have the control protocol in kamailio, e.g., 
'kamctl stats' just displays what is sent back by kamailio.

> Apart from that, there's no reason why an RTP proxy shouldn't be able 
> to export stats or what not via a different protocol and/or in another 
> format. But I don't think this specific protocol is the place to think 
> about interaction with other existing systems, since those almost 
> certainly wouldn't be able to speak the protocol anyway, even if it 
> uses JSON encoding, no matter how you design it. Unless you go above 
> and beyond and make it HTTP-based or some such...
>
> Since you asked for specific numbers comparing the performance, here 
> are some. I took the "offer" command example from the mediaproxy-ng 
> docs, which isn't all that complex, with an average sized SDP body, 
> and ran it in a tight decode-encode-free loop. I increased the number 
> of loop iterations until I got a measurable run time. I did this for 
> both the bencode and the equivalent JSON representation, where the 
> encode step each encoded back to the original format. Using the json-c 
> library, I got a runtime of 18.9 seconds, while with bencode it runs 
> in 2.3 seconds. This is further reduced to 1.6 seconds when the "print 
> as string" encoding step is skipped and the bencode representation 
> instead is put into an iovec array, which the rtpproxy-ng module does. 
> In the grand scheme of things this may or may not make a difference, 
> but why go slower if you can go faster...
Going faster is good as long as the overall impact is not actually 
making the overall integration/system more complex.

Anyhow, I wanted to see if there were any strong technical arguments for 
using bencode or just more like a preference.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda