On 18.04.21 17:33, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

...

In case of topology:

A - P1 - P2 - P1 - B

is the idea to use in P1 context "in" when initial request comes to P1 from A or B and context "out" when initial request comes to P1 from P2?

Does context need to be set in replies too? If so, is reply context the same as the corresponding request context?

And finally, does context need to be set for in-dialog requests/replies the same way as for initial requests?

Normally the context has to be set for the initial request. Set one value for the request coming from A to P1 and another one for P2 to P1, using one of the event routes.

I did more testing on this. When P1 receives INVITE from A, it calls tps_set_context("leg1") in on_topos:msg-sending and when it receives the INVITE from P2, it calls tps_set_context("leg2").

INVITE and 200 OK seems to work as they should, but when P1 receives ACK from A, it first forwards the ACK back to itself and adds Route header to it. After receiving the ACK from itself, it removes the Route header and adds second Via header with different branch value and then forwards the ACK to P2.

I have pcap of this if it would help to figure out what is going on.

Can you reproduce with debug=3 in kamailio.cfg, send me all the logs messages (from the initial invite to ack) along with the pcap and the records in the database from the topos_d and topos_t table?

Cheers, Daniel

On 19.04.21 09:03, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

Can you reproduce with debug=3 in kamailio.cfg, send me all the logs messages (from the initial invite to ack) along with the pcap and the records in the database from the topos_d and topos_t table?

Syslog and pcap are in files

https://box.tutpro.com/tmp/syslog https://box.tutpro.com/tmp/tshark.pcap

About getting redis records, I guess they already disappeared, since KEYS * shows empty list.

It seems to be the problem of matching the R-URI of ACK to be myself (address of the server), because it is the Contact of the callee, which was replaced by 2nd topos processing.

The solution should be to do only loose routing on the edge proxy doing topos using loose_route_mode("1"):

* https://www.kamailio.org/docs/modules/devel/modules/rr.html#rr.f.loose_route...

Cheers, Daniel

On 19.04.21 16:52, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

It seems to be the problem of matching the R-URI of ACK to be myself (address of the server), because it is the Contact of the callee, which was replaced by 2nd topos processing.

The solution should be to do only loose routing on the edge proxy doing topos using loose_route_mode("1"):

Thanks, I made the change and after that ACK and other in-dialog requests were routed correctly.

OK, good to know it worked.

Cheers, Daniel

On 20.04.21 09:03, Juha Heinanen wrote:

Sorry, but it turned out that in calls where B replies first with "183 Session Progress" and which A acknowledges with PRACK request, P1 is not able to forward the PRACK, but responds with "404 Not found".

I cannot reproduce this in my test environment, because I don't have a SIP UA that uses Session Progress. Here is censored debug from production environment on what happens when P1 receives the PRACK:

https://box.tutpro.com/tmp/prack.debug

The 404 is not sent from the C code of the topos module, can you identify what are the cases in your config when a 404 is replied? PRACK should have To-tag, so it should via requests within dialog branch.

Cheers, Daniel

On 20.04.21 11:23, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

The 404 is not sent from the C code of the topos module, can you identify what are the cases in your config when a 404 is replied? PRACK should have To-tag, so it should via requests within dialog branch.

Yes, 404 is sent from the script:

if (!loose_route_mode("1")) { if (is_method("ACK")) { if (t_check_trans()) { t_relay(); } else { xdbg("Discarding unmatched $rm <$ru> by <$fu>\n"); }; } else { xnotice("Discarding in-dialog $rm <$ru> without Route header\n"); send_reply("404", "Not found"); }; exit; };

This has worked OK also with 183/PRACK when topos is not in use. If I add PRACK to the if test:

    if (is_method("ACK") || is_method("PRACK")) {

then "Discarding unmatched PRACK ..." is written to log.

Can you try with latest master branch? I pushed a commit to topos module.

Cheers, Daniel

On 20.04.21 13:09, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

Can you try with latest master branch? I pushed a commit to topos module.

Tried with latest master and the following in-dialog code:

if (!loose_route_mode("1")) {
    if (is_method("ACK")) {
        if (t_check_trans()) {
            t_relay();
        } else {
            xinfo("Discarding unmatched $rm <$ru> by <$fu>\n");
        };
    } else {
        xnotice("Discarding in-dialog $rm <$ru> without Route header\n");
        send_reply("404", "Not found");
    };
    exit;
};

Got this to syslog:

Apr 20 10:53:11 edge /usr/bin/edge-proxy[15624]: NOTICE: {1 2 PRACK HWoFVYqzNT_-3egFTTvu0Q} <script>: Discarding in-dialog PRACK sip:atpsh-607eb272-3d06-1-leg1@46.182.160.60 without Route header

when P1 received PRACK from A (in toplogy A - P1 - P2 - P1 - B).

topos event route in P1 looks like this:

event_route[topos:msg-sending] {

if ($mt == 1) { if (is_method("INVITE") && !has_totag()) { if ($sndto(ip) == "P2") { xinfo("Setting topos leg to <leg1> on <$rm> to $sndto(ip)"); tps_set_context("leg1"); } else { xinfo("Setting topos leg to <leg2> on <$rm> to $sndto(ip)"); tps_set_context("leg2"); }; }; }

Hmm ... the issue seems to be related to missing record-route list for callee side in the transaction record.

I do not have a test bedwhere I can reproduce during the next days, would it be possible for you to use topos with db backend (mysql) instead of redis and send again the logs with debug=3? That should provide details of the db queries and indicate if the record-route values are stored/retrieved to/from database.

Cheers, Daniel

Juha,

On 22.04.21 16:06, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

Hmm ... the issue seems to be related to missing record-route list for callee side in the transaction record.

I do not have a test bedwhere I can reproduce during the next days, would it be possible for you to use topos with db backend (mysql) instead of redis and send again the logs with debug=3? That should provide details of the db queries and indicate if the record-route values are stored/retrieved to/from database.

Daniel,

We did more tests, this time using topos mysql instead of redis. With exactly same config, PRACK to 183 is now forwarded correctly: A->P1->P2->P1-B. We then switched back to redis and P1 responded with 404 as before when it received the PRACK. So looks like there is some issue with redis.

OK, I will check topos_redis and see if something is missing there on this case.

But, there is another problem that showed up with mysql topos.

When A receives 200 OK to PRACK, it sends another PRACK with the same "CSeq: 2 PRACK" header, to which P1 responds with 200 OK without forwarding the PRACK. So looks like it thinks there is something with the 200 OK that A does not like . The same happens three more times. At the third time P1 forwards the PRACK to P2, which forwards is back to P1 starting a loop that finally gets terminated with "483 Too many hops".

Syslog of P1 shows these kind of error messages during PRACK processing:

Apr 22 12:49:49 edge /usr/bin/edge-proxy[402]: ERROR: {2 2 PRACK FQzhCOkpzqUJGaXntnCyKw} topos [topos_mod.c:416]: tps_prepare_msg(): mandatory headers missing - via1: (nil) callid: 0x7f0b1b67c5b0

Can you send me a pcap and debug logs for such case taken on P1? I will try to check what is missing/wrong there.

Lesson: do not try to use any dialog based stuff in a SIP proxy.

This has nothing to do with the dialog, the fact here is that topos was not designed for spirals, as I said in one of the previous emails. I am trying to fix the missing parts to make it work, if you can provide pcap/logs.

Cheers, Daniel

On 22.04.21 18:14, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

This has nothing to do with the dialog, the fact here is that topos was not designed for spirals, as I said in one of the previous emails. I am trying to fix the missing parts to make it work, if you can provide pcap/logs.

Can I email them to you privately?

Yes.

Cheers, Daniel

Daniel-Constantin Mierla writes:

update: last evening I pushed a commit to topos_redis, I hope now it behaves like when using db backend related to provisional replies.

We tried this morning with latest master and unfortunately P1 still rejects PRACK with 404 when topos is using redis.

-- Juha

On 23.04.21 08:31, Daniel-Constantin Mierla wrote:

On 23.04.21 08:17, Juha Heinanen wrote:

...

Daniel-Constantin Mierla writes:

...

update: last evening I pushed a commit to topos_redis, I hope now it behaves like when using db backend related to provisional replies.

We tried this morning with latest master and unfortunately P1 still rejects PRACK with 404 when topos is using redis.

Hmm, then I will dig in further on this issue as well.

Can you try now with latest git master branch and database storage? The logs suggested the wrong profile was used on PRACK reply on P1 when returning to A-side.

I haven't looked yet into topos redis.

Cheers, Daniel

On 23.04.21 16:18, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

Can you try now with latest git master branch and database storage? The logs suggested the wrong profile was used on PRACK reply on P1 when returning to A-side.

Thanks, will test ASAP.

For the records: this should be fixed in master branch, working for db backends (e.g., mysql), just in case anyone else wants to test now or needs the same scenario in the future. topos_redis still needs to be reviewed and likely some changes to make it work for this scenario -- planning to look at it during the next days.

Cheers, Daniel