2009/9/9 Dan Pascu <d...@ag-projects.com>: >> So, if we simply discard the second 200OK, what will happen with UAC2? >> it will think it is in a call... waiting for ACK...... > > I agree. The proxy should not discard anything. From UAC2's > perspective the call is there, it only misses an ACK. It will keep > retransmitting the 200 OK, until it decides to give up, unless is an > UAC that was configured to ignore the missing ACK in which case it > will consider that it has the call anyway and will act accordingly.
Yes, right. I must re-read the draft to know how it handles this case. And I've read it right now and I was wrong, what this draft states is: http://tools.ietf.org/html/draft-sparks-sip-invfix-03 ---------------------------------------------- 4. Summary of Change This correction document updates [RFC3261], adding a state and changing the transitions in the INVITE client state machine such that the INVITE client transaction remains in place to receive multiple 200 OK responses. It adds a state to the INVITE server state machine to absorb retransmissions of the INVITE after a 200 OK response has been sent. It modifies state transitions in the INVITE server state machine to absorb retransmissions of the INVITE request after encountering a unrecoverable transport error when sending a response. It also forbids forwarding stray responses to INVITE requests (not just 200 OK responses), which RFC3261 requires. ---------------------------------------------- So, each 200 is forwarded upstream to the UAC, but the INVITE transaction remains in the proxy (so a retransmittion of the INVITE from the UAC is not treated as a new request). -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel