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.comwrote:
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.htmlhttp://lists.sip-router.org/pipermail/sr-users/2010-October/065669.html
http://lists.sip-router.org/**pipermail/sr-users/2011-** September/069975.htmlhttp://lists.sip-router.org/pipermail/sr-users/2011-September/069975.html
http://lists.sip-router.org/**pipermail/sr-users/2011-** September/070029.htmlhttp://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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
