Hi Kingston,
Timer C. See section 16.8 of rfc3261. BR, Stephen _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 8:50 PM To: Stephen Zhou Cc: 'Manjunath Warad'; [EMAIL PROTECTED]; [email protected]; [email protected] Subject: RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE servertransaction Hi, I agree with Stephen because it is not a problem in non - IST; This is generic to non-IST as well as IST. But consider a scenario like this UAC of UAS of UAS of UE2 UE1 proxy | | | | | non-INV | | non-INV | |--------------------->| |---------------------------->| | | | 2xx | | | | *<---------------| | | | | UAC of Proxy Here UAS of UE2 is re-transmitting the 2xx message toward proxy. But the message that has been sent by UAS of UE2 hasn't reached UAC of proxy (due to network breakage or some other means). So the proxy core (TU) doesn't send the response to UAS of proxy. In this case how will UAS txn of proxy can be released. Regards, S.Kingston Smiler. Stephen Zhou <[EMAIL PROTECTED]> 07/25/2006 03:21 PM To "'Manjunath Warad'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Kingston Smiler/BLR/[EMAIL PROTECTED] cc [email protected], [email protected] Subject RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE servertransaction Hi, Manjunath is right. We MUST assume the communication between TU layer and transation lay in a sip stack is reliable. If there have problems, I thinks this is program problem rather than protocol(transaction layer) problem. Additionally, the same issue exist in IST, if the IST cann't receive the responses from TU. BR, Stephen -----Original Message----- From: Manjunath Warad [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 5:08 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [email protected]; [email protected] Subject: [Sip] RE: [Sip-implementors] Regarding non-INVITE server transaction Hi, Below mentioned behaviour is for client transaction, not for server transaction. Rgds, Manju -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Valentin Nechayev Sent: Tuesday, July 25, 2006 4:55 PM To: [EMAIL PROTECTED] Cc: [email protected]; [email protected] Subject: Re: [Sip-implementors] Regarding non-INVITE server transaction Mon, Jul 24, 2006 at 20:08:13, Kingston.Smiler wrote about "[Sip-implementors] Regarding non-INVITE server transaction": > If the non-IST doesn't receive any RESPONSE message then what will > happen? > RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention > properly > what will happen if the non-IST doesn't receive any provisional > response/final response. ==={{{ 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. ===}}} -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip *********************** FSS-Unclassified *********************** _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
