Having problems using RTPProxy to bridge internal/external networks

[Joe Hart-5]

Hi all,

For a project on which I'm currently working, I am having some problems
figuring out how to correctly configure Kamailio to communicate with RTP
Proxy in order to send media into and out of a network with private IP
address ranges.

I have a proxy set up to send the SIP traffic, and all of this is
working fine.  However, I'm having some trouble getting the RTP Proxy
set up.  Currently, when the call is connected, the offer/answer is made
and RTP Proxy seems to be taking over, but I'm having trouble getting my
audio to flow in both directions.

Examination of the traffic coming into and out of this machine seems to
indicate that the IP addresses aren't being mangled correctly.
Specifically, it appears the internal IP address isn't being changed to
reflect the IP address of the machine on which RTP Proxy is running, so
that when the caller tries to send audio back, the IP it's given to
reply to is 10.10.x.x, which obviously won't work.

I have tried experimenting with specifically setting IP addresses in the
rtpproxy_offer() and _answer() methods to no avail, as well as setting
various flags in those methods.  However, I must admit that I'm not
entirely sure what's happening under the hood with these methods, or
what rtpproxy is doing with that information when it gets it.  Rather
than continue to hack at this by trial and error, I'm hoping someone
here can point me in the right direction.

Any advice, example code or pep talks would be greatly appreciated.

Thanks in advance,

--
Joe Hart
Voice Systems Integrator
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) [phone]
Direct : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Örn Arnarson]

I'm having a similar problem at the moment;

In my setup, I have two physical interfaces, one private and one
public. As with you, I have managed to get SIP flowing without
problems with the correct IP headers re-written.

With the RTP, I've been struggling. I've been where you are at now,
but currently, through fix_nated_sdp and rtpproxy_offer I've managed
to get the correct IP addresses in the SDP header; thus I have
incoming RTP from both sides to the correct respective IP addresses of
kamailio. That is, the private one sends to the private IP address,
and the public one sends to the public IP address.
Kamailio, however, doesn't do anything with these packages. It gives
no reply about ICMP port unreachable, nor does it forward it. So,
packets are streaming in to kamailio/rtpproxy from both ends, but
nothing is coming out on either end.

I have RTP proxy running in bridged mode, with the flag -l
ext.ip.address/int.ip.address.

As with Joe, I'd appreciate any pointers.

Best regards,
Örn

On Tue, Oct 13, 2009 at 10:12 PM, Joe Hart <jhart@...> wrote:

> Hi all,
>
> For a project on which I'm currently working, I am having some problems
> figuring out how to correctly configure Kamailio to communicate with RTP
> Proxy in order to send media into and out of a network with private IP
> address ranges.
>
> I have a proxy set up to send the SIP traffic, and all of this is working
> fine.  However, I'm having some trouble getting the RTP Proxy set up.
>  Currently, when the call is connected, the offer/answer is made and RTP
> Proxy seems to be taking over, but I'm having trouble getting my audio to
> flow in both directions.
>
> Examination of the traffic coming into and out of this machine seems to
> indicate that the IP addresses aren't being mangled correctly. Specifically,
> it appears the internal IP address isn't being changed to reflect the IP
> address of the machine on which RTP Proxy is running, so that when the
> caller tries to send audio back, the IP it's given to reply to is 10.10.x.x,
> which obviously won't work.
>
> I have tried experimenting with specifically setting IP addresses in the
> rtpproxy_offer() and _answer() methods to no avail, as well as setting
> various flags in those methods.  However, I must admit that I'm not entirely
> sure what's happening under the hood with these methods, or what rtpproxy is
> doing with that information when it gets it.  Rather than continue to hack
> at this by trial and error, I'm hoping someone here can point me in the
> right direction.
>
> Any advice, example code or pep talks would be greatly appreciated.
>
> Thanks in advance,
>
> --
> Joe Hart
> Voice Systems Integrator
> Evariste Systems
> Web     : http://www.evaristesys.com/
> Tel     : (+1) [phone]
> Direct  : (+1) [phone]
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users@...
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Örn Arnarson]

Oh, I forgot one thing;

I'm using fix_nated_sdp, as previously mentioned. I have a hunch that
because I'm not using force_rtp_proxy/rtpproxy_offer it's not being
relayed (a hunch, because I don't fully understand how rtpproxy
works). Problem is though, I can't get the IP addresses correct by
using rtpproxy_offer.

Regards,
Örn

2009/10/14 Örn Arnarson <orn@...>:

> I'm having a similar problem at the moment;
>
> In my setup, I have two physical interfaces, one private and one
> public. As with you, I have managed to get SIP flowing without
> problems with the correct IP headers re-written.
>
> With the RTP, I've been struggling. I've been where you are at now,
> but currently, through fix_nated_sdp and rtpproxy_offer I've managed
> to get the correct IP addresses in the SDP header; thus I have
> incoming RTP from both sides to the correct respective IP addresses of
> kamailio. That is, the private one sends to the private IP address,
> and the public one sends to the public IP address.
> Kamailio, however, doesn't do anything with these packages. It gives
> no reply about ICMP port unreachable, nor does it forward it. So,
> packets are streaming in to kamailio/rtpproxy from both ends, but
> nothing is coming out on either end.
>
> I have RTP proxy running in bridged mode, with the flag -l
> ext.ip.address/int.ip.address.
>
> As with Joe, I'd appreciate any pointers.
>
> Best regards,
> Örn
>
> On Tue, Oct 13, 2009 at 10:12 PM, Joe Hart <jhart@...> wrote:
>> Hi all,
>>
>> For a project on which I'm currently working, I am having some problems
>> figuring out how to correctly configure Kamailio to communicate with RTP
>> Proxy in order to send media into and out of a network with private IP
>> address ranges.
>>
>> I have a proxy set up to send the SIP traffic, and all of this is working
>> fine.  However, I'm having some trouble getting the RTP Proxy set up.
>>  Currently, when the call is connected, the offer/answer is made and RTP
>> Proxy seems to be taking over, but I'm having trouble getting my audio to
>> flow in both directions.
>>
>> Examination of the traffic coming into and out of this machine seems to
>> indicate that the IP addresses aren't being mangled correctly. Specifically,
>> it appears the internal IP address isn't being changed to reflect the IP
>> address of the machine on which RTP Proxy is running, so that when the
>> caller tries to send audio back, the IP it's given to reply to is 10.10.x.x,
>> which obviously won't work.
>>
>> I have tried experimenting with specifically setting IP addresses in the
>> rtpproxy_offer() and _answer() methods to no avail, as well as setting
>> various flags in those methods.  However, I must admit that I'm not entirely
>> sure what's happening under the hood with these methods, or what rtpproxy is
>> doing with that information when it gets it.  Rather than continue to hack
>> at this by trial and error, I'm hoping someone here can point me in the
>> right direction.
>>
>> Any advice, example code or pep talks would be greatly appreciated.
>>
>> Thanks in advance,
>>
>> --
>> Joe Hart
>> Voice Systems Integrator
>> Evariste Systems
>> Web     : http://www.evaristesys.com/
>> Tel     : (+1) [phone]
>> Direct  : (+1) [phone]
>>
>> _______________________________________________
>> Kamailio (OpenSER) - Users mailing list
>> Users@...
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Örn Arnarson wrote:

> Oh, I forgot one thing;
>
> I'm using fix_nated_sdp, as previously mentioned. I have a hunch that
> because I'm not using force_rtp_proxy/rtpproxy_offer it's not being
> relayed (a hunch, because I don't fully understand how rtpproxy
> works). Problem is though, I can't get the IP addresses correct by
> using rtpproxy_offer.

On behalf of Joe (same company) I will add that there is no NAT
scenario here.  Both the private and public network are directly
routable from the rtpproxy box;  there is no IP address
oversubscription, and no reason to ignore ports or addresses in SDP
and replace them with received parameters.  This is not a far-end NAT
traversal solution.

What is basically being asked here is how to bridge between two
interfaces (internal, external) without NAT using rtpproxy, and if
anyone can provide a canonical implementation or example.

We've got it running in bridge mode, e.g.

   rtpproxy -F -s udp:10.x.x.x:5050 -l 10.x.x.x/89.y.y.y

... and basically, are just wondering how to get this to work on the
Kamailio side using rtpproxy_offer()/rtpproxy_answer().

The RTP proxy machine is a dedicated host;  the SIP proxies are virtual.


--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Klaus Darilion-2]

I think it is not about offer/answer, but you have to call rtpproxy*
functions with  the proper parameter to activate bridging inside rtpproxy.

E.g. there is an (I guess rather old) example for ipv4 to ipv6 bridging,
but from the logic it should be similar to v4:v6 bridging:
http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/4to6.cfg?revision=2&view=markup

Take a look at the i and e flag:
http://kamailio.org/docs/modules/1.5.x/nathelper#id2468157

regards
klaus

Joe Hart wrote:

> Hi all,
>
> For a project on which I'm currently working, I am having some problems
> figuring out how to correctly configure Kamailio to communicate with RTP
> Proxy in order to send media into and out of a network with private IP
> address ranges.
>
> I have a proxy set up to send the SIP traffic, and all of this is
> working fine.  However, I'm having some trouble getting the RTP Proxy
> set up.  Currently, when the call is connected, the offer/answer is made
> and RTP Proxy seems to be taking over, but I'm having trouble getting my
> audio to flow in both directions.
>
> Examination of the traffic coming into and out of this machine seems to
> indicate that the IP addresses aren't being mangled correctly.
> Specifically, it appears the internal IP address isn't being changed to
> reflect the IP address of the machine on which RTP Proxy is running, so
> that when the caller tries to send audio back, the IP it's given to
> reply to is 10.10.x.x, which obviously won't work.
>
> I have tried experimenting with specifically setting IP addresses in the
> rtpproxy_offer() and _answer() methods to no avail, as well as setting
> various flags in those methods.  However, I must admit that I'm not
> entirely sure what's happening under the hood with these methods, or
> what rtpproxy is doing with that information when it gets it.  Rather
> than continue to hack at this by trial and error, I'm hoping someone
> here can point me in the right direction.
>
> Any advice, example code or pep talks would be greatly appreciated.
>
> Thanks in advance,
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Klaus Darilion-2]

never call both functions. That will not work (you see the result)

when using the correct parameters (flags), force_rtpproxy() should be
able to fix the SDP correctly

regards
klaus

Örn Arnarson wrote:

> Hi Klaus,
>
> I've gathered as much; I'm able to bridge between the interfaces, but
> if I do that, I can't rewrite the SDP properly. I can only rewrite the
> SDP by using fix_nated_sdp. If I use fix_nated_sdp and the rtpproxy
> functions to bridge the call, the SDP gets messed up.
> E.g. I rewrite the media address with fix_nated_sdp from the public
> IP, 157.157.x.x to 10.252.1.8, but if I then call the force_rtp_proxy
> function, it just appends the public IP address directly behind the
> 10.252.1.8 IP address, so the SDP media address is now
> 10.252.1.8157.157.x.x.
>
> Any ideas?
>
> Regards,
> Örn
>
> On Thu, Oct 15, 2009 at 12:30 AM, Klaus Darilion
> <klaus.mailinglists@...> wrote:
>> I think it is not about offer/answer, but you have to call rtpproxy*
>> functions with  the proper parameter to activate bridging inside rtpproxy.
>>
>> E.g. there is an (I guess rather old) example for ipv4 to ipv6 bridging, but
>> from the logic it should be similar to v4:v6 bridging:
>> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/4to6.cfg?revision=2&view=markup
>>
>> Take a look at the i and e flag:
>> http://kamailio.org/docs/modules/1.5.x/nathelper#id2468157
>>
>> regards
>> klaus
>>
>> Joe Hart wrote:
>>> Hi all,
>>>
>>> For a project on which I'm currently working, I am having some problems
>>> figuring out how to correctly configure Kamailio to communicate with RTP
>>> Proxy in order to send media into and out of a network with private IP
>>> address ranges.
>>>
>>> I have a proxy set up to send the SIP traffic, and all of this is working
>>> fine.  However, I'm having some trouble getting the RTP Proxy set up.
>>>  Currently, when the call is connected, the offer/answer is made and RTP
>>> Proxy seems to be taking over, but I'm having trouble getting my audio to
>>> flow in both directions.
>>>
>>> Examination of the traffic coming into and out of this machine seems to
>>> indicate that the IP addresses aren't being mangled correctly. Specifically,
>>> it appears the internal IP address isn't being changed to reflect the IP
>>> address of the machine on which RTP Proxy is running, so that when the
>>> caller tries to send audio back, the IP it's given to reply to is 10.10.x.x,
>>> which obviously won't work.
>>>
>>> I have tried experimenting with specifically setting IP addresses in the
>>> rtpproxy_offer() and _answer() methods to no avail, as well as setting
>>> various flags in those methods.  However, I must admit that I'm not entirely
>>> sure what's happening under the hood with these methods, or what rtpproxy is
>>> doing with that information when it gets it.  Rather than continue to hack
>>> at this by trial and error, I'm hoping someone here can point me in the
>>> right direction.
>>>
>>> Any advice, example code or pep talks would be greatly appreciated.
>>>
>>> Thanks in advance,
>>>
>> _______________________________________________
>> Kamailio (OpenSER) - Users mailing list
>> Users@...
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

An update on this:  we've gotten the SDP substitution to happen
correctly using rtpproxy_offer()/answer(), and the media endpoints now
send their media to the correct respective interface addresses on the
rtpproxy host.

However, despite allegedly running in "bridge mode" (-l
one.ip/two.ip), the rtpproxy does not appear to be "bridging" them -
that is, it is not forwarding.

We previously found that having /proc/sys/net/ipv4/ip_forward on was
an issue, so we turned it on - but to no effect.

Alex Balashov wrote:

> Örn Arnarson wrote:
>
>> Oh, I forgot one thing;
>>
>> I'm using fix_nated_sdp, as previously mentioned. I have a hunch that
>> because I'm not using force_rtp_proxy/rtpproxy_offer it's not being
>> relayed (a hunch, because I don't fully understand how rtpproxy
>> works). Problem is though, I can't get the IP addresses correct by
>> using rtpproxy_offer.
>
> On behalf of Joe (same company) I will add that there is no NAT scenario
> here.  Both the private and public network are directly routable from
> the rtpproxy box;  there is no IP address oversubscription, and no
> reason to ignore ports or addresses in SDP and replace them with
> received parameters.  This is not a far-end NAT traversal solution.
>
> What is basically being asked here is how to bridge between two
> interfaces (internal, external) without NAT using rtpproxy, and if
> anyone can provide a canonical implementation or example.
>
> We've got it running in bridge mode, e.g.
>
>   rtpproxy -F -s udp:10.x.x.x:5050 -l 10.x.x.x/89.y.y.y
>
> ... and basically, are just wondering how to get this to work on the
> Kamailio side using rtpproxy_offer()/rtpproxy_answer().
>
> The RTP proxy machine is a dedicated host;  the SIP proxies are virtual.
>
>

--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Örn Arnarson]

Hi,

I have exactly the same scenario; no NAT involved. Just trying to
bridge between these two interfaces.

Now, to clarify better what I have done;

As I understand it, force_rtp_proxy / rtpproxy_offer needs to be used
to inform RTP proxy that it will have to relay the packets.

So, that pretty much makes it necessary to use that call. As I
understand it, you can't call both fix_nated_sdp and force_rtp_proxy,
as the SDP will be mangled (two IP addresses, one after the other).
However, I can't get the SDP rewritten properly without using
fix_nated_sdp.

No matter how I call force_rtp_proxy, I can't specify my own IP
address. It works as expected when using fix_nated_sdp though.
Here's how I call it:

force_rtp_proxy("coe","10.252.1.8");

I've tried multiple variants of flags, c, co, o, coe, coi, i, no
flags, etc etc, but no matter what I do, the public interface IP
address does not change to the one supplied in the function, and
remains the public IP address.

So, to summarize;
I can change all the headers to be correct with the fix_nated_sdp function.
When using that function, RTPProxy does not relay the RTP streams.
When I use force_rtp_proxy / rtpproxy_offer, RTPProxy does indeed
relay the streams, but does not alter the SDP IP address information
to the required specifications.

Is there something that I'm missing in the usage of the
force_rtp_proxy function, or is it not working as documented?

Best regards,
Örn

2009/10/14 Alex Balashov <abalashov@...>:

> Örn Arnarson wrote:
>
>> Oh, I forgot one thing;
>>
>> I'm using fix_nated_sdp, as previously mentioned. I have a hunch that
>> because I'm not using force_rtp_proxy/rtpproxy_offer it's not being
>> relayed (a hunch, because I don't fully understand how rtpproxy
>> works). Problem is though, I can't get the IP addresses correct by
>> using rtpproxy_offer.
>
> On behalf of Joe (same company) I will add that there is no NAT scenario
> here.  Both the private and public network are directly routable from the
> rtpproxy box;  there is no IP address oversubscription, and no reason to
> ignore ports or addresses in SDP and replace them with received parameters.
>  This is not a far-end NAT traversal solution.
>
> What is basically being asked here is how to bridge between two interfaces
> (internal, external) without NAT using rtpproxy, and if anyone can provide a
> canonical implementation or example.
>
> We've got it running in bridge mode, e.g.
>
>  rtpproxy -F -s udp:10.x.x.x:5050 -l 10.x.x.x/89.y.y.y
>
> ... and basically, are just wondering how to get this to work on the
> Kamailio side using rtpproxy_offer()/rtpproxy_answer().
>
> The RTP proxy machine is a dedicated host;  the SIP proxies are virtual.
>
>
> --
> Alex Balashov - Principal
> Evariste Systems
> Web     : http://www.evaristesys.com/
> Tel     : (+1) [phone]
> Direct  : (+1) [phone]
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Örn Arnarson]

Hi Alex,

Can you give an example of code for the rtpproxy_offer/answer
functions so that I can try them out and see whether the SDP
substitution happens? Because, as you may remember from my last mail,
the bridging is working for me, but the substitution isn't.

Regards,
Örn

2009/10/15 Alex Balashov <abalashov@...>:

> An update on this:  we've gotten the SDP substitution to happen correctly
> using rtpproxy_offer()/answer(), and the media endpoints now send their
> media to the correct respective interface addresses on the rtpproxy host.
>
> However, despite allegedly running in "bridge mode" (-l one.ip/two.ip), the
> rtpproxy does not appear to be "bridging" them - that is, it is not
> forwarding.
>
> We previously found that having /proc/sys/net/ipv4/ip_forward on was an
> issue, so we turned it on - but to no effect.
>
> Alex Balashov wrote:
>
>> Örn Arnarson wrote:
>>
>>> Oh, I forgot one thing;
>>>
>>> I'm using fix_nated_sdp, as previously mentioned. I have a hunch that
>>> because I'm not using force_rtp_proxy/rtpproxy_offer it's not being
>>> relayed (a hunch, because I don't fully understand how rtpproxy
>>> works). Problem is though, I can't get the IP addresses correct by
>>> using rtpproxy_offer.
>>
>> On behalf of Joe (same company) I will add that there is no NAT scenario
>> here.  Both the private and public network are directly routable from the
>> rtpproxy box;  there is no IP address oversubscription, and no reason to
>> ignore ports or addresses in SDP and replace them with received parameters.
>>  This is not a far-end NAT traversal solution.
>>
>> What is basically being asked here is how to bridge between two interfaces
>> (internal, external) without NAT using rtpproxy, and if anyone can provide a
>> canonical implementation or example.
>>
>> We've got it running in bridge mode, e.g.
>>
>>  rtpproxy -F -s udp:10.x.x.x:5050 -l 10.x.x.x/89.y.y.y
>>
>> ... and basically, are just wondering how to get this to work on the
>> Kamailio side using rtpproxy_offer()/rtpproxy_answer().
>>
>> The RTP proxy machine is a dedicated host;  the SIP proxies are virtual.
>>
>>
>
>
> --
> Alex Balashov - Principal
> Evariste Systems
> Web     : http://www.evaristesys.com/
> Tel     : (+1) [phone]
> Direct  : (+1) [phone]
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Örn Arnarson]

Hi Klaus,

I've gathered as much; I'm able to bridge between the interfaces, but
if I do that, I can't rewrite the SDP properly. I can only rewrite the
SDP by using fix_nated_sdp. If I use fix_nated_sdp and the rtpproxy
functions to bridge the call, the SDP gets messed up.
E.g. I rewrite the media address with fix_nated_sdp from the public
IP, 157.157.x.x to 10.252.1.8, but if I then call the force_rtp_proxy
function, it just appends the public IP address directly behind the
10.252.1.8 IP address, so the SDP media address is now
10.252.1.8157.157.x.x.

Any ideas?

Regards,
Örn

On Thu, Oct 15, 2009 at 12:30 AM, Klaus Darilion
<klaus.mailinglists@...> wrote:

> I think it is not about offer/answer, but you have to call rtpproxy*
> functions with  the proper parameter to activate bridging inside rtpproxy.
>
> E.g. there is an (I guess rather old) example for ipv4 to ipv6 bridging, but
> from the logic it should be similar to v4:v6 bridging:
> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/4to6.cfg?revision=2&view=markup
>
> Take a look at the i and e flag:
> http://kamailio.org/docs/modules/1.5.x/nathelper#id2468157
>
> regards
> klaus
>
> Joe Hart wrote:
>>
>> Hi all,
>>
>> For a project on which I'm currently working, I am having some problems
>> figuring out how to correctly configure Kamailio to communicate with RTP
>> Proxy in order to send media into and out of a network with private IP
>> address ranges.
>>
>> I have a proxy set up to send the SIP traffic, and all of this is working
>> fine.  However, I'm having some trouble getting the RTP Proxy set up.
>>  Currently, when the call is connected, the offer/answer is made and RTP
>> Proxy seems to be taking over, but I'm having trouble getting my audio to
>> flow in both directions.
>>
>> Examination of the traffic coming into and out of this machine seems to
>> indicate that the IP addresses aren't being mangled correctly. Specifically,
>> it appears the internal IP address isn't being changed to reflect the IP
>> address of the machine on which RTP Proxy is running, so that when the
>> caller tries to send audio back, the IP it's given to reply to is 10.10.x.x,
>> which obviously won't work.
>>
>> I have tried experimenting with specifically setting IP addresses in the
>> rtpproxy_offer() and _answer() methods to no avail, as well as setting
>> various flags in those methods.  However, I must admit that I'm not entirely
>> sure what's happening under the hood with these methods, or what rtpproxy is
>> doing with that information when it gets it.  Rather than continue to hack
>> at this by trial and error, I'm hoping someone here can point me in the
>> right direction.
>>
>> Any advice, example code or pep talks would be greatly appreciated.
>>
>> Thanks in advance,
>>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users@...
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Klaus Darilion wrote:

> when using the correct parameters (flags), force_rtpproxy() should be
> able to fix the SDP correctly

For us, we are able to achieve that result - even with
rtpproxy_offer/answer().   The endpoints begin to send media to the
correct addresses based on the correctly mangled SDP.

The problem is that rtpproxy does not actually pass the media through
to the other interface.  In other words, it does not appear to perform
its alleged bridging function.

--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Örn Arnarson]

Hi Klaus,

Yes, I have learned that both are not to be used. However, I am unable
to get the SDP to change with the force_rtp_proxy call. Can you see
anything wrong with the way I am calling it? The call is clearly in
effect, as it does change the media addresses, just not to what I need
them to be. Even if I do specify them explicitly in the call.

Best regards,
Örn

2009/10/15 Klaus Darilion <klaus.mailinglists@...>:

> never call both functions. That will not work (you see the result)
>
> when using the correct parameters (flags), force_rtpproxy() should be able
> to fix the SDP correctly
>
> regards
> klaus
>
> Örn Arnarson wrote:
>>
>> Hi Klaus,
>>
>> I've gathered as much; I'm able to bridge between the interfaces, but
>> if I do that, I can't rewrite the SDP properly. I can only rewrite the
>> SDP by using fix_nated_sdp. If I use fix_nated_sdp and the rtpproxy
>> functions to bridge the call, the SDP gets messed up.
>> E.g. I rewrite the media address with fix_nated_sdp from the public
>> IP, 157.157.x.x to 10.252.1.8, but if I then call the force_rtp_proxy
>> function, it just appends the public IP address directly behind the
>> 10.252.1.8 IP address, so the SDP media address is now
>> 10.252.1.8157.157.x.x.
>>
>> Any ideas?
>>
>> Regards,
>> Örn
>>
>> On Thu, Oct 15, 2009 at 12:30 AM, Klaus Darilion
>> <klaus.mailinglists@...> wrote:
>>>
>>> I think it is not about offer/answer, but you have to call rtpproxy*
>>> functions with  the proper parameter to activate bridging inside
>>> rtpproxy.
>>>
>>> E.g. there is an (I guess rather old) example for ipv4 to ipv6 bridging,
>>> but
>>> from the logic it should be similar to v4:v6 bridging:
>>>
>>> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/4to6.cfg?revision=2&view=markup
>>>
>>> Take a look at the i and e flag:
>>> http://kamailio.org/docs/modules/1.5.x/nathelper#id2468157
>>>
>>> regards
>>> klaus
>>>
>>> Joe Hart wrote:
>>>>
>>>> Hi all,
>>>>
>>>> For a project on which I'm currently working, I am having some problems
>>>> figuring out how to correctly configure Kamailio to communicate with RTP
>>>> Proxy in order to send media into and out of a network with private IP
>>>> address ranges.
>>>>
>>>> I have a proxy set up to send the SIP traffic, and all of this is
>>>> working
>>>> fine.  However, I'm having some trouble getting the RTP Proxy set up.
>>>>  Currently, when the call is connected, the offer/answer is made and RTP
>>>> Proxy seems to be taking over, but I'm having trouble getting my audio
>>>> to
>>>> flow in both directions.
>>>>
>>>> Examination of the traffic coming into and out of this machine seems to
>>>> indicate that the IP addresses aren't being mangled correctly.
>>>> Specifically,
>>>> it appears the internal IP address isn't being changed to reflect the IP
>>>> address of the machine on which RTP Proxy is running, so that when the
>>>> caller tries to send audio back, the IP it's given to reply to is
>>>> 10.10.x.x,
>>>> which obviously won't work.
>>>>
>>>> I have tried experimenting with specifically setting IP addresses in the
>>>> rtpproxy_offer() and _answer() methods to no avail, as well as setting
>>>> various flags in those methods.  However, I must admit that I'm not
>>>> entirely
>>>> sure what's happening under the hood with these methods, or what
>>>> rtpproxy is
>>>> doing with that information when it gets it.  Rather than continue to
>>>> hack
>>>> at this by trial and error, I'm hoping someone here can point me in the
>>>> right direction.
>>>>
>>>> Any advice, example code or pep talks would be greatly appreciated.
>>>>
>>>> Thanks in advance,
>>>>
>>> _______________________________________________
>>> Kamailio (OpenSER) - Users mailing list
>>> Users@...
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Klaus Darilion-2]

maybe an iptables problem on the rtpproxy server?

Alex Balashov wrote:

> Daniel-Constantin Mierla wrote:
>
>> IIRC, I use:
>>
>> if(dst_ip==private_ip)
>>       force_rtp_proxy("ocfaei");
>> else
>>       force_rtp_proxy("ocfaie");
>>
>> rtpproxy started with: -l external_ip/private_ip
>>
>> Probably is rtpproxy 1.1 -- cannot check right now.
>
> I just tried this and it works, from the point of view of SDP.  We were
> already able to obtain this result.
>
> The problem is that the actual rtpproxy does not seem to forward the
> packets that come into one interface toward the other, so no media is
> exchanged.
>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Klaus Darilion-2]

Alex Balashov wrote:

> Alex Balashov wrote:
>> Daniel-Constantin Mierla wrote:
>>
>>> IIRC, I use:
>>>
>>> if(dst_ip==private_ip)
>>>       force_rtp_proxy("ocfaei");
>>> else
>>>       force_rtp_proxy("ocfaie");
>>>
>>> rtpproxy started with: -l external_ip/private_ip
>>>
>>> Probably is rtpproxy 1.1 -- cannot check right now.
>>
>> I just tried this and it works, from the point of view of SDP.  We
>> were already able to obtain this result.
>>
>> The problem is that the actual rtpproxy does not seem to forward the
>> packets that come into one interface toward the other, so no media is
>> exchanged.
>>
>
> An additional note:  if I turn OFF /proc/sys/net/ipv4/ip_forward and
> then start the proxy in bridging mode, the following happens when it is
> invoked:
>
> DBUG:handle_command: received command "8725_4 UAIEc0,101
> 5f1690462d84b3814915b05f65c626bd@... 208.52.173.7 11832
> as214288b6;1"
> INFO:handle_command: new session
> 5f1690462d84b3814915b05f65c626bd@..., tag as214288b6;1
> requested, type strong
> Segmentation fault
>
> In other words, it seems to require ip_forward to be on in order to not
> crash, but when it is on, no packets are exchanged between the interfaces.

That's strange, rtpproxy is in usermaode, thus the ip_forward setting
should not cause any influence.

regards
klaus

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[miconda]

Hello,

I have several rtp bridging deployments, I started from alg.cfg

http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/alg.cfg?revision=2&view=markup

Cheers,
Daniel


On 15.10.2009 17:06 Uhr, Örn Arnarson wrote:

> Hi Klaus,
>
> Yes, I have learned that both are not to be used. However, I am unable
> to get the SDP to change with the force_rtp_proxy call. Can you see
> anything wrong with the way I am calling it? The call is clearly in
> effect, as it does change the media addresses, just not to what I need
> them to be. Even if I do specify them explicitly in the call.
>
> Best regards,
> Örn
>
> 2009/10/15 Klaus Darilion <klaus.mailinglists@...>:
>  
>> never call both functions. That will not work (you see the result)
>>
>> when using the correct parameters (flags), force_rtpproxy() should be able
>> to fix the SDP correctly
>>
>> regards
>> klaus
>>
>> Örn Arnarson wrote:
>>    
>>> Hi Klaus,
>>>
>>> I've gathered as much; I'm able to bridge between the interfaces, but
>>> if I do that, I can't rewrite the SDP properly. I can only rewrite the
>>> SDP by using fix_nated_sdp. If I use fix_nated_sdp and the rtpproxy
>>> functions to bridge the call, the SDP gets messed up.
>>> E.g. I rewrite the media address with fix_nated_sdp from the public
>>> IP, 157.157.x.x to 10.252.1.8, but if I then call the force_rtp_proxy
>>> function, it just appends the public IP address directly behind the
>>> 10.252.1.8 IP address, so the SDP media address is now
>>> 10.252.1.8157.157.x.x.
>>>
>>> Any ideas?
>>>
>>> Regards,
>>> Örn
>>>
>>> On Thu, Oct 15, 2009 at 12:30 AM, Klaus Darilion
>>> <klaus.mailinglists@...> wrote:
>>>      
>>>> I think it is not about offer/answer, but you have to call rtpproxy*
>>>> functions with  the proper parameter to activate bridging inside
>>>> rtpproxy.
>>>>
>>>> E.g. there is an (I guess rather old) example for ipv4 to ipv6 bridging,
>>>> but
>>>> from the logic it should be similar to v4:v6 bridging:
>>>>
>>>> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/4to6.cfg?revision=2&view=markup
>>>>
>>>> Take a look at the i and e flag:
>>>> http://kamailio.org/docs/modules/1.5.x/nathelper#id2468157
>>>>
>>>> regards
>>>> klaus
>>>>
>>>> Joe Hart wrote:
>>>>        
>>>>> Hi all,
>>>>>
>>>>> For a project on which I'm currently working, I am having some problems
>>>>> figuring out how to correctly configure Kamailio to communicate with RTP
>>>>> Proxy in order to send media into and out of a network with private IP
>>>>> address ranges.
>>>>>
>>>>> I have a proxy set up to send the SIP traffic, and all of this is
>>>>> working
>>>>> fine.  However, I'm having some trouble getting the RTP Proxy set up.
>>>>>  Currently, when the call is connected, the offer/answer is made and RTP
>>>>> Proxy seems to be taking over, but I'm having trouble getting my audio
>>>>> to
>>>>> flow in both directions.
>>>>>
>>>>> Examination of the traffic coming into and out of this machine seems to
>>>>> indicate that the IP addresses aren't being mangled correctly.
>>>>> Specifically,
>>>>> it appears the internal IP address isn't being changed to reflect the IP
>>>>> address of the machine on which RTP Proxy is running, so that when the
>>>>> caller tries to send audio back, the IP it's given to reply to is
>>>>> 10.10.x.x,
>>>>> which obviously won't work.
>>>>>
>>>>> I have tried experimenting with specifically setting IP addresses in the
>>>>> rtpproxy_offer() and _answer() methods to no avail, as well as setting
>>>>> various flags in those methods.  However, I must admit that I'm not
>>>>> entirely
>>>>> sure what's happening under the hood with these methods, or what
>>>>> rtpproxy is
>>>>> doing with that information when it gets it.  Rather than continue to
>>>>> hack
>>>>> at this by trial and error, I'm hoping someone here can point me in the
>>>>> right direction.
>>>>>
>>>>> Any advice, example code or pep talks would be greatly appreciated.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>>          
>>>> _______________________________________________
>>>> Kamailio (OpenSER) - Users mailing list
>>>> Users@...
>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>        
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users@...
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/


_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

We attempted that formula as well.  The problem is that rtpproxy won't
actually forward the packets to the other interface when started in what
is supposed to be bridging mode, i.e.

   rtpproxy -F -s udp:xxx.xxx.xxx.xxx:5060 -l outside.ip/inside.ip

I enabled /proc/sys/net/ipv4/ip_forward but it did not help.

Daniel-Constantin Mierla wrote:

> Hello,
>
> I have several rtp bridging deployments, I started from alg.cfg
>
> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/alg.cfg?revision=2&view=markup 
>
>
> Cheers,
> Daniel
>
>
> On 15.10.2009 17:06 Uhr, Örn Arnarson wrote:
>> Hi Klaus,
>>
>> Yes, I have learned that both are not to be used. However, I am unable
>> to get the SDP to change with the force_rtp_proxy call. Can you see
>> anything wrong with the way I am calling it? The call is clearly in
>> effect, as it does change the media addresses, just not to what I need
>> them to be. Even if I do specify them explicitly in the call.
>>
>> Best regards,
>> Örn
>>
>> 2009/10/15 Klaus Darilion <klaus.mailinglists@...>:
>>  
>>> never call both functions. That will not work (you see the result)
>>>
>>> when using the correct parameters (flags), force_rtpproxy() should be
>>> able
>>> to fix the SDP correctly
>>>
>>> regards
>>> klaus
>>>
>>> Örn Arnarson wrote:
>>>    
>>>> Hi Klaus,
>>>>
>>>> I've gathered as much; I'm able to bridge between the interfaces, but
>>>> if I do that, I can't rewrite the SDP properly. I can only rewrite the
>>>> SDP by using fix_nated_sdp. If I use fix_nated_sdp and the rtpproxy
>>>> functions to bridge the call, the SDP gets messed up.
>>>> E.g. I rewrite the media address with fix_nated_sdp from the public
>>>> IP, 157.157.x.x to 10.252.1.8, but if I then call the force_rtp_proxy
>>>> function, it just appends the public IP address directly behind the
>>>> 10.252.1.8 IP address, so the SDP media address is now
>>>> 10.252.1.8157.157.x.x.
>>>>
>>>> Any ideas?
>>>>
>>>> Regards,
>>>> Örn
>>>>
>>>> On Thu, Oct 15, 2009 at 12:30 AM, Klaus Darilion
>>>> <klaus.mailinglists@...> wrote:
>>>>      
>>>>> I think it is not about offer/answer, but you have to call rtpproxy*
>>>>> functions with  the proper parameter to activate bridging inside
>>>>> rtpproxy.
>>>>>
>>>>> E.g. there is an (I guess rather old) example for ipv4 to ipv6
>>>>> bridging,
>>>>> but
>>>>> from the logic it should be similar to v4:v6 bridging:
>>>>>
>>>>> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/4to6.cfg?revision=2&view=markup 
>>>>>
>>>>>
>>>>> Take a look at the i and e flag:
>>>>> http://kamailio.org/docs/modules/1.5.x/nathelper#id2468157
>>>>>
>>>>> regards
>>>>> klaus
>>>>>
>>>>> Joe Hart wrote:
>>>>>        
>>>>>> Hi all,
>>>>>>
>>>>>> For a project on which I'm currently working, I am having some
>>>>>> problems
>>>>>> figuring out how to correctly configure Kamailio to communicate
>>>>>> with RTP
>>>>>> Proxy in order to send media into and out of a network with
>>>>>> private IP
>>>>>> address ranges.
>>>>>>
>>>>>> I have a proxy set up to send the SIP traffic, and all of this is
>>>>>> working
>>>>>> fine.  However, I'm having some trouble getting the RTP Proxy set up.
>>>>>>  Currently, when the call is connected, the offer/answer is made
>>>>>> and RTP
>>>>>> Proxy seems to be taking over, but I'm having trouble getting my
>>>>>> audio
>>>>>> to
>>>>>> flow in both directions.
>>>>>>
>>>>>> Examination of the traffic coming into and out of this machine
>>>>>> seems to
>>>>>> indicate that the IP addresses aren't being mangled correctly.
>>>>>> Specifically,
>>>>>> it appears the internal IP address isn't being changed to reflect
>>>>>> the IP
>>>>>> address of the machine on which RTP Proxy is running, so that when
>>>>>> the
>>>>>> caller tries to send audio back, the IP it's given to reply to is
>>>>>> 10.10.x.x,
>>>>>> which obviously won't work.
>>>>>>
>>>>>> I have tried experimenting with specifically setting IP addresses
>>>>>> in the
>>>>>> rtpproxy_offer() and _answer() methods to no avail, as well as
>>>>>> setting
>>>>>> various flags in those methods.  However, I must admit that I'm not
>>>>>> entirely
>>>>>> sure what's happening under the hood with these methods, or what
>>>>>> rtpproxy is
>>>>>> doing with that information when it gets it.  Rather than continue to
>>>>>> hack
>>>>>> at this by trial and error, I'm hoping someone here can point me
>>>>>> in the
>>>>>> right direction.
>>>>>>
>>>>>> Any advice, example code or pep talks would be greatly appreciated.
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>>          
>>>>> _______________________________________________
>>>>> Kamailio (OpenSER) - Users mailing list
>>>>> Users@...
>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>        
>>
>> _______________________________________________
>> Kamailio (OpenSER) - Users mailing list
>> Users@...
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>

--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[miconda]

IIRC, I use:

if(dst_ip==private_ip)
       force_rtp_proxy("ocfaei");
 else
       force_rtp_proxy("ocfaie");

rtpproxy started with: -l external_ip/private_ip

Probably is rtpproxy 1.1 -- cannot check right now.

Cheers,
Daniel

On 15.10.2009 19:38 Uhr, Alex Balashov wrote:

> We attempted that formula as well.  The problem is that rtpproxy won't
> actually forward the packets to the other interface when started in
> what is supposed to be bridging mode, i.e.
>
>   rtpproxy -F -s udp:xxx.xxx.xxx.xxx:5060 -l outside.ip/inside.ip
>
> I enabled /proc/sys/net/ipv4/ip_forward but it did not help.
>
> Daniel-Constantin Mierla wrote:
>
>> Hello,
>>
>> I have several rtp bridging deployments, I started from alg.cfg
>>
>> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/alg.cfg?revision=2&view=markup 
>>
>>
>> Cheers,
>> Daniel
>>
>>
>> On 15.10.2009 17:06 Uhr, Örn Arnarson wrote:
>>> Hi Klaus,
>>>
>>> Yes, I have learned that both are not to be used. However, I am unable
>>> to get the SDP to change with the force_rtp_proxy call. Can you see
>>> anything wrong with the way I am calling it? The call is clearly in
>>> effect, as it does change the media addresses, just not to what I need
>>> them to be. Even if I do specify them explicitly in the call.
>>>
>>> Best regards,
>>> Örn
>>>
>>> 2009/10/15 Klaus Darilion <klaus.mailinglists@...>:
>>>  
>>>> never call both functions. That will not work (you see the result)
>>>>
>>>> when using the correct parameters (flags), force_rtpproxy() should
>>>> be able
>>>> to fix the SDP correctly
>>>>
>>>> regards
>>>> klaus
>>>>
>>>> Örn Arnarson wrote:
>>>>  
>>>>> Hi Klaus,
>>>>>
>>>>> I've gathered as much; I'm able to bridge between the interfaces, but
>>>>> if I do that, I can't rewrite the SDP properly. I can only rewrite
>>>>> the
>>>>> SDP by using fix_nated_sdp. If I use fix_nated_sdp and the rtpproxy
>>>>> functions to bridge the call, the SDP gets messed up.
>>>>> E.g. I rewrite the media address with fix_nated_sdp from the public
>>>>> IP, 157.157.x.x to 10.252.1.8, but if I then call the force_rtp_proxy
>>>>> function, it just appends the public IP address directly behind the
>>>>> 10.252.1.8 IP address, so the SDP media address is now
>>>>> 10.252.1.8157.157.x.x.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Regards,
>>>>> Örn
>>>>>
>>>>> On Thu, Oct 15, 2009 at 12:30 AM, Klaus Darilion
>>>>> <klaus.mailinglists@...> wrote:
>>>>>    
>>>>>> I think it is not about offer/answer, but you have to call rtpproxy*
>>>>>> functions with  the proper parameter to activate bridging inside
>>>>>> rtpproxy.
>>>>>>
>>>>>> E.g. there is an (I guess rather old) example for ipv4 to ipv6
>>>>>> bridging,
>>>>>> but
>>>>>> from the logic it should be similar to v4:v6 bridging:
>>>>>>
>>>>>> http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/examples/4to6.cfg?revision=2&view=markup 
>>>>>>
>>>>>>
>>>>>> Take a look at the i and e flag:
>>>>>> http://kamailio.org/docs/modules/1.5.x/nathelper#id2468157
>>>>>>
>>>>>> regards
>>>>>> klaus
>>>>>>
>>>>>> Joe Hart wrote:
>>>>>>      
>>>>>>> Hi all,
>>>>>>>
>>>>>>> For a project on which I'm currently working, I am having some
>>>>>>> problems
>>>>>>> figuring out how to correctly configure Kamailio to communicate
>>>>>>> with RTP
>>>>>>> Proxy in order to send media into and out of a network with
>>>>>>> private IP
>>>>>>> address ranges.
>>>>>>>
>>>>>>> I have a proxy set up to send the SIP traffic, and all of this is
>>>>>>> working
>>>>>>> fine.  However, I'm having some trouble getting the RTP Proxy
>>>>>>> set up.
>>>>>>>  Currently, when the call is connected, the offer/answer is made
>>>>>>> and RTP
>>>>>>> Proxy seems to be taking over, but I'm having trouble getting my
>>>>>>> audio
>>>>>>> to
>>>>>>> flow in both directions.
>>>>>>>
>>>>>>> Examination of the traffic coming into and out of this machine
>>>>>>> seems to
>>>>>>> indicate that the IP addresses aren't being mangled correctly.
>>>>>>> Specifically,
>>>>>>> it appears the internal IP address isn't being changed to
>>>>>>> reflect the IP
>>>>>>> address of the machine on which RTP Proxy is running, so that
>>>>>>> when the
>>>>>>> caller tries to send audio back, the IP it's given to reply to is
>>>>>>> 10.10.x.x,
>>>>>>> which obviously won't work.
>>>>>>>
>>>>>>> I have tried experimenting with specifically setting IP
>>>>>>> addresses in the
>>>>>>> rtpproxy_offer() and _answer() methods to no avail, as well as
>>>>>>> setting
>>>>>>> various flags in those methods.  However, I must admit that I'm not
>>>>>>> entirely
>>>>>>> sure what's happening under the hood with these methods, or what
>>>>>>> rtpproxy is
>>>>>>> doing with that information when it gets it.  Rather than
>>>>>>> continue to
>>>>>>> hack
>>>>>>> at this by trial and error, I'm hoping someone here can point me
>>>>>>> in the
>>>>>>> right direction.
>>>>>>>
>>>>>>> Any advice, example code or pep talks would be greatly appreciated.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>>          
>>>>>> _______________________________________________
>>>>>> Kamailio (OpenSER) - Users mailing list
>>>>>> Users@...
>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>        
>>>
>>> _______________________________________________
>>> Kamailio (OpenSER) - Users mailing list
>>> Users@...
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>
>

--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/


_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Daniel-Constantin Mierla wrote:

> IIRC, I use:
>
> if(dst_ip==private_ip)
>       force_rtp_proxy("ocfaei");
> else
>       force_rtp_proxy("ocfaie");
>
> rtpproxy started with: -l external_ip/private_ip
>
> Probably is rtpproxy 1.1 -- cannot check right now.

Interesting - thanks Daniel.

I do not think I understand why it is important that the flags occur in
a certain order within the string, or why it is valid to duplicate those
flags as in the alg.cfg example.

I thought these flags just mapped to bits set in a bit field, such that
for example a == (1 << 1) and enabling it is just a matter of flags |= a?

--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Daniel-Constantin Mierla wrote:

> IIRC, I use:
>
> if(dst_ip==private_ip)
>       force_rtp_proxy("ocfaei");
> else
>       force_rtp_proxy("ocfaie");
>
> rtpproxy started with: -l external_ip/private_ip
>
> Probably is rtpproxy 1.1 -- cannot check right now.

I just tried this and it works, from the point of view of SDP.  We were
already able to obtain this result.

The problem is that the actual rtpproxy does not seem to forward the
packets that come into one interface toward the other, so no media is
exchanged.

--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Alex Balashov wrote:

> Daniel-Constantin Mierla wrote:
>
>> IIRC, I use:
>>
>> if(dst_ip==private_ip)
>>       force_rtp_proxy("ocfaei");
>> else
>>       force_rtp_proxy("ocfaie");
>>
>> rtpproxy started with: -l external_ip/private_ip
>>
>> Probably is rtpproxy 1.1 -- cannot check right now.
>
> I just tried this and it works, from the point of view of SDP.  We were
> already able to obtain this result.
>
> The problem is that the actual rtpproxy does not seem to forward the
> packets that come into one interface toward the other, so no media is
> exchanged.
>

An additional note:  if I turn OFF /proc/sys/net/ipv4/ip_forward and
then start the proxy in bridging mode, the following happens when it is
invoked:

DBUG:handle_command: received command "8725_4 UAIEc0,101
5f1690462d84b3814915b05f65c626bd@... 208.52.173.7 11832
as214288b6;1"
INFO:handle_command: new session
5f1690462d84b3814915b05f65c626bd@..., tag as214288b6;1
requested, type strong
Segmentation fault

In other words, it seems to require ip_forward to be on in order to not
crash, but when it is on, no packets are exchanged between the interfaces.

--
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) [phone]
Direct  : (+1) [phone]

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users