Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

[Greger V. Teigre]

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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.iptel.org
>> > >> > http://lists.iptel.org/mailman/listinfo/serusers
>> > >> >
>> > >> >
>> > >> > _______________________________________________
>> > >> > Serusers mailing list
>> > >> > Serusers at lists.iptel.org
>> > >> > http://lists.iptel.org/mailman/listinfo/serusers
>> > >> >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>