Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
--------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
The 100 Trying is hardcoded and you'll have to look for it in the code, remove it, and recompile.
After that, you should send back from your config file the 100 Trying response in the convenient places to stop retransmissions.
Samuel.
2007/2/15, Abdul Qadir ablqadir@yahoo.com:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi,
Thanx for the tip, I found the file and will try this way.
Is there any way we can get user agent value inside the script, so that i can put some check for it and decide whether to send 100 or not.
Thanks Abdul Qadir
samuel samu60@gmail.com wrote: The 100 Trying is hardcoded and you'll have to look for it in the code, remove it, and recompile.
After that, you should send back from your config file the 100 Trying response in the convenient places to stop retransmissions.
Samuel.
2007/2/15, Abdul Qadir :
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------- Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
tectops module with search is the only way to get the User-Agent in SER version 0.9.x
If you're using newer versions you can use select framework to get the value of any (?) header of the incoming SIP request.
Samuel.
2007/2/16, Abdul Qadir ablqadir@yahoo.com:
Hi,
Thanx for the tip, I found the file and will try this way.Is there any way we can get user agent value inside the script, so that i can put some check for it and decide whether to send 100 or not.
Thanks Abdul Qadir
samuel samu60@gmail.com wrote: The 100 Trying is hardcoded and you'll have to look for it in the code, remove it, and recompile.
After that, you should send back from your config file the 100 Trying response in the convenient places to stop retransmissions.
Samuel.
2007/2/15, Abdul Qadir :
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone
A).
The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
I tried to capture a log of message and found that Phone A "CANCEL"
message
is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull
SER,
so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
That's a race condition in SER solved in newer versions.
I observed always this behaviour and new versions properly matches CANCEL with INVITE transaction and the "sipiral" (ending in Too Many Hops) does not occur.
Samuel.
2007/2/16, Abdul Qadir ablqadir@yahoo.com:
Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another
nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL"
message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull
SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
It may be that you are not handling the CANCEL correctly. An early CANCEL (no Route headers) will have to be routed as an INVITE. g-)
Abdul Qadir wrote:
Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
*/Klaus Darilion klaus.mailinglists@pernau.at/* wrote:
Abdul Qadir wrote: > Hi , > > I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation. > Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu > I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. > > Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome. > > Thanking you all in advance. > > Best Regards, > Abdul Qadir > > > --------------------------------- > Don't be flakey. Get Yahoo! Mail for Mobile and > always stay connected to friends. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Serusers mailing list > Serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers -- Klaus Darilion nic.at
Food fight? http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367 Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
mmm
i'll take a look at the config...
maybe i just had a wrong config after all...if that's the case, apologies for the false "race condition" :P samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
It may be that you are not handling the CANCEL correctly. An early CANCEL (no Route headers) will have to be routed as an INVITE. g-)
Abdul Qadir wrote: Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to
another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL"
message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull
SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. ________________________________
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
i'm pretty sure CANCEL hits t_relay and should be matched agains INVITE transaction...the only main routing difference between CANCEL and INVITE is NAT stuff and lookupXXXX which I think it does not affect this thread's topic, or did i miss something??
Try to dial a number and immediately hang up...don't you see the Too Many Hops?
Samuel.
2007/2/16, samuel samu60@gmail.com:
mmm
i'll take a look at the config...
maybe i just had a wrong config after all...if that's the case, apologies for the false "race condition" :P samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
It may be that you are not handling the CANCEL correctly. An early CANCEL (no Route headers) will have to be routed as an INVITE. g-)
Abdul Qadir wrote: Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to
another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL"
message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull
SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. ________________________________
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
My point was that such CANCEL must hit lookup. If not ser has no way of knowing where to route it (as there are no Route headers). Obviously t_relay will lookup the ruri using dns, resolve it to your ser and then you get into a loop. g-)
samuel wrote:
i'm pretty sure CANCEL hits t_relay and should be matched agains INVITE transaction...the only main routing difference between CANCEL and INVITE is NAT stuff and lookupXXXX which I think it does not affect this thread's topic, or did i miss something??
Try to dial a number and immediately hang up...don't you see the Too Many Hops?
Samuel.
2007/2/16, samuel samu60@gmail.com:
mmm
i'll take a look at the config...
maybe i just had a wrong config after all...if that's the case, apologies for the false "race condition" :P samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
It may be that you are not handling the CANCEL correctly. An early
CANCEL
(no Route headers) will have to be routed as an INVITE. g-)
Abdul Qadir wrote: Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL
hit SER
an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to
another nokia sip phone. The call works fine. The problem comes
only when I
call from Phone A to Phone B and then immediately cancel the
call(from Phone
A). The Phone A will hangup the call as it sent CANCEL but the SER
will
ignore this CANCEL and still send INVITE to Phone B resulting in a
ghost
call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL"
message is received on SER even before any provisional response
from Phone
B. Therefor SER doesnot relay this CANCEL request to Phone B. I
even checked
RFC which clearly says that UAC should not send CANCEL untill it
receives
any provisional response. I talked to Nokia expert and they said
the 100
Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run
statefull
SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.
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
everyday I learn something!!!! :D I has assumed CANCEL was "magically" processed by tm module. i'll lookup() CANCEL requests...
Thank you, samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
My point was that such CANCEL must hit lookup. If not ser has no way of knowing where to route it (as there are no Route headers). Obviously t_relay will lookup the ruri using dns, resolve it to your ser and then you get into a loop. g-)
samuel wrote:
i'm pretty sure CANCEL hits t_relay and should be matched agains INVITE transaction...the only main routing difference between CANCEL and INVITE is NAT stuff and lookupXXXX which I think it does not affect this thread's topic, or did i miss something??
Try to dial a number and immediately hang up...don't you see the Too Many Hops?
Samuel.
2007/2/16, samuel samu60@gmail.com:
mmm
i'll take a look at the config...
maybe i just had a wrong config after all...if that's the case, apologies for the false "race condition" :P samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
It may be that you are not handling the CANCEL correctly. An early
CANCEL
(no Route headers) will have to be routed as an INVITE. g-)
Abdul Qadir wrote: Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL
hit SER
an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to
another nokia sip phone. The call works fine. The problem comes
only when I
call from Phone A to Phone B and then immediately cancel the
call(from Phone
A). The Phone A will hangup the call as it sent CANCEL but the SER
will
ignore this CANCEL and still send INVITE to Phone B resulting in a
ghost
call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL"
message is received on SER even before any provisional response
from Phone
B. Therefor SER doesnot relay this CANCEL request to Phone B. I
even checked
RFC which clearly says that UAC should not send CANCEL untill it
receives
any provisional response. I talked to Nokia expert and they said
the 100
Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run
statefull
SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.
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
confirmed: after lookingup() CANCELs no more spirals around!!!! no "race condition", no "failure"... simply my mistake, apologies :P
waiting for delayed CANCELs....
Samuel.
2007/2/16, samuel samu60@gmail.com:
everyday I learn something!!!! :D I has assumed CANCEL was "magically" processed by tm module. i'll lookup() CANCEL requests...
Thank you, samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
My point was that such CANCEL must hit lookup. If not ser has no way of knowing where to route it (as there are no Route headers). Obviously t_relay will lookup the ruri using dns, resolve it to your ser and then you get into a loop. g-)
samuel wrote:
i'm pretty sure CANCEL hits t_relay and should be matched agains INVITE transaction...the only main routing difference between CANCEL and INVITE is NAT stuff and lookupXXXX which I think it does not affect this thread's topic, or did i miss something??
Try to dial a number and immediately hang up...don't you see the Too Many Hops?
Samuel.
2007/2/16, samuel samu60@gmail.com:
mmm
i'll take a look at the config...
maybe i just had a wrong config after all...if that's the case, apologies for the false "race condition" :P samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
It may be that you are not handling the CANCEL correctly. An early
CANCEL
(no Route headers) will have to be routed as an INVITE. g-)
Abdul Qadir wrote: Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL
hit SER
an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to
another nokia sip phone. The call works fine. The problem comes
only when I
call from Phone A to Phone B and then immediately cancel the
call(from Phone
A). The Phone A will hangup the call as it sent CANCEL but the SER
will
ignore this CANCEL and still send INVITE to Phone B resulting in a
ghost
call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL"
message is received on SER even before any provisional response
from Phone
B. Therefor SER doesnot relay this CANCEL request to Phone B. I
even checked
RFC which clearly says that UAC should not send CANCEL untill it
receives
any provisional response. I talked to Nokia expert and they said
the 100
Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run
statefull
SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.
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
I forward this from the serusers list:
A CANCEL is being sent from a UAC before having established a route set, thus the CANCEL has no Route header and is not caught by loose routing. The below thread shows that this case is difficult to understand. Jiri and Bogdan had a discussion on serusers regarding the race condition where the provisional reply from UAS and the CANCEL cross each other.
Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?
Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.
Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective)
Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?
g-)
samuel wrote:
confirmed: after lookingup() CANCELs no more spirals around!!!! no "race condition", no "failure"... simply my mistake, apologies :P
waiting for delayed CANCELs....
Samuel.
2007/2/16, samuel samu60@gmail.com:
everyday I learn something!!!! :D I has assumed CANCEL was "magically" processed by tm module. i'll lookup() CANCEL requests...
Thank you, samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
My point was that such CANCEL must hit lookup. If not ser has no
way of
knowing where to route it (as there are no Route headers). Obviously t_relay will lookup the ruri using dns, resolve it to
your ser
and then you get into a loop. g-)
samuel wrote:
i'm pretty sure CANCEL hits t_relay and should be matched agains INVITE transaction...the only main routing difference between CANCEL and INVITE is NAT stuff and lookupXXXX which I think it does not affect this thread's topic, or did i miss something??
Try to dial a number and immediately hang up...don't you see the Too Many Hops?
Samuel.
2007/2/16, samuel samu60@gmail.com:
mmm
i'll take a look at the config...
maybe i just had a wrong config after all...if that's the case, apologies for the false "race condition" :P samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
It may be that you are not handling the CANCEL correctly. An
early
CANCEL
(no Route headers) will have to be routed as an INVITE. g-)
Abdul Qadir wrote: Hi,
>I think ser should remember canceled transactions and send
CANCEL in
>case of delayed provisional replies.
At present I don't think its working like this, As soon as
CANCEL
hit SER
an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has
dropped after
sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote: > Hi , > > I tried to call from one nokia sip (E61 and other models
)phone to
another nokia sip phone. The call works fine. The problem comes
only when I
call from Phone A to Phone B and then immediately cancel the
call(from Phone
A). The Phone A will hangup the call as it sent CANCEL but the
SER
will
ignore this CANCEL and still send INVITE to Phone B resulting
in a
ghost
call situation. >
Hi!
I think ser should remember canceled transactions and send
CANCEL in
case of delayed provisional replies.
regards klasu
> I tried to capture a log of message and found that Phone A
"CANCEL"
message is received on SER even before any provisional response
from Phone
B. Therefor SER doesnot relay this CANCEL request to Phone B. I
even checked
RFC which clearly says that UAC should not send CANCEL untill it
receives
any provisional response. I talked to Nokia expert and they said
the 100
Trying message from your server is considered as provisional
response,
therefor behaviour of client is absolutely correct. > > Is there any way I can stop 100 Trying message and still run
statefull
SER, so that I can verify what nokia said. Any ideas
suggestions are
welcome. > > Thanking you all in advance. > > Best Regards, > Abdul Qadir > > > --------------------------------- > Don't be flakey. Get Yahoo! Mail for Mobile and > always stay connected to friends. > > >
> > _______________________________________________ > Serusers mailing list > Serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.
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
Greger V. Teigre wrote:
I forward this from the serusers list:
A CANCEL is being sent from a UAC before having established a route set, thus the CANCEL has no Route header and is not caught by loose routing. The below thread shows that this case is difficult to understand. Jiri and Bogdan had a discussion on serusers regarding the race condition where the provisional reply from UAS and the CANCEL cross each other.
I seem to have missed this discussion, but shouldn't the race be between the final reply and the CANCEL?
In SER, there is a race between the INVITE and the CANCEL: If the INVITE processing hasn't been finished and the transaction for it has not yet been established through t_relay() before the CANCEL arrives, things go wonky.
Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?
If you already have a transaction for the INVITE, you should be fine by simply passing the CANCEL to tm by calling t_relay(). Don't remember what tm does with a CANCEL it doesn't have a transaction for. IMHO it should do nothing and give an error back.
Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.
The state is there the moment a transaction is established. The problem here is that SER doesn't CANCEL branches that have not yet received a 100 Trying since The Standard doesn't allow you to.
Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective)
As usual: Ignore. It's a borderline case, anyways. Most likely, it will fix itself anyways because the person that receives the false call will hang up and thus their UA will generate a BYE.
Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?
This depends on what tm is doing with a CANCEL it can't find a transaction for. If I understand the code right, it currently treats such a CANCEL as if it were nothing special. This would actually be in violation of 3261 which states that you MUST forward the CANCEL statelessly. However, the reasoning is that this is because the proxy may have forwarded the INVITE statelessly earlier. Since I never do that, I would happily violate that MUST.
Regards, Martin
FYI: This is the pragmatic approach how openser users handle the problem:
1. drop the CANCEL if there is no corresponding INVITE transaction. The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n"); exit; }
2. delayed CANCEL. If openser hasn't forward a CANCEL because of missing provisional response, it remembers this branch and sends a CANCEL of there is a delayed provisional response from the caller (at least in CVS=1.2)
regards klaus
Martin Hoffmann wrote:
Greger V. Teigre wrote:
I forward this from the serusers list:
A CANCEL is being sent from a UAC before having established a route set, thus the CANCEL has no Route header and is not caught by loose routing. The below thread shows that this case is difficult to understand. Jiri and Bogdan had a discussion on serusers regarding the race condition where the provisional reply from UAS and the CANCEL cross each other.
I seem to have missed this discussion, but shouldn't the race be between the final reply and the CANCEL?
In SER, there is a race between the INVITE and the CANCEL: If the INVITE processing hasn't been finished and the transaction for it has not yet been established through t_relay() before the CANCEL arrives, things go wonky.
Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?
If you already have a transaction for the INVITE, you should be fine by simply passing the CANCEL to tm by calling t_relay(). Don't remember what tm does with a CANCEL it doesn't have a transaction for. IMHO it should do nothing and give an error back.
Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.
The state is there the moment a transaction is established. The problem here is that SER doesn't CANCEL branches that have not yet received a 100 Trying since The Standard doesn't allow you to.
Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective)
As usual: Ignore. It's a borderline case, anyways. Most likely, it will fix itself anyways because the person that receives the false call will hang up and thus their UA will generate a BYE.
Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?
This depends on what tm is doing with a CANCEL it can't find a transaction for. If I understand the code right, it currently treats such a CANCEL as if it were nothing special. This would actually be in violation of 3261 which states that you MUST forward the CANCEL statelessly. However, the reasoning is that this is because the proxy may have forwarded the INVITE statelessly earlier. Since I never do that, I would happily violate that MUST.
Regards, Martin _______________________________________________ Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Hi,
Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the problem:
- drop the CANCEL if there is no corresponding INVITE transaction.
Why not politely return an error?
The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)
Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n"); exit; }
I guess the protocol might have to be checked, as well (at least to reply with an error, rather than drop): for reliable transports you won't see any retransmission and it seems that a client is allowed to open a second connection for the CANCEL[*]; given the fact that INVITEs usually go through multiple checks, the probability of a CANCEL being run against the "transaction table" before the INVITE might not be that low, after all (especially on loaded servers).
[*]: " If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection MAY be opened and used." (RFC3261)
- delayed CANCEL. If openser hasn't forward a CANCEL because of
missing provisional response, it remembers this branch and sends a CANCEL of there is a delayed provisional response from the caller (at least in CVS=1.2)
Yes, there is a pending feature request for this issue, which will probably make to next release.
Cheers, Bogdan.
regards klaus
Martin Hoffmann wrote:
Greger V. Teigre wrote:
I forward this from the serusers list:
A CANCEL is being sent from a UAC before having established a route set, thus the CANCEL has no Route header and is not caught by loose routing. The below thread shows that this case is difficult to understand. Jiri and Bogdan had a discussion on serusers regarding the race condition where the provisional reply from UAS and the CANCEL cross each other.
I seem to have missed this discussion, but shouldn't the race be between the final reply and the CANCEL?
In SER, there is a race between the INVITE and the CANCEL: If the INVITE processing hasn't been finished and the transaction for it has not yet been established through t_relay() before the CANCEL arrives, things go wonky.
Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?
If you already have a transaction for the INVITE, you should be fine by simply passing the CANCEL to tm by calling t_relay(). Don't remember what tm does with a CANCEL it doesn't have a transaction for. IMHO it should do nothing and give an error back.
Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.
The state is there the moment a transaction is established. The problem here is that SER doesn't CANCEL branches that have not yet received a 100 Trying since The Standard doesn't allow you to.
Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective)
As usual: Ignore. It's a borderline case, anyways. Most likely, it will fix itself anyways because the person that receives the false call will hang up and thus their UA will generate a BYE.
Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?
This depends on what tm is doing with a CANCEL it can't find a transaction for. If I understand the code right, it currently treats such a CANCEL as if it were nothing special. This would actually be in violation of 3261 which states that you MUST forward the CANCEL statelessly. However, the reasoning is that this is because the proxy may have forwarded the INVITE statelessly earlier. Since I never do that, I would happily violate that MUST.
Regards, Martin _______________________________________________ Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Bogdan Pintea wrote:
Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the problem:
- drop the CANCEL if there is no corresponding INVITE transaction.
Why not politely return an error?
The assumption is that there is a race and that there will be a transaction soon and all is fine with the re-transmit.
The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)
Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?
When does the "100 Trying" happen in SER. You are, of course, right that this fixes the race (and explains why the rule not to cancel transactions without provisional responses exists in the first place).
Which makes it all the more apparent that t_relay() should never relay a CANCEL. Ever. It should return with an error and I then can decide whether I have a stateless proxy or not to statelessly forward the CANCEL or just error it away.
Regards, Martin
On Feb 26, 2007 at 17:45, Martin Hoffmann hn@nvnc.de wrote:
Bogdan Pintea wrote:
Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the problem:
- drop the CANCEL if there is no corresponding INVITE transaction.
Why not politely return an error?
The assumption is that there is a race and that there will be a transaction soon and all is fine with the re-transmit.
The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)
Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?
When does the "100 Trying" happen in SER. You are, of course, right that this fixes the race (and explains why the rule not to cancel transactions without provisional responses exists in the first place).
Which makes it all the more apparent that t_relay() should never relay a CANCEL. Ever. It should return with an error and I then can decide whether I have a stateless proxy or not to statelessly forward the CANCEL or just error it away.
I think it should relay the CANCEL and if an INVITE comes and the CANCEL transaction is still alive, it should reply w/ 487 (Ottendorf does this).
Andrei
Andrei Pelinescu-Onciul wrote:
On Feb 26, 2007 at 17:45, Martin Hoffmann hn@nvnc.de wrote:
Which makes it all the more apparent that t_relay() should never relay a CANCEL. Ever. It should return with an error and I then can decide whether I have a stateless proxy or not to statelessly forward the CANCEL or just error it away.
I think it should relay the CANCEL and if an INVITE comes and the CANCEL transaction is still alive, it should reply w/ 487 (Ottendorf does this).
But isn't there a potential for DOS? Since CANCELs can only be accepted (no auth*), sending CANCELs to nowhere (from anonymous.invalid :) ) seems the easiest solution to eat fast the shm.
Bogdan.
Andrei
On Feb 27, 2007 at 23:33, Bogdan Pintea pintea@iptego.de wrote:
Andrei Pelinescu-Onciul wrote:
On Feb 26, 2007 at 17:45, Martin Hoffmann hn@nvnc.de wrote:
Which makes it all the more apparent that t_relay() should never relay a CANCEL. Ever. It should return with an error and I then can decide whether I have a stateless proxy or not to statelessly forward the CANCEL or just error it away.
I think it should relay the CANCEL and if an INVITE comes and the CANCEL transaction is still alive, it should reply w/ 487 (Ottendorf does this).
But isn't there a potential for DOS? Since CANCELs can only be accepted (no auth*), sending CANCELs to nowhere (from anonymous.invalid :) ) seems the easiest solution to eat fast the shm.
Good point. I guess the choice is between a potential CANCEL DOS and more reliability in sending CANCELs. You could workaround the potential CANCEL DOS using ratelimit, pike or something similar.
The big problems that statefull CANCELs solve are: - it's not so uncommon to have an INVITE quickly followed by a CANCEL and the INVITE processing delayed due to auth/db lookups/a.s.o. In this case the CANCEL could reach tm before the INVITE. If you would drop or forward the CANCEL statlessly, you won't be able to match it to the INVITE and so you'll have an INVITE after CANCEL (and the phone will ring). If you forward the CANCEL statefully in the worst case you'll get an error reply from the destination (no transaction), but when tm gets to the INVITE it can see that's already canceled and stop its processing (if the delay is no longer then wt_timer - 5 s by default). - if you missed the INVITE (e.g. restart, failover to another server, INVITE silently terminated) it's important to forward the CANCEL exactly in the same way as the INVITE. If we would forward it statelessly you won't have any failure routes for it so it won't be forwarded in the same way as an INVITE that (for example) could be forwarded on timeout to some other host (in the failure route). Same goes for dns (e.g. foo resolves to several ips and the first ips returns 503 => the INVITE will be forwarded to the next one, but if you forward the CANCEL statelessly it will go only to the first ip).
OTOH if it makes everybody happy I will make CANCEL handling a tm option (with the current behaviour as default) so that everyone can choose between: forward statefully (and solve also the CANCEL arrived in tm before the INVITE), forward statelessly (RFC) or drop (for Martin :-)).
Andrei
At 18:45 26/02/2007, Martin Hoffmann wrote:
Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?
When does the "100 Trying" happen in SER. You are, of course, right that this fixes the race (and explains why the rule not to cancel transactions without provisional responses exists in the first place).
It is a kind of trad-off. You could do it immediatelly after receipt of a message. Downside: if SER reboots a nanosecond after that, UAC is led in belief everything is okay and stops retransmitting and elicit the striven-for action. The other extreme way is sending after SER processing is finished, which may take such a while, that UAC unnecesssarily retransmits. Personally, none of these two alternatives seems dramatically worse to me than the other.
Which makes it all the more apparent that t_relay() should never relay a CANCEL. Ever. It should return with an error and I then can decide whether I have a stateless proxy or not to statelessly forward the CANCEL or just error it away.
not sure if dropping it is too nice -- particularly because of SER reboots which may lead tis way to for-ever ringing UASs. I would say rather not. For the forwarding case, I'm kind of twisted on if it is okay to do it statelessly. I would say it is roughly okay. (forking for example should be stateful to avoid UAC confused by an unexpected variaty of asnswers, but I think it is not sooo bad .. UACs have to deal with multiple OKs for INVITEs anyhow, and who cares about answers for CANCELs.....)
-jiri
Bogdan Pintea wrote:
Hi,
Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the problem:
- drop the CANCEL if there is no corresponding INVITE transaction.
Why not politely return an error?
Because an error reply does not trigger a retransmission.
The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)
Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?
In case of openser we need a retransmission, thus the CANCEL is dropped. Probably with Ottendorf, which "remembers" the CANCEL, it should work.
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n"); exit; }
I guess the protocol might have to be checked, as well (at least to reply with an error, rather than drop): for reliable transports you won't see any retransmission and it seems that a client is allowed to open a second connection for the CANCEL[*]; given the fact that INVITEs usually go through multiple checks, the probability of a CANCEL being run against the "transaction table" before the INVITE might not be that low, after all (especially on loaded servers).
You are right - dropping the CANCEL which was received over a reliable transport is a bad idea - regardless if the same connection is used or the request comes in via a new connection. Thus my workaround only works with UDP.
regards klaus
At 15:58 26/02/2007, Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the problem:
- drop the CANCEL if there is no corresponding INVITE transaction. The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n"); exit; }
which does not appear really reboot-safe to me. What it can lead to that ser reboot affects pending calls in that cancels are never forwarded and ringing phones will never stop ringing -- not very pleasant indeed, is it.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Hi all,
I'm facing a problem with "early CANCEL's" such the one described in this thread. The scenario is the following one:
A PSTN call to a SIP phone. When the PSTN decides to cancel the call only a right after initiating, the PSTN will send the CANCEL message to the SER but this is discarded and not forwarded to the correct path to the SIP Phone. So what happens is that we have a ghost call.... The PSTN has already canceled the call but the SIP phone continues to ring.
The code that I have in the SER script is really simple and the behavior to a CANCEL is the same as to a INVITE:
if(subst_uri('/^sip:(+[0-9]+)@ 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){ record_route(); loose_route(); t_relay_to_udp("192.168.20.5", "5060"); break; } In the log file I see that: RFC3261 transaction matching failed t_lookup_request: no transaction found e2e_cancel: e2e cancel proceeding
During this thread I saw that a CANCEL handling tm option was decided to be created. Maybe this option can help me to solve the ghost call issue. How can I change the default behavior ? this feature is available from which SER release ?
Any idea how I can solve this isse?
Thanks in advance.
Best Regards
On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan jiri@iptel.org wrote:
At 15:58 26/02/2007, Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the problem:
- drop the CANCEL if there is no corresponding INVITE transaction. The
UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n"); exit; }
which does not appear really reboot-safe to me. What it can lead to that ser reboot affects pending calls in that cancels are never forwarded and ringing phones will never stop ringing -- not very pleasant indeed, is it.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/ http://iptel.org/%7Ejiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Mar 06, 2008 at 17:45, Nuno Ribeiro nribeiro82@gmail.com wrote:
Hi all,
I'm facing a problem with "early CANCEL's" such the one described in this thread. The scenario is the following one:
A PSTN call to a SIP phone. When the PSTN decides to cancel the call only a right after initiating, the PSTN will send the CANCEL message to the SER but this is discarded and not forwarded to the correct path to the SIP Phone. So what happens is that we have a ghost call.... The PSTN has already canceled the call but the SIP phone continues to ring.
The code that I have in the SER script is really simple and the behavior to a CANCEL is the same as to a INVITE:
if(subst_uri('/^sip:(+[0-9]+)@ 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){ record_route(); loose_route(); t_relay_to_udp("192.168.20.5", "5060"); break; } In the log file I see that: RFC3261 transaction matching failed t_lookup_request: no transaction found e2e_cancel: e2e cancel proceeding
During this thread I saw that a CANCEL handling tm option was decided to be created. Maybe this option can help me to solve the ghost call issue. How can I change the default behavior ? this feature is available from which SER release ?
The option is unmatched_cancel and is present for ser 2.1 (cvs head). However what this does is select between dropping unmatched cancels, forwarding them statelessly or statefully. Older ser versions always forward the cancel statefully, which is what you want in most cases (including yours).
It's strage that the cancel doesn't seem to match the invite transaction in your case. If you would send me some networks dumps with the invite and the cancel I could tell you more.
Andrei
Any idea how I can solve this isse?
Thanks in advance.
Best Regards
On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan jiri@iptel.org wrote:
At 15:58 26/02/2007, Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the problem:
- drop the CANCEL if there is no corresponding INVITE transaction. The
UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n"); exit; }
which does not appear really reboot-safe to me. What it can lead to that ser reboot affects pending calls in that cancels are never forwarded and ringing phones will never stop ringing -- not very pleasant indeed, is it.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/ http://iptel.org/%7Ejiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Nuno Ribeiro
Hi Andrei,
Thanks for your availability to help me... Note that this situation only occurs if the CANCEL message is originated a few moments after the INVITE. I think that the transaction from the INVITE is not yet completely created so when the CANCEL is received it doesn't match any transaction (t_lookup_request: no transaction found). I send in attachment the wireshark log where you can the network traces that you referred.
PS: the first message was rejected by the list as the message was to big....
Best Regards,
On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 06, 2008 at 17:45, Nuno Ribeiro nribeiro82@gmail.com wrote:
Hi all,
I'm facing a problem with "early CANCEL's" such the one described in
this
thread. The scenario is the following one:
A PSTN call to a SIP phone. When the PSTN decides to cancel the call
only a
right after initiating, the PSTN will send the CANCEL message to the SER
but
this is discarded and not forwarded to the correct path to the SIP
Phone. So
what happens is that we have a ghost call.... The PSTN has already
canceled
the call but the SIP phone continues to ring.
The code that I have in the SER script is really simple and the behavior
to
a CANCEL is the same as to a INVITE:
if(subst_uri('/^sip:(+[0-9]+)@ 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B record_route(); loose_route(); t_relay_to_udp("192.168.20.5", "5060"); break; } In the log file I see that: RFC3261 transaction matching failed t_lookup_request: no transaction found e2e_cancel: e2e cancel proceeding
During this thread I saw that a CANCEL handling tm option was decided
to be
created. Maybe this option can help me to solve the ghost call issue.
How
can I change the default behavior ? this feature is available from
which
SER release ?
The option is unmatched_cancel and is present for ser 2.1 (cvs head). However what this does is select between dropping unmatched cancels, forwarding them statelessly or statefully. Older ser versions always forward the cancel statefully, which is what you want in most cases (including yours).
It's strage that the cancel doesn't seem to match the invite transaction in your case. If you would send me some networks dumps with the invite and the cancel I could tell you more.
Andrei
Any idea how I can solve this isse?
Thanks in advance.
Best Regards
On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan jiri@iptel.org wrote:
At 15:58 26/02/2007, Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the
problem:
- drop the CANCEL if there is no corresponding INVITE transaction.
The
UAC must retransmit the CANCEL and meanwhile there should be the
INVITE
transaction. (since 1.0)
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ...
ignore\n");
exit; }
which does not appear really reboot-safe to me. What it can lead to
that
ser reboot affects pending calls in that cancels are never forwarded and ringing phones will never stop ringing -- not very pleasant indeed, is it.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/http://iptel.org/%7Ejiri/<
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Nuno Ribeiro
On Mar 10, 2008 at 12:14, Nuno Ribeiro nribeiro82@gmail.com wrote:
Hi Andrei,
Thanks for your availability to help me... Note that this situation only occurs if the CANCEL message is originated a few moments after the INVITE. I think that the transaction from the INVITE is not yet completely created so when the CANCEL is received it doesn't match any transaction (t_lookup_request: no transaction found). I send in attachment the wireshark log where you can the network traces that you referred.
No, in fact the CANCEL matches and terminates the transaction (you go INVITE, 100 Trying, INVITE forwarded, CANCEL, 487 to the orig. INVITE due to the CANCEL and the 200 to the CANCEL). The problem is when the CANCEL arrives the INVITE transaction has not received any reply yet (if you look in the dump you'll see an 100 trying from .5 long after the CANCEL is received). In ser in this case (CANCEL received and no response yet on a branch) the branch is dropped immediately and a "fake" 487 is sent back (the ideea is that most likely the UA to which the INVITE was forwarded is dead and it saves a lot of resources if we quickly kill the transaction -- unfortunately this backfires in your case). The CANCEL is also not forwarded downstream (the rfc says that CANCEL should be sent only on replied branches).
So to make a long story short, upgrade to the latest cvs version and set modparam("tm", "cancel_b_method", 1). This will keep retransmitting the INVITE if no reply was received, even after the CANCEL arrives and it will avoid all the above problems (see modules/tm/README |grep cancel_b_method for a more detailed description). If you still have problem, drop me another mail. I'm very interested if the cancel fix works properly, not only in my testbed. I'm starting to think that making this the default behaviour might be a good ideea (since it seems that it causes problems quite frequently). It might even become a candidate for a backport to stable.
Andrei
PS: the first message was rejected by the list as the message was to big....
Best Regards,
On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 06, 2008 at 17:45, Nuno Ribeiro nribeiro82@gmail.com wrote:
Hi all,
I'm facing a problem with "early CANCEL's" such the one described in
this
thread. The scenario is the following one:
A PSTN call to a SIP phone. When the PSTN decides to cancel the call
only a
right after initiating, the PSTN will send the CANCEL message to the SER
but
this is discarded and not forwarded to the correct path to the SIP
Phone. So
what happens is that we have a ghost call.... The PSTN has already
canceled
the call but the SIP phone continues to ring.
The code that I have in the SER script is really simple and the behavior
to
a CANCEL is the same as to a INVITE:
if(subst_uri('/^sip:(+[0-9]+)@ 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B record_route(); loose_route(); t_relay_to_udp("192.168.20.5", "5060"); break; } In the log file I see that: RFC3261 transaction matching failed t_lookup_request: no transaction found e2e_cancel: e2e cancel proceeding
During this thread I saw that a CANCEL handling tm option was decided
to be
created. Maybe this option can help me to solve the ghost call issue.
How
can I change the default behavior ? this feature is available from
which
SER release ?
The option is unmatched_cancel and is present for ser 2.1 (cvs head). However what this does is select between dropping unmatched cancels, forwarding them statelessly or statefully. Older ser versions always forward the cancel statefully, which is what you want in most cases (including yours).
It's strage that the cancel doesn't seem to match the invite transaction in your case. If you would send me some networks dumps with the invite and the cancel I could tell you more.
Andrei
Any idea how I can solve this isse?
Thanks in advance.
Best Regards
On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan jiri@iptel.org wrote:
At 15:58 26/02/2007, Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the
problem:
- drop the CANCEL if there is no corresponding INVITE transaction.
The
UAC must retransmit the CANCEL and meanwhile there should be the
INVITE
transaction. (since 1.0)
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ...
ignore\n");
exit; }
which does not appear really reboot-safe to me. What it can lead to
that
ser reboot affects pending calls in that cancels are never forwarded and ringing phones will never stop ringing -- not very pleasant indeed, is it.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/http://iptel.org/%7Ejiri/<
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Nuno Ribeiro
-- Nuno Ribeiro
I will follow your indications and after that I will give you feedback about this solution. Thanks,
On Mon, Mar 10, 2008 at 4:14 PM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 10, 2008 at 12:14, Nuno Ribeiro nribeiro82@gmail.com wrote:
Hi Andrei,
Thanks for your availability to help me... Note that this situation only occurs if the CANCEL message is originated
a
few moments after the INVITE. I think that the transaction from the
INVITE
is not yet completely created so when the CANCEL is received it doesn't match any transaction (t_lookup_request: no transaction found). I send in attachment the wireshark log where you can the network traces
that
you referred.
No, in fact the CANCEL matches and terminates the transaction (you go INVITE, 100 Trying, INVITE forwarded, CANCEL, 487 to the orig. INVITE due to the CANCEL and the 200 to the CANCEL). The problem is when the CANCEL arrives the INVITE transaction has not received any reply yet (if you look in the dump you'll see an 100 trying from .5 long after the CANCEL is received). In ser in this case (CANCEL received and no response yet on a branch) the branch is dropped immediately and a "fake" 487 is sent back (the ideea is that most likely the UA to which the INVITE was forwarded is dead and it saves a lot of resources if we quickly kill the transaction -- unfortunately this backfires in your case). The CANCEL is also not forwarded downstream (the rfc says that CANCEL should be sent only on replied branches).
So to make a long story short, upgrade to the latest cvs version and set modparam("tm", "cancel_b_method", 1). This will keep retransmitting the INVITE if no reply was received, even after the CANCEL arrives and it will avoid all the above problems (see modules/tm/README |grep cancel_b_method for a more detailed description). If you still have problem, drop me another mail. I'm very interested if the cancel fix works properly, not only in my testbed. I'm starting to think that making this the default behaviour might be a good ideea (since it seems that it causes problems quite frequently). It might even become a candidate for a backport to stable.
Andrei
PS: the first message was rejected by the list as the message was to
big....
Best Regards,
On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <
andrei@iptel.org>
wrote:
On Mar 06, 2008 at 17:45, Nuno Ribeiro nribeiro82@gmail.com wrote:
Hi all,
I'm facing a problem with "early CANCEL's" such the one described
in
this
thread. The scenario is the following one:
A PSTN call to a SIP phone. When the PSTN decides to cancel the call
only a
right after initiating, the PSTN will send the CANCEL message to the
SER
but
this is discarded and not forwarded to the correct path to the SIP
Phone. So
what happens is that we have a ghost call.... The PSTN has already
canceled
the call but the SIP phone continues to ring.
The code that I have in the SER script is really simple and the
behavior
to
a CANCEL is the same as to a INVITE:
if(subst_uri('/^sip:(+[0-9]+)@ 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B
http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B
record_route(); loose_route(); t_relay_to_udp("192.168.20.5", "5060"); break;} In the log file I see that: RFC3261 transaction matching failed t_lookup_request: no transaction found e2e_cancel: e2e cancel proceeding
During this thread I saw that a CANCEL handling tm option was
decided
to be
created. Maybe this option can help me to solve the ghost call
issue.
How
can I change the default behavior ? this feature is available from
which
SER release ?
The option is unmatched_cancel and is present for ser 2.1 (cvs head). However what this does is select between dropping unmatched cancels, forwarding them statelessly or statefully. Older ser versions always forward the cancel statefully, which is what you want in most cases (including yours).
It's strage that the cancel doesn't seem to match the invite
transaction
in your case. If you would send me some networks dumps with the invite and the
cancel
I could tell you more.
Andrei
Any idea how I can solve this isse?
Thanks in advance.
Best Regards
On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan jiri@iptel.org wrote:
At 15:58 26/02/2007, Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the
problem:
- drop the CANCEL if there is no corresponding INVITE
transaction.
The
UAC must retransmit the CANCEL and meanwhile there should be the
INVITE
transaction. (since 1.0)
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and
maybe
# the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ...
ignore\n");
exit; }
which does not appear really reboot-safe to me. What it can lead
to
that
ser reboot affects pending calls in that cancels are never forwarded and
ringing
phones will never stop ringing -- not very pleasant indeed, is it.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/http://iptel.org/%7Ejiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Nuno Ribeiro
-- Nuno Ribeiro
Hi Andrei and all,
Sorry by the late answer. I had other tasks in my hands that were more important than this one. I have made the migration of the code that you added in that version to my own testbed and it solved the issue.
I think that this solution would be great if you put on the stable version as it solves an issue that In my opinion is view is very important : ghost calls.
Best Regards,
Nuno Ribeiro
On Mon, Mar 10, 2008 at 5:14 PM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 10, 2008 at 12:14, Nuno Ribeiro nribeiro82@gmail.com wrote:
Hi Andrei,
Thanks for your availability to help me... Note that this situation only occurs if the CANCEL message is originated
a
few moments after the INVITE. I think that the transaction from the
INVITE
is not yet completely created so when the CANCEL is received it doesn't match any transaction (t_lookup_request: no transaction found). I send in attachment the wireshark log where you can the network traces
that
you referred.
No, in fact the CANCEL matches and terminates the transaction (you go INVITE, 100 Trying, INVITE forwarded, CANCEL, 487 to the orig. INVITE due to the CANCEL and the 200 to the CANCEL). The problem is when the CANCEL arrives the INVITE transaction has not received any reply yet (if you look in the dump you'll see an 100 trying from .5 long after the CANCEL is received). In ser in this case (CANCEL received and no response yet on a branch) the branch is dropped immediately and a "fake" 487 is sent back (the ideea is that most likely the UA to which the INVITE was forwarded is dead and it saves a lot of resources if we quickly kill the transaction -- unfortunately this backfires in your case). The CANCEL is also not forwarded downstream (the rfc says that CANCEL should be sent only on replied branches).
So to make a long story short, upgrade to the latest cvs version and set modparam("tm", "cancel_b_method", 1). This will keep retransmitting the INVITE if no reply was received, even after the CANCEL arrives and it will avoid all the above problems (see modules/tm/README |grep cancel_b_method for a more detailed description). If you still have problem, drop me another mail. I'm very interested if the cancel fix works properly, not only in my testbed. I'm starting to think that making this the default behaviour might be a good ideea (since it seems that it causes problems quite frequently). It might even become a candidate for a backport to stable.
Andrei
PS: the first message was rejected by the list as the message was to
big....
Best Regards,
On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <
andrei@iptel.org>
wrote:
On Mar 06, 2008 at 17:45, Nuno Ribeiro nribeiro82@gmail.com wrote:
Hi all,
I'm facing a problem with "early CANCEL's" such the one described
in
this
thread. The scenario is the following one:
A PSTN call to a SIP phone. When the PSTN decides to cancel the call
only a
right after initiating, the PSTN will send the CANCEL message to the
SER
but
this is discarded and not forwarded to the correct path to the SIP
Phone. So
what happens is that we have a ghost call.... The PSTN has already
canceled
the call but the SIP phone continues to ring.
The code that I have in the SER script is really simple and the
behavior
to
a CANCEL is the same as to a INVITE:
if(subst_uri('/^sip:(+[0-9]+)@ 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){http://1@xlab.com/i%27%29%29%7B
http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B
record_route(); loose_route(); t_relay_to_udp("192.168.20.5", "5060"); break;} In the log file I see that: RFC3261 transaction matching failed t_lookup_request: no transaction found e2e_cancel: e2e cancel proceeding
During this thread I saw that a CANCEL handling tm option was
decided
to be
created. Maybe this option can help me to solve the ghost call
issue.
How
can I change the default behavior ? this feature is available from
which
SER release ?
The option is unmatched_cancel and is present for ser 2.1 (cvs head). However what this does is select between dropping unmatched cancels, forwarding them statelessly or statefully. Older ser versions always forward the cancel statefully, which is what you want in most cases (including yours).
It's strage that the cancel doesn't seem to match the invite
transaction
in your case. If you would send me some networks dumps with the invite and the
cancel
I could tell you more.
Andrei
Any idea how I can solve this isse?
Thanks in advance.
Best Regards
On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan jiri@iptel.org wrote:
At 15:58 26/02/2007, Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the
problem:
- drop the CANCEL if there is no corresponding INVITE
transaction.
The
UAC must retransmit the CANCEL and meanwhile there should be the
INVITE
transaction. (since 1.0)
if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and
maybe
# the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ...
ignore\n");
exit; }
which does not appear really reboot-safe to me. What it can lead
to
that
ser reboot affects pending calls in that cancels are never forwarded and
ringing
phones will never stop ringing -- not very pleasant indeed, is it.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/http://iptel.org/%7Ejiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Nuno Ribeiro
-- Nuno Ribeiro
On Feb 26, 2007 at 12:09, Martin Hoffmann hn@nvnc.de wrote:
Greger V. Teigre wrote:
I forward this from the serusers list:
A CANCEL is being sent from a UAC before having established a route set, thus the CANCEL has no Route header and is not caught by loose routing. The below thread shows that this case is difficult to understand. Jiri and Bogdan had a discussion on serusers regarding the race condition where the provisional reply from UAS and the CANCEL cross each other.
I seem to have missed this discussion, but shouldn't the race be between the final reply and the CANCEL?
In SER, there is a race between the INVITE and the CANCEL: If the INVITE processing hasn't been finished and the transaction for it has not yet been established through t_relay() before the CANCEL arrives, things go wonky.
It's mostly fixed in Ottendorf. There is still some race potential if the CANCEL arrives after t_relay() started but before the message being forwarded (e.g. during branch adding inside t_relay()).
Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?
If you already have a transaction for the INVITE, you should be fine by simply passing the CANCEL to tm by calling t_relay(). Don't remember what tm does with a CANCEL it doesn't have a transaction for. IMHO it should do nothing and give an error back.
It forwards it statefully.
Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.
The state is there the moment a transaction is established. The problem here is that SER doesn't CANCEL branches that have not yet received a 100 Trying since The Standard doesn't allow you to.
Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective)
As usual: Ignore. It's a borderline case, anyways. Most likely, it will fix itself anyways because the person that receives the false call will hang up and thus their UA will generate a BYE.
Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?
This depends on what tm is doing with a CANCEL it can't find a transaction for. If I understand the code right, it currently treats such a CANCEL as if it were nothing special. This would actually be in violation of 3261 which states that you MUST forward the CANCEL statelessly. However, the reasoning is that this is because the proxy may have forwarded the INVITE statelessly earlier. Since I never do that, I would happily violate that MUST.
Regards, Martin
Andrei
Martin Hoffmann wrote:
Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?
This depends on what tm is doing with a CANCEL it can't find a transaction for. If I understand the code right, it currently treats such a CANCEL as if it were nothing special. This would actually be in violation of 3261 which states that you MUST forward the CANCEL statelessly. However, the reasoning is that this is because the proxy may have forwarded the INVITE statelessly earlier. Since I never do that, I would happily violate that MUST.
SER/tm forwards the CANCEL statefuly if the corresponding INVITE transaction does not exist in tm. The reason for this measure (as far as I can remember) was improved robustness in the rare cases when no matching INVITE transaction could be found (such as after SER restarts or transaction timeouts). The idea here was that in such cases SER should try to execute exactly the same routing logic for the CANCEL as it did for the INVITE, to increase the chance that the CANCEL would reach the correct final destination.
SER can be configured (and is by default) to drop long-lasting INVITE transaction _silently_, i.e. without terminating it explicitly (see the noisy_ctimer parameter of tm module). If this happened and SER did not forward the CANCEL (although the corresponding INVITE transaction did not exist anymore) then you could end up having a phone ringing indefinitely (or until the first hammer hit by your roommate, it is unbelievable but there are people that can't stand phones ringing for hours).
This is also the reason, by the way, why most SER configuration files do not contain just if (method=="INVITE") but: if (method=="INVITE" || method=="CANCEL"). This is to ensure that CANCELs will go down the same path in the configuration files as INVITEs and that they hit the same destination as the INVITE did.
This, of course, does not work when parallel or sequential forking takes place, or when you have a very complex configuration file in place.
This is my recap what is SER doing with CANCELs that have no matching INVITE transaction in tm and why. I am not sure whether this logic is still relevant today, given the complexity of most configuration files and frequent use of forking.
Jan.
At 13:09 26/02/2007, Martin Hoffmann wrote:
If you already have a transaction for the INVITE, you should be fine by simply passing the CANCEL to tm by calling t_relay(). Don't remember what tm does with a CANCEL it doesn't have a transaction for. IMHO it should do nothing and give an error back.
IMO, it used to create a kind of special (or crippled) transaction to allow CANCEL forwarding after a SER reboot. Not really 100% sure what it does now. (For potential TM redesigners: this is why it pays off to produce branch parameters in a way which can be derived from the original request --> then even rebooted SER generates branches consistently)
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Greger V. Teigre wrote:
I forward this from the serusers list:
A CANCEL is being sent from a UAC before having established a route set, thus the CANCEL has no Route header and is not caught by loose routing. The below thread shows that this case is difficult to understand. Jiri and Bogdan had a discussion on serusers regarding the race condition where the provisional reply from UAS and the CANCEL cross each other.
Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?
No.
Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.
TM will be able to match the CANCEL agains the state created by INVITE even if no provisional reply has been received from downstream. It's just that it will not forward it down the branch.
Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective)
Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?
Yes, it would be possible, you could have a catch-all-CANCELs code at the very beginning of your configuration file, but it won't cover the cases when no INVITE transaction exist. In such a case t_relay will relay the CANCEL which would enter a forwarding loop because the Request-URI does not change.
Jan.
I'm not sure, but it may be that at some point a to/from/call-id matching with INVITE was implemented, thus removing the necessity of using lookup on CANCEL. g-)
samuel wrote:
i'm pretty sure CANCEL hits t_relay and should be matched agains INVITE transaction...the only main routing difference between CANCEL and INVITE is NAT stuff and lookupXXXX which I think it does not affect this thread's topic, or did i miss something??
Try to dial a number and immediately hang up...don't you see the Too Many Hops?
Samuel.
2007/2/16, samuel samu60@gmail.com:
mmm
i'll take a look at the config...
maybe i just had a wrong config after all...if that's the case, apologies for the false "race condition" :P samuel.
2007/2/16, Greger V. Teigre greger@teigre.com:
It may be that you are not handling the CANCEL correctly. An early
CANCEL
(no Route headers) will have to be routed as an INVITE. g-)
Abdul Qadir wrote: Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL
hit SER
an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to
another nokia sip phone. The call works fine. The problem comes
only when I
call from Phone A to Phone B and then immediately cancel the
call(from Phone
A). The Phone A will hangup the call as it sent CANCEL but the SER
will
ignore this CANCEL and still send INVITE to Phone B resulting in a
ghost
call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL"
message is received on SER even before any provisional response
from Phone
B. Therefor SER doesnot relay this CANCEL request to Phone B. I
even checked
RFC which clearly says that UAC should not send CANCEL untill it
receives
any provisional response. I talked to Nokia expert and they said
the 100
Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run
statefull
SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.
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
I think that's yet another issue (which then reinstatiates itself in some other issue) -- you must have a loop in your script which you have to fix first. Just ngrep loopback interface to verify this is the cause of the problem.
-jiri
At 13:34 16/02/2007, Abdul Qadir wrote:
Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion klaus.mailinglists@pernau.at wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367Food fight? Enjoy some healthy debate in the http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367Yahoo! Answers Food & Drink Q&A. _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Hi, Yes it was a loop back going on thats why i got too many hops. Based on the suggestion I put some thing like this for CANCEL method before relaying my original configuration is exactly like this. http://www.voip-info.org/wiki/view/SER+example+NAThelper
if(method=="CANCEL") { if(!lookup("location")) { log(1, "Location not found\n"); } fix_nated_contact(); force_rport(); };
but it created two problems. 1. The cancel is now sent to B party. ( which sends error that the call transaction does not exist, ofcourse which is rite since we haven't sent any INVITE to B party) 2. SER goes in loop of ACK 3. later b side will get invite as well, and the ghost call still exists.
This is how it looks like Caller SER Callee INVITE --------------------------------->
CANCEL --------------------------------->
CANCEL ---------------------------------> 481 (tran does not exist) <---------------------------------
Loopback OF ACK 100 Trying <---------------------------------
INVITE ---------------------------------> rest of call follows.............
Best Regards, Abdul Qaidr
Jiri Kuthan jiri@iptel.org wrote: I think that's yet another issue (which then reinstatiates itself in some other issue) -- you must have a loop in your script which you have to fix first. Just ngrep loopback interface to verify this is the cause of the problem.
-jiri
At 13:34 16/02/2007, Abdul Qadir wrote:
Hi,
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B.
Best Regards, Abdul Qadir
Klaus Darilion wrote: Abdul Qadir wrote:
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
Hi!
I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.
regards klasu
I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards, Abdul Qadir
Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Klaus Darilion nic.at
Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
--------------------------------- The fish are biting. Get more visitors on your site using Yahoo! Search Marketing.
-
Abdul Qadir -
Andrei Pelinescu-Onciul -
Bogdan Pintea -
Greger V. Teigre -
Jan Janak -
Jiri Kuthan -
Klaus Darilion -
Martin Hoffmann -
Nuno Ribeiro -
samuel