Re: [Sip] offer/answer exchange

["Matthias Konrad" <mkonrad@hsr.ch>]

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.




----- Original Message -----
From: "Salvador Rey Calatayud" <salreyca@teleco.upv.es>
To: <sip@ietf.org>
Sent: Wednesday, July 31, 2002 9:45 AM
Subject: [Sip] offer/answer exchange


> 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip