I am fairly sure it’s been asked a number of times, but is there a way to know the destination, and more especially the transport, of the next hop of a reply message, viewable from onreply_route?
For requests, we have $nh and many other PVs which in some way evidence where it’s going.
And yes, I’m aware that this can be previewed from the onsend_routes*, but I need to amalgamate that knowledge with some transaction-specific data.
Thanks!
— Sent from mobile, with due apologies for brevity and errors.
Hi Alex, What about handling Via header with selects?
Regards,
Arsen Semionov
On Tue, Apr 30, 2019 at 8:39 PM Alex Balashov abalashov@evaristesys.com wrote:
I am fairly sure it’s been asked a number of times, but is there a way to know the destination, and more especially the transport, of the next hop of a reply message, viewable from onreply_route?
For requests, we have $nh and many other PVs which in some way evidence where it’s going.
And yes, I’m aware that this can be previewed from the onsend_routes*, but I need to amalgamate that knowledge with some transaction-specific data.
Thanks!
— Sent from mobile, with due apologies for brevity and errors. _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Tue, Apr 30, 2019 at 09:09:50PM +0500, Arsen wrote:
What about handling Via header with selects?
Possible, just a bit too forensic. Wondered if there was a high-level PV I missed.
The way I am currently handling this problem is by setting an AVP with the transport on which the transaction-forming request was received, the figuring being that this allows me to process the reply as though it will be headed back down that same transport in the end.
But this, too, seems a little too high-coupled for my tastes. I need transaction data anyway, but otherwise prefer to operate as statelessly as possible; it's just a good principle of software engineering IMHO.
-- Alex
-
Alex Balashov -
Arsen