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
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
Add new rabbitmq module.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/786
-- Commit Summary --
* rabbitmq: Add new module
-- File Changes --
A modules/rabbitmq/Makefile (14)
A modules/rabbitmq/README (244)
A modules/rabbitmq/doc/Makefile (4)
A modules/rabbitmq/doc/rabbitmq.xml (39)
A modules/rabbitmq/doc/rabbitmq_admin.xml (338)
A modules/rabbitmq/rabbitmq.c (579)
A modules/rabbitmq/rabbitmq.h (15)
A modules/rabbitmq/utils.c (192)
A modules/rabbitmq/utils.h (50)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/786.patchhttps://github.com/kamailio/kamailio/pull/786.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/786
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, 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
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 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
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