Hi Michale,
sorry to be late answering this mail.
see my comments in line.
Sal
Michael Froman wrote:
Resending in case this got lost in the noise over the last week.
Begin forwarded message:
From: Michael Froman <mfroman@xxxxxxxxxxxx>
Date: March 4, 2009 10:00:10 AM CST
To: sipping@xxxxxxxx
Subject: Comments on draft-niemi-sipping-event-throttle-08.txt
Hello all,
I have a question/concern about the closing paragraphs of 4.2.2,
5.2.2 and 6.3.2. Each of these paragraphs deals with retransmissions
of NOTIFY requests and resetting the throttle (or force or average)
based on the completion of the previous transaction. Given that the
notifier and the subscriber can have different ideas of when the
transaction ends (up to T1 I believe), I want to verify the reasoning
behind these paragraphs.
[Sal] here the last paragraph
Retransmissions of NOTIFY requests are not affected by the throttle,
i.e., the throttle only applies to the generation of new
transactions. In other words, the throttle is reset only after the
previous transaction has completed.
Is the point that throttle/force/average not break the retransmission
mechanism
[Sal] that is exactly the point. Throttle/force/average do not break or
modify in any way the retransmission mechanism.
or that, for example, retransmissions modify the time between forced
NOTIFYs by the time taken for the retransmissions to successfully
complete the transaction? An example is the case when the NOTIFY gets
to the subscriber quickly, but the 200OK is slow to make it back to
the notifier. Start with a force value of 2 seconds. The subscriber
thinks the transaction is over and is now expecting a forced NOTIFY 2
seconds from now. The notifier has not completed the transaction. The
next NOTIFY from the notifier can happen anytime up to T1 + 2 sec.
I agree that throttle/force/average should not interfere with the
normal retransmission mechanism. However, I don't agree that waiting
for the transaction to complete before starting the
throttle/force/average timer is going to give much benefit (or always
predictable results).
[Sal] While I agree that this behaviour (waiting for the transaction to
complete) can not always give "predictable" results and that is bad
especially if you want use it to track the location of a UA,
However making "throttle/force/average" timers independent (so to say)
from the the retransmission mechanism can lead to situation where the
timer fires and then you should send out a new NOTIFY when there is
still a retrasmission of a previous one. Any thought on how to solve
this situation without break the retransmission mechanism?
Thanks,
Michael.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
