[sr-dev] Re: [kamailio/kamailio] Dialog DMQ sync: Timer needs fixing, firing on wrong node! (Issue #3656)

[Benoît Panizzon via sr-dev]

I guess I stumbled over some other issue or bug...

`[1 dialog 0f57b21a4ca92561-1371066@x.x.x.x 10 KDMQ]jansson 
[jansson_funcs.c:47]: janssonmod_get_helper(): json error at line 1, col 3154: 
duplicate object key near '"tag1"'`

Indeed, when looking at the JSON structure sent with dialog action 1, state 2, 
sometimes the key 'tag1' is present twice. Value is the same in both keys so 
exact duplicates. This is not valid JSON and thus the jansson parser fails and 
I can not change the lifetime in those occurrences.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3656#issuecomment-1840192218
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] Jenkins build is still unstable: kamailiodev-nightly-binaries » amd64,stretch #2544

[kamailio--- via sr-dev]

See 


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

[sr-dev] Re: Kamailio + RTPEngine + TURN server to enable calling between WebRTC client and legacy SIP clients

[Monxarat via sr-dev]

Hi Serfey Safarov, Thanks for answering.
I have one question. Regarding the right block (1: WebRTC client -> SIP
Server) and the left block (SIP client), will a library be used here? Or is
this functionality handled in Kamailio?

2023年12月5日(火) 15:44 Sergey Safarov :

> 1) INVITE message with ICE and encryption in the SDP;
> 2) INVITE message and then response without ICE and encryption in the SDP
> (if client does not support ICE);
> 3) internal message with SDP content (Kamailio request with received SIP
> message and RTPengine response with SDP for delivery to next hop);
> 4) RTP stream without encryption and without ICE/STUN (if client does not
> support ICE);
> 5) RTP stream with ICE/STUN and encryption.
>
> On Tue, Dec 5, 2023 at 12:48 AM nguyenquocchinhdev--- via sr-dev <
> sr-dev@lists.kamailio.org> wrote:
>
>> Hi guys,
>>  Can anybody explain to me this flow.
>>
>> https://raw.githubusercontent.com/havfo/WEBRTC-to-SIP/master/images/webrtc-sip.png
>>
>> And
>> What will be done in 1,2,3,4,5. When a new connection the request flow is
>> 1,2,3,4,5 order is created.
>>
>> 1: webRTC client -> SIp Server
>> 2: SIP server -> SIP client
>> 3: Kmailio -> RTPengine
>> 4: SIP client -> RTPengine
>> 5: RTPengine -> webRTC client
>> ___
>> Kamailio (SER) - Development Mailing List
>> To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
>>
>
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: Kamailio + RTPEngine + TURN server to enable calling between WebRTC client and legacy SIP clients

[Sergey Safarov via sr-dev]

1) INVITE message with ICE and encryption in the SDP;
2) INVITE message and then response without ICE and encryption in the SDP
(if client does not support ICE);
3) internal message with SDP content (Kamailio request with received SIP
message and RTPengine response with SDP for delivery to next hop);
4) RTP stream without encryption and without ICE/STUN (if client does not
support ICE);
5) RTP stream with ICE/STUN and encryption.

On Tue, Dec 5, 2023 at 12:48 AM nguyenquocchinhdev--- via sr-dev <
sr-dev@lists.kamailio.org> wrote:

> Hi guys,
>  Can anybody explain to me this flow.
>
> https://raw.githubusercontent.com/havfo/WEBRTC-to-SIP/master/images/webrtc-sip.png
>
> And
> What will be done in 1,2,3,4,5. When a new connection the request flow is
> 1,2,3,4,5 order is created.
>
> 1: webRTC client -> SIp Server
> 2: SIP server -> SIP client
> 3: Kmailio -> RTPengine
> 4: SIP client -> RTPengine
> 5: RTPengine -> webRTC client
> ___
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
>
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] branch_failure route in case 503 and dns failover (PR #3138)

[vlitvinov via sr-dev]

@vlitvinov pushed 3 commits.

30f4133c8e39c22cba63466d11391b1cf443ecb6  branch_failure route in case 503 and 
dns failover
9364ca5b71b42a528d88fe0ca4c275a3970c49a6  branch_failure route in case 503 and 
dns failover
74babe6a41a54b528c697de01d2746b31f65e623  branch_failure route in case 503 and 
dns failover

-- 
View it on GitHub:
https://github.com/kamailio/kamailio/pull/3138/files/c7c8084d7dd05602cfb38dc3a8e71e8ee9dce0f8..74babe6a41a54b528c697de01d2746b31f65e623
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 + RTPEngine + TURN server to enable calling between WebRTC client and legacy SIP clients

[nguyenquocchinhdev--- via sr-dev]

Hi guys, 
 Can anybody explain to me this flow.
https://raw.githubusercontent.com/havfo/WEBRTC-to-SIP/master/images/webrtc-sip.png

And
What will be done in 1,2,3,4,5. When a new connection the request flow is 
1,2,3,4,5 order is created.

1: webRTC client -> SIp Server
2: SIP server -> SIP client
3: Kmailio -> RTPengine
4: SIP client -> RTPengine
5: RTPengine -> webRTC client
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] git:master:812df264: ims_ipsec_pcscf: handle IPSec registration case where first SIP REGISTER does not have VIA port as 5060

[Daniel-Constantin Mierla via sr-dev]

Module: kamailio
Branch: master
Commit: 812df26470b50d626ce9ee03b9272373b231ce2a
URL: 
https://github.com/kamailio/kamailio/commit/812df26470b50d626ce9ee03b9272373b231ce2a

Author: Supreeth Herle 
Committer: Daniel-Constantin Mierla 
Date: 2023-12-04T20:29:40+01:00

ims_ipsec_pcscf: handle IPSec registration case where first SIP REGISTER does 
not have VIA port as 5060

---

Modified: src/modules/ims_ipsec_pcscf/cmd.c

---

Diff:  
https://github.com/kamailio/kamailio/commit/812df26470b50d626ce9ee03b9272373b231ce2a.diff
Patch: 
https://github.com/kamailio/kamailio/commit/812df26470b50d626ce9ee03b9272373b231ce2a.patch

---

diff --git a/src/modules/ims_ipsec_pcscf/cmd.c 
b/src/modules/ims_ipsec_pcscf/cmd.c
index c863eff5407..80a714559ba 100644
--- a/src/modules/ims_ipsec_pcscf/cmd.c
+++ b/src/modules/ims_ipsec_pcscf/cmd.c
@@ -855,7 +855,9 @@ int ipsec_create(struct sip_msg *m, udomain_t *d, int 
_cflags)
ipsec_t *old_s = NULL;
 
// Update contacts only for initial registration, for re-registration 
the existing contacts shouldn't be updated.
-   if(ci.via_port == SIP_PORT) {
+   if(ci.via_port == SIP_PORT
+   || (pcontact->security_temp->data.ipsec->port_ps == 0
+   && 
pcontact->security_temp->data.ipsec->port_pc == 0)) {
LM_DBG("Registration for contact with AOR [%.*s], VIA 
[%d://%.*s:%d], "
   "received_host [%d://%.*s:%d]\n",
ci.aor.len, ci.aor.s, ci.via_prot, 
ci.via_host.len,

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

[sr-dev] git:master:2f98aaca: ims_ipsec_pcscf: declare vars at beginning of the block

[Daniel-Constantin Mierla via sr-dev]

Module: kamailio
Branch: master
Commit: 2f98aaca9e4b71b8086abce4c2b41c215fb2a26f
URL: 
https://github.com/kamailio/kamailio/commit/2f98aaca9e4b71b8086abce4c2b41c215fb2a26f

Author: Daniel-Constantin Mierla 
Committer: Daniel-Constantin Mierla 
Date: 2023-12-04T20:33:40+01:00

ims_ipsec_pcscf: declare vars at beginning of the block

---

Modified: src/modules/ims_ipsec_pcscf/cmd.c

---

Diff:  
https://github.com/kamailio/kamailio/commit/2f98aaca9e4b71b8086abce4c2b41c215fb2a26f.diff
Patch: 
https://github.com/kamailio/kamailio/commit/2f98aaca9e4b71b8086abce4c2b41c215fb2a26f.patch

---

diff --git a/src/modules/ims_ipsec_pcscf/cmd.c 
b/src/modules/ims_ipsec_pcscf/cmd.c
index 80a714559ba..de61ad7cf6b 100644
--- a/src/modules/ims_ipsec_pcscf/cmd.c
+++ b/src/modules/ims_ipsec_pcscf/cmd.c
@@ -806,6 +806,10 @@ int ipsec_create(struct sip_msg *m, udomain_t *d, int 
_cflags)
struct pcontact_info ci;
int ret = IPSEC_CMD_FAIL; // FAIL by default
tm_cell_t *t = NULL;
+   sip_msg_t *req = NULL;
+   security_t *req_sec_params = NULL;
+   ipsec_t *s = NULL;
+   ipsec_t *old_s = NULL;
 
if(m->first_line.type == SIP_REPLY) {
t = tmb.t_gett();
@@ -847,12 +851,10 @@ int ipsec_create(struct sip_msg *m, udomain_t *d, int 
_cflags)
goto cleanup;
}
 
-   struct sip_msg *req = t->uas.request;
+   req = t->uas.request;
 
// Parse security parameters from the REGISTER request and get some 
data for the new tunnels
-   security_t *req_sec_params = cscf_get_security(req);
-   ipsec_t *s;
-   ipsec_t *old_s = NULL;
+   req_sec_params = cscf_get_security(req);
 
// Update contacts only for initial registration, for re-registration 
the existing contacts shouldn't be updated.
if(ci.via_port == SIP_PORT

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

[sr-dev] Re: [kamailio/kamailio] pv: Add support to $hfl $hflc for Diversion header (PR #3651)

[Xenofon Karamanos via sr-dev]

@xkaraman pushed 5 commits.

088a1002f714c7b11c0e767bf01e1ad004507cf1  parser: Extend diversion for multiple 
bodies
572eb455ae76902a70a4cb9ad886bdae064fcbff  pv: Add hfl and hflc support for 
Diversion header
1b6b552f69a0139abead40ddc1036b7cc07e38ad  parser: Fix free leakage
67ffe24ab0335e803b7885cf92f8b4d860edc2ad  parser: Fix diversion leakage
ce31601107b7d36a7d93a0037e80461179688144  parser: Explicit cast to required type

-- 
View it on GitHub:
https://github.com/kamailio/kamailio/pull/3651/files/a36da6659df311bb0cfc0b09e44207125e77b137..ce31601107b7d36a7d93a0037e80461179688144
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: Updated: Online devel meeting on matrix - 15:00 UTC, Dec 5, 2023

[Daniel-Constantin Mierla via sr-dev]

Hello,

sort note to refresh about tomorrow's online devel meeting, more details at:

  -
https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings/2023a.md

Cheers,
Daniel

On 27.11.23 11:04, Daniel-Constantin Mierla wrote:
> Hello,
>
> we should consider an online devel meeting sometime soon to summarize
> what was done at (and still needs to be done after) devel meeting in
> Dusseldorf and plan a bit the targets for next major release (5.8 or 6.0)?
>
> If considered useful, I propose Dec 5 at 15:00UTC (16:00
> Berlin/Paris/Madrid/Rome), but we can also look for other dates as well.
>
> Topics to be discussed can be added at:
>
>   -
> https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings/2023a.md
>
> Pull requests can be made by users without git access.
>
> Cheers,
> Daniel
>
> PS: Previous announcement indicated the start time 14:30 UTC, this
> message changes it to 15:00 UTC - 30min later due to a constraint in
> availability of one of the Kamailio developers.
>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>
-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] Hi, could you provide me with a .cfg demo for using SEMS as Announcements in the IMS module? (Issue #3662)

[Olle E. Johansson via sr-dev]

Closed #3662 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3662#event-11135406391
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] Hi, could you provide me with a .cfg demo for using SEMS as Announcements in the IMS module? (Issue #3662)

[Olle E. Johansson via sr-dev]

The issue tracker is for issues - not for general questions and asking for 
help. Please join our mailing lists and ask there.

Thank you!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3662#issuecomment-1838024428
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] uac_req_send crash Kamailio (Issue #3522)

[Péter Barabás via sr-dev]

Here is the full backtrace:
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 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/local/sbin/kamailio...

warning: Can't open file /dev/zero (deleted) during file-backed mapping note 
processing
[New LWP 4110362]
[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/local/sbin/kamailio -P 
/var/run/kamailio/kamailio.pid -f /etc/kamailio/kam'.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140359291291456) 
at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt full
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140359291291456) 
at ./nptl/pthread_kill.c:44
tid = 
ret = 0
pd = 0x7fa7f1b2c740
old_mask = {__val = {528280977419, 1438814044166, 0, 0, 93910694406720, 
6483051068034487040, 552408, 18446744073709551488, 4, 6483051068034487040, 
1, 18446744073709551488, 4, 21, 1, 93910688023664}}
ret = 
pd = 
old_mask = 
ret = 
tid = 
ret = 
resultvar = 
resultvar = 
__arg3 = 
__arg2 = 
__arg1 = 
_a3 = 
_a2 = 
_a1 = 
__futex = 
resultvar = 
__arg3 = 
__arg2 = 
__arg1 = 
_a3 = 
_a2 = 
_a1 = 
__futex = 
__private = 
__oldval = 
result = 
#1  __pthread_kill_internal (signo=6, threadid=140359291291456) at 
./nptl/pthread_kill.c:78
No locals.
#2  __GI___pthread_kill (threadid=140359291291456, signo=signo@entry=6) at 
./nptl/pthread_kill.c:89
No locals.
#3  0x7fa7f1b71476 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
ret = 
#4  0x7fa7f1b577f3 in __GI_abort () at ./stdlib/abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {11204472, 4646408, 5572744, 140358732006944, 
140358731771904, 47, 6483051068034487040, 140724813621040, 6483051068034487040, 
0, 93910686282567, 93910688017824, 93910688018232, 
  140358743675984, 6483051068034487040, 0}}, sa_flags = 1228091018, 
sa_restorer = 0x0}
sigs = {__val = {32, 6483051068034487040, 140724813621104, 
93910686336197, 1701480744, 337218937, 93910687653044, 0, 93910688018058, 
140358731771904, 44, 21474838579, 93909459927052, 140358720490894, 
1284195221895, 0}}
#5  0x55694918b36e in qm_debug_check_frag (qm=0x7fa7d0593000, 
f=0x7fa7d10ed450, file=0x7fa7cf3365f4 "uac: uac_send.c", line=860, 
efile=0x556949332db9 "core/mem/q_malloc.c", eline=511) at 
core/mem/q_malloc.c:129
p = 0x7fa7f0c99f58
__func__ = "qm_debug_check_frag"
#6  0x55694918fbe4 in qm_free (qmp=0x7fa7d0593000, p=0x7fa7d10ed488, 
file=0x7fa7cf3365f4 "uac: uac_send.c", func=0x7fa7cf3373d0 <__func__.2> 
"uac_send_tm_callback", line=860, mname=0x7fa7cf3364d4 "uac") at 
core/mem/q_malloc.c:511
qm = 0x7fa7d0593000
f = 0x7fa7d10ed450
size = 89856
next = 0x7fa7d10e5658
prev = 0x7fa7d10cf6f0
__func__ = "qm_free"
#7  0x55694919b9aa in qm_shm_free (qmp=0x7fa7d0593000, p=0x7fa7d10ed488, 
file=0x7fa7cf3365f4 "uac: uac_send.c", func=0x7fa7cf3373d0 <__func__.2> 
"uac_send_tm_callback", line=860, mname=0x7fa7cf3364d4 "uac") at 
core/mem/q_malloc.c:1350
No locals.
#8  0x7fa7cf32b331 in uac_send_tm_callback (t=0x7fa7d11592f0, type=131072, 
ps=0x7ffd0c86f5d0) at uac_send.c:860
ret = 11203376
hdr = 0x55694919883f 
response = 
"\220\354\206\f\375\177\000\000@R\324\361\247\177\000\000@u\233IiU\000\000\b\000\000\000\000\000\000\000i"
new_auth_hdr = 0x0
auth = {flags = 0, realm = {s = 0x0, len = 0}, domain = {s = 0x0, len = 
0}, nonce = {s = 0x0, len = 0}, opaque = {s = 0x0, len = 0}, qop = {s = 0x0, 
len = 0}, nc = 0x0, cnonce = 0x0}
cred = {realm = {s = 0x7fa7f0e15060 "\370\002", len = -256724976}, user 
= {s = 0x7ffd0c86ead0 "", len = -810742386}, passwd = {s = 0x7fa7f0b2d9e0 "", 
len = 0}, aflags = 16777216, next = 0xaaf1a8}
b_hdrs = 

[sr-dev] Re: [kamailio/kamailio] uac_req_send crash Kamailio (Issue #3522)

[Péter Barabás via sr-dev]

Hi,

any idea about this crash? I got 17 crashes in 4 days. The stack trace is the 
same as above.
In kamailio config I do the followings:
- mobile softphone applications are registered to asterisk through kamailio. 
Kamailio forwards the requests to asterisk which authenticates the users. In 
successful authentication Kamailio saves registrations also into location and 
another table which stores the "active asterisk users".
- when mobile app goes to background registration from location will be deleted 
but registration between Kamailio and asterisk remains active. Registration 
timeout between asterisk and kamailio is 2 hours.
- I wrote a rtimer route which runs in every 10 minutes: kamailio checks which 
registration has less than an hour towards asterisk. If there is such, the 
following happens:
1. Kamailio sends an async http request to our server which results the sip 
passwords of users which have to be renewed.
2. In the http reply handler kamailio builds az $uac_req object and calls 
uac_req_send() to asterisk for each users which registrations have to be 
renewed.
3. $uac_req(evroute)=1 is set before.
4. In uac:reply event route registration data (refresh time...) is saved into a 
mysql table.

The crash occurs immediately after or during calling refresh regsistration.

Any idea, how can this crash be eliminated?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3522#issuecomment-1838019371
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