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 abalashov@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