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

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