Hello list! Please help me understand if putting my b2bua in sensory deprivation is actually the best approach to punish it for sole reason of its existence. The background of this horror story is pretty cliche, call center needs a way to infinitely expand, so I'm building a scaling telephony core. Our main protagonist is an innocent b2bua with a very grounded backstory: step 0: receive external instruction to start a call step 1: originate step 2: park step 3: play moh until: - - a) told to pass it to other component - - b) told to hang up - - c) hang up on local timeout A simplified diagram of the call flow looks something like this (repeating names are same components): ### Signaling ### Remote Destination ^ Kamailio-external ^ Freeswitch-originator V Freeswitch- queue V Kamailio-local V Agent ### end of signaling ### ### Media ### Remote Destination ^ Rtpengine-external ^ Freeswitch-originator V Freeswitch-queue V Rtpengine- local V Agent ### end of media ### Due to specifics of the setting, re-negotiating the media and any non-essential signaling with remote destination is a very much last resort. And, as you can imagine, after step3a (pass it to other component), the character development of Freeswitch-originator service stops completely. Well, at least it is doing an honest job by playing the music on hold, which a little bit justifies its presence on the media path. But not for long. In the world of near future, pull request number 3956 is merged with the master branch, exposing the rtpengine API and leaving me no reason not to move MoH to a kernel media player. At this moment I feel a wild urge to get rid of Freeswitch-originator at all, but then I read the sources for mohq and dialog to remind myself that Kamailio is a proxy and proxies can't do this... So I fill b2bua's dialplan with 387.44 million lines of hateful comments and remind it to rcvonly every time it tries to warn the others about the grim fate. When the queue designates an agent to his call, theoretically I don't even need the second freswitch as well - if agen't media session has been established (sometimes ICE take tooo long) with Rtpengine- local, I can bridge their media sessions using publish and subscribe. I'd like to ask your opinion, list: do you see any plotholes potential issues with such deisgn? I'd honestly like to set Freeswitch to bypass-media, so it wont' waste ports and cpu for nothing at all. Are there any issues if I add body for the iniitial invite in the request_route as if it was received in there? Maybe there's a better way, overall? Any critique is welcome! Thank you -- AC