16 Feb
2007
16 Feb
'07
7:21 p.m.
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
>
>