6 Nov
2008
6 Nov
'08
1:40 a.m.
Et al,
Version: openser-1.1.1-notls
I am receiving the following after calling t_relay within the default
route block.
ERROR: t_newtran: transaction already in process 0xb0139638
WARNING:sl:sl_send_reply: I won't send a reply for ACK!!
WARNING: script writer didn't release transaction
This is happening when a downstream UAC dials outbound to the PSTN and
then terminates the call prior to the far ending answering.
UAC send a CANCEL to the proxy, the proxy responds to the UAC with a
'200 canceling' and forwards the CANCEL to the PSTN provider.
The PSTN provider sends 487 Request Terminated to the proxy and the
proxy sends it on to the UAC. UAC responds with an ACK to the proxy.
Is this an issue? How do I handle this dialog withou getting the
t_relay error message?
--
Thanks,
-- Kyle
6 Nov
6 Nov
11:56 a.m.
looks like the ACK is miss-routed.
Usually calling t_relay() for ACK is sufficient (take a look at the
config file generated with sipwise.com wizard for correct CANCEL/ACK
handling.
regards
klaus
Krom schrieb:
Et al,
Version: openser-1.1.1-notls
I am receiving the following after calling t_relay within the default
route block.
ERROR: t_newtran: transaction already in process 0xb0139638
WARNING:sl:sl_send_reply: I won't send a reply for ACK!!
WARNING: script writer didn't release transaction
This is happening when a downstream UAC dials outbound to the PSTN and
then terminates the call prior to the far ending answering.
UAC send a CANCEL to the proxy, the proxy responds to the UAC with a
'200 canceling' and forwards the CANCEL to the PSTN provider.
The PSTN provider sends 487 Request Terminated to the proxy and the
proxy sends it on to the UAC. UAC responds with an ACK to the proxy.
Is this an issue? How do I handle this dialog withou getting the
t_relay error message?
5:05 p.m.
Klaus,
Thank you for the reply and the link. The link help in checking my
work. My script is very simple and even checking against the compiled
scripted from sipwise.com the error persists.
Here is my CANCEL and ACK handling.
if(is_method("CANCEL") || is_method("ACK")) {
if(t_check_trans()) {
if(!t_relay()) sl_reply_error();
}
exit;
}
Here is my route block for PSTN calls.
route[4]
{
if (!load_gws()) {
sl_send_reply("500", "Server Internal Error");
exit;
}
if (!next_gw()) {
sl_send_reply("503", "Service Unavailable");
exit;
}
t_on_failure("2");
t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder
Controller
exit;
}
Here is my failure route.
failure_route[2]
{
if(t_check_status("408|500|503")) {
if (!next_gw()) {
t_reply("503", "Service Unavailable");
exit;
}
t_on_failure("2");
t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder
Controller
}
exit;
}
Any thoughts or errors you see?
Regards.
On Thu, Nov 6, 2008 at 3:56 AM, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
looks like the ACK is miss-routed.
Usually calling t_relay() for ACK is sufficient (take a look at the config
file generated with sipwise.com wizard for correct CANCEL/ACK handling.
regards
klaus
Krom schrieb:
--
Thanks,
-- Kyle
Et al,
Version: openser-1.1.1-notls
I am receiving the following after calling t_relay within the default
route block.
ERROR: t_newtran: transaction already in process 0xb0139638
WARNING:sl:sl_send_reply: I won't send a reply for ACK!!
WARNING: script writer didn't release transaction
This is happening when a downstream UAC dials outbound to the PSTN and
then terminates the call prior to the far ending answering.
UAC send a CANCEL to the proxy, the proxy responds to the UAC with a
'200 canceling' and forwards the CANCEL to the PSTN provider.
The PSTN provider sends 487 Request Terminated to the proxy and the
proxy sends it on to the UAC. UAC responds with an ACK to the proxy.
Is this an issue? How do I handle this dialog withou getting the
t_relay error message?
8:18 p.m.
Klaus,
Some additional information. After viewing a trace I can see that the
error is being generated from the last ACK received from the UAC.
OpenSER/Kamailio is ACK'ing to the 487 from the PSTN provider and then
relaying the 487 to the UAC which in turn ACK's back. It is the last
ACK from the UAC that is getting the error on t_relay. I can assume
because the ACK to the 487 was already sent by OpenSER/Kamailio to the
PSTN upon receiving the initial 487. Something in the script I can
change to prevent this or just ignore the error and move on. :-)
UAC OSER SBC
CANCEL ---> |
CANCEL ---> |
<--- 200 canceling
| <--- 200 OK
| <--- 487 Request Terminated
ACK --->
<--- 487 Reqest Terminated
ACK ---> |
Regards,
-Kyle
On Thu, Nov 6, 2008 at 9:05 AM, Krom <kyle.romulas(a)gmail.com> wrote:
Klaus,
Thank you for the reply and the link. The link help in checking my
work. My script is very simple and even checking against the compiled
scripted from sipwise.com the error persists.
Here is my CANCEL and ACK handling.
if(is_method("CANCEL") || is_method("ACK")) {
if(t_check_trans()) {
if(!t_relay()) sl_reply_error();
}
exit;
}
Here is my route block for PSTN calls.
route[4]
{
if (!load_gws()) {
sl_send_reply("500", "Server Internal Error");
exit;
}
if (!next_gw()) {
sl_send_reply("503", "Service Unavailable");
exit;
}
t_on_failure("2");
t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder
Controller
exit;
}
Here is my failure route.
failure_route[2]
{
if(t_check_status("408|500|503")) {
if (!next_gw()) {
t_reply("503", "Service Unavailable");
exit;
}
t_on_failure("2");
t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder
Controller
}
exit;
}
Any thoughts or errors you see?
Regards.
On Thu, Nov 6, 2008 at 3:56 AM, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
--
Thanks,
-- Kyle
looks like the ACK is miss-routed.
Usually calling t_relay() for ACK is sufficient (take a look at the config
file generated with sipwise.com wizard for correct CANCEL/ACK handling.
regards
klaus
Krom schrieb:
--
Thanks,
-- Kyle
Et al,
Version: openser-1.1.1-notls
I am receiving the following after calling t_relay within the default
route block.
ERROR: t_newtran: transaction already in process 0xb0139638
WARNING:sl:sl_send_reply: I won't send a reply for ACK!!
WARNING: script writer didn't release transaction
This is happening when a downstream UAC dials outbound to the PSTN and
then terminates the call prior to the far ending answering.
UAC send a CANCEL to the proxy, the proxy responds to the UAC with a
'200 canceling' and forwards the CANCEL to the PSTN provider.
The PSTN provider sends 487 Request Terminated to the proxy and the
proxy sends it on to the UAC. UAC responds with an ACK to the proxy.
Is this an issue? How do I handle this dialog withou getting the
t_relay error message?
5866
days inactive
5867
days old
3 comments
2 participants
participants (2)
-
Klaus Darilion -
Krom