```
Jun 6 14:38:43 spce lb[27903]: : tls [tls_init.c:557]: init_tls_h(): ERROR: tls: init_tls_h: installed openssl library version is too different from the library the Kamailio tls module was compiled with: installed "OpenSSL 1.0.1t 3 May 2016" (0x1000114f), compiled "OpenSSL 1.0.1k 8 Jan 2015" (0x100010bf).#012 Please make sure a compatible version is used (tls_force_run in kamailio.cfg will override this check)
Jun 6 14:38:43 spce lb[27903]: CRITICAL: <core> [main.c:2577]: main(): could not initialize tls, exiting...
```
openssl was upgraded from 1.0.1k-3+deb8u5 to 1.0.1t-1+deb8u2
This seems not to work properly
https://github.com/kamailio/kamailio/blob/master/modules/tls/tls_init.c#L54…
```
#if OPENSSL_VERSION_NUMBER < 0x00907000L
WARN("You are using an old version of OpenSSL (< 0.9.7). Upgrade!\n");
#endif
ssl_version=SSLeay();
/* check if version have the same major minor and fix level
* (e.g. 0.9.8a & 0.9.8c are ok, but 0.9.8 and 0.9.9x are not) */
if ((ssl_version>>8)!=(OPENSSL_VERSION_NUMBER>>8)){
LOG(L_CRIT, "ERROR: tls: init_tls_h: installed openssl library "
"version is too different from the library the Kamailio tls module "
"was compiled with: installed \"%s\" (0x%08lx), compiled "
"\"%s\" (0x%08lx).\n"
" Please make sure a compatible version is used"
" (tls_force_run in kamailio.cfg will override this check)\n",
SSLeay_version(SSLEAY_VERSION), ssl_version,
OPENSSL_VERSION_TEXT, (long)OPENSSL_VERSION_NUMBER);
if (cfg_get(tls, tls_cfg, force_run))
LOG(L_WARN, "tls: init_tls_h: tls_force_run turned on, ignoring "
" openssl version mismatch\n");
else
return -1; /* safer to exit */
}
```
---
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/662
If a PUBLISH request is sent before a 200 OK for the previous PUBLISH request is received, the E-Tag is reset which leads to inconsistent presentity data in the presence server.
This is happening because the second PUBLISH is sent with the same E-Tag as the previous one, but the presence server has an updated the E-Tag (generated while handling the first PUBLISH).
The pua module should implement a queuing mechanism for subsequent PUBLISH request while a previous PUBLISH transaction is in progress. No new PUBLISH requests should be sent before a response to the previous PUBLISH request was received and the E-Tag updated.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/21
Hello,
```
kamailio -v
version: kamailio 4.4.0-pre0 (i386/linux) f39d14-dirty
flags: STATS: Off, EXTRA_DEBUG, 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_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: f39d14 -dirty
compiled on 17:01:22 Feb 12 2016 with gcc 4.9.3
```
If I read well the RFC 3261 section 20.19 [https://tools.ietf.org/html/rfc3261#section-20.19] a SUBSCRIBE or a PUBLISH may have an Expires value of 2**32-1 = (4294967295).
But it appears to me that this value is not supported in Kamailio even if I allow it as a max_expires option in configuration (modparam("presence", "max_expires", 4294967295)).
Kamailio answers with the following:
```
2016/02/29 09:02:59.343750 192.168.100.1:5060 -> 192.168.2.2:5062
SIP/2.0 423 Interval Too Brief
via: SIP/2.0/UDP 192.168.2.2:5062;branch=z9hG4bK-11535-1-9;rport=5062
From: "User1" <sip:user1@example.com>;tag=11535-1
To: "User1" <sip:user1@example.com>;tag=dfba6eee28f067076993264b7e466d4e.151a
Call-ID: 1-11545(a)192.168.1.1-user1
CSeq: 3 PUBLISH
Expires: -2147483648
SIP-ETag: a.1456732971.11285.1.0
Server: kamailio (4.4.0-pre0 (i386/linux))
Content-Length: 0
```
Which is not compliant with the RFC, the Expires value should not be signed.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/521
The README needs to be up to date with the source code. I noted that the "Outbound proxy" modparam is not documented.
---
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/580
This helps first timers and casual users a lot, as they won't have to dig
through the history of Kamailio and various modules to find these
structures.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/718
-- Commit Summary --
* examples/[pis]cscf: adds example database structures for the P/I/S-CSCFs
-- File Changes --
A examples/icscf/icscf.mysql.sql (137)
A examples/pcscf/pcscf.mysql.sql (193)
A examples/scscf/scscf.mysql.sql (448)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/718.patchhttps://github.com/kamailio/kamailio/pull/718.diff
---
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/pull/718
I've been trying to track this issue down myself for the last two days but it appears the value is coming from somewhere in the tm module or somewhere else lower than that, which I haven't worked with at all. I have siptrace turned on and I'm using the destination port from the HEPv2 header but it seems to always come to me as 5060 even if the packet is actually sent to a different port (such as 51000). I'm able to reproduce this with my Polycom phone by having two registrations (one UDP and one TCP) going through a Kamailio server from the same phone. It looks like the first request comes from 5060 and is responded to on 5060, but the second connection comes from a random port on the phone (let's say 35000). When the reply (such as a 200) comes back from the server sitting behind the Kamailio proxy, the siptrace HEP header says the packet is going back to 5060 when it's actually being sent to 35000. I'm not even sure where the 5060 value is coming from in the first place
.
I've tracked the '5060' value to `t.uas.response.dst.to.sin.sin_port` in `t_reply.c:reply_received()` but the value of `t` is retrieved from `get_t()` and I'm not sure where that's added to the hash table in the first place. I can see the actual value of the destination port with `t.uas.request.rcv.src_port` within that same `t_reply.c:reply_received()` but I can't figure out how to get that value into the destination port at the source.
---
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/581
Hello,
If I understand correctly to insert some additional ISUP(SIP-T) data after SDP into INVITE SIP message the first step would be to convert a single body of this SIP message to a multipart body with `set_body_multipart` (from `textops` module) without any parameters (according to https://www.kamailio.org/docs/modules/stable/modules/textops.html#textops.f…) and then it would convert this message to a multipart one. Then use `append_body_part` from the same module to insert ISUP data. However when we tested the first step `set_body_multipart` didn't insert a proper closing boundary delimiter (ending with two more hyphens) as it's supposed to according its documentation: _The core will take care of the last boundary ending "--". Detecting which one is the last and fixing the others if needed._
We tested with the latest release 4.4.1:
kamailio.cfg:
```
route {
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
# account only INVITEs
if (is_method("INVITE"))
{
setflag(1); # do accounting
if(!ds_is_from_list("1")){
## handle INBOUND ISUP
route(ISUP);
} else {
xlog("SIP message from $ru\n");
## handle OUTBOUND ISUP
route(TO_PSTN);
}
}
if ($rU==$null)
{
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
# dispatch destinations
route(DISPATCH);
}
route[TO_PSTN] {
set_body_multipart(); # supposed to do the right thing
msg_apply_changes(); # tested with and without this call, still the same result
}
```
Malformed INVITE SIP message (from Wireshark):
```
INVITE sip:1000@192.168.38.88:5080 SIP/2.0
Record-Route: <sip:192.168.38.88:5080;lr=on;callgenie=true>
Via: SIP/2.0/UDP 192.168.38.88:5080;branch=z9hG4bK61df.358abca8ab3f0186f30b081e906e09d0.0
Via: SIP/2.0/UDP 192.168.38.88:5060;branch=z9hG4bK0fdf4145
Max-Forwards: 69
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as6510bcf9
To: <sip:1000@192.168.38.88:5080>
Contact: <sip:anonymous@192.168.38.88:5060>
Call-ID: 4ad0a0133cdbea9c6a05677715d4bd21@192.168.38.88:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.6.0
Date: Tue, 07 Jun 2016 08:38:02 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-ISUP-ANI: 081101213
Content-Length: 435
Content-Type: multipart/mixed;boundary="unique-boundary-1"
Mime-Version: 1.0
--unique-boundary-1
Content-Type: application/sdp
v=0
o=root 957277759 957277759 IN IP4 192.168.38.88
s=Asterisk PBX 13.6.0
c=IN IP4 192.168.38.88
b=CT:384
t=0 0
m=audio 11424 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv
m=video 13788 RTP/AVP 34
a=rtpmap:34 H263/90000
a=sendrecv
--unique-boundary-1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.38.88:5080;branch=z9hG4bK61df.358abca8ab3f0186f30b081e906e09d0.0
Via: SIP/2.0/UDP 192.168.38.88:5060;branch=z9hG4bK0fdf4145
To: <sip:1000@192.168.38.88:5080>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as6510bcf9
Call-ID: 4ad0a0133cdbea9c6a05677715d4bd21@192.168.38.88:5060
CSeq: 102 INVITE
Content-Length: 0
<skipped>
```
Thanks.
---
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/661