29 Jul
2020
29 Jul
'20
4:07 p.m.
### Description
If db_mode == 2 (PUA_DB_ONLY) ``SIP-If-Match`` header doesn't exists on dialog event
```
PUBLISH sip:testuser1003@spce.test SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKcc38.e1cf4686000000000000000000000000.0
To: <sip:testuser1003@spce.test>
From: <sip:testuser1003@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-86dabd12
CSeq: 10 PUBLISH
Call-ID: 200464472a3c6cfc-497(a)127.0.0.1
Content-Length: 709
User-Agent: Sipwise NGCP Proxy 8.X
Max-Forwards: 70
Event: dialog
Expires: 23761
Content-Type: application/dialog-info+xml
```
same escenario but with db_mode == 0
```
PUBLISH sip:testuser1002@spce.test SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK5e55.d35147e4000000000000000000000000.0
To: <sip:testuser1002@spce.test>
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-84a3a447
CSeq: 10 PUBLISH
Call-ID: 3cce05ee326f011b-24523(a)127.0.0.1
Content-Length: 682
User-Agent: Sipwise NGCP Proxy 8.X
Max-Forwards: 70
Event: dialog
Expires: 23761
SIP-If-Match: a.1596025051.24523.1.0
Content-Type: application/dialog-info+xml
```
#### Log Messages
with db_mode == 0
```
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:406]: dialog_publish_multi(): CALLING dialog_publish for URI
sip:testuser1002@spce.test
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:255]: build_dialoginfo(): new_body:#012<?xml
version="1.0"?>#012<dialog-info
xmlns="urn:ietf:params:xml:ns:dialog-info" version="0"
state="full" entity="sip:testuser1002@spce.test">#012 <dialog
id="NGCP%invite_shared_line%///1-26774(a)127.126.0.1"
call-id="NGCP%invite_shared_line%///1-26774(a)127.126.0.1"
local-tag="26774SIPpTag001"
remote-tag="51E6E31F-5F2168FA000B8FF4-430B7700"
direction="initiator">#012 <state>early</state>#012
<remote>#012 <identity>sip:testuser1003@spce.test</identity>#012
<target uri="sip:127.0.0.1:5085;transport=udp"/>#012
</remote>#012 <local>#012
<identity>sip:testuser1002@spce.test</identity>#012 <target
uri="sip:testuser1002@127.126.0.1:51602"/>#012 </local>#012
</dialog>#012</dialog-info>#012
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:315]: dialog_publish(): publish uri= sip:testuser1002@spce.test
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:50]: print_publ(): publ:
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:51]: print_publ(): uri= sip:testuser1002@spce.test
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:52]: print_publ(): id=
DIALOG_PUBLISH.NGCP%invite_shared_line%///1-26774(a)127.126.0.1
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:53]: print_publ(): expires= 23760
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:498]:
send_publish(): pres_uri=sip:testuser1002@spce.test
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [hash.c:132]: search_htable():
core_hash= 322
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [hash.c:174]: search_htable():
no etag restriction
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [hash.c:183]: search_htable():
found record
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:587]:
send_publish(): record found
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:673]:
send_publish(): etag:a.1596025051.24523.1.0
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:106]:
publ_build_hdr(): UPDATE_TYPE [etag]= a.1596025051.24523.1.0
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:683]:
send_publish(): publ->pres_uri:#012sip:testuser1002@spce.test#012
Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:684]:
send_publish(): str_hdr:#012Max-Forwards: 70#015#012Event: dialog#015#012Expires:
23761#015#012SIP-If-Match: a.1596025051.24523.1.0#015#012Content-Type:
application/dialog-info+xml#015#012 130#012
```
with db_mode == 2
```
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:406]: dialog_publish_multi(): CALLING dialog_publish for URI
sip:testuser1002@spce.test
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:255]: build_dialoginfo(): new_body:#012<?xml
version="1.0"?>#012<dialog-info
xmlns="urn:ietf:params:xml:ns:dialog-info" version="0"
state="full" entity="sip:testuser1002@spce.test">#012 <dialog
id="NGCP%invite_shared_line%///1-8362(a)127.126.0.1"
call-id="NGCP%invite_shared_line%///1-8362(a)127.126.0.1"
local-tag="8362SIPpTag001"
remote-tag="18DEC3EE-5F2165A30000D6FF-42FB6700"
direction="initiator">#012 <state>early</state>#012
<remote>#012 <identity>sip:testuser1003@spce.test</identity>#012
<target uri="sip:127.0.0.1:5085;transport=udp"/>#012
</remote>#012 <local>#012
<identity>sip:testuser1002@spce.test</identity>#012 <target
uri="sip:testuser1002@127.126.0.1:51602"/>#012 </local>#012
</dialog>#012</dialog-info>#012
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo
[dialog_publish.c:315]: dialog_publish(): publish uri= sip:testuser1002@spce.test
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:50]:
print_publ(): publ:
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:51]:
print_publ(): uri= sip:testuser1002@spce.test
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:52]:
print_publ(): id= DIALOG_PUBLISH.NGCP%invite_shared_line%///1-8362(a)127.126.0.1
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:53]:
print_publ(): expires= 23760
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:498]:
send_publish(): pres_uri=sip:testuser1002@spce.test
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:564]:
send_publish(): insert type
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:568]:
send_publish(): UPDATE_TYPE and no record found
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:683]:
send_publish(): publ->pres_uri:#012sip:testuser1002@spce.test#012
Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:684]:
send_publish(): str_hdr:#012Max-Forwards: 70#015#012Event: dialog#015#012Expires:
23761#015#012Content-Type: application/dialog-info+xml#015#012 92#012
```
### Possible Solutions
I think the problem here is that on db_mode == 2 pua never search for the pua record if no
etag is set
change introduced at
https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb3…
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
This is Sipwise's kamailio version based on 5.3.5
```
version: kamailio 5.3.5 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST,
NO_SIG_DEBUG, 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_BLACKLIST, 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 8.3.0
```
--
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/2414
29 Jul
29 Jul
4:11 p.m.
@juha-h since you committed
https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb3…, can
you please comment why it was necessary?
Why on PUA_DB_ONLY there's no call to ``get_record_puadb``
https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb3…
--
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/2414#issuecomment-665654713
30 Jul
30 Jul
9:16 a.m.
Victor Seva writes:
@juha-h since you committed
https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb3…, can
you please comment why it was necessary?
I don't remember. It was long time ago. Perhaps there has been some
mailing list discussion related to the commit.
Why on PUA_DB_ONLY there's no call to
``get_record_puadb``
https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb3…
There is call to ``get_record_puadb``:
```
if (dbmode==PUA_DB_ONLY)
{
if (publ->etag) {
memset(&dbpres, 0, sizeof(dbpres));
dbpres.pres_uri = &pres_uri;
dbpres.watcher_uri = &watcher_uri;
dbpres.extra_headers = &extra_headers;
presentity = get_record_puadb(publ->id, publ->etag,
&dbpres, &res);
}
}
```
--
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/2414#issuecomment-666147074
10:02 a.m.
@juha-h
There is call to ``get_record_puadb``:
Well I mean if ``publ->etag`` is NULL, the previous behavior was to call it always
```
if (dbmode==PUA_DB_ONLY)
{
memset(&dbpres, 0, sizeof(dbpres))
dbpres.pres_uri = &pres_uri;
dbpres.watcher_uri = &watcher_uri;
dbpres.extra_headers = &extra_headers;
presentity = get_record_puadb(publ->id, publ->etag, &dbpres, &res);
}
```
--
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/2414#issuecomment-666170388
10:17 a.m.
https://lists.kamailio.org/pipermail/sr-users/2016-January/091492.html
pua - db_mode set to 0. This stops multiple states for
a single dialog (early, trying, confirmed and terminated) from showing in the presentity
table. I suspect this is a bug?
I still see this behavior and I think is related to this code since pua_dialoginfo never
sets etag when calling ``send_publish()``
--
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/2414#issuecomment-666180304
10:19 a.m.
Victor Seva writes:
@juha-h
I don't remember publish details, but if there is no etag, it is the
first publish and therefore it doesn't make sense to get the record from
db.
--
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/2414#issuecomment-666182388
There is call to ``get_record_puadb``:
Well I mean if ``publ->etag`` is NULL, the previous behavior was to
call it always
10:31 a.m.
Victor Seva writes:
https://lists.kamailio.org/pipermail/sr-users/2016-January/091492.html
Then isn't it a bug in pua_dialoginfo?
If I remember correctly, first PUBLISH is sent without SIP-If-Match
header (containing etag), then etag is obtained from 200 OK's SIP-ETag
header and placed in SIP-If-Match header of following PUBLISH 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/2414#issuecomment-666189711
pua - db_mode set to 0. This stops multiple
states for a single dialog (early, trying, confirmed and terminated) from showing in the
presentity table. I suspect this is a bug?
I still see this behavior and I think is related to this code since pua_dialoginfo never
sets etag when calling ``send_publish()``
10:43 a.m.
Then isn't it a bug in pua_dialoginfo?
I don't think so. The purpose of E-Tag is to identify a state of the resource. If the
resource changes a new E-Tag has to be generated. [Generating
Entity-tags](https://tools.ietf.org/html/rfc5839#page-20)
In this case, pua_dialoginfo is changing the state so a new E-Tag has to be generated and
the record in db in this case must be updated. Not insert a new one.
--
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/2414#issuecomment-666196311
10:58 a.m.
Victor Seva writes:
I don't think so. The purpose of E-Tag is to
identify a state of the
resource. If the resource changes a new E-Tag has to be
generated. [Generating
Entity-tags](https://tools.ietf.org/html/rfc5839#page-20)
That is about notifier behavior in subscribe/notify exchange and does
not deal with publish requests.
In this case, pua_dialoginfo is changing the state so
a new E-Tag has to be generated and the record in db in this case must be updated. Not
insert a new one.
--
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/2414#issuecomment-666205547
11:36 a.m.
Ok. Then it should be this one. https://tools.ietf.org/html/rfc3903#section-8.2
The ``SIP-If-Match`` is missing from any PUBLISH. pua is not doing the same depending on
db_mode.
Even if ``etag`` is not set we need to search for previous record. OK, first PUBLISH will
never have a record but the rest yes.
So, with db_mode == 0:
First PUBLISH
```
PUBLISH sip:testuser1002@spce.test SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK5b55.aee12144000000000000000000000000.0
To: <sip:testuser1002@spce.test>
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-441aa447
CSeq: 10 PUBLISH
Call-ID: 3cce05ee326f0119-24523(a)127.0.0.1
Content-Length: 577
User-Agent: Sipwise NGCP Proxy 8.X
Max-Forwards: 70
Event: dialog
Expires: 23761
Content-Type: application/dialog-info+xml
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0"
state="full" entity="sip:testuser1002@spce.test">
<dialog id="NGCP%invite_shared_line%///1-26774(a)127.126.0.1"
call-id="NGCP%invite_shared_line%///1-26774(a)127.126.0.1"
direction="initiator">
<state>Trying</state>
<remote>
<identity>sip:1003@spce.test</identity>
<target uri="sip:1003@spce.test"/>
</remote>
<local>
<identity>sip:testuser1002@spce.test</identity>
<target uri="sip:testuser1002@spce.test"/>
</local>
</dialog>
</dialog-info>
```
```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK5b55.aee12144000000000000000000000000.0
To: <sip:testuser1002@spce.test>;tag=f3067022b00c564156251ba2f28f331f-7286b99a
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-441aa447
CSeq: 10 PUBLISH
Call-ID: 3cce05ee326f0119-24523(a)127.0.0.1
Expires: 3600
SIP-ETag: a.1596025051.24523.1.0
Server: Sipwise NGCP Proxy 8.X
Content-Length: 0
```
second PUBLISH
```
PUBLISH sip:testuser1002@spce.test SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK5e55.d35147e4000000000000000000000000.0
To: <sip:testuser1002@spce.test>
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-84a3a447
CSeq: 10 PUBLISH
Call-ID: 3cce05ee326f011b-24523(a)127.0.0.1
Content-Length: 682
User-Agent: Sipwise NGCP Proxy 8.X
Max-Forwards: 70
Event: dialog
Expires: 23761
SIP-If-Match: a.1596025051.24523.1.0
Content-Type: application/dialog-info+xml
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0"
state="full" entity="sip:testuser1002@spce.test">
<dialog id="NGCP%invite_shared_line%///1-26774(a)127.126.0.1"
call-id="NGCP%invite_shared_line%///1-26774(a)127.126.0.1"
local-tag="26774SIPpTag001"
remote-tag="51E6E31F-5F2168FA000B8FF4-430B7700"
direction="initiator">
<state>early</state>
<remote>
<identity>sip:testuser1003@spce.test</identity>
<target uri="sip:127.0.0.1:5085;transport=udp"/>
</remote>
<local>
<identity>sip:testuser1002@spce.test</identity>
<target uri="sip:testuser1002@127.126.0.1:51602"/>
</local>
</dialog>
</dialog-info>
```
```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK5e55.d35147e4000000000000000000000000.0
To: <sip:testuser1002@spce.test>;tag=f3067022b00c564156251ba2f28f331f-7286b99a
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-84a3a447
CSeq: 10 PUBLISH
Call-ID: 3cce05ee326f011b-24523(a)127.0.0.1
Expires: 3600
SIP-ETag: a.1596025051.24523.3.1
Server: Sipwise NGCP Proxy 8.X
Content-Length: 0
```
But with db_mode == 2:
fist PUBLISH
```
PUBLISH sip:testuser1002@spce.test SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKbc38.a66034a3000000000000000000000000.0
To: <sip:testuser1002@spce.test>
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-245ea447
CSeq: 10 PUBLISH
Call-ID: 200464472a3c6cfb-497(a)127.0.0.1
Content-Length: 575
User-Agent: Sipwise NGCP Proxy 8.X
Max-Forwards: 70
Event: dialog
Expires: 23761
Content-Type: application/dialog-info+xml
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0"
state="full" entity="sip:testuser1002@spce.test">
<dialog id="NGCP%invite_shared_line%///1-2484(a)127.126.0.1"
call-id="NGCP%invite_shared_line%///1-2484(a)127.126.0.1"
direction="initiator">
<state>Trying</state>
<remote>
<identity>sip:1003@spce.test</identity>
<target uri="sip:1003@spce.test"/>
</remote>
<local>
<identity>sip:testuser1002@spce.test</identity>
<target uri="sip:testuser1002@spce.test"/>
</local>
</dialog>
</dialog-info>
```
```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKbc38.a66034a3000000000000000000000000.0
To: <sip:testuser1002@spce.test>;tag=f3067022b00c564156251ba2f28f331f-7286b99a
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-245ea447
CSeq: 10 PUBLISH
Call-ID: 200464472a3c6cfb-497(a)127.0.0.1
Expires: 3600
SIP-ETag: a.1596025403.497.1.0
Server: Sipwise NGCP Proxy 8.X
Content-Length: 0
```
second PUBLISH:
```
PUBLISH sip:testuser1002@spce.test SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK5c38.492e72e6000000000000000000000000.0
To: <sip:testuser1002@spce.test>
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-fad5a447
CSeq: 10 PUBLISH
Call-ID: 200464472a3c6cfd-497(a)127.0.0.1
Content-Length: 679
User-Agent: Sipwise NGCP Proxy 8.X
Max-Forwards: 70
Event: dialog
Expires: 23761
Content-Type: application/dialog-info+xml
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0"
state="full" entity="sip:testuser1002@spce.test">
<dialog id="NGCP%invite_shared_line%///1-2484(a)127.126.0.1"
call-id="NGCP%invite_shared_line%///1-2484(a)127.126.0.1"
local-tag="2484SIPpTag001"
remote-tag="0485C5EB-5F216A4A00017C06-431B8700"
direction="initiator">
<state>early</state>
<remote>
<identity>sip:testuser1003@spce.test</identity>
<target uri="sip:127.0.0.1:5085;transport=udp"/>
</remote>
<local>
<identity>sip:testuser1002@spce.test</identity>
<target uri="sip:testuser1002@127.126.0.1:51602"/>
</local>
</dialog>
</dialog-info>
```
```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK5c38.492e72e6000000000000000000000000.0
To: <sip:testuser1002@spce.test>;tag=f3067022b00c564156251ba2f28f331f-7286b99a
From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-fad5a447
CSeq: 10 PUBLISH
Call-ID: 200464472a3c6cfd-497(a)127.0.0.1
Expires: 3600
SIP-ETag: a.1596025403.497.3.0
Server: Sipwise NGCP Proxy 8.X
Content-Length: 0
```
--
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/2414#issuecomment-666228920
1:24 p.m.
I no longer see more than one record in pua table and PUBLISH now have the proper
``SIP-If-Match`` header matching the previous value in 200 OK
--
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/2414#issuecomment-666282596
4:37 p.m.
other side effect is that only the last record of DIALOG_PUBLISH.* gets removed properly
and the rest of records just are hanging there until max dialog duration time expires, by
default 3600 secs
--
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/2414#issuecomment-666369143
4:38 p.m.
Closed #2414 via 91d9441a242da4746171bfa532fa2378328e8d73.
--
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/2414#event-3603886239
9:10 p.m.
I cannot reproduce the issue. In my tests after the first publish the rest
do have SIP-If-Match header, for example:
```
T 2020/07/30 20:57:06.251465 127.0.0.1:50064 -> 127.0.0.1:5080 [AP] #20
PUBLISH sip:foo@test.tutpro.com SIP/2.0.
Via: SIP/2.0/TCP 192.168.43.82;branch=z9hG4bK549a.f9d86324000000000000000000000000.0.
To: <sip:foo@test.tutpro.com>.
From: <sip:foo@test.tutpro.com>;tag=ded145cd44a1108aee8ba0e30b80344c-7d4055df.
CSeq: 10 PUBLISH.
Call-ID: 24b1a5bf25ad843a-12771(a)192.168.43.82.
Content-Length: 94.
User-Agent: OpenSIPg SIP Proxy (5.4.0-0b01 (x86_64/linux)).
Max-Forwards: 70.
Event: message-summary.
Expires: 7776001.
SIP-If-Match: a.1594729867.26073.6.12.
Content-Type: application/simple-message-summary.
P-Flags: 0.
..
Messages-Waiting: yes.
Message-Account: sip:foo@vm.test.tutpro.com.
Voice-Message: 1/0 (0/0).
```
That happens because etag param is included in the json request:
```
Jul 30 20:57:06 char /usr/bin/sip-proxy[12771]: INFO: Executing JSON request
<{"jsonrpc":"2.0","method":"pua.publish","params":["sip:foo@test.tutpro.com","7776000","message-summary","application\/simple-message-summary",".","a.1594729867.26073.6.12","sip:127.0.0.1:5080;transport=tcp","P-Flags:
0\r\n","Messages-Waiting: yes\r\nMessage-Account:
sip:foo@vm.test.tutpro.com\r\nVoice-Message: 1\/0 (0\/0)\r\n"],"id":1}>
from <127.0.0.1> with host <127.0.0.1:6060>
```
Why can't pua_dialoginfo do the same?
--
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/2414#issuecomment-666573020
31 Jul
31 Jul
7:22 a.m.
Isn't it so that pua module send_publish function sends exactly such publish as
specified in its parameters? One of the parameters is etag. So if first or subsequent
publish requests contain SIP-If-Match header is up to what kind of parameters send_publish
has got.
--
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/2414#issuecomment-666909531
7:22 a.m.
Reopened #2414.
--
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/2414#event-3606791058
10:27 a.m.
Sorry @juha-h but I don't get your point.
If a pua_* module execute send_publish() and etag is not set pua has to search anyway for
that ``ua_pres_t`` in the db. So it would be updated. If not, we are getting a record for
every state, SIP-If-Match in later PUBLISH of the same dialog is missing and only the last
record gets removed when the dialog is finished.
All of that doesn't happen with
https://github.com/kamailio/kamailio/commit/da7f7ef082e28f81893ec06081358a9…
Every **pua_*** module that uses pua.send_publish() except **pua_rpc** doesn't set
etag parameter.
* **pua_bla**
* **pua_dialoginfo**
* **pua_usrloc**
* **pua_xmpp**
So I don't get what you want to achieve. This was a bug that users reported and I had
suffered.
--
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/2414#issuecomment-666977383
4:39 p.m.
Victor Seva writes:
All of that doesn't happen with
https://github.com/kamailio/kamailio/commit/da7f7ef082e28f81893ec06081358a9…
Every **pua_*** module that uses pua.send_publish() except **pua_rpc** doesn't set
etag parameter.
* **pua_bla**
* **pua_dialoginfo**
* **pua_usrloc**
* **pua_xmpp**
So I don't get what you want to achieve. This was a bug that users
reported and I had suffered.
Why don't these other modules keep track of the etag received from 200
ok to the initial publish and use it in subsequent ones?
Are you sure that the change you made does not have any negative
consequences to pua_rpc user that saves the etag from the initial
publish and uses it in subsequent ones?
May be there was some real reason when I made the commit many years
ago.
--
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/2414#issuecomment-667124637
6:09 p.m.
Are you sure that the change you made does not have any
negative
consequences to pua_rpc user that saves the etag from the initial
publish and uses it in subsequent ones?
I cannot be sure 100% but from what I understand if you set etag... it has the same
behavior than previously.
If is the first PUBLISH, there's no record, so no changes in logic.
Change is merged already do you detect any regression?
--
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/2414#issuecomment-667170220
6:19 p.m.
Victor Seva writes:
I cannot be sure 100% but from what I understand if
you set etag... it has the same behavior than previously.
If is the first PUBLISH, there's no record, so no changes in logic.
Change is merged already do you detect any regression?
I can test when the merge is backported to 5.4, since I don't at present
have a live master system.
2 Aug
2 Aug
5:22 p.m.
Juha Heinanen writes:
Victor Seva writes:
I installed latest master and looks like pua_rpc pua_publish with
explicit etag args works OK.
-- Juha
I cannot be sure 100% but from what I understand
if you set etag... it has the same behavior than previously.
If is the first PUBLISH, there's no record, so no changes in logic.
Change is merged already do you detect any regression?
I can test when the merge is backported to 5.4, since I don't at present
have a live master system.
3 Aug
3 Aug
10:22 a.m.
Closed #2414.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2414#event-3614604803
1601
days inactive
1606
days old
21 comments
3 participants
participants (3)
-
Juha Heinanen -
juha-h -
Victor Seva