Alex, I am not sure of your use case - but one common example I can think of is a LRN service provided via 302 redirect. What we do in this instance is UAC -> Kamailio on this initial transaction we send the call directly to the LRN service (not appending) any other branches and alter the original state of ruri, we then set a special reply route that receives the LRN information, caches it in a database so subsequent requests entirely avoid this process for a period of time since its already cached. We also set a custom failure route that appends the new branch(s) upstream back to LCR / PSTN using LRN information. Now with this said - while the transaction is in flight upstream, and a cancel from UAC is sent, simply flag the transaction / response you receive back from upstream and drop it in the reply.
Sincerely, Brandon Armstead On Sun, Jun 8, 2014 at 12:22 PM, Alex Balashov <abalas...@evaristesys.com> wrote: > Sounds like t_drop_replies() might be the ticket, but I wanted to check > with the Best Practices Council. > > > -- > Alex Balashov - Principal > Evariste Systems LLC > Tel: +1-678-954-0670 > Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ > > Please be kind to the English language: > > http://www.entrepreneur.com/article/232906 > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
