Re: [sr-dev] [kamailio/kamailio] LCR stopper flag doesn't allow load balance of multiple identical rules (#2105)

[juha-h]

You should not use identical rules.  Instead use one stopper rule with two 
gateways (rule targets).

-- 
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/2105#issuecomment-544393723___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] db_mysql: docs for opt_ssl_mode parameter (f012c52)

[juha-h]

This appears in README as its own section 4.  Should it be among other 
parameters as a section 3 subsection?


-- 
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/commit/f012c525264ed05fec2acb4b3924d4b9a1cd3ab9#commitcomment-40062216___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

[juha-h]

Victor Seva writes:

> @juha-h since you committed 
> https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb350bf27e70,
>  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/6822ff45e931ad3e93b22ebf7d1beb350bf27e70#diff-0c68f4211a54ae66988228c3e4b61852R521-R528

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___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

[juha-h]

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.


-- 
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___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

[juha-h]

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.


-- 
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___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

[juha-h]

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___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

[juha-h]

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:f...@test.tutpro.com SIP/2.0.
Via: SIP/2.0/TCP 
192.168.43.82;branch=z9hG4bK549a.f9d86324.0.
To: .
From: ;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:f...@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:f...@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:f...@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___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

[juha-h]

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___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

[juha-h]

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___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

[juha-h]

Victor Seva writes:

> All of that doesn't happen with 
> https://github.com/kamailio/kamailio/commit/da7f7ef082e28f81893ec06081358a9f88571bcc
> 
> 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___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: export rule_id_avp with matching rule id (#1546)

[juha-h]

Merged #1546.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1546#event-1648672279___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] debian pkg missing dependency on docbook2x (#1624)

[juha-h]

Kamailio master build on Debian Stretch fails due to missing dependency on 
docbook2x.  See 
https://lists.kamailio.org//pipermail/sr-dev/2018-August/047549.html for more 
info.

-- 
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/1624___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] debian pkg missing dependency on docbook2x (#1624)

[juha-h]

Victor Seva writes:

> We have no problems with the nightly builds, example:
> https://kamailio.sipwise.com/job/kamailiodev-nightly-binaries/architecture=amd64,distribution=stretch,label=slave/1171/consoleText

For sure you have.  Exactly the same problem that I described:

mkdir -p 
/tmp/buildd/kamailio-5.2.0~dev6+0~20180823005931.1186+stretch/debian/kamailio/usr/share/man//man5
s ../../../doc/stylesheets/serdoc2man.xsl auth.xml
make[3]: s: Command not found
../../Makefile.modules:283: recipe for target 'auth.7' failed
make[3]: [auth.7] Error 127 (ignored)
s ../../../doc/stylesheets/serdoc2man.xsl avp.xml
make[3]: s: Command not found
../../Makefile.modules:283: recipe for target 'avp.7' failed
make[3]: [avp.7] Error 127 (ignored)


-- 
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/1624#issuecomment-415392440___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] debian pkg missing dependency on docbook2x (#1624)

[juha-h]

This clearly is a bug.  I don't understand why bug label was removed. Also, I 
my opinion this kind of error should not be ignored, but build should stop at 
it.

-- 
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/1624#issuecomment-417585090___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] debian pkg missing dependency on docbook2x (#1624)

[juha-h]

Daniel-Constantin Mierla writes:

> I think this should be made optional properly. I do not think anyone
> was using manpage-style docs so far for modules and starting now to
> install/package them all makes no sense.

Optional is fine with me.  I just want the build to work without
errors.   Also, if an error occurs, the build must stop,  This is not
the case now.

-- Juha


-- 
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/1624#issuecomment-417618299___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] debian pkg missing dependency on docbook2x (#1624)

[juha-h]

Daniel-Constantin Mierla writes:

> I will close this issue and if one wants to package man pages for
> modules' readme, open a feature request. To my knowledge, so far they
> were never packaged. If some new issues after the patch, just reopen.

Thanks, debian package now built OK without docbook2x.

-- Juha


-- 
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/1624#issuecomment-417688685___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] support usrloc handle_lost_tcp variable also in DB-Only scheme (#171)

[juha-h]

Daniel-Constantin Mierla writes:

> This should be possible now by using tcpops and sqlops modules --
> delete in db tables using sqlops with connection id inside the event
> route for tcp connection close:
> 
>   * 
> https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#idp24331996

Thanks, Juha


-- 
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/171#issuecomment-418263080___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] jsonrpc reply error (#1640)

[juha-h]

When I execute pua.publish over jsonrpc using pretty new Kamailio master:

#
T 2018/09/11 18:19:03.550376 127.0.0.1:44190 -> 127.0.0.1:6060 [AP]
POST /RPC HTTP/1.1.
Host: 127.0.0.1:6060.
Accept: */*.
Content-Type: application/json.
Content-Length: 339.
..
{"jsonrpc":"2.0","method":"pua.publish","params":[...],"id":1}

#
T 2018/09/11 18:19:03.551735 127.0.0.1:5070 -> 127.0.0.1:5080 [AP]
PUBLISH sip:t...@test.tutpro.com SIP/2.0.
...

#
T 2018/09/11 18:19:03.553158 127.0.0.1:5080 -> 127.0.0.1:5070 [AP]
SIP/2.0 200 OK.
...
CSeq: 10 PUBLISH.

#
T 2018/09/11 18:19:03.556790 127.0.0.1:6060 -> 127.0.0.1:44190 [AP]
HTTP/1.1 200 OK.
Sia: SIP/2.0/TCP 127.0.0.1:44190.
Content-Type: application/json.
Server: OpenSIPg SIP Proxy (5.2.0-0b02 (x86_64/linux)).
Content-Length: 48.
..
{
."jsonrpc":."2.0",
."result":.{
.},
."id":.1
}

I get error at reply:

Sep 11 18:19:03 char /usr/bin/sip-proxy[11079]: ERROR: jsonrpcs 
[jsonrpcs_mod.c:778]: jsonrpc_struct_add(): reply object not initialized in rpl 
context
Sep 11 18:19:03 char /usr/bin/sip-proxy[11079]: ERROR: jsonrpcs 
[jsonrpcs_mod.c:778]: jsonrpc_struct_add(): reply object not initialized in rpl 
context



-- 
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/1640___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] jsonrpc reply error (#1640)

[juha-h]

The error message is now gone,  Thanks.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1640#issuecomment-420517113___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] jsonrpc reply error (#1640)

[juha-h]

Closed #1640.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1640#event-1840186627___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] AUTH_USERNAME_EXPIRED auth api return code (#1910)

[juha-h]

This pull request adds AUTH_USERNAME_EXPIRED auth api return code and uses it 
in ephemeral authentication when username has expired.  Script can then tell 
the user about the expiration with a suitable response.
You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/1910

-- Commit Summary --

  * - added AUTH_USERNAME_EXPIRED auth api return code and used it in auth

-- File Changes --

M src/modules/auth/api.h (1)
M src/modules/auth_ephemeral/authorize.c (26)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/1910.patch
https://github.com/kamailio/kamailio/pull/1910.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/1910
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: enhance the lcr.dump_rules with filtering params: (#1922)

[juha-h]

Looks good.  Could you also update the doc (lcr_admin.xml).

-- 
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/1922#issuecomment-479770104___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] rtpengine module set_rtpengine_set(set1, set2) issue (#2039)

[juha-h]

My Kamailio master based test sip proxy has two rtpengine sets:
```
# sip-proxy_ctl rtpengine.show all
{
url: udp:192.26.134.1:6050
set: 0
index: 0
weight: 1
disabled: 0
recheck_ticks: 0
}
{
url: udp:192.26.134.40:6050
set: 1
index: 1
weight: 1
disabled: 0
recheck_ticks: 0
}
```
Config calls set_rtpengine_set() with two set argument followed by 
rtpengine_offer():
```
set_rtpengine_set("1", "0");
rtpengine_offer("...");
```
Debug shows that sip proxy sends TWO offer commands to the
rtpproxy in the first set 1 and NONE to the rtpproxy in the second set 0.  

Debug at set 1 engine:
```
Aug 19 18:06:08 buster-10-0 rtpengine[1314]: NOTICE: [5e1407211cc50fd9]: 
Creating new call
Aug 19 18:06:08 buster-10-0 rtpengine[1314]: INFO: [5e1407211cc50fd9]: Replying 
to 'offer' from 192.26.134.1:33284 (elapsed time 0.000812 sec)
Aug 19 18:06:08 buster-10-0 rtpengine[1314]: INFO: [5e1407211cc50fd9]: Received 
command 'offer' from 192.26.134.1:33284
Aug 19 18:06:08 buster-10-0 rtpengine[1314]: INFO: [5e1407211cc50fd9]: Replying 
to 'offer' from 192.26.134.1:33284 (elapsed time 0.005247 sec)
```
This looks like a bug to me, since according to README, rtpengine should first 
send the offer to an engine in the first set and then to an engine in the 
second set.

-- 
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/2039___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] rtpengine module set_rtpengine_set(set1, set2) issue (#2039)

[juha-h]

I added some INFO call to  set_rtpengine_set_f():
```INFO("set1/set2 = %u/%u\n", selected_rtpp_set_1->id_set,
 selected_rtpp_set_2->id_set);

return 1;
```
and it correctly printed:
```
Aug 22 17:20:47 salmon /usr/bin/sip-proxy[29734]: INFO: set_rtpengine_set(1, 0)
```
Then I added INFO call to set_rtpengine_set_from_avp():
```
if ((setid_avp_param == NULL) ||
   (avp = search_first_avp(setid_avp_type, setid_avp, &setid_val, 0)) 
== NULL) {
if (direction == 1 || !selected_rtpp_set_2)
active_rtpp_set = selected_rtpp_set_1;
else
active_rtpp_set = selected_rtpp_set_2;
LM_INFO("active_rttp_set = %u\n", active_rtpp_set->id_set);
return 1;
}
```
and it showed that first active set is 1 and second is 0:
```
Aug 22 17:20:47 salmon /usr/bin/sip-proxy[29734]: INFO: rtpengine 
[rtpengine.c:3169]: set_rtpengine_set_from_avp(): active_rttp_set = 1
Aug 22 17:20:47 salmon /usr/bin/sip-proxy[29734]: INFO: rtpengine 
[rtpengine.c:3169]: set_rtpengine_set_from_avp(): active_rttp_set = 0
```
Still both offers are sent to engine in set 1.


-- 
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/2039#issuecomment-523930224___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] rtpengine module set_rtpengine_set(set1, set2) issue (#2039)

[juha-h]

I think I found where the bug is. In select_rtpp_node() function there is this 
function call:
``` // lookup node
node = select_rtpp_node_old(callid, viabranch, do_test, op);
```
When select_rtpp_node() is called second time,  active_rttp_set is set2, but 
select_rtpp_node_old() returns the previous node from set1 and a node from set2 
is not selected.



-- 
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/2039#issuecomment-523948555___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] rtpengine module set_rtpengine_set(set1, set2) issue (#2039)

[juha-h]

I made this kind of patch and it seems to work in my tests, but I may have 
missed something.
```
unsigned int node_in_set(struct rtpp_node *node, struct rtpp_set *set) {
struct rtpp_node *current = set->rn_first;
while (current) {
if (current->idx == node->idx) return 1;
current = current->rn_next;
}
return 0;
}
```
```
static struct rtpp_node * select_rtpp_node(...) {
...
   // lookup node
node = select_rtpp_node_old(callid, viabranch, do_test, op);

// check node
if (!node || (node_in_set(node, active_rtpp_set) == 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/2039#issuecomment-523965844___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] modules/rtpengine: set_rtpengine_set fix (#2040)

[juha-h]

WIthout this fix, set_rtpengine_set(set1, set2) sets set1 twice and set2 not at 
all.


You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/2040

-- Commit Summary --

  * modules/rtpengine: set_rtpengine_set fix

-- File Changes --

M src/modules/rtpengine/rtpengine.c (11)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/2040.patch
https://github.com/kamailio/kamailio/pull/2040.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/2040
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] modules/rtpengine: set_rtpengine_set fix (#2040)

[juha-h]

Daniel-Constantin Mierla writes:

> Thanks! Maybe @rfuchs wants to do a review before merging.

Sure, lets wait his review.  Looks like no-one has ever used that
feature before.


-- 
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/2040#issuecomment-524354809___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] modules/rtpengine: set_rtpengine_set fix (#2040)

[juha-h]

Merged #2040 into master.

-- 
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/2040#event-2584612402___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] modules/rtpengine: set_rtpengine_set fix (#2040)

[juha-h]

Thanks for the review.

-- 
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/2040#issuecomment-524980037___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] rtpengine module set_rtpengine_set(set1, set2) issue (#2039)

[juha-h]

Closed #2039.

-- 
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/2039#event-2584666320___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] rtpengine module set_rtpengine_set(set1, set2) issue (#2039)

[juha-h]

Fixed by https://github.com/kamailio/kamailio/pull/2040.

-- 
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/2039#issuecomment-524987390___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] Branch ordering behavior changed between v5.3 and v5.4 (#2449)

[juha-h]

Daniel-Constantin Mierla writes:

> Also, maybe @juha-h can comment on this issue, being the initial
> developer of these functions, to see what is the expected behaviour
> and if there is an unwanted change in the last version.

Version of tm README before mode param was added tells what the expected
behavior of t_load_contacts() is:

   Function t_load_contacts() removes all branches from the current
   destination set and stores them into the XAVP whose name is configured
   with the parameter contacts_avp.
   ...
   If the current destination set contains more than one branch, the
   function sorts them according to increasing value of the q parameter
   and then stores the branches in reverse order into the XAVP.

   The q parameter of a branch contains a value from range 0-1.0 and it
   expresses relative preference of the branch among all branches in the
   destination set. The higher the q value the more preference the user
   agent gave to the branch. Branches with higher q values will be tried
   before branches with lower ones when serial forking takes place.

If the behavior is not that anymore, there is a bug that needs to be
fixed.







-- 
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/2449#issuecomment-679083935___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] sqlops sql_query() function result value has not been documented in README (#2454)

[juha-h]

README should tell that:

- 1 is returned when query succeeds and result set is not empty
- 2 is returned when query succeeds but result set is not empty
- 3 is returned when result set is not empty, but result param was not given
- -1 is returned in case of error


-- 
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/2454___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] sqlops sql_query() function result value has not been documented in README (#2454)

[juha-h]

Actually, return values were described in the beginning of functions section.  
One value was missing and I added it.

-- 
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/2454#issuecomment-680157264___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] sqlops sql_query() function result value has not been documented in README (#2454)

[juha-h]

Closed #2454.

-- 
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/2454#event-3691126920___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] keepalive.list crash (#2618)

[juha-h]

With Kamalio master, RPC command keepalive.list causes crash (at least when 
there is nothing in the list). 

gdb) bt full
#0  rpc_struct_add (s=0x560b4df75830, fmt=0x7f2da23322c3 "SS") at 
binrpc_run.c:1092
ap = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 
0x7ffebd54cfc0, 
reg_save_area = 0x7ffebd54ced0}}
err = -1118515440
avp = {name = {s = 0x7f2da23322bf "uri", len = 3}, type = 1, u = 
{strval = {s = 0x0, 
  len = 0}, fval = 0, intval = 0, end = 0}}
rs = 0x7ffebd54d0e0
__func__ = "rpc_struct_add"
#1  0x7f2da2322776 in keepalive_rpc_list (rpc=0x7f2da2f022e0 
, 
ctx=0x7ffebd54d0e0) at keepalive_rpc.c:86
sub = 0x560b4df75830
dest = 0x1
t_buf = '\000' 
#2  0x7f2da2ecc993 in process_rpc_req (
buf=0x560b4df55784 "\241\003\021'\332D}\221\017keepalive.list", size=24, 
bytes_needed=0x7ffebd54d1e8, sh=0x7ffebd54d250, saved_state=0x560b4df65788)
at binrpc_run.c:683
err = 0
val = {name = {s = 0x7ffebd54d1c0 " \323T\275\376\177", len = 
-1561476359}, type = 1, 
  u = {strval = {s = 0x560b4df5578d "keepalive.list", len = 14}, 
fval = 4.6741847488088159e-310, intval = 1307924365, end = 
1307924365}}
rpc_e = 0x7f2da3c91910
f_ctx = {in = {ctx = {tlen = 17, cookie = 668615805, type = 0, flags = 
1, 
  offset = 17, in_struct = 0, in_array = 0}, s = 0x560b4df5579c "", 
end = 0x560b4df5579c "", record_no = 0, in_struct = 0}, out = {pkt 
= {
  body = 0x560b4df65820 "\003\203", end = 0x560b4df75820 "", 
  crt = 0x560b4df65822 ""}, structs = {next = 0x560b4df75830, 
  prev = 0x560b4df75830}}, send_h = 0x7ffebd54d250, 
  method = 0x560b4df5578d "keepalive.list", gc = 0x0, replied = 0, 
err_code = 0, 
--Type  for more, q to quit, c to continue without paging-- 
  err_phrase = {s = 0x0, len = 0}}
ctx = 0x7ffebd54d0e0
__func__ = "process_rpc_req"
#3  0x7f2da2ee9ae9 in handle_stream_read (s_c=0x560b4df55750, idx=-1) at 
io_listener.c:511
bytes_free = 65535
bytes_read = 24
bytes_needed = 1307733728
bytes_processed = 22027
r = 0x560b4df55770
sh = {fd = 15, type = 0, from = {sa_in = {s = {sa_family = 0, 
sa_data = 
"\000\000\000\000\000\000\001\000\377\377\377\377\377\377"}, sin = {
sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, 
sin_zero = "\001\000\377\377\377\377\377\377"}, sin6 = 
{sin6_family = 0, 
sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {
__u6_addr8 = "\001\000", '\377' , 
__u6_addr16 = {1, 
  65535, 65535, 65535, 65535, 65535, 65535, 65535}, 
__u6_addr32 = {
  4294901761, 4294967295, 4294967295, 4294967295}}}, 
sin6_scope_id = 0}, 
  sas = {ss_family = 0, 
__ss_padding = "\000\000\000\000\000\000\001\000", '\377' 
, '\000' , 
"\001\000\000\000\000\000\000\000\260:\n\232-\177", '\000' , 
"\340\322T\275\001\000\000\000\260:\n\232-\177\000\000\340\322T\275\376\177\000\000\231{\355\242-\177\000\000\000\000\300\000\000\000\000\000\260:\n\232-\177\000",
 
__ss_align = 10513424}}, sa_un = {sun_family = 0, 
  sun_path = "\000\000\000\000\000\000\001\000", '\377' , '\000' , 
"\001\000\000\000\000\000\000\000\260:\n\232-\177", '\000' , 
"\340\322T\275\001\000\000\000\260:\n\232-\177\000\000\340\322T\275\376\177\000\000\231{\355\242-\177\000\000\000\000\300\000\000"}},
 from_len = 0}
__func__ = "handle_stream_read"
#4  0x7f2da2eeb870 in handle_io (fm=0x7f2da3ca38a8, events=1, idx=-1) at 
io_listener.c:706
--Type  for more, q to quit, c to continue without paging--
ret = 1
__func__ = "handle_io"
#5  0x7f2da2ee2092 in io_wait_loop_epoll (h=0x7f2da2f02380 , 
t=10, repeat=0)
at ../../core/io_wait.h:1070
n = 1
r = 0
fm = 0x7f2da3ca38a8
revents = 1
__func__ = "io_wait_loop_epoll"
#6  0x7f2da2ee6707 in io_listen_loop (fd_no=1, cs_lst=0x560b4df26ee0) at 
io_listener.c:281
max_fd_no = 295
poll_err = 0x0
poll_method = 2
cs = 0x0
type = 2
__func__ = "io_listen_loop"
#7  0x7f2da2ef1aa2 in mod_child (rank=0) at ctl.c:338
pid = 0
cs = 0x7f2d9a0a2850
rpc_handler = 1
__func__ = "mod_child"
#8  0x560b4d8349f7 in init_mod_child (m=0x7f2da3cc0370, rank=0) at 
core/sr_module.c:827
__func__ = "init_mod_child"
#9  0x560b4d834612 in init_mod_child (m=0x7f2da3cc07a0, rank=0) at 
core/sr_module.c:823
__func__ = "init_mod_child"
#10 0x560b4d834612 in init_mod_child (m=0x7f2da3cc0ad0, rank=0) at 
core/sr_module.c:823
__func__ = "init_mod_child"
#11 0x560b4d834612 in init_mod_child (m=0x7f2da3cc12b0, rank=0) at 
core/sr_module.c:823
__func__ = "

Re: [sr-dev] [kamailio/kamailio] keepalive.list crash (#2618)

[juha-h]

For some reason destination list is allocated with one uninitialized  item 
already in it:
```
int ka_alloc_destinations_list()
{
if(ka_destinations_list != NULL) {
LM_DBG("ka_destinations_list already allocated\n");
return 1;
}

ka_destinations_list = (ka_destinations_list_t *)shm_malloc(
sizeof(ka_destinations_list_t));
```
It may be the source of trouble when keepalive_rpc_list tries to list it:
```
static void keepalive_rpc_list(rpc_t *rpc, void *ctx)
{
void *sub;
ka_dest_t *dest;
char t_buf[26] = {0};

for(dest = ka_destinations_list->first; dest != NULL; dest = 
dest->next) {
```



-- 
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/2618#issuecomment-771830462___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] keepalive.list crash (#2618)

[juha-h]

Closed #2618.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2618#event-4296761945___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] keepalive.add hangs (#2625)

[juha-h]

Trying to add first item to keepalive list using rpc command hangs, for example
```
kamailio_ctl> keepalive.add sip:example.com:5060 test
```


-- 
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/2625___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] keepalive.add hangs (#2625)

[juha-h]

Closed #2625.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2625#event-4318651859___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] add_rr_param() call has no effect after record_route_preset() call (#2634)

[juha-h]

R-R URI parameters do not get added to outgoing R-R header(s) when 
add_rr_param() call is made after record_route_preset() call.

I don't know if this a bug or a feature, but it would be very useful if 
add_rr_param() would work same way after record_route_preset() as it works 
after record_route().


-- 
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/2634___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add_rr_param() call has no effect after record_route_preset() call (#2634)

[juha-h]

Checked and in OpenSIPS add_rr_param() works also after record_route_preset(). 
It may not be a bug in K, since r-r code has evolved quite a bit in OpenSIPS 
and now supports it.

-- 
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/2634#issuecomment-777569327___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add_rr_param() call has no effect after record_route_preset() call (#2634)

[juha-h]

Fixed by 
https://github.com/kamailio/kamailio/commit/76b886da8ddf11a94a62850c19bad8c83bd113fc

-- 
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/2634#issuecomment-777587369___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add_rr_param() call has no effect after record_route_preset() call (#2634)

[juha-h]

Closed #2634.

-- 
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/2634#event-4320536416___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Added ; sn param check to loose.c is_myself() (#2643)

[juha-h]

Added ;sn param check to loose.c is_myself() so that loose_route() would 
recognize such a Route URI denoting itself.
You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/2643

-- Commit Summary --

  * Added ;sn param check to loose.c is_myself()

-- File Changes --

M src/modules/rr/loose.c (27)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/2643.patch
https://github.com/kamailio/kamailio/pull/2643.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/2643
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] Added ; sn param check to loose.c is_myself() (#2643)

[juha-h]

Daniel-Constantin Mierla writes:

> The commit message first line has to start with the name of the module
> ("rr: ...") like per contributing guide: 
> 
>   * 
> https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md#commit-message-format
> 
> It is important for generating changelogs and releases. I made a
> similar remark to your latest commit as well.

OK, will add if this leads to anywhere.

> Then, related to the commit itself, `myself` matching is related to
> routing address (ip/domain) matching of the server, this should be the
> default behaviour. Otherwise, on this case, it can happen that is
> matching headers added by another node using same socket names, which
> can have unexpected side effects in processing .

If such conflicts can happen or not, depends on the proxy deployment
environment.

> Personally I do not really see the need for what this patch brings,
> because you can specify the domains associated with the sever on
> several ways: config alias parameters, domain module (with register
> myself) for dynamic or large number of domains and corex module for
> subdomains.

In multi-tenant setup, MS Teams does not know which tenant INVITE from
Kamailio tries to reach if first R-R URI does not contain FQDN of the
tenant and, like everyone knows, MS does not care sh*t about standards
compatibility.  So the FQDN needs to be there and also loose_route()
needs to work.  I don't think that the other options you mention in the
above can help here.

> However, I am fine to add the behaviour of the patch, but controlled
> by a new rr module parameter (e.g, myself_mode) , default being
> disabled (e.g., myself_mode=0) so the match is done like so far, on
> address elements only.

OK, I'll try to add if the patch otherwise is OK.

-- Juha


-- 
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/2643#issuecomment-782832420___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] Added ; sn param check to loose.c is_myself() (#2643)

[juha-h]

Daniel-Constantin Mierla writes:

> What I said that the list of FQDNs for tenants can be specified via
> alias global params, corex or domain modules to Kamailio, then this
> patch is not needed, the loose route should do its job. It is
> irrelevant for what loose route is supposed to do that you need it to
> interconnect with MS Teams.

I'll give corex alias_subdomains a try and close the pull request if it
works as expected.

--- Juha


-- 
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/2643#issuecomment-782841064___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] Added ; sn param check to loose.c is_myself() (#2643)

[juha-h]

Can be replaced by corex alias_subdomains.

-- 
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/2643#issuecomment-782843733___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] Added ; sn param check to loose.c is_myself() (#2643)

[juha-h]

Closed #2643.

-- 
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/2643#event-4356256325___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] add ca_path param to tls module (#2682)

[juha-h]

Currently tls module has `ca_list` param that

`Sets the CA list file name. This file contains a list of all the trusted CAs 
certificates used when connecting to other SIP implementations. If a signature 
in a certificate chain belongs to one of the listed CAs, the verification of 
that certificate will succeed.` 

This issue proposes adding a new tls param `ca_path`.  Its value would be a 
directory that contains any number of CA certificate files thus making it 
unnecessary to cat these files to a single `ca_list` file.

Implementation could be based on SSL_CTX_set_default_verify_dir() OpenSSL API 
function.

-- 
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/2682___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add ca_path param to tls module (#2682)

[juha-h]

Thanks for your work on ca_path. It is so that currently ca_path can
only be given as tls module config parameter and not in tls config
file.   I tried like this:

modparam("tls", "config", "/etc/sip-proxy/tls.cfg")

tls.cfg:

[server:default]
verify_certificate = yes
require_certificate = no
server_name = lohi.tutpro.com
tls_method = TLSv1.1+
private_key = /etc/sip-proxy/certs/key.pem
certificate = /etc/sip-proxy/certs/cert.pem
ca_path = /etc/sip-proxy/certs/ca_list

and got error at start:

Mar 23 11:47:18 lohi /usr/bin/sip-proxy[25175]: ERROR:  
[core/cfg_parser.c:731]: sr_cfg_parse(): tls.cfg:7:1: Unsupported option 
'ca_path'


-- 
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/2682#issuecomment-804768330___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add ca_path param to tls module (#2682)

[juha-h]

Looks like installation of new version of kamailio had failed and tls
module was not updated.  Trying again ...


-- 
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/2682#issuecomment-804775191___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add ca_path param to tls module (#2682)

[juha-h]

Daniel-Constantin Mierla writes:

> The error message seems to be related to failure to open `ca_list`
> file, not to `ca_path` -- can you check if `ca_list` is still set
> somewhere there to an invalid file path?

I checked and config file has only this:

modparam("tls", "config", "/etc/sip-proxy/tls.cfg")

and tls.cfg contains:

# more tls.cfg
[client:default]
verify_certificate = yes
require_certificate = yes
tls_method = TLSv1.2+
private_key = /etc/sip-proxy/certs/key.pem
certificate = /etc/sip-proxy/certs/cert.pem
ca_path = /etc/sip-proxy/certs/ca_list

[server:default]
verify_certificate = yes
require_certificate = no
server_name = lohi.tutpro.com
tls_method = TLSv1.1+
private_key = /etc/sip-proxy/certs/key.pem
certificate = /etc/sip-proxy/certs/cert.pem
ca_path = /etc/sip-proxy/certs/ca_list

There is no trace of ca_list anywhere.  Also syslog shows that ca_list
is null:

Mar 23 13:19:03 lohi /usr/bin/sip-proxy[13983]: INFO: tls [tls_domain.c:322]: 
ksr_tls_fill_missing(): TLSs: 
certificate='/etc/sip-proxy/certs/cert.pem'
Mar 23 13:19:03 lohi /usr/bin/sip-proxy[13983]: INFO: tls [tls_domain.c:329]: 
ksr_tls_fill_missing(): TLSs: ca_list='(null)'
Mar 23 13:19:03 lohi /usr/bin/sip-proxy[13983]: INFO: tls [tls_domain.c:336]: 
ksr_tls_fill_missing(): TLSs: ca_path='/etc/sip-proxy/certs/ca_list'


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2682#issuecomment-804822963___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add ca_path param to tls module (#2682)

[juha-h]

Daniel-Constantin Mierla writes:

> Being Kamailio specific coding, I added the config option and set it
> value as parameter to SSL_CTX_load_verify_locations() based on the
> feature request description, but it might not be complete
> implementation because its manual specify that the folder content is
> not send to client via SSL_CTX_set_client_CA_list(): 
> 
>   * 
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_load_verify_locations.html

Neither is contents of CAfile sent to client:

  In server mode, when requesting a client certificate, the server must
  send the list of CAs of which it will accept client certificates. This
  list is not influenced by the contents of CAfile or CApath and must
  explicitly be set using the SSL_CTX_set_client_CA_list(3) family of
  functions.

-- Juha


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2682#issuecomment-804840617___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add ca_path param to tls module (#2682)

[juha-h]

Daniel-Constantin Mierla writes:

> As I said, I added the parameter based on the description of the
> feature request, but the manual suggested it might not be enough when
> acting as a tls server, see my first comment above. 
> 
> Probably works when it acts as a client (when opens the connection).

Yes, it does work as client.  I have two kamailios A - B using TLS between
them. When A uses ca_path and B uses ca_list, A can connect to B without
errors.  But when I change also B to use ca_path, I get errors on both.

On A:
Mar 23 15:32:58 lohi /usr/bin/sip-proxy[18482]: ERROR: tls [tls_server.c:1283]: 
tls_h_read_f(): protocol level error
Mar 23 15:32:58 lohi /usr/bin/sip-proxy[18482]: ERROR: tls [tls_util.h:42]: 
tls_err_ret(): TLS read:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert 
unknown ca
Mar 23 15:32:58 lohi /usr/bin/sip-proxy[18482]: ERROR: tls [tls_server.c:1287]: 
tls_h_read_f(): source IP: 192.26.134.10
Mar 23 15:32:58 lohi /usr/bin/sip-proxy[18482]: ERROR: tls [tls_server.c:1290]: 
tls_h_read_f(): destination IP: 192.168.43.160

On B:
 Mar 23 15:32:58 buster /usr/bin/sip-proxy[2266]: ERROR: tls 
[tls_server.c:1283]: tls_h_read_f(): protocol level error
Mar 23 15:32:58 buster /usr/bin/sip-proxy[2266]: ERROR: tls [tls_util.h:42]: 
tls_err_ret(): TLS accept:error:1417C086:SSL 
routines:tls_process_client_certificate:certificate verify failed
Mar 23 15:32:58 buster /usr/bin/sip-proxy[2266]: ERROR: tls 
[tls_server.c:1287]: tls_h_read_f(): source IP: 192.168.43.160
Mar 23 15:32:58 buster /usr/bin/sip-proxy[2266]: ERROR: tls 
[tls_server.c:1290]: tls_h_read_f(): destination IP: 192.26.134.10

-- Juha


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2682#issuecomment-804910135___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add ca_path param to tls module (#2682)

[juha-h]

Closed #2682.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2682#event-4499952619___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] add ca_path param to tls module (#2682)

[juha-h]

Both as client and as server work after command `c_rehash .` is executed in 
ca_path directory.  It creates two (why two?) links to each ca certificate 
file, for example:
```
$ ls -ls
total 16
0 lrwxrwxrwx 1 jh jh   18 Mar 24 07:58 12d55845.0 -> dst_root_ca_x3.pem
0 lrwxrwxrwx 1 jh jh   18 Mar 24 07:58 2e5ac55d.0 -> dst_root_ca_x3.pem
0 lrwxrwxrwx 1 jh jh   32 Mar 24 07:58 4a0a35c0.0 -> 
lets-encrypt-x3-cross-signed.pem
0 lrwxrwxrwx 1 jh jh   32 Mar 24 07:58 4f06f81d.0 -> 
lets-encrypt-x3-cross-signed.pem
0 lrwxrwxrwx 1 jh jh   14 Mar 24 07:58 590d426f.0 -> class3_X0E.crt
0 lrwxrwxrwx 1 jh jh   12 Mar 24 07:58 5ed36f99.0 -> root_X0F.crt
0 lrwxrwxrwx 1 jh jh   12 Mar 24 07:58 99d0fa06.0 -> root_X0F.crt
4 -rw-r--r-- 1 jh jh 2427 Mar 23 16:40 class3_X0E.crt
4 -rw-r--r-- 1 jh jh 1200 Mar 23 16:40 dst_root_ca_x3.pem
0 lrwxrwxrwx 1 jh jh   14 Mar 24 07:58 e5662767.0 -> class3_X0E.crt
4 -rw-r--r-- 1 jh jh 1647 Mar 23 16:40 lets-encrypt-x3-cross-signed.pem
4 -rw-r--r-- 1 jh jh 2464 Mar 23 16:40 root_X0F.crt
```
Text on page 
[https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.html](url)
 is not very clear about the links:

`
If CApath is not NULL, it points to a directory containing CA certificates in 
PEM format. The files each contain one CA certificate. The files are looked up 
by the CA subject name hash value, which must hence be available. If more than 
one CA certificate with the same name hash value exist, the extension must be 
different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the 
ordering of the extension number, regardless of other properties of the 
certificates. Use the c_rehash utility to create the necessary links.
`


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2682#issuecomment-805528425___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: source port check for from_any_gw() and from_gw(). (#2832)

[juha-h]

I haven't tested the new feature, but from backwards compatibility point of 
view, the implementation looks good to me.  Thus I have nothing against the 
merge.

-- 
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/2832#issuecomment-904808255___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: improve binary search to support a match including src port (#2859)

[juha-h]

After the binary match change, is it so that there is no need to change this 
test?
```
/* Store tag and flags and return result */
if((res != NULL)
&& ((transport == PROTO_NONE) || 
(res->transport_code == transport))
&& ((src_port == 0) || (res->port == 
src_port))) {
```

-- 
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/2859#issuecomment-922213175___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: improve binary search to support a match including src port (#2859)

[juha-h]

Indentation does not look good  in the if statement.

-- 
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/2859#issuecomment-923101655___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: improve the search for GW when IP address and src_port are used (#2876)

[juha-h]

Victor Seva writes:

> Assigned #2876 to @juha-h.

OK with me to merge the PR because it only deals with the newly
introduced port feature.


-- 
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/2876#issuecomment-938725693___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] Re: [kamailio/kamailio] lcr: add counters per gateway (PR #3391)

[juha-h]

I did some reading of the code and looks like it does not affect current 
behavior nor have any performance impact if the the stats are off.

But if I understood correctly, in the PR, matching of a SIP request/reply to an 
lcr gw is done based on IP address/port (`fetch_gw_id` function).  On my LCR 
module web page, I have:
```
LCR Instance 'default' Gateway 'test'

Inbound Properties
Common Name or IP Address | Transport

Outbound Properties
IP Address or Domain Name | Port | Transport
```
That is, it is possible that LCR  module does not have any knowledge of the IP 
address/port of a gateway.

The only way I can find if a request comes from a gateway specified by Common 
Name is in the script like this:
```
$var(gw_in_id) = $sht(htable=>cn::$tls_peer_subject_cn::gw_id);
```
That is, looking a common name match from htable.

So unless I didn't read the code correctly, I don't consider it a good idea to 
have a stats feature that applies only to some gateways.











-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3391#issuecomment-1465001446
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] lcr: add counters per gateway (PR #3391)

[juha-h]

Alessio Garzi writes:

> Yes,counters will be only incremented if ip and port are maching as you said.
> This is because ip and port is how I usually store in the lcr table and my 
> commit is just based on my needs.
> Maybe someone in the future can improve my commit to cover all cases.
> For now I just added a notice on the docs describing this behaviour.

As I wrote, I don't consider it a good idea to include a feature that
only works in some situations.

Is there some reason why you can't implement the same in the script
without modifying lcr module?


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3391#issuecomment-1467938755
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] [kamailio/kamailio] crash when handling SUBSCRIBE message (Issue #3417)

[juha-h]

### Description

Latest K master crashes on Debian 11 when handling SUBSCRIBE message.

 Reproduction

Happens every time in my test and I can thus provide more information if needed.

 Debugging Data
```
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/pres-serv...
[New LWP 342614]
[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/bin/pres-serv -f /etc/pres-serv/pres-serv.cfg -P 
/run/pres-serv/pres-serv.'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f58c362cad0 in trim_leading (_s=0x7f58bceeb558) at 
../../core/trim.h:59
[?2004h(gdb) bt full
[?2004l
#0  0x7f58c362cad0 in trim_leading (_s=0x7f58bceeb558) at 
../../core/trim.h:59
No locals.
#1  0x7f58c362cbc0 in trim (_s=0x7f58bceeb558) at ../../core/trim.h:90
No locals.
#2  0x7f58c363f51c in print_callid (w=0x7f58bceed731 "", 
dialog=0x7f58c378c350, t=0x7f58bceeb4f0) at t_msgbuilder.c:1531
No locals.
#3  0x7f58c3640d78 in build_uac_req (method=0x7ffc2c640ae0, 
headers=0x7ffc2c640af0, body=0x0, dialog=0x7f58c378c350, 
branch=0, t=0x7f58bceeb4f0, len=0x7ffc2c64023c, dst=0x7ffc2c640380) at 
t_msgbuilder.c:1649
buf = 0x7f58bceed5d0 "NOTIFY 
sip:t...@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce 
SIP/2.0\r\nVia: SIP/2.0/TCP 127.0.0.1:5080;branch=z9hG4bK64ba.0bec0511", '0' 
, ".0\r\nTo:  "0", len = 1}
cseq = {s = 0x7f58c36f77e0  "2", len = 1}
via = {
  s = 0x7f58c378c590 "Via: SIP/2.0/TCP 
127.0.0.1:5080;branch=z9hG4bK64ba.0bec0511", '0' , ".0\r\n", 
  len = 87}
maxfwd_len = 0
tbracket = 1
fbracket = 1
fromtag = {s = 0x0, len = 0}
loc_tag = {s = 0x0, len = 0}
__func__ = "build_uac_req"
#4  0x7f58c36b9e34 in t_uac_prepare (uac_r=0x7ffc2c640b40, 
dst_req=0x7ffc2c640498, dst_cell=0x7ffc2c6404a0) at uac.c:541
dst = {send_sock = 0x7f58c3795bb0, to = {s = {sa_family = 2, 
  sa_data = 
"\023\316\177\000\000\001\000\000\000\000\000\000\000"}, sin = {sin_family = 2, 
sin_port = 52755, 
  sin_addr = {s_addr = 16777343}, sin_zero = 
"\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, 
  sin6_port = 52755, sin6_flowinfo = 16777343, sin6_addr = {__in6_u 
= {__u6_addr8 = '\000' , 
  __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 
0, 0}}}, sin6_scope_id = 0}, sas = {
  ss_family = 2, __ss_padding = "\023\316\177\000\000\001", '\000' 
, __ss_align = 0}}, id = 0, 
  send_flags = {f = 4, blst_imask = 0}, proto = 2 '\002', proto_pad0 = 
0 '\000', proto_pad1 = 0}
new_cell = 0x7f58bceeb4f0
request = 0x7f58bceeb7c0
buf = 0x0
buf_len = 665
ret = -1
hi = 43846
is_ack = 0
lifetime = 512
nhtype = 256
snd_flags = {f = 4, blst_imask = 0}
backup_xd = {uri_avps_from = 0x7f58bcee78a0, uri_avps_to = 
0x7f58bcee78a8, user_avps_from = 0x7f58bcee78b0, 
  user_avps_to = 0x7f58bcee78b8, domain_avps_from = 0x557db2f646c0 
, 
  domain_avps_to = 0x557db2f646c8 , xavps_list = 
0x7f58bcee78d0, xavus_list = 0x7f58bcee78d8, 
  xavis_list = 0x7f58bcee78e0}
local_xd = {uri_avps_from = 0x0, uri_avps_to = 0x0, user_avps_from = 
0x0, user_avps_to = 0x0, domain_avps_from = 0x0, 
  domain_avps_to = 0x0, xavps_list = 0x0, xavus_list = 0x0, xavis_list 
= 0x0}
refresh_shortcuts = 0
sip_msg_len = 0
lreq = {id = 0, pid = 0, tval = {tv_sec = 0, tv_usec = 0}, 
fwd_send_flags = {f = 0, blst_imask = 0}, 
  rpl_send_flags = {f = 0, blst_imask = 0}, first_line = {type = 0, 
flags = 0, len = 0, u = {request = {method = {
  s = 0x0, len = 0}, uri = {s = 0x0, len = 0}, version = {s = 
0x0, len = 0}, method_value = 0}, reply = {
version = {s = 0x0, len = 0}, status = {s = 0x0, len = 0}, 
reason = {s = 0x0, len = 0}, statuscode = 0}}}, 
  via1 = 0x0, via2 = 0x0, headers = 0x0, last_header = 0x0, parsed_flag 
= 0, h_via1 = 0x0, h_via2 = 0x0, 
  callid = 0x0, to = 0x0, cseq = 0x0, from = 0x0, contact = 0x0, 
maxforwards = 0x0, route = 0x0, record_route = 0

[sr-dev] Re: [kamailio/kamailio] crash when handling SUBSCRIBE message (Issue #3417)

[juha-h]

K at this commit works OK: 
https://github.com/kamailio/kamailio/commit/ea30efdbae2b33988e6157ba5e17aba16db156d4
 and crashes at this commit: 
https://github.com/kamailio/kamailio/commit/c7e228eae76a432ea93fac7e95f50fe50979d79e.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3417#issuecomment-1510297347
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] crash when handling SUBSCRIBE message (Issue #3417)

[juha-h]

Daniel-Constantin Mierla writes:

> Can you try with latest devel version? I pushed a commit to fix this.

Thanks, the crash does not happen anymore.

-- Juha


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3417#issuecomment-1513577881
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] crash when handling SUBSCRIBE message (Issue #3417)

[juha-h]

Closed #3417 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3417#event-9038721707
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] lcr: crash on ki_load_gws*() if called via KEMI (Issue #3435)

[juha-h]

Victor Seva writes:

> Assigned #3435 to @juha-h.

Victor,

Anything related to KEMI is not written me and I don't know anything
about it.

-- Juha


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3435#issuecomment-1535226928
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] lcr: crash on ki_load_gws*() if called via KEMI (Issue #3435)

[juha-h]

KEMI was introduced to lcr module by this commit: 
https://github.com/kamailio/kamailio/commit/8fbf7d83b1dbeedf1ee53895aadbf6e99321432d.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3435#issuecomment-1535234476
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

### Description

Kamailio 5.7 build on Debian Bookworm gave me the following build warnings.  
The only curl related build dependency that I have is
libcurl4-openssl-dev and the only openssl build dependency is libssl-dev.

```
CC (gcc) [M http_client.so] functions.o
functions.c: In function 'curL_request_url':
functions.c:158:9: warning: 'CURLOPT_PROTOCOLS' is deprecated: since 7.85.0. 
Use CURLOPT_PROTOCOLS_STR [-Wdeprecated-declarations]
  158 | res = curl_easy_setopt(
  | ^~~
In file included from http_client.h:36,
 from functions.c:45:
/usr/include/x86_64-linux-gnu/curl/curl.h:1749:3: note: declared here
 1749 |   CURLOPTDEPRECATED(CURLOPT_PROTOCOLS, CURLOPTTYPE_LONG, 181,
  |   ^
functions.c:160:9: warning: 'CURLOPT_REDIR_PROTOCOLS' is deprecated: since 
7.85.0. Use CURLOPT_REDIR_PROTOCOLS_STR [-Wdeprecated-declarations]
  160 | res = curl_easy_setopt(
  | ^~~
/usr/include/x86_64-linux-gnu/curl/curl.h:1755:3: note: declared here
 1755 |   CURLOPTDEPRECATED(CURLOPT_REDIR_PROTOCOLS, CURLOPTTYPE_LONG, 182,
  |   ^
functions.c:387:17: warning: 'CURLINFO_SIZE_DOWNLOAD' is deprecated: since 
7.55.0. Use CURLINFO_SIZE_DOWNLOAD_T [-Wdeprecated-declarations]
  387 | curl_easy_getinfo(curl, CURLINFO_SIZE_DOWNLOAD, 
&download_size);
  | ^
/usr/include/x86_64-linux-gnu/curl/curl.h:2841:3: note: declared here
 2841 |   CURLINFO_SIZE_DOWNLOAD
  |   ^~



CC (gcc) [M tls.so] tls_mod.o
tls_mod.c: In function 'mod_child':
tls_mod.c:455:25: warning: 'OPENSSL_fork_prepare' is deprecated: Since OpenSSL 
3.0 [-Wdeprecated-declarations]
  455 | OPENSSL_fork_prepare();
  | ^~~~
In file included from /usr/include/openssl/comp.h:22,
 from /usr/include/openssl/ssl.h:28,
 from tls_init.h:30,
 from tls_mod.c:45:
/usr/include/openssl/crypto.h:427:28: note: declared here
  427 | OSSL_DEPRECATEDIN_3_0 void OPENSSL_fork_prepare(void);
  |^~~~
tls_mod.c:467:25: warning: 'OPENSSL_fork_parent' is deprecated: Since OpenSSL 
3.0 [-Wdeprecated-declarations]
  467 | OPENSSL_fork_parent();
  | ^~~
/usr/include/openssl/crypto.h:428:28: note: declared here
  428 | OSSL_DEPRECATEDIN_3_0 void OPENSSL_fork_parent(void);
  |^~~
tls_mod.c:471:25: warning: 'OPENSSL_fork_child' is deprecated: Since OpenSSL 
3.0 [-Wdeprecated-declarations]
  471 | OPENSSL_fork_child();
  | ^~
/usr/include/openssl/crypto.h:429:28: note: declared here
  429 | OSSL_DEPRECATEDIN_3_0 void OPENSSL_fork_child(void);
  |^~
tls_mod.c: In function 'ksr_rand_engine_param':
tls_mod.c:514:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 
3.0 [-Wdeprecated-declarations]
  514 | RAND_set_rand_method(RAND_ksr_krand_method());
  | ^~~~
In file included from tls_rand.h:26,
 from tls_mod.c:54:
/usr/include/openssl/rand.h:49:27: note: declared here
   49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
  |   ^~~~
tls_mod.c:517:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 
3.0 [-Wdeprecated-declarations]
  517 | RAND_set_rand_method(RAND_ksr_fastrand_method());
  | ^~~~
/usr/include/openssl/rand.h:49:27: note: declared here
   49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
  |   ^~~~
tls_mod.c:520:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 
3.0 [-Wdeprecated-declarations]
  520 | RAND_set_rand_method(RAND_ksr_cryptorand_method());
  | ^~~~
/usr/include/openssl/rand.h:49:27: note: declared here
   49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
  |   ^~~~
tls_mod.c:523:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 
3.0 [-Wdeprecated-declarations]
  523 | RAND_set_rand_method(RAND_ksr_kxlibssl_method());
  | ^~~~
/usr/include/openssl/rand.h:49:27: note: declared here
   49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
  |   ^~~~
tls_mod.c: In function 'mod_register':
tls_mod.c:674:9: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 
3.0 [-Wdeprecated-declarations]
  674 | RAND_set_rand_method(RAND_ksr_crypt

[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

Reopened #3484.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3484#event-9580837229
You are receiving this because you commented.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

Sorry, but the warnings have not been fixed in 5.7, which was the topic of this 
issue.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3484#issuecomment-1598966691
You are receiving this because you commented.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

Daniel-Constantin Mierla writes:

> @juha-h: backporting to 5.7 may take a while, because support for
> libssl 3.0 is not validated yet. Those are deprecating warnings, so
> normally things should still work fine with them, but as reported on
> other issues, there are crashes with libssl 3.0. Therefore it is
> expected there are other internal changes in libssl 3.0 that need to
> be handled.

Yes, I understand, but lots of warnings when building stable, production
version of my SIP Proxy based on stable version of Kamailio, does not
look good.  So, lets keep this issue open until the backport is done to
5.7.

> Maybe you can help testing tls master branch and if proves stable,
> then can be backported. Just getting rid of changes in this case does
> not seem enough at this moment.

I'm using master in my own test setup and will report if I find TLS
related issues.

-- Juha


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3484#issuecomment-1599028823
You are receiving this because you commented.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

With this kind of tls.cfg
```
[client:default]
verify_certificate = yes
require_certificate = yes
tls_method = TLSv1.2+
private_key = /etc/sip-proxy/certs/siika-key.pem
certificate = /etc/sip-proxy/certs/siika-cert.pem
ca_list = /etc/sip-proxy/certs/ca_list.pem

[server:default]
verify_certificate = yes
require_certificate = no
server_name = test.tutpro.com
tls_method = TLSv1.2+
private_key = /etc/sip-proxy/certs/siika-key.pem
certificate = /etc/sip-proxy/certs/siika-cert.pem
ca_list = /etc/sip-proxy/certs/ca_list.pem
```
SIP Proxy was able to verify client certificate and vice versa.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3484#issuecomment-1599227744
You are receiving this because you commented.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

This one is still left:
```
C (gcc) [M http_client.so]  functions.o
functions.c: In function 'curL_request_url':
functions.c:164:9: warning: 'CURLOPT_REDIR_PROTOCOLS' is deprecated: since 
7.85.0. Use CURLOPT_REDIR_PROTOCOLS_STR [-Wdeprecated-declarations]
  164 | res = curl_easy_setopt(
  | ^~~
In file included from http_client.h:36,
 from functions.c:45:
/usr/include/x86_64-linux-gnu/curl/curl.h:1755:3: note: declared here
 1755 |   CURLOPTDEPRECATED(CURLOPT_REDIR_PROTOCOLS, CURLOPTTYPE_LONG, 182,
  |   ^

```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3484#issuecomment-1601389758
You are receiving this because you commented.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

Here is diff to get rid of the curl warning:
```
*** /usr/src/orig/kamailio/src/modules/http_client/functions.c  2023-06-21 
13:15:29.682303834 +0300
--- src/opensipg-sip-proxy/src/modules/http_client/functions.c  2023-06-23 
09:00:14.403813698 +0300
***
*** 162,168 
curl, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | 
CURLPROTO_HTTPS);
  #endif
res = curl_easy_setopt(
!   curl, CURLOPT_REDIR_PROTOCOLS, CURLPROTO_HTTP | 
CURLPROTO_HTTPS);
  
if(_met != NULL) {
/* Enforce method (GET, PUT, ...) */
--- 162,168 
curl, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | 
CURLPROTO_HTTPS);
  #endif
res = curl_easy_setopt(
!   curl, CURLOPT_REDIR_PROTOCOLS_STR, "http,https");
  
if(_met != NULL) {
/* Enforce method (GET, PUT, ...) */
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3484#issuecomment-1603728827
You are receiving this because you commented.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

Yes, all warnings are now gone.  Thanks.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3484#issuecomment-1603835571
You are receiving this because you commented.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)

[juha-h]

Closed #3484 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3484#event-9614691197
You are receiving this because you commented.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] [kamailio/kamailio] ipops compiler warnings (#1074)

[juha-h]

These warnings should be eliminated in order to make compilation readable:

CC (gcc) [M ipops.so]   ip_parser.o
ip_parser.c:18:18: warning: 'ip_parser_en_main' defined but not used 
[-Wunused-const-variable=]
 static const int ip_parser_start = 1;
  ^
ip_parser.c:16:18: warning: 'ip_parser_error' defined but not used 
[-Wunused-const-variable=]
 
  ^  
ip_parser.c:15:18: warning: 'ip_parser_first_final' defined but not used 
[-Wunused-const-variable=]
 /** Data **/
  ^
CC (gcc) [M ipops.so]   rfc1918_parser.o
rfc1918_parser.c:19:18: warning: 'rfc1918_parser_en_main' defined but not used 
[-Wunused-const-variable=]
 static const int rfc1918_parser_en_main = 1;
  ^~
rfc1918_parser.c:17:18: warning: 'rfc1918_parser_error' defined but not used 
[-Wunused-const-variable=]
 static const int rfc1918_parser_error = 0;
  ^~~~
rfc1918_parser.c:16:18: warning: 'rfc1918_parser_first_final' defined but not 
used [-Wunused-const-variable=]
 static const int rfc1918_parser_first_final = 28;
  ^~


-- 
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/1074___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] tls compiler warnings (#1075)

[juha-h]

These warnings should be eliminated in order to make compilation readable:

CC (gcc) [M tls.so] tls_locking.o
tls_locking.c:98:13: warning: 'locking_f' defined but not used 
[-Wunused-function]
 static void locking_f(int mode, int n, const char* file, int line)
 ^
tls_locking.c:83:13: warning: 'dyn_destroy_f' defined but not used 
[-Wunused-function]
 static void dyn_destroy_f(struct CRYPTO_dynlock_value *l,
 ^
tls_locking.c:65:13: warning: 'dyn_lock_f' defined but not used 
[-Wunused-function]
 static void dyn_lock_f(int mode, struct CRYPTO_dynlock_value* l,
 ^~
tls_locking.c:42:37: warning: 'dyn_create_f' defined but not used 
[-Wunused-function]
 static struct CRYPTO_dynlock_value* dyn_create_f(const char* file, int line)
 ^~~~

CC (gcc) [M tls.so] tls_init.o
tls_init.c: In function 'init_ssl_methods':
tls_init.c:377:2: warning: 'TLSv1_client_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1_cli - 1] = TLSv1_client_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1598:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_client_method(void)) /* 
TLSv1.0 */
 ^
tls_init.c:378:2: warning: 'TLSv1_server_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1_srv - 1] = TLSv1_server_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1597:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_server_method(void)) /* 
TLSv1.0 */
 ^
tls_init.c:379:2: warning: 'TLSv1_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1 - 1] = TLSv1_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1596:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_method(void)) /* TLSv1.0 */
 ^
tls_init.c:382:2: warning: 'TLSv1_1_client_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1_1_cli - 1] = TLSv1_1_client_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1604:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_client_method(void)) /* 
TLSv1.1 */
 ^
tls_init.c:383:2: warning: 'TLSv1_1_server_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1_1_srv - 1] = TLSv1_1_server_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1603:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_server_method(void)) /* 
TLSv1.1 */
 ^
tls_init.c:384:2: warning: 'TLSv1_1_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1_1 - 1] = TLSv1_1_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1602:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_method(void)) /* TLSv1.1 */
 ^
tls_init.c:388:2: warning: 'TLSv1_2_client_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1_2_cli - 1] = TLSv1_2_client_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1610:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_2_client_method(void)) /* 
TLSv1.2 */
 ^
tls_init.c:389:2: warning: 'TLSv1_2_server_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1_2_srv - 1] = TLSv1_2_server_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1609:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_2_server_method(void)) /* 
TLSv1.2 */
 ^
tls_init.c:390:2: warning: 'TLSv1_2_method' is deprecated 
[-Wdeprecated-declarations]
  ssl_methods[TLS_USE_TLSv1_2 - 1] = TLSv1_2_method();
  ^~~
In file included from /usr/include/openssl/ct.h:13:0,
 from /usr/include/openssl/ssl.h:61,
 from tls_init.c:45:
/usr/include/openssl/ssl.h:1608:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_

Re: [sr-dev] [kamailio/kamailio] Installation broken because of commented out mpath in example config (#1096)

[juha-h]

Daniel-Constantin Mierla writes:

> Looking at `src/Makefile.defs`, the `LIBDIR` has to be set in the
> build command, like: 
> 
> ```
> make LIBDIR=lib/x86_64-linux-gnu
> ```
> Maybe there is a way to know in Debian specs what value to set here.

pkg-config command may help there.

-- juha


-- 
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/1096#issuecomment-297675652___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] allow more than one tcp/tls connection to same destination (#1107)

[juha-h]

When K connects to another SIP proxy over TCP or TLS, the connection is shared 
for all requests to that destination.  If the receiving SIP proxy is K, it 
means that only one worker process is handling all those requests.  This may 
become a bottleneck if processing of requests is time consuming, e.g., because 
of DB operations.

It should therefore be possible one way or another to establish more than one 
parallel TCP or TLS connections to the same destination.  One solution could be 
based on a function call, such as t_forward_connect(number), to be called 
before t_relay specifying the desired number of parallel connections shared 
randomly by outgoing 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/1107___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Currently core/flags.h defines

  typedef unsigned int flag_t;

It would better to use unsigned long in order to allow more that 32 flags on 64 
bit architectures.


-- 
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/1288___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] sanity() test passes on invalid uri (#1289)

[juha-h]

K master sanity() test passes URI hostpart that contains ` (back quote) 
character and possibly other invalid hostpart characters:

Config:

modparam("sanity", "default_checks", 1024) /* URI checks */
modparam("sanity", "uri_checks", 3)  /* RURI, From */

xlog("L_INFO", "Checking $ru\n");
if (!sanity_check())
xlog("L_INFO", "Check failed\n");
else
xlog("L_INFO", "Check passed\n");

Syslog:

Oct 27 17:17:38 lohi /usr/bin/sip-proxy[31946]: INFO: Checking sip:jh at 
te`st.fi
Oct 27 17:17:38 lohi /usr/bin/sip-proxy[31946]: INFO: Check passed

According to RFC3261:

hostname =  *( domainlabel "." ) toplabel [ "." ]
domainlabel  =  alphanum
/ alphanum *( alphanum / "-" ) alphanum

-- 
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/1289___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Daniel-Constantin Mierla writes:

> This has implications on other parts, such as variables where they can
> be accessed and set via $mf (iirc).

Other parts of the code should not assume anything about the actual
length of flag_t.  If they do, that code needs to be fixed.

> As an alternative for now would be using an avp or xavps, and do
> bitwise operations (`|` and `&`) to set or test.

Use of avps for storing bit flags is too slow.

-- Juha


-- 
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/1288#issuecomment-340397304___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

My proposal is to change flag_t to unsigned long long after master is
opened for new features.  Then there is lots of time to fix code that
might get broken.

-- Juha


-- 
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/1288#issuecomment-340398676___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Daniel-Constantin Mierla writes:

> Another way could be adding a new field, extended flags, with a
> different set of functions to handle them like
> setflagx()/resetflagx(...)/isflagxset(...), so the current behaviour
> is not affected at all.

That would be fine with me.

> view I think using an array (static size) is better than single value
> field. Initially it can be of uint32_t[2] to give access to 64 more
> flags, but in the future it can be changed if needed. The functions
> will take two parameters, bit index and array index.

That would be too complex to use.  A flag should be a single integer.

-- Juha


-- 
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/1288#issuecomment-340545188___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

How about using an array of unsigned ints, but functions have only one 
parameter?  Array index is param / 32 and flag number at the index is param % 
32.

-- 
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/1288#issuecomment-340836695___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] sanity() test passes on invalid uri (#1289)

[juha-h]

Daniel-Constantin Mierla writes:

> I think this was fixed by commit
> 4994960324d5353222b3de08515bed07802ab7bc, if not, reopen.

Yes, I didn't remember that I had opened an issue about it.

-- Juha


-- 
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/1289#issuecomment-357799353___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Daniel-Constantin Mierla writes:

> Just added support for extended flags (xflags) with a capacity of 64
> flags. The functions to manage them are exported by corex module. No
> time to test them, so feedback if all is fine or not is appreciated.

I was going to give corex a try, but loading of the module failed like
this:

ar 21 01:39:35 trout sip-proxy[13013]:  0(13064) ERROR:  
[core/sr_module.c:582]: load_module(): could not open module 
: 
/usr/lib/x86_64-linux-gnu/sip-proxy/modules/corex.so: undefined symbol: setxflag

-- Juha


-- 
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/1288#issuecomment-374583220___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Is t_flush_flags() really needed? (#1490)

[juha-h]

I have not found any situation, where t_flush_flags() is needed.  If I set a 
flag after t_newtran() and then call t_relay(), the flag stays set both in 
failure route and reply route.  If there exists a case, where t_flush_flags() 
needs to be called after t_newtran(), it should be mentioned in README in order 
to avoid needless calls of t_flush_flags().

-- 
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/1490___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

As long as xflags do not work the same way as flags, I do not consider this 
issue closed.  Flags do not require call of t_flush_flags() after t_newtrans() 
in order to make flags available in failure and onreply routes, but xflags does 
require call of t_flush_xflags().  This makes xflags cumbersome to use, since I 
would need to make  t_flush_xflags() call before every t_relay() call.

-- 
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/1288#issuecomment-378833596___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Reopened #1288.

-- 
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/1288#event-1558010774___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Daniel-Constantin Mierla writes:

> As I wrote on the mailing list, flags should not be migrated to the
> transaction after t_newtran() unless one uses t_flush_flags() -- that
> was the desired functionality, otherwise t_flush_flags() has no
> purpose.

I have used flags for many years and for me it has been desirable that
they are available after t_newtrans() in failure and onreply routes
without a need to call t_flush_flags().  If someone wants to change that
behavior and make t_flush_flags() purposeful, then a tm variable can be
introduced to achieve that new behavior.

> You opened another item on this tracker related to this unexpected
> behaviour (#1490), and I think it is better to sort this out there,
> because that is the unexpected behaviour. xflags behave as
> expected. Whatever will be the conclusion of #1490 will be applied to
> both flags and xflags, but makes no sense to track an issue with two
> separate items.

I opened this issue, because I needed more that 32 flags, i.e., flags
that work the same way as before, but more of them.  It is OK to replace
flags with xflags if my current configuration file keeps on working when
I textually change current flag function calls with xflag function
calls, but it is not OK if I need to start adding t_flush_xflags() calls
to it.

Issue "Is t_flush_flags() really needed? #1490" asks about the purpose
of t_flush_flags() function.  I have not been able to figure out one,
but perhaps there is some.  If there is no purpose, then the function
should be removed.

-- Juha


-- 
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/1288#issuecomment-378838094___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Closing the issue even when xflags as currently implemented do not behave the 
same way as flags and thus cannot be used as their replacement.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1288#issuecomment-378851744___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] define flag_t as unsigned long (#1288)

[juha-h]

Closed #1288.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1288#event-1558135695___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] Is t_flush_flags() really needed? (#1490)

[juha-h]

Daniel-Constantin Mierla writes:

> Looked in the code and the flags are resync'ed on t_relay() (or the
> similar relay functions), that happens because of:
> 
>   * 
> https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_lookup.c#L1327

Makes sense, since it greatly simplifies scripting.

> I am going to add the same for xflags.

Thank you very much.

-- Juha


-- 
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/1490#issuecomment-380446392___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Make tcp_check_timer default to depend on tcp_msg_data_timeout and tcp_msg_read_timeout values (PR #3608)

[juha-h via sr-dev]

If  `tcp_check_timer` is not set, use default value that is half of 
`tcp_msg_data_timeout` or `tcp_msg_read_timeout` value depending on which one 
is smaller and not zero.


You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/3608

-- Commit Summary --

  * Make tcp_check_timer default to depend on tcp_msg_data_timeout and

-- File Changes --

M src/main.c (22)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/3608.patch
https://github.com/kamailio/kamailio/pull/3608.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3608
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] Make tcp_check_timer default to depend on tcp_msg_data_timeout and tcp_msg_read_timeout values (PR #3608)

[juha-h via sr-dev]

@juha-h pushed 1 commit.

38a1c736fa3ebef8827a0f3ef645e7e4fa165b5a  Trying to fix format

-- 
View it on GitHub:
https://github.com/kamailio/kamailio/pull/3608/files/dd9d828a782c0c132c536a97beb792176928a716..38a1c736fa3ebef8827a0f3ef645e7e4fa165b5a
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org