### 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@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@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@127.126.0.1" call-id="NGCP%invite_shared_line%///1-26774@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@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@127.126.0.1" call-id="NGCP%invite_shared_line%///1-8362@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@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/6822ff45e931ad3e93b22ebf7d1beb35...
### 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 ```
@juha-h since you committed https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb35..., 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/6822ff45e931ad3e93b22ebf7d1beb35...
Victor Seva writes:
@juha-h since you committed https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb35..., 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/6822ff45e931ad3e93b22ebf7d1beb35...
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); } } ```
@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); } ```
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()``
Victor Seva writes:
@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
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.
Victor Seva writes:
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()``
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.
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.
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.
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@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@127.126.0.1" call-id="NGCP%invite_shared_line%///1-26774@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@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@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@127.126.0.1" call-id="NGCP%invite_shared_line%///1-26774@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@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@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@127.126.0.1" call-id="NGCP%invite_shared_line%///1-2484@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@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@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@127.126.0.1" call-id="NGCP%invite_shared_line%///1-2484@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@127.0.0.1 Expires: 3600 SIP-ETag: a.1596025403.497.3.0 Server: Sipwise NGCP Proxy 8.X Content-Length: 0 ```
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
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
Closed #2414 via 91d9441a242da4746171bfa532fa2378328e8d73.
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@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?
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.
Reopened #2414.
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/da7f7ef082e28f81893ec06081358a9f...
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.
Victor Seva writes:
All of that doesn't happen with https://github.com/kamailio/kamailio/commit/da7f7ef082e28f81893ec06081358a9f...
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.
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?
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.
Juha Heinanen writes:
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.
I installed latest master and looks like pua_rpc pua_publish with explicit etag args works OK.
-- Juha
Closed #2414.
-
Juha Heinanen -
juha-h -
Victor Seva