On Fri, Mar 13, 2015 at 8:25 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
On 13/03/15 10:54, mayamatakeshi wrote:
Hello,
maybe this phrase in the msilo doc is misleading:
/Every time when a user registers with Kamailio, the module is
looking in database for offline messages intended for that user.
All of them will be sent to contact address provided in REGISTER
request./
http://kamailio.org/docs/modules/4.2.x/modules/msilo.html
The above seems to imply that msilo would send the call directly
to the contact address. But this doesn't seem to be the case
based on what is mentioned in several threads in the mailing list
and in what I saw in the msilo.c code.
If so, is there a reason to be a such? Would it be a problem to
allow msilo m_dump to get the values of contact, received and
path and use them when calling t_request?
IIRC, the MESSAGE requests are sent to the From address that sent
the message. That's typically the AoR, meaning that the request is
sent to the server of that user which should do lookup location to
resolve the destination.
There is an option to send some notification back to origin when
the destination is offline, controlled by:
-
http://kamailio.org/docs/modules/stable/modules/msilo.html#msilo.p.use_cont…
But that should not be related to relaying the instant messages
when the user becomes online.
If the destination user is on same kamailio, be sure you don't
authenticate requests coming from the same box (ie, skip
authentication if src_ip==myself).
Daniel,
thanks for the explanation. I am doing as you described.
Everything is running fine.
I was just intrigued about having to loop the request if my own server
is the registrar.
The loop is local so there is no much impact. When msilo was
developed
(iirc, like 2003) there was not much inter-module API and this was the
solution to go.
Now probably msilo can be bound to usrloc and use the internal exported
API, but it is more like some effort for no real big benefits. The
existing behaviour still needs to be kept because msilo can be on a
different instance that location server. Of course a patch will be
accepted, but at least for me there are other higher priority features
to work on for the moment.
A benefit of current behavior is more control of what to do with dumped
messages in request_route when receiving it via local loop.
Cheers,
Daniel
--
Daniel-Constantin Mierla