[SR-Users] event_route tm:branch-failure and onreply_route shared variables

Володимир Іванець volodyaivanets at gmail.com
Wed Mar 20 16:01:08 CET 2019


Hello again!

My problem was solved by using *t_reuse_branch()* in
*event_route[tm:branch-failure:FAILURE]*.

Thanks a lot!



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

> 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 at 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 at 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 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/20190320/133a4402/attachment.html>


More information about the sr-users mailing list