[SR-Users] Understanding t_relay

Daniel-Constantin Mierla miconda at gmail.com
Mon Feb 9 14:39:00 CET 2015


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 at gmail.com <mailto:miconda at 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 at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150209/940566a4/attachment.html>


More information about the sr-users mailing list