12 Jul
2024
12 Jul
'24
4:59 p.m.
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(a)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(a)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(a)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(a)voicefoxtelephony.com