[SR-Users] INVITE forking - uniform way to identify branches

[Ivan Ribakov]

Hi all,

I have a prioritised list of endpoints, where endpoints with the same priority should be sent in parallel:

- endpoint_1_uri; p = 1
- endpoint_2_uri; p = 2
- endpoint_3_uri; p = 4
- endpoint_4_uri; p = 5

As some of the lower priority endpoints are not known upfront, I can not load entire list into the contact list and use TM module's “forking based on Q value” to take care of the rest. So my plan is to load all endpoints with the same priority and fork them in parallel. If none succeed - obtain next endpoint(s) and repeat the process. 

As I go through the above process, I need to update some counters each time delivery to one of the endpoints succeeds or fails. To be able to perform these “housekeeping” tasks I need to be able to clearly identify branches and link them to the destination URI (endpoint URI) of the forked INVITE that started them. Ideally I would like to be able to maintain relationship “branch_id” => “destination URI” where “branch_id” is the identifier that is appended to Via branch parameter. What is the best/most reliable way to achieve this?

I tried logging and observing the value of $du - it was available just before sending out a forked INVITE, but in branch_failure and onreply_route it was <null>.

I tried logging and observing $T_req($du) - I only expected it to work from onreply_route, but it was also <null>.

I tried logging and observing $T_branch_idx - while it was showing meaningful data before sending forked INVITE and during branch_failure route, I couldn’t access it from onreply_route so I couldn’t tell which of the branches current reply is for.

Are there any more variables that could help me build “branch_id” => “destination URI” relationship and access information about “branch_id” and/or “destination URI” from branch_failure and onreply_route?

Apologies in advance for a lengthy description, I did my best to summarise the situation and what I’m trying to achieve.

Regards,
Ivan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200420/ba151910/attachment.html>