Hi Cesar,
are you looking for rtpproxy protocol format or for a more detailed
functionality of rtpproxy capabilities (e.g., what means bridge mode)?
Cheers,
Daniel
On 9/21/10 5:52 PM, César Pinto Magán wrote:
Hello,
I'm actually using rtpproxy_offer/answer(), and it works fine for us. I had to move
from force_rtp_rpoxy() because it had several rare behaviors and the use of the
offer/answer model solved them. It is very simple to implement.
By the way, is there any type of documentation about rtpproxy and their commands (i.e.
how works the bridge/switch mode of the rtp). The rtpproxy wiki says nothing about it.
César Pinto (2439)
+34 91 787 23 00 alhambra-eidos.es
-----Mensaje original-----
De: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
En nombre de Alex Balashov
Enviado el: martes, 21 de septiembre de 2010 17:32
Para: daniel(a)kamailio.org
CC: sr-users(a)lists.sip-router.org; sr-dev
Asunto: Re: [SR-Users] [sr-dev] rtpproxy (k): removal of force_rtpproxy
On 09/21/2010 11:27 AM, Daniel-Constantin Mierla wrote:
personally I haven't tested much those
functions. Maybe is better for
now to mark it obsolete and add a warning message at startup (via
fixup), then remove it with next release, allowing some maturity tests
for new ones. I am saying that also because most of existing configs
out there are using this function and new people will look for it.
I agree.
All of our configs use force_rtp_proxy(), but I would be happy to
migrate them; however, I need some reasonable assurance that
rtpproxy_offer/answer() will actually work.
As can be seen from a number of previous threads on the list, I had to
call force_rtp_proxy() to get several common scenarios to work, even
though supposedly rtpproxy_offer/answer() are just wrappers (the code
would suggest that), and even though the 'nathelper' documentation
says that supposedly they will accept and use the same flags as those
listed for force_rtp_proxy() the same way. It has not been true in my
experience.