Hello,
I've got a situation like this:
UAC ---> (Kamailio) ----------> 1. redirect server on branch 1 <---------- 2. 302 redirect ----------> 3. ACK ----------------------------> UAC B
Problem is, if CANCEL comes in at the exact moment that the INVITE to the redirect server (#1) is "in flight", i.e. has not returned a 302 yet, then the transaction gets cancelled and 302 is fed back to the calling UAC.
Having the 302 fed back to the calling UAC in any circumstances is quite undesirable. I just need to drop it. Problem is, in all other situations, I need to use it--I consume it in a failure_route and create new branches based on it.
What's the best way to accomplish this? I'm concerned that if I use a global onreply_route to filter all 302s going back to callers, that will prevent it from percolating down to the failure_route.
Suggestions appreciated, and thanks!
-- Alex
Sounds like t_drop_replies() might be the ticket, but I wanted to check with the Best Practices Council.
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
Thanks, that's what I ended up doing. And yeah, it's the same kind of use case.
On 8 June 2014 18:32:56 GMT-04:00, Brandon Armstead brandon@cryy.com wrote:
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
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
-
Alex Balashov -
Brandon Armstead