I just realized that $T_branch(uri) variable in onreply_route[REPLY] is always set to first Contact's Address from AoR list.

вт, 19 бер. 2019 о 12:05 Володимир Іванець <volodyaivanets@gmail.com> пише:
Hello,

I'll try to break down my scenario as detailed as I can :)

Following happens when Kamailio receives INVITE from Asterisk:
1. It decides if Asterisk reaches out to registered UAC.
2. lookup("location") is executed. AoR can have multiple Contacts.
3. Processing reaches branch_route[MANAGE_BRANCH]. String with rtpengine_offer parameters is being formed here. It can have different settings based on each Contact. rtpengine_offer is called.
4. Some phones will respond with 415 or 488. These responces are processed in event_route[tm:branch-failure:FAILURE].
5. Alternative rtpengine_offer parameters are compiled. This time call-id is set to value from Call-ID plus a suffix. This information is stored in Htable. rtpengine_offer is called.
6. $du is set from apropriate Contact's data from reg_fetch_contacts("location", "$ru", "callee") and t_relay() is called.
7. Responce 200 for this branch will be processed in onreply_route[REPLY]. rtpengine_answer parameters are formed including call-id and rtpengine_answer is executed.

The problem is that that I was not able to rely responce on step 7 to new request from steps 4-6. I figured that $(ulc(callee=>addr)[$var(i)]) in event_route[tm:branch-failure:FAILURE] will be the same as $T(ruid) in t_on_reply("REPLY"). At this point I need to perform comparison of $T(ruid) to saved values from Htable.

These values have few dozens of characters and operation of comparison does not look to be efficient.

It also looks like $T_branch(uri) variable (which could be perfect to use on step 7) is not available in responce to new branch because how I set $du and called t_relay(). I was trying to call lookup("location") before t_relay() and $T_branch(uri) would be available but since each AoR can have multiple Contacts this will not work.

Please let me know if I need to provide any clarifications. I will really appreciate any suggestions on improvements that cam be made here.

Thanks a lot!

пн, 18 бер. 2019 о 22:51 Alex Balashov <abalashov@evaristesys.com> пише:
On Mon, Mar 18, 2019 at 12:43:25PM +0200, Володимир Іванець wrote:

> I found much better description of the problem here
> https://lists.kamailio.org/pipermail/users/2008-August/019070.html.

Wow. That is some rather ancient history. And I think reflects a
different place in the evolution of my own understanding of
Kamailio/OpenSER; it was 11 years ago. I don't know if the question is
very pertinent today as formulated there.

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users