[Serusers] SER Nokia CANCEL Problem

[Greger V. Teigre]

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
>> >
>> >
>>
>
>