Does iptrtpproxy still work? Should there be consideration into marking it obsolete in Kamailio 4.1.0
Hello,
I was looking through the module dependencies for this and noticed that it requires the netfilter-rtpproxy which has not had a new release in over two years. Further, there is a recent bug report (http://www.2p.cz/en/node/1419 ) which indicates that netfilter-rtpproxy won't even compile with Linux kernels 2.6.18 and above.
In-kernel forwarding is a feature of mediaproxy-ng (through the rtpproxy-ng module), so it looks like iptrtpproxy doesn't provide any features that aren't available elsewhere.
Should there be some consideration about declaring this module obsolete in Kamailio 4.1.0?
Regards,
Peter
+1
I tried some years ago and never had success to build the underlying kernel module.
regards Klaus
On 21.10.2013 00:05, Peter Dunkley wrote:
Hello,
I was looking through the module dependencies for this and noticed that it requires the netfilter-rtpproxy which has not had a new release in over two years. Further, there is a recent bug report (http://www.2p.cz/en/node/1419 ) which indicates that netfilter-rtpproxy won't even compile with Linux kernels 2.6.18 and above.
In-kernel forwarding is a feature of mediaproxy-ng (through the rtpproxy-ng module), so it looks like iptrtpproxy doesn't provide any features that aren't available elsewhere.
Should there be some consideration about declaring this module obsolete in Kamailio 4.1.0?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
+1, I tried three or four times over the years to get it to work too, with no success on the kernel module.
Klaus Darilion klaus.mailinglists@pernau.at wrote:
+1
I tried some years ago and never had success to build the underlying kernel module.
regards Klaus
On 21.10.2013 00:05, Peter Dunkley wrote:
Hello,
I was looking through the module dependencies for this and noticed
that
it requires the netfilter-rtpproxy which has not had a new release in over two years. Further, there is a recent bug report (http://www.2p.cz/en/node/1419 ) which indicates that
netfilter-rtpproxy
won't even compile with Linux kernels 2.6.18 and above.
In-kernel forwarding is a feature of mediaproxy-ng (through the rtpproxy-ng module), so it looks like iptrtpproxy doesn't provide any features that aren't available elsewhere.
Should there be some consideration about declaring this module
obsolete
in Kamailio 4.1.0?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my Nexus 10, with all the figments of autocorrect that might imply.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
The only reason I can think of why it might be a worth trying to salvage iptrtpproxy is political in nature. Mediaproxy is put out by AG Projects, which, as far as I can tell, is firmly with The Other Project in terms of its personal sympathies and affinities (perhaps I'm wrong?). That has always made future compatibility with Kamailio a concern for me.
Yes, I know it's all open source and there isn't necessarily a good reason why we can't hack in new changes to the control protocol, but I've always thought it worth keeping in mind. It's also a key reason why I generally recommend rtpproxy instead to customers.
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
I was looking through the module dependencies for this and noticed that it requires the netfilter-rtpproxy which has not had a new release in over two years. Further, there is a recent bug report (http://www.2p.cz/en/node/1419 ) which indicates that netfilter-rtpproxy won't even compile with Linux kernels 2.6.18 and above.
In-kernel forwarding is a feature of mediaproxy-ng (through the rtpproxy-ng module), so it looks like iptrtpproxy doesn't provide any features that aren't available elsewhere.
Should there be some consideration about declaring this module obsolete in Kamailio 4.1.0?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my Nexus 10, with all the figments of autocorrect that might imply.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Alex Balashov writes:
The only reason I can think of why it might be a worth trying to salvage iptrtpproxy is political in nature. Mediaproxy is put out by AG Projects, which, as far as I can tell, is firmly with The Other Project in terms of its personal sympathies and affinities (perhaps I'm wrong?). That has always made future compatibility with Kamailio a concern for me.
i have used ag mediaproxy and have done some patches to k mediaproxy module along the way. i'm not planning to keep on using it and if the api is changing in the future, someone should do the upgrade of k mediaproxy module or stick to the current version of ag mediaproxy.
Yes, I know it's all open source and the it isn't necessarily a good reason why we can't hack in new changes to the control protocol, but I've always thought it worth keeping in mind. It's also a key reason why I generally recommend rtpproxy instead to customers.
my understanding is that rtpproxy does not support kernel based forwarding and is thus not a good choice. instead, mediaproxy-ng seems like the best fit.
-- juha
Hello,
mediaproxy is from AG Projects. mediaproxy-ng is from SIPWise.
mediaproxy-ng is controlled by the Kamailio rtpproxy-ng modules (confusing naming I know).
As well as supporting in-kernel forwarding mediaproxy-ng also supports SAVPF <-> AVPF, SAVPF <-> SAVP, SAVPF <-> AVP, and so on conversions (useful for WebRTC interoperation).
Regards,
Peter
On 21 October 2013 10:16, Alex Balashov abalashov@evaristesys.com wrote:
The only reason I can think of why it might be a worth trying to salvage iptrtpproxy is political in nature. Mediaproxy is put out by AG Projects, which, as far as I can tell, is firmly with The Other Project in terms of its personal sympathies and affinities (perhaps I'm wrong?). That has always made future compatibility with Kamailio a concern for me.
Yes, I know it's all open source and there isn't necessarily a good reason why we can't hack in new changes to the control protocol, but I've always thought it worth keeping in mind. It's also a key reason why I generally recommend rtpproxy instead to customers.
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
I was looking through the module dependencies for this and noticed that it requires the netfilter-rtpproxy which has not had a new release in over two years. Further, there is a recent bug report ( http://www.2p.cz/en/node/1419 ) which indicates that netfilter-rtpproxy won't even compile with Linux kernels 2.6.18 and above.
In-kernel forwarding is a feature of mediaproxy-ng (through the rtpproxy-ng module), so it looks like iptrtpproxy doesn't provide any features that aren't available elsewhere.
Should there be some consideration about declaring this module obsolete in Kamailio 4.1.0?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my Nexus 10, with all the figments of autocorrect that might imply.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Peter Dunkley writes:
As well as supporting in-kernel forwarding mediaproxy-ng also supports SAVPF <-> AVPF, SAVPF <-> SAVP, SAVPF <-> AVP, and so on conversions (useful for WebRTC interoperation).
i think this error still exists that makes it impossible to use mediaproxy-ng with common webrtc clients:
http://lists.sip-router.org/pipermail/sr-dev/2013-July/020734.html
-- juha
I've been using mediaproxy-ng with JsSIP on Chrome for a couple of months now. It works fine for me and I was running a live demo using it for this at AstriCon two weeks ago.
Regards,
Peter
On 21 October 2013 10:22, Juha Heinanen jh@tutpro.com wrote:
Peter Dunkley writes:
As well as supporting in-kernel forwarding mediaproxy-ng also supports SAVPF <-> AVPF, SAVPF <-> SAVP, SAVPF <-> AVP, and so on conversions (useful for WebRTC interoperation).
i think this error still exists that makes it impossible to use mediaproxy-ng with common webrtc clients:
http://lists.sip-router.org/pipermail/sr-dev/2013-July/020734.html
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Ah yes, that's true enough.
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
mediaproxy is from AG Projects. mediaproxy-ng is from SIPWise.
mediaproxy-ng is controlled by the Kamailio rtpproxy-ng modules (confusing naming I know).
As well as supporting in-kernel forwarding mediaproxy-ng also supports SAVPF <-> AVPF, SAVPF <-> SAVP, SAVPF <-> AVP, and so on conversions (useful for WebRTC interoperation).
Regards,
Peter
On 21 October 2013 10:16, Alex Balashov abalashov@evaristesys.com wrote:
The only reason I can think of why it might be a worth trying to
salvage
iptrtpproxy is political in nature. Mediaproxy is put out by AG
Projects,
which, as far as I can tell, is firmly with The Other Project in
terms of
its personal sympathies and affinities (perhaps I'm wrong?). That has always made future compatibility with Kamailio a concern for me.
Yes, I know it's all open source and there isn't necessarily a good
reason
why we can't hack in new changes to the control protocol, but I've
always
thought it worth keeping in mind. It's also a key reason why I
generally
recommend rtpproxy instead to customers.
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
I was looking through the module dependencies for this and noticed
that
it requires the netfilter-rtpproxy which has not had a new release
in over
two years. Further, there is a recent bug report ( http://www.2p.cz/en/node/1419 ) which indicates that
netfilter-rtpproxy
won't even compile with Linux kernels 2.6.18 and above.
In-kernel forwarding is a feature of mediaproxy-ng (through the rtpproxy-ng module), so it looks like iptrtpproxy doesn't provide
any
features that aren't available elsewhere.
Should there be some consideration about declaring this module
obsolete
in Kamailio 4.1.0?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my Nexus 10, with all the figments of autocorrect that
might
imply.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
-
Alex Balashov -
Juha Heinanen -
Klaus Darilion -
Peter Dunkley