[kamailio/kamailio] topos module producing invalid SIP message (missing Via header) when handling 200 OK to OPTIONS request (#1350)
Hello all, I've come across the following issue with topos on Kamailio 5.1.0-rc2. ### Description Kamailio acts as a proxy for asterisk instances residing in a private IP range. Asterisk's peers are configured with their public IP address or hostname, but asterisk will dispatch requests to them to kamailio instead (because kamailio's IP is set in outboundproxy option in peer definition). This works fine for INVITEs, but if qualify=yes is set for the peer, asterisk will send out OPTIONs to monitor these peers. If the topos module is loaded, 200 OK replies to these OPTIONs will be malformed when forwarded from kamailio to asterisk (no Via header present). Disabling the topos module will resolve this. ### Troubleshooting #### Reproduction Configure a peer in asterisk with outboundproxy option set to kamailio's IP address. Set qualify=yes. Adjust kamailio's default configuration so that OPTIONs to other hosts besides itself are routed. Change the following section in request_route: ``` if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } ``` to: ``` if ( ($rU==$null) && !(is_method("OPTIONS")) ) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # Permit asterisk's monitoring using options if(is_method("OPTIONS") && uri!=myself) { route(RELAY); } ``` Enable and configure the topos module with database. #### SIP Traffic asterisk:5060 -> kamailio:5060 ``` OPTIONS sip:peer.domain.tld SIP/2.0 Via: SIP/2.0/UDP asterisk:5060;branch=z9hG4bK460330cf;rport Max-Forwards: 70 From: "asterisk" <sip:asterisk@domain.tld>;tag=as690c2406 To: <sip:peer.domain.tld> Contact: <sip:asterisk@asterisk:5060> Call-ID: 6548f43b2d8740122186bb0c6e72ac78@domain.tld CSeq: 102 OPTIONS User-Agent: myUA Date: Sun, 03 Dec 2017 00:39:38 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Length: 0 ``` kamailio:5060 -> peer:5060 ``` OPTIONS sip:peer.domain.tld SIP/2.0 Via: SIP/2.0/UDP kamailio:5060;branch=z9hG4bK460330cf;rport Max-Forwards: 69 From: "asterisk" <sip:asterisk@domain.tld>;tag=as690c2406 To: <sip:peer.domain.tld> Contact: <sip:asterisk@asterisk:5060> Call-ID: 6548f43b2d8740122186bb0c6e72ac78@domain.tld CSeq: 102 OPTIONS User-Agent: myUA Date: Sun, 03 Dec 2017 00:39:38 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Length: 0 ``` peer:5060 -> kamailio:5060 ``` SIP/2.0 200 OK Via: SIP/2.0/UDP kamailio;branch=z9hG4bKda8d.cc03bd2def8ad36e8c43f61ab31a636f.0;received=kamailio;rport=5060 From: "asterisk" <sip:asterisk@domain.tld>;tag=as690c2406 To: <sip:peer.domain.tld>;tag=as472874ee Call-ID: 6548f43b2d8740122186bb0c6e72ac78@domain.tld CSeq: 102 OPTIONS Server: myUA Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sip:peer:5060> Accept: application/sdp Content-Length: 0 ``` **kamailio:5060 -> asterisk:5060: Missing Via Header** ``` SIP/2.0 200 OK From: "asterisk" <sip:asterisk@domain.tld>;tag=as690c2406 To: <sip:peer.domain.tld>;tag=as472874ee Call-ID: 6548f43b2d8740122186bb0c6e72ac78@domain.tld CSeq: 102 OPTIONS Server: myUA Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sip:peer:5060> Accept: application/sdp Content-Length: 0 ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.1.0-rc2 (x86_64/linux) 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 with gcc 6.3.0 ``` * **Operating System**: ``` Debian 9.1 ``` * **Other pertinent configuration information**: This kamailio box has several network interfaces. mhomed is not used, instead force_send_socket is called where necessary. I'm mentioning this in case it's what might trigger this issue with topos. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350
Can you run with debug=3 in kamailio.cfg, do such a test and send over all the log messages printed by kamailio? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-348813814
I'm attaching the requested logs, hope it helps... I've grepped the syslog with the call-id for the options message, I hope it is sufficient. [missing-via-topos-options.txt](https://github.com/kamailio/kamailio/files/1533559/missing-via-topos-options...) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-349499489
I also have the problem of missing VIA in 200 OK reply but it was for REINVITE message. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-351683326
I don't have this issue with re-INVITEs, only with the 200 OK to OPTIONS. Just as an update, this also happens with 5.1.0-stable. Does your reINVITE issue go away if you disable topos entirely? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-351695602
The version I was using was 5.0.3. I will test with 5.1.0 to see if the problem still exist. For the version 5.0.3, the problem goes away when I disable the topos module. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-351722251
That is curious... Are you using a derivative of the sample configuration and if yes, have you deviated in any way from the sample WITHINDLG route? Still, I haven't tested specifically for this with 5.0 branch, it is possible I missed it... However the reINVITE I tested was only in one direction. In this case, the 200 OK relayed by kamailio is not the same direction as the 200 OK corrupted by topos for the OPTIONs I reported originally. So my test maybe didn't replicate yours exactly (barring any config file differences). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-351727018
In my case, the reINVITE come in in the same direction as the first INVITE. I have no special treatment for in dialog request. Juste doing loose_route & relay. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-351731449
Just tested with 5.1.0 and had the same problem. Bellow is what I got in my log file. Any idea @miconda? Dec 14 17:51:43: INFO: loose_route : INVITE sip:+xxxx@xxxxx:5080 Dec 14 17:51:43: INFO: Relaying a loose route request: INVITE sip:+xxxx@xxxxx:5080 (sip:192.168.50.xxx;lr;ftag=205258336;did=b2e.1601) Dec 14 17:51:43: INFO: Routing message sip:+xxxx@xxxx:5080 to destination sip:+xxxx@xxxx:5080 (sip:192.168.50.xxx;lr;ftag=205258336;did=b2e.1601) Dec 14 17:51:43: ERROR: topos [tps_storage.c:1254]: tps_db_update_dialog(): no valid dlg uuid Dec 14 17:51:43: ERROR: topos [tps_storage.c:1254]: tps_db_update_dialog(): no valid dlg uuid Dec 14 17:51:44: ERROR: topos [tps_storage.c:1254]: tps_db_update_dialog(): no valid dlg uuid Dec 14 17:51:46: ERROR: topos [tps_storage.c:1254]: tps_db_update_dialog(): no valid dlg uuid Dec 14 17:51:46: ERROR: topos [tps_storage.c:1254]: tps_db_update_dialog(): no valid dlg uuid Dec 14 17:51:50: ERROR: topos [tps_storage.c:1254]: tps_db_update_dialog(): no valid dlg uuid -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-351773179
FYI, the REINVITE has this first line: INVITE sip:**atpsh-5a32a6fe-162e-1**@192.168.50.xxx:5061 SIP/2.0 In the database, I see the value **atpsh-5a32a6fe-162e-1** in the column a_uuid of the corresponding call -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-351775919
Have you updated the database structure for 5.1? Not that it should make a difference, but maybe the new indexes for topos will speedup the lookups in case this is a time-sensitive issue? Long shot, but I'm out of ideas here... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-351787256
Closed #1350. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#event-1425592262
Had the time to play more with it and I think you do not do `record_route()` for OPTIONS requests -- this is a requirement to know local addresses used to communicate with each side, the Record-Route headers do not appear in the requests sent out. I pushed a commit to the docs to make this clear. I also added another patch (97532ca18f595d89edf9b0b6e6688847aa38dd44) that should make it work without `record_route` for your specific case, but I would recommend to do the option with `record_route()`, should be safer overall. Reopen if still an issue. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-357879543
You're right. I never would have thought that record_route() is somehow needed for non-dialog-forming requests... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-358120343
I still have the problem of routing the 200 OK message for the REINVITE. 192.168.70.106:5061 is the Kamailio with topos module enabled. **Here is the REINVITE message arriving from our provider:** INVITE sip:btpsh-5acddf40-d74-5@192.168.70.106:5061 SIP/2.0 Call-ID: 79acbb714c21354c Contact: <sip:80.10.231.10:5060;transport=udp> Content-Type: application/sdp CSeq: 1 INVITE From: <sip:xxxx@xxxx;user=phone>;tag=SDt2dkc98-04020267673121 Max-Forwards: 63 Record-Route: <sip:192.168.70.126:5060;user=i0o0S000000ad;lr;Cpkt=XWJOA;C=xxxx>,<sip:192.168.70.126:5070;user=00000214;lr;Cpkt=YJJEE;C=xxx> To: <sip:+yyyy@xxxx;user=phone>;tag=1713351228 Via: SIP/2.0/UDP 192.168.70.126:5060;branch=z9hG4bK-XWJO-000227ab-7eda6242,SIP/2.0/UDP 192.168.70.126:5070;received=192.168.70.126;rport=5070;branch=z9hG4bK-YJJE-000a057c-0bf8ef7c,SIP/2.0/UDP 193.200.4.20:5060;emission,SIP/2.0/UDP 80.10.231.10:5060;received=80.10.231.10;rport=5060;branch=z9hG4bK5g8vgn00cobc0atd6hf0sb0000g00.1 Accept: application/sdp Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,PRACK Content-Length: 236 **Here is the REINVITE comming out of Kamailio into our core side:** INVITE sip:192.168.40.106:5090;did=d03.e3be0354 SIP/2.0 Via: SIP/2.0/UDP 192.168.70.106:5061;branch=z9hG4bK443f.2ec12863719a69f1e3851178d9cb21d0.0 Call-ID: 79acbb714c21354c Content-Type: application/sdp CSeq: 1 INVITE From: <sip:+xxx@xxxx>;tag=SDt2dkc98-04020267673121 Max-Forwards: 62 To: <sip:xxx@xxxx>;tag=1713351228 Accept: application/sdp Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,PRACK Content-Length: 236 Route: xxx Contact: <sip:atpsh-5acddf40-d75-5@192.168.70.106:5061> **Here is the 200 OK for this REINVITE message comming from the core side** (This message arrived to Kamailio but is never sent to our provider). SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.70.106:5061;branch=z9hG4bK443f.2ec12863719a69f1e3851178d9cb21d0.0 From: <sip:+xxx@xxxx>;tag=SDt2dkc98-04020267673121 To: <sip:xxx@xxxx>;tag=1713351228 Call-ID: 79acbb714c21354c CSeq: 1 INVITE Contact: <sip:192.168.40.106:5090;did=d03.e3be0354> Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO Content-Type: application/sdp Content-Length: 197 **When Kamailio received this 200 OK, I see this log message:** ERROR: topos [tps_storage.c:1299]: tps_db_update_dialog(): no valid dlg uuid (0: - 0:) Some hint on how to debug this please @miconda ? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-380411710
Well, I've just read the #1421. Let me update the code and test again first. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-380412551
The same problem still exist with the lastest code. That's logic because I had reported this error before the commit 97532ca Any help is highly appreciated. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-380418384
@qmphan - open a new issue, do not comment on a closed issue from several months ago, even if seems related, this one was closed with the code base at the same time. Use the relevant comments and details you put here and make a new issue. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-380446786
Just for documentation, the commit 97532ca was reverted. so record_route() is needed e.g. OPTIONS request in this scenario. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1350#issuecomment-947398786
participants (4)
-
Daniel-Constantin Mierla -
David Minh Phan
-
George Diamantopoulos
-
Henning Westerholt