Thank you to everyone who has chimed in on this thread. I’m learning a lot! I now have
some successful flows and have resolved the bind issue by setting a specific bind
interface.
The reason for such specialized endpoints (one for REGISTER, one for INVITE, etc) is that
they already exist. My intention is to place Kamailio in front of them to eventually
accomplish the following soft migration:
1) initially just forward traffic transparently from the originator to allow the legacy
endpoints to continue to serve
2) new SIP accounts will be added which are not present in the legacy endpoints’
databases
3) when Kamailio sees a 404 when passing through the traffic, it will then handle the
traffic itself
4) eventually all accounts will be transitioned to use the new Kamailio-only route so the
legacy endpoints can be deprecated
With all of that in mind, t_relay() doesn’t look like it’s going to get me there. I want
Kamailio to be able to see everything going on between the origination and legacy
endpoints but right now they respond to the originator directly without passing back
through Kamailio on the return.
Apologies again for the possible rephrasing of the same technical question. I probably
should have explained my design’s purpose in the beginning to clarify why I cannot let the
Kamailio instance be optimized out of the path.
Thanks as always for your time,
-Michael
On Nov 20, 2019, at 16:08, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hi Michael,
First, the "no corresponding socket" issue is the result of a
determination by Kamailio that it has no outgoing listener (the
combination of transport protocol, IP address and port) interface that
can reach the destination network of the next hop.
The way that Kamailio makes this determination is influenced by this
setting -- not sure if you have it on.
https://www.kamailio.org/wiki/cookbooks/5.3.x/core#mhomed
Keep in mind that the entire triplet - (transport, address, port) -
matters.
Second, I noticed your comment
# ORIGINATOR sent us something
and considered this condition:
if ( $(ct{nameaddr.uri}{uri.port}) == PORT_ORIGINATOR )
it's probably worth keeping in mind that Contact is a fairly cosmetic
value and can be set to just about anything, and most importantly, can
be spoofed. So, if you are using this to determine whether a given
component of your infrastructure sent you something, you might want to
operate on the real source address and port of the SIP message instead:
https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#si_-_source_i…
https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#sp_-_source_p…
Third: this is by way of philosophical commentary only, and under the
aegis of "helping newbies" :-) -- others may disagree, and are free to
do so.
Early on in my experience with Kamailio (then OpenSER), I was
responsible for some rather unfortunately baroque platform architecture
designs involving many specialised Kamailio proxies performing esoteric
functions. This was based on a consistent tendency to underestimate how
much traffic Kamailio can actually handle and how much work it can do.
I've designed platforms with a dedicated registrar, dedicated business
logic / call processing logic, and a carrier-facing element, separated
into multiple instances, all deployed with redundant mates, etc.
Some of them I still have to support, and they're a nightmare, and most
importantly of all, from a technical point of view they're completely
unnecessary. In hindsight, it was all a mistake, and can easily be done
with a single Kamailio element 99% of the time (as long as the config is
manageable in its organisation), and I regret it all deeply. Cloud
orchestration / deployment tooling that did not exist in those days
might have made it a little easier, but also in many respects more
complicated due to all the service discovery required.
I was thinking about this in the context of:
Originator:
- reachable on port 5060
- originates all traffic to the services
Service A:
- reachable on port 5061
- handles REGISTER
Service B:
- reachable on port 5062
- handles INVITE
Service C:
- reachable on port 5063
- handles MESSAGE
I could be wrong, and you might have very credible reasons for such a
design, but at first glance it reminds me of some massively
overcomplicated things I built when I first got started with Kamailio.
:-) As I said, they were all based on a perception that this or that
element can only handle so much, but it turns out one element can handle
it all - and 20x more.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web:
http://www.evaristesys.com/,
http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users