8 Jun
2014
8 Jun
'14
9:16 p.m.
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
--
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
8 Jun
8 Jun
9:22 p.m.
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
9 Jun
9 Jun
12:32 a.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:46 a.m.
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(a)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(a)evaristesys.com>
wrote:
--
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
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3828
days inactive
3828
days old
3 comments
2 participants
participants (2)
-
Alex Balashov -
Brandon Armstead