They are all wrappers around the same embedded function.
Don't know what was the issue that you encounter then, but please try
now and report any issues.
The new rtpproxy module is using now the core sdp parser and it is way
easier to track down any potential issues.
Also, multipart content should
On 10/06/2010 07:22 PM, Ovidiu Sas wrote:
They work ok in my setup. The plan is to remove force_rtp_proxy in
3.2.
A wholeheartedly palatable goal -- if they work. :-)
IIRC, the issue we had was with trying to use them with the same
richness and diversity of flags that force_rtp_proxy() has
They work ok in my setup. The plan is to remove force_rtp_proxy in 3.2.
Regards,
Ovidiu Sas
On Wed, Oct 6, 2010 at 7:19 PM, Alex Balashov wrote:
> I assume that means rtpproxy_answer|offer actually work now. :-)
>
> Last time there was a conversation about using them, in fall 2009, we
> conclu
I assume that means rtpproxy_answer|offer actually work now. :-)
Last time there was a conversation about using them, in fall 2009, we
concluded that they don't work and went back to using force_rtp_proxy().
On 10/06/2010 07:18 PM, Ovidiu Sas wrote:
You post reminded me that I should update
You post reminded me that I should update the examples on the repo
(which I just did).
It is better to use the new rtpproxy_offer/rtpproxy_answer functions.
For a quick example, please check:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob_plain;f=modules_k/rtpproxy/examples/alg.cf
On 10/06/2010 07:06 PM, Stagg Shelton wrote:
Early tests after your change seem to indicate that fixed the problem.
I'm looking at the docs with this new perspective, and when we read
the description of the i flag and the e flag it seems to suggest that
they are used independently. Nothing jumpe
Thanks Alex.
Early tests after your change seem to indicate that fixed the problem.
I'm looking at the docs with this new perspective, and when we read the
description of the i flag and the e flag it seems to suggest that they
are used independently. Nothing jumped out at us to use them tog
On 10/06/2010 06:41 PM, Stagg Shelton wrote:
I'm working on a setup where we have rtpproxy on a machine with eth0
IP 10.10.5.141/19 and eth1 IP 10.10.10.78/24. When using
force_rtp_proxy("","10.10.5.141"); the connection information (c)
field in the SDP is not being set to the ip 10.10.5.141 I
