Hi Inaki, Iñaki Baz Castillo wrote: > El Wednesday 27 February 2008 11:04:00 Bogdan-Andrei Iancu escribió: > >> Hi Taisto, >> >> As mentioned in a previous email, the RFC3261 says that the 200OK ACK >> forms a separate transaction: >> >> 17 Transactions (page 122) >> .... >> >> The reason for this separation is rooted in the importance of >> delivering all 200 (OK) responses to an INVITE to the UAC. To >> deliver them all to the UAC, the UAS alone takes responsibility >> for retransmitting them (see Section 13.3.1.4), and the UAC alone >> takes responsibility for acknowledging them with ACK (see Section >> 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is >> effectively considered its own transaction. >> ..... >> >> >> And OpenSER is doing this - 200OK ACK is not part of the INVITE >> transaction. >> >> Now, about destroying the INVITE transaction after 200OK, I not sure if >> the RFC really states this. The RFC says the transaction is completed >> with the 200 OK, but not destroyed - this is more or less an >> implementation option, in my opinion. >> > > Hi Bogdan, about that there is lot of info in this draft: > > http://tools.ietf.org/html/draft-sparks-sip-invfix > > It fixes the RFC3261 by removing the need of destroying the INVITE > transmission when a 200 Ok is received. Instead it suggests to keep the > transacction in memory for a while ("completed" status) to match request > retransmissions and other replies in case of parallel forking. > > But the original RFC 3261 seems to indicate to destroy the INVITE transaction > in the UAC/Proxy when a 200 Ok is received. > Thanks for the update - can you point me this section/page from the RFC3261 ?
Regards, Bogdan _______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
