[SR-Users] Re: (no subject)

[Sergio Charrua via sr-users]

Hi Brett!

>From what I could understand, my client (a Carrier) assigns services and
products to its customers identified by trunkgroups (depending on the
customer and the service requested, as well as the ingress trunkgroup
the call will be forwarded to a specific egress trunkgroup).
.
The INVITE is sent by customer to the SBC (ingress), where some kind of
process (which i have no details) will decide what IP:Port to forward the
messages to Kamailio with additional infos (Kamailio is listening on
different NICs/IPs/Ports). Then, Kamailio will check on the (external)
routing engine the route to take and forwards to the outbound endpoint.

Depending on the IP:Port that Kamailio receives the call (SBC may choose
one NIC or the other) the request is then received by Kamailio and
verified/processed by the routing engine replying back to kamailio with the
route to take, and then Kamailio forwards to the outbound endpoint (egress
SBC...).

It is a bit confusing, and I want to simplify things as much as possible,
but apparently the old/current solution is set this way and they pretend to
keep the new solution as similar as possible to the old/current solution.
This is mostly due to the billing process, which is very (overly?) complex
and they do not pretend to change it.

IMHO, the routing engine should be much simpler but it is a much more
complex process the Carrier currently has...and wishes to keep.

(sorry for posting without a subject. I did, however, re-posted with
corrected subject)

Atenciosamente / Kind Regards / Cordialement,


*Sérgio Charrua*

On Fri, Jul 12, 2024 at 8:11 PM Brett Nemeroff 
wrote:

> Is there a reason you have to identify the trunk group based on received
> IP/Port? I've seen this as a requirement from some more antiquated systems
> and it's always a pain. It's always better to use source IP or even a trunk
> prefix (dialed number prefix) which isn't really secure, but works when
> security isn't an issue.
>
> If you have to do it that way, I'd probably turn the $Ri/$Rp into some
> sort of cache key like $Ri_$Rp and map it to something like a dispatcher
> setid.
>
> There may be a more modern way to do this, but I don't think there is.
>
> Good luck!
> -Brett
>
>
> On Fri, Jul 12, 2024 at 1:40 PM Sergio Charrua via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
>> Hi all!
>>
>> for a project under development, one requirement is to be able to
>> forward/relay the call to a specific destination depending on which IP
>> Address and Port the call was received by Kamailio.
>> This also means that Kamailio will be listening on multiple IP Address
>> and Ports
>> listen=udp:IP_1:port_1  # trunkgroup 1
>> listen=udp:IP_2:port_2  # trunkgroup 2
>> listen=udp:IP_3:port_3  # trunkgroup 3
>>
>> I know the pv $Ri and $Rp can be used to identify from which IP address
>> and port the message reached Kamailio and having those details, depending
>> on the value, I can define some conditions that allows Kamailio to relay
>> the call to different destination endpoints.
>> For example:
>> - calls from +32 to + 39 received on trunkgroup1 needs to go to Italy SBC
>> address  A.B.C.D
>> - but calls from +32 to +39 received on trunkgroup2 need to go to Germany
>> on SBC address 1.2.3.4 (as it is cheaper)
>>
>> Is there a better way of doing this without using IF/THEN/ELSE or SWITCH
>> blocks and "hard code" destination SBC addresses?
>> I have read the DRouting module's documentation but not sure if it could
>> help and how...
>>
>> Any suggestions?
>>
>>
>>
>> Atenciosamente / Kind Regards / Cordialement,
>>
>>
>> *Sérgio *
>> __
>> 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:
>>
>
>
> --
>
> 
> Brett Nemeroff
> Voice Fox Telephony LLC
> Office: 512-670-8369
> Email: br...@voicefoxtelephony.com
>
__
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: No ACK from Kamailio

[Arseniy Moskvich via sr-users]

Hi John. Thanks for your help.
> Also there is a strange thing that when we receive ACK. Basically, we 
> dispatch our ACK by doing a lookup location but the thing is, when we log the 
> $du, destination is the Kamailio domain, should not be it the user's IP? But 
> in Wireshark we can see PrivateFreeSwitchIP (Source) PrivateKamailioIP 
> (Destination) SIP (Protocol)  Request: ACK 
> sip:usernameA@PrivateKamailioIP;transport=ws | (info) (edited)
> Could you also explain please where exactly should be 
> KSR.rr.record_route_preset? in our ksr_route_dispatch?

2024-05-02T14:35:52.878225+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: ERROR:  [core/kemi.c:97]: 
sr_kemi_core_err(): WITHIN DLG
2024-05-02T14:35:52.878307+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: ERROR:  [core/kemi.c:97]: 
sr_kemi_core_err(): HAS TO TAG
2024-05-02T14:35:52.878341+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: ERROR:  [core/kemi.c:97]: 
sr_kemi_core_err(): ACK RECEIVED!
2024-05-02T14:35:52.878359+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: ERROR:  [core/kemi.c:97]: 
sr_kemi_core_err(): ALERT: WITHIN KSR ROUTE DISPATCH FUNCTION
2024-05-02T14:35:52.878380+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: INFO:  [core/kemi.c:153]: 
sr_kemi_core_log(): 
Debugging - Source IP: PUBLIC_FREESWITCH_IP, Source Port: 5080
2024-05-02T14:35:52.878403+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: INFO:  [core/kemi.c:153]: 
sr_kemi_core_log(): 
Debugging - Destination IP: None, Destination Port: 443
2024-05-02T14:35:52.878423+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: INFO:  [core/kemi.c:153]: 
sr_kemi_core_log(): Match found 
2024-05-02T14:35:52.878468+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: ERROR:  [core/kemi.c:97]: 
sr_kemi_core_err(): 
ALERT: Updated request domain $du to 
sip:kamailio.domain.com:443;transport=ws;r2=on;lr=on
2024-05-02T14:35:52.878488+00:00 ip-private-ip 
/usr/local/kamailio-5.8/sbin/kamailio[136069]: ERROR:  [core/kemi.c:97]: 
sr_kemi_core_err(): 
ALERT: Updated request domain $ru to 
sip:kamailio.domain.com:443;transport=ws;r2=on;lr=on
Best Regards,
Arseniy

> On 2 May 2024, at 16:29, Who AmI  wrote:
> 
> Hey Arseniy,
> 
> I had a similar thing so I tweaked the default config a little. Here is the 
> kemi python bit I use. 
> 
> if KSR.rr.loose_route() > 0:
> if KSR.is_method_in("B"):
> # do accounting ...
> KSR.setflag(FLT_ACC)
> # ... even if the transaction fails
> KSR.setflag(FLT_ACCFAILED)
> elif KSR.is_NOTIFY():
> # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
> KSR.rr.record_route()
> 
> self.ksr_route_relay(msg)
> else:
> if KSR.is_ACK():
> if KSR.tm.t_check_trans() > 0:
> # no loose-route, but stateful ACK
> # must be an ACK after a 487
> # or e.g. 404 from upstream server
> self.ksr_route_relay(msg)
> else:
> self.ksr_route_dispatch(msg) # Goes to my dispatcher logic
> return -255
> 
> KSR.sl.sl_send_reply(404, "No request here")
> return -255
> 
> I use dispatcher to route between destinations and use double rr params as I 
> sit behind NAT and have private endpoints I route to. 
> 
> https://www.kamailio.org/docs/modules/devel/modules/rr.html#rr.p.enable_double_rr
> 
> I also describe the rr params as well as depending on direction (to do NAT 
> traversal.)
> 
> So from PBX to Customer - KSR.rr.record_route_preset("PUB_IP" + ";r2=on", 
> "PRIV_IP" + ";r2=on")
> And from Customer to PBX - KSR.rr.record_route_preset("PRIV_IP" + ";r2=on", 
> "PUB_IP" + ";r2=on") 
> 
> Hope this helps you get it working. 
> 
> John. 
> 
> 
> On Thu, 2 May 2024 at 12:48, Arseniy Moskvich via sr-users 
> mailto:sr-users@lists.kamailio.org>> wrote:
>> Hi everyone. We are new to Kamailio and using Kamailio 5.8 with FreeSwitch.
>> We have the issue with the incoming call from our provider. They are 
>> dropping after 30 seconds. The client doesn't receive ACK from Kamailio. But 
>> FreeSwitch sends ACK to Kamailio. The outbound call is working fine. At the 
>> moment flow is our provider -> FreeSwitch -> Kamailio -> our web client. 
>> Could someone give us some directions please? Please find attached Kemi.py.
>> Thank you so much in advance
>> __
>> 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: No ACK from Kamailio

[Who AmI via sr-users]

Hey Arseniy,

I had a similar thing so I tweaked the default config a little. Here is the
kemi python bit I use.

if KSR.rr.loose_route() > 0:
if KSR.is_method_in("B"):
# do accounting ...
KSR.setflag(FLT_ACC)
# ... even if the transaction fails
KSR.setflag(FLT_ACCFAILED)
elif KSR.is_NOTIFY():
# Add Record-Route for in-dialog NOTIFY as per RFC 6665.
KSR.rr.record_route()

self.ksr_route_relay(msg)
else:
if KSR.is_ACK():
if KSR.tm.t_check_trans() > 0:
# no loose-route, but stateful ACK
# must be an ACK after a 487
# or e.g. 404 from upstream server
self.ksr_route_relay(msg)
else:
self.ksr_route_dispatch(msg) # Goes to my dispatcher
logic
return -255

KSR.sl.sl_send_reply(404, "No request here")
return -255

I use dispatcher to route between destinations and use double rr params as
I sit behind NAT and have private endpoints I route to.

https://www.kamailio.org/docs/modules/devel/modules/rr.html#rr.p.enable_double_rr

I also describe the rr params as well as depending on direction (to do NAT
traversal.)

So from PBX to Customer - KSR.rr.record_route_preset("PUB_IP" + ";r2=on",
"PRIV_IP" + ";r2=on")
And from Customer to PBX - KSR.rr.record_route_preset("PRIV_IP" + ";r2=on",
"PUB_IP" + ";r2=on")

Hope this helps you get it working.

John.


On Thu, 2 May 2024 at 12:48, Arseniy Moskvich via sr-users <
sr-users@lists.kamailio.org> wrote:

> Hi everyone. We are new to Kamailio and using Kamailio 5.8 with FreeSwitch.
> We have the issue with the incoming call from our provider. They are
> dropping after 30 seconds. The client doesn't receive ACK from Kamailio.
> But FreeSwitch sends ACK to Kamailio. The outbound call is working fine. At
> the moment flow is our provider -> FreeSwitch -> Kamailio -> our web client.
>  Could someone give us some directions please? Please find attached
> Kemi.py.
> Thank you so much in advance
> __
> 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: No access to variables within timer route

[dries--- via sr-users]

So the initial idea was to prolonge the expiry of the redis key within the 
timer. The expiration would be set to a value a bit higher than the timer 
interval. At each timer iteration, the key would be renewed.
That way, if a call teardown occurs because of an unexpected event (so no 
BYE/CANCEL), the redis object would expire itself because the timer would stop 
running (and thus renewing the key) if the call transaction had ended?
However, I can't do that since I need to get the call-id/extension within the 
timer route to pick the right key.

So my alternative would be to store the dialogs into redis and loop over those 
within the timer to compare them to the existing callstate keys. If a dialog 
would no longer be known, I could delete the matching callstate key. However, 
it appears that the dialogs aren't cleaned up during unexpected events so it's 
of no use neither?

Regards
__
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: No access to variables within timer route

[Ben Kaufman via sr-users]

What I'm not clear on from your example is the use of the timer:

- Kamailio gets an invite, write a record to redis where the key identifies the 
user.
- On call teardown, find the key and delete it.

What is the timer route doing?  It should be able to read redis.

-Original Message-
From: dries--- via sr-users  
Sent: Thursday, November 30, 2023 8:30 AM
To: sr-users@lists.kamailio.org
Cc: dr...@degendt.com
Subject: [SR-Users] Re: No access to variables within timer route

CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Hi Ben,

I'll try my best to explain the use case here.

I have a direct trunk between our Asterisk and Kamailio servers. My goal is 
that when an agent is already in call, he doesn't get prompted with another 
incoming call on either of his devices. So Asterisk is supposed to perform a 
redis check each time a call goes through the Asterisk queue.

Since Asterisk can't determine the device state here, I've set up a redis 
cluster which is supposed to keep track of the agent's call state. For each 
INVITE in Kamilio, I'm storing a key into redis based on the agent's number, 
for example "callstate_242680". The value is the call-id.
When a BYE/CANCEL is received, I'm retrieving the particular key and comparing 
the current call-id agains the call-id in the redis object. If it matches, I'm 
deleting the object so the extension is "available" again.

This works pretty good but sometimes the keys are stored way too long in case a 
BYE/CANCEL was missed (for example, restart of Kamailio process, network 
interruptions, ...).
I was thinking of setting a redis expiration time for each key, which would be 
prolonged by the timer running in each call transaction. That way I could 
retrieve the agent's number and increase the expiration of the matching redis 
key. I don't think shared memory would be possible since I can't identify the 
call here.

As an alternative, I'm thinking of keeping track of dialogs using dlg_manage() 
and also store these into a local redis server (since db_redis doesn't seem to 
have redis cluster support). That way I can use a timer block to retrieve all 
the stored dialogs and compare them to the stored callstate keys. I've noticed 
however that the tracking of dialogs also depends of that BYE/CANCEL however so 
I don't think it's very usefull.

An alternative method could be to update the redis object in case of a periodic 
ACK but that's no guaruantee. I also don't want the agent to be wrongfully 
"busy" for too long.

I'm still trying to fit all the pieces together, I was just hoping if anyone 
could confirm this is a correct approach?
__
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: No access to variables within timer route

[dries--- via sr-users]

Hi Ben,

I'll try my best to explain the use case here.

I have a direct trunk between our Asterisk and Kamailio servers. My goal is 
that when an agent is already in call, he doesn't get prompted with another 
incoming call on either of his devices. So Asterisk is supposed to perform a 
redis check each time a call goes through the Asterisk queue.

Since Asterisk can't determine the device state here, I've set up a redis 
cluster which is supposed to keep track of the agent's call state. For each 
INVITE in Kamilio, I'm storing a key into redis based on the agent's number, 
for example "callstate_242680". The value is the call-id.
When a BYE/CANCEL is received, I'm retrieving the particular key and comparing 
the current call-id agains the call-id in the redis object. If it matches, I'm 
deleting the object so the extension is "available" again.

This works pretty good but sometimes the keys are stored way too long in case a 
BYE/CANCEL was missed (for example, restart of Kamailio process, network 
interruptions, ...).
I was thinking of setting a redis expiration time for each key, which would be 
prolonged by the timer running in each call transaction. That way I could 
retrieve the agent's number and increase the expiration of the matching redis 
key. I don't think shared memory would be possible since I can't identify the 
call here.

As an alternative, I'm thinking of keeping track of dialogs using dlg_manage() 
and also store these into a local redis server (since db_redis doesn't seem to 
have redis cluster support). That way I can use a timer block to retrieve all 
the stored dialogs and compare them to the stored callstate keys. I've noticed 
however that the tracking of dialogs also depends of that BYE/CANCEL however so 
I don't think it's very usefull.

An alternative method could be to update the redis object in case of a periodic 
ACK but that's no guaruantee. I also don't want the agent to be wrongfully 
"busy" for too long.

I'm still trying to fit all the pieces together, I was just hoping if anyone 
could confirm this is a correct approach?
__
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: No access to variables within timer route

[Ben Kaufman via sr-users]

>From the rtimer documentation overview:

>   The module executes route blocks on a timer base. It can create new timer 
> processes and execute many route blocks on same timer.
>   A static faked SIP message is given as parameter to called functions, so 
> all functions available for REQUEST_ROUTE can be used.


It runs in it's own processes, and as Alex noted $var() is per process.  It's 
not clear if the process re-spawns so setting a variable inside the timer 
action will be retained through multiple executions or not.
As for $avp()s, along with $xavp()s and their assorted variants, these are 
scoped to a SIP transaction, and the timer shouldn't be handling a transaction.

Shared variables and hashtables should be available inside this route, though.

It might be good to clarify what your goal is (why you expect the variables to 
have values in this route).


-Original Message-
From: dries--- via sr-users  
Sent: Wednesday, November 29, 2023 3:36 PM
To: sr-users@lists.kamailio.org
Cc: dr...@degendt.com
Subject: [SR-Users] Re: No access to variables within timer route

CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Sorry, please ignore the variable name typo in the "REFRESH_CALLSTATE_TIMER" 
route in my initial post.

The issue still stands however.

route[REFRESH_CALLSTATE_TIMER] {
xlog("L_INFO", "Testvariable: $var(testvar)\n"); }

I've also tried enabling the timer on start as well  as attempting to use $avp 
instead. All called variables within the route are either 0 or null?
__
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: No access to variables within timer route

[dries--- via sr-users]

Sorry, please ignore the variable name typo in the "REFRESH_CALLSTATE_TIMER" 
route in my initial post.

The issue still stands however. 

route[REFRESH_CALLSTATE_TIMER] {
xlog("L_INFO", "Testvariable: $var(testvar)\n");
}

I've also tried enabling the timer on start as well  as attempting to use $avp 
instead. All called variables within the route are either 0 or null?
__
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: No access to variables within timer route

[Alex Balashov via sr-users]

Hi,

It is important to know that the scope of $var(...) is per-process[1], and 
timer functions run in a different process. 

When REFRESH_CALLSTATE_TIMER runs, it is not in response to any particular SIP 
message or call, and it does not know the context of any particular SIP message 
or call. 

-- Alex

[1] Which also has unexpected consequences when a different SIP message hits 
the same process in which a $var() was set before; they are process-persistent, 
as the documentation notes.

> On 29 Nov 2023, at 16:02, dries--- via sr-users  
> wrote:
> 
> Hi,
> 
> I have a timer which is called each 5 seconds:
> modparam("timer", "declare_timer", 
> "REFRESH_CALLSTATE_TIMER=REFRESH_CALLSTATE_TIMER,5000,slow");
> 
> I'm enabling setting the variable "testvar" and enabling the timer when an 
> INVITE is received:
> if (is_method("INVITE|ACK|UPDATE|CANCEL|BYE")) {
>$var(testvar) = "blablabla";
>timer_enable("REFRESH_CALLSTATE_TIMER", "1");
> ...
> 
> route[REFRESH_CALLSTATE_TIMER] {
> xlog("L_INFO", "Testvariable: $var(test)\n");
> }
> 
> However, the variable is always 0:
> INFO: 

[SR-Users] Re: No

[Henning Westerholt]

Hello Sergey,

your shown number of 500 fragments are not much and should not concern you. I 
would suggest to just increase the shared memory. About 128MB RAM is probably 
not enough for your server, configure it to 256MB or more, if you have.

Cheers,

Henning

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

From: Sergey Safarov 
Sent: Dienstag, 8. August 2023 07:15
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] No

I catched issue with
In the Kamailio logs i see

ssl bug #1491 workaround: not enough memory for safe operation: shm=10219080 
threshold2=11796480

Current stat about shared memory

[root@sbc-a1 ~]# kamctl stats shmem
{
  "jsonrpc":  "2.0",
  "result": [
"shmem:fragments = 528",
"shmem:free_size = 11343104",
"shmem:max_used_size = 124449952",
"shmem:real_used_size = 122874624",
"shmem:total_size = 134217728",
"shmem:used_size = 58728144"
  ],
  "id": 703182
}

But when kamailio started

[root@sbc-a1 ~]# kamctl stats shmem
{
  "jsonrpc":  "2.0",
  "result": [
"shmem:fragments = 122",
"shmem:free_size = 112534264",
"shmem:max_used_size = 22372528",
"shmem:real_used_size = 21683464",
"shmem:total_size = 134217728",
"shmem:used_size = 12833888"
  ],
  "id": 703670
}

What is stange a lot of fragments.
How it can be troubleshooted?
Can memory manager show info about each fragment like when fragment are created 
an and which module requested fragment?
__
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: No voice for webrtc call

[Arun K R]

After loading crypto module into the kernel now I am getting SRTP
authentication failed, kindy see the logs below

Mar 25 10:45:34 debian rtpengine[17868]: o=- 7850469901141480639 2 IN IP4
127.0.0.1
Mar 25 10:45:34 debian rtpengine[17868]: s=-
Mar 25 10:45:34 debian rtpengine[17868]: t=0 0
Mar 25 10:45:34 debian rtpengine[17868]: a=group:BUNDLE 0
Mar 25 10:45:34 debian rtpengine[17868]: a=extmap-allow-mixed
Mar 25 10:45:34 debian rtpengine[17868]: a=msid-semantic: WMS
ukQZUUNqJBfb86Rzru3RA390AAIGX4mzOsH4
Mar 25 10:45:34 debian rtpengine[17868]: m=audio 9 UDP/TLS/RTP/SAVPF 111 63
9 0 8 13 110 126
Mar 25 10:45:34 debian rtpengine[17868]: c=IN IP4 0.0.0.0
Mar 25 10:45:34 debian rtpengine[17868]: a=rtcp:9 IN IP4 0.0.0.0
Mar 25 10:45:34 debian rtpengine[17868]: a=ice-ufrag:ZW7m
Mar 25 10:45:34 debian rtpengine[17868]: a=ice-pwd:R11oi+7clD5K3WHviTxun+qG
Mar 25 10:45:34 debian rtpengine[17868]: a=ice-options:trickle
Mar 25 10:45:34 debian rtpengine[17868]: a=fingerprint:sha-256
83:27:2D:0A:0D:AF:EE:7A:B9:F6:D0:B3:5E:E1:B0:31:70:38:00:AB:E2:90:E4:AA:93:94:BE:0E:22:0A:53:26
Mar 25 10:45:34 debian rtpengine[17868]: a=setup:actpass
Mar 25 10:45:34 debian rtpengine[17868]: a=mid:0
Mar 25 10:45:34 debian rtpengine[17868]: a=extmap:1
urn:ietf:params:rtp-hdrext:ssrc-audio-level
Mar 25 10:45:34 debian rtpengine[17868]: a=extmap:2
http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
Mar 25 10:45:34 debian rtpengine[17868]: a=extmap:3
http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
Mar 25 10:45:34 debian rtpengine[17868]: a=extmap:4
urn:ietf:params:rtp-hdrext:sdes:mid
Mar 25 10:45:34 debian rtpengine[17868]: a=sendrecv
Mar 25 10:45:34 debian rtpengine[17868]:
a=msid:ukQZUUNqJBfb86Rzru3RA390AAIGX4mzOsH4
61406c6f-0991-409d-921a-67c1747ef4b1
Mar 25 10:45:34 debian rtpengine[17868]: a=rtcp-mux
Mar 25 10:45:34 debian rtpengine[17868]: a=rtpmap:111 opus/48000/2
Mar 25 10:45:34 debian rtpengine[17868]: a=rtcp-fb:111 transport-cc
Mar 25 10:45:34 debian rtpengine[17868]: a=fmtp:111
minptime=10;useinbandfec=1
Mar 25 10:45:34 debian rtpengine[17868]: a=rtpmap:63 red/48000/2
Mar 25 10:45:34 debian rtpengine[17868]: a=fmtp:63 111/111
Mar 25 10:45:34 debian rtpengine[17868]: a=rtpmap:9 G722/8000
Mar 25 10:45:34 debian rtpengine[17868]: a=rtpmap:0 PCMU/8000
Mar 25 10:45:34 debian rtpengine[17868]: a=rtpmap:8 PCMA/8000
Mar 25 10:45:34 debian rtpengine[17868]: a=rtpmap:13 CN/8000
Mar 25 10:45:34 debian rtpengine[17868]: a=rtpmap:110 telephone-event/48000
Mar 25 10:45:34 debian rtpengine[17868]: a=rtpmap:126 telephone-event/8000
Mar 25 10:45:34 debian rtpengine[17868]: a=ssrc:199333846
cname:OBdOn05PKdHnvXw9
Mar 25 10:45:34 debian rtpengine[17868]: a=ssrc:199333846
msid:ukQZUUNqJBfb86Rzru3RA390AAIGX4mzOsH4
61406c6f-0991-409d-921a-67c1747ef4b1
Mar 25 10:45:34 debian rtpengine[17868]: ", "replace": [ "origin",
"session-connection" ], "call-id": "oaece23ntismpjeug83i", "received-from":
[ "IP4", "122.161.108.16" ], "from-tag": "pc2bfpeipd", "command": "offer" }
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[core] Using default bitrate of 32000 bps for 2-channel Opus
Mar 25 10:45:34 debian rtpengine[17868]: NOTICE: [oaece23ntismpjeug83i]:
[core] Creating new call
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[core] Subscribing 'pc2bfpeipd' to ''
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[core] Subscribing '' to 'pc2bfpeipd'
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Updating codecs for offerer pc2bfpeipd #1
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec opus/48000/2 (111)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec red/48000/2 (63)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec G722/8000 (9)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec PCMU/8000 (0)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec PCMA/8000 (8)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec CN/8000 (13)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec telephone-event/48000 (110)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec telephone-event/8000 (126)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Updating codecs for answerer  #1
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec opus/48000/2 (111)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec red/48000/2 (63)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding codec G722/8000 (9)
Mar 25 10:45:34 debian rtpengine[17868]: DEBUG: [oaece23ntismpjeug83i]:
[codec] Adding

[SR-Users] Re: No voice for webrtc call

[Arun K R]

You mean

No support for kernel packet forwarding available (encryption cipher
> or HMAC not supported by kernel module

can you suggest how can i add kernel support for cipher or HMAC
encryption if that is the issue.

Thank you


On Fri, Mar 24, 2023 at 5:58 PM Alex Balashov 
wrote:

> It seems to me the answer might be in the logs you posted:
>
> > On Mar 24, 2023, at 3:41 AM, Arun K R  wrote:
> >
> > Mar 24 13:07:02 debian rtpengine[7345]: WARNING:
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]:
> [core] No support for kernel packet forwarding available (encryption cipher
> or HMAC not supported by kernel module)
> > Mar 24 13:07:02 debian rtpengine[7345]: NOTICE:
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]:
> [core] Setting 'non-forwarding' flag for kernel stream due to lack of sinks
> > Mar 24 13:07:03 debian rtpengine[7345]: ERR:
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]:
> [rtcp] SRTCP output wanted, but no crypto suite was negotiated
> > Mar 24 13:07:03 debian rtpengine[7345]: INFO:
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]:
> [core] Removing media stream from kernel: local 10.13.1.127:10940
> > Mar 24 13:07:03 debian rtpengine[7345]: INFO:
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]:
> [core] Kernelizing media stream: 10.13.1.170:15634 -> 10.13.1.127:10940 |
> 10.13.1.127:10960 -> 192.168.30.200:53489
> > Mar 24 13:07:03 debian rtpengine[7345]: WARNING:
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]:
> [core] No support for kernel packet forwarding available (encryption cipher
> or HMAC not supported by kernel module)
>
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> 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: No voice for webrtc call

[Alex Balashov]

It seems to me the answer might be in the logs you posted:

> On Mar 24, 2023, at 3:41 AM, Arun K R  wrote:
> 
> Mar 24 13:07:02 debian rtpengine[7345]: WARNING: 
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: 
> [core] No support for kernel packet forwarding available (encryption cipher 
> or HMAC not supported by kernel module)
> Mar 24 13:07:02 debian rtpengine[7345]: NOTICE: 
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: 
> [core] Setting 'non-forwarding' flag for kernel stream due to lack of sinks
> Mar 24 13:07:03 debian rtpengine[7345]: ERR: 
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: 
> [rtcp] SRTCP output wanted, but no crypto suite was negotiated
> Mar 24 13:07:03 debian rtpengine[7345]: INFO: 
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: 
> [core] Removing media stream from kernel: local 10.13.1.127:10940
> Mar 24 13:07:03 debian rtpengine[7345]: INFO: 
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: 
> [core] Kernelizing media stream: 10.13.1.170:15634 -> 10.13.1.127:10940 | 
> 10.13.1.127:10960 -> 192.168.30.200:53489
> Mar 24 13:07:03 debian rtpengine[7345]: WARNING: 
> [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: 
> [core] No support for kernel packet forwarding available (encryption cipher 
> or HMAC not supported by kernel module)


-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
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: (no subject)

[glengagne]

In fact, to summarize my issue, I see that :

At Termination, PCSCF is asking PCRF to setup QoS for a flow between the RTP 
Port of the offer it received and the RTP Port of the anwer it received. Whole 
it should ask to set QoS for a flow between the RTP port it allocated (after 
rewriting SDP Offer) and the RTP Port of the answer it got from B.

Same kind of issue at Origination.

Best Regards
__
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: (no subject)

[gui]

Hi Henning

Thanks for your answer, I do not see anything wrong in the SDP, RTP
ports are correctly allocated on Invite and 183 session progress.

Regards

Le mer. 8 mars 2023 à 08:16, Henning Westerholt  a écrit :
>
> Hello,
>
> did not looked into the pcap, but you should try to debug why it uses the 
> wrong port. Maybe you are adding wrong SDP content to the SIP messages you 
> route in your setup. If its add wrong SDP, try to debug why this happens.
>
> Cheers,
>
> Henning
>
> -Original Message-
> From: gui 
> Sent: Freitag, 3. März 2023 16:29
> To: sr-users@lists.kamailio.org
> Subject: [SR-Users] (no subject)
>
> Hello
>
> I have an issue with Rx in my VolTE call Flow. Please refer to picture and 
> pcap in annex.
> I am using same rtp engine at origination and termination.
> I am sending rtpmanage for invite and 183 session progress at both 
> origination and termination.
>
> My issue is that Rx is not sending for the proper media flow component to 
> PCRF.
> At origination it is considering a media flow between A 50034 and RTPEngine 
> 49186 (instead of considering RTP Engine Port 49152) At Termination it is 
> considering a media flow between B 50054 and RTPEngine 49132 (instead of 
> considering RTP EnginePort 49170)
>
> Any idea why?
__
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: (no subject)

[Henning Westerholt]

Hello,

did not looked into the pcap, but you should try to debug why it uses the wrong 
port. Maybe you are adding wrong SDP content to the SIP messages you route in 
your setup. If its add wrong SDP, try to debug why this happens.

Cheers,

Henning

-Original Message-
From: gui  
Sent: Freitag, 3. März 2023 16:29
To: sr-users@lists.kamailio.org
Subject: [SR-Users] (no subject)

Hello

I have an issue with Rx in my VolTE call Flow. Please refer to picture and pcap 
in annex.
I am using same rtp engine at origination and termination.
I am sending rtpmanage for invite and 183 session progress at both origination 
and termination.

My issue is that Rx is not sending for the proper media flow component to PCRF.
At origination it is considering a media flow between A 50034 and RTPEngine 
49186 (instead of considering RTP Engine Port 49152) At Termination it is 
considering a media flow between B 50054 and RTPEngine 49132 (instead of 
considering RTP EnginePort 49170)

Any idea why?
__
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: no autocomplete for kamcmd for latest debian packages

[Karsten Horsmann]

Hi,

as work around you can kamcmd help ¦ grep dispatcher or whatever to get an
hint.
Or if you on Centos ;)

Ovidiu Sas  schrieb am Sa., 4. Feb. 2023, 05:53:

> Hello,
>
> The latest debian packages are built without autocomplete for kamcmd.
> Do we have the libreadline-dev package installed on the build machine?
> I know that we have kamctl rpc  and kamcli, but if we are still
> shipping kamcmd, it should have the autocomplete feature enabled.
>
> Regards,
> Ovidiu Sas
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
> __
> 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: no autocomplete for kamcmd for latest debian packages

[Henning Westerholt]

Hello,

should be fixed in new minor versions, when they are released.

commit a70b6bf09c73d961ebea1947216757fafb951c24
Author: Henning Westerholt 
Date:   Wed Dec 14 08:38:12 2022 +

utils/kamcmd: add missing USE_READLINE define for pkg-config build, related 
to #3284

Cheers,

Henning

-Original Message-
From: Ovidiu Sas  
Sent: Saturday, February 4, 2023 5:16 AM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] no autocomplete for kamcmd for latest debian packages

Hello,

The latest debian packages are built without autocomplete for kamcmd.
Do we have the libreadline-dev package installed on the build machine?
I know that we have kamctl rpc  and kamcli, but if we are still shipping 
kamcmd, it should have the autocomplete feature enabled.

Regards,
Ovidiu Sas

--
VoIP Embedded, Inc.
http://www.voipembedded.com
__
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: