All server transactions linger for the 3 minutes Hmm can you point me such place in rfc ? If i look rfc 3261 17.2.x Server transactions will destroy too if final response, only in some cases linger for 4 seconds.
There is an error in 3261 in that it does not clearly separate the processing of *transactions* from *dialogs*. In the case of transactions, every server transaction, after it sends a response, must remain "in the system" until any possible retransmission of the request can be received. This is so that the resent request will receive the same response. Although this logic isn't specified in 3261, the requirement that resent requests receive the same response is in there somewhere, and this logic is the only way to implement that. Also what the use of Cancel then if transaction linger so long time. And also normally retransmit of request ot server transaction won't happen, because server transaction must send 100 trying (i mean at least time you in real life cancel transaction). However, the 100 can be lost by the network and/or the network can deliver duplicates of the request packet. The only *guaranteed* time limit for resent requests in the timer in the client transaction that requires it to stop resending a certain time after the first request was sent (plus maximum network latency). The only idea is to cancel Invite when ringing. And i suspect Cancel will terminate transaction or there is no meaning/use of cancel. What the CANCEL does is that it terminates the early *dialog* that was established when the INVITE first arrived. But dialog processing is "at a higher level" in the SIP stack than transactions. And indeed, the INVITE server transaction does live longer than the dialog that it started. But that's the only way to implement it that does not fail under various circumstances. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
