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