Before we start, know this: I am a total Kamailio/SER noob. There. I admitted it. This is my first attempt. I seek wisdom from you experienced, all-knowing wise ones! I've searched many hours about this problem, read thru the docs about the modules, etc. etc. Here's the setup. Centos 5.x Kamailio 3.3.3 Asterisk 1.6.x We have one Asterisk based PBX. We have two trunk sip accounts. Both to the same voip provider machine. Their system is such that the two accounts are billed separately, but they need to have them at two different ip/port combinations. Asterisk can only listen for SIP on one port, and it for sure can only send responses from one port. The voip provider only listens on one port: 5060. Pretty normal, actually, right? So, I create the first sip account, going directly to the voip provider, just like normal, from/to Asterisk. But, on Asterisk, the second sip account is pointed to port 25061 on localhost. On the same system as Asterisk, I have installed kamailio. It will listen on localhost:25061. It also listens on the network address, port 45061. And for that second account, the voip provider is set up to talk to our machine at port 45061. And I programmed kamailio to shuttle incoming packets from Asterisk on 25061 to the voip provider via the 45061 port. And, the incoming packets from the Voip provider on port 45061 are shuttled to Asterisk via the 25061 port. At least, that's the intention! But it's not working that way. In the following config stuff, 100.100.100.100 is the IP of my asterisk box. 200.200.200.200 is the IP of the voip provider. I'm using a stock kamailio.cfg file, with some changes. disable_tcp = yes ## I don't think I need tcp... listen=udp:127.0.0.1:25061 # primary Asterisk port listen=udp:100.100.100.100:45061 # My boxes external IP address on the internet. port=25060 ## do I really need this? request_route { # per request initial checks route(REQINIT); if (src_ip=="127.0.0.1") { # outgoing SIP from Asterisk if(dst_port==25061) { #realm 3 if( !t_relay("200.200.200.200",5060) ) # The IP of the voip provider { sl_reply_error(); break; } force_send_socket(udp:100.100.100.100:45061); #This machine's IP } } else { # incoming SIP from voip provider if(dst_port==45061) { # voip provider trunk if(!t_relay("127.0.0.1",5060) ) # The realm primary IP { sl_reply_error(); break; } force_send_socket(udp:127.0.0.1:25061); #This machine's IP } } } The only other route block I kept from the original was the route[REQINIT] stuff. Nothing fancy. Could easily be, that I took out too much. When I try to make an outgoing call from the Asterisk server, out to the voip provider, I see this: 0(3150) ERROR: <core> [udp_server.c:598]: ERROR: udp_send: sendto(sock,0xb5d2a870,1007,0,200.200.200.200:5060,16): Invalid argument(22) 0(3150) : <core> [udp_server.c:603]: CRITICAL: invalid sendtoparameters one possible reason is the server is bound to localhost and attempts to send to the net 0(3150) ERROR: tm [../../forward.h:150]: msg_send: ERROR: udp_send failed 0(3150) DEBUG: tm [t_fwd.c:1365]: t_send_branch: send to 200.200.200.200:5060 (1) failed 0(3150) ERROR: tm [t_fwd.c:1383]: ERROR: t_send_branch: sending request on branch 0 failed 0(3150) DEBUG: tm [t_funcs.c:361]: ERROR:tm:t_relay_to: t_forward_nonack returned error 0(3150) DEBUG: tm [t_funcs.c:369]: -477 error reply generation delayed 0(3150) DEBUG: <core> [msg_translator.c:206]: check_via_address(127.0.0.1, 100.100.100.100, 0) 0(3150) ERROR: sl [sl_funcs.c:371]: ERROR: sl_reply_error used: Unfortunately error on sending to next hop occurred (477/SL) 0(3150) DEBUG: tm [t_lookup.c:1532]: t_unref: delayed error reply generation(-477) 0(3150) DEBUG: <core> [msg_translator.c:206]: check_via_address(127.0.0.1, 100.100.100.100, 0) 0(3150) DEBUG: tm [t_reply.c:1543]: DEBUG: cleanup_uac_timers: RETR/FR timers reset 0(3150) DEBUG: tm [t_reply.c:703]: DEBUG: reply sent out. buf=0xb7b96d78: SIP/2.0 477 Unfortun..., shmem=0xb5d2a648: SIP/2.0 477 Unfortun 0(3150) DEBUG: tm [t_reply.c:713]: DEBUG: _reply_light: finished So, is the above a reasonable approach? Is there a better way to handle things? What's the deal with 127.0.0.1 traffic not being OK? why is sendto having problems? If I were to want to do this for several trunks, why can't I use switch (dst_port) {} ? I'm probably pretty off-track on all this; any help you folks can provide will surely be appreciated. murf

Hi Richard! I wonder why I have to set mhomed. In the scenario I described both sockets are in the same network segment and I would guess that automatic socket selection will not work and always chooses the same socket. I think I have to set the proper outgoing socket manually with force_send_socket(), regardless if mhomed is on or off. regards Klaus On 07.01.2013 02:20, Richard Brady wrote:

Hi Klaus Thanks for posting the working solution. You are right that mhomed=1 won't help if the sockets both have same IP address. Though I think if you used it with two different IPs and the correct routing tables on the OS then it would work. In any case your solution is a good one. Richard On 7 January 2013 15:45, Klaus Darilion &lt;klaus.mailinglists(a)pernau.at&gt;wrote;wrote:

+1 Klaus - I used your tips and Kamailio is working great behind NAT. I'll try to test different types of NATs and see if SIP and RTP works perfectly for all scenarios. Thanks and cheers Sammy On Fri, Jan 11, 2013 at 1:42 PM, Klaus Darilion < klaus.mailinglists(a)pernau.at&gt; wrote: