Curious: why is this necessary? Is there a possibility there is an unnecessary complicating assumption at the root of your setup? Maybe not, but I have to wonder. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

Benoit, I think the first part of that sentence, about normal VSP business, is a powerful intuition, and you should double down on it instead of waving it away. I've been reading your posts for a while. If you permit me a broad characterisation, which I don't mean to be inflammatory or characterologically unflattering: I think you frequently raise very captivating and nuanced technical problems, and that you are extremely energetic and motivated, and succeed in inventive, innovative, nuanced and incisive technical workarounds, using very clever and original techniques. I'm struck by the level of the quick aptitude for understanding, assimilating and applying small implementational details of all kinds, and the energy and enthusiasm with which you do this again and again. If I had 25% of your vigour and industry, I might be a very wealthy man. But almost every time, I wonder: "What is so complex about his service provider environment? Is he providing something so intricate? Very large-scale? Planetary? Intergalactic?" :-) Often, overly clever workarounds and innovations end up being counterproductive in the long run, because they leave behind a devastating trail of technical debt, complicate institutional memory and knowledge transfer, create friction in training and communication of how the system works, impede delegation and the creation of replicable business processes around it, etc. And from a purely engineering point of view, overly complicated systems are more susceptible to bit rot, lopsided maintenance, and in general, entropy. Squeezing the balloon of complexity in one place inflates it somewhere else. One cannot escape thermodynamics. I appreciate the well-rounded and detailed description. From my perspective, I think it confirms that you are not doing anything extraordinary or overly unusual, and probably should not require many extraordinary or overly unusual tricks. RTPEngine's loop-protect solution, as you point out, has the pitfall that many UAs improperly reflect the 'a=rtpengine:xxx' attribute, even though the standards are crystal-clear that they are not to reflect SDP attributes they don't understand. The standards are equally clear that endpoints are to ignore any SDP attributes they don't understand. I think this is an example of a situation--perhaps one of many--where you just need some zoomed-out, big-picture perspective, rather than yet another technical fix. From a functional perspective, both approaches will solve your problem, but methodologically, the latter is more likely to leave you with more problems. Consider: - SIP proxies participate in a single logical call leg. Leg A comes in, leg A goes out. - In contrast, the better-known B2BUAs (Back-to-Back User Agents), on which most big brand SBCs, PBXs and softswitches are founded, mediate two logically independent call legs: Leg "A" in, Leg "B" out. These have their own Call-IDs, From/To tags, sequence numbers, and other SIP attributes, and the B2BUA is free to decide the level of opacity, or transparency, with which it shall translate events on leg "B" back to leg "A", and vice versa. In contrast, a proxy does not have the flexibility to do this, and must instead propagate events with fidelity along one chain between both parties; - There are numerous technical trade-offs to the B2BUA and proxy approach, and they should be carefully weighed. The proxy approach doesn't "naturally" provide topology hiding, and poses an array of possible issues related to sending a call back (call looping) to the same UA that initiated it. Even where dialog spiraling can be used to obviate the most straightforward problem, other issues arise; - Kamailio, by virtue of being a SIP proxy at the core, mandates the proxy approach; - Because RTPEngine tracks call state by <Call-ID, From-tag>, that is one of the complications in the penultimate point; - Only a relatively small percentage of your calls are "hairpinned" or "on-net" ("Hey, it's also a customer of ours, let's route the call back to the registrar!"), so you don't need to architect your entire platform around this principle; by definition, these calls are exceptional, even if they are not astronomically rare; - For those calls, you could deploy a lightweight, signalling-only B2BUA to solve these "looping" problems. SEMS has historically been recommended for this purpose often, but the community edition has fallen into a bit of disrepair. FreeSWITCH, Asterisk, Drachtio, and others make good alternatives. Adding a B2BUA to your platform is also a moving part and introduces complexity. However, the call flow is extremely straightforward, the software componentry involved is very straightforward, and forwarding requests is a core competency of Kamailio that is very idiomatic. Compared to your solution of manipulating the Call-ID in baroque ways, it's much less internally complex, and runs in more well-worn grooves that will be more easily understood by other Kamailio operators and SIP experts in the future. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

Fred, This is beautiful: <extension name="b2bua"> <condition field="destination_number" expression="^b2bua-(.+)$"> <action application="log" data="INFO entered b2bua extension"/> <action application="set" data=“sendto=${sip_via_host}:5080"/> <action application="set" data="bypass_media=true"/> <action application="set" data="sip_copy_custom_headers=false"/> <action application="bridge" data="[sip_h_X-PGPX=${uuid}]sofia/internal/$1@${sendto}"/> <action application="hangup"/> </condition> I was not aware it was that simple. Thank you for the education! -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

Indeed, and this is why I recommended it. It would solve a larger class of problems, above and beyond the one you currently face with RTPEngine per se. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800