[Serusers] On Reply Processing Question

Ricardo Villa ricvil at epm.net.co
Thu Nov 6 21:02:25 CET 2003


Great!  Thanks Jan for your explanation.

----- Original Message ----- 
From: "Jan Janak" <jan at iptel.org>
To: "Ricardo Villa" <ricvil at epm.net.co>
Cc: <serusers at lists.iptel.org>
Sent: Thursday, November 06, 2003 2:28 PM
Subject: Re: [Serusers] On Reply Processing Question


> Hello,
>
> On 06-11 14:21, Ricardo Villa wrote:
> > Hi,
> >
> > The manual explains that we can use "t_on_failure" and "failure_route"
> > primitives to route a SIP request to another destination if the original
> > destination does not answer.  It is very clear to me how this would work
for
> > an INVITE message which receives a confirmation from the far end (like
> > "Trying").   But when the call is established, the originating party
sends
> > an ACK message which is not supposed to receive a reply.  How does SER
know
> > where to send this ACK to??  Does it again try the first destination?
If so
> > then the message will be lost.
>
>   No, the ACK is a mid-dialog request and therefore it will be routed
>   using record routing. That means Request-URI will not contain URI
>   belonging to the server but the contact of the callee (from 200 OK from
>   the callee), that's how SER knows where to send ACK requests. The
>   routing logic in the ser.cfg file is not applied to ACKs.
>
> > And how about INFO messages (like those used to send DTMF tones).  Lets
say
> > a call is established to a backup gateway using "failure_route".  Then
the
> > user sends a DTMF tone as an INFO message (maybe he called an IVR).  How
> > does SER know that this INFO message must go to the backup gateway?  If
SER
> > tries the main gateway first for every single DTMF digit pressed then
this
> > is not going to work properly.
>
>   The same story here. INFO messages in this case are sent within the
>   dialog created by INVITE and thus they will be routed using record
>   routing.
>
>   The same for the final BYE.
>
>   In you switch off record routing on your server then ser will not even
>   see such messages because they will be sent directly from the caller
>   to the callee.
>
>    Jan.
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>






More information about the sr-users mailing list