[SR-Users] Re: Crypto module AES algorithm details

[Henning Westerholt via sr-users]

Hello,

if you can suggest changes to the 3rd party library that is used to encrypt the 
data, it should work. Just have a look to the source code how the Kamailio side 
its doing it. It might be just a different mode that its used from the library, 
for example.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Jayesh Nambiar 
Sent: Freitag, 6. Oktober 2023 16:52
To: Kamailio (SER) - Users Mailing List 
Cc: Henning Westerholt 
Subject: Re: [SR-Users] Crypto module AES algorithm details

Hi Henning,
Thanks for your responses.
The exact use case is as follows:
- In a custom SIP header, I'll have the number that is supposed to be dialed 
out in AES encrypted format
- I will have to decrypt it using the shared key and IV that was used to 
encrypt this phone number on Kamailio
- Once decrypted, I will have the number to call.
- So the encryption algorithm used by a third party should be same as what is 
being used to decrypt in kamailio.

Any other way of doing this? I can request to change the encryption mechanism 
to the third party if needed. Any suggestions on how to achieve this.

Thanks,

- Jayesh

On Thu, Oct 5, 2023 at 3:13 PM Henning Westerholt 
mailto:h...@gilawa.com>> wrote:
(Please keep the list in CC)

Hello,

The web tools might use another logic internally. I had some success with a 
java library use case and also with PostgreSQL, I think.

A usual use-case is to have an encrypted password value in a DB, for data at 
rest encryption. The password is encrypted from something else. Then inside the 
Kamailio cfg you want to encrypt it on the fly, to use it for example for 
challenging a phone with username/password.

Maybe you can give it a try with some python or other script languages, where 
you can play with the different crypto system parameter more easily.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com


From: Jayesh Nambiar mailto:jayesh1...@gmail.com>>
Sent: Donnerstag, 5. Oktober 2023 06:41
To: Henning Westerholt mailto:h...@gilawa.com>>
Subject: Re: [SR-Users] Crypto module AES algorithm details

Hello Henning,
Thanks for the super fast reply.
I tested this within kamailio 5.3.4 and I can successfully encrypt a header 
value and also the same encrypted value decrypts to proper plain text when.
But when I compare the encrypted text with online resources like 
https://www.devglan.com/online-tools/aes-encryption-decryption and 
https://www.javainuse.com/aesgenerator, their encrypted text value is different 
from what I see from kamailio.
Both these resources produce the same encrypted text while the encrypted text 
from kamailio is different.
How do I validate this?
My use case is as follows:
-- I get an encrypted text in a SIP Header
-- I decrypt it and validate it against some DB
-- If valid proceed or else exit

Now if the algorithm doesnt match exactly, there are chances of error, hence 
asking question on how to validate it.


On Wed, Oct 4, 2023 at 1:43 PM Henning Westerholt 
mailto:h...@gilawa.com>> wrote:
Hello Jayesh,

AFAIK its uses AES 256 with CBC mode. The IV is generated from OpenSSL, e.g. 
https://www.openssl.org/docs/man3.0/man3/EVP_BytesToKey.html

For newer versions I have added the init_vector functionality to enable 
interoperability with other crypto functions, e.g. some databases, java 
frameworks etc. If you want to use this functionality, I’d suggest to update, 
as the 5.3. is also end of life since some time. Otherwise you can of course 
also backport this feature.

Cheers,

Henning


--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com



From: Jayesh Nambiar via sr-users 
mailto:sr-users@lists.kamailio.org>>
Sent: Mittwoch, 4. Oktober 2023 08:54
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>
Cc: Jayesh Nambiar mailto:jayesh1...@gmail.com>>
Subject: [SR-Users] Crypto module AES algorithm details

Hello,
I am running kamailio-5.3.4 on one of my setup and I intend to use the crypto 
module in the same.
I wanted to understand the following details when the module is used:
I understand it uses the AES algorithm, is that correct?
Does it use AES 128, 192 or 256 bit algorithms?
Does it use CBC or ECB mode for AES?
The 5.3 version does not have an parameter for init-vector, so does kamailio 
use any init vector internally in this case?

When i compared the encrypted text that kamailio produces and the ones 
available online, they were producing different outputs even when same shared 
secret was used. Hence asking for more clarification

PS: Upgrading kamailio is my very last option as this is one af an old setup 
which only needs this feature without much changes.

Thanks for any valuable response.

-- Jayesh


__
Kamailio - Users Mailing List - Non Commercial Discu

[SR-Users] Restarts Kamailio after general protection fault

[Daian Conrad via sr-users]

Hi all,

I have started using kamailio as a proxy register for asterisk's and works
fine, but in some moment kamailio show WARNINGs, ALERTS and CRITICAL logs
and restart.

I don't no how debug correctly, but the crash show this log lines


*Oct 16 21:34:26 proxy /usr/sbin/kamailio[2148]: CRITICAL: 
[core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm.
0x7f14a27a5ab8 (address 0x7f14a27a5af0) beginning overwritten
(7f14a27a8e58)! Memory allocator was called from uac: uac_send.c:860.
Fragment marked by UH��AWAVAUATSH��:139726602009368. Exec from
core/mem/q_malloc.c:511.*

-










*Oct 16 21:39:46 proxy /usr/sbin/kamailio[2556]: CRITICAL: 
[core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm.
0x7ff7ad456330 (address 0x7ff7ad456368) beginning overwritten (0)! Memory
allocator was called from uac: uac_send.c:860. Fragment marked by (null):0.
Exec from core/mem/q_malloc.c:511.Oct 16 21:39:46 proxy
/usr/sbin/kamailio[2578]: CRITICAL:  [core/pass_fd.c:277]:
receive_fd(): EOF on 19Oct 16 21:39:46 proxy /usr/sbin/kamailio[2539]:
ALERT:  [main.c:774]: handle_sigs(): child process 2556 exited by a
signal 6Oct 16 21:39:46 proxy /usr/sbin/kamailio[2539]: ALERT: 
[main.c:777]: handle_sigs(): core was not generatedOct 16 21:39:46 proxy
systemd[1]: kamailio.service: Main process exited, code=exited,
status=1/FAILUREOct 16 21:39:46 proxy systemd[1]: kamailio.service: Failed
with result 'exit-code'.Oct 16 21:39:46 proxy systemd[1]: kamailio.service:
Service RestartSec=100ms expired, scheduling restart.Oct 16 21:39:46 proxy
systemd[1]: kamailio.service: Scheduled restart job, restart counter is at
9.Oct 16 21:39:46 proxy systemd[1]: Stopped Kamailio - the Open Source SIP
Server.*


any advice is apreciated

-- 

**Daian Conrad**

E-mail: daian.con...@gmail.com
OpenS Team (DaCoD)
Linux user: #248912
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: UDP Fragmentation webRTC/UDP Call

[Mirko Brankovic via sr-users]

Oh ok

On Mon, Oct 16, 2023, 18:11 Yuriy G  wrote:

>  They actually aren't for the udp leg
>
> On Mon, 16 Oct 2023, 18:09 Mirko Brankovic via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
>> I'm maybe out of context here but i don't think you can remove ssrc
>> headers from sdp since they are crucial in identification of the rtp streams
>>
>> On Mon, Oct 16, 2023, 14:41 Social Boh via sr-users <
>> sr-users@lists.kamailio.org> wrote:
>>
>>> Hello,
>>>
>>> in the rtpengine LOG i can see:
>>>
>>> Oct 16 06:32:53 sip1 rtpengine[146001]: DEBUG: [28vs0pbtdtu7udefti8m]:
>>> ... "*: [ "sdp-attr-remove-audio-ssrc::" ], "replace":* [ "origin",
>>> "session-connection" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [
>>> "demux" ], "SDES": [ "off" ], "call-id": "28vs0pbtdtu7udefti8m",
>>> "via-branch": "z9hG4bK4978560", "received-from": [ "IP4", "186.98.231.105"
>>> ], "from-tag": "h8l2da68sp", "command": "offer" }
>>>
>>> but the ssrc lines still presents in the INVITE sent to sip device.
>>>
>>> Regards
>>>
>>> ---
>>> I'm SoCIaL, MayBe
>>>
>>> El 14/10/2023 a las 12:39 p. m., Social Boh via sr-users escribió:
>>>
>>> Hello,
>>>
>>> I'm trying to using sdp-attr without luck:
>>>
>>> sdp-attr-remove-audio-ssrc:
>>>
>>> in this sentence:
>>>
>>> $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-demux
>>> DTLS=off SDES-off ICE=remove RTP/AVP sdp-attr-remove-audio-ssrc:";
>>>
>>> this to remove two ssrc lines
>>>
>>> Regards
>>>
>>> ---
>>> I'm SoCIaL, MayBe
>>>
>>> El 14/10/2023 a las 11:12 a. m., Richard Fuchs via sr-users escribió:
>>>
>>> On 14/10/2023 02.46, [EXT] Karsten Horsmann via sr-users wrote:
>>>
>>> Hi,
>>>
>>> did you pass over the ice stuff from webrtc to the udp side? You could
>>> strip that of with rtpengine options.
>>>
>>>
>>> With recent versions we even have explicit SDP manipulations options, so
>>> you can use rtpengine to strip attributes that it itself doesn't understand
>>> or process.
>>>
>>> Cheers
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Inquiry Regarding Kamailio Behavior and Drop Requests

[satyaprakash ch via sr-users]

Hi,

We possess a code within Kamailio, which specifically handles malformed SIP
responses. Below is the code snippet:





*reply_routeCopy code if(!sanity_check("17604", "6")) { xlog("Malformed SIP
response from $si:$sp\n"); drop;*

Additionally, we have Kamailio drop request statistics as follows:

Command: *kamctl stats | grep core:drop_requests*
Output of the command: *core:drop_requests = 5*

My queries are:

1. Is the aforementioned "reply_route" related to the drop requests we are
experiencing?
2. If it is not related, what could be the cause of the drop requests?
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: UDP Fragmentation webRTC/UDP Call

[Yuriy G via sr-users]

For the sdp cleanup purpose ( if possibilities of rrpengine are not enough)
I use the next technic:
- Set up write_avp param for the rtpengine module
- call rtpengine manage: handled sdp will be then posted to write_avp pvar.
- use lua/python/etc to call via lua_run(...) (this is for lua )
- handle value of write_avp there
- apply the value to body of the message.

On Mon, 16 Oct 2023, 18:11 Yuriy G,  wrote:

>  They actually aren't for the udp leg
>
> On Mon, 16 Oct 2023, 18:09 Mirko Brankovic via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
>> I'm maybe out of context here but i don't think you can remove ssrc
>> headers from sdp since they are crucial in identification of the rtp streams
>>
>> On Mon, Oct 16, 2023, 14:41 Social Boh via sr-users <
>> sr-users@lists.kamailio.org> wrote:
>>
>>> Hello,
>>>
>>> in the rtpengine LOG i can see:
>>>
>>> Oct 16 06:32:53 sip1 rtpengine[146001]: DEBUG: [28vs0pbtdtu7udefti8m]:
>>> ... "*: [ "sdp-attr-remove-audio-ssrc::" ], "replace":* [ "origin",
>>> "session-connection" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [
>>> "demux" ], "SDES": [ "off" ], "call-id": "28vs0pbtdtu7udefti8m",
>>> "via-branch": "z9hG4bK4978560", "received-from": [ "IP4", "186.98.231.105"
>>> ], "from-tag": "h8l2da68sp", "command": "offer" }
>>>
>>> but the ssrc lines still presents in the INVITE sent to sip device.
>>>
>>> Regards
>>>
>>> ---
>>> I'm SoCIaL, MayBe
>>>
>>> El 14/10/2023 a las 12:39 p. m., Social Boh via sr-users escribió:
>>>
>>> Hello,
>>>
>>> I'm trying to using sdp-attr without luck:
>>>
>>> sdp-attr-remove-audio-ssrc:
>>>
>>> in this sentence:
>>>
>>> $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-demux
>>> DTLS=off SDES-off ICE=remove RTP/AVP sdp-attr-remove-audio-ssrc:";
>>>
>>> this to remove two ssrc lines
>>>
>>> Regards
>>>
>>> ---
>>> I'm SoCIaL, MayBe
>>>
>>> El 14/10/2023 a las 11:12 a. m., Richard Fuchs via sr-users escribió:
>>>
>>> On 14/10/2023 02.46, [EXT] Karsten Horsmann via sr-users wrote:
>>>
>>> Hi,
>>>
>>> did you pass over the ice stuff from webrtc to the udp side? You could
>>> strip that of with rtpengine options.
>>>
>>>
>>> With recent versions we even have explicit SDP manipulations options, so
>>> you can use rtpengine to strip attributes that it itself doesn't understand
>>> or process.
>>>
>>> Cheers
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: UDP Fragmentation webRTC/UDP Call

[Social Boh via sr-users]

hello,

i only a example... not for production.

Regards

---
I'm SoCIaL, MayBe

El 16/10/2023 a las 10:37 a. m., Mirko Brankovic via sr-users escribió:
I'm maybe out of context here but i don't think you can remove ssrc 
headers from sdp since they are crucial in identification of the rtp 
streams


On Mon, Oct 16, 2023, 14:41 Social Boh via sr-users 
 wrote:


Hello,

in the rtpengine LOG i can see:

Oct 16 06:32:53 sip1 rtpengine[146001]: DEBUG:
[28vs0pbtdtu7udefti8m]: ... "*: [ "sdp-attr-remove-audio-ssrc::"
], "replace":* [ "origin", "session-connection" ],
"transport-protocol": "RTP/AVP", "rtcp-mux": [ "demux" ], "SDES":
[ "off" ], "call-id": "28vs0pbtdtu7udefti8m", "via-branch":
"z9hG4bK4978560", "received-from": [ "IP4", "186.98.231.105" ],
"from-tag": "h8l2da68sp", "command": "offer" }

but the ssrc lines still presents in the INVITE sent to sip device.

Regards

---
I'm SoCIaL, MayBe

El 14/10/2023 a las 12:39 p. m., Social Boh via sr-users escribió:

Hello,

I'm trying to using sdp-attr without luck:

sdp-attr-remove-audio-ssrc:

in this sentence:

$xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + "
rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP
sdp-attr-remove-audio-ssrc:";

this to remove two ssrc lines

Regards

---
I'm SoCIaL, MayBe

El 14/10/2023 a las 11:12 a. m., Richard Fuchs via sr-users
escribió:

On 14/10/2023 02.46, [EXT] Karsten Horsmann via sr-users wrote:

Hi,

did you pass over the ice stuff from webrtc to the udp side?
You could strip that of with rtpengine options.


With recent versions we even have explicit SDP manipulations
options, so you can use rtpengine to strip attributes that it
itself doesn't understand or process.

Cheers

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply
only to the sender!
Edit mailing list options or unsubscribe:

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply
only to the sender!
Edit mailing list options or unsubscribe:

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply
only to the sender!
Edit mailing list options or unsubscribe:


__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email tosr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: UDP Fragmentation webRTC/UDP Call

[Yuriy G via sr-users]

 They actually aren't for the udp leg

On Mon, 16 Oct 2023, 18:09 Mirko Brankovic via sr-users, <
sr-users@lists.kamailio.org> wrote:

> I'm maybe out of context here but i don't think you can remove ssrc
> headers from sdp since they are crucial in identification of the rtp streams
>
> On Mon, Oct 16, 2023, 14:41 Social Boh via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
>> Hello,
>>
>> in the rtpengine LOG i can see:
>>
>> Oct 16 06:32:53 sip1 rtpengine[146001]: DEBUG: [28vs0pbtdtu7udefti8m]:
>> ... "*: [ "sdp-attr-remove-audio-ssrc::" ], "replace":* [ "origin",
>> "session-connection" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [
>> "demux" ], "SDES": [ "off" ], "call-id": "28vs0pbtdtu7udefti8m",
>> "via-branch": "z9hG4bK4978560", "received-from": [ "IP4", "186.98.231.105"
>> ], "from-tag": "h8l2da68sp", "command": "offer" }
>>
>> but the ssrc lines still presents in the INVITE sent to sip device.
>>
>> Regards
>>
>> ---
>> I'm SoCIaL, MayBe
>>
>> El 14/10/2023 a las 12:39 p. m., Social Boh via sr-users escribió:
>>
>> Hello,
>>
>> I'm trying to using sdp-attr without luck:
>>
>> sdp-attr-remove-audio-ssrc:
>>
>> in this sentence:
>>
>> $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-demux
>> DTLS=off SDES-off ICE=remove RTP/AVP sdp-attr-remove-audio-ssrc:";
>>
>> this to remove two ssrc lines
>>
>> Regards
>>
>> ---
>> I'm SoCIaL, MayBe
>>
>> El 14/10/2023 a las 11:12 a. m., Richard Fuchs via sr-users escribió:
>>
>> On 14/10/2023 02.46, [EXT] Karsten Horsmann via sr-users wrote:
>>
>> Hi,
>>
>> did you pass over the ice stuff from webrtc to the udp side? You could
>> strip that of with rtpengine options.
>>
>>
>> With recent versions we even have explicit SDP manipulations options, so
>> you can use rtpengine to strip attributes that it itself doesn't understand
>> or process.
>>
>> Cheers
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: UDP Fragmentation webRTC/UDP Call

[Mirko Brankovic via sr-users]

I'm maybe out of context here but i don't think you can remove ssrc headers
from sdp since they are crucial in identification of the rtp streams

On Mon, Oct 16, 2023, 14:41 Social Boh via sr-users <
sr-users@lists.kamailio.org> wrote:

> Hello,
>
> in the rtpengine LOG i can see:
>
> Oct 16 06:32:53 sip1 rtpengine[146001]: DEBUG: [28vs0pbtdtu7udefti8m]: ...
> "*: [ "sdp-attr-remove-audio-ssrc::" ], "replace":* [ "origin",
> "session-connection" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [
> "demux" ], "SDES": [ "off" ], "call-id": "28vs0pbtdtu7udefti8m",
> "via-branch": "z9hG4bK4978560", "received-from": [ "IP4", "186.98.231.105"
> ], "from-tag": "h8l2da68sp", "command": "offer" }
>
> but the ssrc lines still presents in the INVITE sent to sip device.
>
> Regards
>
> ---
> I'm SoCIaL, MayBe
>
> El 14/10/2023 a las 12:39 p. m., Social Boh via sr-users escribió:
>
> Hello,
>
> I'm trying to using sdp-attr without luck:
>
> sdp-attr-remove-audio-ssrc:
>
> in this sentence:
>
> $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-demux
> DTLS=off SDES-off ICE=remove RTP/AVP sdp-attr-remove-audio-ssrc:";
>
> this to remove two ssrc lines
>
> Regards
>
> ---
> I'm SoCIaL, MayBe
>
> El 14/10/2023 a las 11:12 a. m., Richard Fuchs via sr-users escribió:
>
> On 14/10/2023 02.46, [EXT] Karsten Horsmann via sr-users wrote:
>
> Hi,
>
> did you pass over the ice stuff from webrtc to the udp side? You could
> strip that of with rtpengine options.
>
>
> With recent versions we even have explicit SDP manipulations options, so
> you can use rtpengine to strip attributes that it itself doesn't understand
> or process.
>
> Cheers
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Dialog Module: enable_dmq and multiple nodes update SAME profiles_with_value counter?

[Henning Westerholt via sr-users]

Hello,

some installations are using this distributed profile support also with writes 
from different places. It works ok for the usual application (like channel 
limiting, fraud mitigation etc..).

There is no locking in place, so if by some reasons a profile value will be 
updated from two servers the same time, it will probably not be the correct 
value saved in the profile. But usually this self-recovers, for example in the 
night due to the (dialog) timeout. If you are concerned with correctness 
against this kind of race conditions, you should think about using a real 
distributed datastore, like a clustered SQL/NOSQL database. 

Cheers,

Henning

-- 
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

> -Original Message-
> From: Benoit Panizzon via sr-users 
> Sent: Montag, 16. Oktober 2023 15:28
> To: Kamailio (SER) - Users Mailing List 
> Cc: Benoit Panizzon 
> Subject: [SR-Users] Dialog Module: enable_dmq and multiple nodes update
> SAME profiles_with_value counter?
> 
> Hi Team
> 
> I'm still hunting down DMQ dialog issues.
> 
> https://www.kamailio.org/docs/modules/devel/modules/dialog.html#dialog.
> p.enable_dmq
> 
> Quote:
> "Notably, it is not possible to send in-dialog requests on any but the 
> original
> proxy instance."
> 
> I make sure, that if a procied call (with same callID) is being redirected 
> from
> anywhere, it is send to the came dialog aware kamailio instance it originated
> from. This seems to have fixed a lot of issues with dialogues getting 
> corrupted.
> 
> The two main purposed we use dialog is:
> 
> * CDR
> * Channel Counting / Limiting
> 
> modparam("dialog", "profiles_with_value", "custprofilecounter");
> 
> Can a such profile WITH value be written from any node sharing dialog via
> DMQ or is this bound to cause troubes?
> 
> Example.
> 
> Two call get to same customer, but over two different nodes.
> 
> Node A is getting a call:
> 
> set_dlg_profile("custprofilecounter","Customer7664");
> get_profile_size("custprofilecounter","Customer7664","$var(busy_count)");
> 
> => $var(busy_count) is now 1.
> The profile is replicated to Node B and the value can be accessed there.
> 
> While Call on Node A is running, Node B is getting a call to same
> customer:
> 
> set_dlg_profile("custprofilecounter","Customer7664");
> get_profile_size("custprofilecounter","Customer7664","$var(busy_count)");
> 
> => $var(busy_count) is now 2 on Node B.
> 
> Is this value being replicated BACK to Node A where the profile counter
> originally was created?
> 
> As far as I have experienced, this is the case.
> 
> But what happens if the call on Node B is ending before the Call on Node A?
> Will the counter being decreased also correctly be replicated to Node A?
> 
> What happens the other way round?
> 
> What happens if both call end at the same time? Is a race condition possible,
> or is there some sort of locking to prevent this?
> 
> Can I use profiles_with_value the way I use them? Or is this bound to fail
> because it's not supported?
> 
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
> 
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> __
> Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe
> send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Dialog Module: enable_dmq and multiple nodes update SAME profiles_with_value counter?

[Benoit Panizzon via sr-users]

Hi Team

I'm still hunting down DMQ dialog issues.

https://www.kamailio.org/docs/modules/devel/modules/dialog.html#dialog.p.enable_dmq

Quote:
"Notably, it is not possible to send in-dialog requests on any but the
original proxy instance."

I make sure, that if a procied call (with same callID) is being
redirected from anywhere, it is send to the came dialog aware kamailio
instance it originated from. This seems to have fixed a lot of issues
with dialogues getting corrupted.

The two main purposed we use dialog is:

* CDR
* Channel Counting / Limiting

modparam("dialog", "profiles_with_value", "custprofilecounter");

Can a such profile WITH value be written from any node sharing dialog
via DMQ or is this bound to cause troubes?

Example.

Two call get to same customer, but over two different nodes.

Node A is getting a call:

set_dlg_profile("custprofilecounter","Customer7664");
get_profile_size("custprofilecounter","Customer7664","$var(busy_count)");

=> $var(busy_count) is now 1.
The profile is replicated to Node B and the value can be accessed there.

While Call on Node A is running, Node B is getting a call to same
customer:

set_dlg_profile("custprofilecounter","Customer7664");
get_profile_size("custprofilecounter","Customer7664","$var(busy_count)");

=> $var(busy_count) is now 2 on Node B.

Is this value being replicated BACK to Node A where the profile counter
originally was created?

As far as I have experienced, this is the case.

But what happens if the call on Node B is ending before the Call on
Node A? Will the counter being decreased also correctly be replicated
to Node A?

What happens the other way round?

What happens if both call end at the same time? Is a race condition
possible, or is there some sort of locking to prevent this?

Can I use profiles_with_value the way I use them? Or is this bound to
fail because it's not supported?

Mit freundlichen Grüssen

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: UDP Fragmentation webRTC/UDP Call

[Social Boh via sr-users]

Hello,

in the rtpengine LOG i can see:

Oct 16 06:32:53 sip1 rtpengine[146001]: DEBUG: [28vs0pbtdtu7udefti8m]: 
... "*: [ "sdp-attr-remove-audio-ssrc::" ], "replace":* [ "origin", 
"session-connection" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [ 
"demux" ], "SDES": [ "off" ], "call-id": "28vs0pbtdtu7udefti8m", 
"via-branch": "z9hG4bK4978560", "received-from": [ "IP4", 
"186.98.231.105" ], "from-tag": "h8l2da68sp", "command": "offer" }


but the ssrc lines still presents in the INVITE sent to sip device.

Regards

---
I'm SoCIaL, MayBe

El 14/10/2023 a las 12:39 p. m., Social Boh via sr-users escribió:

Hello,

I'm trying to using sdp-attr without luck:

sdp-attr-remove-audio-ssrc:

in this sentence:

$xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-demux 
DTLS=off SDES-off ICE=remove RTP/AVP sdp-attr-remove-audio-ssrc:";


this to remove two ssrc lines

Regards

---
I'm SoCIaL, MayBe

El 14/10/2023 a las 11:12 a. m., Richard Fuchs via sr-users escribió:

On 14/10/2023 02.46, [EXT] Karsten Horsmann via sr-users wrote:

Hi,

did you pass over the ice stuff from webrtc to the udp side? You 
could strip that of with rtpengine options.


With recent versions we even have explicit SDP manipulations options, 
so you can use rtpengine to strip attributes that it itself doesn't 
understand or process.


Cheers

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only 
to the sender!

Edit mailing list options or unsubscribe:

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only 
to the sender!

Edit mailing list options or unsubscribe:__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Discrepancy between RPC stats and real data from the UAC module

[Denys Pozniak via sr-users]

Hello!

We use the UAC module for outbound registrations and when we try to get RPC
statistics we see that the data does not match, what could be the reason?

# kamcmd stats.get_statistics uac:
uac:regactive = 14
uac:regdisabled = 0
uac:regtotal = 0

# kamctl rpc uac.reg_dump | grep flag | grep 20 -c
745

# kamailio -v
version: kamailio 5.6.4 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 10.2.1


-- 

BR,
Denys Pozniak
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe: