Hello,
I'm new with Kamailio. I've just setup on Debian Squeeze using mostly the
example configuration.
I've been able to route inbound / outbound call on local networks W/O NAT
and over mobile 3G+NAT ...
Unfortunateley I've tried over 3 wifi / local + NAT and Kamailio drop call
and return me this message "SL local ACK found -> dropping it! error ..."
My Kamailio server has public fixed IP and listen on 5060:udp
It's look and issue with NAT setup ... How can we solve it ?
Best regards
Hi,
I would like to force kamailio to send another code as Request timeout when
fr invite timeout is hit. Is there some nice way how to achieve it, or I
have to edit the code ? :(
Thank you!
Hi Andres,
no problem ;-)
See my answers inline.
2011/1/17 "Andrés S. García Ruiz" <asgarcia(a)um.es>:
>
> Hi Carsten,
>
> Thanks a lot for all the information and the access to your developments.
>
> I haven't been able to answer last week cause I got the flu. I'm fine right
> now.
>
> In a previous mail you wrote:
>
> "The goal of the project is to create a stable, fast, open-source,
> feature-rich IMS implementation based on Kamailio and the
> OpenIMS-Core."
>
>
>
> I suppose that you've chosen Kamailio as a Sip Server for XCAP, Presence,
> RLS, presence-rules, etc. and OpenIMSCore as the heart of the IMS. So your
> work aims -I think- to make an easy integration of Kamailio with the
> OpenIMSCore. Is that true?
No, not exactly. I've replaced the SER-Core from the OpenIMS-Core with
the Kamailio-Core and we are in the progress of creating a new
OpenIMS-Core (based on the "old" one). We do not continue to use the
existing OpenIMS-Core as such.
The OpenIMS-Core implementation has some limitations and has some
aspects, which i personally do not like and which i am trying to
change (don't misunderstand me here: For a research project, there was
really great work done). However, there are a few parts, which i want
to change, in order to make the OpenIMS-Core more flexible (and in
some issues more stable):
- The current OpenIMS-Core borrowed some code from other modules, e.g.
there was some code taken from the dialog module, from the Nathelper
module and maybe others, in order to implement the CSCF-Components. As
the intented show-case and prototype, that is totally acceptable.
However, this results in improvements and fixes done to those modules
not necessarily leading to fixes in the OpenIMS-Modules
- The used Core is SER 2.1-dev1. I think, that was the version of SER
when the OpenIMS-Core was released. I wanted to replace the core with
a more current core (in my case Kamailio 3.1/3.2), in order to bring
the OpenIMS-Core forward.
- many aspects of the implementation can be replaced in the current
version with Core-Functions (e.g. header manipulation), that will make
the code easier to maintain
- i want to add the missing documentation for the modules
- i wanted to include the modules in the Kamailio/sip-router.org
project, in order to keep them maintained
My work has nothing to do with integrating a Kamailio-Server (e.g.
Presence) into a system consisting of the OpenIMS-Core, but it has
something to do with improving the OpenIMS-Core. First i want to
improve the OpenIMS-Core, and then we will see, what's next.
All i did so far, in order to make a Kamailio-based-Presence-Server
work with the IMS-Core, was to modify the Trigger-Point on my HSS a
little bit... (but more a dirty hack and nothing, were i am sure if it
is the currect or even safe to do; i made it work rather than thinking
of, if it was correct...).
You need to reconfigure your trigger-points (check the Session Case)
in order to make this work.
I have attached my trigger-point for presence, may this will help you...
> I'm trying to design and implement a similar architecture, but I've had some
> issues, mainly with how the OpenIMSCore communicates with the external SIP
> presence servers. For example, when I send a RLS SUBSCRIBE to the IMS core,
> it does the following:
> - If the subscribed URI is an user of the domain, it translates its SIP URI
> to the sip contact uri.
> - If the subscribed URI is not an user, it answers with "HSS User unknown".
>
> Could you tell me what kind of problems have you solved till now?
>
> Kind regards,
> Andrés.
>
> PS: I'm using Ubuntu. Is Ubuntu compatible with your distribution?
Since Ubuntu is based on Debian, i think that should work out of the
box (but no warranty for that).
Kind regards,
Carsten
P.S: Please always use the reply to all button, in order to keep the
lists in CC.
Hi folks,
I have a problem with a scenario where an incoming INVITE is forwarded to a redirect server
which responds with 302 and a new target in the Contact header (B). The call is being forwarded
to the new contact correctly. All responses from B that are either provisional or a 200 OK
are being routed back to the caller. If B responds with any code >=400 the 302 from the
redirect server is being returned to the caller instead of the received code.
A B C
|--INVITE->| |
| |--INVITE->|
| |<---302---| D
| |----INVITE--->|
| |<-----404-----|
|<---302---|
Is this intended? And if so, is there any way to change this behaviour so the latest received
response is returned?
I tested using the version from repository from 13.01.2011
My reduced config looks like this:
route{
if (@to.tag != "") {
if (loose_route()) {
record_route();
t_relay();
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
t_relay();
exit;
} else {
# ACK without matching transaction ... ignore and discard.\n");
exit;
}
}
record_route();
}
exit;
} else {
record_route();
}
t_on_failure("REDIRECT_REPLY");
if (!t_relay_to_udp("192.168.0.10","5060")) {
sl_reply_error();
};
exit;
}
failure_route[REDIRECT_REPLY] {
if (t_check_status("3[0-9][0-9]")) {
get_redirects("*:1");
t_relay();
exit;
}
}
Regards,
Stefan
Hi,
I have a very short question: Kamailio does listen to many IP Addresses and does forward messages to the peer with t_relay. Which IP address will kamailio use for the outgoing traffic as source-ip, if there are many IP addresses on the interface? Is it possible to specify this somehow?
Thanks in advance.
Best regards,
Bernhard
Hi!
I would like to use probing implementation in dispatcher module to keep
track of the state of the gateways, but I want to choosing a gateway
manually in the config.
For example I defined a dispatcher set with 6 entries. Then in .cfg I
want to retrieve a certain entry from the set (by index) and its state
(active, inactive, probing).
AFAIS there is currently now way to do this. Does anybody knows a
workaround or maybe another way for manual dispatching but automatic
probing?
Thanks
Klaus
