[sr-dev] rtpproxy-ng

[Daniel-Constantin Mierla]

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

Have you got any figures of json vs bencode performances that made you 
mind to go for the later?

 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.

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?

Cheers,
Daniel

On 7/9/13 6:56 PM, Richard Fuchs wrote:
> Hello,
>
> I've just committed the initial version of the rtpproxy-ng module to a
> private branch (rfuchs/rtpproxy-ng) for comments and review. This module
> is heavily based on the old rtpproxy module and addresses some, but not
> all, of the concerns listed at [1]. Notably asynchronous discovery,
> enabling and disabling of proxies is on my to-do list.
>
> This module currently works with mediaproxy-ng [2] and supports full SDP
> rewriting. It passes the complete body to the RTP proxy and receives
> back a replacement body. As such, some of the features (such as ICE
> handling) of the old rtpproxy module are removed from the module and
> left to the RTP proxy instead. Other features not currently supported by
> mediaproxy-ng, such as media playback or recording, are left
> unimplemented (i.e. not rewritten and commented out) in rtpproxy-ng, but
> it would be trivial to implement them.
>
> Instead of JSON, it uses the bencode [3] format for the control
> protocol, which has a very similar feature set, but is a much simpler
> and more efficient encoding. The module includes a bencode "library"
> (bencode.[ch]) which is deliberately written without any close ties to
> the Kamailio core code, so that it can potentially be used in other
> projects with little or no modification. For other languages, such as
> Perl or Python, bencode modules already exist.
>
> The control protocol in its current state is described at [4]. Most of
> it is made to resemble the flags and other options and features of the
> old rtpproxy module. The rtpproxy-ng module is also made to be a drop-in
> replacement, all the function names and their syntax is the same. This
> should make for easy transitioning. However, as more and more features
> are added to the RTP proxies, I feel there's a need for a new set of
> module functions with an extended syntax in the future. The control
> protocol is made to be flexible and easily extendable.
>
> Comments welcome.
>
> cheerse
>
>
> [1] http://www.kamailio.org/wiki/devel/rtpproxy-ng
> [2] https://github.com/sipwise/mediaproxy-ng
> [3] http://en.wikipedia.org/wiki/Bencode
> [4] https://github.com/sipwise/mediaproxy-ng#the-ng-control-protocol
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130710/16e7f0e2/attachment.html>