[SR-Users] INVITE forking - uniform way to identify branches
i.ribakov at zaleos.net
Mon Apr 20 17:14:29 CEST 2020
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-users