16 Feb
2007
16 Feb
'07
11:14 a.m.
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(a)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,
--
Jiri Kuthan http://iptel.org/~jiri/
---------------------------------
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
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(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