<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.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.kamailio.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 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
The reginfo notifications sent via pua_reginfo + presence_reginfo contains the version fixed to `0`.
The pua docs report the param `reginfo_increase_version` which should increase the version if enabled, but currently does nothing.
Looking into the code seems to confirm that, param is read from `pua` module but is not used anywhere. While the param `dlginfo_increase_version` seems to be used for the intended scope.
#### Reproduction
Setup pua + pua_reginfo to publish registration informations and observe that version param of reginfo is always 0, not respecting pua `reginfo_increase_version` setting.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.6.1 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, 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_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, 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 9.4.0
```
* **Operating System**:
```
Linux Debian bullseye/sid
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3234
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3234(a)github.com>
version: kamailio 5.5.2 (arm6/linux) 55e232
raspberry pi 3b
I initially stated that I was running on 5.5.3 but I was mistaken. However I checked the 5.5.3 source and it appears to be the same.
I think that there is a bug in the tm module with respect to the "tm:local-response" event route. In the "t_reply.c" file, there is a static variable called '_tm_local_response_set_lookup'. This variable is initialized at load time to zero. It is checked in the '_reply_light()' routine and will initiate a local callback from the config script if "armed". The problem as I see it is that if the callback is readied, the variable is set to one. But it is never reset.
So the observed behavior is as follows. A REGISTER is received and the request_route arms the callback. The REGISTER requires an authorization (local database sqlite). After the 401 is sent back, the callback via the event route is called as expected. All good except that the event route script fragment is never executed again after the first call... ever, even if it's a new REGISTER request.
I would think that somewhere in the tm module, the variable should be reset to zero so that subsequent transactions can initiate the event route again. Or maybe the variable ought to live somewhere in the transaction cell???
. . .
t_on_reply ("MY_FRAG");
t_on_failure ("MY_FRAG");
. . .
event_route [tm:local-response] {
xlog ("L_NOTICE", IN tm:local-response\n");
my_function();
}
. . .
So 'my_function()' is only called once.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3064
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3064(a)github.com>
With GNU make 4.4 building Kamailio prints many “make: --libs: No such file or directory” and similar warnings. This changeset utilizes immediate variables and silences the warnings on my systems.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3475
-- Commit Summary --
* lib/ims: Aviod “make: --libs: No such file or directory” warnings
* auth_identity: Aviod “make: --libs: No such file or directory” warnings
* auth_ephemeral: Aviod “make: --libs: No such file or directory” warnings
* app_python3: Avoid “/bin/sh: line 1: --ldflags: command not found” warnings
* app_python3s: Avoid “/bin/sh: line 1: --ldflags: command not found” warnings
* cdp: Aviod “make: --libs: No such file or directory” warnings
* cnxcc: Avoid “make: --libs-only-L: No such file or directory” warnings
* cplc: Avoid “make: --libs-only-L: No such file or directory” warnings
* crypto: Aviod “make: --libs: No such file or directory” warnings
* db_postgres: Avoid “make: --libs-only-L: No such file or directory” warnings
* db_redis: Avoid “make: --libs-only-L: No such file or directory” warning
* dialplan: Avoid “make: --libs-only-L: No such file or directory” warning
* gzcompress: Aviod “make: --libs: No such file or directory” warnings
* http_async_client: Aviod “make: --libs: No such file or directory” warnings
* http_client: Aviod “make: --libs: No such file or directory” warning
* ims_auth: Avoid “make: --libs-only-L: No such file or directory” warning
* ims_icscf: Aviod “make: --libs: No such file or directory” warning
* ims_registrar_scscf: Avoid “make: --libs-only-L: No such file or directory” warnings
* ims_registrar_pcscf: Aviod “make: --libs: No such file or directory” warning
* ims_isc: Avoid “make: --libs-only-L: No such file or directory” warnings
* jansson: Aviod “make: --libs: No such file or directory” warning
* kazoo: Avoid “make: --libs: No such file or directory’ warning
* lcr: Aviod “make: --libs: No such file or directory” warning
* log_systemd: Aviod “make: --libs: No such file or directory” warning
* lost: Aviod “make: --libs: No such file or directory” warnings
* lwsc: Aviod “make: --libs: No such file or directory” warning
* ndb_redis: Aviod “make: --libs: No such file or directory” warning
* osp: Avoid “make: --libs: No such file or directory’ warning
* outbound: Aviod “make: --libs: No such file or directory” warnings
* presence: Avoid “make: --libs-only-L: No such file or directory” warnings
* presence_conference: Aviod “make: --libs: No such file or directory” warning
* presence_dialog: Aviod “make: --libs: No such file or directory” warning
* presence_reginfo: Aviod “make: --libs: No such file or directory” warning
* presence_xml: Avoid “make: --libs-only-L: No such file or directory” warnings
* pua: Avoid “make: --libs-only-L: No such file or directory” warnings
* pua_bla: Aviod “make: --libs: No such file or directory” warning
* pua_dialoginfo: Aviod “make: --libs: No such file or directory” warning
* pua_reginfo: Aviod “make: --libs: No such file or directory” warning
* pua_usrloc: Aviod “make: --libs: No such file or directory” warning
* pua_xmpp: Aviod “make: --libs: No such file or directory” warning
* regex: Aviod “make: --libs: No such file or directory” warning
* rls: Avoid “make: --libs-only-L: No such file or directory” warnings
* slack: Aviod “make: --libs: No such file or directory” warning
* systemdops: Avoid “make: --libs-only-L: No such file or directory” warning
* tls: Aviod “make: --libs: No such file or directory” warnings
* tlsa: Avoid “make: --libs-only-L: No such file or directory” warning
* topos_redis: Aviod “make: --libs: No such file or directory” warning
* utils: Avoid “make: --libs-only-L: No such file or directory” warnings
* uuid: Aviod “make: --libs: No such file or directory” warning
* websocket: Aviod “make: --libs: No such file or directory” warnings
* xcap_server: Avoid “make: --libs-only-L: No such file or directory” warnings
* xhttp_pi: Avoid “make: --libs-only-L: No such file or directory” warnings
* xmlops: Aviod “make: --libs: No such file or directory” warning
* xmlrpc: Aviod “make: --libs: No such file or directory” warning
-- File Changes --
M src/lib/ims/Makefile (4)
M src/modules/app_python3/Makefile (6)
M src/modules/app_python3s/Makefile (6)
M src/modules/auth_ephemeral/Makefile (2)
M src/modules/auth_identity/Makefile (4)
M src/modules/cdp/Makefile (4)
M src/modules/cnxcc/Makefile (4)
M src/modules/cplc/Makefile (4)
M src/modules/crypto/Makefile (2)
M src/modules/db_postgres/Makefile (2)
M src/modules/db_redis/Makefile (2)
M src/modules/dialplan/Makefile (2)
M src/modules/gzcompress/Makefile (2)
M src/modules/http_async_client/Makefile (6)
M src/modules/http_client/Makefile (2)
M src/modules/ims_auth/Makefile (4)
M src/modules/ims_icscf/Makefile (4)
M src/modules/ims_isc/Makefile (4)
M src/modules/ims_registrar_pcscf/Makefile (4)
M src/modules/ims_registrar_scscf/Makefile (4)
M src/modules/jansson/Makefile (2)
M src/modules/kazoo/Makefile (2)
M src/modules/lcr/Makefile (2)
M src/modules/log_systemd/Makefile (2)
M src/modules/lost/Makefile (6)
M src/modules/lwsc/Makefile (2)
M src/modules/ndb_redis/Makefile (2)
M src/modules/osp/Makefile (2)
M src/modules/outbound/Makefile (7)
M src/modules/presence/Makefile (4)
M src/modules/presence_conference/Makefile (4)
M src/modules/presence_dialoginfo/Makefile (4)
M src/modules/presence_reginfo/Makefile (4)
M src/modules/presence_xml/Makefile (4)
M src/modules/pua/Makefile (4)
M src/modules/pua_bla/Makefile (4)
M src/modules/pua_dialoginfo/Makefile (4)
M src/modules/pua_reginfo/Makefile (4)
M src/modules/pua_usrloc/Makefile (4)
M src/modules/pua_xmpp/Makefile (4)
M src/modules/regex/Makefile (2)
M src/modules/rls/Makefile (4)
M src/modules/slack/Makefile (2)
M src/modules/systemdops/Makefile (2)
M src/modules/tls/Makefile (4)
M src/modules/tlsa/Makefile (4)
M src/modules/topos_redis/Makefile (2)
M src/modules/utils/Makefile (4)
M src/modules/uuid/Makefile (2)
M src/modules/websocket/Makefile (2)
M src/modules/xcap_server/Makefile (4)
M src/modules/xhttp_pi/Makefile (4)
M src/modules/xmlops/Makefile (4)
M src/modules/xmlrpc/Makefile (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3475.patchhttps://github.com/kamailio/kamailio/pull/3475.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3475
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3475(a)github.com>
Actual implementation doesn't work with async. Need to investigate how to support it
---
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/684
The dialog module will expire dialogs that don't actually belong to the particular proxy.
Scenario: 2 proxies on 5.2.4 with a loadbalancer in front. Call was routed over proxy1, dialog timeout on proxy2 was shorter (to make it easier to reproduce it). The results:
* Dialog synchronized with DMQ: proxy 2 would timeout the dialog
* Dialog entry synchronized to proxy2 DB and proxy2 restarted: Proxy2 would timeout the dialog
* Dialog entry synchronized to proxy2 DB and proxy2 not restarted: Proxy2 would _not_ timeout the dialog (I’ve tried both db_mode 1 and 2)
So the proxy2 would load the dialog into memory and then later expire it. So timeout routes, send_bye on timeout would not work correctly.
One idea to solve this would be to check e.g. over the existing socket data if the dialog belongs to this proxy and skip loading it in this case. This could be also made configurable e.g. with a module parameter.
Any comments? Better ideas how to solve it?
--
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/2080
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.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.kamailio.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 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.
-->
The dmq_usrloc module is not replicating the extra attributes saved in the xavp for the contact. So remote nodes don't receive these values, being unable to access it properly.
It is expected that the attributes are replicated as well.
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
Setup two nodes using the dmq_usrloc and usrloc in db_mode=0.
When receiving a REGISTER, before saving the contact add some attribute in the xavp_contact. In a subsequent message to this contact (e.g.: INVITE) use a lookup() or registered() and try to access the desired xavp_contact attribute. If the request is received in the local node (which received the original REGISTER), the attribute will be valid, but if the request is received in the remote node, the attribute is empty.
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: registrar [save.c:410]: pack_ci(): generated ruid is: uloc-5cee2114-5abe-2
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ucontact.c:73]: ucontact_xavp_store(): trying to clone per contact xavps
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: <core> [core/xavp.c:697]: xavp_clone_level_nodata(): cloned root xavp [ulattrs]
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: <core> [core/xavp.c:721]: xavp_clone_level_nodata(): cloned inner xavp [cluster_node]
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ucontact.c:1701]: update_ucontact(): exists callback for type= UL_CONTACT_UPDATE
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ul_callback.h:84]: run_ul_callbacks(): contact=0x7f51b624d418, callback type 2/15, id 1 entered
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:776]: dmq_ul_cb_contact(): Callback from usrloc with type=2
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:427]: init_usrloc_dmq_recv(): Initializing usrloc_dmq_recv for pid (23230)
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:785]: dmq_ul_cb_contact(): Replicating local update to other nodes...
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:746]: usrloc_dmq_send_contact(): sending serialized data {"action":1,"aor":"345671002","ruid":"uloc-5cee20df-5953-1","c":"sip:345671002@172.28.128.200:5060;rinstance=38e53fed7e84e081;transport=UDP","received":"","path":"<sip:172.28.128.102:5060;received=sip:172.28.128.200:5060;lr>","callid":"NOeeFh1Bh5JR0eJG8DENkg..","user_agent":"Z 3.15.40006 rv2.8.20","instance":"","expires":1559110577,"cseq":12,"flags":0,"cflags":3072,"q":-1,"last_modified":1559109977,"methods":4294967295,"reg_id":0,"server_id":0}
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:315]: usrloc_dmq_send(): sending dmq broadcast...
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
Only workaround seems to use usrloc with db_mode=3 and then not use the dmq_usrloc, having the usrloc with attributes info shared via the DB....
### Additional Information
Kamailio 5.2.2 installed from the repo.
```
# kamailio -v
version: kamailio 5.2.2 (x86_64/linux) 67f967
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 67f967
compiled on 11:40:41 Mar 11 2019 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`)
-->
```
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)
# uname -a
Linux kamailio-2 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20 12:24:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
```
--
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/1968
### Description
This is an umbrella ticket to address issues with the WIP `tls_wolfssl` module
### Expected behavior
The module behaves robustly under load testing and various configurations
and thus can be accepted long-term in kamailio
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3160
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3160(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.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.kamailio.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 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
When using the PATH header option to keep track of original Kamailio node that received the REGISTER, if nathelper is also used with SIP ping enabled, the SIP OPTIONS is sent to itself following the PATH header and not sent directly to the destination.
The nathelper/user location modules should have a flag similar to the "path_check_local" of the registrar module, which is meant to avoid looping the message to itself in case the next hop pointed by the PATH header is "myself".
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
Configure the registrar module to support PATH and before saving the contact info add the PATH header with the local Kamailio information. Also make sure to have the nathelper and usrloc modules configured to send the keepalive SIP OPTIONS to the registered extensions.
By the time the SIP OPTIONS is sent, Kamailio sends to itself, then the message has to be loose_route'd to the final destination.
This could be avoided by having the nathelper module to identify the next hop is Kamailio itself skipping this destination as a call to "lookup()" does for the registrar module when the flag path_check_local is true.
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### 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).
-->
172.128.128.10 is the Kamailio IP and 172.128.128.20 is the extension IP
```
11:51:07.224713 IP (tos 0x60, ttl 64, id 64497, offset 0, flags [none], proto UDP (17), length 518)
172.128.128.10.5060 > 172.128.128.10.5060: SIP, length: 490
OPTIONS sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713
Route: <sip:172.128.128.10:5060;received=sip:172.128.128.20:5060;lr;cluster_node=192.168.156.10:5060>
From: sip:sbc@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2
To: sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP
Call-ID: 40ee1573-7506bba3-5e30c05(a)172.128.128.10
CSeq: 1 OPTIONS
Content-Length: 0
11:51:07.226132 IP (tos 0x60, ttl 64, id 44359, offset 0, flags [none], proto UDP (17), length 502)
172.128.128.10.5060 > 172.128.128.20.5060: SIP, length: 474
OPTIONS sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.128.128.10;branch=z9hG4bKb958.b807e80b742db62504a45220d8f0e974.0
Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713
From: sip:sbc@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2
To: sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP
Call-ID: 40ee1573-7506bba3-5e30c05(a)172.128.128.10
CSeq: 1 OPTIONS
Content-Length: 0
11:51:07.303474 IP (tos 0x0, ttl 128, id 10816, offset 0, flags [none], proto UDP (17), length 786)
172.128.128.20.5060 > 172.128.128.10.5060: SIP, length: 758
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.128.128.10;branch=z9hG4bKb958.b807e80b742db62504a45220d8f0e974.0
Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713
Contact: <sip:172.128.128.20:5060>
To: <sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP>;tag=bb0c1f2d
From: sip:sbc@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2
Call-ID: 40ee1573-7506bba3-5e30c05(a)172.128.128.10
CSeq: 1 OPTIONS
Accept: application/sdp, application/sdp
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, outbound, path, X-cisco-serviceuri
User-Agent: Z 3.15.40006 rv2.8.20
Allow-Events: presence, kpml, talk
Content-Length: 0
11:51:07.306821 IP (tos 0x60, ttl 64, id 64570, offset 0, flags [none], proto UDP (17), length 727)
172.128.128.10.5060 > 172.128.128.10.5060: SIP, length: 699
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713
Contact: <sip:172.128.128.20:5060;alias=172.128.128.20~5060~1>
To: <sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP>;tag=bb0c1f2d
From: sip:sbc@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2
Call-ID: 40ee1573-7506bba3-5e30c05(a)172.128.128.10
CSeq: 1 OPTIONS
Accept: application/sdp, application/sdp
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, outbound, path, X-cisco-serviceuri
User-Agent: Z 3.15.40006 rv2.8.20
Allow-Events: presence, kpml, talk
Content-Length: 0
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
Not found.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
# kamailio -v
version: kamailio 5.2.2 (x86_64/linux) 67f967
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 67f967
compiled on 11:40:41 Mar 11 2019 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`)
-->
```
# uname -a
Linux kamailio-1 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20 12:24:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
```
--
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/2011