Hi Giovanni, are you using sip instances and the client reconnecting is the same? There is currently a limitation in the module which prevent it from working with sip.instance, I had in mind to fix it since a while but I still haven't found the time to work on it. If it's the case, try not using sip.instance.

Regards,

Federico

On Wed, Jul 6, 2016 at 1:45 PM, gmele giovanni.mele@nagra.com wrote:

Hello Federico,

thanks for your answer. We applied the parameter and set it to 1. we also change some of our config:

Transaction store:

route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); }

    if (!t_relay(PROXY_IP, PROXY_PORT)) {
            sl_reply_error();
    }
    if (is_method("INVITE")) {
            *ts_store("$tu");*
            $sht(vtp=>stored::$tu) = 1;
            route(SENDPUSH);
    }
    exit;

}

route[INVRESUME] { statsd_gauge("SIPRegistrar.InviteResumed", "+1"); lookup("location"); t_relay(PROXY_IP, PROXY_PORT); *ts_store("$tu");* $sht(vtp=>stored::$tu) = 1; }

Transaction append: =============¨

route[PUSHJOIN] { $var(hjoin) = 0; lock("$tu"); $var(hjoin) = $sht(vtp=>join::$tu); $var(hstored) = $sht(vtp=>stored::$tu); $sht(vtp=>join::$tu) = $null; unlock("$tu");

    if ($var(hjoin)==0) {
            if ($var(hstored)) {
                    xlog("L_ERROR", "ts_append(location, $tu)");
                    *ts_append("location", "$tu");*
            }
            return;
    }

    $var(id_index) = $(var(hjoin){s.select,0,:}{s.int});
    $var(id_label) = $(var(hjoin){s.select,1,:}{s.int});
    t_continue("$var(id_index)", "$var(id_label)", "INVRESUME");

}

Unfortunately, it seems we still have a problem because when ts_append is called, we get an error:

ERROR: <script>: ts_append(location, sip:giovanni.mele@mydomain.com) ERROR: tm [t_append_branches.c:168]: t_append_branches(): ERROR: t_append_branch: failure to add branches (-1)

In the tsilo table, we have:

Dump ts.dump : Size: 2048 R-URIs: { R-URI: sip:giovanni.mele@mydomain.com Hash: -1300472314 Transactions: { Transaction: { Tindex: 29399 Tlabel: 1320156092 } } } Stats: { RURIs: 1 Max-Slots: 1 Transactions: 1 }

and in the location table, we have:

| 2722 | uloc-577cd29e-1102-c | giovanni.mele | NULL | sip:giovanni.mele@123.123.123.123:58313 ;app-id=289988461719;pn-type=google;pn-tok=APA91bEeHLdOx4LnaRZW-V_TUFN0rdI5e-9hVNN-7zKqO4vGelfg6Pc-Jj6W2l75mE7BZ1L6d2J6ydYpBuh8-Fk5;transport=tls | NULL | NULL | 2016-07-06 14:23:31 | -1.00 | CKHD~MMv8~ | 21 | 2016-07-06 13:23:31 | 0 | 0 | LinphoneAndroid/2.5.1-2662-g758a89c (belle-sip/1.4.2) | udp:213.244.194.153:4060 | NULL | urn:uuid:d0df1f0d-57bf-46dc-bf9b-75f2a5fe68fe | 0 | 0 | -1 | 0 | 4 |

Can you help me to understand why the ts_append didn't create the new branch for the current transaction? Is it linked to the username in the location table not having the domain set?

Thx

Giovanni

-- View this message in context: http://sip-router.1086192.n5.nabble.com/tsilo-ts-append-problem-tp150184p150... Sent from the Users mailing list archive at Nabble.com.

---

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

Hi Giovanni, when I suggested to disable sip.instance, really I meant in the client, since I know that linphone has an option for this. Anyway the problem is not due to your patch. If your registrar is behind a proxy, you have to enable the support for the Path header in the registrar module ( http://www.kamailio.org/docs/modules/devel/modules/registrar.html#registrar....) otherwise Kamailio will try to send the INVITE to the contact address, regardless of tsilo. In fact I guess that with your current configuration even a "direct" INVITE is not working. Hope this helps.

Regards,

Federico

On Wed, Jul 6, 2016 at 4:21 PM, gmele giovanni.mele@nagra.com wrote:

Hello Federico,

yes, we use the sip.instance as it is sent by our softphone. To validate it is the sip.instance that is causing the error, I patched the tm module to ignore the sip.instance in the contact info when it is written in the location table.

In our system, we have a kamailio proxy and a kamailio registrar. It is the registrar that is doing the push notif and the tsilo store and append.

So, after our dirty patch in the tm module, we found that the tm module is not sending the branched request to the SIP Proxy but tries to do it directly (ts_append calls tm::t_append_branches which calls t_send_branch), thus trying to open a TLS connection directly to the softphone... Of course, this is not working :-/

Do you have an idea on how to relay the branched request to the proxy instead of trying to send it directly?

To manage the push notifs, our idea was to do:

1. send the INVITE to the callee
2. store the transaction in tsilo
3. do a push notif to the callee (in case the location info is wrong)
4. wait the callee REGISTER and append the transaction in tsilo (which will

forward the previously received INVITE to the callee)

What do you think about this solution, taking in account we are using a SIP Proxy behind the SIP Registrar?

Thx

Giovanni

-- View this message in context: http://sip-router.1086192.n5.nabble.com/tsilo-ts-append-problem-tp150184p150... Sent from the Users mailing list archive at Nabble.com.

---

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

Hi Giovanni, glad that I could help you :) About your questions:

sip.instance: I've pushed in a branch ( https://github.com/kamailio/kamailio/tree/grumvalski/ts_append-instance) a change in tm t_append_branches function. Can you give it a try and let me know how it works for you? The change is really trivial, maybe too much. Basically I just add a comparison between the current checked branch uri (already added) and the current uri to add. If after testing everything looks fine we can merge/backport it.

DB backend for tsilo: it doesn't have too much sense to store the tsilo data on db for several reasons: 1) it cannot be useful for restarting kamailio, because anyway after a restart all transactions are gone 2) it cannot be useful for replication scenarios since tm transaction are not replicable and only the proxy holding the transaction can add branches on it

For replication scenarios I'd suggest another approach. Given that, as said, the transaction is on a specific server and that the ts_append call is triggered by a REGISTER, let the REGISTER itself reach the proxy where the transaction is stored. If you have only two proxies you can simply t_replicate all the REGISTERS between servers. If you have multiple and/or you want a more sophisticated logic, you could rely on htable and dmq to have a distributed table of ongoing transactions and selectively replicate the REGISTER. Kamailio is flexible :)

Regards,

Federico

On Thu, Jul 7, 2016 at 11:07 AM, gmele giovanni.mele@nagra.com wrote:

Hello Federico,

the dirty patch on the TM module was just for test as we are implementing our own softphone application (like yours @ Orange) based on Linphone, but in another team, so asking for changes takes time.

Like you suggested, the Path module resolved our INVITE problem. Thx :-)

Now, about the sip.instance support in the TSILO module, we cannot avoid using it as we may have several UE for the same user (mobile and desktop app). When do you plan to update TSILO to support it?

Do you think we can do it for you?

About TSILO, is there a possibilty to store the transaction in the DB? We have 2 Kamailio registrars behind the proxy, and we need to synchronize them...

Thx

Regards

Giovanni

-- View this message in context: http://sip-router.1086192.n5.nabble.com/tsilo-ts-append-problem-tp150184p150... Sent from the Users mailing list archive at Nabble.com.

---

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

Hi Giovanni, thanks for testing and reporting. I will prepare a PR for this. About your solution I do agree with it, simple and effective :)

Regards,

Federico

On Fri, Jul 8, 2016 at 8:20 AM, gmele giovanni.mele@nagra.com wrote:

Hello Federico,

your patch seems to work for us. Thx.

For the 2 registrars needing the transaction information, we have found another way to solve it: in our previous config, the dispatcher ds_select_dst was using algo 1 (from URI) for INVITE and REGISTER, meaning that the INVITE may be done on first registrar and the callee REGISTER (after push notif) on the second one, causing the INVITE to be never sent. Now, we will use algo 2 instead, meaning that both INVITE and callee REGISTER will be done on the same registrar.

What do you think about this solution?

Thx again

Giovanni

-- View this message in context: http://sip-router.1086192.n5.nabble.com/tsilo-ts-append-problem-tp150184p150... Sent from the Users mailing list archive at Nabble.com.

---

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