[SR-Users] Beginner Help: Relay vs Forward

[Michael Iedema]

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 at 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_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/
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users