Hello,
the module docs are specifying that its necessary that all rtpengine operations on a call should be done on the same set-id, as somehow expected.
I would assume that this also applies to the in-dialog request case. As the module provides different ways to set the set-id (function, AVP), I think right now it needs
to configured manually.
Of course, the module could provide a way of storing a mapping of dialog information to a specific set-id and then using this on later calls of rtpengine functions.
I have not looked into the code to see how easy this would be to add.
Cheers,
Henning
From: Ben Kaufman via sr-users <sr-users@lists.kamailio.org>
Sent: Tuesday, April 15, 2025 6:18 PM
To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
Cc: Ben Kaufman <bkaufman@bcmone.com>
Subject: [SR-Users] RTPEngine pool selection for in-dialog requests
I'm looking for information on the correct way to handle calls to RTPEngine when processing in-dialog requests. I currently have several setid's configured for varying usages. During
processing of an initial INVITE, a determination is made as to if the call will require the use of RTPEngine, and if so, which of the sets should be used. The following is done in code:
·
setid is assigned to AVP
$avp(rtpengine_pool_num)
·
set_rtpengine_set("$avp(rtpengine_pool_num)") is called,
·
rtpengine_offer
is then called.
·
Additionally, a record-route parameter of
proxy_media=yes is added.
·
The flag PROXY_MEDIA is set
In the reply route, the PROXY_MEDIA flag is checked, and if set,
set_rtpengine_set("$avp(rtpengine_pool_num)") is called, followed by
rtpengine_answer
.
When handling an in-dialog message my code didn't have anything to evaluate for the setid.
rtpengine_offer
was just called. Looking at the debug from the rtpengine module, I can see that the record is found in the hashtable, however the node indicated
in that result is not necessarily used - rtpengine will select an entry from the default setid instead. From the rtpengine module logs, IP addresses redacted:
2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine_funcs.c:139]: check_content_type(): type <application/sdp> found valid
2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:2249]: build_rtpp_socks(): same rtpengines list version: 1 (1744651613)
2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3818]: select_rtpp_node_old(): rtpengine hash table lookup find node=udp:A.B.C.D:1234 for calllen=36 callid=ac66f56b-93f8-123e-1b99-0242ac120002 viabranch=
2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3702]: select_rtpp_node_new(): sum is = 210
2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3198]: rtpp_function_call(): proxy reply: d3:sdp288:v=0
o=FreeSWITCH 1744611570 1744611571 IN IP4 W.X.Y.Z
s=FreeSWITCH
c=IN IP4 W.X.Y.Z
My question is really: **SHOULD**
rtpengine_offer
(and
rtpengine_manage
, etc) use the node that it finds in the hash table lookup automatically, or should I have to explicitly set the setid? For now I've solved the
problem by adding the setid to the record-route headers so I can easily retrieve it in dialog, but it seems that if the module finds a record for a node that there should be some way to rely on that explicitly.
|