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(a)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(a)evaristesys.com>wrote;wrote: