Re: RTPEngine pool selection for in-dialog requests

Henning,

Thank you.  My primary question was about interpretation of how it should work (i.e. Is this a bug or not).  It was a bit confusing to see that the hash table was queried, a result was found, but then it wasn't used, which is why I was asking.  I'm content with "this is the intended functionality, not a bug"

Regards,
Kaufman
________________________________
From: Henning Westerholt <[email protected]>
Sent: Tuesday, April 15, 2025 12:01 PM
To: Kamailio (SER) - Users Mailing List <[email protected]>
Cc: Ben Kaufman <[email protected]>
Subject: RE: RTPEngine pool selection for in-dialog requests


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


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 <[email protected]>
Sent: Tuesday, April 15, 2025 6:18 PM
To: Kamailio (SER) - Users Mailing List <[email protected]>
Cc: Ben Kaufman <[email protected]>
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.

Kaufman

Senior Voice Engineer



E: [email protected]<mailto:[email protected]>






SIP.US Client Support: 800.566.9810  |  SIPTRUNK Client Support: 800.250.6510  |  Flowroute Client Support: 855.356.9768

[img]<https://www.sip.us/>

[img]<https://www.siptrunk.com/>

[img]<https://www.flowroute.com/>



NOTE: This e-mail and any attachments are from BCM One, Inc. and are intended solely for the use and review of the individual(s) to whom it is addressed. If you believe you received this e-mail in error, please notify the sender immediately, delete the e-mail (and any attachments) from your computer and do not copy or disclose it to anyone else.

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!