6 Nov
2003
6 Nov
'03
2:21 p.m.
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.
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.
Thanks,
Ricardo Villa
6 Nov
6 Nov
2:28 p.m.
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.
3:02 p.m.
Great! Thanks Jan for your explanation.
----- Original Message -----
From: "Jan Janak" <jan(a)iptel.org>
To: "Ricardo Villa" <ricvil(a)epm.net.co>
Cc: <serusers(a)lists.iptel.org>
Sent: Thursday, November 06, 2003 2:28 PM
Subject: Re: [Serusers] On Reply Processing Question
say
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 > 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:04 p.m.
At 08:21 PM 11/6/2003, 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.
SER does not generate the ACK for a 200 -- UAC does. The ACK is (unless
record-routing is deployed) send directly to UAS. That's how SIP works.
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.
Any follow-up requests either travel directly or follow record-routing
logic. Strictly speaking, they follow dialog rules and a proxy server
is not supposed to determine their routing on its own.
BTW -- DTMF over INFO is proprietary. There is no standard for it, Cisco
gateways do so nevertheless.
-jiri
7721
days inactive
7721
days old
3 comments
3 participants
participants (3)
-
Jan Janak -
Jiri Kuthan -
Ricardo Villa