Benoit,
> On May 30, 2024, at 4:05 PM, Benoît Panizzon <[email protected]> wrote:
>
> *sigh* yes I guess you may ask. Somehow I think we do 'normal' VSP
> business, but it looks like we seem to have a complicated set-up.
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.
> [snip description of VSP environment]
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.
> Well, for this to work, I need to run the call separately through
> rtpengine again, with a different callID. If I activate loop-protect on
> rtpengine, then the settings which are compatible towards our SBC and
> interconnection would be sent to the customer as the 2nd invocation of
> rtpengine would be ignored.
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
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
