<!-- Kamailio Project uses GitHub Issues only for bugs in the code or feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement), you can delete the text of the template and only add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment). -->
### Description
<!-- Explain what you did, what you expected to happen, and what actually happened. --> Kamailio incorrectly routed RPACK packets with topos module enabled. In the same time there is no problem with topoh module enabled. It's seems like related to #1097,
### Troubleshooting
#### SIP Traffic
<!-- If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
RPACK SIP packets with Kamailio topos module: http://imgur.com/SScErQp RPACK SIP packets with Kamailio topoh module: http://imgur.com/45ch3HB
### Possible Solutions
<!-- If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix. -->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.1.0-dev4 (x86_64/linux) (git revision 7dbf3fe) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 00:24:21 Jun 26 2017 with gcc 4.8.5 ```
* **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `uname -a`) -->
``` Red Hat Enterprise Linux Server release 7.3 (Maipo) Linux 2.6.32-042stab113.21 #1 SMP Wed Mar 23 11:05:25 MSK 2016 x86_64 x86_64 x86_64 GNU/Linux ```
If you do not have parallel forking, then you can try with the patch from #1097. It's in my todo list to work on the fix for parallel forking, but lack of time lately postpone it.
Unfortunately, I can't use #1097 patch because of parallel forking and with incorrect behaviour with RPACK packets (404 Not here answer) we can't use topos module at all. So I will wait for your patch and till that will use topoh module instead. Thanks in advance!
After all, I assume you mean PRACK, not RPACK.
Yes, I mean PRACK, my bad.
Although with rather long delay, I started to work on it. First step was to add support for storing the record-route and contact values in the branch record (topos_t table). Can you test with latest master branch and see if those fields are set after 180/183? I didn't have time to do any tests yet by myself. If this part is ok, then I will continue to implement using them for routing PRACK and other requests during early dialog state.
Hi Daniel. I have just tested. Please look at screenshot from topos_t table. http://imgur.com/w4nnyQI
Now PRACK is sending to contact from 183 Progress, but it does not recovers as it must be. I think it is record route restore issue.
Hi, Daniel. Do you have any updates regarding this issue?
Hello,
is more useful to get the record from database as text instead of a screenshot. You can use:
``` select * from topos_t\G ```
That will make records with many columns to be printed in more compact form suitable for pasting here.
Can you also tell the IP addresses for each node in the path of the call?
Hi Daniel
This is the output from topos_t
*************************** 29. row *************************** id: 1145715 rectime: 2017-07-21 08:14:54 s_method: INVITE s_cseq: 9022 a_callid: uACs6xvwpwRYZyfNDsRi2Z.3Ge809DJK a_uuid: atpsh-5967680b-2b6d-5 b_uuid: btpsh-5967680b-2b6d-5 direction: 0 x_via: SIP/2.0/TLS 100.65.48.39:48702;received=37.73.197.220;rport=22343;branch=z9hG4bKPjMyQEnMkzRQYL5wQjgt-ih0wGZkrX6TvM;alias x_vbranch: z9hG4bKbab9.50ac03836b503a91b5269332e0da72fc.0 x_rr: y_rr: sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:10.56.42.37:5070;lr;ftag=PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK;did=243.ca42;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA s_rr: sip:10.56.42.37;r2=on;lr;ftag=PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK;did=243.f55;vsf=AAAAAAoLAQ4DAA4DCHlnag5heGJnG3Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAwEcGwMWGgMYAxkIAAM3MDt1c2VyPXBob25l;nat=yes,sip:1.2.3.4:5081;transport=tls;r2=on;lr;ftag=PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK;did=243.f55;vsf=AAAAAAoLAQ4DAA4DCHlnag5heGJnG3Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAwEcGwMWGgMYAxkIAAM3MDt1c2VyPXBob25l;nat=yes x_uri: a_contact: b_contact: sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXl* as_contact: bs_contact: x_tag: PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK a_tag: b_tag: 04002092200999 a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 30. row *************************** id: 1145716 rectime: 2017-07-21 08:14:59 s_method: PRACK s_cseq: 9023 a_callid: uACs6xvwpwRYZyfNDsRi2Z.3Ge809DJK a_uuid: atpsh-5967680b-2b6d-5 b_uuid: direction: 0 x_via: SIP/2.0/TLS 100.65.48.39:48702;received=37.73.197.220;rport=22343;branch=z9hG4bKPjn0XwMow5-ohClQyJ4wjKHN9WhsEmu6Fr;alias x_vbranch: z9hG4bKcab9.e4f6045b55f53485a72152348d7218cb.0 x_rr: y_rr: sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*,sip:10.56.42.37:5070;lr;ftag=PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK;did=243.ca42;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA s_rr: x_uri: a_contact: b_contact: sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXl* as_contact: bs_contact: x_tag: PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK a_tag: b_tag: 04002092200999 a_srcaddr: b_srcaddr: a_socket: b_socket:
Client generates PRACK PRACK sip:atpsh-5967680b-2b6d-5@1.2.3.4:5081;transport=tls SIP/2.0 Via: SIP/2.0/TLS 100.65.48.39:48702;rport;branch=z9hG4bKPjn0XwMow5-ohClQyJ4wjKHN9WhsEmu6Fr;alias Max-Forwards: 70 From: sip:380931701939@1.2.3.4;tag=PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK To: sip:0938221583@1.2.3.4;tag=04002092200999 Call-ID: uACs6xvwpwRYZyfNDsRi2Z.3Ge809DJK CSeq: 9023 PRACK RAck: 500 9022 INVITE Content-Length: 0
After kamailio with topos:
PRACK sip:10.56.42.37;r2=on;lr;ftag=PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK;did=243.f55;vsf=AAAAAAoLAQ4DAA4DCHlnag5heGJnG3Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAwEcGwMWGgMYAxkIAAM3MDt1c2VyPXBob25l;nat=yes SIP/2.0 Via: SIP/2.0/UDP 10.56.42.37;branch=z9hG4bKcab9.e4f6045b55f53485a72152348d7218cb.0;i=f465 Max-Forwards: 69 From: sip:380931701939@1.2.3.4;tag=PxSmzGfYu.lDW-wDENFhyPTkaze9ygCK To: sip:0938221583@1.2.3.4;tag=04002092200999 Call-ID: uACs6xvwpwRYZyfNDsRi2Z.3Ge809DJK CSeq: 9023 PRACK RAck: 500 9022 INVITE Content-Length: 0 Contact: sip:btpsh-5967680b-2b6d-5@10.56.42.37
ip 1.2.3.4 - external kamailio ip 10.56.42.37 - internal kamailio ip 10.56.42.37:5070 - kamailio2 ip
Daniel, do you have some updates regarding this issue?
Hope to get to it in the next few days ... with the summer holidays around, I didn't get to work that long in a raw at the desk to put a testing scenario in place.
Finally pushed a new patch related to this. Can you test with latest master branch?
If there is something not working properly, to get all needed data and have privacy, send me directly via email the pcap of such call along with the records from both topos database tables. Just make a comment here that you emailed those to me, in order to look for it in inbox. Would be also useful if you can run with debug=3 and email the logs printed by kamailio.
Hi, Daniel.
I just send you requested info with email. There no record about PRACK in topos_t table now...
Another related patch landed in master, give it another try and on issue, send a report as before.
All same exept in logs Aug 8 16:47:08 csbc-uat /usr/sbin/kamailio[21308]: DEBUG: db_mysql [km_res.c:168]: db_mysql_convert_rows(): no rows returned from the query Aug 8 16:47:08 csbc-uat /usr/sbin/kamailio[21308]: DEBUG: topos [tps_storage.c:898]: tps_db_load_branch(): no stored record for **INVITE < ~ >**
So I'm getting close and closer ... another patch pushed, try again ...
Hi Daniel.
Pcap, db content and log with level 3 you can find in attach.
PRACK is now generated but to the wrong uri... Details send to you via email.
Can you add following xlog at thet top of request_route, redo the last test and send again all the troubleshooting info?
``` xlog("received from $si: [[$mb]]\n"); ```
I want to see the requests as constructed by topos after doing the request received callback. The pcap doesn't capture that.
Send it via email
Test one more with latest branch.
Send result in email. Better but route headers are restored in wrong order. and uri for send prack seems got from record-route header...
The Contact field was not loaded for transaction record and R-URI was not changed, resulting in doing strict routing instead of loose routing. Can you try again?
Still same, as before. PRACK is construct incorrect.
uri in PRACK after topos is first record-route part, not contact. record route restores incorrect to.
Thank you.
I see log messages that are not in the default source code:
``` Aug 14 14:29:30 csbc-uat /usr/sbin/kamailio[4315]: ERROR: topos [tps_msg.c:766]: tps_request_received(): sbasov load_branch done ```
Can you test with fresh master branch? Otherwise I cannot correlate logs with source code.
The Route headers seems to be ok, only the R-URI not recovered, but as I looked again at code, it should. Just test with latest master again, without any changes from your side.
Sorry, Daniel It was my fault... After commit fbf8f68ed1f8df9af7ed60cb14d379e571550a03 PRACK is handled properly.
@slavrov can you make tests with latest master?
Thank you.
I will make a try and will report in a few days.
Closed #1167.
@sergey-vb no worries, thanks for testing troubleshooting!
I am closing it and if there are issues, reopen or open a new issue, as you consider better.
Dear Daniel! Just compiled kamailio 5.0.4 and still have problem with PRACK packets. I sent SIP dump to your email. Hope this helps. Thanks in advance!
Hi All.
Looks like Daniel forgot to merge some commits to 5.0 branch. Latest commit to topos module in 5.0 branch is on May 8, 2017
Fixes for correct PRACK processing was committed after that date... Mostly in August.
@slavrov can you compile master branch and perform tests?
For me it works.
The topos module got major refactoring in the master branch (to have support for other backends, redis (see topos_redis) being the one added along with the old support for db). I am not sure these patches can be backported without a consistent work. If someone does it and makes a pull request for branch 5.0, I will review and merge it. But I do not have the time at this moment. In few week 5.1 will be out anyhow as a stable release, my efforts on spare time are directed to make it stable.
ok thanks for info guys! will wait 5.1 release then.
-
Daniel-Constantin Mierla -
Sergey Lavrov
-
sergey-vb