11 May
2007
11 May
'07
4:04 p.m.
Yes, it's related (i.e. early CANCELs), but his code modifies how
t_relay handles early CANCEL (to simplify routing logic by for example
sending the CANCEL to the out r-uri of the matching INVITE, dropping it,
or just relaying it).
g-)
Atle Samuelsen wrote:
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 <gustavo.passos.tourinho(a)gmail.com> [070511 13:57]:
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:
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:
> Hello,
>
> Im having some problems with cancelled calls. This is the scenario:
>
> U1 Proxy
U2
>
> INVITE -->>> <<--- 100
Trying
> INVITE -->>>
>
<<--- 100 Trying
> <<--- 100 Trying CANCEL ->>>
<<-- 200 Cancelling
> CANCEL ->> <<--
180 Ringing
> <<-- 487 Cancelled
> <<-- 180 Ringing
>
<<-- 200 OK
> (Wrong??)
> <<-- 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
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers