[KKT]So you say that the Timer C by proxy or user defined timer in case of end point should be started by TU and not by client transaction. Please correct me if i am wrong.

[Mukul] Timer C for proxy, app/human driven by TE(Terminal Equipment). (Explained below in detail)
Hi,



I have one basic doubt in timers in UAC transaction. When a UAC

transaction sends an INVITE request and gets a provisional response it

enters a "Proceeding" state. Here rfc3261 says that for a proxy it

should restart TIMER C. But however for an endpoint, it does not say

anything about whether a timer has to be restarted or not and also does

not say about the value of the timer. So i am assuming that the endpoint

can start a timer of its choice. Now when this timer times out or when

TIMER C times out (and proxy does not want to restart this timer),

should we change the transaction state to "TERMINATED" or should we

still remain in "PROCEEDING" state?



[ABN] when provisional response received the retrans timer will be

stopped (Ta). When INVITE sent out the Tb (= 64*T1) also would have been

started which will take care of transaction termination. When Tb fires

the transaction moves to TERMINATED state...

Tb is not for this purpose. It controls the transaction timeouts i.e.

when there is no response at all from the other side.



When in proceeding state, the termination of transaction if no further

response is received, is signalled by TU. TU can start a timer, or it

can wait for the user( probably human) response. This is beacause a

timer should handle machine controlled responses, and not the responses

(like 200,486 etc) which are dependent on human interaction.



[ABN] Its no where mentioned that TU can start a timer to protect the transaction? It?s the responsibility of the Transaction module to run both *Ta* and *Tb* when INVITE is sent out. After each Ta times out INVITE is retransmitted and once the Tb expires then indicate TU about the transaction timeout with 408-"Request Timeout"


[Mukul] Ok TU shold not start a timer. But still IMO Tb is not for this purpose. Cancelling of this transaction should be invoked by the user (As in the case of telephone, a user decide when to press the cancel button when there is no reply). The application logic "MAY" contain such a timer. This will tell the TU to cancel the early dialog, and transaction.
(As an example, Auto Redial App: It may wait for k unit of time after receiving 1xx response (ie after moving to proceeding state), and then automatically cancels the current transaction, and then send a fresh request.)


Proxies are provided with special Timer C, because they do not have any human interface.Hence to free the resources at a proxy, a timer is provided, with large timeout value (> 3min), and that too may be reset depending upon the controlling policy at this proxy.



regards
Mukul

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to