26 Feb
2007
26 Feb
'07
5:23 a.m.
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(a)gmail.com>om>:
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(a)teigre.com>om>:
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(a)gmail.com>om>:
>> 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(a)teigre.com>om>:
>> >
>> > 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(a)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(a)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(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> > _______________________________________________
> > Serusers mailing list
> > Serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
>