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:

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: bkaufman@bcmone.com




 

SIP.US Client Support: 800.566.9810  |  SIPTRUNK Client Support: 800.250.6510  |  Flowroute Client Support: 855.356.9768
img
img
img
 
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.