16 Feb
2007
16 Feb
'07
3:34 p.m.
At 10:07 16/02/2007, samuel wrote:
--
Jiri Kuthan http://iptel.org/~jiri/
The 100 Trying is hardcoded and you'll have to look
for it in the
code, remove it, and recompile.
After that, you should send back from your config file the 100 Trying
response in the convenient places to stop retransmissions.
Samuel.
2007/2/15, Abdul Qadir <ablqadir(a)yahoo.com>om>:
>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.
>
>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.
It appears that there are two things mixed together. The 100 is sent upstream
whereas the problem appears downstream. Not sending 100 downstream doesn't
solve the race conditions located downstream.
The problem is that SER doesn't delay sending the CANCEL, it just gives up
on it. The issues is being bug-tracked now, there is no ETA yet.
Thank you for reporting!
-jiri
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
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 
19 Feb
19 Feb
5:56 p.m.
New subject: [Serusers] SER Nokia CANCEL Problem
Jiri Kuthan wrote:
It appears that there are two things mixed together.
The 100 is sent upstream
whereas the problem appears downstream. Not sending 100 downstream doesn't
solve the race conditions located downstream.
The problem is that SER doesn't delay sending the CANCEL, it just gives up
on it.
As a side observation regarding to protocol's fault tolerance / race
prone, it would seem there's no way for a stateful proxy to let a callee
(1) whose provisional reply got lost (or not sent, in the first place,
as provisionals is a MUST only for stateful proxies), but (2) whose
final answer was received, about the fact that the call was canceled in
the meantime, even though the proxy has the clear picture - and the only
one that can have it - at the moment it sees the final reply from
callee; (callee which will, however, time out, eventually, waiting for
the ACK).
Bogdan.
The issues is being bug-tracked now, there is no ETA
yet.
Thank you for reporting!
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Bogdan Pintea
iptego GmbH - VoIP Security
http://www.iptego.de
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
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:50 p.m.
New subject: [Serusers] SER Nokia CANCEL Problem
At 16:56 19/02/2007, Bogdan Pintea wrote:
As a side observation regarding to protocol's fault
tolerance / race prone, it would seem there's no way for a stateful proxy to let a
callee (1) whose provisional reply got lost (or not sent, in the first place, as
provisionals is a MUST only for stateful proxies), but (2) whose final answer was
received, about the fact that the call was canceled in the meantime, even though the proxy
has the clear picture - and the only one that can have it - at the moment it sees the
final reply from callee;
Hi Bogdan,
just thinking loudly how to best narrow down the problem. I think there are two:
one (2) is race-condition. This occurs even if no provisional answer is lost --
it is just that CANCEL meets 200 on the net and client has then to sort it out.
The other problem (1) is a kind of amplifier in that it enlarges the race condition
window through lacking reliability of provisional answers.
So I think that the solution is the same ... put the burden on UAC. It is then
UAC's responsibility to terminate a too-late-cancelled call (even if "too
late"
is actually caused by reliability issues).
RFC3261
"If the INVITE results in 2xx final response(s)
to the INVITE, this means that a UAS accepted the invitation while
the CANCEL was in progress. The UAC MAY continue with the sessions
established by any 2xx responses, or MAY terminate them with BYE."
So I guess that the harm is sustainable even though it indeed doesnt look
too nice.
(callee which will, however, time out, eventually,
waiting for the ACK).
How come? UAS keeps retransmitting 200s till ACK comes. The ACK should come
rather early. It is then UAC's choice to BYE the too-late-cancelled
call or not.
-jiri
20 Feb
20 Feb
1:04 p.m.
New subject: [Serusers] SER Nokia CANCEL Problem
Hi Jiri,
Jiri Kuthan wrote:
The other problem (1) is a kind of amplifier in that
it enlarges the race condition
window through lacking reliability of provisional answers.
So I think that the solution is the same ... put the burden on UAC. It is then
UAC's responsibility to terminate a too-late-cancelled call (even if "too
late"
is actually caused by reliability issues).
RFC3261
"If the INVITE results in 2xx final response(s)
to the INVITE, this means that a UAS accepted the invitation while
the CANCEL was in progress. The UAC MAY continue with the sessions
established by any 2xx responses, or MAY terminate them with BYE."
Yeah, you're right, my "there is no way" was too categorical. The callee
is left at the mercy of the two "MAY"s above, and the existence of
"ghost calls" would indicate that none of the two is chosen, while not
really breaking the specs... (it's not like "must either send 2xx or
bye"). It only takes a responsible caller client to make sure that the
"tried-to- cancel-but-actually-failed,
even-though-in-a-successful-manner" dialog gets eventually brought down,
not let to timeout on callee's side.
I think I even saw this scenario as an attack for capacity starvation on
PSTN GWs somewhere.
But the 'generic finding' was that the proxy knows what's going on and
could, theoretically, put a quick end, in a predictable way, to callee's
lurch, but it can't (as it's just a proxy; maybe yet another, not so
solid, argument for B2Bs in network's core...).
Bogdan.
So I guess that the harm is sustainable even though it
indeed doesnt look
too nice.
--
Bogdan Pintea
iptego GmbH - VoIP Security
http://www.iptego.de
(callee which will, however, time out,
eventually, waiting for the ACK).
How come? UAS keeps retransmitting 200s till ACK comes. The ACK should come
rather early. It is then UAC's choice to BYE the too-late-cancelled
call or not.
-jiri
6489
days inactive
6493
days old
3 comments
2 participants
participants (2)
-
Bogdan Pintea -
Jiri Kuthan