Hi, Yes it was a loop back going on thats why i got too many hops. Based on the suggestion I put some thing like this for CANCEL method before relaying my original configuration is exactly like this. http://www.voip-info.org/wiki/view/SER+example+NAThelper
if(method=="CANCEL") { if(!lookup("location")) { log(1, "Location not found\n"); } fix_nated_contact(); force_rport(); };
but it created two problems. 1. The cancel is now sent to B party. ( which sends error that the call transaction does not exist, ofcourse which is rite since we haven't sent any INVITE to B party) 2. SER goes in loop of ACK 3. later b side will get invite as well, and the ghost call still exists.
This is how it looks like Caller SER Callee INVITE --------------------------------->
CANCEL --------------------------------->
CANCEL ---------------------------------> 481 (tran does not exist) <---------------------------------
Loopback OF ACK 100 Trying <---------------------------------
INVITE ---------------------------------> rest of call follows.............
Best Regards, Abdul Qaidr
Jiri Kuthan jiri@iptel.org wrote: I think that's yet another issue (which then reinstatiates itself in some other issue) -- you must have a loop in your script which you have to fix first. Just ngrep loopback interface to verify this is the cause of the problem.
-jiri
At 13:34 16/02/2007, 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 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
-- Jiri Kuthan http://iptel.org/~jiri/
--------------------------------- The fish are biting. Get more visitors on your site using Yahoo! Search Marketing.