[SR-Users] Kamailio 4 + Asterisk 11: Local Extensions busy / congested

[Michael Leuker]

Hi everybody,

I've been following Daniel's excellent tutorial at

http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb

and managed to get registrations and outbound dialing to run. The problem
is that whenever I try to call a local extension (directly or via trunk),
CLI reports

  == Everyone is busy/congested at this time (1:0/0/1)

and plays the according VM message. "sip show peers" shows the extension as
online / the registration correctly passed along by Kamailio:

1001/1001       198.23.139.21            D            A  5060     OK (1 ms)

198.23.139.21 is the server IP and used for both Kamailio (5060) and
Asterisk (5080). Asterisk only allows for UDP, Kamailio for for UDP and TCP
connections.

The server is connected directly to the internet and the only NAT is on the
client side. I have disabled NAT support both in Asterisk and Kamailio
because the clients support ICE and can connect using TURN to the Asterisk
echo-test just fine. Enabling NAT support (with and without rtpproxy) in
Kamailio doesn't solve the above problem (and doesn't seem to be able to
traverse all NAT situations in any case).

To be clear: The Asterisk configuration itself is working flawlessly. I
don't encounter the problem at all if I connect directly to the Asterisk
server, either in its original, standalone configuration or on port 5080
(after disabling the ACL allowing only the Kamailio IP and re-enabling the
password).

Please let me know if you need specific logs (I wouldn't want to needlessly
clutter the original description with useless information) to take a closer
look at the problem. If this is a known issue, a friendly pointer would be
much appreciated as well! I've searched for hours and hours and never
seemed to find anything helpful. Have a great day and with

Best Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130528/5ad934e2/attachment.html>