Subject: [Sip] offer/answer exchange

From: Salvador Rey Calatayud <[email-masked]>
Date: Wed, 31 Jul 2002 09:45:15 +0200 (CEST)

Hi everyone,

I resubmit this question since it has got no answer yet,

as for the transaction state diagrams, and section 14.1 of RFC 3261, a UAS
that had received an INVITE(not blank) cannot send another one, and thus start
a new offer/answer cycle, until it sends a 200ok, or receives the ACK for a
300-699 response. why is the rule different for 200ok than for other responses?

section 14.1 RFC 3261
"2. If there is an ongoing INVITE server transaction, the TU MUST wait
until the transaction reaches the confirmed or terminated state before initiating
the new INVITE."

I think UPDATE and this are not alligned since the UPDATE specification
says that another offer cannot be sent until a previous 1xxrel containing a
descriptor is acknowledged with a PRACK (playing the role of ACK to 200ok
in basic SIP).

I include section 5.1 of UPDATE-02
"and for the callee:
o If the UPDATE is being sent before the completion of the
INVITE transaction, and the initial INVITE contained an offer,
the UPDATE cannot be sent unless the callee has generated an
answer in a reliable provisional response, !!has received a
PRACK for that reliable provisional response!!, has not received
any requests (PRACK or UPDATE) with offers that it has not
answered, and has not sent any UPDATE requests containing
offers that have not been answered."

comments?

regards,
Salva

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Matthias Konrad" <[email-masked]>
Date: Wed, 31 Jul 2002 11:01:30 +0200

Hi
"Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in either
   direction."
This is only about new INVITE transactions within an "existing" dialog.
If the UAS has sent a 200 ok, a new INVITE transaction within a dialog is
just a
(re) INVITE.

So your other question was, why the rule for other responses than 200ok are
different. Are they? It is just, that the TU is responsible for the ACK
handling and not the transaction layer itself. And that is, because positive
final response are end to end acknowleged an negative ones hop by hop.