11 May
2007
11 May
'07
4:01 p.m.
Well, if the callee/UAS wrongly sends a 200 OK for INVITE, the
caller/UAC should immediately send a BYE, assuming that their paths crossed.
I would start trying to figure out why the UAS sends the 200 OK if it
already has sent cancelling.
But anyway, a UA can be turned off (power or network cuts) and you have
dangling Start-Invites, so you need a way to deal with those.
g-)
Gustavo Passos Tourinho wrote:
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