Hi, There is late offer-answer model (offer in 200, answer in ACK) according to RFC3261 par.13 and RFC3264. In it, if the transaction requester don't accept the offer, the only correct action is to confirm transaction (sending ACK) but then immediately stop the call with BYE. Am I right in this? If yes, I have the question _why_ this approach was selected among another possible ones: 1. Send ACK without SDP leaving UAs in state "established dialog, but no session" with need to negotiate session; 2. Send negative opposition of ACK (name it here "NAK"); this also would be useful in some other cases not related to session itself (want to cancel request when final response is unacceptable); 3. Send ACK but with special rejecting description (this is kind of merge of 1 and 2); 4. Disable responding with ACK totally, causing here UAS timeout trigger and stopping the call on opposite side; 5. Require 100rel to work with late OAM, send offer SDPs only in 1xx and respond with answer in PRACK; 6. something else? The problem I need to solve is to embed late OAM implementation properly into existing stack with own complex processing which doesn't restore after misconfirmed offers... -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:netch@xxxxxxxxxxxx _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
