[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] INVITE client Transaction....

hi
coments inline ....
first a request : can u provide me the link to the previuos discussion on the same subject, as u had mentioned. I browsed the archive but cudnt filter out the mails.

Natesan Kannan wrote:
Hi,

    RFC 3261 says, in section 9:
"Note that both the transaction corresponding to the original request
   and the CANCEL transaction will complete independently.  However, a
   UAC canceling a request cannot rely on receiving a 487 (Request
   Terminated) response for the original request, as an RFC 2543-
   compliant UAS will not generate such a response.  If there is no
   final response for the original request in 64*T1 seconds (T1 is
   defined in Section 17.1.1.1), the client SHOULD then consider the
   original transaction cancelled and SHOULD destroy the client
   transaction handling the original request."
Doesnt it implies that transaction layer must cancel the transaction after this timeout (which can be timer B). If the implication is that UA must start this timer (called by some other name) then Timer B and this timer are duplicated (unnecessary overhead ).

Secondly, the scenario of CANCEL not getting a 200 response because of
the server crash cannot happen, as CANCEL is hop-by-hop and a 200 OK is sent
from the next proxy in line.
I am not sure on this. Wont the proxy reply with trying and wait for an OK from the remote host and then send an OK. Please clarify on this issue.

    In general, the timer mentioned above could be started irrespective of
*any* response to the CANCEL, including a time-out.
I agree to this. But this timer must be started at transaction layer when initial INVITE request is send (that is the reason i m calling it timer B) and a mention in the state diagram over the path from *proceeding* state to *terminated* state on the expiry of this timer.

- mukul

-Kannan


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip