[sr-dev] rtpproxy-ng

[Daniel-Constantin Mierla]

On 7/10/13 5:14 PM, Richard Fuchs wrote:
> On 07/10/13 10:43, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> I understand that the documentation of the protocol is exemplified with
>> JSON, but the implementation is actually bencode? From the readme it
>> seems you still keep the key=value format, passing them as a dictionary
>> in the control protocol. That means it could result in dictionaries
>> included in other dictionaries and/or lists (e.g., the result of query,
>> like the last json in the readme from the github) - obviously no longer
>> that easy to troubleshoot by 'eye'.
>
> Correct, that's about the only disadvantage bencode has over JSON. 
> However, large JSON structures can also be quite cumbersome to read if 
> condensed enough, unless you run them through a pretty-printer (which, 
> btw, I had to do with that query example from the readme). The same 
> process applies to bencode structures.

Are there pretty-printing tools for bencode? Or just 'gateways' to 
json/xml pretty-printing.


>
>> Have you got any figures of json vs bencode performances that made you
>> mind to go for the later?
>
> I don't. But since the primary purpose of the control protocol is to 
> pass back and forth SDP bodies, the fact that those don't have to be 
> copied and escaped/unescaped every time a request is sent or a reply 
> is received should give a clear advantage to bencode.

That's is indeed an inconvenience, although most of sdps don't have 
quotes, a walk through has to be done to be safe. The impact might not 
be that significant, though.
>
>>  From my point of view, json would have had the benefits of being easy
>> to query/display in some languages as well as storage engines. This is
>> mainly for statistics, when willing to search for various situations,
>> without a need to pre-process the result from the rtp relay.
>
> Assuming you're talking about searching in, or running stats over, the 
> raw encoded data blobs that occur on the wire, bencode actually makes 
> this easier, since the encoding is deterministic, i.e. there's only 
> one way to encode any particular structure or data. With JSON on the 
> other hand, the encoded version could look like anything and you'd 
> have to get into complicated regular expressions to get what you're 
> looking for, while still leaving a chance of missing it due to 
> unexpected escaping.

I was referring to post-processing -- i.e., do the queries periodically 
or for each call at the end, store the results in a storage system and 
then generate reports. With json, in some systems you can simply refer 
to it as a structure, like:

result.totals.input.rtp.bytes>1000

This kind of operations makes very easy generating reports.

>
>> Another thing I haven't noticed is about brdiging between two networks
>> of the same type, are --ip/--ipv6 parameters taking values like rtpproxy
>> addr1/addr2?
>
> Mediaproxy-ng currently only supports one address each for IPv4/6. But 
> this is not a limitation of the control protocol or the module, as it 
> still supports the same external/internal flags like the old one.

The question was ofr mediaproxy-ng app, because I was referring to 
--ip/--ipv6 parameters -- wanted to see if it supports bridging networks 
of same address family.

Cheers,
Daniel

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