Re: [OpenSER-Users] No answers whatssoever??

El Wednesday 27 February 2008 11:22:30 Bogdan-Andrei Iancu escribió: Sure, anyway the exact changes to the RFC 3261 appear in the Section 8 of the above draft: RFC 3261: Section 13.3.1.4 paragraph 4 ------------------------------------------ Once the response has been constructed, it is passed to the INVITE server transaction. Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. ------------------------------------------ draft-sparks-sip-invfix makes fix it: ------------------------------------------ Once the response has been constructed, it is passed to the INVITE server transaction. In order to ensure reliable end-to-end transport of the response, it is necessary to periodically pass the response directly to the transport until the ACK arrives. ------------------------------------------ also it fixes the way a response not matching a transaction should be forwarder upstream or dropped: RFC 3261: Section 16.7 paragraphs 1 and 2 ------------------------------------------ When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST process the response (even if it is an informational response) as a stateless proxy (described below). If a match is found, the response is handed to the client transaction. Forwarding responses for which a client transaction (or more generally any knowledge of having sent an associated request) is not found improves robustness. In particular, it ensures that "late" 2xx responses to INVITE requests are forwarded properly. ------------------------------------------ draft-sparks-sip-invfix makes fix it: ------------------------------------------ When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST NOT forward the response. If a transaction is found, the response is handed to the client transaction. ------------------------------------------ RFC 3261: Section 17.1.1.2. ------------------------------------------ When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state, [...] The client transaction MUST be destroyed the instant it enters the "Terminated" state. This is actually necessary to guarantee correct operation. ------------------------------------------ draft-sparks-sip-invfix makes fix it: ------------------------------------------ When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state [...] The client transaction SHOULD start timer D when it enters the "Completed" state for any reason, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used. ------------------------------------------ There are more changes pointed in the section 8 of the draft. Best regards. -- Iñaki Baz Castillo ibc(a)in.ilimit.es