On 13/03/15 12:55, mayamatakeshi wrote:


On Fri, Mar 13, 2015 at 8:25 PM, Daniel-Constantin Mierla <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.

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_contact

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
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com