Subject: [Sipping] UPDATE vs reINVITE

From: "Nina Garaca" <[email-masked]>
Date: Tue, 11 Jul 2006 12:48:22 +0200

Hi,

I was thinking about differences between a reINVITE and UPDATE request. 
According to RFC 3311 the re-INVITE request has an impact on the state of the dialog, while the UPDATE request hasn't. On the other side, the same RFC 3311 claims that the UPDATE is a target refresh request, which consequently changes the dialog state. I would like to hear some explanations on this subject.

RFC 3311:

The primary difficulty is when aspects of the session need to be modified before the initial INVITE has been answered.  An example of this situation is "early media", a condition where the session is established, for the purpose of conveying progress of the call, but before the INVITE itself is accepted.  It is important that either caller or callee be able to modify the characteristics of that session (putting the early media on hold, for example), before the call is answered.  However, a re-INVITE cannot be used for this purpose, because the re-INVITE has an impact on the state of the dialog, in addition to the session.
As a result, a solution is needed that allows the caller or callee to provide updated session information before a final response to the initial INVITE request is generated.  The UPDATE method, defined here, fulfills that need.  It can be sent by a UA within a dialog (early or confirmed) to update session parameters without impacting the dialog state itself. 
The UPDATE is processed as any other mid-dialog target refresh request, as described in Section 12.2.2 of RFC 3261 [1].

Regards, Nina Garaca.
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.5 - Release Date: 12/26/2004
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Nataraju A B" <[email-masked]>
Date: Thu, 13 Jul 2006 17:11:14 +0530

Comments inline… 

Thanks & Regards,
Nataraju A.B.
-----Original Message-----
From: Nina Garaca [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 4:18 PM
To: Sipping
Subject: [Sipping] UPDATE vs reINVITE

Hi,
 
I was thinking about differences between a reINVITE and UPDATE request. 
According to RFC 3311 the re-INVITE request has an impact on the state
of the dialog, while the UPDATE request hasn't. On the other side, the
same RFC 3311 claims that the UPDATE is a target refresh request, which
consequently changes the dialog state. I would like to hear some
explanations on this subject.
 
[ABN] with respect to target refresh, both reINVITE and UPDATE would do
the same. But for some other functionalities they differ. For example,
if we want SDP re-negotiation, then reINVITE is preferred over UPDATE.
Because there is no guarantee that the re-negotiated media information
reached UAC or not. Soon after UAS sent the 200-UPD can't start using
the new SDP information, 

Since there is no guarantee that, 200-UPDATE reached UAC or not, we
don’t have any conformation whether we can start using new SDP or not,
re-INVITE is preferred over UPDATE for SDP renegotiation. 

Note: in general a single request would do multiple functionality, that
is why we have use each of them depending on which is of most
appropriate. 

RFC 3311:
 
The primary difficulty is when aspects of the session need to be
modified before the initial INVITE has been answered.  An example of
this situation is "early media", a condition where the session is
established, for the purpose of conveying progress of the call, but
before the INVITE itself is accepted.  It is important that either
caller or callee be able to modify the characteristics of that session
(putting the early media on hold, for example), before the call is
answered.  However, a re-INVITE cannot be used for this purpose, because
the re-INVITE has an impact on the state of the dialog, in addition to
the session.
As a result, a solution is needed that allows the caller or callee to
provide updated session information before a final response to the
initial INVITE request is generated.  The UPDATE method, defined here,
fulfills that need.  It can be sent by a UA within a dialog (early or
confirmed) to update session parameters without impacting the dialog
state itself. 
The UPDATE is processed as any other mid-dialog target refresh request,
as described in Section 12.2.2 of RFC 3261 [1].
 
[ABN] The 3261 clearly says, there could only one INVITE transaction
open at any point in time within a dialog. I mean to say when INVITE
transaction is not complete you can't initiate re-INVITE. This will
upset the dialog handling. 

I am not very sure why this distinction for INVITE (same problem could
happen with any other dialog creating request) whereas there could any
number of open non-INVITE transactions at any time. 

Probably the best option would have been to have only one open dialog
creating request and any number of non-dialog creating requests. 

Am I missing something here? 

Regards, Nina Garaca.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jul 2006 14:58:44 -0400

> re-INVITE is preferred over UPDATE for SDP renegotiation. 

I don't agree with your conclusions. If the 200 UPDATE doesn't arrive, 
the UPDATE will be restransmitted, and then the 200 UPDATE will be 
retransmitted. And this is no worse that INVITE when answer is in the ACK.

Also, nothing prevents you from "using" the SDP before you know it has 
been received. You only listen using your own SDP, you transmit using 
the SDP from the other end. Worse case is that you listen and don't hear 
anything.

So I think the use of UPDATE need not be restricted as you suggest. In 
some cases, such as before an INVITE has completed, it is the only way 
for the UAC to make another offer if the initial offer was already 
answered before a 2xx is received.  (This is mostly for preconditions.)

In other cases it is just more convenient because it takes one less message.

> as described in Section 12.2.2 of RFC 3261 [1].

The above is problematic language, that should be improved. Like many 
things related to dialogs it suffers from confusion about what is dialog 
state and what is state of the dialog-usage. The key thing about the 
above is that UPDATE is permitted between an INVITE and the 
corresponding ACK, and may be used to convey a new offer/answer, as long 
as the rules of 3264 are followed.

> Am I missing something here? 

Yes, a bunch. You are however right in that this is probably more 
complex than it needs to be, for historical reasons.

You should see:

draft-sawada-sipping-sip-offeranswer-01
draft-ietf-sipping-dialogusage-02

	Paul