15 May
2007
15 May
'07
8:02 p.m.
Last question, I promise :)
A CANCEL request is hop-by-hop. If the proxy receives a cancel (using
his server transaction) it should response and issue a CANCEL request
(using his client transaction) to next hop.
So, if it receives a 200 OK after sent a CANCEL, shouldnt it send a BYE
they self? Insted of relying it to caller?
As I promise, last question and thank you very much for your help.
Regards,
Greger V. Teigre escreveu:
Inline.
Gustavo Passos Tourinho wrote:
Hello All,
I Guess that the Proxy relays 200 OK (INVITE) because it didnt
destroyed the transaction correctely affter it was canceled, right?
No, the proxy MUST relay the 200 OK. The caller UA (UAC) should then
send an immediate BYE. The callee UA (UAS) wrongly(?) sends a 200 OK
after it claims to cancel the call. However, this may happen due to a
race condition that is unavoidable (RFC3261)
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.
Your problem is that the caller UA does not immediately send a BYE.
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.
That's correct, a CANCEL cannot be challenged (as in authentication).
g-)
Well, thank you very much for your help.
Regards,
Gustavo
Greger V. Teigre escreveu:
As I said, I would start finding out why the UA
sends 200 OK after
it has sent > canceling.
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.
g-)
Gustavo Passos Tourinho wrote:
> Hi,
>
> So, is there a BUG in CANCEL transaction?
>
> How can I confirm this information?
>
> Thanks
>
> Atle Samuelsen escreveu:
>> 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
>>> >>>
>> >>