```
Reading symbols from kamailio...Reading symbols from /usr/lib/debug/.build-id/10/824757bd1066806f2e19310929e17a9009a991.debug...done.
done.
[New LWP 5583]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -f /etc/kamailio/proxy/kamailio.cfg -P /var/run/kamailio/kam'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 xavp_get_internal (name=0x7f486b2f7568, list=<…
[View More]optimized out>, idx=0, prv=0x0) at xavp.c:265
265 xavp.c: No such file or directory.
(gdb) bt
#0 xavp_get_internal (name=0x7f486b2f7568, list=<optimized out>, idx=0, prv=0x0) at xavp.c:265
#1 0x00007f486306b8b3 in pv_get_xavp (msg=0x7f4866d8e5f0, param=0x7f486b2f7768, res=0x7ffceb21ed90)
at pv_xavp.c:134
#2 0x000000000058f96e in pv_get_spec_value (msg=0x7f4866d8e5f0, sp=0x7f486b2f7750,
value=0x7ffceb21ed90) at pvapi.c:1307
#3 0x00007f479badb45d in lua_sr_pv_get (L=0x2b46aa0) at app_lua_sr.c:906
...
(gdb) f 3
#3 0x00007f479badb45d in lua_sr_pv_get (L=0x2b46aa0) at app_lua_sr.c:906
906 app_lua_sr.c: No such file or directory.
(gdb) p pvn
$5 = {s = 0x2c47588 "$xavp(caller_dom_prefs=>dummy)", len = 30}
(gdb) f 2
#2 0x000000000058f96e in pv_get_spec_value (msg=0x7f4866d8e5f0, sp=0x7f486b2f7750,
value=0x7ffceb21ed90) at pvapi.c:1307
1307 pvapi.c: No such file or directory.
(gdb) p sp
$6 = (pv_spec_p) 0x7f486b2f7750
(gdb) p *sp
$7 = {type = PVT_XAVP, getf = 0x7f486306b810 <pv_get_xavp>, setf = 0x7f486306c640 <pv_set_xavp>,
pvp = {pvn = {type = 1, nfree = 0x0, u = {isname = {type = 1798272592, name = {n = 0, s = {
s = 0x0, len = 0}, re = 0x0}}, dname = 0x7f486b2f7650}}, pvi = {type = 0, u = {
ival = 0, dval = 0x0}}}, trans = 0x0}
(gdb) f 1
#1 0x00007f486306b8b3 in pv_get_xavp (msg=0x7f4866d8e5f0, param=0x7f486b2f7768, res=0x7ffceb21ed90)
at pv_xavp.c:134
134 pv_xavp.c: No such file or directory.
(gdb) p xname
$8 = (pv_xavp_name_t *) 0x7f486b2f7650
(gdb) p *xname
$9 = {name = {s = 0x7f486b2f77b6 "caller_dom_prefs=>dummy)", len = 16}, index = {type = PVT_NONE,
getf = 0x0, setf = 0x0, pvp = {pvn = {type = 0, nfree = 0x0, u = {isname = {type = 0, name = {
n = 0, s = {s = 0x0, len = 0}, re = 0x0}}, dname = 0x0}}, pvi = {type = 0, u = {
ival = 0, dval = 0x0}}}, trans = 0x0}, next = 0x7f486b2f7568}
(gdb) p *xname->next
$10 = {name = {s = 0x7f486b2f77c8 "dummy)", len = 5}, index = {type = PVT_NONE, getf = 0x0,
setf = 0x0, pvp = {pvn = {type = 0, nfree = 0x0, u = {isname = {type = 0, name = {n = 0, s = {
s = 0x0, len = 0}, re = 0x0}}, dname = 0x0}}, pvi = {type = 0, u = {ival = 0,
dval = 0x0}}}, trans = 0x0}, next = 0x0}
(gdb) p avp
$11 = <optimized out>
(gdb) p avp->val
value has been optimized out
(gdb) p avp->val.v
value has been optimized out
(gdb) p avp->val.v.xavp
value has been optimized out
```
Relevant code?
```
static sr_xavp_t *xavp_get_internal(str *name, sr_xavp_t **list, int idx, sr_xavp_t **prv)
{
sr_xavp_t *avp;
unsigned int id;
int n = 0;
if(name==NULL || name->s==NULL)
return NULL;
id = get_hash1_raw(name->s, name->len);
if(list && *list)
avp = *list;
else
avp = *_xavp_list_crt;
while(avp)
{
if(avp->id==id && avp->name.len==name->len
&& strncmp(avp->name.s, name->s, name->len)==0)
{
if(idx==n)
return avp;
n++;
}
if(prv)
*prv = avp;
avp = avp->next;
}
return NULL;
}
```
--
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/808
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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
dmq_usrloc has "location" hardcoded as the table name. If usrloc module is using a different table name for save() and lookup(), dmq_usrloc fails.
One potential solution could be to have a modparam for dmq_usrloc to specify the tables to sync
--
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/796
For security reasons we can use only 32min character passwords on my work.
And when i tried to create user i got errors from DB.
So, i think this will be useful for other kamailio users.
Sorry for wrong commit format, but i can't understand to which part of kamailio this changes are related.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/779
-- Commit Summary --
* increase password length to 64 in utils(postgres, oracle, …
[View More]mysql, sqlite)
* increase password length to 64 in scripts(postgres, oracle, mysql)
-- File Changes --
M scripts/mysql/my_create.sql (2)
M scripts/oracle/or_create.sql (2)
M scripts/postgres/pg_create.sql (2)
M utils/kamctl/db_sqlite/auth_db-create.sql (2)
M utils/kamctl/db_sqlite/uid_auth_db-create.sql (2)
M utils/kamctl/mysql/auth_db-create.sql (2)
M utils/kamctl/mysql/uid_auth_db-create.sql (2)
M utils/kamctl/oracle/auth_db-create.sql (2)
M utils/kamctl/oracle/uid_auth_db-create.sql (2)
M utils/kamctl/postgres/auth_db-create.sql (2)
M utils/kamctl/postgres/uid_auth_db-create.sql (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/779.patchhttps://github.com/kamailio/kamailio/pull/779.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/779
[View Less]
Hi Daniel,
This issue might be related to #679 and #752.
On a "A endpoint" --- Kamailio ---- "B endpoint" scenario with track_cseq_updates enabled, I am having this issue:
- **A** sends INVITE with CSeq 101, **Kamailio** forwards it and gets 407 from **B**.
- **Kamailio** makes the SIP Auth with CSeq 102 using _uac_auth_.
- **A** sends a within-dialog transaction with Cseq 102.
- **Kamailio** does not mangle the Cseq (although it adds P-K-CSeq-Refresh: 103 header).
- **B** sends 200 OK …
[View More]with Cseq 102.
- **Kamailio** mangles it and forwards it to **A** with Cseq 101 (that doesn't match the expected CSeq).
I have tested both in master branch (commit d150d5a) and 4.4 branch (commit 5a21952).
I send you a pcap to your gmail account so that you can see what I mean :)
Thank you and tell me please if you need more testing!
--
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/787
[View Less]
Sipwise hat ON:
In order to be able to share the same DB and take care of the expired records only related to that server.
We need a module parameter to allow filter by server_id when loading values from DB
Related to #781
--
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/782