Hello List,
I've successfully configured Kamailio with a farm of asterisk servers in L/B | F/O mode. The topology is something like below:
User<-->Kamailio<-->Asterisk-Servers Both kamailio and Asterisk serevrs are on public IPs
*The problem:* Kamailio and Asterisk Servers need to be on Public IPs in order to fully handle NAT/media related issues. Whereas what I require is to have two interfaces at kamailio server, one is Public other is Private and All the Asterisk Servers should be on LAN/Private IPs.
I've tried making a scenario as per my requirement (attached image) but there are some serious NAT and media issues.
Can anyone help me how to handle NAT'd Asterisk servers behind Kamailio?
Thanks and Best Regards. Sammy
If you want to have your Asterisks on only private IPs, you will need to use some sort of RTPProxy, the standard config examples typically work for that setup.
On the other hand, some people are starting to come back from that topo, and just use Asterisk (or freeswitch) as the RTPProxy. And perhaps you can just have your asterisk on a public IP. As the extra security you might think you have because it has a private IP, is much less then what the diagram says.
Anyhow all is possible, the beauty of flexibility :)
2011/11/4 Sammy Govind govoiper@gmail.com
Hey Davy,
Thanks for looking into it, I've already setup RTPproxy as Standard procedure as published in this Kamailio KB/Wikihttp://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb . RTPproxy is currently working fine for any NAT'd cleints. i.e
Client(10.2.3.45)->VMAsterisk(NAT'd)<--->Windows7Host(172.16.30.30)<-->NAT'd<---->(internet)<--->Kamailio<-->Asterisk
This works fine. the only thing now I'm wishing to establish is put Asterisks/Freeswitches in Private/LAN block so I've no limitation on buying Public IPs for Media-Services.
I was also hoping in the beginning that stock/standard configurations for this setup. I'd to start RTPproxy in Bridge mode and also force_send_socket before relaying calls to private-ip Servers etc. but all in vain.
I'm still working to make it work like I pictured it. Any help in it would be much appreciated. I'm already very thankful to Alex for helping and pointing to some direction last-night.
Thanks and Best Regards, Sammy
On Fri, Nov 4, 2011 at 12:03 PM, davy van de moere < davy.van.de.moere@gmail.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
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:
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:
Seems like the NAT traversal is just broken.
just some basic rules:
- Call fix_nated_contact only for request from the clients (although it shouldn't hurt if you call it for all requests) - Whenever a message contains a session description call force_rtp_proxy(). Make sure to provide proper flags regarding the direction of the message. E.g. start rtpproxy listening to internal and external IP and provide the flags "ie" for requests from internal->external and "ei" for requests from external to internal.
regards klaus
On 04.11.2011 08:51, Sammy Govind wrote:
-
Alex Balashov -
davy van de moere -
Klaus Darilion -
Sammy Govind