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@arnarson.net:

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@evaristesys.com 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) (678) 954-0670 Direct  : (+1) (678) 954-0673

---

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

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.

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@pernau.at 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/ex...

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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

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@pernau.at:

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@pernau.at 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/ex...

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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

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/ex...

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@pernau.at:

...

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@pernau.at 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/ex...

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@lists.kamailio.org 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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

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?

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.

Hi Alex!

Could you finally solve the issue? If yes, it would be cool if you could post the result (rtpproxy command line and the force_rtpproxy commands).

thanks klaus

Alex Balashov wrote:

No firewall rules anywhere. That's the first thing I checked.

Besides, I did the packet capture right on the rtpproxy server; even if firewall rules were preventing media from getting out, I would still see attempts to send it onto the wire.

Klaus Darilion wrote:

...

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.

I got it working by using Klaus's flags;

if ($ruri =~ "10.252.*") { force_send_socket("10.252.1.8"); force_rtp_proxy("ocfaie");

The SDP is correctly re-written and rtpproxy bridges the stream.

Regards, Örn

2009/10/16 Örn Arnarson orn@arnarson.net:

Yes, I'd be very interested to see that too :-)

Regards, Örn

On Thu, Oct 15, 2009 at 8:41 PM, Klaus Darilion klaus.mailinglists@pernau.at wrote:

...

Hi Alex!

Could you finally solve the issue? If yes, it would be cool if you could post the result (rtpproxy command line and the force_rtpproxy commands).

thanks klaus

Alex Balashov wrote:

...

No firewall rules anywhere.  That's the first thing I checked.

Besides, I did the packet capture right on the rtpproxy server;  even if firewall rules were preventing media from getting out, I would still see attempts to send it onto the wire.

Klaus Darilion wrote:

...

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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

Alex Balashov schrieb:

That's pretty much what I did.

All I had to do was use force_rtp_proxy(). Everything was broken when I tried to use rtpproxy_offer/answer, though the code suggests they are just wrappers around force_rtp_proxy().

That's strange. I took a look at the code and these are really just wrappers - fmro code point of view it looks fine.

Do you have syslog traces?

regards klaus

Yes, you should find the function engage_rtpproxy on module docs and use it. It will work exactly like your old force-rtp-proxy but with more enhanced way. On Sep 15, 2012 7:34 AM, "Brandon Armstead" brandon@cryy.com wrote:

Klaus,

It seems that force_rtp_proxy is removed in Kamailio 3.3 --- has there been a work-around for this bridge issue without using force_rtp_proxy?

Sincerely, Brandon Armstead

On Wed, Nov 4, 2009 at 5:46 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:

...

Alex Balashov schrieb:

That's pretty much what I did.

...

All I had to do was use force_rtp_proxy(). Everything was broken when I tried to use rtpproxy_offer/answer, though the code suggests they are just wrappers around force_rtp_proxy().

That's strange. I took a look at the code and these are really just wrappers - fmro code point of view it looks fine.

Do you have syslog traces?

regards klaus

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

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

ok ignore the name in my previous email: its http://www.kamailio.org/docs/modules/3.3.x/modules/rtpproxy.html#id2550699

On Sat, Sep 15, 2012 at 10:05 AM, Brandon Armstead brandon@cryy.com wrote:

Samy,

I am not locating any such functions, engage_rtpproxy ?

Perhaps you could point me further into the right direction?

Sincerely, Brandon Armstead

On Fri, Sep 14, 2012 at 9:13 PM, SamyGo govoiper@gmail.com wrote:

...

Yes, you should find the function engage_rtpproxy on module docs and use it. It will work exactly like your old force-rtp-proxy but with more enhanced way. On Sep 15, 2012 7:34 AM, "Brandon Armstead" brandon@cryy.com wrote:

...

Klaus,

It seems that force_rtp_proxy is removed in Kamailio 3.3 --- has there been a work-around for this bridge issue without using force_rtp_proxy?

Sincerely, Brandon Armstead

On Wed, Nov 4, 2009 at 5:46 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:

...

Alex Balashov schrieb:

That's pretty much what I did.

...

All I had to do was use force_rtp_proxy(). Everything was broken when I tried to use rtpproxy_offer/answer, though the code suggests they are just wrappers around force_rtp_proxy().

That's strange. I took a look at the code and these are really just wrappers - fmro code point of view it looks fine.

Do you have syslog traces?

regards klaus

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

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi,

Seems really strange: for anything conclusive toward the solution I need atleast a kamailio+rtpproxy syslogs appearing for one call establishment and hangup. Second thing that will help us greatly is the pcap traces from the server for a call. use tcpdump or tshark or anyother tool of your choice to capture all the SIP and RTPs from the Kamailio server. That way atleast i can suggest you whats happening or whats the solution.

Also I need to know what is your network topology !! any firewalls on Kamailio server blocking UDP port ranges for audio? How are you starting your RTPproxy ?

Thanks BR Sammy

On Sat, Sep 15, 2012 at 11:15 AM, Brandon Armstead brandon@cryy.com wrote:

Samy,

I am utilizing these functions without any success.

Essentially the problem I am running into is the SDP is correctly mangled and negotiated, however rtpproxy simply never bridges the public side.

UAC 1 -> KAM -> UAC 2

I see RTP packets flow from UAC 1 -> KAM -> UAC 2

I also see RTP packets from from UAC 2 -> KAM

The caller does not hear any audio, as KAM/RTPProxy is not sending audio back to the caller.

Sincerely, Brandon Armstead

On Fri, Sep 14, 2012 at 11:12 PM, SamyGo govoiper@gmail.com wrote:

...

ok ignore the name in my previous email: its http://www.kamailio.org/docs/modules/3.3.x/modules/rtpproxy.html#id2550699

On Sat, Sep 15, 2012 at 10:05 AM, Brandon Armstead brandon@cryy.comwrote:

...

Samy,

I am not locating any such functions, engage_rtpproxy ?

Perhaps you could point me further into the right direction?

Sincerely, Brandon Armstead

On Fri, Sep 14, 2012 at 9:13 PM, SamyGo govoiper@gmail.com wrote:

...

Yes, you should find the function engage_rtpproxy on module docs and use it. It will work exactly like your old force-rtp-proxy but with more enhanced way. On Sep 15, 2012 7:34 AM, "Brandon Armstead" brandon@cryy.com wrote:

...

Klaus,

It seems that force_rtp_proxy is removed in Kamailio 3.3 --- has there been a work-around for this bridge issue without using force_rtp_proxy?

Sincerely, Brandon Armstead

On Wed, Nov 4, 2009 at 5:46 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:

...

Alex Balashov schrieb:

That's pretty much what I did. > > All I had to do was use force_rtp_proxy(). Everything was broken > when I tried to use rtpproxy_offer/answer, though the code suggests they > are just wrappers around force_rtp_proxy(). >

That's strange. I took a look at the code and these are really just wrappers - fmro code point of view it looks fine.

Do you have syslog traces?

regards klaus

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

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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 208.52.173.7 11832 as214288b6;1" INFO:handle_command: new session 5f1690462d84b3814915b05f65c626bd@208.52.173.7, 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.

Klaus Darilion wrote:

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 208.52.173.7 11832 as214288b6;1" INFO:handle_command: new session 5f1690462d84b3814915b05f65c626bd@208.52.173.7, 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.

That's what I thought too. It does not call any kernel IP forwarding APIs.

But it seems to make a difference!

Alex Balashov wrote:

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 208.52.173.7 11832 as214288b6;1" INFO:handle_command: new session 5f1690462d84b3814915b05f65c626bd@208.52.173.7, 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.

To be more precise:

Program received signal SIGSEGV, Segmentation fault. create_listener (cf=0x7fff90524230, ia=0x0, port=0x7fff905241ac, fds=0x7fff90524190) at rtpp_command.c:89 89 fds[i] = socket(ia->sa_family, SOCK_DGRAM, 0); (gdb) where #0 create_listener (cf=0x7fff90524230, ia=0x0, port=0x7fff905241ac, fds=0x7fff90524190) at rtpp_command.c:89 #1 0x0000000000408e09 in handle_command (cf=0x7fff90524230, controlfd=6, dtime=1255611428.2989011) at rtpp_command.c:789 #2 0x000000000040324b in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:742

Is rtpproxy even usable? Or is it too buggy due to lack of substantial evolution and maintenance since OpenSER 1.1/1.2 days?

Never mind, I was invoking it improperly:

-l one.ip other.ip

not:

-l one.ip/other.ip

this is because I copy/pasted it straight from the process list, where its argv exposure does not match the actual invocation.

It does not crash anymore, but it does continues to not bridge packets.

Daniel-Constantin Mierla wrote:

On 15.10.2009 20:02 Uhr, Alex Balashov wrote:

...

Alex Balashov wrote:

...

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 208.52.173.7 11832 as214288b6;1" INFO:handle_command: new session 5f1690462d84b3814915b05f65c626bd@208.52.173.7, 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.

To be more precise:

Program received signal SIGSEGV, Segmentation fault. create_listener (cf=0x7fff90524230, ia=0x0, port=0x7fff905241ac, fds=0x7fff90524190) at rtpp_command.c:89 89 fds[i] = socket(ia->sa_family, SOCK_DGRAM, 0); (gdb) where #0 create_listener (cf=0x7fff90524230, ia=0x0, port=0x7fff905241ac, fds=0x7fff90524190) at rtpp_command.c:89 #1 0x0000000000408e09 in handle_command (cf=0x7fff90524230, controlfd=6, dtime=1255611428.2989011) at rtpp_command.c:789 #2 0x000000000040324b in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:742

Is rtpproxy even usable? Or is it too buggy due to lack of substantial evolution and maintenance since OpenSER 1.1/1.2 days?

Never mind, I was invoking it improperly:

-l one.ip other.ip

not:

-l one.ip/other.ip

this is because I copy/pasted it straight from the process list, where its argv exposure does not match the actual invocation.

It does not crash anymore, but it does continues to not bridge packets.

I don't remember if there is need to enable ip forward, but definitely is working, version is openser 1.3 or kamailio 1.4, check with rtpproxy 1.0 -- i havent followed the latest devel of rtpproxy closely since I need it just for rtp relaying and latest versions has quite complex new features.

Strange. I have never gotten it to work well.

What are the plausible alternatives? MediaProxy 2.0 is too complex and requires a bunch of Python dependencies that aren't always easily installable, and, the RTP proxy component coming into SR from the SER side looks interesting but I'm not holding my breath on the integration.