Re: [SR-Users] Beginner Help: Relay vs Forward

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: 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/