[sr-dev] rtpproxy-ng

[Richard Fuchs]

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.

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

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

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

cheers