<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello All,<br>
<br>
I Guess that the Proxy relays 200 OK (INVITE) because it didnt
destroyed the transaction correctely affter it was canceled, right?<br>
<br>
I was looking for a possible configuration bug (ie. relaying 200 OK
statelessly), but there is no such think. All relays are done by
t_relay () function.<br>
<br>
Another question. If a cancel request is not replyed with a response
after some time, the UA should try to retransmit it? After reading the
RFC 3 times I just so that the CANCEL cannot be challenge.<br>
<br>
Well, thank you very much for your help.<br>
<br>
Regards,<br>
Gustavo<br>
<br>
Greger V. Teigre escreveu:
<blockquote cite="mid46457205.6050909@teigre.com" type="cite">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
As I said, I would start finding out why the UA sends 200 OK after it
has sent canceling.<br>
There is no sign of any bugs in CANCEL transaction. As I explained, the
CVS trunk changes are related to how CANCELs are handled. Your CANCEL
reaches the UA ok.<br>
g-)<br>
  <br>
Gustavo Passos Tourinho wrote:
  <blockquote cite="mid:464469B2.20101@gmail.com" type="cite">
    <meta content="text/html;charset=ISO-8859-1"
 http-equiv="Content-Type">
Hi,<br>
    <br>
So, is there a BUG in CANCEL transaction?<br>
    <br>
How can I confirm this information?<br>
    <br>
Thanks<br>
    <br>
Atle Samuelsen escreveu:
    <blockquote cite="mid20070511124518.GK29224@mystic.cyberhouse.no"
 type="cite">
      <pre wrap="">Hi,

I might be wrong, but I think Andrei added some code in CVS head a few
days back that addresses this issue. 

-A

* Gustavo Passos Tourinho <a moz-do-not-send="true"
 class="moz-txt-link-rfc2396E"
 href="mailto:gustavo.passos.tourinho@gmail.com">&lt;gustavo.passos.tourinho@gmail.com&gt;</a> [070511 13:57]:
  </pre>
      <blockquote type="cite">
        <pre wrap="">Thanks for your reply.

Yes, I have this problem right now. The problem is that when the proxy receives 200 OK (for INVITE, confirmed by CSeq), insted of 200 Cancelling,  it issue 
an RADIUS request for billing.

So, I will have an "Start-Invite" (200 OK), but will have not a "Stop-Bye" because the BYE message will not be generated.

How can I ensure that the proxy will not forward 200 OK for INVITE? I mean, if it is a transaction statefull and the transaction doesnt existis, why it is 
stills forwarding the message? Is there any thing that I can do to prevent this kind of situation to occour?

Thanks again.

Regards,
Gustavo

Greger V. Teigre escreveu:
    </pre>
        <blockquote type="cite">
          <pre wrap="">No, the UAS (U2) shall answer with 200 OK to confirm that the call has been canceled and yes, it should be sent to U1.
Do you have an actual experienced problem or was the 200 OK the problem?
g-)

Gustavo Passos Tourinho wrote:
      </pre>
          <blockquote type="cite">
            <pre wrap="">Hello,

Im having some problems with cancelled calls. This is the scenario:

U1                                     Proxy                                       U2

INVITE   --&gt;&gt;&gt;                                             &lt;&lt;--- 100 Trying
                                        INVITE  --&gt;&gt;&gt;
                                                                           &lt;&lt;--- 100 Trying
                              &lt;&lt;--- 100 Trying  CANCEL  -&gt;&gt;&gt;                                              &lt;&lt;-- 200 Cancelling
                                         CANCEL -&gt;&gt;               &lt;&lt;-- 180 Ringing
                               &lt;&lt;-- 487 Cancelled
                               &lt;&lt;-- 180 Ringing
                                                                                                                                        &lt;&lt;-- 200 OK
                                   (Wrong??)
                                &lt;&lt;-- 200 OK


My problem is that after some time waiting for "ringing", the user cancel the call. Even that proxy responses "487" it still forward the late 200 OK.

Should it forward? I guess not because the transaction was destroyed, right?

Can it be a configuration problem on my ser.cfg ou it can be in t_relay implementation?

Thanks in advanced.
Regards,

Gustavo                       _______________________________________________
Serusers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>


        </pre>
          </blockquote>
        </blockquote>
        <pre wrap="">_______________________________________________
Serusers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
    </pre>
      </blockquote>
      <pre wrap=""><!---->
  </pre>
    </blockquote>
    <br>
  </blockquote>
</blockquote>
<br>
</body>
</html>