[SR-Users] Beginner Help: Relay vs Forward

[Alex Balashov]

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_ip_address

   https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#sp_-_source_port

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/