New subject: [Kamailio-Users] CANCEL and 487 Request Terminated

6 Nov 2008

I think that's the way it should be. First it receive 487 from SBC and immediately it
responds it to SBC with the ACK. Then it passes the 487 to the UAC and receive the ACK,
that's all. It doesn't have to forward that last ACK to the SBC.

----- Mensaje original -----
De: Krom &lt;kyle.romulas(a)gmail.com&gt;
Fecha: Jueves, Noviembre 6, 2008 4:06 pm
Asunto: Re: [Kamailio-Users] CANCEL and 487 Request Terminated

...
  My apologies for the drawing.  Openser is receiving
the 487 from the
 SBC, ACKing back to the SBC and then passing the 487 to the UAC and
 the the UAC ACK's back to Openser.  At which time the error occurs
 because the ACK will not be forwarded since it already ACK'd for the
 487 to the SBC.

 -Kyle

 On Thu, Nov 6, 2008 at 2:42 PM,  &lt;ingdavidcespedes(a)cable.net.co&gt; 
 wrote:> The final 487 should go from openser to UAC, not from SBC 
 to UAC. That's why the final ACK is getting lost, because it was 
 allready ACK'd by openser.

 ----- Mensaje original -----
 De: Krom &lt;kyle.romulas(a)gmail.com&gt;
 Fecha: Jueves, Noviembre 6, 2008 1:18 pm
 Asunto: Re: [Kamailio-Users] CANCEL and 487 Request Terminated

> 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 &lt;kyle.romulas(a)gmail.com&gt;  
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
> > &lt;klaus.mailinglists(a)pernau.at&gt; 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:
> >>>
> >>> 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

 --
 Thanks,
 -- Kyle

 _______________________________________________
 Users mailing list
 Users(a)lists.kamailio.org
 http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

 -- 
 Thanks,
 -- Kyle