Hi Brett!

From what I could understand, my client (a Carrier) assigns services and products to its customers identified by trunkgroups (depending on the customer and the service requested, as well as the ingress trunkgroup  the call will be forwarded to a specific egress trunkgroup). 
.
The INVITE is sent by customer to the SBC (ingress), where some kind of process (which i have no details) will decide what IP:Port to forward the messages to Kamailio with additional infos (Kamailio is listening on different NICs/IPs/Ports). Then, Kamailio will check on the (external) routing engine the route to take and forwards to the outbound endpoint. 

Depending on the IP:Port that Kamailio receives the call (SBC may choose one NIC or the other) the request is then received by Kamailio and verified/processed by the routing engine replying back to kamailio with the route to take, and then Kamailio forwards to the outbound endpoint (egress SBC...).

It is a bit confusing, and I want to simplify things as much as possible, but apparently the old/current solution is set this way and they pretend to keep the new solution as similar as possible to the old/current solution. This is mostly due to the billing process, which is very (overly?) complex and they do not pretend to change it.

IMHO, the routing engine should be much simpler but it is a much more complex process the Carrier currently has...and wishes to keep.

(sorry for posting without a subject. I did, however, re-posted with corrected subject)

Atenciosamente / Kind Regards / Cordialement,


Sérgio Charrua


On Fri, Jul 12, 2024 at 8:11 PM Brett Nemeroff <brett@voicefoxtelephony.com> wrote:
Is there a reason you have to identify the trunk group based on received IP/Port? I've seen this as a requirement from some more antiquated systems and it's always a pain. It's always better to use source IP or even a trunk prefix (dialed number prefix) which isn't really secure, but works when security isn't an issue. 

If you have to do it that way, I'd probably turn the $Ri/$Rp into some sort of cache key like $Ri_$Rp and map it to something like a dispatcher setid.

There may be a more modern way to do this, but I don't think there is. 

Good luck! 
-Brett


On Fri, Jul 12, 2024 at 1:40 PM Sergio Charrua via sr-users <sr-users@lists.kamailio.org> wrote:
Hi all!

for a project under development, one requirement is to be able to forward/relay the call to a specific destination depending on which IP Address and Port the call was received by Kamailio. 
This also means that Kamailio will be listening on multiple IP Address and Ports
listen=udp:IP_1:port_1  # trunkgroup 1
listen=udp:IP_2:port_2  # trunkgroup 2
listen=udp:IP_3:port_3  # trunkgroup 3

I know the pv $Ri and $Rp can be used to identify from which IP address and port the message reached Kamailio and having those details, depending on the value, I can define some conditions that allows Kamailio to relay the call to different destination endpoints.
For example: 
- calls from +32 to + 39 received on trunkgroup1 needs to go to Italy SBC address  A.B.C.D
- but calls from +32 to +39 received on trunkgroup2 need to go to Germany on SBC address 1.2.3.4 (as it is cheaper)

Is there a better way of doing this without using IF/THEN/ELSE or SWITCH blocks and "hard code" destination SBC addresses? 
I have read the DRouting module's documentation but not sure if it could help and how...

Any suggestions? 

 

Atenciosamente / Kind Regards / Cordialement,


Sérgio 

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:


--

========================================================
Brett Nemeroff
Voice Fox Telephony LLC
Office: 512-670-8369
Email: brett@voicefoxtelephony.com