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
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 TryingCANCEL ->>> <<-- 200 Cancelling CANCEL ->> <<-- 180 Ringing <<-- 487 Cancelled <<-- 180 Ringing
<<-- 200 OK (Wrong??) <<-- 200 OKMy 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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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 TryingCANCEL ->>> <<-- 200 Cancelling CANCEL ->> <<-- 180 Ringing <<-- 487 Cancelled <<-- 180 Ringing
<<-- 200 OK (Wrong??) <<-- 200 OKMy 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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > >
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> >> >> >>>> _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers >>> >
Gustavo Passos Tourinho wrote:
Last question, I promise :)
say, for now, and I may believe you ;-)
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.
Yes and no. There's a difference between a locally generated CANCEL and an externally generated one. SER will generate CANCEL where required in the RFC, but CANCELs coming from downstream needs to be handled by ser.cfg and relayed. The most robust method in 0.9 and 2.0 (not future 2.1) is to let CANCELs with Route be handled by loose_route and then let any CANCELs without Route be handled like INVITE (i.e. rewrite request uri)
So, if it receives a 200 OK after sent a CANCEL, shouldnt it send a BYE they self? Insted of relying it to caller?
No, SER will NEVER generate a BYE. This can only be done by a UAC. According to the RFC, the 200 OK is most likely due to the callee UA not being able to cancel the call before it was picked up, thus a dialog is created. In order to tear down the dialog, the caller has to send a BYE in response even though it CANCELed the call previsouly. How you account is another story, the same happens in PSTN. I believe many telcos bill those calls.
As I promise, last question and thank you very much for your help.
Sure, no probs. g-)
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@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@lists.iptel.org >>> http://lists.iptel.org/mailman/listinfo/serusers >>> >>> >>> >>>> _______________________________________________ > Serusers mailing list > Serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > >>> >>
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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 OKMy 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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Atle Samuelsen -
Greger V. Teigre -
Gustavo Passos Tourinho