[SR-Users] Re: [EXTERNAL] Fwd: rtpengine timestamp jumps

[Richard Fuchs via sr-users]

On 24/05/2024 15.34, Jeff Brower wrote:

Hi Richard-

Thanks very much for your reply. Please allow me to answer in reverse 
order - first in the Wireshark screencap (see link below) the two red 
arrows are pointing at media packets, not SID. The sequence number 
advances by 1 but the RTP timestamp advances 640 (should be 320 for 
AMR-WB).


Second, the stream is not transcoded, but I'm trying to narrow down 
whether there may be "rate correction" happening, and if so where it's 
occurring. The carrier says they are not sending media packets with 
non-matching sequence number and RTP timestamp increments, at least 
not on a regular basis (i.e. 10 to 15% of a 2 hour call).


If there's no transcoding then it's certainly not rtpengine manipulating 
either sequence numbers or timestamps. Both of these values are 
passthrough in non-transcoding cases.


Your assumption that RTP timestamp advances must match sequence number 
advances might be flawed. Sequence numbers should match the sequence of 
packets, and timestamps should match the times. DTX in particular allows 
for "gaps" in the timestamp series while not having gaps in the 
sequencing (as the packets are still in order). AMR is a codec which 
explicitly allows and supports DTX as a feature. Under DTX it is 
perfectly allowable to have the sequence number increase by 1 while the 
timestamp increases by 640 or 960 or 1280 or 2560 or any other non-ptime 
amount, as long as the actual real timing of the packets (roughly) lines 
up with the timestamps. Generally the RTP marker bit should be set after 
one such event to signify that the RTP clock should be resynchronised, 
and this is what your pcap shows.


But again this is not something that rtpengine has anything to do with.

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:

[SR-Users] Re: [EXTERNAL] Fwd: rtpengine timestamp jumps

[Richard Fuchs via sr-users]

I don't know if my original reply to this went through to the list or 
not, so I'm sending it again:


Is this stream actually produced by rtpengine (i.e. from transcoding) or 
just a relay? Because this looks like just regular DTX behaviour from a 
normal AMR sender, i.e. send a SID frame and then not transmit anything 
for up to 200 ms or so. Rtpengine itself doesn't produce DTX streams.


Cheers


On 21/05/2024 12.45, Jeff Brower via sr-users wrote:

Rtpengine support-

I am re-posting again, as I noticed on the SR-USERs web page no HTML 
or inline images are showing 
(https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/latest?count=200).


The Wireshark screencap that demonstrates the issue is uploaded at:

https://www.signalogic.com/images/rtpengine_wireshark_capture_timestamp_jump.png

all other info remains the same.

Thanks, Jeff

- Forwarded message from Jeff Brower  -
   Date: Fri, 17 May 2024 17:10:10 +
   From: Jeff Brower 
Subject: Fwd: [SR-Users] rtpengine timestamp jumps
 To: sr-users@lists.kamailio.org

Reposting this. If there is an issue with HTML format and/or wireshark 
screen cap and I need to upload that separately somewhere else, please 
let me know. Thanks.


-Jeff

- Forwarded message from Jeff Brower  -
   Date: Thu, 09 May 2024 05:32:27 +
   From: Jeff Brower 
Subject: [SR-Users] rtpengine timestamp jumps
     To: sr-users@lists.kamailio.org

 Hi rtpengine experts,

We have some customers processing long multi-party call pcaps using 
mediaMin who are reporting large amounts of packets with timestamp 
jumps but no packet loss (for instance 10% of packets over a 1 hr 45 
min call). For example, in the Wireshark excerpt shown below, packets 
6 and 8 sent by rtpengine show a timestamp increment of 640, but 
sequence number increment of 1:


 [screencap link at 
https://www.signalogic.com/images/wireshark_capture_timestamp_jump.png]


In the mediaMin output packet log we typically see sections similar to:

   :
   :
Seq num 98584  timestamp = 3902252372, rtp pyld len = 33 
media-R
Seq num 98585  timestamp = 3902252692, rtp pyld len = 33 
media
Seq num 98586  timestamp = 3902253012, rtp pyld len = 33 
media-R
Seq num 98587  timestamp = 3902253332, rtp pyld len = 33 
media
Seq num 98588  timestamp = 3902253652, rtp pyld len = 33 
media-R
Seq num 98589  timestamp = 3902253972, rtp pyld len = 33 
media
Seq num 98590  timestamp = 3902254292, rtp pyld len = 33 
media
Seq num 98591  timestamp = 3902254612, rtp pyld len = 33 
media-R
Seq num 98592  timestamp = 3902254932, rtp pyld len = 33 
media
Seq num 98593  timestamp = 3902255252, rtp pyld len = 33 
media
Seq num 98594  timestamp = 3902255572, rtp pyld len = 33 
media-R
Seq num 98595  timestamp = 3902255892, rtp pyld len = 33 
media
Seq num 98596  timestamp = 3902256212, rtp pyld len = 33 
media
Seq num 98597  timestamp = 3902256532, rtp pyld len = 33 
media
Seq num 98598  timestamp = 3902256852, rtp pyld len = 33 
media-R
Seq num 98599  timestamp = 3902257172, rtp pyld len = 33 
media
Seq num 98600  timestamp = 3902257492, rtp pyld len = 33 
media-R
Seq num 98601  timestamp = 3902257812, rtp pyld len = 33 
media
Seq num 98602  timestamp = 3902258132, rtp pyld len = 33 
media
Seq num 98603  timestamp = 3902258452, rtp pyld len = 33 
media
Seq num 98604  timestamp = 3902258772, rtp pyld len = 33 
media-R
Seq num 98605  timestamp = 3902259092, rtp pyld len = 33 
media

   :
   :

where media-R packets are timestamp gap repairs (i.e. frame loss 
concealment). The behavior tends to be bursty, but once it gets going 
it goes for a while and seems relatively consistent.


Is this expected behavior for rtpengine ? If so is rptengine in turn 
dealing with some type of "slow packet rate" issue from a remote sender ?


Thanks, Jeff
- End forwarded message -

- End forwarded message -


__
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: [EXTERNAL] Kamailio and RTPengine and no voice on calls

[Richard Fuchs via sr-users]

On 10/05/2024 04.49, palany wrote:


Thank you Richard. I have changed my rtpengine.conf as per your 
instruction and now sdp m is now showing the correct ip but the o is 
still showing the private ip as below.


The o= line is not relevant for the media flow, but you can add 
`replace-origin` to your signalling flags to also replace it.


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:

[SR-Users] Re: [EXTERNAL] Kamailio and RTPengine and no voice on calls

[Richard Fuchs via sr-users]

On 09/05/2024 10.16, palany via sr-users wrote:


I have an AWS ec2 instance with Kamailio and rtpengine configured. I 
am having a challenge of no voice on calls. I have sip client on my 
mobile phone and soft phone on my laptop and the two are on different 
networks behind nat. Signaling is working fine but there is no media 
and when I check on on the SDP the call logs are showing private ips 
instead of public ips : o=- 3 2 IN IP4 192.168.1.33 and c=IN IP4 
172.31.36.50. I understand this is a NAT issue but I am failing to see 
where is the challenge. My rtpengine seems to be working fine .


Most likely you need to use the "advertised address" notation in your 
interface config as on AWS generally you don't have the public IP 
address bound on a local interface. So something like


interface = external/172.31.36.50!13.246.88.123;internal/172.31.36.50

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:

[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption

[Richard Fuchs via sr-users]

On 10/04/2024 17.46, David Cunningham wrote:
I was asking whether OpenSSL was used because of a question we had 
about FIPS validation. FIPS requires that all cryptography components 
go through a validation process, which some versions of OpenSSL (but 
not all) have done.


My understanding is that RTPengine uses OpenSSL for the AES, but not 
for all of the key functions. Is that right? If so then even if we're 
using a FIPS validated version of OpenSSL, not all of the cryptography 
components of RTPengine would be using it, so we wouldn't be fully 
FIPS validated.


DTLS is entirely provided by OpenSSL, except for the raw network I/O.

Once the DTLS handshake completes, the SRTP keys are extracted out of 
OpenSSL.


The cipher implementation (AES) as well as the digest implementation 
(SHA-1) are provided by OpenSSL.


For AEAD-GCM, the entire encryption, decryption, and authentication 
process is handled by OpenSSL.


For the other cipher suites (AES-CM, AES-F8), OpenSSL is used to create 
the block key via AES, and then rtpengine has its own implementation of 
the counter-mode cipher to apply the AES key to the SRTP payload. This 
is because SRTP uses a peculiar version of AES-CM that OpenSSL doesn't 
directly support. (This really isn't much more than XOR'ing the AES key 
onto the SRTP payload and so isn't really doing much cryptography.)


For SRTP in the kernel module, it's more or less exactly the same, 
except that the kernel's crypto API is used instead of OpenSSL. (DTLS is 
done in userspace only.)


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:

[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption

[Richard Fuchs via sr-users]

On 09/04/2024 23.14, Alex Balashov via sr-users wrote:

Exchanging keys directly in the SDP body is rather suboptimal from a security 
standpoint, even if the signalling is encrypted, but it's certainly simpler.

I suppose that makes DTLS "more secure", but in every other sense, I'm not sure DTLS is 
"better". W3C WebRTC standards mandate DTLS-SRTP, as far as I know, so I suppose it's 
more fit for that purpose.


To add to that, one benefit DTLS has over SDES is that key exchange can 
happen as soon as media can flow, which theoretically can be immediately 
after the initial offer (invite), especially if ICE is also in use, as 
is the case with WebRTC. Whereas with SDES, since key exchange happens 
in-line with the signalling, key exchange can only be completed once an 
answer to the initial offer has been received. Which means that at least 
in theory DTLS is faster to establish media than SDES is. (Caveat: Not 
all DTLS clients actually allow this.)


As for security: The most commonly used SRTP key types that can be 
exchanged are the same between SDES and DTLS, so in this aspect neither 
is more secure than the other. As for key exchange itself, DTLS is more 
sophisticated as it uses a peer-to-peer (with rtpengine being one of the 
peers in your case) public-key exchange to set up SRTP, whereas SDES 
relies on the signalling transport to be encrypted, which almost 
certainly isn't the case peer-to-peer (i.e. any involved signalling 
gateway or proxy can inspect or possibly modify the keys).


In theory DTLS also allows extra trust to be established via 
verification of the DTLS certificates, but in practice this isn't 
usually done as the certificates are often self-signed.


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:

[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption

[Richard Fuchs via sr-users]

On 09/04/2024 17.40, David Cunningham via sr-users wrote:
How does rtpengine get the TLS certificates, and what crypto library 
does it use (openssl?).


SRTP itself doesn't use any certificates, and is not TLS. The underlying 
cipher (AES) is provided by OpenSSL, while the SRTP implementation 
itself is its own.


TLS and certificates are relevant when it comes to the key exchange. 
With SDES, keys are exchanged in-line and nothing else is needed.


The other option is DTLS: Here a self-signed certificate is used 
(generated at startup), and keys are exchanged using the DTLS 
implementation provided by OpenSSL. The certificate's fingerprint is 
exchanged in-line and that's how the peer's certificate is verified. 
After the key exchange completes, the SRTP keys are extracted from the 
handshake, DTLS is done, and the rest is just regular SRTP.


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:

[SR-Users] Re: Standard on RTP ports

[Richard Fuchs via sr-users]

On 15/12/2023 14.04, [EXT] Calvin E. via sr-users wrote:

Probably this:

https://github.com/sipwise/rtpengine/blob/master/debian/changelog

ngcp-rtpengine (12.1.0.0+0~mr12.1.0.0) unstable; urgency=medium
  * [2fa121c] MT#54294 add GPU support
  * [b3544be] MT#54294 packaging for rtpengine-gpu
  * [079bfac] MT#55283 fix up pkg generator for -gpu packages

I'm guessing this uses underlying FFmpeg CUDA support.


It's a bit more complicated than this as ffmpeg doesn't have GPU support 
for audio processing.


So we took the Opus codec, ported it to CUDA, heavily modified it for 
parallel execution, and combined it with some other codecs (G.711 for 
now) to be able to do transcoding on a GPU.


This isn't relevant for the regular media proxy (RTP passthrough) use 
case though.


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:

[SR-Users] Re: Sharing load between rtpengine servers

[Richard Fuchs via sr-users]

On 08/11/2023 15.33, [EXT] David Cunningham via sr-users wrote:

Hello,

We have a Kamailio configuration with the following, however all the 
load is going to the server at 22.22.22.22 (hiding the real IP 
obviously) instead of being shared evenly between 22.22.22.22 and 
33.33.33.33. Can anyone please tell me why? The rtpengine server at 
11.11.11.11 is intended to only receive calls if the other two are 
offline. Thank you very much.


#!define RTPENGINE_ADDR "udp:11.11.11.11:7724=1 
udp:22.22.22.22:7724= udp:33.33.33.33:7724="


modparam( "rtpengine", "rtpengine_sock", RTPENGINE_ADDR )


I recall this was discussed on the mailing list before, but of course I 
can't find the relevant thread.


What happens is that for legacy reasons (read: I don't really know why), 
if the default hashing algorithm (simple hash over call ID) is used, 
then the resulting weight is capped at 255. That means that no proxies 
beyond an accumulated weight of 255 will ever be used.


So either keep the sum of your weights below that, or use a different 
hashing algorithm (CRC or SHA-1).


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:

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

[Richard Fuchs via sr-users]

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:

[SR-Users] Re: Wrong RTP endpoint announced by Kamailio when forwarding calls, but looks correct from RTPEngine

[Richard Fuchs via sr-users]

On 12/10/2023 09.02, [EXT] Leonardo Arena via sr-users wrote:

I've opened the captured traffic with Wireshark and I've found out
that Kamailio is actually forwarding the call with a double SDP
header. ngrep was showing only a partial header. I think this happens
because when forwarding the call I use rtpengine_offer() and not
rtpengine_manage(). I've tried using rtpengine_manage() and I get only
one SDP header but with the (wrong) private IP address. I've tried
also rtpengine_delete() before rtpengine_offer() but there's always a
double header. Ideas? Still digging..


Duplicated SDPs in combination with rtpengine are usually the result of 
manipulating the SDP multiple times, e.g. using sdpops first and then 
passing the SDP to rtpengine (or the other way around) without 
msg_apply_changes() in between, or perhaps invoking the rtpengine 
methods multiple times within the same script run.


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:

[SR-Users] Re: Choose RTP port in routing script

[Richard Fuchs via sr-users]

On 26/09/2023 08.10, [EXT] Duarte Rocha via sr-users wrote:

Hello all,

I have my rtpengine configured to use ports 2 - 5 for RTP in 
rtpengine.conf.


Now i want to able to select the port or the port range in a call by 
call basis. Is that possible?


Not currently possible with rtpengine. There's only a single port range 
and it's not possible to choose a particular port.


Why do you want to choose a particular port?

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:

[SR-Users] Re: ICMP Port Unreachable using loopback interface with ethernet IP

[Richard Fuchs]

On 11/05/2023 16.00, [EXT] Calvin E. wrote:
We added a listen on localhost and forced the outside application 
server to return 127.0.0.1 instead of the IP of Kamailio. This worked 
as expected, but wasn't the solution we were looking for.


It turns out that enabling sysctl net.ipv4.ip_forward=1 resolves the 
original issue. Is IP Forwarding a normal requirement for Kamailio in 
general?


For reference, running "ip route get _interface_ip_" on other Linux 
servers confirms that the "lo" interface is used when sending packets 
to an assigned Ethernet IP address.


That is quite surprising as IP forwarding is something very much 
different, and definitely shouldn't be required for normal communication 
with a locally bound address (and with that communication going over the 
`lo` interface being completely expected).


You mentioned the address being a floating address. Was this address 
perhaps not bound when Kamailio was started? (Doing this requires the 
`ip_nonlocal_bind` sysctl to be enabled, although in that case I guess 
the :5060 port also wouldn't be open.)


"Port unreachable" could also indicate a REJECT firewall rule, perhaps 
something restricting `lo` to be used only with localhost addresses, 
and/or something restricting the external IP address only to its 
respective eth interface? (Although enabling IP forwarding wouldn't 
change anything in that case.)


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:

[SR-Users] Re: rtpengine module: sdp offer in message reply, ip protocol version not passed to rtpengine?

[Richard Fuchs]

On 02/05/2023 12.13, [EXT] Benoît Panizzon wrote:

Invite+SDP from B to A

It looks like this works as expected. A SDP c= line is created
containing an ipv6 address.

Sorry, I was mistaking. No it is not :-/

So I guess I have to look at the location or RURI-Host to determine
the IP protocol and tell rtpengine what to use.


This is the way.

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:

[SR-Users] Re: Strange RTCP issue

[Richard Fuchs]

On 27/04/2023 11.08, [EXT] Kiss Zoltán wrote:


Everything is working fine, but with some clients (like Grandstream 
phone) the RTCP session wants to go tot he private address of the 
phone. Here is the log of one of these strange calls:


Apr 27 16:54:38 rtp1 rtpengine[2273]: INFO: 
[312ed76c31f21b71452e91e5184ad25b@172.16.2.210:5060]: [core] - 
Port  178.238.213.14:11088 <> 81.183.216.3:5068 , SSRC 77c19488, 625 
p, 107500 b, 0 e, 29 ts


Apr 27 16:54:38 rtp1 rtpengine[2273]: INFO: 
[312ed76c31f21b71452e91e5184ad25b@172.16.2.210:5060]: [core] - 
Port  178.238.213.14:11089 <> 10.0.5.192:5069  (RTCP), SSRC 0, 0 p, 0 
b, 0 e, 43 ts


As you can see the RTP itself is okay, but the RTCP will somehow go to 
the private address. If we tracing the sdp messages in sngrep, then we 
can see that Kamailio transforming IP addresses for the backend 
servers to the public (and the private address of the rtpengine) 
addresses.


This is almost certainly because the client has not /sent/ any RTCP, and 
therefore rtpengine was not able to learn the correct public non-NAT 
address for the RTCP port, leaving you with the address that was 
advertised in the SDP.


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:

[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?

[Richard Fuchs]

On 25/04/2023 10.59, [EXT] Olle E. Johansson wrote:

One workaround (kludge/hack) I've seen is to store the last successful SDP 
somewhere, then intercept and drop the 488 and replay the last offer/answer 
with the stored SDPs. (Absolutely not something I would consider a proper 
solution…)

That will break more than it helps.
But is there a way to “revert” back. Let’s say I store the last successful SDPs 
- can I transmit them to RTPengine to revert. If I have the dialog module I 
could very well save them within the context of the dialog.
Yeah that's exactly what I was talking about. You can replay the last 
successful rtpengine_offer()/_answer() with a stored SDP, and that would 
revert the call to the last state. That's what read_sdp_pv and 
write_sdp_pv config params are for.

Would be nice to have a “rtpengine_revert()” command that resets back to the 
state before the last INVITE, the last successful state with complete offer and 
answer.


That's what a theoretical handling of 488 etc would entail, yes...

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:

[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?

[Richard Fuchs]

On 25/04/2023 02.39, [EXT] Olle E. Johansson wrote:

So how do we handle a reinvite that is not accepted and tell RTPengine to fall 
back?

Consider:

1. Successfull INVITE/200OK/ACK with alaw only
 - RTPengine setup and active
2. Re-invite with video added
 - RTP engine active with video
3. Re-invite denied with 488
- How do we tel RTPengine to skip video?

In many cases a re-invite is just hold/off hold or mute/off mute so it’s no 
problem, But if we have significant modification of media - ports, types and 
codecs (if RTPengine transcodes) a failed re-invite could be hurtful to the 
call. Unless there’s some code in RTPengine to handle this.


Currently there's no way to signal these types of events to rtpengine, 
and so there's no automatic handling of them. It would be a great 
feature to have, just someone needs to implement it 嵐


An additional complication is that an event such as a 488 might require 
cooperation from the SIP layer to rectify (depending on the exact 
scenario), e.g. another invite/ok subsequent to the 488, but without 
knowledge of the opposite-side device. In general this would go beyond 
the scope of what a plain SIP proxy does.


One workaround (kludge/hack) I've seen is to store the last successful 
SDP somewhere, then intercept and drop the 488 and replay the last 
offer/answer with the stored SDPs. (Absolutely not something I would 
consider a proper solution...)


For the concrete example you've given, that currently wouldn't even work 
with explicit signalling to rtpengine as we don't support manipulating 
entire media sections yet. That's a feature that should™ hopefully™ be 
coming soon™.


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:

[SR-Users] Re: Rtpengine: no audio after kernelization.

[Richard Fuchs]

On 17/04/2023 02.55, [EXT] Tim Bowyer wrote:


Hello Everyone,

Looks to be related to the team interface after all, which is strange.

Have confirmed that after getting rid of the LACP/Team interface, 
media is flowing as expected after kernelization.


...

Is it worth opening an issue in the rtpengine repo?

That depends on whether 1) it's reproducible, and 2) it's something that 
is supposed to work.


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:

[SR-Users] Re: Rtpengine: no audio after kernelization.

[Richard Fuchs]

On 22/03/2023 08.19, [EXT] Tim Bowyer wrote:


Evening!

I ditched firewalld and swapped to configuring iptables manually…

I’ve also made some basic calls with media going in/out of the same 
interface and I’m still seeing the audio stop completely or become 
one-way once kernelized.


On the two different interfaces, I get no-way audio once kernelized.  
Weird!


Could this be related to the kernel module being unsigned (running 
CentOS 8 Stream)?


kernel: xt_RTPENGINE: loading out-of-tree module taints kernel.

kernel: xt_RTPENGINE: module verification failed: signature and/or 
required key missing - tainting kernel


kernel: Registering xt_RTPENGINE module - version git-HEAD-5bf2c50a

systemd-modules-load[781]: Inserted module 'xt_RTPENGINE'


No, that is expected and perfectly fine.


Have been pulling my hair out!

[root@blahblah zgadmin]# iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source   destination

rtpengine udp  --  anywhere anywhere

ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED


ACCEPT icmp --  anywhere anywhere

//cut//

Chain FORWARD (policy ACCEPT)

target prot opt source   destination

Chain OUTPUT (policy ACCEPT)

target prot opt source   destination

Chain rtpengine (1 references)

target prot opt source   destination

RTPENGINE udp  --  anywhere anywhere RTPENGINE 
id:0


That looks fine. How about the actual network setup? Any network 
namespaces, policy routing, or other unusual setup in place?


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:

[SR-Users] Re: webrtc audio issue

[Richard Fuchs]

This is still the same thing that I already responded to on GH, as well 
earlier on this mailing list: 
https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/message/WG44P2L4X5SLUG6HUJ3QQDI7R6G2RGPT/


You have no connectivity to your calling party. No ICE candidates are 
provided in the offer, and no trickle ICE SDP fragments are passed to 
rtpengine. The calling party could start making ICE/STUN requests to the 
ICE candidate provided by rtpengine, but this never happens (no activity 
on that port), possibly because it's a private address and may not be 
reachable by the calling client.



On 13/03/2023 03.19, [EXT] Arun K R wrote:

Hello,

I have installed Kamailio 5.6 in debian 11 and RTPengine 11.3 also in 
the same server. I have configured kamailio to work as webrtc server 
and it forwards the registration to asterisk. Now when I am trying 
call from jssip webrtc client it reaches kamailio and route it through 
private interface to asterisk server. Asterisk then route it to the 
provider server. When i make a call asterisk server recives rtp from 
the provider and convert the rtp to srtp and sending back to kamailio. 
but there is no sound for webrtc from public internet . Also i am 
getting warning (SRTCP /RTP output wanted, but no crypto suite was 
negotiated)


webrtc from Local network works fine with VPN

For normal udp call without webrtc works fine.

Kamailio having two interfaces, interface1 is private 10.13.1.140 and 
interface 2 is publi ip 100.x.x.x


webrtc client sends calls to the public ip interface 100.x.x.x and 
kamaiio routes the call to the asterisk via private interface 10.13.1.140.
asterisk server sends the call to remote server and gets the rtp back 
from that
Asterisk server ---converts RTP to SRTP and forward to > kamailio 
10.13.1.140
but there is nothing happens after that, please help me on this i am 
new to kamailio and rtpengine.


The issue is only for webrtc from public internet. But when using 
webrtc from LAN works fine



below are the logs

__
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: webrtc from public internet have no voice

[Richard Fuchs]

As mentioned on GH, you have 1) rtpengine running on a private IP 
address, so is not directly reachable from the public internet, and 2) 
an offer from a WebRTC client using trickle ICE, which doesn't provide 
any ICE candidates, and so that client isn't reachable from rtpengine. 
Either give rtpengine a public address so that it can be reached from 
outside, and/or (preferable "and") make sure the trickle ICE fragments 
being sent by the WebRTC client (usually as SIP INFO) are passed to 
rtpengine (and hoping that one of the candidates are a public address 
that is reachable by rtpengine).


Cheers


On 09/03/2023 11.31, mail4aru...@gmail.com wrote:

Hello,
I have installed Kamailio 5.6 in debian 11 and RTPengine 11.3 also in the same 
server. I have configured kamailio to work as webrtc server and it forwards the 
registration to asterisk. Now when I am trying call from jssip webrtc client it 
reaches kamailio and route it through private interface to asterisk server. 
Asterisk then route it to the provider server. When i make a call asterisk 
server recives rtp from the provider and convert the rtp to srtp and sending 
back to kamailio. but there is no sound for webrtc from public internet . Also 
i am getting warning (SRTCP /RTP output wanted, but no crypto suite was 
negotiated)

webrtc from Local network works fine with VPN

For normal udp call without webrtc works fine.

Kamailio having two interfaces, interface1 is private 10.13.1.140 and interface 
2 is publi ip 100.x.x.x

webrtc client sends calls to the public ip interface 100.x.x.x and kamaiio 
routes the call to the asterisk via private interface 10.13.1.140.
asterisk server sends the call to remote server and gets the rtp back from that
Asterisk server ---converts RTP to SRTP and forward to > kamailio 
10.13.1.140
but there is nothing happens after that, please help me on this i am new to 
kamailio and rtpengine.

The issue is only for webrtc from public internet. But when using webrtc from 
LAN works fine



below are the logs

Mar 9 20:21:02 debian /usr/local/sbin/kamailio[11778]: INFO: 

[SR-Users] Re: How to access rtpengine rtcp-metrics?

[Richard Fuchs]

On 02/03/2023 09.51, [EXT] Benoit Panizzon wrote:

onreply_route[MANAGE_REPLY]
{
[...]
 rtpengine_manage();
 xlog("L_INFO", "$cfg(route): $rm reply MOS: 
$avp(mos_average)\n");
}

Messages pass those blocks, $avp(mos_average) is 'null' no mater what.

What am I missing?

In the syslog output of rtpengine I see there is rtcp data.


Have you verified that MOS is actually reported by rtpengine back to 
Kamailio? If you enable debug logging in rtpengine you can see it 
printed in the response messages sent back to Kamailio.


Another thing you can check is to see if other metrics are populated, in 
particular the ones not depending on bidirectional RTCP, such as jitter. 
Also see if explicitly calling rtpengine_query() makes a difference.


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:

[SR-Users] Re: Rtpengine: no audio after kernelization.

[Richard Fuchs]

On 02/03/2023 22.13, [EXT] Tim Bowyer wrote:


I’m having the same issue but believe it’s related to my network topology.

I have multiple carrier-facing NIC’s and an internal NIC on each media 
proxy.


Is this configuration supported?

This should work fine as long as it's "just" normal IP routing and 
doesn't involve network namespaces or cgroups or things like that. 
(Source-based routing should work, but other policy routing options 
might not.)


[r...@per01-mtp01.dev.xyz blah]# cat /proc/rtpengine/0/list

local inet4 203.x.x.x:4

stats:   350880 bytes, 2040 
packets,    0 errors


RTP payload type   0:    0 bytes,    0 
packets


RTP payload type   8:   350880 bytes, 2040 
packets


SSRC in: 65aa31af

output #0

src inet4 10.y.y.y:4

dst inet4 203.x.x.x:39302

This looks like the kernel module is receiving packets just fine and is 
sending them out (or trying to). It should work as long as the kernel is 
able to route packets from the 10.x address to the 203.x address.


I was also looking to find some config to make this working using 
firewalld rules, fishing through the Sipwise repos I stumbled across 
some firewalld rules as part of their automated builds but didn’t have 
any luck with them


If somebody had some rules I could try would be much appreciated!

There's two things here. One is the necessary "-j RTPENGINE" iptables 
rule, which is needed to pass the packets to the kernel module to 
process. The bundled systemd startup scripts are in charge of adding and 
removing that. However, if you have separate firewall scripts which may 
override or remove this rule in some way, then this needs to be taken 
into account, so you don't lose this rule. But from your /proc output 
it's obvious that this rule is in place.


The other thing is that rtpengine is able to manage firewall rules for 
individual ports directly, opening and closing the firewall rules as 
individual ports are opened and closed. This is entirely optional, and 
needs to be enabled explicitly, and is in fact not recommended usage.


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:

[SR-Users] Re: RTPengine multiple setID sockets

[Richard Fuchs]

On 24/01/2023 06.05, [EXT] John Hardiman wrote:

...

So anything between FreeSWITCH and Kamailio/RTPengine uses the private 
IP's for media, the rest use public IP's.


It is good to note that the RTPengine's are the same in each set (3 
total RTPengine's), just using the public/private IP's based on set ID.


...

# Public IP's ID 1:

modparam("rtpengine", "rtpengine_sock", "1 == udp:5.5.5.5:2223 
udp:6.6.6.6:2223 udp:7.7.7.7:2223")


# Internal IP's ID 2:

modparam("rtpengine", "rtpengine_sock", "2 == udp:10.0.0.1:2223 
udp:10.0.0.2:2223 udp:10.0.0.3:2223")


 ...

Using the above, the Kamailio starts fine and understands/loads each 
set of RTPengine's and calls work with audio. but regardless of the 
set number used (even only using set 2 in both) it defaults to public 
IP's in the SDP. (This is the only place in the config where this 
function is defined)


Rtpengine doesn't distinguish between which IP address you use to 
communicate with it, so using multiple sets to talk to the same 
rtpengine instances (just with different IPs) is pointless for this purpose.


Instead, what you want to do is list the interfaces you have available 
in rtpengine's config file with different names (e.g. "int" for just the 
private address, and "ext" for the same address but with the public 
address as "advertised address") and then use the `direction=` flags in 
your calls to rtpengine_manage to tell rtpengine which interfaces to use.


The first `direction=` corresponds to where the message is coming from 
(, the second corresponds to where it's going to. So for example, if the 
SDP has an internal/private address in it, and you know the outgoing SDP 
will go an external system requiring the public address,  you would use 
`direction=int direction=ext`.


There's no need to have multiple rtpengine sets configured in Kamailio 
for this.


HTH

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:

[SR-Users] Re: rtpengine - SRTP <> RTP

[Richard Fuchs]

On 20/01/2023 10.10, [EXT] Krzysztof Drewicz wrote:

I think that i need more in depth understanding how this works - i
need to use rtpengine_ofer - before TLS w/ sRTP hits my kamailio
script ? and then, rtpengine_manage towards the no-SRTP endpoint, and
then - finally rtpengine_answer - ? So - 6 times - rtpengine_X ? (one
for incoming leg, 2nd for - outgoing)


You just need one invocation each: one for the offer, one for the 
answer. (Assuming single offer/answer exchange and no branches.)


You can use rtpengine_manage() for either of them if you want to let the 
module figure out whether the message is an offer or an answer. But you 
will want to use different flags for the two cases, mostly depending on 
where the message is going to.


If the message is going to a plain RTP (non-SRTP, non-ICE, etc) client, 
use "RTP/AVP ICE=remove" etc. If the message is going to an SRTP, 
ICE-enabled client, use "RTP/SAVPF ICE=force" etc.


For the "direction=" flags you want to pay attention both to where the 
message is coming from (first "direction") and where it is going to 
(second "direction").


If you want to manually distinguish between offers and answers instead 
of using rtpengine_manage(), in general you only need to give these 
flags for the offer. In that case you can then leave the flags for the 
answer (mostly - there are some exceptions) blank.


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:

[SR-Users] Re: rtpengine - SRTP <> RTP

[Richard Fuchs]

On 20/01/2023 01.19, kdrewicz+kamai...@cludo.pl wrote:

I try to workout if - currently it would work, or - where and how to debug more:

I face - 2 interfacec - public internet (so, TLS + sRTP) is desired
and private - old infrastructure - i mus only use plain RTP
...
all i do is:

 if (proto==TLS) {
 rtpengine_manage("RTP/AVP ICE=remove replace-session-connection 
replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding 
direction=external direction=internal record-call=on");
 } else if ($ru =~ "transport=tls") {
 rtpengine_manage("DTLS=on SRTP AVPF ICE=remove 
replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA 
record-call=on allow-transcoding direction=internal direction=external record-call=on 
media-address=1.2.3.24");
 }


Double check that one of these is actually triggered for each 
offer/answer (invite/ok).


(Your usage of `media-address` is probably not what you want - usually 
it's the "advertised address" syntax of the interface config that people 
want)



what i see:
...
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: 
[c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag '', created 60:00 ago 
for branch ''
...
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: 
[c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] - Port 172.23.9.70:30014 
<>:0, SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: 
[c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] - Port 172.23.9.70:30015 
<>:0 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 
b, 0 e


This looks like no "answer" was seen, which is what makes me think your 
script doesn't actually trigger the function for the answer.


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:

[SR-Users] Re: rtp lost package in 300 concurrent calls and above

[Richard Fuchs]

On 16/01/2023 14.48, [EXT] Mohammad Reza Keshavarzianpoor wrote:

What is the ethernet network speed?


its 1Gb esxi


Try outside of a virtualised environment.

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:

[SR-Users] Re: rtp lost package in 300 concurrent calls and above

[Richard Fuchs]

On 16/01/2023 11.25, [EXT] Mohammad Reza Keshavarzianpoor wrote:

yes I tried tcp dump and it says ubuntu is dropping packets
618916 packets captured
1242894 packets received by filter
623578 packets dropped by kernel


"Packets dropped by kernel" means that some aspect of the system isn't 
keeping up with the network traffic. That could be tcpdump itself (see 
`-n` and `-B` options), or it could be the network hardware or driver, 
or the CPU or some other component could be maxed out (perhaps the disk 
that tcpdump is writing to isn't keeping up).


If you can't eliminate packet drops after making sure that it's not 
tcpdump itself that is the bottleneck, perhaps look into what tunables 
your network hardware supports (see ethtool), especially regarding RX 
queues.


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:

Re: [SR-Users] Rtpengine: no audio after kernelization.

[Richard Fuchs]

On 13/12/2022 09.04, [EXT] Michel Pelletier wrote:

Hello,

Thank you for your reply.  I checked the versions and they look good.  
xt_RTPENGINE is 11.1.1.3 and the daemon is 11.1.1.3-1~bpo11+1.  
Looking at /proc/rtpengine/0/list I see the packet and byte counters 
incrementing normally with 0 errors.  In wireshark, capturing on any, 
I see the stream coming in on the private network interface but 
nothing going out through the public network interface.  Everything is 
good until 5 seconds into the call when the kernelization happens.


Does the destination address seen in /proc match what is expected?

Any unusual network setup involved? Policy routing, network namespaces, 
containers, anything like that?


Cheers


__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Rtpengine: no audio after kernelization.

[Richard Fuchs]

On 12/12/2022 14.53, [EXT] Michel Pelletier wrote:
I am proxying all RTP through RTPEngine.  Everything works fine until 
about 5 seconds into the call, when rtpengine enters kernelization, 
after which all RTP forwarding ceases. I've checked the required 
iptables entries, and all looks good.


Inspect /proc/rtpengine/0/list while a call is running, in particular 
paying attention to the packet and byte counters.


Also double check that the version of the rtpengine daemon matches the 
version of the kernel module (and that the module has been reloaded if 
there have been any upgrades - `dmesg` or `kern.log` are good places to 
check that).


Cheers


__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailio & rtpengine question

[Richard Fuchs]

On 14/10/2022 07.22, [EXT] Gerry Kernan wrote:


Hi Henning

Issue could be that I’m trying to do something that’s not possible .

We have an asterisk server behind kamailio .  kamailio and asterisk 
are on the same subnet 10.3.1.0/24 . kamailo/rtpeengine are configured 
to advertise its WAN IP . would this mess up SIP/RTP from kamailio to 
the asterisk server.



Yes.

To make this work, you either need a WAN/NAT setup that is able to 
reflect traffic back into the internal network, or (much better) 
configure rtpengine with two network interfaces, one with and one 
without the advertised address, and then tell rtpengine as part of the 
signalling coming from Kamailio which direction the message is flowing. 
Use two `direction=` options in the offer with the respective interface 
names, and then SDPs going to Asterisk will have the internal address, 
and SDPs going outside will have the WAN address.


Cheers
__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailio & rtpengine question

[Richard Fuchs]

On 10/10/2022 08.58, [EXT] Gerry Kernan wrote:


Hi

Im using rtpengine_offer as below

rtpengine_offer("trust-address replace-origin 
replace-session-connection ICE=remove")


is there another flag I need to set to change c=in to the WAN alias?

rtpeengine.conf

interface as set as below

### for different advertised address:

interface = 10.3.1.6!20.82.X.X


...


c=IN IP4 10.3.1.6

t=0 0

m=audio 32080 RTP/AVP 0 8 103...

If you have an advertised address configured in rtpengine.conf with the 
`!` notation, then this address should be in the outgoing SDP. Double 
check that this configuration is actually active and that rtpengine is 
actually being engaged for the call.


Cheers
__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] play_media sounds interrupted

[Richard Fuchs]

On 09/10/2022 10.52, [EXT] Stepan Kislyakov wrote:


Hi,

I'm using latest kamailio 5.6.2 and rtpengine.

I need to play announcement to both parties when call is answered by 
callee. Now I run play_media in event route but when audio start 
announcement sounds like we have a 50% packet loss. After it is 
completed there is no problem with audio both sides.  I figured out 
that if i do block_media() my announcement play perfectly but i dont 
understand how to do unblock_audio() after announcement ends.


The duration of the media playback is returned from the play_media() 
command (see `media_duration` modparam). You could use some sort of 
timer to invoke media unblocking after media playback ends. Sadly my 
Kamailio-Fu isn't strong enough to be able to tell you how to run this 
sort of timer. :)


Cheers


__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Error in RTP engine setup

[Richard Fuchs]

On 04/10/2022 10.59, [EXT] palany wrote:

Hi Richard

I installed from the package from git (git clone
https://github.com/sipwise/rtpengine.git) and built the .deb packages and
use the following command to install the packages.
dpkg -i ngcp-rtpengine-daemon_*.deb ngcp-rtpengine-iptables_*.deb
ngcp-rtpengine-kernel-dkms_*.deb.

The version for RTPENGINE is mr11.1.0.0.

Which method of installation does include this rtpengine-utils package?


Building the .deb packages like this would also produce the -utils 
package. Maybe you just need to install it? Even though I'm surprised 
you could install the -daemon package without being given a dependency 
error.


Cheers


__
Kamailio - Users Mailing List - Non Commercial Discussions
 * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
 * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Error in RTP engine setup

[Richard Fuchs]

On 04/10/2022 08.24, [EXT] palany wrote:

I have installed  RTPENGINE on debian 11 and on starting it I am getting the
following errors.

Oct 04 12:14:39 ip-172-31-26-106 systemd[1]: Starting NGCP RTP/media Proxy
Daemon...
Oct 04 12:14:39 ip-172-31-26-106 ngcp-rtpengine-iptables-setup[4655]:
/usr/sbin/ngcp-rtpengine-iptables-setup: 15:
/usr/libexec/rtpengine/rtpengine-get-table: not found
Oct 04 12:14:39 ip-172-31-26-106 rtpengine[4659]: INFO: [crypto] Generating
new DTLS certificate
Oct 04 12:14:39 ip-172-31-26-106 rtpengine[4659]: ERR: [core] FAILED TO
CREATE KERNEL TABLE 0 (No such file or directory), KERNEL FORWARDING
DISABLED
Oct 04 12:14:39 ip-172-31-26-106 rtpengine[4659]: INFO: [core] Startup
complete, version 11.1.0.0+0~mr11.1.0.0 git-master-c53f213f
Oct 04 12:14:39 ip-172-31-26-106 systemd[1]: Started NGCP RTP/media Proxy
Daemon.
Oct 04 12:14:39 ip-172-31-26-106 rtpengine[4659]: INFO: [http] Websocket
listener thread running


Which version and how was it installed? In recent version the helper 
script rtpengine-get-table is part of the rtpengine-utils package, which 
is a dependency of the rtpengine-daemon package, so it should be present.


Cheers


__
Kamailio - Users Mailing List - Non Commercial Discussions
 * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
 * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine + Kamailio state question

[Richard Fuchs]

On 30/09/2021 13.34, [ EXT ] Alex Balashov wrote:

On Sep 30, 2021, at 1:32 PM, Richard Fuchs  wrote:

On 30/09/2021 13.17, [ EXT ] Alex Balashov wrote:

I’m not sure how the mapping works internally. But whatever the operation is, 
is that value stored somewhere or possible to store somewhere so as to persist 
across restarts in a turn-key way?

AFAICR the node is selected based on a deterministic hash over the call ID. So 
as long as the config doesn't change between restarts, the node selected from 
any particular call ID would remain the same.

The exception is cases where the selected node was not available and the call 
then had to go to a secondary fallback node. AFAIK this association is stored 
in memory only and would be lost after a restart (which would become a problem 
if the previously unavailable node is now back up).


Thanks for that. That accounts for how a Call-ID is mapped to a node within a 
set. But what if the set ID chosen for a particular call is nonstandard, i.e. 
expressly overridden with set_rtpengine_set()? Is that knowledge somehow 
available after a restart?

No there's no persistent state at all. I would suggest to always 
explicitly select the appropriate set before every invocation of any 
function (or at least once at the beginning of the script) regardless of 
the use case.


Cheers


__
Kamailio - Users Mailing List - Non Commercial Discussions
 * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
 * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine + Kamailio state question

[Richard Fuchs]

On 30/09/2021 13.17, [ EXT ] Alex Balashov wrote:

I’m not sure how the mapping works internally. But whatever the operation is, 
is that value stored somewhere or possible to store somewhere so as to persist 
across restarts in a turn-key way?


AFAICR the node is selected based on a deterministic hash over the call 
ID. So as long as the config doesn't change between restarts, the node 
selected from any particular call ID would remain the same.


The exception is cases where the selected node was not available and the 
call then had to go to a secondary fallback node. AFAIK this association 
is stored in memory only and would be lost after a restart (which would 
become a problem if the previously unavailable node is now back up).


Cheers


__
Kamailio - Users Mailing List - Non Commercial Discussions
 * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
 * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio/rtpengine not populating mos avp stats?

[Richard Fuchs]

This should be fixed now.

Cheers

On 20/07/2021 20.23, [ EXT ] Anthony Joseph Messina wrote:

Yep.  No problem -- that's why I wanted to ask first.  Thanks again.  I'll
keep an eye out.  -A

On Tuesday, July 20, 2021 6:46:40 PM CDT Richard Fuchs wrote:

I haven't had a chance to look at it yet. There's been a lot of construction
going on in current master (and some more to come) so it's quite possible
that this is fallout from that.

Cheers


On 20/07/2021 19.15, [ EXT ] Anthony Joseph Messina wrote:
Thanks, Henning.  I rebuilt with that commit reverted and it didn't make a
difference.  I wasn't sure if there were rtpengine-side changes or kamailio-
side changes that might be necessary.  I've seen @rfuchs chime in on this
list from time-to-time so I'll gather up some more information before
filing a ticket.  -A

On Tuesday, July 20, 2021 9:00:38 AM CDT Henning Westerholt wrote:
Hello,

one month ago was a fix in this area (4399fe5243), but not much changes
since then.

If no reply from somebody else that observe a similar issue, just create an
issue on our github tracker with more details.

Cheers,

Henning

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

-Original Message-
From: sr-users  On Behalf Of Anthony
Joseph Messina Sent: Saturday, July 17, 2021 7:06 AM
To: Kamailio Users Mailing List 
Subject: [SR-Users] Kamailio/rtpengine not populating mos avp stats?

I'm using Kamailio compiled from the current 5.5 tip (1f9f6fff6e), and
rtpengine compiled from the current master (6e160da4).

While rtpengine is working quite well, within the past month or so, I've
noticed that Kamailio isn't populating the mos* related AVPs.  I see
continued upstream rtpengine work stream handling, etc. -- should I wait or
try to debug?

Thanks -A


__
Kamailio - Users Mailing List - Non Commercial Discussions
 * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
 * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio/rtpengine not populating mos avp stats?

[Richard Fuchs]

I haven't had a chance to look at it yet. There's been a lot of 
construction going on in current master (and some more to come) so it's 
quite possible that this is fallout from that.


Cheers


On 20/07/2021 19.15, [ EXT ] Anthony Joseph Messina wrote:

Thanks, Henning.  I rebuilt with that commit reverted and it didn't make a
difference.  I wasn't sure if there were rtpengine-side changes or kamailio-
side changes that might be necessary.  I've seen @rfuchs chime in on this list
from time-to-time so I'll gather up some more information before filing a
ticket.  -A

On Tuesday, July 20, 2021 9:00:38 AM CDT Henning Westerholt wrote:

Hello,

one month ago was a fix in this area (4399fe5243), but not much changes
since then.

If no reply from somebody else that observe a similar issue, just create an
issue on our github tracker with more details.

Cheers,

Henning

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

-Original Message-
From: sr-users  On Behalf Of Anthony
Joseph Messina Sent: Saturday, July 17, 2021 7:06 AM
To: Kamailio Users Mailing List 
Subject: [SR-Users] Kamailio/rtpengine not populating mos avp stats?

I'm using Kamailio compiled from the current 5.5 tip (1f9f6fff6e), and
rtpengine compiled from the current master (6e160da4).

While rtpengine is working quite well, within the past month or so, I've
noticed that Kamailio isn't populating the mos* related AVPs.  I see
continued upstream rtpengine work stream handling, etc. -- should I wait or
try to debug?

Thanks -A

__
Kamailio - Users Mailing List - Non Commercial Discussions
   * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Getting MOS feedback from rtpengine

[Richard Fuchs]

On 14/05/2021 11.57, [ EXT ] Barry Flanagan wrote:


In more recent versions of rtpengine you can enable local RTCP 
generation and this should give you stats even if the clients don't 
send RTCP.


I am running rtpengine 8.5.3.2 - how would I enable this feature or 
what version would I need?


This is available from 9.2 onwards. Simply add `generate-RTCP` to your 
offer or answer flags and this will switch from RTCP passthrough to 
locally generated RTCP for that call.


Cheers


__
Kamailio - Users Mailing List - Non Commercial Discussions
 * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
 * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Getting MOS feedback from rtpengine

[Richard Fuchs]

Are your RTP clients sending RTCP? MOS calculation depends on RTCP. You 
can look in rtpengine's log, at the end of the call the MOS score is 
logged together with other stream stats.


In more recent versions of rtpengine you can enable local RTCP 
generation and this should give you stats even if the clients don't send 
RTCP.


Cheers


On 14/05/2021 09.52, [ EXT ] Barry Flanagan wrote:

Hi

Using Kamailio 5.4.4 on Debian Buster. I am trying to get feedback of 
the MOS scores at call end. However the variables are always .


I have the modparams set as follows:

# - rtpengine params -
modparam("rtpengine", "rtpengine_sock", "udp:localhost:2223")
modparam("rtpengine", "rtpengine_disable_tout", -1)
modparam("rtpengine", "rtpengine_tout_ms", 2000)
modparam("rtpengine", "rtpengine_allow_op", 1)
modparam("rtpengine", "mos_min_pv", "$avp(s:mos_min)")
modparam("rtpengine", "mos_max_pv", "$avp(s:mos_max)")
modparam("rtpengine", "mos_average_pv", "$avp(s:mos_avg)")
modparam("rtpengine", "mos_average_packetloss_pv", 
"$avp(s:mos_avg_packetloss)")

modparam("rtpengine", "mos_average_jitter_pv", "$avp(s:mos_avg_jitter)")
modparam("rtpengine", "mos_average_roundtrip_pv", 
"$avp(s:mos_avg_roundtrip)")


I am trying to log the values from within the dialog:end event_route:

event_route[dialog:end] {
    rtpengine_delete();
    xlog("L_INFO","mos_avg=$avp(mos_avg), 
packetloss_avg=$avp(mos_avg_packetloss), 
jitter_avg=$avp(mos_avg_jitter), latency_avg=$avp(mos_avg_roundtrip), 
sip_last_reply=$rs   - $ci\n");

    return;
}

Am I missing something? I have tried rtpengine_query and 
rtpengine_manage in place of the _delete and also tried placing this 
in the BYE handling section of WITHIN_DIALOG but no joy.


Any assistance much appreciated!

-Barry





__
Kamailio - Users Mailing List - Non Commercial Discussions
   * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] start_recording and stop_recording inside event_route[xhttp:request]

[Richard Fuchs]

On 28/04/2021 10.53, [ EXT ] Володимир Іванець wrote:

Hello!

I'm testing call recording with Rtpengine. It works fine when the 
"record-call=on" flag is added to the /rtpengine_offer/ or 
/start_recording/ is used in the *request_route*.


But I was wondering if the call recording can be managed by a separate 
application. So I add the following lines to the 
*event_route[xhttp:request]* and triggered it with an HTTP request 
after the call was established. The call-id value was taken from the 
Rtpengine log and sent with the request.


/  if ($hu =~ "^/CALL_RECORD_START/") {/
/    $var(call_id) = /"call-id=" + /$(hu{s.select,2,/});/
    xlog("L_DBG", "$var(call_id)");
/    start_recording($var(call_id));/
//exit;
/  }/

If you have to reason to go through Kamailio for this, you can simply 
trigger the command from any other external application. There's a 
sample script included in the repo that can be used for this purpose 
directly (making use of the Perl module that is also included): 
https://github.com/sipwise/rtpengine/blob/master/utils/rtpengine-ng-client


There's also a nodejs client that I'm aware of: 
https://github.com/davehorton/rtpengine-client


Or you can hand-roll the request and talk to rtpengine via HTTP or 
Websocket for example.


Cheers

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Help required in sipwise rtpengine-ng-client and rtpengine-ctl

[Richard Fuchs]

On 21/01/2021 00.32, mahesh prasad behera wrote:

Hi Team,

We are using sipwise rtpengine on platform centos 7. To get call 
related statistics from rtpengine. We tried to use utils 
"rtpengine-ng-client" and "rtpengine-ctl". But for us both of them are 
not working.


*Rtpengine process status:*
[root@ctl utils]# ps -ef |grep rtpengine
root      3924   668  0 00:11 pts/0    00:00:00 grep --color=auto 
rtpengine
root     20502 20499  0 Jan19 ?        00:10:02 ../sbin/rtpengine -f 
--num-threads 4 -i pub/10.211.160.132  -i 
priv/10.211.160.132  -n 127.0.0.1:8500 
 -c 127.0.0.1:8500  -m 
32001 -M 32500 -T 184 -o 90 -d 4 -s 900 -p /var/run/rtpengine1.pid 
--scheduling rr --priority 37

[root@ctl utils]#

* rtpengine-ng-client:*
When i ran rtpengine-ng-client, I was getting Bencode.pm missing so I 
have manually installed perl bencode library 
"perl-Convert-Bencode-1.03-9.el7.noarch.rpm"

Now when i ran rtpengine-ng-client i am getting below error
[root@ctl utils]# ./rtpengine-ng-client list
*Undefined subroutine ::bencode called at 
/usr/local/lib64/perl5/NGCP/Rtpengine.pm line 33. *


That's a different Perl module (Convert::Bencode instead of Bencode). If 
there's no RPM for the Bencode module, you should be able to install it 
through CPAN.

*rtpengine-ctl:*
When i ran  ./rtpengine-ctl -ip 127.0.0.1:8500  
list , We are not getting any valid response from rtpengine.
[root@ctl utils]# ./rtpengine-ctl -ip 127.0.0.1:8500 
 list

*Inside do while after call socket->recv(response, 1024*1024*10)*


Not sure what this is about, but `list` is not a complete CLI command. 
Try `list sessions all`. You can also talk to the CLI port with 
something like netcat, e.g. `echo list sessions all | nc localhost 8500`


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio as MS-Teams SBC

[Richard Fuchs]

On 19/01/2021 07.11, Daniel-Constantin Mierla wrote:

Hello,

I built rtpengine deb packages for debian just a few days ago and all 
went fine. I used the file mr8.5.1.5.tar.gz from the github releases 
of rtpengine project.


However, I noticed that some past releases fail to build because of 
the tests. I had to edit a bit the Makefile to disable the tests target.


If some of the tests are causing a problem, you can let me know and I'll 
see if they can be defused to make things work for everybody.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio RTP proxy require?

[Richard Fuchs]

On 17/12/2020 09.00, Sergio Charrua wrote:

Personally I use NATHelper and RTPEngine modules

RTPEngine, afaik, is the latest and upgraded version of RTPProxy 
(please, anyone correct me if that is not the case)


They serve a similar purpose, but they're unrelated products and 
rtpengine is not based on rtpproxy at all.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

[Richard Fuchs]

Use IPv6 

Cheers

On 07/12/2020 23.01, David Cunningham wrote:

Hello,

We have a problem with a SIP doorbell device which sends media one way 
only, and NAT at the receiving device.


When the doorbell button is pressed it makes a call to a configured 
destination. Since the doorbell only sends and doesn't receive it 
sends the INVITE with sendonly in the SDP, and the destination then 
replies with a 200 OK with recvonly in the SDP. The problem is that 
the destination is behind NAT, and its reply contains a private 
network IP in the SDP.


Normally Asterisk when nat=yes works around that by adjusting the 
destination for RTP to be the address it actually receives audio from, 
however because this device is recvonly Asterisk never receives audio 
from it. This means Asterisk keeps trying to send the doorbell's RTP 
to the private network IP which of course fails, and the destination 
never gets the RTP from the doorbell.


We haven't found a solution in Asterisk to this, so are now looking to 
Kamailio which acts as a load-balancing proxy in front of Asterisk for 
one. For example, maybe we could use fix_nated_sdp, but only on 200 
OK's with recvonly.


Has anyone else encountered this, and are there any recommended solutions?

Thank you in advance!

--
David Cunningham, Voisonics Limited
http://voisonics.com/ 
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 14.04, Andrew Chen wrote:
Sure...I understand ICE has its own setup workflow than SIP but it's 
also important that rtpengine uses the rtp path that's negotiated in 
the SIP or else it can cause confusion (to those who don't understand 
ICE very well like me).


There is no RTP path negotiated through SIP. There is only a number of 
possible paths, which are compiled from the list of candidates that each 
side advertises. ICE then checks which paths work, and then finally 
chooses the one with the highest priority.


The only way to have a single media path that is negotiated through SIP 
is if you don't use ICE.


Cheers



___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 13.36, Andrew Chen wrote:
Hmm..that's interesting.  You would guess that the rtpengine binary 
process shouldn't start connecting ICE candidates once the SIP part is 
fully negotiated, which should trigger the rtpengine module on the 
Kamailio to tell rtpengine binary.."ok..you can start associating now..."


Not really. Why would you think that? ICE and SIP are really largely 
unrelated, and ICE processing starts as soon as possible so that media 
can flow as soon as possible. Any delay in ICE processing leads to 
delays in establishing the call or the media flows. (Trickle ICE exists 
partly for that reason.) In particular early media would break if ICE 
had to wait for SIP to finish.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 13.10, Andrew Chen wrote:
So from a SIP point of view, the 200 OK should of sent the final 
negotiation of SDP once the client ACK's it right?


The requirement to send an updated offer once ICE has completed with the 
final negotiated candidates existed in the original ICE RFC, but I 
believe it has been removed in the newer ICE RFC (I'm not 100% sure 
about that though). For rtpengine that requirement certainly doesn't 
exist and it's happy to negotiate and conclude ICE without a final 
updated offer. Also rtpengine itself cannot trigger such an updated 
offer since it's not directly in the SIP path, so that would have to be 
left up to the clients. So in short, a single offer/answer exchange is 
enough to get ICE started and it can complete negotiation out of band 
without further signalling.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 11.39, Andrew Chen wrote:
oh...that's the IPv6 address of the STUN server, not the ipv6 of the 
rtpengine instance.


Ok. From rtpengine's point of view, this is one of the client's IP 
addresses. The ICE candidate in the SDP is the client telling rtpengine: 
This is one of my own addresses (`typ host`) and I can receive media 
here. It is also listed (by the client who has sent the SDP) as the 
highest priority candidate, and this is why it's (presumably) negotiated 
as the candidate to use. This is why rtpengine is sending media there.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 11.31, Andrew Chen wrote:
If that's the case then I don't know why this line doesn't show the 
ipv6 address of the client:


Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG: 
[ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint: 
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)


It doesn't?

2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:3373280875 1 udp 2122262783 
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0 
network-id 2 network-cost 10


What is this then?

Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 10.39, Andrew Chen wrote:

So my next question would be:

My 200 OK back to the client should have rtpengine as the only ICE 
candidate.  Shouldn't it use that one instead?


Yes it should. And it probably does.

Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 09.40, Andrew Chen wrote:

Hey Richard,

So that's what I thought too until I saw this in rtpengine logs for 
one of my test calls:


Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG: 
[ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint: 
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)


unless I misunderstood what this line means.


I think you did. It means rtpengine has received a media packet from one 
side and has forwarded it to the other side. Of course it's one of the 
ICE candidates from the SDP because that's where the peer said it wants 
to receive the media from rtpengine.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 09.24, Andrew Chen wrote:

Hey Richard,

So it is true rtpengine is handling rtp between kamailio and receiver 
(freeswitch).  I'm trying to understand if there is a way to not 
forward rtp to any of the ICE candidates in the original INVITE 
request from the client side.  In other words, have the client rtp 
forward directly to the rtpengine and not any of the STUN servers (or 
ICE candidates).  i honestly thought putting ICE=force in the 
rtpengine_answer would help in this case...but I don't see this part 
working.


But that is what's happening, isn't it? What other media would rtpengine 
be sending to the client if not the media received from the other 
client? So your A client is sending to rtpengine, and rtpengine is 
forwarding that to B, while your B client is also sending to rtpengine, 
which then forwards it to A. Where do you not see that working?


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 04/12/2020 09.11, Andrew Chen wrote:

So for Yuriy's comment:

I did issue ICE=force parameter but, as you can see my paste, it's 
still sending RTP sequence packets to the ICE candidate, which is not 
what I want to do.


Richard,

So our current setup is this:

SIP
client -> kamailio -> freeswitch
RTP
client -> freeswitch

What I want to accomplish is this:

SIP
client -> kamailio -> freeswitch
RTP (bypass ICE)
client -> rtpengine -> freeswitch


I still don't understand. What does "bypass ICE" mean?

If you see rtpengine forwarding media packets as per the log you posted, 
what makes you think that media is not going through rtpengine?


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] question regarding rtpengine and ICE candidate selection

[Richard Fuchs]

On 03/12/2020 13.39, Andrew Chen wrote:

Hi all,

I was wondering if someone can help me understand how the ICE 
parameter works in the rtpengine module works.


So basically our client does an ICE candidate lookup and grabs a list 
of them and applies it to the INVITE that gets sent to the Kamailio.  
The list looks like this:


2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:3373280875 1 udp 2122262783 
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0 
network-id 2 network-cost 10
2020-12-03T18:05:46.456057+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:3040609428 1 udp 2122197247 
2001:8a0:78fc:7000:d979:bf75:dbc0:69f 59828 typ host generation 0 
network-id 3 network-cost 10
2020-12-03T18:05:46.456081+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:1681997092 1 udp 2122129151 192.168.1.66 59829 typ host 
generation 0 network-id 1 network-cost 10
2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:2274611867 1 tcp 1518283007 
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active 
generation 0 network-id 2 network-cost 10
2020-12-03T18:05:46.456131+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:4223662180 1 tcp 1518217471 
2001:8a0:78fc:7000:d979:bf75:dbc0:69f 9 typ host tcptype active 
generation 0 network-id 3 network-cost 10
2020-12-03T18:05:46.456155+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:717406676 1 tcp 1518149375 192.168.1.66 9 typ host tcptype 
active generation 0 network-id 1 network-cost 10
2020-12-03T18:05:46.456180+00:00 ashmainkama51 kamailio[22147]: 
a=candidate:2130547417 1 udp 8199935 206.81.191.27 61165 typ relay 
raddr 85.247.0.121 rport 53091 generation 0 network-id 1 network-cost 10



In the rtpengine_offer, I have this:

rtpengine_offer("ICE=force DTLS=passive replace-session-connection 
replace-origin external internal");


What i am trying to do is to tell the freeswitch endpoint to use 
rtpengine as ICE candidate and I see in the SDP this is happening:


a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host 
generation 0


Btw..206.81.191.52 is a separate AWS instance running rtpengine binary.

On the rtpengine_answer, I tell the remote client side the same 
thing..use rtpengine as your ICE candidate:


rtpengine_answer("ICE=force DTLS=passive replace-session-connection 
replace-origin internal external");


and this is snippet from 200 OK:

a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host 
generation 0


Question:

Why does the rtpengine logs still show that it's trying to use 
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 as RTP candidate in this scenario?


Dec  3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG: 
[ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint: 
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)


I thought ICE=force will handle such adjustments so that all rtp is 
handled by the rtpengine to our client and bypass the STUN server?


Isn't that what's happening? Rtpengine receives media from one peer and 
forwards it to one of the ICE candidates (presumably the primary one 
that was negotiated) of the other peer. Or am I misunderstanding what 
you posted?


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio + rtpengine

[Richard Fuchs]

Can't say for sure from the log you posted, but my guess is that you're 
trying to play media to the B side before having received an answer from 
B. Enable debug logging for a better view of what's happening.


Cheers


On 21/10/2020 11.43, Amit Pal wrote:


Hi,

I have using kamailio with rtpengine,  I have started rtpengine 
session (rtpengine_offer() /rtpengine_answer() )only when call getting 
hold and then play media file and on un hold detach rtpengine 
session(rtpengine_delete()).
during this activity I have received the log “No supported output 
codec found in SDP” from rtpengine.  And getting silence on other leg.


Above activity log are attach in mail.

if we do same step again (i.e. hold/unhold) in same call then second 
leg listening the file perfectly and rtpengine working fine vice-versa.


I want to know , what else missing to configure here. Pls guide me to 
get out this.


Regards

Amit Pal




___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPENGINE question

[Richard Fuchs]

On 14/09/2020 13.14, Andrew Chen wrote:
Btw Richard Fuchs, to follow up on your comment, we have a load 
generator running sipp which is non-SRTP traffic.
As for the fallback, how does that work exactly?  We tried the 
following today and it seems to have helped:


- Removed "--table" startup param in systems file
- Uncommented "no-fallback = false" in rtpengine.conf
- Set "table=-1" in rtpengine.conf

Is there anything else I'm missing that controls the fallback?


Userspace fallback is always available, even if `no-fallback` is set 
(which is relevant during startup only). If a packet is not handled by 
the kernel module for whatever reason, it's always automatically passed 
on to the daemon to be handled (except when explicitly instructed to 
drop a packet, e.g. through `strict-source`). In this sense, you get the 
same behaviour as if `table = -1` is used.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SRTP-DTLS and rtpengine

[Richard Fuchs]

On 12/09/2020 05.51, Gholamreza Sabery wrote:

Hi,

I checked rtpengine's documentation, and I wonder what happens if I 
use SRTP-DTLS with rtpengine? My connection will be hop by hop 
encrypted with rtpengine, or like TURN my connection will remain 
end-to-end encrypted??


In most cases, rtpengine will act as the DTLS termination point. There 
is however a special passthrough mode, which is enabled when 
ICE=force-relay mode is used, and then rtpengine will simply pass the 
DTLS packets through (because it cannot guarantee that it will even get 
to see them).


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPENGINE question

[Richard Fuchs]

On 11/09/2020 15.29, Andrew Chen wrote:

Thanks Alex.

So it turns out my rtpengine stopped working after our latest kernel 
upgrade to:


Linux sjomainrtpe30 5.3.0-1035-aws #37-Ubuntu SMP Sun Sep 6 01:17:09 
UTC 2020 x86_64 x86_64 x86_64 GNU/Linux


at the time, I was running an older version 8.0.x so I recompiled all 
the ngcp packages under this kernel and completed the installation 
without issues.


As soon as we started making test calls, I received 0 audio from those 
test endpoints.  Looking at the rtpengine logs, I see several messages 
that's quite concerning:


Sep 11 18:43:41 sjomainrtpe30 kernel: [  13.434623] xt_RTPENGINE: 
loading out-of-tree module taints kernel.
Sep 11 18:43:41 sjomainrtpe30 kernel: [  13.434670] xt_RTPENGINE: 
module verification failed: signature and/or required key missing - 
tainting kernel
Sep 11 18:43:41 sjomainrtpe30 kernel: [  13.434938] Registering 
xt_RTPENGINE module - version 9.0.1.0+0~mr9.0.1.0


and

Sep 11 18:49:50 sjomainrtpe30 rtpengine[1030]: WARNING: 
[2-7859@2600:1f1c:4ff:3e01:f64d:2f67:c0fa:c931 port 5]: No support 
for kernel packet forwarding available (decryption cipher or HMAC not 
supported by kernel module)


We don't actually have any crypto suites in the code which aren't also 
supported by the kernel module, so there's something else going on. Even 
with this error popping, forwarding should fall back to userspace mode 
and you should have audio. There's probably some other messages in the 
log which point to the real underlying cause, possibly some SRTP-related 
negotiation issues (DTLS?)


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Handling of packet loss in the Kamailio to RTPEngine control protocol

[Richard Fuchs]

On 02/09/2020 19.30, Patrick Wakano wrote:

Hello list,
Hope you are all well.

Under some load test simulations I've been facing cases where the 
command Kamailio sends to RTPEngine times out with such message:

send_rtpp_command(): timeout waiting reply for command "" from RTP proxy
After checking RTPEngine logs, I can see the command was received and 
a reply was sent, so I am thinking the reply packet could have been 
lost somewhere in the network (they are in different servers). So my 
question is, how resilient is the RTPEngine NG protocol to handle 
packet loss situations? I saw TCP is not supported, so are there UDP 
retransmissions in place to guarantee packet delivery? Any ideas to 
make this connection more reliable?


The module automatically resends the command a number of times if no 
reply was received within the timeout period. The modparam 
`rtpengine_retr` is how many times a command is resent, and 
`rtpengine_tout_ms` is how long it waits (in ms) each time for a reply.


If you don't get a reply even after multiple retries, you might have an 
underlying network issue. Most often this is due to broken IP 
fragmentation in the network.


We're currently working on adding HTTP and Websocket support to 
rtpengine, so this could be used in the future as control protocol from 
Kamailio instead of UDP, even though in a properly functioning network 
there's no reason why UDP shouldn't be as reliable as TCP.


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] KAMAILIO/RTPENGINE - Log

[Richard Fuchs]

On 22/08/2020 09.39, Amit Pal wrote:


Dear Team,
 I am using kamailio with rtpengine for media.

When I make call between two sipUA then media  flow is manage by 
rtpengine offer/answer.


The issue is when hold the call  then following some error are coming .

Pls find the full log in attached file.

rtpengine[14099]: DEBUG: 
[43402b3cc9425239MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.]: 
av_log: parser not found for codec pcm_s16le, packets or times may be 
invalid.


rtpengine[14099]: DEBUG: 
[43402b3cc9425239MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.]: 
av_log: max_analyze_duration 500 reached at 512 microseconds st:0


rtpengine[14099]: DEBUG: 
[43402b3cc9425239MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.]: 
av_log: stream 0: start_time: -1152921504606847.000 duration: 27.034


rtpengine[14099]: DEBUG: 
[43402b3cc9425239MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.]: 
av_log: format: start_time: -9223372036854.775 duration: 27.034 
bitrate=128 kb/s


rtpengine[14099]: DEBUG: 
[43402b3cc9425239MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.]: 
av_log: After avformat_find_stream_info() pos: 131130 bytes 
read:19 seeks:1 frames:22


rtpengine[14099]: ERR: 
[43402b3cc9425239MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.]: No 
supported output codec found in SDP


rtpengine[14099]: INFO: 
[43402b3cc9425239MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.]: 
Replying to 'play media' from 127.0.0.1:48757 (elapsed time 0.12 sec)


rtpengine[14099]: DEBUG: 
[43402b3cc9425239MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.]: 
Response dump for 'play media' to 127.0.0.1:48757: { "result": "ok" }


I am unable to understand this issue.

Is this related to rtpenging, which is  not supported given codec  or 
file codec, which is used to play after hold call or anything else in 
script issue.


Can you please guide me where is the issue.

You're trying to play media to the B side (callee - answerer), but 
rtpengine has only seen the offer from the A side (caller). So rtpengine 
neither knows which codec to use, nor where to send the media to. You 
can only play to the B side after having seen an answer from it.


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailio+rtpengine for media not playing media file while hold the call

[Richard Fuchs]

On 20/08/2020 03.42, Amit Pal wrote:


Dear Team,

   I am using kamailio with rtpengine  for media.
when call getting hold no media sound play (configure hold.mp3).

From rtpengine gets following error.

rtpengine[624]: ERR:  No suitable SDP section for media playback

rtpengine[624]: WARNING:  Protocol error in packet from 
127.0.0.1:46333: Failed to start media playback from file 
[d8:supportsl10:load 
limite4:file38:/home/coralswitch/queuesounds/hold.mp37:call-id60:89162207232fae50MTg0YzVlODc0NTBiZGU1ZGJiYmNmYjY1MDc0MjIwMzI.13:received-froml3:IP414:192.168.20.254e8:from-tag32:9f5288f14b704b28a1c2dfc2112250eb6:to-tag8:1e05e7577:command10:play 
mediae]


rtpengine[624]: INFO:  Received command 'offer' from 127.0.0.1:46333

rtpengine[624]: INFO: Replying to 'offer' from 127.0.0.1:46333 
(elapsed time 0.000106 sec)


 /usr/local/sbin/kamailio[9094]: ERROR:rtpengine [rtpengine.c:2619]: 
rtpp_function_call(): proxy replied with error: Failed to start media 
playback from file


Attached file show complete log of one call with hold /unhold actions.


That's because you tried to play media towards a `sendonly` RTP client.

Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtcp-mux is missing in the OK for WebRTC-Calls

[Richard Fuchs]

On 10/07/2020 04.59, Benjamin Flügel | vio:networks wrote:

Hey guys,

I'm trying to configure a Kamailio to work with a browser softphone based on 
SIPJS using WebRTC.
So far it works great on Firefox but have a specific problem with chrome, when 
I want to make call from the softphone to another extension.
After anwsering the call Chrome/the softphone sends a BYE immediately, because this line 
"a=rtcp-mux" is missing in the OK.

The Kamailio is a proxy. Behind the Kamailio there is an Asterisk, which is 
responsible for the pbx-features.


Those are my rtpengine Flags for the Invite:

rtpengine_manage: replace-origin replace-session-connection trust-address 
via-branch=extra rtcp-mux-demux DTLS=off SDES-on ICE=remove RTP/AVP


And those are the flags for the response, in this case the OK:

rtpengine_manage: replace-origin replace-session-connection rtcp-mux-offer 
rtcp-mux-accept generate-mid DTLS=off SDES-on ICE=force RTP/SAVPF 
direction=internal direction=external loop-protect

It seems that the Kamailio ignores ths "rtcp-mux-offer rtcp-mux-accept" in the 
response. Can you help me get it to work?


You don't need to provide some of these options in your answer (neither 
rtcp-mux nor the direction nor the protocol - the direction should be 
specified in the offer). You should also provide the same via-branch 
option in your answer as you did in the offer, especially if this is a 
branched offer. In particular if this is a branched offer and the 
via-branches weren't given correctly, then that would explain the 
missing rtcp-mux.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtpengine inserted random line into sdp

[Richard Fuchs]

Rtpengine takes and replaces the entire SDP body, so if there's another 
module also manipulating the SDP, one module won't see the changes made 
by the other one unless you call msg_apply_changes in between, leaving 
you with bits of string in the wrong places.


Cheers

On 26/06/2020 08.50, Andrew Chen wrote:

Thanks Richard.

I do have the nathelper module running but not rtpproxy. How does 
nathelper cause this issue?


On Fri, Jun 26, 2020 at 8:27 AM Richard Fuchs <mailto:rfu...@sipwise.com>> wrote:


Looks like you're using both rtpengine and some other
SDP-modifying module together, such as nathelper or rtpproxy,
without calling msg_apply_changes() in between.

Cheers

On 25/06/2020 16.46, Andrew Chen wrote:

Hi forum,

I'm starting my rtpengine project and I'm facing a strange
problem with rtpengine.  I am seeing this in the SDP part of the
INVITE:

a=rtcp:52021

a=rtcp-mux

2001:470:7:3A7:0:0:0:2

a=direction:active

a=oldmediaip:54.153.25.234


As you can see there is a random insert of the local kamailio IP
in there and I'm have tried the following to remove it but failed
to succeed:

- Remove in the offer the combination of ICE and
replace-session-connection flags
- Switched between rtpengine_offer and rtpengine_manage
- Restarted ngcp-rtpengine-daemon process
- Used sdpops function sdp_remove_line_by_preifx()

Currently running Kamailio 5.1.2.

I am running out of ideas.

Any suggestions would be greatly appreciated.

-- 
Andy Chen

Sr. Telephony Lead Engineer
achen@ <mailto:ac...@thinkingphones.com>fuze.com <http://fuze.com>



*Confidentiality Notice: The information contained in this e-mail
and any
attachments may be confidential. If you are not an intended
recipient, you
are hereby notified that any dissemination, distribution or
copying of this
e-mail is strictly prohibited. If you have received this e-mail
in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this
e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org  <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



--
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <mailto:ac...@thinkingphones.com>fuze.com <http://fuze.com>


*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of 
this

e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtpengine inserted random line into sdp

[Richard Fuchs]

Looks like you're using both rtpengine and some other SDP-modifying 
module together, such as nathelper or rtpproxy, without calling 
msg_apply_changes() in between.


Cheers

On 25/06/2020 16.46, Andrew Chen wrote:

Hi forum,

I'm starting my rtpengine project and I'm facing a strange problem 
with rtpengine.  I am seeing this in the SDP part of the INVITE:


a=rtcp:52021

a=rtcp-mux

2001:470:7:3A7:0:0:0:2

a=direction:active

a=oldmediaip:54.153.25.234


As you can see there is a random insert of the local kamailio IP in 
there and I'm have tried the following to remove it but failed to succeed:


- Remove in the offer the combination of ICE and 
replace-session-connection flags

- Switched between rtpengine_offer and rtpengine_manage
- Restarted ngcp-rtpengine-daemon process
- Used sdpops function sdp_remove_line_by_preifx()

Currently running Kamailio 5.1.2.

I am running out of ideas.

Any suggestions would be greatly appreciated.

--
Andy Chen
Sr. Telephony Lead Engineer
achen@ fuze.com 



*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of 
this

e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Parallel forking and rtpengine handling

[Richard Fuchs]

On 22/01/2020 14.26, Daniel-Constantin Mierla wrote:


Btw, a few questions for further clarifications: if a call has 
parallel forking and rtpengine offer is executed for each branch, one 
is answered, but the other branch-sessions are not not deleted, what 
does rtpengine? It times them out, or keeps them for the duration of 
the call?


Those branches would remain open. When the call is finished, it will 
depend on how the delete is executed: if the delete is done from the 
side which branched the call (side A, caller), then the entire call 
including other branches are deleted. If the delete is done from the 
opposite side (B, one of the branches), the other branches would still 
remain open, keeping the entire call alive. The call would then 
eventually time out depending on the config, but it might take a while.


Also in the case of parallel forking, if via-branch is not give to 
rtpengine offer command, does the 2nd (and the next) rtpengine offer 
command overwrite the previous one, so the rtpengine keeps only the 
data from the last one?


Correct, with possibly some undesired side effects depending on which 
flags were used (e.g codec changes).


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Parallel forking and rtpengine handling

[Richard Fuchs]

On 22/01/2020 13.15, George Diamantopoulos wrote:



On Wed, 22 Jan 2020 at 18:28, Richard Fuchs <mailto:rfu...@sipwise.com>> wrote:


On 22/01/2020 11.06, Sebastian Damm wrote:
> Hi,
>
> our scenario is the following: We have two clients registered to our
> Kamailio server, one with a TLS capable phone, one via
websocket. Now,
> when a call comes in, the call is forked and is sent out to both
> clients. rtpengine handling is done in the branch route, so
there are
> two offers, and we use the "via-branch" parameter.
>
> Now, when one branch answers the call, what happens to the other
> branch? I there a way to delete the other branch? How and in which
> route? Or does Kamailio do this automatically?

You do it the same way as you handle an answer: You issue a delete
with
the via-branch option.

Doesn't this happen automatically when one uses rtpengine_manage() in 
the failure_route?


I would think it does, as long as you supply the via-branch parameter.

Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] systemd - properly starting up rtpengine with kernel forwarding

[Richard Fuchs]

On 17/01/2020 09.01, Daniel-Constantin Mierla wrote:

Hello,

do people here have (implemented) special ways to properly start
rtpengine with kernel forwarding after system reboot?
On our own systems, we have xt_RTPENGINE loaded through modules-load.d, 
and the iptables rule added through iptables-persistent. But obviously 
this is not a generic solution as there are dependencies.

Not strictly related, but if someone is aware or had some experiences
with,  I am curious if "echo 'del 0' > /proc/rtpengine/control" is
really needed because on a system where I forgot to have it in the
scripts (well, was commented), I haven't noticed any issues after
rtpengine restarts.


This is not actually required any more. The daemon itself handles this 
on startup now.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamalio + RTP Engine + SIP Client behind NAT

[Richard Fuchs]

On 16/01/2020 12.29, Nuno Miguel Reis wrote:

Hi again.

Thanks for all the help and suggestions. I realized the issue happens 
if using kernel forwarding only. If I change rtpengine to start at 
userspace without the kernel module enabled everything works fine as 
expected.
Do you have any hints on why this could be happening with the kernel 
module?


I'm running rtpengine like this:

usersapece: $ rtpengine -f -L 7 --interface=100.100.100.100 
--listen-ng=127.0.0.1:2223  --tos=184 --sip-source


kernel: $ rtpengine -f -L 7 --table=0 --interface=100.100.100.100 
--listen-ng=127.0.0.1:2223  --tos=184 
--no-fallback --sip-source


The kernel module receives its instructions from the userspace daemon, 
so there's no reason there should be a difference. Can you post 1) logs 
and 2) the flags you use for your offers/answers?


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamalio + RTP Engine + SIP Client behind NAT

[Richard Fuchs]

On 15/01/2020 13.39, Nuno Miguel Reis wrote:

Hi guys.

I'm replacing a environment where I was using kamailio + freeswitch by 
another where I'm adding rtpengine to the mix.

One of the issues I'm having now is when I have a SIP Client behind NAT:

When I send the INVITE from the SIP Client, the SDP is using the 
private LAN IP address + the advertised media port, let's admit it's 
10.10.10.10:5000  when the call establishes 
with a public server running kamailio + rtpengine, the actual RTP 
arrives from the home router public IP on a natted port, let's admit 
it's 100.100.100.100:65100 , event 
though, RTPENGINE assumes that RTP stream is coming from 
100.100.100.100 :5000.I'm using the 
'--sip-source' with RTPENGINE to make it use the received ip address 
instead of the private IP coming in the SDP but I'm not finding 
anything to make RTPENGINE adapt an start sending the RTP FLOW to the 
port where he starts receiving the RTP flow from, discarding the SDP 
media port information.


Rtpengine does this automatically, unless the `asymmetric` flag is used. 
You should see a log message about a `confirmed peer address` as soon as 
the first RTP is received on a port.


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine / Transcoding question

[Richard Fuchs]

On 29/05/2019 03.25, Carsten Bock wrote:

Hi,

the problem is, the device (a VoLTE phone) will ALWAYS offer AMR-WB 
and AMR-NB and we will need to do transcoding to G722 / G711 in most 
cases (unless the B-Party actually offers AMR-WB/AMR-NB).
The Answer may be pure G711 (RTPEngine will do Transcoding G711 <=> 
AMR-WB [meaningless]) or G722 (RTPEngine will do Transcoding G722 <=> 
AMR-WB [Makes sense]) or AMR-NB/-WB (no Transcoding [ideal]). If I 
could limit the Answer from RTPEngine to contain only AMR-NB, that 
would ideal, as AMR-NB has less complexity, than transcoding into 
AMR-WB and it would additionally save bandwidth (which is important in 
our case).


Ah I see. As explained already, making this decision at the time the 
answer comes through doesn't really work, because the codec in question 
might already be in use at that time. What you would like to see instead 
is to make a decision at the time of the offer: Transcode one of the 
offered transcoded codecs to a particular one of the original offered 
codecs ("offer G.722 and transcode to AMR-WB"), and transcode another 
offered transcoded codec to another one of the original offered codecs 
("offer G.711 and transcode to AMR-NB"). Something along those lines, 
correct? That's simply a feature that doesn't yet exist, as right now 
transcoding always happens to the first supported original codec (i.e. 
if AMR-WB is first in the list, then that's what will be used).


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine: rtpengine_manage(), Subsequent requests, Transcoding

[Richard Fuchs]

On 29/05/2019 06.57, Carsten Bock wrote:

Hi,

quick question:
If understood it correctly in the past (and it worked for me quite 
well this way), I can simply call rtpengine_manage() for subsequent 
requests without adding any additional information (e.g. used 
interfaces, RTP/SRTP translation or anything like that), as this 
information is stored in the internal hash table of the RTPEngine 
module during call setup and initial offer/answer.


However, this does not seem to apply to the transcoding options. When 
I just call "rtpengine_manage()" for a Re-INVITE of a transcoded call 
(in my case AMR-WB to G722), the transcoding options are no longer 
applied. The forwarded offer does not get the transcoded codecs added 
(e.g. in my case G722 is not added to the list of AMR/AMR-WB from the 
phone).


Did I misunderstand something or is it a bug?

My RTPEngine is still on 7.2, but I will double check with more recent 
versions today or tomorrow. However, I also found no commit messages 
relating to this.


It depends on your point of view whether you see this as a feature, a 
bug, or a missing feature. :) But yes, currently the codecs seen in an 
offer SDP passing through empty out the list of known codecs and 
populates it fresh, which requires the desired transcoding options to be 
given fresh also. The reason for this is that it's obviously possible 
for a client to start a codec renegotiation at any time, and that may 
result in a different codec pairing after a re-invite. So the preferred 
way to handle this is to detect it in your script and pass the 
appropriate options.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine / Transcoding question

[Richard Fuchs]

On 21/05/2019 18.42, Carsten Bock wrote:

Hi Richard,

Thanks for your reply, understood.

The issue is following (not really an issue, more an optimization):
At the moment of the offer, I simply don't know, what will be 
supported by the callee. G711 is however always supported, that's why 
I don't want to strip it. I send the call to our upstream provider; if 
he sends it to Telefonica, we get an answer with G722 and G711. If he 
sends it to Deutsche Telekom, the answer is only G711. However, we 
don't know, if it's gonna be Telefonica or Deutsche Telekom...


I was thinking about avoiding uneccessary RTP traffic (in HD) between 
RTPEngine and the device in case of an outbound call. From a 
signalling perspective, I get the right result, if I use 
sdp_remove_codecs() in my reply. However, that won't work, since the 
RTP stream sent from RTPEngine to the device is in HD, regardless of 
the signalling.


Maybe you want to make your transcoding options also dependent on 
whether G.711 was present in the original offer, and/or in what order 
the codecs were listed? Rtpengine won't do transcoding if both sides 
support the same codec, even if other codec pairings are possible 
(unless `always-transcode` is given). Are you using that option? Are you 
using other options to reorder codecs in the offer? Because normally the 
first supported codec will be used, and rtpengine adds transcoding codec 
offers to the end of the list. So they should only be used if no other 
codec is supported by the callee, unless the callee ignores the listed 
codec preferences, or codecs were reordered, or `always-transcode` was used.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine / Transcoding question

[Richard Fuchs]

On 21/05/2019 11.48, Carsten Bock wrote:

Hi,

I want to implement selective transcoding, e.g. avoiding Transcoding 
between a HD codec (G722) and a non HD Codec (G711).


In case the caller does offer HD codecs, this is fine, e.g.

if(sdp_with_codecs_by_name("G722,OPUS")) {
  rtpengine_offer("codec-transcode=OPUS codec-transcode=G722 
codec-transcode=PCMA");

} else {
  rtpengine_manage("codec-transcode=PCMA");
}

Now I have the issue, if the callee only sends me G711, I don't want 
to offer G722 or Opus to the caller. However, rtpengine_answer() does 
not seem to accept "codec-strip=G722 codec-strip=OPUS", e.g.:


onreply_route() {
  if(!sdp_with_codecs_by_name("G722,OPUS")) {
    rtpengine_ manage("codec-strip=OPUS codec-strip=G722");
  }
}

As a result, the SDP always contains the transcoding options, e.g. 
G722 and OPUS. I always end up in transcoding G722 to G711, which is 
meaningless in that case.


Any ideas on how to solve that?
(above examples very simplified)


All transcoding options must be present in the `offer` - they're ignored 
in the `answer`. (At least in newer versions - older versions did accept 
them in an `answer`, but they didn't do what was expected, which is why 
they were removed in later versions.)


The reason for this is that the callee may send media before the SDP 
from the callee (the answer) is seen. Therefore all transcoding 
decisions must be made at the time of the offer (otherwise you may end 
up switching codecs whenever the answer is seen, which is undesirable). 
So you'll have to figure out a way to decide what you want to do based 
on what you know at the time of the offer.


I'm a bit confused by your example. If you want to avoid transcoding 
between G.722 or Opus, and G.711, why do you want to offer PCMA when the 
caller supports G.722 or Opus? Shouldn't you rather only offer other 
"HD" codecs and strip all non-HD codecs in that case?


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtpengine_offer() with ICE not updating o= and m= IP addresses

[Richard Fuchs]

`replace-origin` and `replace-session-connection` are optional for 
normal operation and are preempted by `ICE=force-relay`. If you want c= 
and o= (and m=) lines updated, you should use `ICE=force` instead.


Cheers


On 19/04/2019 05.25, David Dean wrote:

Sorry, not sure I understand.

The documentation says these options will update c= and m= but in my 
case they aren't applying and I don't know why.


Are you saying c= and m= won't be updated if ICE is being forced?

-
https://www.kamailio.org/docs/modules/4.4.x/modules/rtpengine.html#rtpengine.f.rtpengine_offer

replace-origin - flags that IP from the origin description (o=) should 
be also changed.


replace-session-connection - flags to change the session-level SDP 
connection (c=) IP if media description also includes connection 
information.





On Friday, 19 April 2019, 10:15:28 GMT+1, Daniel Tryba 
 wrote:



On Fri, Apr 19, 2019 at 08:52:30AM +, David Dean wrote:
> I'm using the following rtpengine_offer() to force the use of ICE 
relay and also replace o= and m=
> ?? ??rtpengine_offer("replace-origin replace-session-connection 
ICE=force-relay RTP");

>
> The SDP is being updated to include an ICE relay candidate, but the 
IP addresses in the o= and m= lines are not changing??to the servers 
IP address (X.X.X.X).



This is a feature, not a bug: https://github.com/sipwise/rtpengine

"
* ICE

...
With force-relay, existing ICE candidates are left in place except relay
type candidates, and rtpengine inserts itself as a relay candidate. It
will also leave SDP c= and m= lines unchanged.

This flag operates independently of the replace flags.
"

Strange that media adress doesn't work, but try replace. Maybe that
works?


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org 
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

[Richard Fuchs]

Hi,

(X-posted to sr-dev as this is getting into the nitty gritty)

As a short-term workaround for this, I've been playing with the 
preloaded library approach to hijack the pthread mutex calls and force 
them to provide process-shared mutexes. AFAICT this seems to be working 
and only has the minuscule performance impact of using slower 
process-shared mutexes in all instances, even when they aren't required.


The code for the preloaded library itself is very short and simple: 
https://gist.github.com/rfuchs/1bb7348b6acbe37e557d94c2f69a1498


As a more complete patch that integrates it into the build system 
(probably badly): 
https://gist.github.com/rfuchs/b240ffe87938a45e6f2a4cf53fe29f17


Finally it requires adding it to the startup script, for example in a 
systemd service file as:


Environment='LD_PRELOAD=/usr/lib/x86_64-linux-gnu/kamailio/openssl_mutex_shared/openssl_mutex_shared.so'

(that's with a hard coded path which isn't optimal of course).

I don't consider this a proper fix, but only a hacky workaround, but it 
might be a solution for the very near future. Throwing it out there in 
case other people have been working on similar approaches, and/or maybe 
have some comments about this.


Cheers


On 01/04/2019 04.52, Daniel-Constantin Mierla wrote:

Hello,

an update on this issue -- I spent a bit of time looking at
libssl/libcrypto library and the problem can be the type of mutexes they
use now internally starting with v1.1, respectively the pthread mutex.
They are not process shared and kamailio is a multi-process application,
working with the same tls connection from multiple processes.

Today I wrote to openssl mailing list, waiting now to see if I get any
hints from there.

Cheers,
Daniel

On 01.04.19 10:33, Kristijan Vrban wrote:

Hi Andrew,

yes, with openssl 1.0.2 Kamailio is now up and running since five
days. Looks good so far.

Kristijan

Am Do., 28. März 2019 um 11:09 Uhr schrieb Andrew Pogrebennyk
:

On 3/26/19 3:52 PM, Kristijan Vrban wrote:

Just curious, did you get to compile with OpenSSL 1.0 and test?

Just compiled with OpenSSL 1.0 . Gone test now.

Kristijan,
any new occurrences since you have recompiled kamailio with openssl 1.0?

Regards,
Andrew

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Rtpengine - no RTP packets going out

[Richard Fuchs]

On 01/04/2019 09.14, Istvan Mogyorosi wrote:

Dear all,

This is my first post after reading a lot in this mailing-list.
I'm trying to use Kamailio 5.1 with the dispatcher module and 
rtpengine acting as SIP + RTP proxy.
I have 6 asterisk servers in a private subnet that should talk with 
the peer via a single IP like this:


Asterisk 1..n|---> | GW.PRIVATE.IP -o- GW.PUBLIC.IP |> PEER.SIP.TRUNK

I'm on Centos 7, with firewalld configured, iptables module is loaded 
and the rule is well defined.

Packet forwarding is also enabled.

Chain rtpengine (1 references)
target prot opt source   destination
RTPENGINE  udp  --  anywhere anywhere RTPENGINE id:40

My call flow seems to be fine, Kamailio/rtpengine private IP is the 
outboundproxy parameter of Asterisk instances.


My problem is that RTP packets are not present on the public 
interface, the rtpengine final log showing
the 2 sessions, but I'm not sure this is what I want or simply the 
firewall does not let it out ?
(To be more precise PEER.SIP.TRUNK is the trunk for SIP traffic, I 
have multiple IP addresses

for media to connect to, reinvites are allowed)

Closing call due to timeout
Final packet stats:
--- Tag 'as6d12caea', created 1:00 ago for branch '', in dialogue with 
'as541b1e61'

-- Media #1 (audio over RTP/AVP) using unknown codec
- Port  GW.PRIVATE.IP:1 <> 192.168.30.13:11152, SSRC 0, 0 
p, 0 b, 0 e, 60 ts
- Port  GW.PRIVATE.IP:10001 <>   192.168.30.13:11153 (RTCP), 
SSRC 0, 0 p, 0 b, 0 e, 60 ts


--- Tag 'as541b1e61', created 1:00 ago for branch '', in dialogue with 
'as6d12caea'

-- Media #1 (audio over RTP/AVP) using unknown codec
- Port GW.PUBLIC.IP:1 <> PEER.SIP.TRUNK:28216, SSRC 0, 
0 p, 0 b, 0 e, 60 ts
- Port GW.PUBLIC.IP:10001 <> PEER.SIP.TRUNK:28217 (RTCP), 
SSRC 0, 0 p, 0 b, 0 e, 60 ts


These are all reception counters, so this is a problem of packets not 
being received. Having the iptables RTPENGINE rule installed does not 
automatically allow the packets to pass through your firewall. You have 
to do that separately.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Compressing SIP messages

[Richard Fuchs]

On 01/04/2019 11.22, Fred Posner wrote:

On 4/1/19 11:18 AM, Steve Davies wrote:
Never quite got this.  UDP packets can be up to 64k, right?  And 
fragmentation is a standard IP feature if a packet is bigger than MTU 
size.


Steve



of course, you're hoping that the fragmented packets arrive in order.

That really makes no difference. The network stack takes care of 
reassembling the fragments no matter what order they arrive in.


Issues only arrive from broken routers or firewalls, or if you have to 
deal with packet loss.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtpengine force-relay

[Richard Fuchs]

On 15/03/2019 06.37, Vitalii Aleksandrov wrote:



On Thu, Mar 14, 2019 at 06:01:41PM +0200, Vitalii Aleksandrov wrote:

What is wrong with the default behavior? That adds ICE records and
rewrites SDP c=.
When a call goes through multiple proxies and every proxy inserts 
itself SDP

becomes really huge. What I like in "force-relay" is that it removes
previously inserted "relay" candidates and inserts itself. Hope 
rtpengine
will still talk to those relay candidates on incoming leg if "host" 
are not
reachable. So I'm satisfied with "force-relay" when call to ICE 
supported

phone, but when callee can't do ICE I'm in trouble.

ICE is end to end. rtpengine does nothing with other ICE candidates
(AFAIK). So removing those other candidates defeats the purpose IMHO.
You might as well remove any ICE and simply rewrite DSP
Oh, it actually does. If you use ICE=force, rtpengine removes all ICE 
candidates and inserts its own and both call participant can't to talk 
to each other directly but still can use ICE to establish media 
streams to rtpengine. ICE=force-relay does another cool thing. Using 
it call participants try to talk directly and if they can't (both 
behind NAT) they can still use "relay" candidate inserted by rtpengine 
and exchange media via it. I just need a mixed behavior like default + 
force-relay and don't want to hack rtpengine sources and then maintain 
my patches when need to update it.


You can always submit a pull request as long as it doesn't break 
existing functionality, e.g. by making it a new optional feature.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] tm.so --> segfault at 3135352e36 ip 00007f761bb57ed1 sp 00007fff9db8b1c0 error 4 in tm.so

[Richard Fuchs]

On 25/02/2019 13.40, Daniel-Constantin Mierla wrote:


I will look into this direction as well, there was something reported
also for t_should_relay_response() over the time.

You were running 5.2.1?


This one was on 5.1.7.

Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] tm.so --> segfault at 3135352e36 ip 00007f761bb57ed1 sp 00007fff9db8b1c0 error 4 in tm.so

[Richard Fuchs]

On 25/02/2019 12.34, Daniel-Constantin Mierla wrote:


Hello,

that's strange, but a while ago someone else reported an issue with 
same backtrace.


So the crash happens at the last line in the next snippet from 
reply_received() function in the tm module:


    uac=>uac[branch];
    LM_DBG("org. status uas=%d, uac[%d]=%d local=%d is_invite=%d)\n",
        t->uas.status, branch, uac->last_received,
        is_local(t), is_invite(t));
    last_uac_status=uac->last_received;

The backtrace and info locals say that uac is null (0x0). According to 
my knowledge, the address of a field in a structure cannot be null and 
uac is set to >uac[branch]. Moreover, uac->last_received is printed 
in the LM_DBG() above the line of crash, if uac was 0x0, the crash 
should have happened there.


t->uac is a pointer to an array, not a static array contained in the 
struct. So, if t->uac was null, then >uac[branch] would also yield 
null if branch was zero. (For a non-zero branch, it would yield a 
pointer to somewhere just past null. >uac[branch] is the same as 
t->uac + branch.)


As for LM_DBG, I'm not too familiar with the logging macros, but if 
they're defined in such a way to check the log level first and then skip 
calling the actual logging function if the log level is too low, then 
the LM_DBG arguments would never be evaluated and so no null dereference 
would occur there.


I was debugging a similar core dump just the other day, although in a 
different location. That one was in t_should_relay_response(), line 
1282, and also had Trans->uac == null. The strange part about this one 
was that according to gdb, Trans->uac was valid:


#0  0x7f3f11d5b5e8 in t_should_relay_response 
(Trans=Trans@entry=0x7f3e14a551f8, new_code=new_code@entry=200,
    branch=branch@entry=0, 
should_store=should_store@entry=0x7fffb0353408, 
should_relay=should_relay@entry=0x7fffb0353404,
    cancel_data=cancel_data@entry=0x7fffb0353670, reply=0x7f3f160aa6e8) 
at t_reply.c:1282

1282 in t_reply.c
(gdb) p Trans->uac[branch].last_received
$11 = 0

even though the asm instruction definitely was a null dereference into 
->uac:


 0x7f3f11d5b5de <+718>: add 0x170(%rbx),%r8
=> 0x7f3f11d5b5e8 <+728>: mov 0x190(%r8),%eax
(gdb) p $r8
$2 = 0

%rbx had Trans and so %r8 had Trans->uac. At this point, %8 == 
Trans->uac == null, even though:


(gdb) p (long int) Trans->uac
$18 = 139904611079176

Investigating further, we found that Trans resided in shared memory and 
so we (tentatively) concluded that this looks to be a race condition 
with another process overwriting the Trans shm. First Trans->uac was 
null and got assigned to %r8, then another process changed it to 
something valid in shm, then the segfault happened through %r8. We 
didn't have a chance to investigate further and I can't say for sure if 
these two crashes are related.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Installing and setup of RTP engine on kamailio

[Richard Fuchs]

On 20/02/2019 06.53, Prabhat Kumar wrote:

I am getiing this error in syslog

Feb 20 11:48:58 ip-10-0-0-X systemd[1]: Started Cleanup of Temporary 
Directories.
Feb 20 11:49:39 ip-10-0-0-X systemd[1]: Stopped NGCP RTP/media Proxy Daemon.
Feb 20 11:49:39 ip-10-0-0-X systemd[1]: Starting NGCP RTP/media Proxy Daemon...
Feb 20 11:49:39 ip-10-0-0-X kernel: [  943.077424] Registering xt_RTPENGINE 
module - version 6.5.0.0+0~mr6.5.0.0
Feb 20 11:49:39 ip-10-0-0-X systemd[1]: Started NGCP RTP/media Proxy Daemon.
Feb 20 11:49:39 ip-10-0-0-X rtpengine[2122]: [1550663379.862848] CRIT: Fatal 
error: Missing option --interface
Feb 20 11:49:39 ip-10-0-0-X systemd[1]: ngcp-rtpengine-daemon.service: Main 
process exited, code=exited, status=255/n/a
Feb 20 11:49:40 ip-10-0-0-X systemd[1]: ngcp-rtpengine-daemon.service: Unit 
entered failed state.
Feb 20 11:49:40 ip-10-0-0-X systemd[1]: ngcp-rtpengine-daemon.service: Failed 
with result 'exit-code'.
Feb 20 11:49:40 ip-10-0-0-X kernel: [  944.145301] Unregistering xt_RTPENGINE 
module
How can i correct it?


By setting up your config file correctly, in particular the IP/interface 
config.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Re. SRTP configuration Rtpengine

[Richard Fuchs]

On 16/02/2019 07.38, vinod mn wrote:

Hi I am not able to do SRTP configuration properly
this the kamailio configuration
*route[NATMANAGE] {
*
*rtpengine_manage("replace-origin replace-session-connection RTP/SAVP");
}*
I can see in SDP RTP/SAVP but still the packets are RTP.
clients used linphone-android (media-encryption is SRTP ) and 
3cx-windows-client


You have to differentiate between offers and answers. In the offer going 
from RTP to the SRTP client, instruct rtpengine to use RTP/SAVP. In the 
answer, omit that option (or use RTP/AVP). Indiscriminately calling 
rtpengine_manage with the same options in both directions doesn't work.


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio with RTPengine, allow source port of RTP to change during a call

[Richard Fuchs]

On 06/02/2019 01.55, Laurent Schweizer wrote:


Hello,

I’m using the RTPengine with Kamailio and I have a question for a 
specific case.


I have some customer that are changing the source port of the RTP 
stream during the call ( no re-invite) I think it’s more a NAT issue 
that a user agent issue…


I see in the doc that I can handle this case with the “media 
handover”  but in that case the rtpengine will allow a change of the 
source port but also of the source IP.


Any possibility to allow only a change of the source port so source IP 
must still be the same ?


We don't have such a feature right now, but it would be fairly simple to 
implement. As always, pull requests are welcome of course :)


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtpengine in stateless kamailio

[Richard Fuchs]

On 02/01/2019 09.32, Yuriy Gorlichenko wrote:

Thx for the reply
Yes
Internal hash table diffenentelly stores info
But even it case of putting timeout to 0 it still grows in synthetic 
tests. So looks like it will grows alsways because of deletes entries 
but creates new and so on and so on...

So means it decrases "leak" but not fully

Is there some hidden function maybe to drop hast table o some ticky to 
do this? (we are using oru ow algorinthm that garanties to use same 
node in case of transaction)



You should be able to set the timeout to zero and the size of the hash 
table to one (variable `hash_table_size`). That should make the code 
purge out all entries on every operation, keeping the number of entries 
minimal.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtpengine in stateless kamailio

[Richard Fuchs]

On 02/01/2019 07.45, Yuriy Gorlichenko wrote:

Hi!
Happy new year to all!!!

Look like I am first in this year wit hthe questions in this list :-).

I'm using stateless kamailio and RTPengnine to build some kind of the 
stateless cluster
I found that kamailio keeps some data  in the SHMEM in case of using 
RTPengine module even if it is not a rtpengine_manage function but 
offer/answer/delete


In this case if INVITE (offer) handled by 1-st kamailio in my cluster, 
and BYE/CANCEL handled by second kamailio in the cluster - 1-st 
kamailio (which has been used for offer) will hase kinda internal 
"memory leak" (in SHMEM it never decrased)


At the rtpengine module source I found some transation dependencies 
for the rtpengine_manage function but did not find for the 
offer/answer/delete
I supposed these 3 functions just sending requests to the rtpnegine 
with keys and not storing anything


So my question - is it possible to use RTPengine module in stateless 
way to avoid internal "memory leak" because in my scenario I have big 
chance never receive  BYE/CANCEL on the machine that started handle 
particular call



This is probably the module-internal hash table that is used to make 
sure that signalling relating to the same call is always sent to the 
same rtpengine instance. This hash table does have a configurable 
timeout value (`hash_table_tout`, defaults to 1 hour), which makes it 
possible to still use it in a way you've described. However, from the 
code it's my understanding that timed out hash table entries are only 
deleted when they're encountered during processing, so it's not entirely 
deterministic that old entries are always deleted after they've timed 
out. The RPC command `rtpengine.get_hash_total` can be used to inspect 
the current size of the hash table.


Cheers


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Assistance with re.subst & newline

[Richard Fuchs]

On 06/12/2018 07.17, Mark Hall wrote:


Hi,

I am using rtpengine to proxy audio to/from media servers.

The outbound calls are being rejected by a couple of my carriers 
(although accepted by others), and the closest that I have been able 
to find for the reason is the inclusion of “a=rtcp:x” in the SDP 
generated by rtpengine.


To test further, I am trying to remove this line.  Rtpengine itself 
doesn’t have any options to remove it, so I am left with manipulating 
the generated SDP in Kamailio.




Actually it does. Add the flag `no-rtcp-attribute` to your invocations 
and you should be all set.


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine

[Richard Fuchs]

This is usually a symptom of doing a double SDP rewrite, e.g. by making 
a call to rtpengine twice in the same script iteration, or making a call 
to rtpengine and then doing some other SDP rewrite operations either 
before or after that.


Cheers

On 2018-10-23 21:54, Wilkins, Steve wrote:

Entire section.

-Original Message-
From: sr-users  On Behalf Of Alex Balashov
Sent: Tuesday, October 23, 2018 9:31 PM
To: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data 
when using rtpengine

Is the entire SDP body doubled, or just the v=0 line?

--
Sent from mobile. Apologies for brevity and errors.

-Original Message-
From: "Wilkins, Steve" 
To: "Kamailio (SER) - Users Mailing List" 
Sent: Tue, 23 Oct 2018 9:07 PM
Subject: [SR-Users] Double Session Description Protocol Version (v) 0 data when 
using rtpengine

Hello all,

I noticed double Session Description Protocol Version (v) 0 data in the SDP 
section when using rtpengine with Kamailio.  Has any else noticed this?  Is 
there a way for Kamailio to remove one of them?

Thank you,
-Steve

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dlg.end_dlg on RTP timeout

[Richard Fuchs]

On 2018-09-06 06:13, Carsten Bock wrote:

Hi Richard,

this is awesome! Thanks!

One question:
Currently, the XML-RPC URL has to be set in the config, right? I
frequently have the following setup:
- 2x Kamailio
- 2x RTPEngine
(and each Kamailio is connected to both RTPEngines, for redundancy and
maintenance reasons)

If I configure the URL statically, RTPEngine will only try to
terminate the dialog on one of the Kamailios, not from the Kamailio
where it received the call. If I understand the source-code correctly,
you store the information, from where the dialog was received anyway,
right? (created_from_addr / created_from in struct call). Would it be
feasable, to create the URL dynamically based on the Proxy where it
came from?


Yes, that is already supported. A double percent "%%" in the URL will be 
replaced with the address that the call was created from, e.g. `b2b-url 
= http://%%:8090/`


Additionally, this address can be overridden with the 
`xmlrpc-address=...` flag in one of the rtpengine signalling commands.


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dlg.end_dlg on RTP timeout

[Richard Fuchs]

This is now supported as per 
https://github.com/sipwise/rtpengine/commit/89084da8d820919b44a0244e16e6701822070a72


Cheers

On 2018-09-05 05:39, Daniel-Constantin Mierla wrote:


There is the dlg.terminate_dlg rpc command that requires callid, 
from-tag and to-tag as parameters:


  * 
https://kamailio.org/docs/modules/5.1.x/modules/dialog.html#dlg.r.terminate_dlg


So it expects something like:



dlg.terminate_dlg

_CALLID_VALUE__
_FROM_TAG_VALUE__
_TO_TAG_VALUE__



I planned to make the from-tag and to-tag optional for quite some 
time, but didn't get the time for it yet.


Cheers,
Daniel

On 05.09.18 08:52, Richard Fuchs wrote:

Yup that's exactly right.

It would be fairly simple to implement an additional XMLRPC format if 
there's a particular one that's more friendly towards Kamailio.


Cheers

On 2018-09-05 02:42, Daniel-Constantin Mierla wrote:


Looking quickly at the readme of rtpengine application and digging a 
bit with google, it is something like rtpengine has to be started with


-b http(s)://myrpcserver.ip/path -x 1

and then the xmlrpc request is going to be sent to that url, having 
a format like:




teardown

_CALLID_VALUE__



Is it right? If yes, then I can try to make a sample config that 
could handle it using xmlops, xhttp and jsonrpcs modules.


Cheers,
Daniel


On 05.09.18 08:24, Richard Fuchs wrote:
It does an XMLRPC callback. Currently there's two formats for it, 
one is a sems sbc teardown request (using the from-tag), the other 
is a generic "teardown" command using the call ID.


Cheers

On 2018-09-04 07:52, Daniel-Constantin Mierla wrote:


Hello,

what do you get from rtpengine on rtp timeout? An RPC call back or 
an http request?


Cheers,
Daniel


On 04.09.18 12:48, Igor Olhovskiy wrote:

Hi all!

Is there any way to end dialog in Kamailio on RTP Timeout event 
on RTPEngine?


Or only look at logs/redis database with external tool?

Regards, Igor


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda  --www.linkedin.com/in/miconda
Kamailio World Conference --www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin --www.asipto.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda  --www.linkedin.com/in/miconda
Kamailio World Conference --www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin --www.asipto.com



___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda  --www.linkedin.com/in/miconda
Kamailio World Conference --www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin --www.asipto.com
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dlg.end_dlg on RTP timeout

[Richard Fuchs]

Yup that's exactly right.

It would be fairly simple to implement an additional XMLRPC format if 
there's a particular one that's more friendly towards Kamailio.


Cheers

On 2018-09-05 02:42, Daniel-Constantin Mierla wrote:


Looking quickly at the readme of rtpengine application and digging a 
bit with google, it is something like rtpengine has to be started with


-b http(s)://myrpcserver.ip/path -x 1

and then the xmlrpc request is going to be sent to that url, having a 
format like:




teardown

_CALLID_VALUE__



Is it right? If yes, then I can try to make a sample config that could 
handle it using xmlops, xhttp and jsonrpcs modules.


Cheers,
Daniel


On 05.09.18 08:24, Richard Fuchs wrote:
It does an XMLRPC callback. Currently there's two formats for it, one 
is a sems sbc teardown request (using the from-tag), the other is a 
generic "teardown" command using the call ID.


Cheers

On 2018-09-04 07:52, Daniel-Constantin Mierla wrote:


Hello,

what do you get from rtpengine on rtp timeout? An RPC call back or 
an http request?


Cheers,
Daniel


On 04.09.18 12:48, Igor Olhovskiy wrote:

Hi all!

Is there any way to end dialog in Kamailio on RTP Timeout event on 
RTPEngine?


Or only look at logs/redis database with external tool?

Regards, Igor


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda  --www.linkedin.com/in/miconda
Kamailio World Conference --www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin --www.asipto.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda  --www.linkedin.com/in/miconda
Kamailio World Conference --www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin --www.asipto.com
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dlg.end_dlg on RTP timeout

[Richard Fuchs]

It does an XMLRPC callback. Currently there's two formats for it, one is 
a sems sbc teardown request (using the from-tag), the other is a generic 
"teardown" command using the call ID.


Cheers

On 2018-09-04 07:52, Daniel-Constantin Mierla wrote:


Hello,

what do you get from rtpengine on rtp timeout? An RPC call back or an 
http request?


Cheers,
Daniel


On 04.09.18 12:48, Igor Olhovskiy wrote:

Hi all!

Is there any way to end dialog in Kamailio on RTP Timeout event on 
RTPEngine?


Or only look at logs/redis database with external tool?

Regards, Igor


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda  --www.linkedin.com/in/miconda
Kamailio World Conference --www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin --www.asipto.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Struggling with RTPProxy and RTPEngine

[Richard Fuchs]

It may be more helpful to post some logs from rtpengine. You should 
never see "*Call-ID not found*" from an offer.


Cheers

On 2018-08-22 08:49, Wilkins, Steve wrote:


Here is my start up =>

rtpengine --interface 111.121.22.11\!27.22.132.10 --listen-ng 
127.0.0.1:12221 --dtls-passive -f -m 1 -M 2  -E -L 7 
--log-facility=local1


My offer and answer =>

rtpengine_offer("trust-address replace-session-connection 
replace-origin");


*From:* sr-users  *On Behalf Of 
*Wilkins, Steve

*Sent:* Wednesday, August 22, 2018 8:43 AM
*To:* Kamailio (SER) - Users Mailing List 
*Subject:* [SR-Users] Struggling with RTPProxy and RTPEngine

Hello all,

I can’t seem to get either RTPProxy or RTPEngine to work correctly.  I 
have decided to concentrate on RTPEngine because I have read that it 
works the best. I am using Asterisk with Kamailio in front.  When I 
make calls, I see RTPEngine being hit but I continually get the error 
“*Call-ID not found*”, calls work but media traffic doesn’t go through 
RTPEngine.  I have tried many combination of the flags but I seem to 
always get the same error.    When I look at the tcpdump log, I see 
that the media offer is not on the RTPEngine port. Is there a common 
mis-configuration error that can cause this?


I know I can send all my logs and configurations but I really want to 
try and resolve this as a learning experience.


Thanks all,

-Steve



___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Issue with RTPEngine(6.5.0.0+0~mr6.5.0.0)

[Richard Fuchs]

On 2018-08-16 05:23, Mojtaba wrote:

Hello,
Before i used RTPEngine (6.4.0.0+0~mr6.4.0.0) without any problem,
Nowday i install RTPEngine from git. I notice that it's varsion is
changed to 6.5.0.0+0~mr6.5.0.0. When i want install
ngcp-rtpengine-recording-daemon, I have this issue:
Failed to start ngcp-rtpengine-recording-daemon.service: Unit
rpcbind.socket failed to load: No such file or directory.
invoke-rc.d: initscript ngcp-rtpengine-recording-daemon, action "start" failed.
dpkg: error processing package ngcp-rtpengine-recording-daemon (--install):
  subprocess installed post-installation script returned error exit status 6
Processing triggers for systemd (215-17+deb8u7) ...
Errors were encountered while processing:
  ngcp-rtpengine-recording-daemon

Please let me what is this issue?




Do you have the rpcbind package installed?

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Migrate from RtpProxy to Rtpengine

[Richard Fuchs]

On 2018-08-14 04:45, Nicolas Breuer wrote:

I don't like the msg_apply_changes but can you explain the different behavior 
between rtpproxy & rtpengine?


The difference is due to the fact that rtpengine rewrites and replaces 
the entire SDP body, while rtpproxy only manipulates bits and pieces of 
it (like ports and IP addresses). Since Kamailio doesn't perform SDP 
changes immediately but rather collects them in a lump list and applies 
them only when requested (or when the message is sent out), trying to 
apply two rewrite operations on the same SDP portion doesn't work.


Cheers

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine UDP receive queue issue

[Richard Fuchs]

On 2018-08-08 13:05, Alex Balashov wrote:

On Wed, Aug 08, 2018 at 09:38:02AM -0400, Richard Fuchs wrote:


On 2018-08-08 09:25, Alex Balashov wrote:

Richard,

rtpproxy classic edition had an SDP attribute that could be inserted to
prevent rtpproxy from operating on the SDP if another rtpproxy had
already been engaged upstream. Does RTPEngine have a similar feature?


Yes, if you include the `loop-protect` option.

Thanks! Are there any SDP interoperability concerns with using it?


Not any more than what you would get with rtpproxy doing the same thing :)



The other aspect of this that I am puzzling over is where the packets in
this loop are coming from. The call is long dead, the ports involved are
not in use (per the RTPEngine call list), but I'm still getting:

Aug 08 12:50:00 gw1 rtpengine[18934]: ERR: [992251125_16092378@x.x.x.x port 
60368]: Too many packets in UDP receive queue (more than 50), aborting loop. 
Dropped packets possible

Are these RTP frames that were previously sent at some point during the
call looping?


Hard to say without any further details. What does "long dead" mean 
exactly? Seconds, minutes, hours? A deleted call disappears from the 
call list immediately, but components of it (ports in particular) may 
remain open for a short period of time until all reference counts drop 
to zero. That should take only seconds at most though.


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine UDP receive queue issue

[Richard Fuchs]

On 2018-08-08 09:25, Alex Balashov wrote:

Richard,

rtpproxy classic edition had an SDP attribute that could be inserted to
prevent rtpproxy from operating on the SDP if another rtpproxy had
already been engaged upstream. Does RTPEngine have a similar feature?



Yes, if you include the `loop-protect` option.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] RTPEngine UDP receive queue issue

[Richard Fuchs]

On 2018-08-06 21:17, Alex Balashov wrote:

 From the 5.1 TB transferred on the 'lo' interface (RTPEngine running on
same host as Kamailio):

lo: flags=73  mtu 65536
 inet 127.0.0.1  netmask 255.0.0.0
 inet6 ::1  prefixlen 128  scopeid 0x10
 loop  txqueuelen 1  (Local Loopback)
 RX packets 27694476978  bytes 5678003789723 (5.1 TiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 27694476978  bytes 5678003789723 (5.1 TiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

... I would surmise that this is some sort of loop / infinite loop
condition, but I can't quite put my finger on what it is.

 From an RTPEngine logging standpoint, the scenario begins looking rather
normally:

Aug  6 18:11:04 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
Received command 'offer' from 127.0.0.1:48525
Aug  6 18:11:04 gw1 rtpengine[25476]: NOTICE: 
[1074537188_44545952@20.20.20.20]: Creating new call
Aug  6 18:11:04 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
offer time = 0.000865 sec
Aug  6 18:11:04 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
Replying to 'offer' from 127.0.0.1:48525
Aug  6 18:11:14 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
Received command 'answer' from 127.0.0.1:58668
Aug  6 18:11:14 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
answer time = 0.000123 sec
Aug  6 18:11:14 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
Replying to 'answer' from 127.0.0.1:58668
Aug  6 18:11:18 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20 
port 61666]: Confirmed peer address as 2.2.2.2:38236
Aug  6 18:11:23 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
Received command 'offer' from 127.0.0.1:50995
Aug  6 18:11:23 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
offer time = 0.82 sec
Aug  6 18:11:23 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
Replying to 'offer' from 127.0.0.1:50995
Aug  6 18:11:23 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
Received command 'offer' from 127.0.0.1:47321
Aug  6 18:11:23 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
offer time = 0.000151 sec
Aug  6 18:11:23 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20]: 
Replying to 'offer' from 127.0.0.1:47321
Aug  6 18:11:23 gw1 rtpengine[25476]: INFO: [1074537188_44545952@20.20.20.20 
port 61666]: Switching local interface to 1.1.1.1:61666
Aug  6 18:11:23 gw1 rtpengine[25476]: ERR: [1074537188_44545952@20.20.20.20 
port 61666]: Too many packets in UDP receive queue (more than 50), aborting 
loop. Dropped packets possible
[... ad nauseum... ]

The only thing unusual about it from a SIP perspective is that it
involves an SRTP endpoint and several reinvites which don't seem to be
handled as one would expect:

Aug  6 18:11:04 gw1 /usr/local/sbin/kamailio[22070]: INFO: 
[R-INBOUND-ROUTE-BRANCH:1074537188_44545952@2.2.2.2] Relaying media through 
RTPEngine
Aug  6 18:11:04 gw1 /usr/local/sbin/kamailio[22070]: INFO: 
[R-INBOUND-ROUTE-BRANCH:1074537188_44545952@2.2.2.2] -> Forcing Secure RTP 
(SRTP) profile in offer
Aug  6 18:11:04 gw1 /usr/local/sbin/kamailio[22233]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] Reply '100 Trying' from 3.3.3.3:54246
Aug  6 18:11:04 gw1 /usr/local/sbin/kamailio[22233]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] Reply '180 Ringing' from 
3.3.3.3:54246
Aug  6 18:11:14 gw1 /usr/local/sbin/kamailio[22258]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] Reply '200 OK' from 3.3.3.3:54246
Aug  6 18:11:14 gw1 /usr/local/sbin/kamailio[22258]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] -> Reply contains SDP;  diverting 
through RTPEngine
Aug  6 18:11:14 gw1 /usr/local/sbin/kamailio[22112]: INFO: 
[R-MAIN:1074537188_44545952@2.2.2.2] -> Other sequential ACK received from 
2.2.2.2:5060
Aug  6 18:11:23 gw1 /usr/local/sbin/kamailio[22263]: INFO: 
[R-MAIN:1074537188_44545952@2.2.2.2] -> Re-invite received on rtpengine'd call 
-- updating RTPEngine
Aug  6 18:11:23 gw1 /usr/local/sbin/kamailio[22068]: INFO: 
[R-MAIN:1074537188_44545952@2.2.2.2] -> Re-invite received on rtpengine'd call 
-- updating RTPEngine
Aug  6 18:11:23 gw1 /usr/local/sbin/kamailio[22074]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] Reply '100 Trying' from 1.1.1.1:5060
Aug  6 18:11:23 gw1 /usr/local/sbin/kamailio[22057]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] Reply '100 Trying' from 2.2.2.2:5060
Aug  6 18:11:23 gw1 /usr/local/sbin/kamailio[22070]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] Reply '200 OK' from 2.2.2.2:5060
Aug  6 18:11:23 gw1 /usr/local/sbin/kamailio[22070]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] -> Reply contains SDP;  diverting 
through RTPEngine
Aug  6 18:11:27 gw1 /usr/local/sbin/kamailio[22065]: INFO: 
[R-MAIN-REPLY:1074537188_44545952@2.2.2.2] Reply '200 OK' from 2.2.2.2:5060
Aug  6 18:11:27 

Re: [SR-Users] UDP workers block when one or more rtpengine instances go offline

[Richard Fuchs]

On 2018-08-06 06:58, Sebastian Damm wrote:

Hi,

we run multiple rtpengine servers to share the load. Whenever we need
to take an rtpengine server offline, we used to just block the control
port via iptables, then no new calls ended up on this instance of
rtpengine. This worked pretty well in Kamailio 4.4.5.

However, since Kamailio 5.0, and the problem persists with 5.1.4,
Kamailio hangs almost immediately after we block the control port
traffic. In the log file there are almost no packets processed except
every few seconds, which looks like a timeout thing.

Did we configure anything wrong there? Or is the "dead rtpengine
detection" just broken?

Our configuration:

loadmodule "rtpengine.so"
modparam("rtpengine", "rtpengine_disable_tout", 120)
modparam("rtpengine", "setid_avp", "$avp(rtpsetid)")
modparam("rtpengine", "rtpengine_sock", "0 == udp:1.2.3.4:9001=2
udp:1.2.3.5:9001=2 udp:1.2.3.6:9001=2")
modparam("rtpengine", "rtpengine_sock", "1 == udp:2.3.4.5:9001=2")


When you query the running config via kamcmd for the value of 
rtpengine_tout_ms, what does it say? (Wondering if the default value of 
1000 properly gets established or if some other value is in effect - it 
shouldn't block longer than this value)


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users