[SR-Users] How to retrieve local socket that will be used to send a message from the branch route

Patrick Wakano pwakano at gmail.com
Fri Nov 22 00:01:39 CET 2019


Yes David, we have all sorts of weird things (specially legacy
installations where creativity really shined....). Also, in some private
network architectures my external interface may not have a public IP at
all....
Anyway, I first thought about applying some logic on the destination IP,
but it is only reliable if I know my routing table, and this task Kamailio
already performs when relaying.... The easiest way for now seems to save
the info in the DB, so I explicit tell from which socket each GW is
reachable....

And for curiosity I attempted the $snd() variables but they don't have the
socket information.... the $snd(ip) has the destination IP, not my local
socket as the doc may suggest.....The $branch variable (
http://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#branch_name_-_branch_attributes)
was promising but I couldn't figure out when it is set. In my branch_routes
it is always null......


On Fri, 22 Nov 2019 at 09:15, David Villasmil <
david.villasmil.work at gmail.com> wrote:

> Hello,
>
> Interesting challenge you’ve got.
>
>  It may fail in cases where my kernel routing table has some rule where a
> private IP is reachable via my external interface but different GW for
> example
>
> In this case then, the $du will be a rfc1918 ip but the outgoing interface
> will be a public ip?
>
> Have you tried $send(name) ?
>
> The docs state:
>
> Send Address Attributes
> $sndfrom(name)
>
> *$snd(name)* - return attributes of the address from where the request is
> going to be sent (local socket).
>
> On Thu, 21 Nov 2019 at 22:57, Patrick Wakano <pwakano at gmail.com> wrote:
>
>> Thanks for the replies and examples! Much appreciated!
>>
>> I was thinking of something similar to David suggestion, but I think this
>> is not 100% reliable. It may fail in cases where my kernel routing table
>> has some rule where a private IP is reachable via my external interface but
>> different GW for example (multiple IPs in the same interface or more
>> complex network architecture with VPN or direct link with some
>> endpoint).... So given Kamailio already consults the kernel looking for the
>> correct interface to a given destination, I thought this is actually the
>> correct information I should use in my script. The only problem is that
>> apparently Kamailio is not exposing this info for the script writer....
>> Karsten suggestion should probably work but in short this is just a way
>> to statically save in DB the network routing information I know before
>> hand. If this route changes (which should not happen often I agree) then I
>> have to update the DB. And also this DB data could be replaced by some
>> logic in my script if I had access to the chosen socket... That's exactly
>> the purpose of having mhomed=1 in the script, I don't need to save socket
>> info for all my GWs in DB because I am letting Kamailio automatically
>> decide it. And it does pretty well! The only problem now is that I don't
>> know what this decision was and I need it to implement the RTPEngine logic
>> in my script based on the interface the INVITE will go out.
>>
>> Happy to hear more ideas!
>> Thanks,
>> Kind regards,
>> Patrick Wakano
>>
>> On Thu, 21 Nov 2019 at 20:07, Karsten Horsmann <khorsmann at gmail.com>
>> wrote:
>>
>>> Hi Patrick,
>>>
>>> If you don't use tls at this moment, the config from sbc OS is also an
>>> good example of using dispatcher with the socket params to select the right
>>> sendsock and using vars to give rtpengine the right internal / external
>>> directions. They use numbers for internal and external. To figure out where
>>> the direction is, this config use pseudo vars for receiving local socket
>>>
>>>
>>> https://github.com/voiceboys/sbcOS/blob/master/SbcOS/configs/voice/kamailio/kamailio.cfg#L450
>>>
>>> Cheers
>>> Karsten Horsmann
>>>
>>> Patrick Wakano <pwakano at gmail.com> schrieb am Do., 21. Nov. 2019, 07:11:
>>>
>>>> Hello list,
>>>> Hope you are all doing well!
>>>>
>>>> I am trying to figure out a way to retrieve the local socket the
>>>> t_relay() has decided to use in a mhomed=1 env. Is there a way to do that?
>>>> I couldn't find any variable other than the $snd ones that maybe have this
>>>> info, but I am not using onsend_route anyway.....
>>>> I am after this value because this is what I can use to figure out if I
>>>> need to engage RTPEngine with parameters "external, internal", "external,
>>>> external", "internal, external" or "internal, internal". In my case, my
>>>> server is in between two networks, and calls can traverse or can be routed
>>>> back to the same interface depending on what was decide by the LCR module.
>>>> Signalling is fine, but engaging the RTPEngine must be done with the
>>>> correct parameters to get the correct IPs in the SDP, other else I get one
>>>> way audio in the call.....
>>>>
>>>> Any help is much appreciated!
>>>> Thank you!
>>>> Kind regards,
>>>> Patrick Wakano
>>>>
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.work at gmail.com
> phone: +34669448337
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20191122/302ac074/attachment.html>


More information about the sr-users mailing list