[SR-Users] Problem with MSILO module forwarding messages

[Richard Brady]

Hi Owen

The module overview describes this behaviour:
> "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 REGISTER request contact header looks OK:
>  Contact: <sip:hxqecvtn at 192.168.2.236:57532
> ;transport=tls>;expires=3600;received="sip:192.168.2.236:53628
> ;transport=TLS";+sip.instance="<urn:uuid:1ee63413-3569-46dc-a9ee-34c6e4e1403c>"
>
> However the 'outbound_proxy' parameter seems to contradict this:
> "The SIP address used as next hop when sending the message. Very useful
> when using Kamailio with a domain name not in DNS, or when using a separate
> Kamailio instance for msilo processing. If not set, the message will be
> sent to the address in destination URI."
>
> So, when 'outbound_proxy' is not set, the message is sent to the address
> in the destination URI, rather than the UA contact address?
>
>
Yes. In both cases the R-URI of the new message request will be set to the
stored Contact URI. If outbound_proxy is not set, then it will be sent to
that new R-URI directly. If outbound_proxy is set it will be sent to the
outbound_proxy URI for forwarding to the R-URI.

Can the module be configured to forward stored messages directly to the UA
> contact address?
>

Yes, just don't set outbound_proxy. But if the clients are behind NAT, or
if there is another (intermediate) proxy between the msilo server and the
clients, then the requests will fail and you will have some extra work.

The received="sip:192.168.2.236:53628;transport=TLS" parameter in your
Contact header makes it appear there may be both NAT and an intermediate
proxy involved. Can you tell us more about your topology and perhaps share
the rest of the SIP REGISTER request.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130110/42c68eea/attachment.htm>