[sr-dev] rtpproxy-ng

[Richard Fuchs]

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. 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...

Anyway, just my 2 bits worth.

cheers