10 Jul
2013
10 Jul
'13
5:43 p.m.
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(a)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