4 Jan
2013
4 Jan
'13
3:14 p.m.
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