Hi Manuel!

With a trace (of SUBSCRIBE and NOTIFY) it is really difficult to understand the problem.

Thus I suggest: Take a look at the SUBSCRIBE request on both Kamailio proxies. Verify that record-route and contact headers are correct.

Then take a look at the NOTIFY also on both servers and verify that the message is correct. If it is correct but routed wrong, check the config on the server which routed wrong.

regards Klaus

On 29.02.2012 16:11, Manuel Perez wrote:

Thanks for your reply.

This is part of my config file:

request_route { # per request initial checks route(REQINIT);

# NAT detection route(NATDETECT);

# handle requests within SIP dialogs route(WITHINDLG);

### only initial requests (no To tag)

# CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; }

t_check_trans();

# authentication route(AUTH);

# record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE|NOTIFY")) record_route();

# account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting }

# dispatch requests to foreign domains route(SIPOUT);

### requests for my local domains

# handle presence related requests route(PRESENCE);

# handle registrations route(REGISTRAR);

if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; }

# dispatch destinations to PSTN route(PSTN);

# user location service route(LOCATION);

route(RELAY); }

route[RELAY] {

# enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|SUBSCRIBE|NOTIFY")) { t_on_branch("MANAGE_BRANCH"); t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { t_on_failure("MANAGE_FAILURE"); }

if (!t_relay()) { sl_reply_error(); } exit; }

route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } if ( is_method("ACK") ) { # ACK is forwarded statelessy route(NATMANAGE); } route(RELAY); } else { if ((is_method("SUBSCRIBE| NOTIFY")) && uri == myself) { route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } }

I'm using loose_route function in WITHINDLG function, presence in the same server works buts with user from another domain I receive duplicate notifys. The request line for this notifys is userB@ip_of_domainB not userB@ip_of_userB like the ones I receive when the two users are in the same domain.

Thanks. Regards.

On Tue, Feb 28, 2012 at 5:22 PM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:

NOTIFYs are in-dialog and should be loose-routed. Verify that
loose-routing works fine.

If the clients are behind NAT also verify that Contact headers are
rewritten during subscription.

regards
Klaus


On 28.02.2012 16:08, Manuel Perez wrote:

    Hello,

    I've used kamailio 3.2.2, i have rls, simple presence and xcap
    support
    working. I've replicated this server into another one in a different
    domain, but presence between domains is not working. I'm using for
    presence presence.so, presence_xml.so and presence_mwi.so. In
    route[WITHINDLG] i have the following lines:

    ...
    if (is_method("SUBSCRIBE|NOTIFY") && uri==myself)
          route(PRESENCE);
    ...

    When NOTIFY from user B at domain B arrives to the server at
    domain A,
    the message is not forwarded to the user A, How can i achieve this?

    Thank you.





    _________________________________________________
    SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
    mailing list
    sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
    http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>