Hey community,
I'm trying to understand t_relay () when a forward times out.
This is an abbreviated version of what i have:
Request_route { ... Route(do1) }
Route [do1] { ... T_on_reply (1reply) T_on_failure (1fail) T_relay () }
Reply_route[1reply] { ... If (t_check_status (302)) { Route (do2) } }
Failure_route [1fail] { Xlog (dafail1) }
Route [do2]{ ... T_on_reply (2reply) T_on_failure (2fail) T_relay () }
Reply_route [2reply]{ Xlog (twerked) }
Failure_route [2fail]{ Xlog (failured) }
The case im currently interested in is when the first relay (do1) returns a 302 and then the second (do2) times out.
What happens on the second when it times out, it hits the 1fail failure_route. This messes with my logic as i would've expected (and want to find out how to make it) hit the 2nd failure_route.
I also noticed that if i loop and try the do2 again after the first failure it will then hit the 2fail route.
Any clarification on this subject would be greatly appreciated,
Ryan
Hello,
On 04/02/15 16:28, Ryan Brindley wrote:
Hey community,
I'm trying to understand t_relay () when a forward times out.
This is an abbreviated version of what i have:
Request_route { ... Route(do1) }
Route [do1] { ... T_on_reply (1reply) T_on_failure (1fail) T_relay () }
Reply_route[1reply] { ... If (t_check_status (302)) { Route (do2) } }
Failure_route [1fail] { Xlog (dafail1) }
Route [do2]{ ... T_on_reply (2reply) T_on_failure (2fail) T_relay () }
Reply_route [2reply]{ Xlog (twerked) }
Failure_route [2fail]{ Xlog (failured) }
The case im currently interested in is when the first relay (do1) returns a 302 and then the second (do2) times out.
What happens on the second when it times out, it hits the 1fail failure_route. This messes with my logic as i would've expected (and want to find out how to make it) hit the 2nd failure_route.
I also noticed that if i loop and try the do2 again after the first failure it will then hit the 2fail route.
Any clarification on this subject would be greatly appreciated,
It is not easy to follow your pseduo-code, but it is important to know that the SIP response is handled in an onreply_route. Given that, you cannot call t_relay() on a SIP response (reply). SIP responses are routed automatically based on Via header.
t_relay() must be used only for SIP requests. If you sent the SIP request to many destinations (parallel fork), the tm is waiting for all branches to complete before executing failure_route, the selected response is based on an algorithm derived from SIP RFC specs. If you want to have a routing block executed on a negative reply, use branch_failure_route - in it, you get the request for processing and you can relay it again.
Cheers, Daniel
Hey Daniel,
Thanks for the reply and pointers on what I'm doing wrong. I'll look into the branch_failure_route and read the docs again to make sure I do serial forking and not accidentally creating a parallel fork.
Does there happen to be any good resources (blog posts, wiki articles, books, ancient Egyptian hieroglyphics) on better understanding the handling of requests/responses in Kamailio? Or are the module docs the best available resource?
Thanks,
Ryan
On Wed, Feb 4, 2015 at 1:02 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 04/02/15 16:28, Ryan Brindley wrote:
Hey community,
I'm trying to understand t_relay () when a forward times out.
This is an abbreviated version of what i have:
Request_route { ... Route(do1) }
Route [do1] { ... T_on_reply (1reply) T_on_failure (1fail) T_relay () }
Reply_route[1reply] { ... If (t_check_status (302)) { Route (do2) } }
Failure_route [1fail] { Xlog (dafail1) }
Route [do2]{ ... T_on_reply (2reply) T_on_failure (2fail) T_relay () }
Reply_route [2reply]{ Xlog (twerked) }
Failure_route [2fail]{ Xlog (failured) }
The case im currently interested in is when the first relay (do1) returns a 302 and then the second (do2) times out.
What happens on the second when it times out, it hits the 1fail failure_route. This messes with my logic as i would've expected (and want to find out how to make it) hit the 2nd failure_route.
I also noticed that if i loop and try the do2 again after the first failure it will then hit the 2fail route.
Any clarification on this subject would be greatly appreciated,
It is not easy to follow your pseduo-code, but it is important to know that the SIP response is handled in an onreply_route. Given that, you cannot call t_relay() on a SIP response (reply). SIP responses are routed automatically based on Via header.
t_relay() must be used only for SIP requests. If you sent the SIP request to many destinations (parallel fork), the tm is waiting for all branches to complete before executing failure_route, the selected response is based on an algorithm derived from SIP RFC specs. If you want to have a routing block executed on a negative reply, use branch_failure_route - in it, you get the request for processing and you can relay it again.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
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
Hello,
look also at core cookbook:
- http://www.kamailio.org/wiki/cookbooks/devel/core
More documentation is available at:
- http://www.kamailio.org/w/documentation/
SER Getting Started is old, but still useful to read. Other commercial books can be found out there.
Cheers, Daniel
On 04/02/15 21:57, Ryan Brindley wrote:
Hey Daniel,
Thanks for the reply and pointers on what I'm doing wrong. I'll look into the branch_failure_route and read the docs again to make sure I do serial forking and not accidentally creating a parallel fork.
Does there happen to be any good resources (blog posts, wiki articles, books, ancient Egyptian hieroglyphics) on better understanding the handling of requests/responses in Kamailio? Or are the module docs the best available resource?
Thanks,
Ryan
On Wed, Feb 4, 2015 at 1:02 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, On 04/02/15 16:28, Ryan Brindley wrote: > > Hey community, > > I'm trying to understand t_relay () when a forward times out. > > This is an abbreviated version of what i have: > > Request_route { > ... > Route(do1) > } > > Route [do1] { > ... > T_on_reply (1reply) > T_on_failure (1fail) > T_relay () > } > > Reply_route[1reply] { > ... > If (t_check_status (302)) { > Route (do2) > } > } > > Failure_route [1fail] { > Xlog (dafail1) > } > > Route [do2]{ > ... > T_on_reply (2reply) > T_on_failure (2fail) > T_relay () > } > > Reply_route [2reply]{ > Xlog (twerked) > } > > Failure_route [2fail]{ > Xlog (failured) > } > > The case im currently interested in is when the first relay (do1) > returns a 302 and then the second (do2) times out. > > What happens on the second when it times out, it hits the 1fail > failure_route. This messes with my logic as i would've expected (and > want to find out how to make it) hit the 2nd failure_route. > > I also noticed that if i loop and try the do2 again after the first > failure it will then hit the 2fail route. > > Any clarification on this subject would be greatly appreciated, > It is not easy to follow your pseduo-code, but it is important to know that the SIP response is handled in an onreply_route. Given that, you cannot call t_relay() on a SIP response (reply). SIP responses are routed automatically based on Via header. t_relay() must be used only for SIP requests. If you sent the SIP request to many destinations (parallel fork), the tm is waiting for all branches to complete before executing failure_route, the selected response is based on an algorithm derived from SIP RFC specs. If you want to have a routing block executed on a negative reply, use branch_failure_route - in it, you get the request for processing and you can relay it again. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Ryan Brindley