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