Klaus: mhomed did work indeed - no need to force_send_socket() now :) Thanks

I'm progressing abit. 

RTP-Proxy was run in bridged mode like this.

rtpproxy -l 109.XX.XXX.212/192.168.2.29 -s udp:localhost:22222 -F -d DBUG

I'm getting RTPstats published on Kamailio/RTPproxy syslog.

I am using Echo() application in asterisk. So I've observed that my audio went to asterisk and asterisk did indeed send audio back to the RTPproxy assigned ports BUT the RTPproxy isn't forwarding the Audio back to the client or may-be the audio is lost somewhere in between RTPproxy<--->Client. [See Wirshark Flow-Diagram taken on-Kamailio/RTPproxy Server]

The # DTMF signal sent from Client phone reached asterisk safely and terminated the Echo() application.

I did the  ip_forwarding thingie too.-- somebody mentioned to do this if using RTPproxy in bridged mode.
#echo "1" >> /proc/sys/net/ipv4/ip_forward
#sysctl -p


Here are the corresponding Logs from Kamailio and rtpproxy.

************** INCOMING INVITE*********************************
NOTICE: <script>: INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) Started Accountin
NOTICE: <script>: INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) in Route[SIPOUT] block Sending to Route[RELAY]
NOTICE: <script>: INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) Sending Call to route(TOASTERISK)

************** ENGAGE DISPATCHER/LOAD-BALANCER*********************************
INFO:INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) FWDing to Asterisk - Use Load-Balancer here
INFO: <script>: INFO:INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) RELAY to Asterisk After LB 'sip:192.168.2.75:5060'

**************RELAY TO DESTINATION*********************************
NOTICE: <script>: INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) in Route[RELAY] block Sending to Route[RTPPROXY]

**************NAT-CHECKS/RTPPROXY DECISION*********************************
NOTICE: <script>: INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) in Route[RTPPROXY]
rtpproxy[12253]: DBUG:handle_command: received command "12276_8 Uc0,8,97,98,101 b0068178ac0b7f0c 203.215.176.22 9890 0078c812;1"
rtpproxy[12253]: INFO:handle_command: new session b0068178ac0b7f0c, tag 0078c812;1 requested, type strong
rtpproxy[12253]: INFO:handle_command: new session on a port 40920 created, tag 0078c812;1
rtpproxy[12253]: INFO:handle_command: pre-filling caller's address with 203.215.176.22:9890
rtpproxy[12253]: DBUG:doreply: sending reply "12276_8 40920 109.XX.XXX.29#012"

************** RTPPROXY FORCED NOW RELAY*********************************
NOTICE: <script>: INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) in Route[RTPPROXY] Forcing RTPproxy
NOTICE: <script>: INVITE from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) in Route[RELAY] destined for 'sip:192.168.2.75:5060'

************** REPLY FROM ASTERISK*********************************
NOTICE: <script>: incoming reply for 'INVITE' in onreply_route[REPLY_ONE]

**************NAT-CHECKS/RTPPROXY DECISION*********************************
NOTICE: <script>: incoming reply for 'INVITE' in onreply_route[REPLY_ONE] Forcing RTP-Proxy
rtpproxy[12253]: DBUG:handle_command: received command "12271_9 Lc0,8,97,98,101 b0068178ac0b7f0c 192.168.2.75 13692 0078c812;1 as1393db66;1"
rtpproxy[12253]: INFO:handle_command: lookup on ports 40920/47896, session timer restarted
rtpproxy[12253]: INFO:handle_command: pre-filling callee's address with 192.168.2.75:13692
rtpproxy[12253]: DBUG:doreply: sending reply "12271_9 47896 109.XX.XXX.29#012"

**************CALL ACK/ESTABLISHED*********************************
NOTICE: <script>: ACK from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) in Route[RELAY] block Setting FLB_NATB
NOTICE: <script>: ACK from sip:71125@109.XX.XXX.29 (IP:203.215.176.22:36388) in Route[RELAY] block Sending to Route[RTPPROXY]

**************BYE - BYE TIME*********************************
NOTICE: <script>: BYE from sip:71124@109.XX.XXX.29 (IP:192.168.2.75:5060) in Route[RELAY] block Setting FLB_NATB
NOTICE: <script>: BYE from sip:71124@109.XX.XXX.29 (IP:192.168.2.75:5060) in Route[RELAY] block Sending to Route[RTPPROXY]
NOTICE: <script>: BYE from sip:71124@109.XX.XXX.29 (IP:192.168.2.75:5060) in Route[RTPPROXY]

**************UNFORCE RTPPROXY*********************************
rtpproxy[12253]: DBUG:handle_command: received command "12270_9 Q b0068178ac0b7f0c as1393db66;1 0078c812"
rtpproxy[12253]: DBUG:doreply: sending reply "12270_9 60 0 325 325 0#012"

**************RTP-PROXY STATS*********************************
NOTICE: <script>: BYE from sip:71124@109.XX.XXX.29 (IP:192.168.2.75:5060) in Route[RTPPROXY] unforced RTP Proxy STATS='60 0 325 325 0#012'
rtpproxy[12253]: DBUG:handle_command: received command "12270_10 D b0068178ac0b7f0c as1393db66 0078c812"
rtpproxy[12253]: INFO:handle_delete: forcefully deleting session 1 on ports 40920/47896
rtpproxy[12253]: INFO:remove_session: RTP stats: 0 in from callee, 325 in from caller, 325 relayed, 0 dropped
rtpproxy[12253]: INFO:remove_session: RTCP stats: 0 in from callee, 3 in from caller, 3 relayed, 0 dropped
rtpproxy[12253]: INFO:remove_session: session on ports 40920/47896 is cleaned up
rtpproxy[12253]: DBUG:doreply: sending reply "12270_10 0#012"

Everything seems to be working fine except no media forwarded to end user !! :(

Hope to have it working sometime soon
Thank you all,

--
Regards,
Sammy


On Fri, Nov 4, 2011 at 12:51 PM, Sammy Govind <govoiper@gmail.com> wrote:
Thanks Alex for actually finding the thread for me- I'm reading these thoroughly and let me try these.

Klaus, mhome=1 is a good tip let me try it now: The problem is that when I set-up the scenario as I mentioned using Private IPs the end user starts sending the media to the private IP of asterisk (which is of-course not found anywhere near UAC) - The Asterisk Server on the other hand sends media to the Public IP of the Client(fixed by the NAT route and RTPproxy route automatically.)

What I've figured out theoretically is that i need to do the NAT address fixation in on-reply route from Asterisk servers. By fixing the c= header in Kamailio for the 200OK back to the client will make the Client software send media to the Kamailio/RTPproxy port and not on some private IP.

I hope I made some sense in what I wrote, do let me know if any clarification is required.

I'm just this one step away from publishing the setup on blog to benefit the community so any help from experts will be much much appreciated.

Best Regards,
Sammy

On Fri, Nov 4, 2011 at 12:27 PM, Alex Balashov <abalashov@evaristesys.com> wrote:
The fundamental complications that often arise in such a setup are summarised in these threads:

http://lists.sip-router.org/pipermail/sr-users/2010-October/065669.html

http://lists.sip-router.org/pipermail/sr-users/2011-September/069975.html

http://lists.sip-router.org/pipermail/sr-users/2011-September/070029.html

--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/


_______________________________________________
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