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