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


_______________________________________________
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